Knowledge-Based Systems 12 (1999) 257–267

Design engineering—a need to rethink the solution using knowledge

based engineering
C.B Chapman*, M. Pinfold
Advanced Technology Centre, Warwick Manufacturing Group, University of Warwick, Coventry CV4 7AL, UK
Received 8 December 1998; accepted 17 March 1999

Abstract
This paper discusses the current limitations of Computer Aided Design (CAD) tools and reports on the use of knowledge Based
Engineering (KBE) in the creation of a concept development tool, to organise information flow and as an architecture for the effective
implementation of rapid design solutions. The KBE tool along with supporting analytical solutions has been applied to the Body-In-White
area of automotive design. The present methods of using CAD and Finite Element Analysis (FEA) systems do not use a unified product/
process model representation and lead to the creation of separate non-relation data models that only capture the result of the engineering
process. The KBE method unifies the engineering intent into a single model that allows for existing or novel design solutions to be assessed.
These design solutions can then represent themselves in the correct form to the analysis systems. Automeshing is achieved using a rule-base
that meshes the model with respect to the analysis solution required, materials and processes. q 1999 Elsevier Science B.V. All rights
reserved.
Keywords: Knowledge based engineering; Computer aided design; Object oriented; Body-in-white

1. Introduction: the designers dilemma
Engineering design is a multi-disciplined environment, a
highly integrated and integrating process. Designers juggle
with many, and often conflicting, constraints to balance
aesthetics, manufacturability and functional objectives
within a marketable product specification. The designers
must transcend their perceived view of the world, to
shrug-off the narrow boundaries of specialisation, while
exploiting specialised technical problem solving skills and
be open to external information at all stages of the design
cycle. This requires the integration and utilisation of infor-
mation, supplied from many sources both internal and exter-
nal and in many formats. The information is constantly
refined by negotiations, clarifications, discussions and
evaluations, until a optimised or compromised solution is
agreed. The success of a traditional design project is deter-
mined in two stages, by the effective communication of
information relevant to a productive solution and then the
capturing of the resultant solution or solutions. This iterative
communication cycle with the results captured has inherent
limitations. Designs can be produced that cannot be manu-
factured. The manufacturing experiences, or the experience
* Corresponding author. Tel.: 1 44-1203-524721.
E-mail address: c.b.chapman@warwick.ac.uk (C.B. Chapman)
0950-7051/99/$ - see front matter q 1999 Elsevier Science B.V. All rights reserved.
PII: S0950-705 1(99)00013-1
of the whole product cycle, are not readily made available or
captured within the design model. Competitive business
time-scales constrain designers to make critical decisions
without exploring alternative strategies. The designer then
constrains the manufacturing engineers, limiting their abil-
ity to improve the process. Decisions taken at the early
design stages may not be evident as having a negative
impact on the downstream process until the product model
is complete. Design decisions are made continuously during
the product development cycle. In fact it has been suggested
that designers make million dollar decisions every minute
without ever knowing it [1]. Early decisions can determine
almost 80% of the product costs (determined costs), at a
stage where knowledge about the product, customer and
the processes involved is low or vague, and the actual devel-
opment costs (incurred costs) are low [2] (Fig. 1). Making
changes to early decisions may necessitate a great repetition
of the design processes steps and incur costs that increase
strongly as we step through the product development cycle
[3] (Fig. 2).
Concurrent Engineering (CE) allows the engineering
team to utilise the varied inputs, knowledge and technology
to speed up product development by integrating down-
stream concerns as early as possible in the design process,
by performing simultaneously many activities that used to
be performed in sequence. For CE to work the agents in the
258 C.B. Chapman, M. Pinfold / Knowledge-Based Systems 12 (1999) 257–267
100%
Determined Cost
Percent of 75%
Product
Life Cycle
Cost 50% Knowledge of Design
Incurred Cost
25%
Concept Detail Verification
Development Development Testing
Concurrent Engineering
Extends
Concept Development
Fig. 1. Product cost related to the design process [2].
product cycle need to be integrated with respect to the
appropriate information exchange. For the purpose of creat-
ing an integrated design environment, computer tools are
used to complement and assist the multi-disciplinary team,
giving the ability of each member to access a common
product model data structure. Today’s Computer Aided
Design (CAD) systems are limited in their inference abil-
ities and it is the duty of the knowledgeable team member to
interpret and assess the impact of any change to the product
model.
1.1. A need to rethink the solution
CAD has evolved from simple drafting and analysis tools.
Our present systems automate small and often isolated tasks
within the overall engineering process. The CAD systems
have been extended by programmatic means to assist the
engineer in localised application areas and in the optimisa-
tion of specialist part objects. To go further, we must take a
holistic view of the design. To create a design system, the
design process should be modelled. Our design systems
should be flexible, and not constrain the designer to work
in an unnatural manner. To automate design or to increase
the role CAD systems play, we must increase the level of
Fig. 2. The cost of change [3].
natural interaction and intelligence. The CAD system
should play the part of a consultant, a valued team member,
making decisions based on the design constraints, interact-
ing with the free flow of the design process, suggesting
alternative strategies and assisting in an optimised or
compromised design solution. The system should allow
for quicker design solutions, giving time to the human
team member to do what they do best, be creative and search
for new scenarios. The system should give back the time to
be an engineer. A true CAD system should be able to draw
Production from a company’s natural knowledge base, the accumulated
experience of the workforce. The proposed system will
demonstrate the ability to utilise knowledge from various
disciplines at the design stage and present this in an intuitive
working environment. It is interesting to note that Quinn
suggests that, “In the post-industrial era, the success of a
corporation lies more in its intellectual and systems capabil-
ities than in its physical assets. The capability to manage
human intellect and convert it into useful products and
services is fast becoming the critical executive skill of this
age” [4].
2. Application domain: design analysis of hybrid
structures
Lightweight vehicle design is being driven by environ-
mental and vehicle performance pressures. More stringent
safety legislation tends to increase body weight. Customers
are demanding increased non-structural content and weight
for more comfort, luxury and power assistance, further
increasing pressure towards lightweight body design. The
decreasing ratio of the structural to non-structural mass
requires higher specific stiffness, strength and energy
absorption for the structural materials and the body, leading
to the use of new higher-performance materials. To mini-
mise body weight, material usage must be optimised, so that
the best material combinations and construction methods
are chosen for a particular purpose. This leads to the use
of mixed materials structures. There is thus a need for
design capability to enable efficient design development
for hybrid body structures.
2.1. Body-in-white
Body-In-White (BIW) is an automotive term used to
describe the structural body of a vehicle. The structural
body is comprised of many sub-structures that come
together to form a framework. This framework has a number
of functions, to distribute the structural loads, as a mounting
for the major components and sub-assemblies, to protect the
vehicle occupants, providing a level of safety in the case of
impact. The BIW contribution to the overall vehicle design
represents the heaviest singular component and has the
largest influence on many of the other vehicles characteris-
tics. Automotive manufacturers and material suppliers see
this area as a key in the battle to meet tougher environmental
 C.B. Chapman, M. Pinfold / Knowledge-Based Systems 12 (1999) 257–267
