Robotics and Computer-Integrated Manufacturing 15 (1999) 77 — 87

A procedure for building product models

Lars Hvam*
Department of Industrial Management and Engineering, Technical University of Denmark 423, 2800 Lyngby, Denmark

Abstract

The application of product modeling in manufacturing companies raises the important question of how to model product
knowledge in a comprehensible and efficient way. An important challenge is to qualify engineers to model and specify IT-systems
(product models) to support their specification activities. A basic assumption is that engineers have to take the responsibility for
building product models to be used in their domain. To do that they must be able to carry out the modeling task on their own without
any need for support from computer science experts. This paper presents a set of simple, easily adaptable concepts and methods for
modeling product knowledge. The concepts and methods are based on well-defined concepts and methods from data modeling (object
oriented analysis) and domain modeling (product modeling). The concepts are general and can be used for modeling all types of
specifications in the different phases in the product life cycle. The modeling techniques presented have been tested in different
companies and have proved to work.  1999 Elsevier Science Ltd. All rights reserved.

Keywords: Product modeling; Object oriented modeling; Feature modeling

1. Introduction theories or methods for identification of features. This

The aim of this paper is to present concepts and
methods that will qualify engineers to build product
models, i.e., knowledge bases which contain knowledge
and information associated with products in different
phases of their life cycles, such as design and production.
Based on this knowledge engineers set up specifications
like drawings, lists of parts, operation sequences, opera-
tion instructions, CNC codes, etc.
Product models contain a formalized representation of
product knowledge that is normally represented in the
heads of skilled engineers (domain experts). An assump-
tion in this article is that, rather than having computer
experts interviewing domain experts and building up
applications, domain experts should be qualified to build
detailed models on their own. Attention has therefore
been focused on establishing a simple and easily adapt-
able way of modeling product knowledge.
Central requirements for establishing a product model
are identification and modeling of relevant engineering
entities e.g., features. Today there do not exist any
* Tel.:#45 45 25 44 35; Fax:#45 45 93 44 67; E-mail: larsh@ipv.dtu.dk
paper introduces a set of pragmatic concepts and
methods for identifying and modeling features based on
well-established modeling methods and empirical work.
The modeling includes the formalization of features into
rigid data modeling structures.
The starting point for development of a product model
is normally a domain analysis, i.e., an analysis of relevant
products and related design activities and actors [1]. In
this paper it is assumed that relevant parts and subsys-
tems to be modeled have been identified. The result of the
domain analysis guides the identification of features.
In the next section we present a procedure for building
product models. The following sections present a more
detailed discussion of the basis for identifying features
and how to model features into objects. Finally, a case of
modeling product knowledge using the concepts and
methods in the procedure is presented.
2. Procedure for building product models
Fig. 1 presents a procedure for building product
models. The first two phases in the procedure contain an
analysis of the specification tasks to be supported
(phase 1) and a synthesis (phase 2) where the overall

0736-5845/99/$ — see front matter  1999 Elsevier Science Ltd. All rights reserved.
PII: S0736-5845(98)00030-1
78 L. Hvam / Robotics and Computer-Integrated Manufacturing 15 (1999) 77–87
Fig. 1. A procedure for building product models.
content and structure of the models to build is deter-
mined. The synthesis phase sets up the context, view and
purpose for the identification and modeling of features in
phase 3. The later phases (3—7) are based on the object
oriented project life cycle [2, 3]. This paper focuses on the
identification and modeling of features in phase 3.
The basis for identifying features is set up during the
analysis and synthesis in phases 1 and 2. It is not our
intention to go into a detailed discussion of how to
analyze the specification tasks, but take as a precondition
that the overall content and structure of the models to
build and the purpose, view and context of the modeling
work have all been decided. For further discussion of this
see [1, 4, 5].
In order to clarify the basis of the modeling work, we
provide a more detailed discussion (in Section 3) of the
results of the synthesis phase. Context, view and purpose
for the models to be built guides the identification of
features to be modeled in phase 3. In addition to analysis
of the specification tasks the functionality of the system
and its roles in application are determined using function
modeling (IDEF-0) [6].
Phase 3 involves formalization of features by means of
the concepts and methods of object oriented modeling.
The procedure presented in Fig. 1 follows the object
oriented project life cycle (analysis, design, implementa-
tion and maintenance). Phase 3 covers the analysis phase
containing:
E Identification of objects.
E Identification of object structures and other relations
between objects.
E Separating the models into subjects.
E Identifying attributes and methods in the objects.
The identification and specification of objects are
based on the features described in the initial phase. The
performance and user interface of the system are defined
based on the functional view in the domain analysis
(phases 1 and 2).
 L. Hvam / Robotics and Computer-Integrated Manufacturing 15 (1999) 77–87
