Product Knowledge Management within Knowledge ... - Engineering


6 Νοε 2013 (πριν από 4 χρόνια και 6 μήνες)

161 εμφανίσεις

Proceedings of DETC’00
ASME 2000 Design Engineering Technical Conference
And Computers and Information in Engineering Conference
Baltimore, Maryland, September 10-13, 2000.

1 Copyright © 2000 by ASME



P. Sainter
, K. Oldham
, A. Larkin
, A. Murton
, R. Brimble
Knowledge Engineering & Management Centre
Coventry University, Priory Street, Coventry, CV1 5FB, UK.
Tel: +44 24 76888999 Fax: +44 24 76888604
BAE SYSTEMS Advanced Technology Centres - Sowerby
PO Box 5, Filton, Bristol, BS34 7QW, UK.
Tel: +44 117 936 6205 Fax: +44 117 936 3733

Knowledge-based engineering systems are now becoming more
commonplace in engineering industry. There is a need to ensure
the technology is used correctly and to provide the user with all
the possible benefits that the system can offer.
This paper looks at how product knowledge can be managed
within knowledge-based engineering systems to ensure that the
knowledge retains its value and usefulness during the product
lifecycle. Presently, the use of these systems has been for the
short-term benefit of the company. However, it is believed that it
is important to consider longer-term issues also, since
knowledge normally has a half-life of around 20 years.
The main aim of this paper is to demonstrate the need for
product knowledge management within knowledge-based
engineering systems by looking at key issues that are related to
the longer-term use of these systems. This paper will also
provide a product knowledge management scheme for the
development and management of product knowledge within
knowledge-based engineering systems, thereby extending the
benefits of knowledge-based engineering systems into the

In this age of international markets and increased worldwide
competition, many companies are looking for new ways to gain
and keep competitive advantage. In doing this they will try to
use their intellectual capital to the full [Winch 1999]. Since most
companies have access to the same processes, cost management
systems, and material management systems, the only thing that
separates them is the intellectual capital that each company
holds. One method of using and storing intellectual capital
within the manufacturing industry is to use systems, such as
Knowledge-Based Engineering (KBE) systems.
Currently KBE systems provide benefit during the design phase
of many products. These benefits include the reduction of
product introduction lead-time, the introduction of DFx (Design
for x) techniques into the design process and automatic
consideration of legislation by the system. Reduction in lead-
time encourages engineers to explore additional product
options. However, these benefits are normally achieved by
using the technology for the short term without fully
considering the possible future of the application in the long-
This paper will investigate the key issues that face the use of
KBE systems for the longer term and suggests methods of
managing the product knowledge held within KBE systems
more effectively.
Therefore this paper will discuss KBE systems, Product
Knowledge and Product Knowledge Management.

Engineering has always used knowledge to design and
manufacture products. The traditional practice of storing
engineering product knowledge has taken many forms, such as
work books, text books, drawings, reports and information
embedded in software application tools, but none of these

2 Copyright © 2000 by ASME

forms of representation are amenable to the use of computational
tools to assist collaboration between engineers. The knowledge
held within Knowledge-Based Engineering systems is the same
product knowledge as that held in traditional knowledge storage
systems, the only difference being that all the knowledge has
been entered into a software knowledge base. This knowledge
base allows collaboration between engineers through a set of
rules that hold knowledge about the design, manufacturing
processes, material properties and other aspects of product
Knowledge-based engineering systems do not express designs
with specific data instances as conventional computer-aided
design systems do, but with sets of rules that enable the design to
apply to large classes of similar parts. These rules are the basis
for all knowledge held in Knowledge-Based Engineering
systems and these rules can be selectively executed to allow the
design problems to be resolved. A typical rule may take the form
of IF X then Y, where X is the condition and Y is the reaction to
the condition. Although this looks simple, these rules can be
combined to form complex and powerful expressions.
Therefore the definition of Knowledge-Based Engineering
which we are going to use within this paper is a system that
captures product knowledge and the skills of an individual
within an engineering domain, incorporates them and makes
them available within a computerised application.

