Ipa concepts and applications in engineering ebook lib

The processes, based onthe articulated process, presented above and actually realised in life by particulardesigners, could have had many different forms resulting from personal experien

Series Editor

Dr Rajkumar Roy

Department of Enterprise Integration

School of Industrial and Manufacturing ScienceCranfield University

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

IPA: concepts and applications in engineering – (Decision engineering)

1 Engineering design – Data processing 2 Decision support systems

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

Apart from any fair dealing for the purposes of research or private study, or criticism or review, as mitted 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 publish- ers, 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.

per-ISSN 1619-5736

ISBN 1-85233-741-9 Springer-Verlag London Berlin Heidelberg

a member of BertelsmannSpringer Science+Business Media GmbH

http://www.springer.co.uk

© Springer-Verlag London Limited 2004

CLIPS is a rule-based language that was developed by NASA’s Johnson Space Center.

GBB is the product of Knowledge Technologies, International Inc., Flexible Service Center, 211 West State Street, Suite 203, Media, PA 19063, USA http://www.ktiworld.com/GBB/

Goldworks III is the product of GoldHill, 36 Arlington Road, Chestnut Hill, MA 02467, USA http://www.goldhill-inc.com/goldworks.htm

The use of registered names, trademarks, etc in this publication does not imply, even in the absence of

a specific statement, that such names are exempt from the relevant laws and regulations and therefore free for general use.

The publisher makes no representation, express or implied, with regard to the accuracy of the tion contained in this book and cannot accept any legal responsibility or liability for any errors or omis- sions that may be made.

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

This book presents the results of extensive research in computer-supported decisionprocesses in engineering, carried out over many years by the author and his collab-orators The author has cooperated with designers in Poland and in Germany Veryoften there was university–industry cooperation for the building of specific soft-ware for certain engineering tasks

The majority of the concepts, for example “the designer’s personal assistant” andthe decomposition and coordination of multicriteria decision problems, evolvedthrough cooperation with designers in this field The author, while working togetherwith them, understood that this group of people is characterised by a strong indi-vidualism and that the range of applied approaches and methods is wide

The most significant influences on the author’s opinions through contact with thedesigners were the lectures he delivered for more than 12 years for post-graduatestudies on computer-aided design in machinery The lectures included seminarswhich required the creation of concepts for an individual computer support systemfor decision processes, generally well known to the designers who participated in thelectures In the theoretical part the characteristics of the actual computer-aideddesign and engineering (CAD and CAE) tools were depicted, whereas in the practicalpart the students created concepts of computer environments for the realisation ofdesign projects in their own professional work The task was confined to the expres-sion of the design process This was followed by the development of a concept for theimplementation of different computer technologies in the next stages of theirprocesses The lectures were attended annually by 15 to 25 participants, allowing theteacher the opportunity to cover quite a wide spectrum of real industrial designprocesses The majority of students worked in machine industries with different pro-duction outputs and product ranges: from aircraft components to a production linefor the spraying of car bodies, and from the development of mobile aerial systems tothe production of lightbulbs Several concepts worked out during the seminars werelater realised in practice

It remains to be added that the lectures were conducted flexibly and openly anddid not aim at systematic design according to a certain design theory.Although elem-ents 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 andfurther developed by ordinary students and research students Looking at the multi-tude of solutions of the design processes, the author drew the conclusion that thedesigners’ individualism and internal personal factors play an essential role Because

of that it became important to notice the permanent development of individual eering knowledge, its richness in facets and its constant evolution Another obser-vation is the omnipresent re-using of previous processes, their forms of descriptionand the adjustment of the modelling In spite of certain limitations, often creative

engin-v

elements with the freedom to create new processes could be observed This mostlyworked by using well-known tools, that is, existing and reliable sub-processes.Interesting was the relationship between designing and the multicriteria optimi-sation methods It became obvious that the multicriteria optimisation methods pre-sented as decision-making theory were widely accepted in connection with everydaydecision 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 wereimplemented within larger projects, and others became the beginnings of a productthat is still being developed

Apart from the direct working collaboration there were many discussions, ments and suggestions

com-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 colleaguesand collaborators of the computer techniques team at the Institute of MachineDesign Fundamentals at the Warsaw University of Technology: Janusz Bonarowski,Jacek Jusis, Boguslaw Kozicki, Grzegorz Linkiewicz, Witold Marowski, StanislawSkotnicki, and Jerzy Wróbel

Many problems were solved practically by numerous students, research studentsand 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 friendsSophie and Chris Klimiuk who made every endeavour to give my book its final shape

1 Introduction to the Problems of Knowledge-based

Engineering 1

1.1 The Role of Knowledge in Design 1

1.2 Concepts of Design Rationale 10

1.2.1 Design Knowledge Repositories 10

1.2.2 Introduction to the Concept of an Intelligent Personal Assistant 18

1.3 Examples Explaining the Sense of Knowledge in Engineering Design 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 Multiobjective Optimisation Layer 113

9.2 Formal Model of a Machine Design Problem 118