3. Identification of features
In this section we discuss the basis for identifying and
modeling features. Features are utilized to describe differ-
ent views on the product throughout the product life
cycle [7, 8]. There are a number of examples of different
features in literature. According to Salomons et al. [9],
these can be divided into two main perspectives, a design
perspective (design features) and a manufacturing per-
spective (manufacturing features). Others define more
perspectives, corresponding to the phases in the product
life cycle. For example, Tjalve [10] defines five life time
phases: development, manufacture, sales/distribution,
use and disposal.
In general, the exact content of features depends
on the perspectives considered. Vesterager et al. [11]
state the following general definition of the feature
concept:
‘‘Feature: engineering knowledge element or concept.
Features are engineering knowledge dependent and as
a consequence when talking about concurrent engin-
eering either dependent on the single functions in the
engineering process with its purpose, viewpoint, con-
text, and semantics, or referring to a (well)defined en-
gineering knowledge domain (for instance turning).
Product specifications are expressed in and/or per-
ceived as features. Features can be basic/atomic
(relative to an engineering knowledge domain) or com-
pound/combined (last-mentioned normally dependent
on the specific engineering task in question). A physical
object described by features can be described in many
different ways with highly unlike features, dependent
on the perspective or the purpose of the descrip-
tion 2’’
The concept of a feature is here defined as a knowledge
element. Features are related to a given function
(for example, designing or preparing a method) or
to a particular domain (for example, turning or as-
sembling electronic components). Thus, the specific
content of the concept of feature (the descriptive
elements) can only be specified in relation to a given
application area.
Products are specified by means of features, which can
be related to a single domain or to two or more domains.
Features describe an item from a particular perspective
(function or domain). Features which describe the same
item can therefore differ markedly, depending on the
perspective.
The exact definition of features depends on the con-
crete products and aspects to be modeled, and involves
asking questions like:
1. Which products or parts are to be modeled?
2. Which part of the product life cycle will be included?
3. What is the functionality of the resulting system?
79
(1) The domain analysis leads to a definition of which
products or parts are to be modeled, and the variabil-
ity of the products and parts to be handled in the
models.
(2) The product life cycle describes the different phases
that a product goes through in its life time (e.g., sales/
contracting, design, methods engineering, produc-
tion, assembly, delivery, use and disposal). In order to
limit the views that have to be incorporated when
identifying and modeling features, a decision has to
be made as to which phases in the total product life
cycle will be included in the models.
(3) The functionality of the models is determined based
on the domain analysis. The functionality can be
described using IDEF-0 function modeling tech-
niques.
The structure of the models is decided according to
common examples from the literature on how to struc-
ture product models, e.g. [12] that separate models into
product, factory, process and application models. Also
the concepts from the chromosome model [13] — func-
tion, organ and part — can be useful when identifying
features in the product model.
In this presentation the term product model denotes
a model containing a description of the product’s
functional and structural design, while product-related
models are the remaining models related to the
product (for example, a process model). Based on
this, the general lines for the subsequent tasks of
identifying features and building up product and prod-
uct-related models are drawn up by formulating
purposes, views and contexts for the modeling task.
The following definitions of purpose, view and context
are based partly on ICAM’s use of these concepts
[6], and partly on the domain-specific features
of the construction of product and product-related
models.
3.1. Purpose
The purpose specifies the intention of building the
model, and what it is to be used for. For example, to
support the task of specifying routings, so as to achieve
a reduction in resource consumption and shorter
throughput time in methods engineering.
3.2. View
This specifies the model builder’s view on the given
context, for example the methods engineering perspective
on the modeling of knowledge and information for build-
ing up routings. The view of the modeling task is set up
according to which phases in the product life cycle have
to be included in the models.
80 L. Hvam / Robotics and Computer-Integrated Manufacturing 15 (1999) 77–87
3.3. Context
The model’s context delimits the model in relation to
its environment (a larger whole). Thus in connection with
the building up of product and product-related models,
a specification is given of which product properties, i.e.,
phases in the product life cycle, and which product or
parts are to be included in the model. Based on this the
features to be modeled can be listed.
4. Building the OOA-model
After the features have been listed, the next question
is how to model the features into a rigid data structure
in order to implement the feature model. For that
purpose we introduce object oriented modeling tech-
niques as a means to model the features, their char-
acteristics and the relations between the different
features.
In this section we give a brief introduction to the object
oriented modeling techniques, and discuss how to model
features into objects.
4.1. Basic concepts in object oriented modeling
Fig. 2 below shows part of the notation used in object-
oriented analysis, as defined by [14]. The notation ap-
plies both to individual objects and to classes of objects.
A class of objects is a description of one or more objects
which have similar properties (attributes) and procedures
(services), together with a description of how new objects
in the class can be created.
The figure shows the following types of relation
between objects:
1. Whole-part structures, which define objects which are
different, but which form parts of a whole, for example
parts of a car: wheels, seats, steering wheel, etc. Rela-
tions in whole-part structures are also defined by their
cardinality. Thus, a seat corresponds to exactly one
car, corresponding to the specification of cardinality
in IDEF1 notation.
Fig. 2. Object-oriented notation [14].
2. Generalization—specialization structures, which define
objects with common information (attributes) and
procedures (services), as for example in the case of
a car object, which contains general information and
procedures about cars, and objects which describe
particular groups of cars, such as goods vehicles and
lorries, with corresponding information and proced-
ures describing the specific group.
3. Instance connections, which describe relations be-
tween individual objects (instances) in the model. As in
the case of whole-part structures, this type of relation
is also described by its cardinality. The notation for
an instance connection is a line between the two
objects.
4. Message connections, which describe the informa-
tion (message) which is sent from a sender object to
a receiver object in order to have a procedure ex-
ecuted. The notation for a message connection is
a bold line with an arrow pointing to the receiving
object.
In building up an object-oriented analysis model
(OOA model), the activities indicated in Fig. 3 below, in
which the OOA model is described as consisting of five
layers, are carried out. The individual activities (layers)
can be thought of as different perspectives, which to-
gether make up the OOA model. The activities are usu-
ally performed in the order in which they are listed, but
can also be carried out in any arbitrary order. In practice
the modeling task is performed as a series of iterations
among the various layers of the model.
E The subject layer contains a sub-division of the com-
plete domain which is to be modeled in different sub-
ject areas. In relation to the use of product modeling,
a subject area can, for example, be a product model or
a factory model [12].
E The class and object layer contains a list of the classes
and objects which have been identified in the indi-
vidual subject areas.
E The structure layer contains the relationships between
the objects, i.e., a specification of generalization—spe-
cialization and whole—part structures.
 L. Hvam / Robotics and Computer-Integrated Manufacturing 15 (1999) 77–87