Table 1
Structural performance Table ULSAB [6]
Structural performance Current average
Torsional rigidity (Nm/deg): 11,531
Bending rigidity (N/mm) 11,900
First BIW mode (Hz) 38
BIW mass (kg) 271
(All targets set for BIW with glass except mass target)
and safety legalisation. The Partnership for a New Genera-
tion of Vehicles (PNGV) is an American government
initiative that aims to provide the framework to create
vehicles that have a target fuel consumption of 54.6 mpg.
To achieve this the reduction of the overall vehicle weight
by 40% is the key. [5]. Other initiatives such as the Ultra
Lightweight Steel Auto Body (ULSAB) [6] project aim to
improve vehicle characteristics, see Table 1, to compete
with lighter weight materials such as aluminium and
composites increasing in use within the automotive
industry.
Design analysis tools are needed for a much wider range
of materials and constructions than hitherto. More design
effort and time will be needed to ensure optimum design
from this wider range of options (Fig. 3). This in turn
requires a faster method for concept structure design in
order to avoid the lengthening design and development
programmes. The conventional concept design route must
be cut short using more intelligent, automatic design
development to take advantage of the established knowl-
edge.
The objectives of this research project are twofold:
1. To develop design analysis tools and methodologies for
the structural simulation of new materials (specifically
composites), manufacturing methods and assembly
methods for stiffness, strength and impact (Fig. 4).
2. To develop a fast concept design tool which will use
the existing knowledge to guide and facilitate the
259
Future reference ULSAB target ULSAB result
13,000 13,000 19,056
12,200 12,200 12,529
40 40 51
250 200 205
development of a vehicle body structure using hybrid
materials (Fig. 5).
It is the second objective described within this paper, the
creation of a Design Analysis Response Tool (DART) using
a Knowledge based engineering system (KBE). The first
objective will feed the second with rules and guidelines to
fuel the KBE system. The DART system has been applied to
the automotive BIW area.
3. The DART system
To understand DART, we shall look at KBE, stepping
though the development cycle and then the implementation
used in the creation of the DART KBE system.
3.1. Knowledge based engineering
KBE is an engineering method that represents a merging
of object oriented programming (OOP), Artificial Intelli-
gence (AI) techniques and computer-aided design technol-
ogies, giving benefit to customised or variant design
automation solutions. The KBE systems aim to capture
product and process information in such a way as to allow
businesses to model engineering design processes, and then
use the model to automate all or part of the process. The
emphasis is on providing, informational complete product
representations, captured in a product model. The product
model represents the engineering intent behind the
Fig. 3. More options.
260 C.B. Chapman, M. Pinfold / Knowledge-Based Systems 12 (1999) 257–267

