10 INFORMATION AND KNOWLEDGE MANAGEMENT IN PRODUCT DESIGN

Wilfred van der Vegte and Regine Vroom

Information and knowledge management (IKM) has the an overabundant source, containing obsolete or
potential to significantly improve the efficiency of the unrelated other knowledge.
design process, but it can also imcrease the success of
At the time of Court’s actual investigation (around 1993),
products. The objective of this chapter is to provide
the internet and other recent sources of knowledge were
insight into the kind of improvements that IKM can
hardly available, and Court mentioned that designers had
introduce in companies in general, and in product
to depend on the following sources: journals, magazines,
development more specifically, as well as the technologies
catalogues, libraries, external organizations, design guides
that are utilized to realize these improvements. One of the
and events (such as exhibitions, conferences and
primary aims of IKM is to make knowledge more
courses). Six years later, Bruggeling reported that at Océ,
accessible to everyone who needs it. The implementations
a Dutch photocopier manufacturing company, designers
of information and knowledge management that can be
also used the following sources to access knowledge: the
considered forms of ‘advanced design support’ are
world wide web, the company intranet, e-mail and the
typically in the area of computer-based IKM, which is also
product data management system. The arrival of new
the focus of this chapter. In practice, the terms
technologies offered opportunities to reduce the time
information and knowledge are often used
designers spend searching for knowledge, while the
interchangeably. For obvious commercial reasons,
advancement of computer technologies, such as CAD, has
‘upgrading’ existing solutions for data or information
also accelerated design activities other than those related
management to knowledge management solutions is a
to information finding. A negative effect of progress is
popular practice among software vendors and
that increasingly cheap data storage has resulted in huge
management consultants. To avoid confusion, we will
amounts of critical data, among which it has become even
refer to knowledge management and information
more difficult to find back the information. Thus, the time
management as IKM, and only make the distinction
savings brought about by new technologies are perhaps
between knowledge, information and data where this is
annulled by the increase of stored data that the same
relevant.
new technologies have caused when it comes to
Designing and developing products is usually a information finding.
knowledge-intensive activity with its own specific IKM
problems and solutions. In the following subchapters we 10.2 Types of knowledge
will explore the specifics of IKM in the context of product
design and development. Where it is needed, we will It was already mentioned that making knowledge more
discuss topics from IKM in a broader sense. accessible is an important goal in IKM. Usually a
distinction between more accessible and less accessible
types of knowledge is made. Such a distinction in types of
10.1 Knowledge-related problems in product
knowledge is useful because it makes it easier to identify
design and development
problem areas and to devise strategies for improvement.
One of the most recognized knowledge-related problems We can distinguish domain-independent or general types
in design is how to find the knowledge. According to of knowledge and domain-dependent or specific types of
research by Court and others, engineering designers knowledge. General knowledge may pertain, for instance,
devote 18-30% of their working hours to searching for, to an insurance company as well as to a design agency.
and handling, information and knowledge. Not finding the In our case, discussion of domain-dependent knowledge
knowledge is a problem that can manifest itself in many focuses on the domain of product design
different forms:
• It can be completely missing: both inside and outside
10.2.1 General types of knowledge
the company, the knowledge that is needed, e.g. to When it comes to general knowledge, perhaps the most
solve a particular problem, is simply unavailable; important distinction that can be made is the one just
mentioned: between more accessible and less accessible
• It can be untraceable, hidden or inaccessible: it is not
types of knowledge. More accessible types of knowledge
possible to find out who owns the knowledge or
are known as explicit knowledge and formal knowledge,
where the knowledge is stored, and in some cases it
while less accessible types of knowledge are known as
is not even known that it exists. Typically, this is
informal and implicit, or tacit, knowledge. Often the only
because the considered knowledge is only present in
distinction that is made is between explicit knowledge and
a tacit form, but knowledge that is readily available
formal knowledge on the one hand, and implicit, tacit and
can sometimes also be inaccessible, for instance,
informal knowledge on the other hand. In this syllabus we
because it is only available in a language that is not
will use a more subtle distinction, which will prove useful
understood. Sometimes knowledge is hidden on
in the explanation of IKM solutions in the further parts of
purpose – think of classified knowledge;
this chapter. The distinction between fundamental types
• It can be difficult to capture, for instance because it of knowledge is illustrated in Figure 10.1.
is unstructured, or because it can only found amidst

127
 The most concrete form of information is formal
knowledge. This is knowledge that is reproducible and
unambiguous. What is formal knowledge depends on who
of what is working with this knowledge. To a human, a
piece of legal text from a law book can unambiguously tell
him what to do or not to do, but to a computer equipped
with a compiler for a particular programming language,
only a well-written program in that language is formal
knowledge.
The next most concrete type of knowledge is explicit
knowledge. Explicit knowledge includes formal knowledge,
but it also includes knowledge that has been recorded in a
reproducible form and that is not strictly unambiguous,
for instance an informal textual description in a text book,
or a voice recording saved as an audio file. This
knowledge can be said to be informal, yet it is explicit
because it can be explicitly referred to. A computer can
store and process it as data (like the abovementioned
audio file) but not as knowledge because it is not formal.
In the real world we also have to deal with informal
knowledge that cannot be referred to, because it is not
available in any reproducible form. Thus this knowledge
lacks all the characteristics that explicit knowledge has: it
is implicit knowledge. It is also known as tacit knowledge.
Typical examples of implicit knowledge are ‘craftsmanship’
and ‘routine’, or the skills that someone has acquired to
do a particular job.
As an example, consider a company that wants to gain
knowledge from a successful design project in order to
make it available for future projects. If the achievements
of this project can be described in terms of types of
knowledge, it is easier to find out how the results can be
reused. Formal knowledge is the easiest to reuse: it can
be universally understood by humans and even be
processed by computer applications, if they are
compatible with the representation format of the
knowledge. Explicit informal knowledge can also be
reused but not by computers. The effort needed to reuse
it may depend on the person: it is easier for same people
who recorded the knowledge to reuse it than it is for
others. The other knowledge related to the project is tacit
knowledge. This is the area where the most additional
effort is needed for reuse in future projects. At best, it is
known what the tacit knowledge is about (e.g. ‘the skill to
create a shape that is attractive for the customer’) but not
what it contains and how it is utilized. At worst, the tacit
knowledge is not even recognized as knowledge, and thus
not recognized as something that is worth reusing.
Another practical general distinction is the one between
functional, operational and contextual knowledge.
explicit informal
knowledge knowledge
explicit implicit
formal
informal or tacit
knowledge
knowledge knowledge
examples
programmed textual a person’s skills
instruction description in accomplishing
for a machine in a book a task
Figure 10.1 General types of knowledge: explicit,
implicit, formal and informal knowledge
128
skills (experience, craftsmanship)
implicit
cognitive knowledge
(mental models, beliefs)
physical products
knowledge assets
software
product-bound
-
services
explicit
traditional media
documents
digital media
Figure 10.2 Subdivision of a company's knowledge
assets (adapted from Korbijn)
Functional knowledge (know what and know why) is
knowledge about a field of application, such as aesthetics,
mechanics or ergonomics. Operational or procedural
knowledge (know how) is primarily about acting and
primarily based on past experience. Learning by doing
plays an important role in acquiring operational
knowledge. In an industrial design-engineering
environment, knowledge about design processes and
design methods is a typical example of operational
knowledge. Contextual knowledge (know where and know
when) refers to operating in specific environments or
circumstances. An example in the context of industrial
design engineering is knowledge about suppliers that can
provide electro-motors for vacuum cleaners, or knowledge
about the vacuum-cleaner market in Germany.
Korbijn relates the general types of knowledge to the
knowledge assets1 of a company, which is formed by all
knowledge inside a company (Figure 10.2).
10.2.2 Specific types of knowledge in product
design
In design, we can also distinguish knowledge about the
product (which corresponds to both functional knowledge
and contextual knowledge), and knowledge about the
design process (corresponding to procedural knowledge).
Most types of knowledge in design, including knowledge
about the product and the design process, can be
somehow related to the product life cycle. Life cycle-
related knowledge is often subdivided into aspects
representing the various ‘x-abilities’ in design for X (DFX),
such as manufacturability, usability and serviceability.
Based on a model of the product, this knowledge can be
used to predict or to explore what will happen during the
product’s life cycle. They can also be converted into
prescriptive knowledge or guidelines, telling the designer
how to design, what to do next, or what to take into
account.
1
Korbijn uses the term ‘knowledge base’ instead of ‘knowledge
assets’. To avoid confusion with the knowledge bases discussed
in subchapter 10.6 and 10.7, we will not refer to a ‘knowledge
base’ in that sense here.