In recent years the term Knowledge Management has become
more commonplace within industry. In a recent report [Sheina
and Wood 1999], it states that the Knowledge Management
market is growing rapidly and will continue to evolve and
expand over the next five years as Knowledge Management
becomes a core element of corporate IT strategies. It is forecast
that the worldwide market for Knowledge Management software
is set to increase from US$515 million in 1999 to US$3.5 billion
by 2004. In the same period, Knowledge Management services
will grow from US$2.6 billion to reach US$8.8 billion.
What does knowledge management mean? Have not engineers
been managing knowledge for years quite successfully?
The usual meaning of knowledge is the experience, concepts,
values, beliefs and ways of working that can be shared and
communicated. Knowledge management means attending to
processes for creating, sustaining, applying, sharing and
renewing knowledge to enhance the company’s performance and
create value for that company.
So from this definition of knowledge management it is easy to
see why companies are interested in using knowledge
management techniques and technology. Although engineers
might assert that they have been managing their knowledge, this
has traditionally been on a personal rather than a company basis.
The knowledge has normally been managed in an ad hoc and
sometimes incomplete manner, allowing knowledge loss
throughout the product life cycle (e.g. key members of the
design team leave and the people remaining in the company do
not know why a certain aspect of the design has been designed
in a particular way). As an example, a design team from an
automotive company was asked to reduce costs on one of the
company’s models. It was discovered that the rear windows
were designed to withstand speeds of 90 miles per hour. The
design team saw no reason why this had happened, since most
cars cannot reverse at that speed. It was decided that this was an
ideal item to make a large saving on the production cost of the
car, accordingly the requirements for the rear window were
reduced to around 30 miles per hour. However after the start of
production of the new model, the design team started receiving
complaints about broken or cracked rear windows. It then
became clear that the reason why there was a 90 miles per hour
speed requirement on the rear window, was the fact that the
transport trains from the car plant quite often reached high
speeds and since the cars were loaded with the rear window
facing forward on the train, the rear windows needed to
withstand these high speeds. This is just a simple example of
where a decision was taken and over the years the reason for it
was lost.
In this paper we are interested in the management of knowledge
within the engineering and manufacturing aspects of a
company, namely within Knowledge-Based Engineering
systems that have been developed to reduce knowledge loss for
products and to automate routine design.
The following section looks at the key product knowledge
management issues that are associated with the use of
Knowledge-Based Engineering systems.

As noted in the previous section, knowledge management is
becoming a core part of company operations and knowledge-
based engineering systems provide a method to store and use
product knowledge within an engineering company giving
benefits such as reduced product introduction lead time,
reduced knowledge loss and improved designs. However in the
rush to achieve these benefits, many companies have developed
applications in an ad hoc manner, there by giving the company
the short-term benefits of KBE, but generating longer-term
problems. These longer-terms problems, such as:

• Knowledge loss, due to poor modelling of the
application (limitations of the application);
• Knowledge loss, due to development language
(limitations of the KBE system);
• Knowledge misuse, due to the wrong kind of
applications being developed;
• Increased maintenance costs, due to non-standard
development of applications;
• Knowledge under utilised, due to the inability to share
and reuse the knowledge both at human and computer

The authors of this paper believe that developing applications
in an ad hoc manner is not an effective method of product
knowledge management. There is a need for a structured
methodology and framework to allow the short-term benefits of
KBE to be extended to the longer-term. In order to do this it is

3 Copyright © 2000 by ASME

important to address a number of key issues such as, application
development, knowledge value, knowledge coverage,
knowledge reuse and sharing, company culture and application

If we look at the traditional method of KBE application
development, we see that it is developed largely in an ad hoc
manner within a company. This ad hoc development method
gives the KBE application a limited useful life span compared to
the product lifecycle. Also with an ad hoc application
development the management of the underlying knowledge isn’t
fully considered allowing actual knowledge loss during the
development process. So if a new product is developed using the
existing technology, much of the existing application may
require re-coding, incurring cost and increased product
introduction lead-time that could be avoided.