Fig. 4. Design analysis tools.

product design, storing the how, why and what of a design.
The product model is an internal computer representation of
the product design process and can contain information on
both the product and processes that go to create the part.
Attributes can describe geometry, functional constraints,
material type and processes such as the methods required
to analyse, manufacture and cost a part. The KBE product
model can also use information outside its product model
environment such as databases and external company
programs. The ultimate goal of the KBE system should be
to capture the best design practices and engineering exper-
tise into a corporate knowledge base (Fig. 6). The KBE
methodology should provide an open framework for
formally capturing and defining the process of design
creation [7].
3.2. Developing with KBE
To develop a KBE system we need to first acquire, repre-
sent, reason and then communicate the intent of the design
process, Developing a KBE system is similar in nature to
developing a solution in the design environment. The
problem is first understood at a conceptual level, then
decomposed into understandable working objects, devel-
oped further through an iterative process until a satisfactory
outcome has been reached.
There have been many development methodologies
suggested for the Knowledge Based System (KBS) domain.
The methodologies have been aimed at assisting the devel-
opers to define and model the problem in question. Methods
such as Structured Analysis and Generation of Expert
Systems (STAGES) and Knowledge Acquisition Documen-
tation System (KADS) (an acronym that has been redefined
many times, e.g. Knowledge Acquisition Documentation
System and Knowledge-based system Analysis and Design
Support) [8]. These methods have normally been applied to
areas other than the engineering design area, and have not
been commercially used for KBE development, where
systems tend to follow a traditional design life cycle pattern.
Mulvenna [9] suggest that the KBS needs to be object-
oriented in nature to support an iterative prototyping area
such as design, and that KADS does not support this type of
environment. Church [10] at the keynote speech for the
British Computer Societies Specialist Group on Expert
Systems in 1993, recognised the fact that such methods
proved difficult for the dedicated Expert System (ES) prac-
titioner to use and that this would hinder development by
non-dedicated personnel within companies using a multi-
skilled workforce. The authors concur with this statement
about KBS and would add that the KBE technology has the
ability for widespread growth within the design environ-
ment as the technology is developed along the methods

Fig. 5. Concept design tool.

 C.B. Chapman, M. Pinfold / Knowledge-Based Systems 12 (1999) 257–267