10.3 Knowledge flows and related tasks
‘Finding’ information and knowledge, as we mentioned in
subchapter 10.1, is an important issue for designers. But
to master the utilization of knowledge effectively, ‘finding’
the knowledge is not the only thing that needs to be
done. In order to be ‘found’, knowledge has to be ‘made’
first. To address the different treatments or conversions
that knowledge (or data or information) needs to undergo
before it can be used, knowledge-management specialists
typically distinguish knowledge flows consisting of various
steps or stages. There are numerous different models that
describe the steps or stages in different types of
knowledge flows, and we will not cover all of them in this
chapter. Anyway, the various models show a substantial
Figure 10.3 Knowledge flows (compilation from
various literature sources)
129
amount of similarity, and Figure 10.3 is an attempt to
combine different models of knowledge flows for
companies found in various sources in the literature.
Recognizing the different sub-processes in the flow of
knowledge is important if we want to understand the
different tools and techniques that are available in
information and knowledge management: what they do,
what they need, what they deliver, etc. With that in mind,
we will now describe the steps in Figure 10.3 in more
detail. Please note that most of the activities discussed
here can be thought of as performed by humans as well
as computers. Also, they are not necessarily the
responsibility of designers but to a large extent the task of
others inside and outside the company.
Knowledge, information and data may already exist in a
prepared form that makes it more or less directly usable,
inside or outside the company. ‘Searching’ and ‘finding’
knowledge is usually called absorbing or capturing
knowledge. For data and information, this process is
usually referred to as acquisition, collection or gathering.
These activities may refer to prepared data and
information as well as to unprepared data or information.
However, the process of acquiring useful data and
information from unprepared sources – for instance from
implicit knowledge – is more difficult and therefore it
typically requires a different approach. The term
knowledge acquisition is also used, but usually in a
broader sense: it refers to capturing knowledge plus some
of the succeeding steps, and it is also known as
knowledge discovery (see below). A related activity is
knowledge exploration, focusing on analysis (research) of
collected knowledge rather than using it directly – for
instance with the purpose to investigate general
characteristics of knowledge, to identify relationships
between pieces of knowledge or to find patterns of
knowledge.
A great deal of the efforts put into knowledge
management is in the conversion of data and information
into knowledge. Most sources in the literature identify
several steps of processing data and information before
the final step of conversion to formal knowledge, such as
clustering and structuring. Typically, these steps, and in
some cases also the final step, are considered to belong
to the field of knowledge discovery and data mining, a
range of activities that mostly leans on computer
technology. This area will be discussed into more detail in
subchapter 10.8. Depending on the quality of the input,
the processing steps may not only have to be applied to
data and information but also to already available
knowledge – for instance if the obtainable explicit
knowledge is not in a format that can directly be used
inside the company. In order to gain explicit knowledge
from data, information or implicit knowledge, the final
processing step of representing the knowledge is always
needed. If explicit knowledge is created based on data,
information and implicit knowledge, then the whole of
activities performed from acquisition to processing is also
called knowledge generation or knowledge synthesis,
because the result can be considered to be new
knowledge.
Once we have explicit knowledge, we can store or archive
it so that it can be utilized more than once. This is also
referred to as knowledge warehousing, as it is done in a
knowledge warehouse or knowledge base (subchapter
10.6), from which the knowledge can be extracted. If the
knowledge is actively made available to multiple
recipients, this is called distribution (or diffusion or
sharing) of knowledge. Finally, knowledge is there to be
used inside the company, it can be embedded into
products and it can also be sold or exploited externally to
turn into direct profit for the company.
We have to realize that these knowledge flows are not
necessarily limited to one company. For instance, for a
product-developing company, selling its knowledge
directly does not seem to be the most obvious activity,
but to buy knowledge from another company that has
made knowledge available, for instance through
consulting activities, software, a database or a website is
quite common. For the product-developing company, the
purchased knowledge is external input to its knowledge
flows, whereas for the selling company or knowledge
provider, the same knowledge is output. In some cases,
knowledge providers seem to provide useful knowledge at
no cost: we are probably all familiar with knowledge
portals and search engines such as Google (see
subchapter 10.9). Of course, these companies do make
profit from their knowledge, but they do this, for instance,
through advertisements rather than selling it directly.
Another obvious example of managing knowledge among
multiple companies is a context in which the companies
are working together in one project. It is clear that in
case of collaboration, the IKM practices of the various
participants have to be adjusted or adapted to each other.
Especially in the field of computer support and
communication, various software and hardware solutions
have been developed to make effective knowledge-
intensive cooperation possible (see chapter 2).
The overall process of adaptation, from one form of data,
information or knowledge to another one that is
eventually used, is called knowledge conversion. It is
important to note that in order to represent common
forms of knowledge conversion and real-life knowledge
handling in companies, various steps in Figure 10.3 can
be skipped. For instance, a very common form of
knowledge conversion is direct transfer of implicit,
personal knowledge from one person to another person,
for instance by exchange of experience, imitating, etc., as
it is done in the traditional master-apprentice context. In
Figure 10.3, this would correspond to a direct arrow from
unprepared sources of implicit knowledge to use of
knowledge. Even in modern product-development
environments, this type of knowledge conversion still
plays an important role. In their standard work ‘The
Knowledge-creating Company’, Nonaka and Takeuchi
distinguish four types of knowledge conversion: (1)
socialization: from implicit to implicit knowledge; (2)
externalization: from implicit to explicit knowledge; (3)
combination: from explicit knowledge to explicit
knowledge and (4) internalization: from explicit to implicit
knowledge (see also the example case in subchapter
10.5). They argue that a continuous cyclic succession of
these conversions, called the knowledge spiral, is
beneficial for the efficiency and the success of product
development processes.
130
The four types of knowledge conversion can be clarified
through a case study presented by Nonaka and Takeuchi
as a successful application of combining the four types of
conversion in a product-realization case, namely the
development of the first bread-baking machine that
Matsushita started in 1985. The objective was to allocate
the routine tasks involved in baking bread, such as
kneading the dough and adjusting the temperature as a
function of time, to a machine – which was in this case
not strictly a computer, but a consumer product
incorporating mechanical components as well as some
computing power in embedded software. A first prototype
based on objective measurements of temperatures,
kneading torques, etc., from baking processes, turned out
incapable of producing edible bread. One of the problems
that were recognized was that the kneading process is in
fact based on implicit knowledge owned by bakers.
Matsushita sent off Ikuko Tanaka, one of the members of
the development team, to work as an apprentice with a
master baker (socialization). When she had gained
sufficient kneading skills, she tried to explain the
technicians in the team how the kneading process should
be carried out by the product but it turned out difficult to
make the knowledge explicit in such a direct way. Then,
the technicians were also sent to the bakery and tried to
knead the dough according to their own implicit
assumptions of how it should be done, while Tanaka
watched them and tried to give instructions on how the
kneading movements should be modified based on the
implicit knowledge she had gained. This was also done
with the product prototype. Tanaka simply said ‘exert
more force’, ‘let the hook turn faster’, or ‘make a twisting-
stretching movement’ (externalization). After a tedious
trial-and-error process of several months, this process
resulted in a design with specially formed ribs inside the
baking tin to enable the twisting-stretching movement,
and optimized torques and rotation speeds (combination).
The product with its embedded formal knowledge was
launched on the market in 1987 and became an instant
success, which stimulated Matsushita to develop more
products to improve the quality of living in a similar way
(internalization).
Information and knowledge management is about
managing the knowledge flows, thus facilitating
knowledge conversion. Two different levels of IKM can be
distinguished: IKM at organizational level, also known as
macro-scale IKM, and IKM at application level, also known
as micro-scale IKM. The practical IKM solutions that can
be considered forms of advanced design support typically
belong in the category of micro-scale IKM. However, for
successful implementation of IKM in a company, it has to
be implemented at organizational level in the first place.
It is for that reason that in 10.4, macro-scale IKM will be
briefly introduced before the succeeding subchapters
elaborate on micro-scale applications and solutions.
10.4 Macro-scale IKM: managing information
and knowledge-related issues in
product development on an
organizational level
Macro-scale IKM in product-realizing organizations is
typically dealt with by the management and by
management-supporting staff, such as human resource
management (HRM). From that point of view, IKM
activities can be divided into two items respectively:
• Allocation of the tasks in Figure 10.3 between
humans and IT systems and
• Management of those IKM tasks that are allocated to
humans inside and outside the organization.
Typically, the second management activity requires the
most effort but the allocation is not trivial either: both
humans and machines have their strong points and weak
points when it comes to handling knowledge, and it
depends on the specifics whether a certain task is best
performed by humans, by IT systems or by a combination
of both.
10.5 Allocation of IKM tasks to humans and
computers
Key considerations in the allocation of IKM tasks are: the
capabilities of humans and computers, the costs involved
and the risks involved in allocating tasks to humans or to
computers. In the first place, it is important to note that
as long as knowledge is implicit (tacit), computers cannot
handle it. Secondly, when it comes to tasks already
concerning operations on explicit knowledge, so-called
MABA-MABA lists (men are better at … - machines are better
at …) can be used to evaluate the capabilities of humans
and computers. There are many of these lists in literature
and on the web; the most famous one is the first MABA-
MABA list presented by Fitts in 1951, better known as the
Fitts list. Table 10.1 shows a selection of IKM-relevant
items from the original Fitts list. Together with the
distinction between explicit, implicit, formal and informal
knowledge, these lists can provide a first impression of
task allocation options. The development of the bread-
baking machine discussed in subchapter 10.3 is a good
example of a successful subdivision of tasks over humans
and machines, where humans had to uncover the implicit
knowledge to create explicit knowledge that could
eventually be formalized and embedded in a machine as a
repetitive routine task.
Beside the strong and weak points of humans and
computers, often a more important factor is the
availability of an applicable solution for a given IKM task:
the computer may be the best performer for the task, but
if no IKM software tool is readily available for this task, a
custom-built application is needed. In many cases, that
may be a too expensive solution. From subchapter 10.5.2
an overview will be given of computer applications for
IKM tasks in product development, and to what extent
solutions are readily available.
One of the most common motivations for allocating IKM
tasks to computers, especially when it comes to storage,
is the risk that knowledge in people’s minds becomes
unavailable as soon as the people in question are
unavailable: they can go on holiday, become sick, retire
or move over to the competitor.
A typical problem in product developing companies is how
to manage design history. An illustrative example of
problems related to design history management is
131
Table 10.1. MABA-MABA: some IKM-relevant items
from the original Fitts list
Humans appear to surpass present-day machines with respect
to the following:
Ability to improvise and use flexible procedures.
Ability to recall relevant facts from large amounts of
knowledge stored over a long time at the appropriate time.
Ability to reason inductively.
Ability to exercise judgement.
Present-day machines appear to surpass humans with respect
to the following:
Ability to perform repetitive, routine tasks.
Ability to reason deductively, including computational
ability.
Ability to handle highly complex operations, i.e. to do
many different things at once.
described by Sainter and his fellow researchers. A design
team at an automotive company was asked to reduce
costs on one of the company’s models. The designers
found out that the rear windows had been designed to
withstand speeds of 150 km/h, apparently for no reason,
since most cars cannot reverse at that speed. They
concluded that this was a perfect item to save costs and
decided to reduce the speed requirements for the rear
window to around 50 km/h. The design of the window
was changed accordingly. Shortly after production and
distribution of the new car model had started, however,
complaints came in about damaged rear windows. It then
turned out that the cars were distributed on transport
trains where they were often loaded back to front, thus
exposing the rear window to the air pressure generated
by the train speed, which was 150 km/h. Over the years,
the reason for the speed requirement was lost, and the
indirect effect of this loss of knowledge resulted in
financial consequences for the company: already
produced cars were returned to the company and had to
be refitted with old-style rear windows, and the
production process of the rear-window assembly had to
be reverted to its original setup.
Storing knowledge in computers can be done in various
ways and at various levels of explicitness, ranging from
text documents in natural language to highly formalized
logical structures. Whatever way it is done, information
and knowledge stored in a computer needs to be
retrieved from that computer as well. Several ways to
accomplish this are discussed in more detail from
subchapter 10.5.2 onwards.
Storing and handling knowledge with computers also has
its risks: application software, operating systems, etc.,
can become obsolete and it can become difficult to
retrieve it after a long period in time because the systems
on which it was created are no longer available. Yet, in
many cases, once information and knowledge is stored on
computers, companies become motivated to expand the
range of IKM tasks that are computer-supported.
Extensive coverage of how far a company can go or
should go falls outside the scope of this course. At any
rate, companies will always end up with certain IKM
activities that need to be done but cannot be performed
with computers. The next subchapter briefly discusses
what companies can do in this area.
10.5.1 Managing knowledge by managing
people
Although this course focuses on computer-supported
forms of knowledge management, it is important to
realize that IKM is not a branch of computer science.
When computers are not used or cannot be used in IKM,
there are many things that a product-realizing company
can do to deal with information and knowledge-related
issues more efficiently and successfully, and it is useful to
have some notion of other ways of managing knowledge.
The main IKM activities that involve people and that can
serve as a starting point for IKM projects in a company
are (1) generating or synthesizing new knowledge, (2)
capturing existing knowledge from external and internal
sources (3) storing knowledge, (4) distributing knowledge
internally, (5) using knowledge and (6) exploiting or
selling knowledge. Revisiting Figure 10.3 it becomes clear
that, in this context, some tasks are skipped. These are
the tasks that are specifically computer related: the main
reason for their absence here is obviously that humans
can handle and store implicit knowledge.
Concrete activities that can optimize the knowledge flows
in a product-realizing company from a human-centred
approach are:
1) Improve and increase synthesis of new knowledge by
stimulating research and development activities.
Provide incentives to people who come up with novel
ideas. Recruit people with invention skills. Promote
creativity techniques.
2) Stimulate capturing existing external knowledge by
sending people to courses to brush up their
professional knowledge. Subsidize subscriptions to
professional journals for staff members. Establish an
in-house library with access for all employees and
recruit a dedicated librarian. Invite people from
potential suppliers and other relevant companies or
organizations to give presentations about new
developments in their lines of work for the product
development staff. Appoint experienced workers as
tutors or mentors to assist less experienced workers.
3) If there is a lot of implicit knowledge in the minds of
people, make sure that there are more people
available with the same knowledge; take care that
they do not take a holiday at the same time.
Implement measures that reduce the risk of people
with crucial implicit knowledge moving over
competitors, or more general: nourish ‘human capital’
and make it attractive for people to stay with the
company. Create an atmosphere, both socially and
physically, in which people stay healthy.
4) Organize in-house colloquia where staff members
distribute their knowledge from finished projects
among the others. Initiate job-rotation projects
where people can gain experience in different fields
and different environments.
5) Use knowledge effectively by matching jobs to
people’s capacities. Improve the knowledge that
managers have of people’s capacities.
132
6) Convert company knowledge to profit by encouraging
patent applications and licensing knowledge to other
companies. Propagate an image of being a
knowledgeable company to attract more assignments
and customers.
This list of possible initiatives is far from complete. For a
more complete overview, we refer to the many books on
the human and organizational aspects of IKM that are
available. For those who are further interested in macro-
scale knowledge management, the book by Nonaka and
Takeuchi can be recommended; there is also plenty of
general knowledge-management content on the web1.
10.5.2 Computer supported knowledge
management in product design: an
overview of micro-scale applications
In this subchapter we will take a closer look at some of
the typical techniques and technologies behind computer-
supported IKM. We will do this based on the knowledge
flows that were identified in Figure 10.3 because IKM
tools based on particular technology typically focus on
particular steps in the overview of knowledge flows.
Figure 10.4 outlines the key areas of computer support.
To put the micro-level IKM techniques and technologies in
a practical context, we will discuss them starting from the
application side (‘bottom-up’):
• Perhaps the ultimate form of utilizing knowledge is to
build it into a product, so that the end user can
directly benefit from it. Of course, knowledge can
also be prepared for use in the design process, and
this is what is typically offered by knowledge-based
engineering applications. Systems for knowledge-
based engineering form a subcategory of ‘knowledge-
based systems’, a general concept that is introduced
in subchapter 10.6, which aims to extract knowledge
that is needed for specific usage from a formalized
source. Most knowledge embedding in products is
based on similar foundations.
• Typical technologies for distribution of knowledge are
computer supported collaborative work and
groupware. These are briefly discussed in 10.10, but
are explained in more detail in Chapter 2. To
distribute knowledge, knowledge portals and search
engines can also be used. These technologies are
more commonly used to collect knowledge, one of
the next activities in this listing.
• For the storage of knowledge, knowledge-based
systems rely on knowledge bases. In other systems
that support knowledge management, knowledge and
data is also archived in so-called knowledge
warehouses and data warehouses, which are
discussed in 10.7.
1
skyrme.com/resource/kmbasics.htm,
gurteen.com/gurteen/gurteen.nsf, brint.com/km, sveiby.com,
tinyurl.com/ya7qqz,
news.cbel.com/knowledge_management/?order=pop,
dmoz.org/Reference/Knowledge_Management,
cio.com/research/knowledge, tinyurl.com/6vpjw,
www.kmmagazine.com, knowledgemanagement.ittoolbox.com
 engine and the knowledge portal. Although our