9.3 Two-level Optimisation Method 125

9.4 Concepts of Criteria Space Ordering 126

9.5 Relationships Between Different Concepts of Criteria Space Ordering 128

9.6 A Survey of Selected Multiobjective Optimisation Methods 129

vii

9.6.1 Methods Based on the Value Function Concept 129

9.6.2 Method of Interactive Multiobjective Optimisation 130

9.6.3 Method of Constraints and Utopia Solution 131

9.6.4 Lexicographic Approach 132

9.6.5 Characteristics of Multiobjective Optimisation Methods 133

9.7 Additional Assumptions in the Formulation of Large Optimisation Problems in Machine Design 134

9.8 Method of Leading and Related Sub-problems 137

10 Intelligent Personal Assistant – Implementation 145

11 Intelligent Personal Assistant – Unified Framework 157

References 159

Further Reading 167

Index 169

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 mechanicalproducts and mechanical design processes

The goal of design is to create a vision of a product The product is then keted with the aim of achieving a scheduled position The design procedure is car-ried out by designers working individually or in design teams They have to startthe whole procedure from an initial specification First they plan their design activ-ities and discuss details of the design The designers’ planning and handling isbased on short-/long-distance strategies The strategies can have many differentgoals Designers have to develop the concepts of a product, which are then evalu-ated, and subsequently the designers generate a project in detail The detailed doc-umentation is nowadays mostly done by computer

mar-Design is an activity where designers create new solutions This activity, since ithas a beginning, a middle consisting of various stages, and an end, is called a process(Figure 1.1) It is very difficult to create a formal model of such an activity Not everystep has a formal representation Much of the activity can take place in the designer’smind and so not necessarily be apparent to others The designer, looking for newsolutions, tries to test his ideas He has to model real situations He decides what ismodelled and how He analyses, considers different aspects, evaluates and synthe-sises The whole process consists of a number of actions which are treated by thedesigner as important, such as which should be performed The results of theseactions support the process of decision making – selecting partial solutions, select-ing subsequent problems and steps Finally, the designer decides when the results aresatisfactory and discontinues all actions

Let us take an example: the design process of the braking system design for amobile 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 theproduct of longstanding design experience The procedure wasdeveloped some years ago when calculations were generally carried

out without the use of computers It consists of linearly placed stepsthat are followed sequentially (Figure 1.2) In the case of difficultieswith fulfilling constraints in one of the steps it was necessary torepeat the design process from one of the steps preceding the cor-rected step Consequently the whole procedure had a linear form.

The original version of the process was depicted as a scheme onpaper and was stored in that form The scheme includes places wherethe designer had to look for external sources of information:catalogues,standards, etc Every step was regarded as an important activity, and assuch was connected with a number of design variables for which valueshad to be obtained during that step The values of the design variableswere calculated or selected from standards or catalogues

Design processes can be classified as routine, innovative or creative [10, 12, 32,109] (Figure 1.3) The borders between these classes are not very rigid However,our example can be called a routine process

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

vari-● If the set of design variables remains the same and each design variable fromthis set does not change its standard range during the design process, then wecall this process routine

● However, in the case where the set of the design variables remains the same butsome design variables from this set change their standard ranges, then we have

Standard components

Standards

Vehicle data specification

Braking force calculation

Pressure distribution

Selection of servo-motors

Selection of air containers

Composition of particular sub-systems

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

The characteristics presented in the above example are a kind of exposition – anarticulated process, represented in some objective form The processes, based onthe articulated process, presented above and actually realised in life by particulardesigners, could have had many different forms resulting from personal experienceand knowledge (Figure 1.4).

Knowing that this example was a process realised without computer support wecan easily imagine that all the steps were done by one particular designer and thatall intermediate stages were stored on paper The designer made calculations, andselected suitable parameters in catalogues and standards He probably discussedsome 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 designerlooked at existing projects, compared the results of the calculations and tried tocomprehend the decisions which were made in particular steps

However, he might have had difficulties with some information It is not alwayspossible to infer from written classic project documentation why he decided onthis option (Figure 1.5) Provided that the designer knows the type of the problemconsidered he may be able to understand the situation However, it often happens

Standard tooth gear

Standard list of design variables Z1 Z2 M A

B

…

Standard constraints

(a) Routine problem

Standard tooth gear

Standard list of design variables Z1 Z2 M A B

…

Standard constraints

D

Standard constraints

that people who carried out a certain design process in the past, after some timeforget the background details of a particular design situation.

The whole design process can be shown in a more formal way than so far in thischapter 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 thedesigner 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 isrecorded later in the formal project model and the formal project documentation

We should not expect this formal documentation to contain everything Somehowthere 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

Articulated design process

Personal variants of articulated design process

How was it done?

Realised design process Designer‘s real activities

Figure 1.5 Design process and its final results.