Fig. 6. Corporate knowledge base.
already used quite naturally by the designer. Crowther et al
[11] has recognised that using a specialised knowledge engi-
neer (KE) to gather and represent knowledge in an engineer-
ing domain can lead to frustration due to the possible
ambiguity in the problem representation. Fig. 7 shows
their suggested knowledge acquisition (KA) solution,
using a shared representation as a development method.
The ESPRIT CIME project [12] presents a methodological
approach to design support by presenting a framework for
system creation aimed at the design engineers themselves.
The key to the natural integration of such systems, into
traditional design areas, must lie in the fact that any system
can be created, modified and used readily by the workforce
in the domain area, and not necessitate the use of an
Fig. 7. KA and modelling using a shared representation [12].
261
additional resource, who are only specifically focused on
one area of a systems development. Building the KBE
systems within the iterative design environment has led to
the use of Rapid Application Development (RAD) techni-
ques being employed, by the KBE developers. A typical
system will evolve over time. Akman [13] suggests that
the strategy, in the development of an intelligent CAD
system, should be to “Plan to throw one away. You will
anyhow”. The nature of the design is an exploratory adven-
ture within a set of possibly conflicting constraints. The
techniques of RAD are complementary to the designer’s
natural way of working, RAD is in fact exploratory
programming. The techniques advocate iterative
programme enhancement, leading to an evolutionary life
cycle. The KBE system starts with a skeletal system, with
new modules added until a review stage is entered into.
From the rapid prototype demonstration, the strengths and
weaknesses are assessed and the program developed further.
3.2.1. Implementation process
The KBE tools are very flexible and do not dictate a
particular implementation approach. However in the authors
experience many applications follow a similar pattern. The
aim of the KBE system being discussed is to produce an
interactive application, tailored to the design of the BIW
process.
The DART application is designed to allow the engineer
to interact through a set of menus and graphical interface
tools, to specify the requirements of the desired product,
(Fig. 8). Then, the knowledge base and design rules are
used to construct the product within the imposed
constraints.
The object oriented nature of KBE development using
RAD programming requires up-front work to understand
the problem domain. However, implementation is accom-
plished by the process of incremental development, using
Fig. 9 as a typical sequence of events in the development of
a KBE system, we shall step through and describe the KBE
development process.
The first step is to state the problem. Full definition is not
required as the prototype model is often used to “bring out”
full and open discussions between all the personnel involved
in the product life cycle. The DART initial specification and
project requirements were gathered by using standard CE
methods. Treating the project as a normal engineering
problem solving exercise meant that all people involved in
supplying rules and defining the system had the necessary
skill sets. The CE team meetings were held over a period of
time until a system requirement and initial layout was estab-
lished. The requirement was agreed as:
The concept design system will use the specified struc-
tural performance and overall dimensions to establish an
appropriate stiffness distribution within the constraints of
the initial style and package. It will then use relevant struc-
tural, manufacturing and material knowledge to create an
initial concept body structure. The structural performance
262 C.B. Chapman, M. Pinfold / Knowledge-Based Systems 12 (1999) 257–267
User Interface
Part Libraries
Conceptual Product Model
Design Output
Solid/Surface FEA M esh / output Decks
M odels
Drawings
NC Code
M anufacturing Plan Product / Process Reports
Fig. 8. Architecture of a typical KBE application.
of this design will be assessed using finite element simula-
tion, for which the system will generate appropriate finite
element models and analysis input data. For the evaluation
of the effects of modifications on the structural performance
the system will revise the design in accordance with any
geometric changes which the designer makes, and generate
updated analysis input to re-evaluate its structural perfor-
mance within a timescale needed to support the design deci-
sion processes. The tools will be developed for use by
structural analysts and body concept engineers, see Fig. 10.
After stating the problem and identifying the information
required by the model, key objects were created, to form a
parts library. As each of the part objects were defined they
were individually tested, by creating an instance of the
object. Part objects created within the KBE system form
the building blocks of any model, often representing real
world objects. The DART model, breaks down into six main
Fig. 9. KBE development cycle.
parts the style, packaging, structural members, joints and
panels. These parts then decompose further, each stage of
decomposition varying the intelligence of the objects. For
example primitive objects might only know how to draw
themselves, whereas higher level objects will use the knowl-
edge base to make specific decisions regarding their shape,
relationships, manufacturing process and cost.
Part object terminology changes depending on the appli-
cation domain. As most KBE systems are based on OOP
methodology, they solve problems by defining, creating and
manipulating collections of data and procedures called
objects. The terminology and concepts behind OOP and
KBE relate to how objects are defined, have properties
assigned to them, how they interact and how they are
combined to form more complex objects.
The object encapsulates the data or properties, and the
methods to manipulate that data into a single unit. The class
is the template, and the object is specific case, (Fig. 11). An
object with a particular set of values is called an instance, of
a class definition.
When values change that are used by the object to calcu-
late properties or as parameters for method procedures, the
object is re-evaluated. This is called demand driven compu-
tation and is a fundamental difference between OOP and
conventional procedural programming. It is typical that
any change made to a procedural language or CAD/CAM
macro language, will result in re-computing everything,
since the computations are performed in sequence. In a
procedural language, a value is computed when the proce-
dure for computing it is encountered in the sequence. In the
KBE systems, values are computed only when required.
This technique is called the dependency backtracking. For
example if the topology changes, the model will not be re-
computed until a request is made to draw the object on
screen, or a calculation for the changed objects mass
properties are made.
 C.B. Chapman, M. Pinfold / Knowledge-Based Systems 12 (1999) 257–267