readers are most probably familiar with search
external externally engines, we will briefly discuss them within the
sources prepared sources context of IKM. Search engines can be deployed at
both ends of the knowledge flows: to search data
internal
sources internally from ‘unprepared’ external or internal sources such
prepared as a company intranet or the Web, as well as for
sources
searching in data or knowledge warehouses.
Knowledge portals can also be found at both ends of
acquiring/ acquiring/ the knowledge flows: at the entry side, designers can
collecting/ collecting/ capturing/ consult external knowledge portals, and at the exit
gathering/ gathering absorbing side, they can consult internal knowledge portals that
eliciting /eliciting assist in finding knowledge in, for instance, a data
warehouse, or in finding internal experts in a given
field. Search engines and knowledge portals are
discussed in subchapter 10.9.
search knowledge • The activity of exploiting or selling knowledge outside
engines portals the company is not commonly supported by
computers, except where knowledge is embedded
into products that are sold – see subchapter 10.6.
processing/clustering/structuring
The problem here is, that in order to be recognized
and processed by computers, knowledge must be
available in some kind of formalized language, and in
order to make exchange possible beyond company
articulating/ knowledge acquisition /
knowledge discovery &
boundaries, this formalized language has to be
representing/
formalizing data mining understood externally. Apart from specific areas,
there is no standard format for formalized
knowledge; furthermore, most companies prefer to
data & knowledge
warehousing; knowledge make profit from the effort they have put in
storing/
bases formalization instead of making the formalized
archiving/ knowledge freely available, for instance, on the Web.
warehousing
knowledge based Going through the techniques from the application of
systems / knowledge
extracting based engineering knowledge to the sources of its ‘rough materials’, we will
see that the design-specific content of the techniques
distributing/ computer supported declines. At the application end, micro-scale IKM in design
diffusing/ collaborative work & and engineering focuses on specific issues such as
groupware; knowledge
sharing portals & search engines material selection, parameterized design, problem solving
and diagnosis, etc. Here, formalization plays an important
role in making knowledge more accessible. If we come
exploiting
closer to the sources of the knowledge, we will see that
embedding using/utilizing computer support is more general in nature, and based
/selling
on ubiquitous technologies such as search engines and
databases. Yet, we will attempt to point out the design-
products company
specific relevance where this is possible.
staff