Fig. 3. The five layers of OOA modeling [14, p. 54].
E The attribute layer contains a specification of the
information associated with the individual objects,
i.e., what the objects know about themselves.
E The method layer contains a description of the
individual objects methods (procedures), i.e., what the
objects can perform.
As a basis for building up an OOA model, it can also be
useful to perform an analysis of the system’s functionality
by using IDEF0 functional modeling. In this way,
one obtains a more detailed understanding of the work-
ings of the domain, and thus an improved basis for
identifying the individual elements in the five-layer OOA
model.
The single objects are described using so-called CRC-
cards [15]. Here the CRC-cards have been extended with
sections describing the object’s position in object hierar-
chies. Another extension is a section with graphical
information, e.g., a sketch, and a section called ‘‘Respon-
sibilities’’, that contains a textual description of the
object’s mission in the model. Fig. 8 shows an example
of a CRC-card.
4.2. Identification and characterization of objects
In this section we present the procedure used to ident-
ify subject areas and objects, and to specify the objects’
characteristics and mutual relationships. As stated, the
objects are modeled based on purpose, view, and context,
the features listed, and the function model. The methods
described are based on Coad and Yourdon [14].
An object is defined as a element in a domain, which is
able to perform in a system by containing information or
is able to execute procedures. A class is a description of
one or more objects, including how new objects in a class
can be created. In this presentation we have chosen to use
the word ‘‘object’’ to refer both to an object and a class of
objects.
When identifying objects in a domain, one can
amongst other things search for structures in the domain
and for functions (procedures) which can be performed
within the domain. In addition, it is possible to focus on
which information and procedures are necessary in the
given system context, including which general properties
and procedures are associated with the domain.
81
During identification of structures, a distinction is
made, as previously mentioned, between generaliz-
ation—specialization structures and whole—part struc-
tures. Generalization—specialization structures are
identified by starting from the individual objects and
investigating whether it would be appropriate in the
context (responsibility) of the system to generalize or
specialize the object’s properties or procedures. If there
are many generalization—specialization structures in the
domain, one should start by identifying the simplest and
the most detailed structures, and then determine the
remaining generalization—specialization structures.
Whole-part structures are identified by grouping ob-
jects which together form a whole, such as components in
a parts list (assembly-parts), objects which can be con-
tained in other objects (container-contents), or objects
which together form a collection of objects (collection-
members). The individual objects are considered as
respectively whole-objects and part-objects in the
hierarchy, and the object’s contribution to the complete
system is evaluated. If the object only contains a status
value, the object is removed, and the object’s status is
instead added as a property of the topmost object in the
hierarchy.
Subject areas are defined partly in order to make it
possible to get an overall view of an otherwise large and
complicated model, and partly to organize the resulting
system (the program) into well-defined units. A subject
area is defined by grouping the uppermost objects in the
structures which have been found, together with the
remaining objects according to subject. For example,
objects which describe a product’s construction can be
placed in one subject area, while objects which describe
the product’s manufacturing process are placed in an-
other subject area.
An effort is also made to minimize dependencies (struc-
tures and instance connections) and communication
(message connections) between different subject areas,
so that objects which are often connected with one an-
other are as far as possible collected in the same subject
area. An object can appear in more than one subject
area, in as far as this will make the model easier to
understand.
Properties (attributes) describe the object’s current
state, and are identified by asking how the individual
objects are described (what must the object know about
itself ?), and which different states the object can be in.
A property can be described by a single value or an array
(table) of values. When identifying properties in a
generalization—specialization structure, the general prop-
erties are placed uppermost in the hierarchy, while
the specific properties are placed at the bottom of the
hierarchy.
Properties are as far as possible denoted by terms
which are used within the domain, and a permissible
interval of values is given, together with units for the
82 L. Hvam / Robotics and Computer-Integrated Manufacturing 15 (1999) 77–87
values (such as $, kg., meters, etc.). In addition, any
limitations on the property, such as dependencies on
other properties, are specified.
Instance connections denote relationships between ob-
jects which are naturally related to one another, such as
the object ‘‘car’’ and the object ‘‘car owner’’, and are thus
in many ways similar to a whole-part structure.
Procedures (services) denote a given behavior which
the individual object is responsible for demonstrating.
Procedures are identified by starting from the various
states which an object, according to its specified proper-
ties, can be in. This can if necessary be done by using an
Object State Diagram, which shows the different states
which an object can be in.
During the determination of procedures, attention is
focused partly on simple procedures, such as creating or
making a connection to an object, or definition of the
value for a property (attribute value) in an object, and
partly on complex procedures, which in turn are divided
up into two categories, involving respectively the calcu-
lation of object attribute values and the displaying of
object attribute values. Procedures are found by asking
which calculations the object is to perform, and which
information the object is to display.
Message connections denote connections in which an
object calls another object in order to have a procedure
executed. Message connections are found by investigat-
ing, for a given object, which procedures in other objects
have to be called, and correspondingly which other ob-
jects that call procedures are to be found in the given
object.
5. Building the OOD-model and programming
In this section we discuss the final phases (phases 4—7)
in the procedure.
When a system is being built up, the perspective
changes from being domain oriented (what and which
task?) to being implementation oriented (how?). Thus, in
the design phase it is made clear how the specified objects
can be implemented most efficiently using given software.
To put it another way, the analysis model is moved over
into a specific hardware and software environment,
which is used as a tool for building up the specified
system.
The design phase is made considerably easier by the
use of OOA analysis, as the OOA model forms the
immediate basis for the OOD model, which in rough
terms is produced by giving more details of the individual
objects and if necessary by adding new objects. In the
design phase the five-layer model from object-oriented
analysis (Fig. 3) is used.
The object-oriented modeling techniques make it
possible to perform a division of labour between the
model builder (domain expert) and the developer of the
computer system (programmer), as the model builder
designs the OOA model, while the developer of the com-
puter system programs the system. Construction of the
OOD model can be performed as a collaboration be-
tween these two participants, as the division of tasks
between the system developer and the programmer can
be weighted differently in each individual situation
(see [1]).
The OOD model which is built up forms the basis for
programming, and thus if an object-oriented program-
ming language is used makes up the system documenta-
tion. In this connection it should be noted that it is
necessary to update the OOD model and the computer
program simultaneously when the system is maintained.
Maintenance of the system is eased considerably by the
use of object oriented modeling. [16, p. 238] argues that
in traditional system development the costs of program-
ming later versions of a system are almost the same as for
version 1, as it is not possible to re-use elements from the
previous version. With object-oriented programming,
there is a considerable saving in the development of later
versions, as it is possible to re-use elements from the first
version.
6. A case study
The modeling techniques have been tested at Alfa
Laval Separation A/S, a SME with 200 employees. The
company manufacture decanter centrifuges to separate
solid materials from liquids like oil, juice, waste water,
etc. In this case study, the choice has been made to focus
on the activities involved in specifying windings (one of
the components in the decanter) and their operations
sequence. Windings are a sub-part of the overall part
conveyor. Based on the results of the analysis of the
specification tasks, the purpose, view and context for the
model can be summarized as follows.
Purpose
The purpose of the model is to support design and
methods engineering for windings in the conveyor. An
OOA model is to be built up which can form the basis for
constructing an application which contains the necessary
knowledge and information for specifying windings and
their manufacturing procedure.
View
The view used in building up the OOA model is that of
the phases of design and methods engineering in the
product life cycle. General rules for building up windings
are to be modeled, so that the model is not just a cata-
logue of previous designs, but contains the necessary
knowledge for specifying new variants of windings within
the given solution space, where the desired degrees of
freedom are taken into account.
 L. Hvam / Robotics and Computer-Integrated Manufacturing 15 (1999) 77–87 83