If the product knowledge and KBE application are effectively
managed, the need for re-capturing, re-engineering and re-
coding the product knowledge is much reduced. Since there is
less knowledge loss and the knowledge retains its value for
longer, it is clear that effective management helps expand the
benefits of KBE applications. The reason why the knowledge
loss is reduced and the knowledge retains much of its value is
because of the maintenance and management the knowledge
receives post-development.

The remainder of this section will look at these key issues in
turn, discussing the reasons why they need to be addressed. The
following section will provide a suggestion for the management
of these issues to form a strategy for product knowledge
management for knowledge-based engineering systems.
4.1. Knowledge Value

Currently no techniques exist to place a value on knowledge
within the engineering environment. However there are a
number of techniques under development to place a value on a
companies knowledge as a whole. One of these methods is
called Intellectual Capital Accounts (ICA) [Erhvervs Udviklings
Rådet 1997]; it should be noted that ICA is neither an authorised
accounting term nor in common use. Through these ICA’s, a
company (both internally and externally) represents its value as
being highly influenced by its intellectual capital. Consequently,
the measurements of the ICA’s are closely related with the
strategy of the company. So what exactly is an ICA? It is not for
raising capital for the company, although it is of interest to
potential investors. ICA often deals with the non-financial
elements of the corporate strategy, customers, product and
knowledge base. Therefore it is seen that intellectual capital and
the management of the intellectual capital is becoming more
important in terms of potential investment and the future of the
The measurement of product knowledge might be included
within an ICA, however they tend to be a higher-level
measurement of intellectual capital or knowledge within a
company and of little use when assessing the value of the
product knowledge.
So even with a method like ICA, the value of product
knowledge is still largely unknown when developing a strategy
for the development and management of a Knowledge-Based
Engineering application. The value of knowledge could be used
to indicate the quality of product knowledge, which in effect
will affect choices made during the development of an
application, such as knowledge coverage, application
development costs, product knowledge reuse and sharing and
application management.
4.2. Application Development

Application development is seen in many companies to be the
first step in the development of a KBE system. This view is
misguided. The first step in the development of a KBE system
is the assessment of the processes used within the company and
the identification of the processes that would benefit most from
being supported by a KBE application. This is shown in fig.1.

FIG.1 Product Knowledge Lifecycle

Once a suitable set of activities within a process has been
identified, it is necessary for knowledge about these activities
to be acquired, many companies achieve this in an ad hoc
manner. Many of the details of the activities are covered by
ISO9000, if this standard has been adopted. During the
development of an application, a knowledge engineer would
have to make multiple visits to knowledge domain experts, just
to enable the engineer to develop a clear picture of the product
he is trying to model within the system. This ad hoc application
development increases the lead time and cost for the KBE
application development.
Therefore application development can be a lengthy and costly
procedure. There is also the possibility that the application
might be incomplete or incorrect, perhaps due to poor
knowledge engineering or poor knowledge quality. These
problems could also be related to the lack of requirement
engineering of a product, since the early definition phases of a
complex product is often characterised by uncertainty,
ambiguity, inconsistencies, incompleteness of customer
requirements and decisions based on analogies to existing
Knowledge Structuring
Knowledge Acquisition
Knowledge Selection
Knowledge Storage/
Knowledge Transfer
and Use

4 Copyright © 2000 by ASME

projects [Volpeliere et al 1999]

4.3. Knowledge Coverage