10.6 Computer support for knowledge

customers
Figure 10.4. Computer support in the context of
knowledge flows (white text)
• Creating explicit and/or formal knowledge through
automated processing of unprepared data and
information as well as data relating to implicit
knowledge (for instance the transcript of an interview
with a person possessing valuable skills) is usually
referred to as knowledge discovery and data mining.
An introduction to this area is given in subchapter
10.8.
• Collecting prepared data, information and knowledge
from internal and external sources can be done in
several ways. Two of the most essential forms of
computer support in this process are the search
extraction and utilization
We can distinguish two forms of knowledge utilization:
utilization by the designer in the design process and
utilization by the end user, mostly during the use process.
Computer support of knowledge utilization by the user
typically comes in the form of embedded software, where
the product is equipped with its own ‘computer’, usually a
microchip. This topic is more specifically addressed in the
course ID 4130, ‘Smart systems and technologies’.
Knowledge-utilization support in the design process
typically comes in the form of knowledge-based
engineering (KBE) systems, a specific type of knowledge-
based systems (KBSs). KBS technology has mainly
developed from a branch of artificial intelligence (AI)
called rule-based systems. In rule-based systems, the

133
knowledge of interest is compiled by human experts into
a system of logical rules and equations and stored in a
knowledge base.
The rules are a formal representation of the knowledge
concerning the given area or domain. The representation
typically uses symbolic (i.e., non-numeric) terms defined
in a language based on a predefined syntax with
semantics to express meaning. In most current KBSs, the
domain expertise is captured in the form of so-called
production rules, relationships and facts. They are
generally formulated as
IF (condition) THEN (draw conclusion or take
action)
For instance,
IF material(part_A OR part_B) = thermoplastic
AND no_extra_part_allowed = TRUE
THEN connection_type = snap_fit
is a production rule for the selection of a connection. A
more complex version could prompt the user to choose
between alternatives that do not require a separate
fastener, e.g., snap fit or ultrasonic welding. Additional
rules could guide the user through the process of
dimensioning a snap finger based on parameters such as
the insertion force allowed and the insertion distance.
Further possible add-ons are the automatic creation of
geometry that can be imported into a CAD application, or
even complete integration into a CAD system.
In the knowledge base, production rules are usually
formulated in a more concise way than the above IF-
THEN statement, but typically still in an English-like
‘language’. To cover more complex relationships,
sometimes object-oriented representations called ‘frames’,
‘graphs’ and ‘networks’ are used. For the end user of the
system, the difference is not clearly noticeable. Two other
alternatives for traditional production rules that do make a
difference to the end user are KBs based on the AI
concepts of fuzzy logic (or fuzzy sets) and those based on
neural networks. The typical characteristic of fuzzy KBs, is
that they are able to deal with vague descriptions, while
neural networks, enable a KB to become self-learning: the
system can be trained by feeding it with examples of
input and the desired output, instead of feeding it with
formal rules. This is useful in case it is known that a
relationship exists, but it is not possible to express it in a
formula or a logical statement. Currently, however, most
of the work involved in preparing a knowledge based is
still done by human experts or knowledge authors. and
KBs that create part of their knowledge output
automatically based on fuzzy logic and neural networks
are not widespread in design and engineering. For the
theory behind fuzzy logic and neural networks we refer to
the course ‘smart systems and technologies’ (ID4130)
once again.
The knowledge in the KB itself is usually created and
processed via the workflow shown in Figure 10.3. The
extraction of the information from the knowledge base is
carried out by a part of the system known as inference
engine, which is generally separate from the KB itself.
Inference normally involves searching the knowledge base
for the appropriate rules that apply in order to reach a
134
given objective, e.g., to optimize the parameters of a
design. In most cases, the KBE system will be rule-based
and it has to deal with multiple rules that all apply to the
problem at hand. The most important task of the
inference engine is to identify these rules and to put them
in the right order for processing, or to combine them into
more complex (e.g. nested) rules.
It is probably true to say that outside of the field of
engineering, KBSs are mostly used by large companies
because these systems are custom-built and therefore
expensive. Typical applications are routine commercial
operations – such as order processing, and diagnostic
systems – such as problem solving in a car workshop.
Another widespread application of KBSs in troubleshooting
can be found on the websites that many companies have
opened for customer support, for instance Apple and
Microsoft1.
Engineering is a field where people are used to
formulating problems in terms of equations and logic;
therefore it is not surprising that – when it comes to
application in smaller companies – knowledge-based
engineering (KBE) is ahead of most KBS application areas.
A KBE system represents product knowledge and the skills
of an individual (the knowledge author) within an
engineering domain; it incorporates them and makes
them available within a computerised application. As a
sub-domain of KBSs dedicated to engineering and design
applications, KBE has grown out of CAD/CAE technology.
We distinguish custom-built KBE systems in the tradition
of KBSs (10.6.1), KBE systems in close connection to CAD
(10.6.2) and stand-alone KBE systems that do not
intensively interface with CAD systems. In the latter
category we will discuss KBE tools for problem solving and
idea finding (10.6.3), and knowledge-based ‘design-for-X’
(10.6.4).
10.6.1 Application of company-specific
customized KBEs
Customized KBE systems specifically tailored for a specific
context in a specific company. These systems are not very
widespread but they have a long history of successes
particularly in the aerospace and automotive industries.
The introduction of customized KBE is considered to have
resulted in substantial reductions in development times.
The systems do not necessarily have a high level of
technological sophistication. Typically, a product model is
held in a rule-based format such that properties of a
product can be linked together with constraints. Design
rules are stored in a knowledge base from which they are
retrieved by an inference engine. Current KBE systems
are problem solvers based on declarative models with no
concept of a design process. They have not been devised
for capturing the designer’s reasoning and are often built
in an ad hoc fashion, which makes maintenance of the
system difficult.
Many KBE systems focus on geometric knowledge, i.e.,
linking the dimensional relationships of a product. Outputs
include complete detail design drawings, costs, bills of
1
search.info.apple.com/, support.microsoft.com
material and manufacturing process information.
Typically, they rely on some kind of macro language that
is already included in conventional CAD/CAE software, but
not intended for the average CAD user. Knowledge-based
engineering is especially beneficial for companies with one
or more of the following characteristics (which also apply
to the systems discussed in the introduction of 10.6):
• Products are based on design-to-order or
engineering-to-order: each product is slightly
different from the other; the differences depend on
the assignment from the customer;
• The design of the products includes repetitive design
tasks;
• The products can be defined by a set of rules and
equations.
An example1 is the KBE application for headlamp design
implemented at Jaguar Cars, where repetitive design
tasks were captured into rules and equations. A car
designer who makes a style rendering initially determines
the form of the headlamps. Before KBE implementation,
this rendering was entered into a CAD system and the
CAD file was sent to the headlamp supplier who usually
came up with modifications. These modifications on their
turn would lead to modifications that the designer had to
apply to the bonnet and the wing of the car body, which
again made it necessary to reconsider the headlamp
design, and so on. This tedious trial-and-error process
could take up to three months. As early as 1989, the car
company and the supplier decided to work on a KBE
system that incorporates all the headlamp knowledge
concerning practical design and legislation, and which
enables the designer to play with various styling options
in the certainty that the design of the front of the car
body and the headlamps will be compatible. What once
took months to accomplish now takes minutes. For
further reading on the principles behind Knowledge-based
engineering, Mike Lewis’ course documents at Coventry
University can be recommended1, as well as McMahon
and Browne’s book.
10.6.2 Application of user-customizable KBE
in combination with CAD
Software that more explicitly profiles itself as KBE
software is typically integrated with CAD systems. These
off-the-shelf solutions are typically based on the same
macro languages as the customized KBE applications, but
they provide a more easily accessible user interface to
everyday CAD users, making it possible to define rules
and equations by using a graphical interface. Key players
in the KBE world are Genworks, Solid Works in
combination with DriveWorks or RuleStream, and CATIA
(Product Knowledge Template)2.
1
www.kbe.coventry.ac.uk/MLewis/342%20des/342des.htm
2
genworks.com, www.driveworks.co.uk,
rulestream.com, tinyurl.com/yxzljt
135
10.6.3 Knowledge-based support for problem
solving and idea-finding
IKM-tools for problem-solving are often based on TRIZ.
TRIZ (pronounced TREEZ) is the Russian acronym for the
Theory of Inventive Problem Solving. It is an algorithmic
approach to solving technical problems. It began in 1946
when the Russian engineer and scientist Genrich
Altshuller (1926–1998) discovered that the evolution of a
technical system is not a random process, but is governed
by certain objective laws. These laws can be used to
consciously develop a system along its path of technical
evolution, by determining and implementing innovations3.
Looking for inventive problems and how they were solved,
Altshuller screened over 200,000 patents. Of these, only
20% had somewhat inventive solutions; the rest were
straightforward improvements. Altshuller defined an
inventive problem as one in which the solution causes
another problem to appear, such as increasing the
strength of a metal plate causing its weight to get
heavier. Usually, inventors must resort to a trade-off and
compromise between the features and thus do not
achieve an ideal solution. In his study of patents, he
found that many described a solution that eliminated or
resolved the contradiction and required no trade-off. In
the 1960s and 1970s, Altshuller categorized the solutions
into five levels, ranging from routine design problems
and. minor improvements to existing systems, to rare
scientific discoveries and pioneering invention of
essentially new systems. He noted that with each
succeeding level, the source of the solution required
broader knowledge and more solutions to consider before
an ideal one could be found. Based on these findings,
Altshuller re-categorized the patents. Instead of
classifying them by industry, such as automotive,
aerospace, etc., he removed the subject matter to
uncover the problem solving process. He found that often
the same problems had been solved over and over again
Figure 10.5 The Innovation Workbench suggests
solutions for the containment ring
problem.
using one of only 40 fundamental inventive principles. If
only later inventors had knowledge of the work of earlier
ones, solutions could have been discovered more quickly
and efficiently. These 40 principles have been described in
3
www.aitriz.org/triz.htm
Table 10.2 Two out of 40 TRIZ principles