Fig. 4. The complete task which the system is to deal with in collaboration with the designer and methods engineer.

Context
The context of the model is specification of windings in
the conveyor. The model supports the construction of
drawings, bills of materials and routings for windings in
the given product series. This means that the overall
model involves a product model for windings at the
component level, and a production model containing
knowledge and information for the generation of
routings.

6.1. Presentation of the domain

Besides the listed purpose, view and context I shall give

a brief introduction to the domain by presenting the
overall function model and the part (windings) to be
modeled. The overall task which the system deals with
together with the designer and the methods engineer is
shown in the IDEF0 model in Fig. 4.
From a description (the winding characteristics) of the
windings in the conveyor (described by the internal and
external profile of the conveyor, the pitch, coating, etc.,),
the computer system must generate specifications for the
individual winding segments, together with drawings and
routings.
Fig. 4 shows the functional description of the specifica-
tion tasks at the top level. The content of the boxes A1
and A2 is described in more detailed diagrams at the
lower level.
In the further presentation of the case we ignore the
production subject of the model and focus on the product
subject considering the windings on the conveyor (see
Fig. 5). These are composed of a number of winding
segments.
The external geometry of the winding segments is
calculated from a specification of the windings’ external
profile and the conveyor’s profile (Fig. 5).
Fig. 5. The conveyor.
In addition to their geometric description, the wind-
ings are described in terms of their materials, possibly
together with a hard coating or tiles. Tiles are small, hard
metal plates, which are soldered or riveted on the ex-
tremities of the windings so as to increase their resistance
to wear.
6.2. Identification of features
Fig. 6 below shows part of a feature which describes
windings (a product feature). In the illustration, elements
which form part of the complete feature (elements of type
‘‘consists of ’’) are symbolized by circles, and are distin-
guished from elements describing the individual elements
of the complete feature (type ‘‘describes’’), which are sym-
bolized by triangles.
The feature for describing windings contains the
elements: windings, section interval set, and surface
84 L. Hvam / Robotics and Computer-Integrated Manufacturing 15 (1999) 77–87
Fig. 6. Feature which describes windings.
treatment zone. It should be noted that the surface
treatment zone element, which is part of the overall
description of the conveyor, is included because it deter-
mines the coating of the windings.
6.3. The product model
Based on the identified features, the detailed models
have been built up as shown in Fig. 7. The model consists
firstly of a whole—part hierarchy, as the coating zone,
windings, and section interval set objects are a part of
a whole—part hierarchy under the conveyor object, and
secondly of a generalization—specialization hierarchy in-
volving coating type (hard coating or tiles), related to the
coating zone object.
Windings are constructed of winding segments, whose
geometry is described by the use of the so-called section
intervals, modeled in objects 19 and 20. A section interval
is a group of connected values for the angle of the
external contour of the windings, the conveyor angle and
the angle of cant for a given interval on the conveyor. The
angle of cant gives the tilt of the winding segments
relative to the long axis of the conveyor. The section
interval set object (no. 20) contains knowledge and in-
formation about the complete set of section intervals in
the conveyor.
The conveyor is correspondingly divided into coating
zones (end zone, intake zone and cone zone), each of
Fig. 7. Product model for windings.
which has a particular type of coating, which can be hard
coating or tiles. Tiles are further divided into Alpha and
SH tile types.
Each of the boxes in the Fig. 7 denotes an object which
contains a description of the object’s state (knows) and of
the procedures which the object is able to carry out
(does).
Fig. 8 shows the section interval set object (no. 19)
which, from the external winding profile, conveyer profile
and angle of cant, forms the section intervals for the
conveyor, and calculates the number of tiles, the welding
length and the length of the external contour of the
windings. The formulae for these calculations are listed in
an appendix to the object.
Objects may also contain graphical information.
Fig. 9 below shows the conveyor with a graphical depic-
tion of the section intervals. The figure forms part of
object 19, and has been included in order to increase the
communication value of the model.
Fig. 9 shows how a new section interval is created
every time there is a break in the external profile of the
windings or the conveyor body.
 L. Hvam / Robotics and Computer-Integrated Manufacturing 15 (1999) 77–87 85