compromise of different goals created in a very subjective way.Very often one of thegoals 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 thedesigner remembers a lot of information from the overall accompanying data flow.However, we cannot fully rely on the designer’s ability to remember, although weshould notice that any data are at once validated by the designer The data receivecomments containing evaluations and associations made by the designer Thisprocess leads to the designer’s personal knowledge modifications and it is the basisfor knowledge development (Figure 1.6)

Most designers carry out many different projects throughout their lives Eachproject consists of a number of actions Many of the projects are good material forthe verification and modification of concepts which are stored as designers’ knowl-edge This knowledge has a dynamic aspect – it changes and develops

We can easily imagine the situation of a car designer in the 1970s An expertresponsible 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 usthat according to his knowledge the structure of the car body is the most importantaspect of car safety These are only two stages in the knowledge evolution of a par-ticular designer

As we can see, a designer’s knowledge is not only dynamic but also personal andconsequently very subjective From all the designer’s knowledge we only get to knowwhat is explicitly expressed by him He can express his knowledge through tellingand through sketching, etc However, the overall process of expressing knowledgerequires effort as well as time It is also influenced by exterior factors such as per-sonal relationships with other designers

Moreover, it often happens that some knowledge starts to evolve while beingarticulated Why is that? Because somebody who permanently works with theknowledge without being aware of it modifies the knowledge while sharing it withothers This means that he performs some extraction or verification It would cost

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.

enormous effort to update the exterior knowledge depot; it is a task that most peopleare not willing to undertake.

The designer’s auto-censorship is another aspect of personal knowledge sition Simply when he makes private notes (stored in his mind, on paper or in thecomputer memory) for himself he does it spontaneously and without further delib-erations However, when the notes are meant to be read by others, the designer, con-sciously or unconsciously, selects his information and considers the consequences.The knowledge which designers have in their minds has different levels of valid-ity It can be standard routine knowledge or very personal knowledge, which is notverified and more hypothetical We can observe this feature after longer coopera-tion with designers, with mutual trust For what they allow you to acquire depends

acqui-on a very subjective, persacqui-onal view and acqui-on human interrelatiacqui-ons

The last 30 years have brought a relatively high development of computer tools supporting engineers in their design activities CAD and CAE systems have becomeindustrial standards Many other engineering problems like simulation, analysis anddecision making have been supported by both commercial and non-commercial soft-ware Many of these systems are in permanent use Others are used from time to timeonly The ability to use these systems during the design process is connected withdesigner cognitive effort The way in which particular software is applied depends onthe domain, its traditions and the personal characteristics of the designer

Design teams, working on their projects, use various computer systems and manycomputer codes These systems and codes often function separately Mostly they arenot integrated and exist in several versions.In many design offices we can observe howdifferent computer systems are involved in design processes The existence of officestandards dealing with how they are used is noticeable These standards function assome office knowledge, as repetitive plans However, when we take a closer look at whytheir procedure is so similar to that of others or even the same, we will find that theirunderstanding of the problem is very individual and therefore different (Figure 1.7)

Designer X’s real design activities

Designer Y’s real design activities

Figure 1.7 Personal way of using computer tools.

There is a wide variety of computer tools, from which every designer selects agroup and uses it in his individual and subjective way (Figure 1.8) By doing so insome way, dedicated software for the needs of a particular designer is created Thisfact shows the individualistic aspect of the design process; and what we observewith single designers is also valid for design teams.

We have seen that designers’ work is very individual, in the way they use theirown approaches and methods, and their individual ways of seeing a problem.When we observe how these people solve their problems, we first notice that theyuse mental modelling, mental problem identification and mental problem-solvingprocedures They do mental exercises with the problem Sometimes they use hand-made 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 theimportant knowledge remains in designers’ minds

Designers differ in the way they solve their problems [5, 22, 35, 67, 106] There arepeople who do everything according to the methodical approach Others prefer to

do everything quickly in their minds without documenting and make fast jumpsbetween different methodical stages, while others like chatting to solve problems

In mechanical engineering, we observe that today’s designers tend to use puter tools at relatively early stages of the design process These cases are verydomain sensitive Designers often have a number of ready-stored sub-tasks, wellknown, well tested and well understood to some extent (Figures 1.9, 1.10) Whenthey solve a new problem they like to apply sub-tasks from their private repository

com-of tasks These tasks have their own knowledge and own rationale In most casesthey 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 sions: the number of such sub-tasks in the case of a particular designer may reachhundreds These sub-tasks are somehow knowledge-intensive processes Whileusing these sub-tasks, knowledge is acquired and verified Therefore, sub-taskschange in a very dynamic way Sub-tasks are ready to act as knowledge chunks.Because the customised software reflects the designers’“sub-task thinking” it shouldoffer the possibility of modification and easy redefinition.Without these features thesoftware will become outdated quickly

dimen-Ten to fifteen years ago we could observe that some software producers weredeveloping dedicated software for some “very important” customers Mostly it wasdone in narrow domains The development of the software was permanent and the

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.

relationships between user and software-maker were very strong Both partnersknew the whole problem very well but from different aspects.