Principle 1. Segmentation
Divide an object into independent parts: replace
mainframe computer by personal computers; replace a
large truck by a truck and trailer; use a work
breakdown structure for a large project;

Make an object easy to disassemble: Modular furniture;

quick-disconnect joints in plumbing;

Increase the degree of fragmentation or segmentation:

Replace solid shades with Venetian blinds;

Principle 2. Taking out

Separate an interfering part or property from an object,
or single out the only necessary part (or property) of an
object: Locate a noisy compressor outside the building
where compressed air is used; use the sound of a Figure 10.6 Design for assembly: knowledge-based
barking dog, without the dog, as a burglar alarm. software from Boothroyd Dewhurst, Inc.

several publications and on several websites1. Table

10.2 gives two principles with examples. Figure 10.5
shows a screenshot of Innovation WorkBench in action2.
Most of the TRIZ software packages are aimed at large
companies and they are relatively expensive. However
TRIZ40 offers a web-based TRIZ toolkit that can be used
at no cost3.
10.6.4 Knowledge-based design-for-X
Another area of application is that of design reviews in
various stages of the design, to assess cost and
manufacturability. Commonly used methods in this area
are design for manufacturing and assembly (DFMA) and
design-to-target-cost (DTC), but also other forms of
design analysis, such as quality function deployment
(QFD) and failure modes and effects analysis (FMEA).
Notably, not all of these applications for design support
advertise themselves as ‘KBE tools’. Typical examples of
commercial software in this area are Boothroyd &
Dewhurst’s DFMA (Figure 10.6), Seer DFM and TeamSet’s
software for DFMA, DTC, QFD and FMEA. Examples from
product design, with the obtained improvements, can be
found on the respective websites4. Also, on the web,
various KBE oriented online tools can be found which
offer support for ‘quick-and-dirty’ estimates for
engineering problems, for instance cost calculation for
injection moulding5 or strain calculation for snap-fits6.
However, the ‘knowledge’ content of the latter tool is
questionable, since it is based on equations only.
10.7 Computer support of knowledge storage
The most basic solution for storage of data and
information in large quantities is the database. In a
product development environment, typical database-
oriented systems are engineering data management
(EDM) and product data management (PDM) systems.
Database technology, as well as its application in EDM
and PDM, is discussed in more detail in the bachelor
course ID2601, ‘Software in design’. At low level,
databases store data and information as ASCII characters
representing numbers and/or textual information. When
these numbers and text have a meaning that can be
interpreted by other system components, like the rules
discussed in subchapter 10.6, they can be considered
knowledge. Thus, a knowledge base as explained in
subchapter 10.6 can also be implemented as a database,
as is indeed the case for most knowledge bases. We have
to keep in mind that this is also true for other ‘advanced’
forms of knowledge storage that we will discuss in this
subchapter, namely knowledge warehouses, product life-
cycle management (PLM) systems – which are in fact
extended PDM systems – or systems for storing design
rationale.
Strictly spoken, the knowledge bases discussed in the
previous subchapter should also have been discussed
here as means of knowledge storage. But because of the
way KBs are specifically adapted to their concrete
application, we chose to discuss all the elements of
knowledge-based systems in one subchapter.

10.7.1 Data warehousing and knowledge

1
tinyurl.com/yjv5wx,
warehousing
www.triz-journal.com/archives/1997/07/b/ Data warehouses originate from a line of work called
2
ideationtriz.com/paper_IWB_comparative_case_study.htm business analysis, where historical business data is
3
analyzed in order to make forecasts, to underpin
triz40.com
management decisions or to support quality assurance7.
4
dfma.com, galorath.com, teamset.com
7
5
akf-agf.nl/offer2.html, Dutch only; For Dutch students: please note that the English word
kazmer.uml.edu/Software/JavaCost/index.htm warehouse does not correspond to the Dutch warenhuis
(department store). Instead, it corresponds to magazijn, pakhuis
6
rpi.edu/dept/mane/deptweb/student/snapfit/index2.htm or opslagloods