Fig. 8. Object no. 19: Section interval set.

model. The individual steps of the model are marked to

indicate which objects are communicated with.
The OOD-model was developed in a cooperation be-
tween the domain-expert (who built the OOA-model)
and the computer science expert. The OOD-model was
programmed by the computer science expert. The time
spent building the OOD-model was 40 hours, while the
computer science expert spent 250 h on programming the
model.

7. Conclusions

Fig. 9. Graphical depiction of section intervals.
The dynamic perspective of the model is described
using diagrams which show the sequence of events in-
volved in the use of the model. Fig. 10, for example,
shows the sequence of events for reading in data for the
The aim of the work presented is to provide engineers
with a simple and easily adapted way of modeling
features, in order to enable engineers to model their
engineering knowledge and information, so that they can
— by themselves — specify IT-systems to support engineer-
ing activities.
86 L. Hvam / Robotics and Computer-Integrated Manufacturing 15 (1999) 77–87

Appendix to Fig. 8

A.1. Calculation of number of tiles, welding length, and

length of the outer contour of the windings

Number of tiles:

Circumference (per cut at the vessel angle)

Circumference

  
" ((DY * n * DY * n#s * s) * LKi/s
G
DY"(DYstart#DYend)/2
AL-tiles:
Number of tiles"Circumference/34.5 (mm)
SH-tiles:
Number of tiles " Circumference/37 (mm)
LKi is the length of the cut in the ith interval
s is the pitch of the windings
DI is the diameter of the conveyor
DY is the diameter of the outer contour of the
windings