Knowledge coverage can be defined as the percentage of the real
world an application needs to cover to perform the task in hand.
For example, if modelling a car door, what level of detail is
required to represent things like door handles and locking
mechanisms? So the question is, do we model all of the product
or just key elements? If we model just the key elements, is some
of the product knowledge lost and what is the value of this lost
product knowledge? Does this product knowledge loss reduce
the competitive advantage of the design? In some cases reducing
the product knowledge within an application reduces the
problem-solving capabilities of the knowledge-based
engineering system.
Therefore there are choices to be made when developing the
KBE system between an application with a high level of detail
that takes considerable time and money to develop or an
application that requires less development but will lose its value
more quickly. It should also be noted that KBE systems have
limitations when representing product knowledge. Currently as
already stated, the knowledge within systems is represented by
rules. However the reasoning behind these rules is not
represented within the application. So a KBE system might be
solving design problems using knowledge for which it has no
rationale. This has effects on how we can reuse and share the
knowledge and the management of the application.

4.4. Product Knowledge Reuse and Sharing

The concept of project knowledge reuse and sharing is where the
product knowledge can be shared within the same knowledge
domain (A knowledge domain is a specific area of expertise,
such as Engineering or Medicine), but at different locations
(fig.2) and allows the domain knowledge to be reused in new
situations (fig.3). The knowledge that is being reused is normally
a sub-part of the knowledge stored in the application, which is of
interested within other applications in a different area of the
company, such as costing generation within an engineering
application would be of interest to an accounting application in
the finance department of a company


Fig.2 Product Knowledge Sharing


Fig.3 Product Knowledge Reuse
Currently, reuse and sharing activities have to be done by
manually re-coding from source to target all the rules within the
knowledge base. This is time consuming, expensive and the
exact meaning of the knowledge may be lost during the
translation process. At the moment, reuse and sharing of
product knowledge activities would prove costly to implement
within a company, since there is a lack of standardisation
within KBE applications, platforms and systems.
This is becoming more of a concern, since companies that have
invested in KBE technology within the last ten years are
investing more time and money in the development of KBE
applications. So if any change in market conditions of the KBE
development platform vendor takes place, such as a take-over
or company failure, the company that has invested in their
product faces a problem if support for the KBE development
platform is withdrawn.

4.5. Company Culture

Successful deployment of KBE systems depends to a large
extent on the company having an accommodating culture in
terms of human and organisational aspects. On the human side
during the development and use of KBE systems, there needs to
be a close link between the application experts, knowledge
engineers and end users. If any one of these links fail, the
benefits of the KBE system are reduced. Companies, which
have deployed KBE systems successfully, have recognised the
need to have an educated workforce with respect to the benefits
of knowledge management and KBE systems. Without such a
workforce, a negative culture can exist, and employees may
feel that "giving away" their knowledge will make them
vulnerable to redundancy, or alternatively they may resent a
perceived role of "being told what to do" by the KBE system.
On the organisational side, the extra work asked of employees
needs to be recognised, and in general, problems are
compounded when KBE applications cross-functional
boundaries. Again, successful of KBE systems have recognised
that if KBE is a key technology for their future, then they may
need to reorganise the company to be more project focused,
rather than functionaly based. However, it is recognised that
sometimes organisations are simply too busy to make
knowledge management work [Guptara 1999] particularly as
companies pursue lean organisational structures.

4.6. Application Management

Currently in many companies, applications can be altered a
number of times throughout the life cycle of a product.

5 Copyright © 2000 by ASME

However the documentation of these changes can be incomplete
or ambiguous. There is also an added problem in that the nature
of a KBE application means that the application is hard to
understand, since it is largely in code and not referenced. In
order to understand an application fully for problem-solving
purposes, it is normal to re-engineer the entire application, which
is time consuming and costly. It also wastes much of the effort
expended during the development of the original application.
Since the post-development work on the application can be
costly and time consuming, the maintenance of the application is
sometimes put on hold. This reduces the benefits gained from
the application over a number of years and, in some cases, the
knowledge loss from the lack of maintenance is very important
to the product. Using out-of-date knowledge can result in the
KBE system falling into disrepute and eventually it will no
longer be used.