136
Most of the data that business analysts need to do their
job is generated and managed by a multitude of software
applications, such as ERP systems, spreadsheets, order-
processing systems and manufacturing planning systems.
The difficulty in dealing with so many sources is what
inspired the advancement of data warehousing. The
following description is from Dymond:
‘A data warehouse gathers data from multiple sources and
organizes it in a logical and accessible structure. One of
the motivations for using a data warehouse is efficiency.
The original data may be located in different computers,
databases, and formats. Every time a study is done, it is
necessary to gather and prepare data from these many
sources. If the same preparation work is being done
repeatedly, then it makes sense to try to find a way to do
most of the preparation phase once and then reuse it.’
The various business systems from which the warehouse
retrieves its data mostly deal with dynamic data–for
instance, manufacturing data is continuously updated.
However, the warehouse typically requires static or non-
volatile data, i.e., data that refers to completed affairs, so
that it has potential historical relevance. The business
analyst is more interested in the fact that the total
development time of a new product took 6 months than in
the fact that a design review on the 5th of March gave
reason to select a different material for the product
housing. Other characteristics of a data warehouse are
that it is structured, it can be extended, it is updated and
maintained for a long period in time, and that it is capable
of delivering dedicated summaries of detail data according
to the most common queries from the analysts1. It is
exactly these characteristics that distinguish a data
warehouse, as a special type of database, from a regular
database.
Figure 10.7 illustrates the structure of a typical data
warehouse. It is organized by topic and it consists of
tables. The central table is called fact table. It holds
columns with detail data, with the columns representing
Figure 10.7 Structure of a data warehouse (from
Dymond)
the variables that are used repeatedly to answer common
questions about a particular topic (characterization by
1 3
system-services.com/dwintro.asp
137
Dymond2). Some of the columns in the fact table are
joined with matching columns in so-called dimension
tables dedicated to specific queries.
The direct relevance of data warehouses for product
designers is fairly limited, in particular because of their
static nature. They may, however, have some practical
advantage in the following circumstances:
• Situations where designers work with (historical)
market or customer data, especially when data about
or from the customer has direct influence on the
product design. Potentially, data warehouses can be
used to store anthropometric data, or results from
customer surveys;
• Situations where designers work closely together with
other disciplines in the company, such as marketing,
sales, maintenance and manufacturing.
Indirectly, designers are also confronted with data
warehouses because they play an important role as a
subsystem in some of the IKM technologies discussed in
the following subchapters.
In data warehouses computers store data, just as the
name says. The warehouses can be used as a source for
knowledge but computers do not store (formal)
knowledge in them directly. This is what knowledge
warehouses are for; however, the distinction between a
knowledge warehouse and a regular knowledge base is
not as clear as that between a data warehouse and a
regular database. The only distinction is a rather
subjective one: knowledge warehouses are supposed to
store more knowledge than knowledge bases. One of the
reasons for the lack of distinction is that, unlike regular
databases, regular knowledge bases are already static in
nature because its rules have to be prepared by experts.
A special type of knowledge warehouse, currently in its
infancy, is the distributed knowledge warehouse in which
knowledge belonging to multiple companies is connected,
so that it can be accessed as one knowledge warehouse.
This type of knowledge warehouse is expected to play a
role in collaborative engineering environments (see
chapter 2) in the near future.
There are several sources on the web that can provide
further information on data warehousing and related
technologies3.
10.7.2 Knowledge-oriented product lifecycle
management
Product lifecycle management (PLM) is an overarching
strategy of guiding the product throughout its entire
lifecycle. PLM includes PDM as one of its many
subsystems since a key feature nonetheless remains the
ability to generate bills of materials (BOMs) and automate
their changes to keep them perpetually up to date.
However, it also entails more, allowing collaboration
amongst many constituents and successful planning and
execution of product development and introduction
programs. A much broader – but not yet realized –
2
www2.sas.com/proceedings/sugi27/p144-27.pdf
e.g., dwinfocenter.org, kenorrinst.com/dwpaper.html
mission of PLM would be to provide a panoramic overview
of data and business processes associated with the
product from creation to disposal to any involved party,
such as design engineers, manufacturing engineers,
production planners, purchasing, marketing, and
suppliers. This still evolving category of software should
help any manufacturing company deliver a product and
continually enhance it by helping it manage and automate
materials sourcing, design & visualization, engineering
change orders and product documentation, such as test
results, product packaging, and post-sales data. It should
also help companies manage through a growing number
of local, regional, national and international regulations1.
PLM systems operate from a product life-cycle centred
perspective, covering conceptualization, design,
procurement, production, delivery, service, retire etc.
These phases naturally include multiple people, operating
in multiple departments, and typically from multiple
companies, each with locations in multiple countries
around the world. Solving these inherent difficulties that
result from managing this complexity stimulated the
development of PLM solutions. Most PLM vendors focus
on specific industries with a particular supply chain, and
their solutions have been developed to solve the specific
needs of those industries (e.g., automotive suppliers
caring mostly about effectively managing the complex
supply chain, or fast-moving consumables companies
concentrating on maintaining and extending the value and
variety of merchandise brands). Because of this
specialization, different PLM systems can have completely
different functionalities and there is no single vendor yet
that can meet all of the varying needs.
PLM systems typically manage several layers of
information, offering related applications for each layer,
for instance, a layer of information and applications for
executives, a layer for resource management and
budgets, a layer for overseeing projects, and a layer for
tracking all product-related business processes.
Applications include product portfolio management,
project management, resource management, strategic
selection of suppliers, design collaboration, visualization,
and others in addition to traditional engineering
applications like PDM and CAD.
The PLM market is still in its infancy, emerging from the
traditional PDM market, primarily due to expanded
collaboration features and on the availability of web-based
technology. There are several dozen vendors that are
offering suites of PLM functionality coming from different
worlds, based on their origins. A great part of these
logically hail from the engineering space and have since
added to their design-focused PDM and/or CAD
applications to support additional manufacturing and
operations-oriented business processes. Some companies
offering PLM solutions are EDS/UGS PLM Solutions,
Centric/Framework Technologies, MatrixOne/Cadence,
Dassault Systèmes and PTC2.
1 catalog rather than designing them from scratch.
http://tinyurl.com/uuu9l (Jakovljevic, Predrag & Brown)
2
ugs.com, centricsoftware.com, matrixone.com, 3ds.com,
ptc.com/products/plm.htm (must select country before
proceeding to URL)
138
10.7.3 Tools for archiving design rationale
Design rationale is an explanation of why a product, or
some part of a product, has been designed the way it is.
As such, it is part of the design history of a product. In
various situations it is beneficial for a company to have
access to design rationale, in particular when the work
done by one or more designers is passed on to others or
if others have to base their work on what designers have
prepared. In practice, this situation can occur when
people are temporarily on leave, when design work is
forwarded to a different discipline such as production
preparation, or when a product is being redesigned. The
case of the car rear window in subchapter 10.5 is a good
example of what can go wrong when design rationale
cannot be backtracked. The obvious place to look for
design rationale is in the minds of the original designers,
but they are not always available or they may have
forgotten why particular design decisions have been made
in the past.
As was already suggested in subchapter 10.5, a possible
solution is to archive the design rationale by using
computer support. Based on the work of Regli and others,
three approaches accomplishing this can be distinguished
• The process-oriented approach: the designer actively
enters the design rationale into a structure that is
given by the system. The structure offers
standardized means to express where in the design
history a decision was taken, if alternatives were
considered, if and why a particular solution was
chosen or rejected, etc. Reasons behind decisions are
typically entered by the designers in natural language
and/or explanatory sketches.
• The feature-oriented approach: The system actively
offers the designer available solutions for the typical
sub-problems that need to be solved for typical
design processes in the design domain at hand. This
is only possible in domains where design processes,
as well as the components and features in the
products, are highly standardized, e.g., printed-circuit
board design or chemical plant engineering. The set
of problems is limited and built into the system; for
every problem there is a limited set of typical
solutions, from which the original problem, thus the
reasoning behind the design, can be backtracked.
These systems are typically rule-based and, clearly,
hardly applicable in industrial design engineering.
• The integrated approach: the designer uses a
dedicated CAD system, and the design-rationale
system automatically derives the designer’s reasoning
from his actions, without requiring active entry of the
reasoning. At the current state of technology, this
approach, again, is typically feasible for the design of
products from highly-standardized components,
where the choice of each component can be
backtracked to the reason why it was chosen.
Typically, the designer selects components from a
Obviously, from what is currently available, the process-
oriented approach is the only one that is realistic in
industrial design engineering. Although there are no
 Figure 10.8 Example of a rationale structure created with DRed (Bracewell and others)
(legend at bottom left)

commercial software solutions yet, successes have been
reported with software developed in academia that was
applied in product developing companies. As an example,
Figure 10.8 shows a fragment of a so-called ‘rationale
structure’ that designers can create using a tool called
DRed (Design Rationale editor). DRed is being developed
by Rob Bracewell and others at the Cambridge
Engineering Design Center and it has been successfully
applied in several companies. Typical issues that can be
entered are which solutions came up for problems the
designers have been facing, which solutions were chosen
and which ones were rejected, and – most importantly –
why they were chosen or rejected.
Clearly, before rationale knowledge can be stored in such
structures, it needs to be entered (knowledge acquisition
or knowledge capture), and if the knowledge is used at a
later stage it has to be extracted from storage. Yet, tools
supporting preservation of design rationale are discussed
here, because storage is the critical element in retaining
the knowledge for the future.
10.8 Computer support for (re)organizing
knowledge: knowledge discovery and
data mining
Knowledge discovery and data mining are two names for
the same discipline comprising a portfolio of techniques,
usually abbreviated KDD. The objective is to create
knowledge from data. In a similar context the term
‘knowledge mining’ is also used; it gives a more adequate
description of what is actually happening – compare, for
instance ‘gold mining’, where the goal is to find gold. KDD
software is often marketed under confusingly broad
denominations such as ‘knowledge management
solutions’. Known suppliers of KDD software, mostly in
combination with data warehousing, are companies like
Hummingbird, Verity, Convera and Autonomy, but also
IBM.
Usually KDD technologies are not specifically implemented
for product design. However, a substantial amount of
knowledge that designers work with, for instance
knowledge from the sources discussed in subchapter 3.2,
originates from data-mining and knowledge-discovery
activities. It can therefore be beneficial to designers to
have a common understanding of what these techniques
bring about. In the following subchapters KDD will be
briefly introduced in more detail; there are several
sources on the web that can provide further background
information1.
10.8.1 From data to knowledge: processing
steps and technologies for KDD
In accordance with Figure 10.4, typical tasks for KDD are
data acquisition, clustering (segmentation), structuring
(classification), and representation. Representation, or
making knowledge formal, is usually subdivided into three
application fields for formal knowledge: generalization,
detection and prediction.
Data acquisition
Data acquisition involves the collection of unprepared,
‘rough’ data from a given collection of sources. These
sources can be on paper or on any other type of analogue
or digital information carrier. Data that is not available in
1
e.g., aaai.org/AITopics/html/mining.html, twocrows.com