Welding length:
Welding length

Fig. 10. Description of the sequence for reading data into the model. 

  
"2 * ((DI * n * DI * n#s * s) * LKi/s
G
The modeling techniques for modeling features pre- #2 * (DY!DI) * LKi/s
sented are based on well defined concepts and methods DI is the diameter at the conveyor body, DY is the
from data modeling (e.g., object oriented modeling, func- external diameter at the windings. If the angle is '(0
tion modeling, and definition of context, view and pur- the diameter is calculated as the avarage value of Dstart
pose to guide the modeling task). In addition, concepts and Dend at the cut. To be calculated for each cut at the
from product modeling have been used in order to guide conveyor body.
the definition of the overall structure of the models. The
modeling techniques are general and can be used for Length of the outer cut of the windings (per covering
modeling all types of specifications in the different phases zone):
in the product life cycle.
The modeling techniques have been tested in different 

  
Length" ((DY * n * DY * n#s * s) * LKi/s
companies where they have proved to work. For
G
example, at Odense Steel Shipyard [17], where engineers
were qualified to use the modeling techniques within (to be calculated for each cut in the covering zone)
2—3 days. Engineering students at the Technical Univer- (All values rounds up to nearest integral number
sity of Denmark have been trained in the modeling tech- [mm]).
niques during an ordinary term course. Experiences from
the course shows that students can learn the modeling
techniques within 2—3 days. References
An important strength of the modeling techniques
presented is that they are simple and general. However, [1] Hvam L. Application of product modeling — from a work study
view point; Ph.D. Thesis; Department of Industrial Management
an important subject for the future research work will be and Engineering, Technical University of Denmark, 1994.
to set up general guidelines for the detailed identification [2] Coad P, Yourdon E. Object-oriented analysis. 2nd ed. Englewood
of features in different phases of the product life cycle. Cliffs, NJ: Prentice-Hall, 1991.
 L. Hvam / Robotics and Computer-Integrated Manufacturing 15 (1999) 77–87