After many years of this kind of development the computer systems whichresulted from this process had very personal features resulting from the personalknowledge of the designers, the software and the economic circumstances It is veryinteresting to see that among designers in the same country, in the same domain,with similar education at a similar age, but working for different firms, there is sig-nificant diversification of the structuring and building of sub-tasks This observa-tion makes software building a personalised engineering activity

Sub-task 1

Knowledge associated with particular sub-task in its historical development

Sub-task 2

Knowledge associated with particular sub-task in its historical development

Sub-task n

Knowledge associated with particular sub-task in its historical development

Computer tools for fast integration

Knowledge associated with particular sub-task in its historical development

Knowledge associated with particular sub-task in its historical development

Knowledge associated with particular sub-task in its historical development

Figure 1.10 Design process created from available sub-tasks.

However, parallel to this development, large vendors of software started to offeruniversal software, such as CAD/CAE systems with many possibilities that could becustomised to some extent In addition to this, the variety of the existing softwaretools supporting the design process allows it to be created in a very flexible way.When we look at the actual state of the development of computer tools supportingthe design process, accepted by the designers, we see quite a wide variety and flex-ibility Nevertheless, all these features allow the user to maintain an individual per-sonalised character throughout the whole computer support system.

Actually both kinds of software coexist and cooperate Not always does thedevelopment of software made by large vendors improve software which is madefor a very specific domain

1.2 Concepts of Design Rationale

1.2.1 Design Knowledge Repositories

Computer tools belong to the wide range of tools supporting the design process.Information processed by computer tools is not always integrated However, theintegration of computer tools can make the whole design process more efficient.Therefore the problem of fast, effective and flexible integration of design toolsshould 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 scienceachievements mean adding new sub-tasks to existing software and testing them inconjunction with the existing sub-tasks

We can observe a growing number of commercial systems offering the possibility

of fast and efficient integration These tools enable the user to integrate computer tems quickly and flexibly They also make it possible to store, repeat and optimise thewhole process and to perform parallel analyses with alternative models or software.The trend mentioned above concentrated on the aspect of “how” a particulardesign process was achieved In recent years, however, many research teams haveworked on the methodology and on tools whose main goal is to store the “why” ofthe procedure

sys-The information behind a project is called the design rationale [58, 99] sys-Thedesign rationale information tells why a particular design process has its actualform and why particular design decisions were made It can be stored as a full project history together with its background in the form of significant decisiondescriptions Another practical solution is the storage of design features togetherwith their argumentation

During the last 20 years a lot of research has been accomplished in this field Someapproaches 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 thenext step of this development.We can observe attempts to create knowledge-orientedstandards 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 inspecially made design knowledge repositories (Figure 1.11)

The main goal of collecting the information behind some decisions is to exploitthoroughly the existing knowledge, and to better organise the work of cooperatingteams 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, sented in this book, is based on the idea of an intelligent personal assistant Weassume at first that knowledge is delivered, serviced and managed by the designerpersonally for himself, in his notebook or his own personal computer database, andfor his own purposes

pre-If we think about the actual generation of engineering software and we try toimplement the designer’s knowledge in this software we will notice that this isnearly impossible First, it would be very distributed; second, permanently incom-plete and not integrated; and some research [19] has proved that designers do theirtasks 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 notesgenerally are stored in some paper notebooks The information in the notebookdoes 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 fordata is also done chronologically Sometimes keywords are important They can be

Design knowledge repository

Designers can be geographically distributed

connected with a particular project, the kind of analysis, results, comments or dates,perhaps functioning as headings Designers often make notes which do not onlydeal with the actual problems but which are also more general comments on sometechnical problems and situations They store their conceptual visions of products

or some aspects of their functioning Designers’ notes often contain comments toother data structures like formal project documentation, formal analysis, formalcontacts, 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 ofthe notes are selected and again transformed into a practical form – to a piece ofaction in the design process, and we obtain valuable results The whole proceduredescribed 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-basedcomputer 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 (expertdesigner) purposes In this case the system fulfils the role of the expert’s activenotes This knowledge may contain comments relating to different models, param-eters, 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 alsowant to keep the user’s personal opinions and his personal knowledge chunks withtheir different representations, because it is likely that the user has had differentassociations connected with different pieces of knowledge or information

Designer’s “drawer depot”

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

Every design office has its own knowledge, specialisation, achievements and style

of work The knowledge of the whole design office can function in different forms:

as human (designers’) knowledge, knowledge encapsulated in documents, in written software, in commercial software and in an officially accepted procedures.This knowledge, available in the office, decides what products can be designed, howthey are designed, what analysis should be made in the design process, what goals can

self-be achieved, what the design process is like and what it consists of in a particular case.The knowledge stored in a design office is in permanent evolution Each projectcan give impulses for articulation of a new knowledge chunk or for the modification

of an old one

Designers’ knowledge can exist in a variety of forms Non-articulated ledge, 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

know-or from the analysis of projects made by other people In both cases the knowledge

is very closely connected with the human and personal way of problem solving