Fig. 10. Initial basic layout.
The method of creating objects is very similar in most
commercial KBE systems. The Adaptive Modelling
language (AML) from TechnoSoft [14] used within this
project has the ability to create objects and write rules
from templates that assist the designer in writing the
programme. The object or define-class form is used to define
new classes. In any define-class, the following may be
specified:
1. Other classes which the new class should inherit from
(superclasses).
2. The properties for the new class and their formulas (attri-
butes).
3. The sub-objects of the new class (children).
The next step was to create an initial conceptual product
model. This is not a complete representation, but acted as a
first draft, a blueprint of the implementation. The conceptual
product model can be thought of as a schematic of the
completed system. A particular design instance of a product
model is described by a product model tree (Fig. 12). This
structure describes the hierarchical relationships between
the various components (parts and processes) of the
model. The model also determines the methods of how
the objects will obtain the correct information, in order to
carry out their specific tasks and as to the information they
will provide to other objects. This hierarchical abstraction
Object Name
Property 1
Property 2
…………
Value 1
Property n
Value 2
Location
………
Visualisation
Value n
Class Definition
Vector
Draw Method
Object
Fig. 11. Class and object relationship.
263
means the decomposition of information into levels of
increasing detail [15]. The decisions made by the system
to create a model will be based on the user inputs and the
knowledge bases.
Using the initial part library and conceptual product
model as a starting point, a subset of the overall system is
defined, complete with user interfaces (UI). The system is
extended by increasing the part library, UI and by expanding
the object class definitions. The incremental development
approach means that the system can be continuously eval-
uated and utilised, as it is always operational (Fig. 13).
4. Current status
The DART project has currently been through three
prototype models and is now in the final development
stage after the prototype models were used to promote
discussion and as a training aid to the developer. Fig. 14
shows the initial prototype and training aid, Fig. 15 shows
the agreed UI layout containing a concept layout, sketched
around the imported surface style model and the resulting
basic structure definition. All the solid and surface geometry
requirements for the structural members and panels have
been coded into part objects. The next interactive require-
ments are the selection and application of the joint members
into the overall structural model. The solid model has the
ability to be altered through the graphical interface or
through altering the non-geometrical properties that
constrain the BIW process model. As this is a conceptual
model any change is allowed, although if a working “Best
Practice” rule is violated the system will inform the current
user and audit the change. Taking the structural body model
into the analysis phase has been proven by automeshing the
solid model within the KBE system. The meshing is done
with respect to heuristic, material and analysis solution rule
bases at an object level. If a structure is altered, for example
a beam section the mesh automatically updates itself. Prior
to the mesh being created the rule bases are checked to see if
the structures material and manufacturing process are still
maintained (Fig. 16). If the part cannot be created in reality
264 C.B. Chapman, M. Pinfold / Knowledge-Based Systems 12 (1999) 257–267
B od y
S tru c tu re
F loor p a n B on n et
then there is no point analysing it, unless we are trying
something outside the current “Best Practices”, at this
point the engineer can override the system.
5. Summary
This paper looks at our present CAD tools with respect to
the design process and reports on the first phase of a KBE
tool for the creation of the BIW structures. The DART
system aims to overcome the limitations imposed by the
computer centred approach in today’s design analysis
process by creating a concurrent unified modelling environ-
ment. The first stage in the DART development was to
understanding the BIW process. The mapping of this
process and subsequent acquisition of rules and relation-
ships was achieved by the use of standard CE methods.
By bringing all the people involved in the product life
cycle together and utilising their specialist knowledge to
come to a common solution, through negotiation and
compromise. Costs, functionality, materials, manufacturing
and processes are all considered. This result of the group
knowledge was then captured as a formal specification on
paper. To create an integrated solution where this knowl-
edge can be automatically processed it was necessary to
capture intent behind the results in a computer system.
Fig. 13. Incremental development of application.
C ar
P owertrain E lec tric al S ys tem s
C ras h m em b ers E n g in e ...... ......
D oors ..... ...... ......
......
Fig. 12. Product model tree.
The next stage was to create part objects in a conceptual
model that satisfied the results of stage one.
Sharing knowledge: KBE can utilise the stored knowl-
edge, making it available at design time to anyone at any
stage of the product cycle. We have already stated that
incompatible systems exist throughout the design process,
KBE can store knowledge within its own structured “smart
parts” or can be used as an interface to bring together the
incompatible data sets, transforming their representation
into one that can be used in an automatic fashion. The
DART system uses process knowledge within its object
structure and also uses external information such as a target
vehicle rule database to populate the structural model. The
ability to populate the object model with external data was
critical in this development as the rules resulting from other
research sources were being conducted in parallel with the
KBE system.
Smart parts: The KBE systems allow the engineer to
create what are sometimes termed as “smart parts”. These
parts are created in the KBE system as objects. The parts can
have rules and methods applied to them, rules such as cost-
ing rules, stress rules and process rules. With the advent of
OOP the capability to build and manipulate parts within a
KBE system is in tune with the real world situations.
Objects with knowledge are manipulated in a non-proce-
dural way that is particularly adept at modelling the design
engineering process. Object Oriented (OO) technology is
forgiving, accepting that we cannot get it correct the first
time and provides an easy mechanism for quickly changing
and modifying the conceptual product model. The object
structure has been developed with reuse in mind, this way
future systems can be built rapidly. The objects are built
using a programming language supplied with the KBE
system and require the engineer to learn programming tech-
niques and the particular language syntax. Although creat-
ing this product/process model in a KBE system was
relatively easy, this was due to the author’s background as
a designer, where decomposition and relationships are
understood. The KBE vendors should not just concentrate
on their particular KBE software when training new users,
but treat KBE as a methodology and also give an under-
standing of the philosophy of OO techniques. The creation
of a system is normally done using evolutionary program-
ming techniques, but before mass acceptance by the
 C.B. Chapman, M. Pinfold / Knowledge-Based Systems 12 (1999) 257–267 265