139
a digital form will have to be processed manually and/or
(semi)automatically in order to be used as input for KDD.
Automatic and semi-automatic methods of digitizing data
involve combinations of technologies such as 2D and 3D
scanning, optical character recognition and feature
recognition. Digital data occurs in many forms, including
documents created with office software, CAD files, HTML
pages, sound files, movie clips, etc. If the data is pure
text, the acquisition and subsequent KDD activities are
usually referred to as text mining.
Once data is available digitally one could say that it has
been acquired. If the data is in a local, closed, or
practically finite system, such as a library archive, a PDM
system or some other document management system,
indeed, no further preparation may be needed for KDD.
However, if the data is in a remote, open, or practically
infinite system, such as the World Wide Web, a large
company intranet or a large computer network, a local
extract or index of the complete system is typically
prepared as a principal source for further KDD activities.
This index itself can be stored as a local source in, for
instance, a data warehouse, a database, a PDM system or
an ERP system. For automated collection of data from the
original remote system, typically so-called crawlers,
spiders and bots are used: see subchapter 10.9.1.
Clustering and structuring
Clustering (also called segmentation) is the process of
dividing the source dataset into mutually exclusive groups
such that the members of each group are as ‘close’ as
possible to one another, and different groups are as ‘far’
as possible from one another, where distance is measured
with respect to all available variables1. The structuring
task examines the characteristics of the data elements
(e.g., documents) and places them into categories
according to meaningful partition criteria, models or rules.
This is mostly done by classification. The aim of
classification is to divide a dataset into mutually exclusive
groups such that the members of each group are as
‘close’ as possible to one another, and different groups
are as ‘far’ as possible from one another, where distance
is measured with respect to specific variable(s) relevant to
the knowledge domain that is covered by the eventual
formal knowledge. For example, a typical classification
problem is to divide a database of products into groups
that are as homogeneous as possible with respect to a
variable with possible values ‘successful on the market’
and ‘unsuccessful on the market’. Most of the
classification algorithms are based on symbolic and
statistical methods. To extract categories from the original
dataset, symbolic methods produce rules that contain
variables, e.g.:
IF sales in North America > 100,000 AND sales in
Europe > 50,000
THEN the product is successful on the market;
ELSE it is unsuccessful.
Statistical methods extract statistical discriminators, such
as probability distributions. As an example, statistical
discriminators can be (a) 95% of the products cheaper
1 3
thearling.com/text/dmwhite/dmwhite.htm
140
than € 10.- is successful on the market; (b) 85% of the
products more expensive than € 25.- is unsuccessful; (c)
30% of the products produced in China is unsuccessful on
the market; (d) 95% of the products produced in China
costs less than € 12.-; (e) 75% of the products with a
cardboard packaging is successful. A statistical clustering
method can be applied to produce a hypothesis about the
success of a product produced in China, is packed in
plastic and costs € 15.-. Another statistical method might
produce a hypothesis about the origin of an unsuccessful
product that costs € 4.50 and that is packed in cardboard.
An illustrative visual demonstration of data clustering is
the presentation of websites shown in Figure 10.9 created
with Visual Net2, a clustering tool of which the results can
be accessed through a web interface. The collected data
in the figure are URLs obtained from the Open Directory
project3. The example shows how the user can zoom in
on clusters of URLs (in this case the CAD cluster, a sub-
cluster of the URLs relating to 'computers'). The size of a
cluster corresponds to the total number of URLs collected
in it and the proximity of clusters and URLs shows how
closely they are related. Used this way, Visual net could
be used as a visualized interface to information portals.
However, since 2005 it is only available for business
analysis purposes, working with large amounts of
unstructured data collected in an enterprise context for
business analysts to find patterns and relations in
unstructured data sets.
Knowledge representation
The knowledge-representation subtasks that are usually
addressed as generalization, detection and prediction are
not specifically included in Figure 10.4. The actual
activities addressed with these terms actually boil down to
making knowledge formal by representing it in such a
form that it makes detection and prediction possible
during its use. The objective of the generalization task in
KDD is to extract generally applicable relations or rules
that characterize the source data. Generalization can also
be seen as a form of modelling.
Detection aims at finding anomalies or irregularities that
are considered relevant, mostly in large sets of
observation data. Examples are, for instance, detection of
intrusion in a network, or money-transfer patterns that
indicate fraud.
Predictive KDD is usually applied in complex situations
where massive quantities of input data are available,
representing large sets of variables that are assumed to
have influence on variables to be predicted (which are, in
some cases the same variables as the input variables). In
such situations, traditional predictive models based on
equations are rarely available. In some cases, clustering
methods, as demonstrated in the above hypothetical
example about the market success of products, can be
helpful. In more complex situations, KDD enriched with
machine-learning techniques such as neural networks and
2
antarcti.ca/products/visual_net,
arnoldit.com/articles/visualnet401.html
dmoz.org
Figure 10.9 Demonstration of Visual Net clustering results.
genetic algorithms, can attempt to extract predictions
about the future course of variables. A typical popular
application field is weather and climate forecasting, where
massive amounts of sample data about wind directions,
water temperatures, air temperatures, geometry of the
landscape, etc., can be used to predict the course of the
weather. Similar application fields are ecological
forecasting (development and effects of pollution,
development of wildlife populations, etc.) and geology
(erosion, earthquakes, landslides, etc.). Another
interesting area for prediction can be found in situations
where data is difficult to quantify or to parameterize;
especially where human preferences (taste!) and
psychological or sociological behaviour are concerned.
Successful implementations of data mining in this area
can be found on websites where people can specify their
preferences for books, movies or music; based on
similarities with profiles of other site visitors, the system
can recommend other movies, books or CDs to a user
that he or she did not know yet. A well-known example of
this form of taste prediction is Amazon.com’s website.
Although the potential of this area has hardly been
exploited in an IDE context, it is obvious that this is one
of the most promising areas of advanced design support
that KDD can offer: think of predicting customer
preferences, fashion trends and user behaviour.
10.8.2 Current and future application of KDD
in industrial design engineering
Like the knowledge that is mostly represented by rules in
KBE, the discovered knowledge in KDD is formal and,
likewise, it may also be described based on rules. The
difference between knowledge in KBE/KBS and knowledge
in KDD, is that in KDD data has undergone an automated
treatment through acquisition, clustering, structuring and
representation as knowledge, whereas in KBE/KBS, the
knowledge is typically compiled ‘manually’ by experts or
141
by so-called knowledge authors based on interviews with
experts. As a result, the automated creation of knowledge
in KDD usually does not present a solution to a queried
problem that is typical in the designer’s line of work, as in
KBE, but rather a collection of apparent conclusions from
the available source data based on generalization and
prediction (typically, the detection capabilities of KDD are
not important in the context of IDE). In other words, KDD
starts from available data and comes up with knowledge
that might be relevant for some problem that the designer
may have.
The downside of this approach is that knowledge from
KDD might not be useful at all. However, at best KDD
might come up with ‘off-the-beaten-track’ knowledge that
is not based on predefined problems, and thus stimulate
creativity more than KBE is likely to do. Nevertheless, it
hardly seems surprising that direct, dedicated application
of KDD in IDE is scarce. Therefore it is not surprising that
the area where KDD is providing support for designers
already, is in searching information and knowledge during
the analysis stage of design, based on data from the web,
the intranet, electronic libraries, but also from
‘engineering data warehouses’ that store historical
product and design data for a company. On the web,
many designers already use text mining and other KDD-
generated knowledge without being aware of it: the
search engines and knowledge portals that are already
invaluable sources of information and knowledge to
designers are (partially) based on KDD techniques (see
also subchapters 10.9.1 and 10.9.2). Most of the tools for
content based image retrieval and 3D model database
querying that were discussed in subchapter 3.2 are
strongly rooted in KDD.
Another promising area of KDD support for designers is
text mining. Directly or indirectly, design processes often
produce large quantities of text in the form of design-
review reports, business correspondence, product
advertisements and user manuals. Internally, text mining
could assist, for instance, in re-tracing design rationale,
errors from the past and marketing-based reasons behind
features of former products. On the other hand, designers
do not always have sufficient time to uncover potentially
relevant knowledge from external sources, such as patent
databases, or information about products from
competitors on the web. Text mining solutions have
indeed been developed to mine information from patents,
successfully pointing out groups of similar patents or
potential areas of patent infringement for a given
product1.
10.9 Computer support for knowledge
capture and knowledge elicitation
Knowledge elicitation can be done by consulting internal
and external sources. The two most common computer-
based tools that are used here are the search engine and
the knowledge portal. Both can be used within a company
context to capture knowledge that is available internally
or externally, but also to prepare knowledge to be offered
to external customers or users. The following two
subchapters will provide a brief introduction; there are
several sources on the web that can provide further
background knowledge2.
10.9.1 Search engines
A search engine is a program that searches documents for
specified keywords and returns a list of the documents
where the keywords were found 3. Search engines
actually form a general class of programs, but the term is
often used to specifically describe systems that enable
users to search for documents on the Web and Usenet
newsgroups. The Web is the most familiar application
area for search activities in data acquisition, because it
offers the convenience that documents usually contain
links to each other4, but databases and data warehouses
can also serve as a source for search engines.
One of the most basic tasks of a search engine is data
acquisition by sending out a program called crawler (also
called bot or spider) to fetch as many documents as
possible. It starts from a given URL (uniform resource
locator) or another specific address, and then
automatically follows all the links in each document5,6.
Another program, called an indexer, then reads these
documents and creates an index, which is a database in
which the words contained in each document are
recorded. Each search engine uses a proprietary algorithm
to create its indices such that, ideally, only meaningful
results are returned for each query. In fact, using a
1
dama-michigan.org/21%20Kas%20Kasravi%20Presentation.ppt
2
e.g., www.robotstxt.org/wc/faq.html#books,
·brightplanet.com/resources/details/tutorials.html
, trinity.edu/rjensen/portals.htm
3
www.webopedia.com
4 7
www.robotstxt.org/wc/faq.html
5 8
www.research.ibm.com/journal/sj/404/mack.pdf,
6 9
tinyurl.com/4u663 (Weiss)
142
search engine does not imply searching the Web (or other
source) but searching the index. To keep the index up-to-
date, the crawler must be instructed to return to the
indexed sites on a regular basis.
User input into a search engine is usually done through a
query: a specification of terms that the user is looking for,
or wants to exclude, formulated in a query language. A
query language is mostly specific to a search engine,
although many query languages show similarities. The
query language prescribes how the user has to enter
terms that he or she wants to include, to exclude, to
appear in a specific combination, etc. For instance, a
search for pages that contain the phrase ‘design support’
but not the word ‘architecture’ in the query language
supported by Google7 would be
“design support” –architecture
but in the query language supported by Scirus8, a search
engine for scientific publications, it would be
(design support) ANDNOT architecture
Many of query languages and the algorithms that are
used to match input terms to those in the index originate
from vintage computer technology that was already used
in – for instance – library catalogues from the 1960s or
even earlier.
The results returned by a search engine are mostly
considered to be information rather than knowledge.
However, the growing problem of users having to deal
with too many search results has inspired the developers
of search engines to include some ‘intelligence’ in the
form of ranking the search results by relevance based on
knowledge9. The knowledge on how relevant a document
is supposed to be can be based on various contributing
factors, ranging from predictive KDD analysis of the
search-and-find behaviour of other search-engine users,
to data about how many other websites link to the
website in question. Certain search engines, such as
vivisimo.com, use KDD techniques to cluster search
results.
10.9.2 Knowledge portals and wikis
Knowledge portals can be defined as single-point access
software systems intended to provide easy and timely
access to information and to support communities of
knowledge workers who share common goals5. The usual
appearance form of a knowledge portal is a website that
can be accessed through a web browser. Most knowledge
portals are driven by a software application called portal
server, running on a central computer, which is also called
server. A portal server provides all kinds of functionality
that is nowadays common on websites, such as:
• Content management: a knowledge portal, or any
website managed by a portal server, is typically more
google.com
scirus.com
google.com/technology/
 that just a collection of HTML documents that link to