At first, some people approach new problems by analysing many things mentally,some look for inspiration, some start doing conceptual models with computertools, and others like to discuss the case with each other [5, 22, 35, 67, 106].With each

of these approaches very personal procedures are connected For instance:

● What plan should be used for the first concept creation

● How to create a first conceptual model with the help of the computer tools

● How to continue the discussion with other people

● How to provoke their interest

Finally, all the information gathered while dealing with the problem in differentways is stored in the designer’s mind with his own personal interpretation; andimportantly, this interpretation changes in the course of time

In this case human designers are the acting power which can transform suchknowledge into a sequence of activities which will eventually lead to valuable solu-tions The principal problem is how to acquire, capture and encapsulate as much aspossible of this knowledge in computer repositories

Computer tools used in the design process are developing towards supported software Many technologies belonging to artificial intelligence arestarting to support classical engineering systems (expert systems, case-based rea-soning, neural networks, machine learning, intelligent databases, embedded artifi-cial intelligence technologies, blackboard architecture, intelligent agents etc.) Allthese movements lead in the direction of software taking the role of a knowledgerepository and are a mixture of many techniques and software based on differentcomputer technologies (Figure 1.13)

knowledge-Many design problem analyses are based on knowledge which is the result of along period of design experience, for instance the long period of modelling andanalysing dynamic phenomena of some structures with the help of multibody for-malism With this the designer exploits theoretical knowledge together with theknowledge he gained during earlier design activities While working he conducts akind of dialogue – between the problem actually solved, his own available know-ledge sources and cases from his past experience

It is not easy to depict what knowledge is needed to solve particular problems inmachine dynamics In any case we need a theoretical basis, experience and the abil-ity to model successfully, to make correct observations and to create a suitable

hypothesis Most of these elements are rarely found in the literature Authors whowrite about problems of real systems mostly concentrate on some theoretical orpractical cases and do not describe their full decision path (including positive andnegative experiences) The fact that such knowledge may not exist in the literature,and thus is not officially expressed, does not mean that it does not already function

as expert knowledge, which – more or less efficiently – helps to solve some kinds ofproblem Human experts exploit their own memory for storing such knowledge.Sometimes they have some notes or some schemes Experts conduct dialogues withdifferent knowledge sources such as what they remember, what they have as papernotes and what they can retrieve from the past stored on their own computers

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.

Example 1.2

Let us assume that a designer solves problems of machine dynamicsconcerning 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 besolved.While working he exploits his earlier experience and his earlierstored knowledge Designing can be regarded as a process of movingslowly in the direction of valuable conclusions During this process,documentation, comments, hypotheses and conclusions are perma-nently created and verified

Because of their size, machine dynamics problems force expertdesigners permanently to learn and to articulate new knowledge.Everything is very subjective There are different levels of knowledgevalidity Therefore, the process of multisession testing of the know-ledge is very important It enables the designer to modify andimprove the articulated knowledge Knowledge is a side-effect ofdesigning It appears and it may be stored

We assume that the designer will use knowledge stored in the lowing forms:

fol-● Classic notes stored with the help of relational database technology