To manage product knowledge within a knowledge-based
engineering system, it is necessary to address the issues that
have been discussed in the previous section. It is believed that
once we have addressed these issues many of the long-term
problems of KBE systems will be solved. It is clear that these
issues relate and affect each other, such as application
development and application management, where the choices
made at the development phase affect the later management of
the application. Thus one solution may solve or affect more than
one issue. It is only natural to try to solve all of the issues at
once and find the common links between issues. Table 1 lists all
of the issues and places a possible solution or combination of
solutions next to the issue.

Issues / Core solutions
Application Development
 

Application Management

Knowledge Coverage

Product Knowledge Reuse and

Human Environment

Knowledge Value

Table.1 Product Knowledge Management Issues and Solutions
From table 1 we can see that there are four solutions, which can
be used in different combinations to solve any one of the issues.
However, we can use all four solutions simultaneously to solve
all of the issues and problems, which relate to the long-term use
of KBE systems.
The following section considers the four solutions and section
6.2 looks at how these four solutions once integrated can form a
scheme for product knowledge management for KBE systems.

5.1. Core Solutions

The four solutions form the basis for the proposed scheme for
the management of the product knowledge.

5.1.1. Methodology

A methodology is essentially a set of instructions and
guidelines on how to perform a complex procedure. It details
the different tasks, how they should be performed, in what
order and how the work should be documented.
It might take longer to develop an application using a
methodology, however the benefits of using a methodology
outweigh the increased time required for development. A
methodology is vital for quality, reusability and maintainability
of an application.
A knowledge engineer may also benefit from using a
methodology [Lovett et al 1999]:
• Knowledge engineers can benefit from the knowledge
of experts in the field;
• Knowledge engineers who are new to the field will not
omit essential tasks;
• Standardised procedures mean that the work of an
individual can be more easily followed by another;
• It may be possible to recruit staff trained in a required
• Applications, or parts of applications, can be more
easily adapted and reused;
• Ease of maintenance. The time and effort devoted to
the maintenance of most applications is greater than
that needed for the original development;
• Project management is greatly facilitated, as
recognised stages and activities can be identified and if
necessary allocated to development team members.
There are a number of different methodologies available for
KBS systems, however, there is only one methodology for the
development of Knowledge-Based Engineering systems. This
methodology is currently under development as part of the
ESPRIT MOKA (Methodology and tools Oriented to
Knowledge based engineering Applications) project. The
MOKA project is developing a standard methodology for the
development and maintenance of KBE applications. It is hoped
that the MOKA project will allow the lead-time for the
development of an application to be reduced by up to 25%
[Callot et al 1998]. Also, once the product knowledge has been
acquired, it will be stored in a manner that would allow product
knowledge updates, reuse and sharing using the MOKA
software tool, which is also being developed within the MOKA

5.1.2. Language

Current KBE systems use a set of design languages that are
based upon an object-oriented representation of products and

6 Copyright © 2000 by ASME

processes. The design languages are normally a top-level
language built upon a LISP programming language. Most
engineers are not familiar with object-oriented programming or
the LISP language. So if a standard language could be developed
with engineers in mind, there would be less chance of errors in
interpretation (by the engineers) if the terms of the language
matched more closely those with which engineers are familiar.
An additional benefit resulting from the development of a
neutral product knowledge representation language is that
engineers will be only expected to learn and develop skills
within one language. This neutral language would also have the
capability of representing a greater degree of product knowledge
than the existing vendor-dependent representation languages
e.g. design rationale which is not presently modelled. The
neutral language would also improve the management of the
application, since one could have a framework that allows
knowledge to be moved from system to system and be stored in
a central neutral repository, where the company’s applications
would be stored together. The framework would then be used to
distribute the applications thought out the company.
There are a number of different languages that could be used to
represent product knowledge in a neutral form, such as
EXPRESS (ISO10303-11), PIF (Process Interchange Format)
and KIF [Sainter et al 1998 and Uschold 1999]. In work
conducted at the Knowledge Engineering and Management
Centre, EXPRESS has been used to represent product
knowledge for reuse and sharing. The benefit of using
STEP/EXPRESS for the basis of a Product Knowledge
Representation Language is that both current KBE development
systems and STEP use an object-oriented representation and
they both allow a design object to be defined as a collection of
attributes. The major difference between STEP and a current
KBE representation language is that STEP is designed to
represent design data, whereas a current KBE representation
language is designed to represent design knowledge. It is
believed that this gap between the two language types can be
bridged to form a standard Product Knowledge Representation
Language [Sainter et al 1998].