each other. Often part of the content of the website
(text documents, movies, sounds, etc) is stored in
other formats, in databases, data warehouses, KBs,
etc. and is not directly accessible through a web
browser. Browser-compatible temporary HTML pages
are created on-the-fly by the portal server if the user
clicks on a link that refers to specific information.
Such one-time documents can usually be recognized
by the characteristic that their URL does not contain
a regular path name to indicate a file inside a folder,
such as
www.geplastics.com/resins/designsolution/
tools/disclaimers/general.html
but rather a seemingly cryptic combination of codes
and commands, such as
aleph.library.tudelft.nl/F/V985K9RCVU6R5GXNV
RSCFYJ8FGBBM3V9XETABYUJRA5XMIVQHV01537?func=
file&file_name=find-b&local_base=tud01
Obviously, as the above URL indicates, the website of
the DUT library is based on a content management
system that creates on-the-fly web pages. Other
everyday examples of portal-server based sites are
the DUT central website and the local blackboard
education support system1, which can be said to be a
true knowledge portal. In fact, blackboard2 is a good
example of portal-server software.
• Collaboration features: knowledge portals can
accommodate discussion forums, polls, chat rooms
and other interactive features. Unlike the other IKM
support tools discussed in the previous subchapters,
that basically deploy knowledge transfer from a
system to its human users, knowledge portals do also
support knowledge exchange between people.
• Access management: especially when a knowledge
portal appears on a company intranet, it can be
desirable to limit access to internal users, or to
distinguish different areas for, for instance the
company management, the company staff, regular
customers and the general public. As a matter of
course, a portal server can manage who has access
to what information, who is authorized to edit
content and who is admitted to which discussion
forum, etc.
Historically, knowledge portals are the descendants of the
so-called information portals. This first generation of
portals on the Web were devised as an alternative to the
first search engines in the early 1990s. A good example
was (and still is) Yahoo3. Instead of letting the user enter
search terms, the portal offers a pre-defined catalogue of
taxonomically arranged information or knowledge
categories. The most significant correspondence between
an information portal and a knowledge portal is that they
offer a single point of access. Information portals mainly
differ from today’s knowledge portals in that all of the
1 6
tudelft.nl, blackboard.tudelft.nl
2 7
www.blackboard.com
3 8
yahoo.com
143
content finds itself on relatively permanent web pages,
and that human administrators perform the content
management.
On the internet, there is a wide range of knowledge
portals available dedicated to support of designers in
areas such as finding the right equations to solve an
engineering problem4, finding suppliers for parts5, and
finding existing patents6.
Another popular concept closely related to knowledge
portals, information portals and content management
systems is the wiki. A wiki is a type of website that allows
the visitors themselves to easily add, remove, and
otherwise edit and change available content, sometimes
without the need for registration. This ease of interaction
and operation makes a wiki an effective tool for
collaborative authoring7. Perhaps the most well-known
wiki is Wikipedia, ‘the free encyclopedia’. Because not
only administrators but virtually everyone can add, edit
and delete content, a wiki is more dynamic than an
information portal. Unlike many knowledge portals, wiki-
based websites typically do not produce pages on-the-fly.
The term wiki can also refer to the collaborative software
itself (wiki engine) that facilitates the operation of such a
web site. In fact, this software is a particular type of
content-management system. Specific characteristics of a
wiki engine are, for instance that for each article it
provides one-click access to a discussion page particular
to that article and that the most recent additions and
modifications of articles can be monitored.
10.10 Computer support of knowledge
sharing, computer-supported
collaborative work and groupware
Groupware could be defined as ‘computer-based systems
that support groups of people engaged in a common task
or goal and that provide an interface to a shared
environment’. CSCW or ‘computer-supported cooperative
work’ is the study of how people work together using
computer technology. Typical applications include email,
awareness and notification systems, videoconferencing,
chat systems, multi-player games, and real-time-shared
applications (such as collaborative writing or drawing)8.
These tools have already been discussed in Chapter 2.
10.11 Conclusions
There are several interesting benefits that can be attained
from applying information and knowledge management in
a product-design environment: making reuse possible of
knowledge that has been applied before and/or by others,
4
www.martindalecenter.com/Calculators.html,
eml.ou.edu/equation,
engineersedge.com/Design_Data.shtml
5
globalspec.com/MediaKit, www.cad.sun.ac.za/catalogs,
mcmaster.com, grainger.com, thomasnet.com
freepatentsonline.com
en.wikipedia.org/wiki/Wiki
usabilityfirst.com/groupware/cscw.txl
re-tracing decisions that have been made in the past,
reducing the workload needed for routine tasks and
calculations, finding external information and knowledge
easier and faster, discovering relevant patterns in huge
and unstructured collections of data – for instance on
potential users – and receiving guidance while applying
design supporting methods such as DFX, FMEA and TRIZ.
Specific IKM applications for designers are mostly
available in the form of knowledge-based engineering
tools and design-specific knowledge portals. In some
areas, such as support for storing design rationale, the
development of tools for designers has not yet matured
from academic research, while in other areas applications
in design are still waiting to be taken on by researchers
and software vendors. One of the possibly interesting
applications is the application of data mining to uncover
knowledge about ‘softer’ aspects in design, such as taste
and preferences based on social backgrounds.
Apart from IKM support specific for designers, there are
also ubiquitous forms based on IKM technology that are
being used by designers on a daily basis, especially on the
internet. Although search engines have been around for
over a decade, they are still becoming more powerful
thanks to the inclusion of the latest AI and KDD
technologies. This makes them also increasingly
successful in helping to find information and knowledge
for professionals with specific needs, including product
designers.

144