● Rules consisting of two parts, condition and action (e.g., when wehave 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 ofmultistage processes and can be modelled in the simplest case as linearsequences of activities As a consequence the linear model consists of anumber of ordered nodes corresponding to particular activities.Important events from a particular design process are the basis for thenode separation

The knowledge sources can be decomposed into subgroups andthen connected with particular nodes of the linear process model(Figure 1.14)

Consequently the knowledge-based system, which supports theprocess of modelling and analysis in machine dynamics, can consist of

Expert system Case-based reasoning

Data base

Figure 1.14 Relationships between different knowledge sub-sources.

a number of knowledge sources, which are connected with particularnodes 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 body formalism, which is stored in the form of rule-based knowledgebases, relational databases, and multimedia

multi-● Case-based knowledge, resulting from problems solved in the pasttogether with knowledge explaining past solutions and know-ledge, describing the estimated range of a particular case adapta-tion (expert system technology, databases and multimedia)

● Descriptive knowledge, in the form of text and multimedia mation, stored in a relational database

infor-Figure 1.14 presents the scheme of a knowledge aspect in a particularnode It shows that in every node of the linear model we can activateany knowledge source, which supports the generation of missing data.Consequently the linear model of the analysis process is equipped withcomponents which should allow modelling that correlates withhuman experience and time evolution

Consultations with our domain experts (on car dynamics and fluidflow dynamics problems) proved the fact that the global knowledgeproblem for particular real machine dynamics problems has a mazestructure (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.

models of the design process (Figure 1.16) [9, 10, 75, 78, 83, 132] In amaze model the designer can start the process of designing from aset of nodes His way of moving in the maze can be created individu-ally and each time he can finish designing in a different nodebecause not every design process looks the same.

Let us consider a single node of the maze model Let us start withthe assumption that we want to move from one node to the next Forthis purpose we can employ a relevant knowledge source and lookfor theoretical or practical experiences; most importantly, we canmove from one node to the other via special links called associationlinks The association links are special fast connections between dif-ferent knowledge sub-sources belonging to different nodes.They arecreated by the designer while using the whole structure

Designers often solve parallel alternative problems If we add theideas mentioned above to our concept of environment it means thatthe designer can move in the maze,change his knowledge sources andconsider (i.e., change dynamically) several projects at the same time.Parallel to the process of creating a path in the maze model thedesigner can try to select the best parameters for his solutions and as

a consequence create a sequence of problems belonging to the egory of optimisation problems (Figure 1.17) We can assume thatwith every node of the maze model can be connected a multicriteriaoptimisation problem created by the designer by selecting decisionvariables, constraints and criteria functions.The sequence of optimisa-tion problems – accompanying a path in the maze model – can bemutually interacted with via decision variables, constraints or criteria

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 elec-tronic 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 nolonger 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 theauthor in new documents, this means less work in the future

In the book we try to interlink two ideas:

● A computer system integrating computer design tools

● A computer system fulfilling the role of an intelligent personal assistant.The book presents the concepts of a knowledge-based system supporting machinedesign 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 veryintuitively and descriptively The basic meaning of this term is widely known

Somebody can have knowledge, knowledge can be available, and can be created,captured etc We can imagine that knowledge can be stored and later be re-used.Knowledge is behind all human activities However, it is difficult to explain whatknowledge 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 completedesign process is relatively comprehensive and complicated For ourpurposes 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 haveseveral pairs of cooperating toothed wheels? There is basic theoret-ical and practical literature dealing with these topics Should we lookfor knowledge there? Certainly there will be a lot of information,which should provide knowledge on this problem However, there islittle chance that we will find something that fits our design situationexactly Probably only a part of the information found will be helpfulfor our purpose Therefore we will have to do some intellectual workand 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 wecan find procedures which consist of steps – single activities where

we can get ready information on how to solve our problem Maybethis procedure can even be done on a computer system where ourrole will be reduced to problem modelling and evaluating the finalresults

In both these cases we can speak about knowledge The ledge can be stored for instance in books, or as an algorithmic proced-ure forming the basis of some computer code (Figure 1.18) Ourknowledge can have the form of separate knowledge chunks dealingwith different topics and can tell us about the multitude of problemsconnected with our domain without any specific intention.This is theform which we know from lexicons, encyclopaedias and specialguides It is easy to imagine that today such an approach exists in theform of computer multimedia applications equipped with a number

know-of tools (keywords, searching, browsing) helping to find the propertopics (Figure 1.19) Such applications are produced by firms or pub-lishing companies Some of them are accessible to everybody via the internet, others only to users who have been granted the right touse them

Browsing, searching

Results: text, pictures,

Browsing, searching

Figure 1.19 Looking for knowledge in knowledge repositories.

Design process based

on literature

Design process based on literature and expressed as computer code

Project documentation

Project documentation

Figure 1.18 Design process represented in two different ways.

How can the designer use such an application? First he must clearlyknow what problem he has to solve Then he decides on several keywords and starts searching Finally he gets some results, forinstance some pieces of information in form of articles Let us assumethat he selects two of them, reads them, and starts again with newkeywords and new searches, and the procedure continues In thisapproach 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 (bythe designer) The whole approach is shared between the designerand the computer We call such an approach “human interpretable”.Inthis case the human plays the key role Obviously our knowledgestored and manipulated this way can be connected with some narrowdomain and can then have the form of specially prepared recipes.Moreover the knowledge can be continuously updated From this acomplete management system can be made.The knowledge which isstored cannot only be used by a single designer, but also by a depart-ment or by the whole company.The system in question can exist as anautonomous application or as a deeply integrated system In the lattercase such an application looks like a help tool only, but in reality itoffers rich functionality and it is an intelligent assistant

Example 1.4

Let us turn towards a system which supports the design process of acar braking system (Figure 1.20) [102] Naturally such a system is rela-tively large, consists of a number of modules and is integrated with

a database of components offered by different suppliers Designerswho work on braking systems often have to consider whole families

of cars and at the same time they must try to reduce the number ofbraking system variants They have to compare the results of theirwork with former models, models from competing companies etc Inany of these analyses they need approximate data for instance aboutthe centre of mass These data are often evaluated on the basis ofsome knowledge We can imagine a system where a module whichsupports generation of missing data is added to those modules aid-ing the design of the braking system; and this additional module isorganised as an application with keyword searching

It is very useful to have the ability to move directly among differentmodules An example of such an application is shown in Figures 1.20and 1.21

Reading and understanding information costs effort Therefore we should considerwhether this effort can be reduced The knowledge chunks stored in the system arerelatively short and are not complicated This means that what we store normallyshould be represented in a more decomposed way We can imagine that our know-ledge chunks can have the form of rules where the first part contains the conditions

which should be fulfilled and the second tells us what actions can be taken after theconditions have been fulfilled The main problem is that we have to prepare a lot ofsuch 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 performthe inference We may start from some initial keywords; later our control systemlooks for knowledge chunks which have conditions fitting our keywords After hav-ing used the knowledge chunks found, the result can be stored and be the basis forthe next automatic attempt to find suitable knowledge chunks This procedure can

be continued again and again

The process of inference presented above is nearly an informal description of theway that classic expert systems solve problems However, we want to make it moreformal 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

Knowledge chunks supporting assistance, implemented into system System functionality

Main window of system – procedural processing

Integrated knowledge-based assistance module

Figure 1.20 System for car braking systems design support.

process in the case of a computer-interpretable application does notonly work with information which is in the form of words (strings) Itcan also make modifications to technical models, geometrical andnon-geometrical.

Let us consider the following case We want to integrate inferencetogether with geometrical modelling For instance we want to create

a geometrical model of components belonging to the car gear box: atoothed wheel together with a clutch cooperating with a wheel [92].For this purpose we may create a number of variables which are basicparameters of the toothed wheel If we want to obtain a geometrical

Data flow from procedural part to knowledge-based module

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

Example 1.6

Let us take another example belonging to the category of ledge-based non-geometrical systems It is a system which supportsthe design process of a piping system [74, 85] (Figure 1.23) The spe-cialised system consists of two sub-systems: one models the geom-etry of the piping system and the other analyses the problem of fluidflow dynamics within the system These sub-systems are connected

know-to each other The generaknow-tor of the fluid flow dynamics model is aknowledge-based system When the geometry of the piping system

is given first, the user can later add some physical data and then getthe pressure distribution in the piping system

The knowledge-based system was filled with the knowledge ofhow to transform a geometrical model and its physical data into afluid flow dynamics model Thereby about 60 rules which supportedthe model transformation were created Additionally the geometricalmodel required physical data like pressure, flow or temperature

Basic initial parameters

of toothed gear

Parametric formulas for toothed wheels Rules defining geometry of clutch

Complete assembly

Parametric and knowledge-based model of toothed wheel

Knowledge-based model of clutch

A special editor supporting the physical data modelling, as valuesconnected with geometrical primitives, was developed Some datawere generated on the basis of an algorithmic approach, for instancethe flow resistance calculations for different structures like bends andvalves Rules deciding what is processed in which part of the piping

Knowledge-based module for fluid model generation

Cells

Links .

Simulation

State variables in nodes (in time domain)

Results analysis

Figure 1.23 Functioning of system for fluid flow dynamics analysis.

network were created.The knowledge-based module could then ate a dynamic model of fluid within the geometrical model of thepiping system The results of the simulation were presented as dia-grams modelled in a geometrical model There were static diagrams

cre-of different state variables anywhere in the network, or diagrams andanimations were made on an indicated path in the piping system Inthis way the user could work with the system without knowing thesimulation system

In the above examples we showed that our knowledge dealt with the problem offeatures in particular.We see that the knowledge can be connected with design sub-tasks which are knowledge-intensive processes

● 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 exploittheir imagination and work with pictures in their minds Then they try to figureout characteristics of the problems Often, while explaining their task to other people, designers begin to understand the matter themselves It becomes more clear

to them and they find new ideas

With more complicated problems some designers try to sketch their ideas onpaper or use a CAD system Others build physical models and test their concepts atonce in “reality” The third group are quick thinkers who are immediately able toexpress their ideas on how to handle the problem Others have to speak with otherpeople Finally, all the different ways of approaching a project help the designers tounderstand the main problem of the task and clarify its characteristics

During this initial stage of the process the designers look for new informationand try to form associations with what they already know Everything is done withthe intention of finding a solution to their problem They do some mental inference.The designers do their analysis with the help of a multitude of models and tools.The models which are considered could exist only in the designers’ minds or beexpressed in a more formal way The designers build the so-called formal modelsoften by using formal methods and formal software

The human ability to build models and test them is still the key aspect of ing Specific knowledge is connected with every technique of modelling and analy-sis This knowledge decides what analysis can be done, what goals can be achievedand how the design process can look in a particular case

design-The sequence of problems considered in the design process reflects the designhistory and can be a good source of information for solving particular problems Itmay also be a source of available plans already applied in a design process.The knowledge stored by designers is continuously modified Each project analy-sis can give impulses for a new articulation or modification of a knowledge chunk.Designers exploit their own memory for storing different kinds of knowledge

or for the evaluation of other knowledge sources by referring to notes andschemes

Very interesting results with the interdisciplinary empirical studies of ing design can be found in [5, 22, 35, 50, 51, 67, 100, 106] The research presented wasdone in industrial design offices and university laboratories over many years One ofthe goals of this research was to answer the following questions from the perspective

engineer-of our times:

● What patterns of thought do designers use while problem solving?

● What is the influence of formal methodologies?

The results obtained are multidimensional Details of different design stages, ferent models, different tools, the influence of computer tools and the way they areused are considered Very informative are the results of the comparison betweendesigners who are only practitioners and designers who have a methodologicaleducation Along with this are extremely interesting comments about the form ofinformation which is applied during the design process and the way this informa-tion is transformed The observed relationships between individual and team work

dif-in real cases are significant, for dif-instance [67]: “dif-in design processes dif-individual workdominates to an extent70% compared to 30% of teamwork.”

For us, most significant is the variety of ways that designers do their job at eachstage (individually or in a team) We can notice a strong influence of subjective andpersonal factors If in addition we think of the knowledge behind every design deci-sion, we see clearly the importance of these personal and subjective aspects; most

of the design knowledge has such roots Environmental conditions can also play asignificant role

If we want to consider a particular design process realised by a particulardesigner we not only have to understand his actual knowledge-intensive activities,but also some background knowledge concerning his professional experience Inthe 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 beexploited to a wider extent New methods have been developed which were origin-ally invented as a computer approach The problem of interaction between man andthe computer implementation of a particular method has become very important.The interaction between the designer and the design problem can be considered ondifferent levels The levels are set on the basis of cooperation between man and com-puter However, this classification has a very strong influence on the particular leveland 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 abstractlevel, which is very well synthesised The knowledge presented in this context isvery valuable We can observe an articulated knowledge structure, its hierarchy

and its dynamic historical aspect Hereby the designers use analogies andmetaphors while explaining Listening to them, we can almost sense (if we haveenough imagination) how two surfaces cooperate in a joint or how one toothedwheel fits into a second one, for example.

● Designer-methods of particular domains (methods which belong to a particulardomain and have an acting function) They support the process of achieving valu-able solutions Most of the designers who achieved the first level did their workexploiting relatively wide experience with some models and methods Each oftheir cases solved in practice has a knowledge-intensive background They canpresent practical knowledge on how to solve a particular problem by giving theevaluation of the whole approach Additionally they compare this approach withother approaches, indicating their advantages and disadvantages We can learnhow the approach was developed over some years

● Designer-methods of a particular domain in a programmed form Today many ofthe engineering problems are solved with the help of computers Consequentlybehind the designers’ decisions stand processes or other steps realised by com-puter systems This is connected with very practical knowledge assisting in solv-ing design problems with a particular computer code

● Designer-computer systems, including methods of a particular domain in grammed form Rarely does a designer use only one single computer tool Often

pro-a vpro-ariety of tools pro-are used pro-as pro-a ppro-art of pro-a lpro-arger tpro-ask This cpro-an be thought of pro-as thebuilding 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 newtasks 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 com-puter 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 hismental models Then he must “squeeze” them into the frames of existing computersystems

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 hismental work can be placed in the formally developed models and descriptions.This is a situation we are always confronted with, irrespective of whether we usecomputer 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 formalrepresentation can ever be

Let us take an example from machine dynamics

Example 2.1

The development of computer technologies has a strong influence onthe range of analysis in machine dynamics [12, 72, 78, 90] Many prob-lems previously regarded as complicated have become routine

However, some classes of problem have been left unchanged by thisdevelopment Up to now it is still difficult to store the knowledge ofmodelling and solving a particular problem.If somebody wants to solve

a certain problem in machine dynamics (a particular phenomenon or

product) he has to build (or select from earlier considered models) andexamine several models This process can be called problem learning(by the designer) In many cases it is a long and time-consumingprocess.

The modelling of a car dynamics model means a lengthy period ofwork for the designer For the modelling of a specific multibody system,for example, it is necessary to describe a system of bodies, their connec-tions, their parameters and their external forces

A real car dynamics problem will serve as our example:the stabilisingmoment of the steering wheel We started analysing our problem byreviewing relevant literature.We found several descriptions of this prob-lem There are also some theoretical models and mathematical formu-las.They present a part of the abstract knowledge,which gives a generaloverview of existing problems However, in the literature there arehardly any examples of described models It is very difficult to find outwhich 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 wearranged meetings with an expert from the domain [12, 78, 90] Theexpert 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 resultingfrom negotiations with clients, decisions regarding constructions of anew model and the adoption of a new problem to already existing solu-tions 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 threadoften refers to one of the previous cases Then he establishes the pro-cedure for the actual case and tries to generalise it.This is how a lineardescription of problem solving arises After the expert has presentedseveral cases we notice that there are common points in the set of lin-ear descriptions We connect these points and we notice that the out-put reminds us of a maze model Figure 2.1 shows us how to proceedwith the problem.The diagram presents the way of adapting the prob-lem to existing models and the possibilities of building a new model.The expert divided the problem into several subgroups These sub-groups distinguish the way the problem is perceived: how deeply onewants to analyse it, which situations are taken into consideration, if thedriver’s point of view is important in a particular case, or if the researchresults are to be used in court.When the problem is classified,it is neces-sary to find out the purpose of the research, what kind of data can bedelivered, and the influence of geometry relationships on the finalresults Finally, it is important to know who performs the researchbecause some of the developed models are of an enormous value andcannot be disclosed It should also be remembered that time and finan-cial resources allocated to a project are of great importance At the end