Fig. 14. Initial prototype model and training aid.

engineering community more research into the management
and planning of the KBE systems should be encouraged.
The main drawback of creating a KBE project is the exten-
sive development time scales, due to the training of engi-
neers to become users of a programming tool. The KBE
vendors offer consultancy to assist at this stage, but this is
expensive. If a software tool is aimed at the engineering
community it should offer Computer Aided Software Engi-
neering (CASE) type visual programming aids. The engi-
neers should be allowed to express themselves and not be
bogged down in syntax.
Modelling and representing the results (views of the
world): The traditional way to create a model was to take
a functional specification and give it to a design engineer

Fig. 15. UI with concept layout and initial frame.

266 C.B. Chapman, M. Pinfold / Knowledge-Based Systems 12 (1999) 257–267
Add or alter target loads and conditions
Fig. 16. Unified model represents all requirements.
who would draw the model in a CAD system using their
experience to interpret the specification. As happens all too
often within industry design models are duplicated, not due
to integration issues, but due to the fact that the different
engineering disciplines have a different yet valid view of the
world.
The KBE systems allow for easily customised UIs to be
created and the product model created by the rule base to be
presented to the user in various ways. There are two main
“views” of the product process required in DART, a full
product representation and a FEA representation supporting
both stiffness/strength and impact modelling. The design
model is a complete representation. The analyst normally
needs to remodel the initial design. This will either be done
by editing the designer’s CAD data or by creating a comple-
tely new model within the analysis software.
Progressive CAD and analysis software companies have
recognised the need for integration and have either inte-
grated with other products or have modelling and analysis
software within one system environment. This, however,
does not go far enough and may well lead to rework. A
design system must have within it the ability to represent
a single product model as various alternative engineering
views. There is a great deal of confusion in this area. As
CAD systems create a geometric model and through data
transfer or direct integration pass the model to other
systems, the CAD vendors suggest that the design/analysis
modelling route is automated. From understanding the
design/analysis process we can see that there is a stage
hardly discussed, that of simplification or model transforma-
tion. This step is critical for the engineering process and
often creates extra models that have no associatively. The
SANDIA Meshing Round Table 1996 [16] stated that auto-
mation of this design/analysis loop is hindered by the trans-
formation process being a judgmental operation and that the
Post verification is concerned with automatic
model simplification to satisfy various analysis
perspectives for example:
• static
•crash
Creating meshed models
directly from the concept
model. Only one model exists
for all variations, the unified
model representation alters
itself depending on the
product perspective being
looked at.
Prepare the model for analysis input:
•Mesh
•Input decks
key issue was geometry processing, agreeing that data
exchange using an international standard was not the solu-
tion. The DART system overcomes these limitations by
having the model transform itself automatically depending
upon on which process is required. This was possible
because of the dynamic nature of the object-oriented repre-
sentation of the design process. Thus a material change,
such as a change from a steel member to aluminium,
would entirely restructure the design and design process.
This method of generative modelling allows the designer
to use the KBE model and rapidly perform a series of
“what-if” analyses during the concept phase, allowing a
number of alternative design solutions to be considered.
The preparation of the model for FEA has shown that a
typical BIW structure of 250,000 elements can entail 15
man weeks of effort upon receipt of the CAD model. The
time taken and cost incurred in this effort has meant that
typically the analysis models are often used in a post design
phase to evaluate a final design that will only be modified if
the results are found to be unacceptable [17]. The DART
system using an automatic analysis model based on an
understanding of the processes and materials will deliver a
prepared model in minutes to the analytical solution tools.
This will allow the body engineers to try more structural
combinations in a greatly shorter period of time, as the
models are all created from a unified model description
duplication and the subsequent management costs will be
eliminated. Downstream processes will benefit from having
available to them 3D solid geometry models and not meshed
models as they have now. The models will also have the
benefit of being known at concept time to be able to be made
reducing costly downstream change orders.
The final stages in the DART system will be completed at
the end of the first quarter of 1999, where a technical system
description and results will be made available.
 C.B. Chapman, M. Pinfold / Knowledge-Based Systems 12 (1999) 257–267