[3] Booch G. Object oriented design. Menlo Park, CA: Benjamin/
Cummings, 1991.
[4] Hvam L. Using product models in SME’s. Proc 5th Conf on
Flexible Automation and Intelligent Manufacturing. 214—225.
Stuttgart, 28—30 June 1995.
[5] Hvam L. Application of methods engineering principles for prod-
uct model development and implementation; The 1st Annual Int
Conf on Industrial Engineering Applications and Practice; 4—7
December 1996; Houston, TX USA.
[6] ICAM project group; Integrated Computer-Aided Manufactur-
ing (ICAM) Architecture Part II, vol. IV-Function Modeling
Manual (IDEF-0); Soft Tech Inc. MA USA, June 1981.
[7] Kristensen L, Andreasen MM. Features describing products
and processes. Proc 6th IPS Research Seminar. Fugls+, March
1992.
[8] Meier A. Krupp Atlas Datensysteme GmbH; Advantages of using
features to integrate product and process modeling — results of
IMPPACT (ESPRIT 2165), 1993.
[9] Salomons OW, van Houten FJAM, Kals HJJ. Review of research
in feature-based design. J Manuf Systems 12(2): 113—131.
[10] Tjalve E. Systematic development of industrial products;
Akademisk Forlag, Copenhagen, 1976 (in Danish).
[11] Vesterager J, M+lleskov T. Department of Industrial Manage-
ment and Engineering, TUD, Tuxen Jan og Christiansen Ka re,
Odense Steel Shipyard, Lind+; Architecture for a global concur-
rent engineering system; 2nd deliverable of IMS Test Case, Global
concurrent engineering; Department of Industrial Management
and Engineering, Technical University of Denmark, 1994.
87
[12] Krause F-L. Knowledge integrated product modeling for design
and manufacture, Organization of Engineering Knowledge
for Product Modeling in Computer Integrated Manufacturing;
179—219, The 2nd Toyota Conf, Aichi Japan, 2—5 October 1988.
[13] Andreasen MM. Designing on a designers workbench (DWB); 9.
WDK Workshop, Rigi, March 1992.
[14] Coad P, Yourdon E. Object-oriented design. 2nd ed. Englewood
Cliffs, NJ: Prentice Hall, 1991.
[15] Beck K, Cunningham W. A laboratory for teaching object-
oriented thinking. Proc OOPSLÄ89: Object-Oriented Program-
ming Systems, Languages, and Applications; SIGPLAN Notices,
vol. 24 (10) October 1989.
[16] Adiga S. Object-oriented software for manufacturing systems.
Berkely, USA: University of California, 1993.
[17] Christiansen KG. Concurrent engineering — A knowledge produc-
tion concept for a Shipyard. Industrial Ph.D. Thesis; Odense Steel
Shipyard, and Department of Industrial Management and Engin-
eering, Technical University of Denmark, 1996.
[18] Hammer M, Champy J. Reengineering the Corporation — A mani-
festo for business revolution, HarperBusiness, 1993.
[19] Harrington HJ. Business process improvement — The break-
through strategy for total quality productivity and competitive-
ness. New York: McGraw-Hill, 1991.
[20] Graham Ian. Object oriented methods. Reading, MA: Addison-
Wesley, 1991.
[21] Meerkamm H. Computer support of design for X — the import-
ance of a product model; Friedrich-Alexander-Universität, Erlan-
gen Nürnberg, May 1993.