5.1.3. Framework

A framework is the structure or network of computers that
allows the product knowledge to flow around a company or

Fig.4 Basic Framework
The framework can be centred around a knowledge repository
(fig.4). There are a number of different levels of application
deployment available, such as:

1. Standalone applications
2. Linked applications within a company
3. Linked applications within and between companies.

The use of a framework allows the applications to be linked
within the company and between companies. Having all
knowledge and KBE applications at a central repository enables
more effective knowledge management, such as application
maintenance that can update the application in the repository
knowing that whenever the next person uses the application,
they would be using the updated version.
The current trend towards integration of the supply chain will
require the increase of data, information and knowledge sharing
between different companies within the supply chain. Therefore
an increase in the need for the reuse and sharing of product
knowledge would be expected, the framework would naturally
be expanded to include the supply chain. However, the sharing
knowledge has issues, such as intellectual property and the
intangible assets of the companies involved. Therefore it is
important that agreements between companies are made before
actual knowledge sharing can take place. The requirement for
sharing product knowledge has been added to by the speed of
the modern manufacturing world with advances, such as mass
customisation, that being that the process of allowing products
to be configured for the customer, taking advantage of product
modularity and part commonality. Mass customisation is the
fastest growing segment of the manufacturing sector, in the UK
it is worth approximately £22 billion a year. The positioning of
the UK OEMs and their supply chains demands that the
performance on internal and external engineering functions be
greatly improved in this respect. [Kneebone and Oldham 1998].

5.1.4. Management

There are two aspects to management, namely management of
the application and of the people involved (stakeholder).
The management of the KBE application is improved through
the use of a methodology, neutral language and framework.
This combination allows maintenance to be carried out with
relative ease, since the structure of the application would be the
same, the language that the application is in will be the same
and there would be a framework in place that would allow easy
access to the application.
The management of the people that will be using or giving their
knowledge to the application is a harder nut to crack, since no
two organisations are the same, just as no two office
environments are the same. It has been stated by Guptara
[Guptara 1999] that most barriers to success with knowledge
management are ingrained within the culture and structure of
organisations. He also states that knowledge management needs
to be accepted as a key success factor of the overall business
strategy and it must therefore be institutionally recognised. It
could then be developed into a fear of not sharing knowledge,

7 Copyright © 2000 by ASME

rather than the current knowledge hoarding mentality. The
phrase “Knowledge is Power” would be rewritten “Using
Knowledge is Power”.
To achieve cultural change within an organisation is a complex,
and a long-term task and even then success is not guaranteed.
However for the short-term there needs to be an information
sharing exercise, showing the benefits to the company of
knowledge management and the benefits that everyday users
would receive from the knowledge-intensive system.
5.2. Product Knowledge Management Scheme

This product knowledge management scheme assumes that you
have the core solutions in place. For example you would be
using the methodology for the acquisition of knowledge. In
order to achieve the most out of any product knowledge
management scheme the underlying structure (core solutions)
would need to be standard. This enables the development of
Virtual Enterprises where knowledge can be controlled, reused
and shared with partners and throughout the supply chain.
The core solutions should be introduced in the following order:

1. Management
2. Methodology
3. Language
4. Framework

The reason for introducing management first is that this is the
core solution that would require the most time to produce any
benefits. The methodology is introduced next so that knowledge
can be acquired and documented in a standard way for future
development of application, therefore giving the knowledge
engineer a benefit of the new product knowledge scheme as soon
as possible.
The introduction of a neutral language without the framework
would allow knowledge to be shared and reused within different
systems with the use of translators. This is not ideal, so the quick
introduction of the framework is recommended.
Once the standard product knowledge handling system is in
place, the life cycle of an application would take the following