Acknowledgements
This work is being undertaken as part of a UK Govern-
ment EPSRC sponsored research programme under the IMI
Land Transport programme entitled Structural Advanced
Lightweight Vehicle Objective project 4 (SALVO 4). The
partner companies to the University of Warwick in this part
of the programme are Rover Group, British Steel and Ove
Arup Ltd. TechnoSoft [14] supplied the Adaptive Modelling
Language used for this project and the authors would like to
thank them for their support throughout this project.
References
[1] D.E. Whitney, Designing the Design Process. Research in Engineer-
ing Design, 2, Springer, New York, 1990 pp. 3–13, ISSN 09349839.
[2] T.A. Salmone, What Every Engineer should know about Concurrent
Engineering, Marcel Dekker, New York, 1995 ISSN 08247955784.
[3] G. Evans, Time for change, rapid news Europe, Time Compression
Engineering Solutions, Rapid News Publications Plc, TCT House, 2
Worley Court, Bolesworth Road, Tattenhall, Cheshire, CH3 9HL,
UK, 1996.
[4] J.B. Quinn, P. Anderson, S. Finkelstein, Managing professional intel-
lect: making the most of the best, Harvard Business Review 74
(March–April) (1996) 2 ISSN 00178012.
[5] T.C. Moore, A.B. Lovins, Vehicle design strategies to meet and
exceed goals, SAE Transactions Paper 951906, 1995.
[6] High strength steel bulletin, Ultralight Steel Auto Body Demonstrates
Value of Steel in the Automobile’s Future, AISI Publications, Amer-
ican Iron and Steel Institute, 2000 Town Centre, Suite 1900, South-
field, Michigan, USA, 1996.
[7] B.C. Chapman, The design process: A need to rethink the solution
using knowledge based engineering, University of Warwick, MSc
thesis, February 1997.
[8] G.N. Blount, S. Kneebone, M.R. Kingston, Selection of knowledge-
based engineering design applications, Journal of Engineering Design
267
6 (1) (1995) 31–38 CARFAX International Periodical Publishers,
ISSN 09954-4828.
[9] M.D. Mulvenna, J.G. Hughes, Expert agents in knowledge-based
systems—applications and innovations in expert systems, Proceeding
of Expert Systems 93, The Thirteenth Annual Conference of the British
Computer Society Specialist Group on Expert Systems, Cambridge,
December 1993, Information Press, UK, 1999 ISBN 1-85598-021-5.
[10] C.W. Church, A business plan for knowledge inclusive systems,
research and development in expert systems X, Proceeding of Expert
Systems 93, The Thirteenth Annual Conference of the British Compu-
ter Society Specialist Group on Expert Systems, Cambridge, Decem-
ber, Information Press, UK, 1993 ISBN 1-85598-020-7.
[11] W.J. Crowther, D.R. Bull, C.A. Burrows, et al., ISBN 1-899621-04-0,
Knowledge acquisition for engineering systems using bond graphs.
Research and development in expert systems, Proceeding of Expert
Systems 95, The Fifteenth Annual Technical Conference of the British
Computer Society Specialist Group on Expert Systems, Cambridge,
December, SGES Publications, UK, 1995 pp. 41–56.
[12] J. Forster, P. Fothergill, J. Angel, et al., ISBN 1-899621-04-0,
DEKLARE: Knowledge acquisition and support system for re-
design—research and development in expert systems, Proceeding
of Expert Systems 95, The Fifteenth Annual Technical Conference
of the British Computer Society Specialist Group on Expert Systems,
Cambridge, December, SGES Publications, 1995 pp 23–40.
[13] V. Ackman, P.J.W. Ten Hagen, T. Tomiyama, A fundamental and
theoretical framework for an Intelligent CAD system, Computer-
Aided Design 22 (6) (1990) 52–367 ISSN 0010-4485.
[14] Adaptive Modelling Language version 2.1.1, TechnoSoft Inc, 4424
Carver Woods Drive, Cincinnati, Ohio 45242, USA.
[15] w. Zeiler, State of the art, object-oriented hybrid intelligent CAD
system, Computers in Industry, 20(2), Elsevier, Amsterdam, 1992
pp. 1–9.
[16] Analysis Models. Bench Mark, The international magazine for engi-
neering designers and analysts, NAFEMS April 1996, ISSN 0951-
6859.
[17] M. Pinfold, C.B. Chapman, Linking knowledge based engineering
techniques to the finite element analysis of structures, Fifth Interna-
tional conference on Computer Aided Optimum Design of Structures
(OPTI 97).