1. Problem Identification
2. Application scoping, selection and feasibility
3. Problem definition
4. Software selection
5. Application design and development of generic
applications to solve the problem
6. Commissioning, testing and maintenance
7. Use, Reuse and Share the KBE application and the
product knowledge held within it. Maintenance of the
application and product knowledge will be conducted
throughout the lifetime of the application.

Once we have an application using the core solutions, we are
able to use, reuse and share the product knowledge throughout
the company and in some cases the supply chain. It is also
expected that the structure of KBE applications will be changed
to produce smaller generic sub-applications that can be taken
and used in new product applications when needed, there by
reducing the lead-time required to develop new applications
when a new product is being developed. This use of generic
sub-applications also makes the maintenance of an application
The actual structure of the product knowledge held within the
application will change, although still in rule form the design
rationale behind the rules will be represented within the

The future of knowledge-based engineering systems is bright.
However, to ensure that it is even brighter, there is a need to
standardise the management of the product knowledge used.
Taking the longer-term view when developing applications will
give the company a repository of knowledge that could be used
in different aspects of the company and enable a product
knowledge library of generic sub-applications to be generated.
If KBE systems were developed in this manner in the wider
world, the ability to buy off-the-shelf generic applications
might become possible. One of the KBE vendors has already
produced two generic applications – one related to the design of
cars and the other to the design of aircraft. These are available
for sale but require access to the vendor’s system. However, if
the applications were developed using the core solutions and
the management scheme mentioned within this paper, the
application would be assessable to different KBE development
platforms and even different KBS development platforms.
If a company uses the product knowledge management scheme
as set out within this paper, it would enable the company to
solve many of the problems associated with KBE systems.
However, it is difficult to produce the right answer for everyone
using the same scheme, but this scheme would form the basis
for most product knowledge management schemes for KBE

Callot, M., Kneebone, S., Oldham,K., “A user-driven project to
develop a Methodology and Tools oriented to Knowledge
Based Engineering Applications”, Proceedings of the European
Conference Product Data Technology Days, Watford UK,
March 1998.

Erhvervs Udviklings Rådet, “Rapportering og styring af
videnkapital”, May 1997, Danish Trade and Industry
Development Council.

Guptara, P., “Why knowledge management fails”, Knowledge
Management Review, July/August 1999, pp26-29, Melcrum

8 Copyright © 2000 by ASME

Lovett, P., Ingram, A., Bancroft, C., “Knowledge Based
Engineering for SMEs – A Methodology”, Proceedings of the
Annual Conference on Computer-Aided Production
Engineering (CAPE’99), Durham UK, 1999.

Kneebone, S., Oldham, K., “The integration of supply chain
engineering using knowledge based engineering”, TCT Rapid
News, Volume 5, Number 6, 1997, pp24-32.

Sainter, P.; Oldham, K.; Kneebone, S., “The necessity for
product knowledge reuse and sharing within knowledge-based
engineering systems”, Proceeding of the ASME Design
Automation Conference 1998, DETC/DAC-5569, Atlanta USA,
September 1998.

Sheina, M., Wood, E., “Knowledge management: Building the
collaborative enterprise”, Ovum (, 1999.

Uschold, M.; Jasper, R.; Clark, P., “Three approaches for
knowledge sharing: A comparative analysis”, Proceedings of the
Banff Knowledge acquisition for knowledge based
engineering systems workshop, Editors B.R.Gaines, R.Kremer &
M.Musen, Banff, October 1999

Winch, G., “Knowledge Management”, IEE Manufacturing
Engineer, August 1999, Volume 78, Number 4, pp 178-180.

Volpeliere,A. Spelberg, R., “ESPRIT 28916 KARE –
Knowledge Acquisition and sharing for Requirement
Engineering – 1
Public Annual Report”,, August