TRITA-IIP-03-09

ISSN 1650-1888

Information Modeling of Manufacturing

Processes: Information Requirements for
Process Planning in a Concurrent
Engineering Environment

Johan Nielsen

Stockholm 2003

Doctoral Dissertation
Royal Institute of Technology
Department of Production Engineering
Third edition.

c Johan Nielsen, November 27, 2003

Högskoletryckeriet, Stockholm 2003

Acknowledgments

Without help from many work colleagues, friends and family, this the-
sis would not have been possible to accomplish. With that in mind I
would like to thank the following wonderful people: Professor Torsten
Kjellberg, Olof Nyqvist, Jonas Rosén, Dr. Mattias Johansson, Dr. Gu-
nilla Sivard, Dario Aganovic, Pär Mårtensson, Jonas Fagerström, Pet-
ter Falkman, Daniel Tesfamariam, Dr. Sven Hjelm, Mikael Lundkvist,
Gordon Sjöqvist, Dr. Tomas Lundholm, Professor Bengt Lennartsson,
Dr. Niklas Andersson, Anders Carlsson, Ulla Franke, Kjell Björklund,
Lars-Erik Ringström, and any other name that might have slipped my
mind. Any errors - factual or otherwise - are totally the fault of these
people. The author is not to blame.
Finally a grateful THANK YOU to the organizations that made this
thesis possible, i.e. the financiers, Scania and NUTEK (PDMI-2 project),
Woxéncentrum, Produktionstekniskt Forum (PTF), Scania and VIN-
NOVA (PDTnet project), and Programme for Production Engineering
Education and Research (PROPER).

iii
iv
Abstract
The innovation process is an important process for our prime motor
of welfare, manufacturing. During this process, the prerequisites for
manufacturing are set. To set the best possible prerequisites consid-
eration about products, manufacturing processes, and manufacturing
resources must be made concurrently, which also means involving sev-
eral different disciplines in a collaborative effort.
As a consequence of involving different disciplines, the communication
of engineering information may be hindered. The reason is that dif-
ferent disciplines use different terminology for the same concept and
sometimes have the same terminology for different concepts. This may
result in difficulties understanding each other, which may, in turn, re-
sult in unnecessary loss of quality and productivity.
The main objective of this thesis is to identify information concepts
(i.e. information requirements) for process planning in a concurrent
engineering environment, and to formally define the corresponding ter-
minology. The work is based on case studies at Volvo Car Corporation,
involving management of weld spot and location system information,
and at ABB Body-in-White, involving tender preparation information.
The results are presented in the thesis in terms of an information model,
the Product-Process-Resource (PPR) information model, and two cor-
roborated hypotheses. The PPR information model define the iden-
tified information requirements in the scope of the thesis whereas the
hypotheses concern how, e.g., modularization can be used in informa-
tion modeling.
The PPR information model provides the base for an information plat-
form in a concurrent engineering environment. The PPR information
model enable model based documentation and, thus, traceability of the
evolution of the product, process, and manufacturing resource designs,
and their interrelations.
TRITA-IIP-03-09 • ISSN 1650-1888

v
vi
Contents

1 Introduction 1
1.1 Product Innovation . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Concurrent Engineering . . . . . . . . . . . . . 4
1.1.2 Collaboration in the Extended Enterprise . . . . 4
1.1.3 Communication and Management of Engineering
Information . . . . . . . . . . . . . . . . . . . . 5
1.1.4 Process Planning . . . . . . . . . . . . . . . . . 8
1.1.5 Related Research and Research Gap . . . . . . 10
1.2 Objectives of the Thesis . . . . . . . . . . . . . . . . . 12
1.3 Delimitation of the Thesis . . . . . . . . . . . . . . . . 13
1.4 Structure of the Thesis . . . . . . . . . . . . . . . . . . 14

2 Research Methodology 15
2.1 Research and Science . . . . . . . . . . . . . . . . . . . 16
2.2 Development of Theories . . . . . . . . . . . . . . . . . 16
2.2.1 Hypotheses . . . . . . . . . . . . . . . . . . . . 18
2.2.2 The Way to Prediction - Induction or Deduction? 18

vii
viii Contents

2.3 Influences on the Research Result . . . . . . . . . . . . 21

2.4 Research Method . . . . . . . . . . . . . . . . . . . . . 22
2.4.1 Preparation Phase . . . . . . . . . . . . . . . . 22
2.4.2 Creation Phase . . . . . . . . . . . . . . . . . . 24
2.4.3 Presentation Phase . . . . . . . . . . . . . . . . 26

3 Activity and Information Modeling 27

3.1 Model and Modeling . . . . . . . . . . . . . . . . . . . 27
3.2 Activity Modeling . . . . . . . . . . . . . . . . . . . . . 28
3.2.1 Activity . . . . . . . . . . . . . . . . . . . . . . 29
3.2.2 Rationale Behind the Use of Activity Modeling 30
3.2.3 Activity Model . . . . . . . . . . . . . . . . . . 31
3.3 Information Modeling . . . . . . . . . . . . . . . . . . . 33
3.3.1 Data, Information, Knowledge and Competence 33
3.3.2 Information Model and Information Modeling . 36
3.3.3 Representation of Information Models . . . . . . 38

4 The Innovation Process 41

4.1 Innovation . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2 Successful Innovation . . . . . . . . . . . . . . . . . . . 46
4.3 The Innovation Process . . . . . . . . . . . . . . . . . . 46
4.3.1 The Create Process Plan Activity . . . . . . . . 52
4.4 Organization of the Activities in the Innovation Process 55
4.4.1 Concurrent Engineering . . . . . . . . . . . . . 56
4.5 Managing Information in the Innovation Process . . . . 57
Contents ix

4.6 Information Models in the Innovation Process . . . . . 58

4.6.1 The Product Model . . . . . . . . . . . . . . . . 60
4.6.2 The Manufacturing Process Model . . . . . . . 63
4.6.3 The Manufacturing Resource Model . . . . . . . 65

5 Information Requirements for Process Planning 71

5.1 Hypotheses . . . . . . . . . . . . . . . . . . . . . . . . 71
5.2 The PPR Information Model . . . . . . . . . . . . . . . 74
5.3 Requirements on Process Plan Core Model . . . . . . . 75
5.3.1 Representation of Process Plan . . . . . . . . . 75
5.3.2 Representation of Process Plan Version . . . . . 76
5.3.3 Representation of Processes in a Process Plan . 78
5.3.4 Reuse of Processes in Process Plans . . . . . . . 78
5.3.5 Representation of Process Sequence . . . . . . . 80
5.3.6 Representation of Process Hierarchy . . . . . . . 80
5.3.7 Representation of Alternative Processes . . . . . 81
5.3.8 Representation of Arbitrary Ordered Processes . 82
5.3.9 Representation of Parallel Processes . . . . . . . 83
5.3.10 Representation of Process Grouping Relationship 83
5.4 Requirements on Outer Part of the PPR Information
Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.4.1 Representation of Process Definition Attribute . 86
5.4.2 Representation of Process Property . . . . . . . 86
5.4.3 Representation of Process Classification . . . . . 88
5.4.4 Representation of Capability . . . . . . . . . . . 89
x Contents

5.4.5 Representation of Process Condition . . . . . . 92

5.4.6 Representation of Configuration Control of Pro-
cess Structures . . . . . . . . . . . . . . . . . . 93
5.4.7 Representation of Process Constraint . . . . . . 96
5.4.8 Representation of Documentation . . . . . . . . 97
5.4.9 Representation of Organization . . . . . . . . . 97
5.4.10 Representation of Effectivity . . . . . . . . . . . 98
5.4.11 Representation of Coordinate Space . . . . . . . 99
5.4.12 Representation of Product . . . . . . . . . . . . 100
5.4.13 Representation of Product Concept . . . . . . . 102
5.4.14 Representation of Project Management Informa-
tion . . . . . . . . . . . . . . . . . . . . . . . . 104
5.4.15 Representation of Produced Output . . . . . . . 105
5.4.16 Representation of Input and Output to and from
Processes . . . . . . . . . . . . . . . . . . . . . 106
5.4.17 Representation of Location System . . . . . . . 107
5.4.18 Representation of Mating . . . . . . . . . . . . 110
5.4.19 Representation of Material . . . . . . . . . . . . 112
5.4.20 Representation of Manufacturing Resource . . . 113
5.4.21 Representation of Alternative Resources . . . . 116

6 Validation of the Information Model 117

6.1 Case: Development of Weld Cell at Scania Oskarshamn 118
6.2 Validation of the Information Model . . . . . . . . . . 120
6.2.1 Product Specification . . . . . . . . . . . . . . . 120
Contents xi

6.2.2 Process Plan Specification . . . . . . . . . . . . 127

6.2.3 Work Request . . . . . . . . . . . . . . . . . . . 129
6.2.4 Process and Manufacturing System Solution . . 130
6.3 Test of the Hypotheses . . . . . . . . . . . . . . . . . . 138

7 Discussion and Conclusions 141

7.1 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 141
7.1.1 Strengths and Implications of the Results . . . . 142
7.1.2 Points of Improvement . . . . . . . . . . . . . . 144
7.1.3 Fulfillment of Research Objectives . . . . . . . . 147
7.1.4 Related Research . . . . . . . . . . . . . . . . . 147
7.1.5 Identification of Further Studies . . . . . . . . . 151
7.2 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 153

Bibliography 155

A Definitions 169

B List of Publications 173

C Volvo Car Corporation - A Case Study Report 2000 175

C.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 176
C.2 Process Points . . . . . . . . . . . . . . . . . . . . . . . 178
C.3 Master Location Point . . . . . . . . . . . . . . . . . . 178
C.4 Location Point . . . . . . . . . . . . . . . . . . . . . . 180
C.5 Weld Spots . . . . . . . . . . . . . . . . . . . . . . . . 180
xii Contents

C.6 Master Location and Location Point Preparation . . . 181

C.7 Weld Spot Preparation . . . . . . . . . . . . . . . . . . 184
C.8 Use of Master Location Point and Weld Spot Data . . 187
C.9 Discussion and Conclusion . . . . . . . . . . . . . . . . 190

D ABB Body-in-White - A Case Study Report 2000 193

D.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 193
D.2 Tender Preparation . . . . . . . . . . . . . . . . . . . . 195
D.3 Pilot Study of eMPlanner from Tecnomatix . . . . . . 198
D.3.1 Background . . . . . . . . . . . . . . . . . . . . 199
D.3.2 Goals with the Pilot Study . . . . . . . . . . . . 199
List of Figures

1.1 Relationship between the innovation process, the focus

area of thesis, and the product realization process. . . . 2
1.2 Prerequisites for manufacturing are set during the inno-
vation process, the activities to the left. . . . . . . . . . 2
1.3 Example of how a concept can be referenced by different
terms and how a term can reference different concepts. 5
1.4 The impact of the early decisions on the total cost of de-
velopment, adapted from Schaub (1990) and Vallhagen
(1996). . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5 Work efforts should be focused where they affect the
total cost most. . . . . . . . . . . . . . . . . . . . . . . 10

2.1 The Model of Research (Fagerström and Moestam-Ahlström,

2001). . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 When inference passes from singular statement to uni-
versal statements it is called inductive. . . . . . . . . . 19
2.3 In a deductive approach a theory is never considered
true only corroborated or falsified. . . . . . . . . . . . . 20
2.4 The choice of problem, method and objects influence the
result of the research, adapted from Ejvegȧrd (1996). . 21
2.5 A procedural description of the used research method. . 23

xiii
xiv List of Figures

2.6 The incremental aspect of the hermeneutics circle, with

decision points D1 and D2, was introduced in the model
of the research method. . . . . . . . . . . . . . . . . . . 24

3.1 Under control, an activity transforms its input into out-

put with its mechanism (Marca and McGowan, 1988). . 32

3.2 The relationship between data, information, knowledge

and competence. . . . . . . . . . . . . . . . . . . . . . 35

4.1 Input is being transformed to output in a process. . . . 43

4.2 A transformation system transform inputs to outputs

(Hitomi, 1979). . . . . . . . . . . . . . . . . . . . . . . 44

4.3 A transformation system rely on several sub-systems to

execute the transformation process (Hubka and Eder,
1988). . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.4 The phase review process funnel (McGrath, 1996). . . . 47

4.5 The innovation process according to Sohlenius (1998). . 48

4.6 Activities in the innovation process, adapted from Fager-

ström et al. (2002). . . . . . . . . . . . . . . . . . . . . 50

4.7 Schematic view of activities in the develop manufactur-

ing system activity. . . . . . . . . . . . . . . . . . . . . 51

4.8 Activities in the create process plan activity. . . . . . . 54

4.9 Activities in the innovation process, adapted from Ep-

pinger et al. (1994) and Tátray (1998). . . . . . . . . . 55

4.10 Dependencies between the Develop Product and Develop

manufacturing system activities. . . . . . . . . . . . . . 56

4.11 Concurrent engineering at Toyota (Liker et al., 1995). . 57

List of Figures xv

4.12 Three main domains of information: the product, the

manufacturing process and the manufacturing resource
domains. . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.13 The NIST-model, left, and the ISO-model, right, (Bauer
et al., 1991). . . . . . . . . . . . . . . . . . . . . . . . . 67
4.14 The process capability is determined by the executing
resources and the method that controls the execution. . 69
4.15 The detailed design of a product will be affected differ-
ently when using clinching and spot welding. . . . . . . 70

5.1 The product-process-resource information model with

its process plan core. . . . . . . . . . . . . . . . . . . . 74
5.2 The representation of a process plan. . . . . . . . . . . 75
5.3 The representation of a process plan relationship. . . . 76
5.4 The representation of a process plan and its version. . . 77
5.5 The representation of a process plan version relationship. 77
5.6 The representation of a process in a process plan version. 78
5.7 The representation of a process definition in a process
plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.8 The representation of a process definition. . . . . . . . 79
5.9 The representation of a process definition relationship. 80
5.10 The representation of process sequences. . . . . . . . . 80
5.11 The representation of a group of processes. . . . . . . . 82
5.12 The representation of process object relationship. . . . 84
5.13 A mechanism to represent process structures. . . . . . 85
5.14 An example of an interface mechanism relating core in-
formation with non core information. . . . . . . . . . . 85
xvi List of Figures

5.15 Representation of process definition attribute. . . . . . 86

5.16 The representation of process properties. . . . . . . . . 87
5.17 The representation of process classification. . . . . . . . 88
5.18 The representation of relationships between capability
and requirer or provider of capability. . . . . . . . . . . 90
5.19 The representation of capability. . . . . . . . . . . . . . 91
5.20 The representation of a process condition. . . . . . . . 92
5.21 The representation of a process and its configuration. . 95
5.22 The representation of process constraint. . . . . . . . . 96
5.23 The representation of document. . . . . . . . . . . . . . 97
5.24 The representation of organizational information. . . . 98
5.25 The representation of effectivity. . . . . . . . . . . . . . 99
5.26 The representation of a reference coordinate space of a
process. . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.27 The representation of product and manufacturing re-
source. . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.28 The representation of assembly. . . . . . . . . . . . . . 102
5.29 The representation of a mechanism to represent product
requirements and concepts. . . . . . . . . . . . . . . . . 103
5.30 The representation of project related information. . . . 105
5.31 The representation of produced output. . . . . . . . . . 106
5.32 The representation of input and output of a process. . 107
5.33 The representation of reference system. . . . . . . . . . 108
5.34 A location point, in the shape of a hole, that guide in
three directions (from Volvo (1996)). . . . . . . . . . . 110
List of Figures xvii

5.35 The representation of a mating definition. . . . . . . . 111

5.36 The representation and association of properties to mat-
ings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
5.37 The representation of material. . . . . . . . . . . . . . 113
5.38 The representation of a resource and its association with
a process. . . . . . . . . . . . . . . . . . . . . . . . . . 114
5.39 The representation of a resource and its classification. . 115

6.1 The main flow of information between Scania and ABB

BiW. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
6.2 The weld cell as it was delivered to Scania. . . . . . . . 119
6.3 Representation of the mating of the carrier frame assem-
bly. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
6.4 The 10310025 carrier frame assembly. . . . . . . . . . . 121
6.5 Representation of an instance of the 10310325 door car-
rier reinforcement and its association with a mating def-
inition. . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
6.6 The transformation of the door carrier reinforcement in
the coordinate space of the carrier frame assembly. . . 123
6.7 The representation of the instances of door carrier rein-
forcement and the carrier cross member in a mating. . 124
6.8 The representation of a weld spot. . . . . . . . . . . . . 124
6.9 The presentation of the definition of a weld spot in the
PLibEditor application. . . . . . . . . . . . . . . . . . . 125
6.10 The presentation of the definition of the identifier in the
PLibEditor application. . . . . . . . . . . . . . . . . . . 126
6.11 The presentation of the definition of the placement in
the PLibEditor application. . . . . . . . . . . . . . . . 126
xviii List of Figures

6.12 The presentation of the definition of the weld spot diam-

eter in the PLibEditor application. . . . . . . . . . . . 127
6.13 The representation of a process plan and its two processes. 128
6.14 The representation of a process definition and its classi-
fication. . . . . . . . . . . . . . . . . . . . . . . . . . . 128
6.15 The representation of the definition of spot welding in
the PLibEditor application. . . . . . . . . . . . . . . . 129
6.16 The representation of a work order and related informa-
tion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
6.17 The representation of a functional requirement on a man-
ufacturing resource. . . . . . . . . . . . . . . . . . . . . 131
6.18 The representation of a functional requirement and the
capability the function is required to realize. . . . . . . 131
6.19 The representation of the definition of the joining capa-
bility in the PLibEditor application. . . . . . . . . . . . 132
6.20 The representation of functional requirement and con-
ceptual solution. . . . . . . . . . . . . . . . . . . . . . . 132
6.21 The representation of the constraints on a product com-
ponent. . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
6.22 The representation of a decomposed function. . . . . . 134
6.23 The representation of a decomposed process. . . . . . . 134
6.24 The representation of input and output of a process. . 135
6.25 The representation of concerned detail and transforma-
tion of a process input. . . . . . . . . . . . . . . . . . . 136
6.26 The representation of a process and its manufacturing
resource concept. . . . . . . . . . . . . . . . . . . . . . 137
6.27 The representation of a process and its physical manu-
facturing resource. . . . . . . . . . . . . . . . . . . . . 137
List of Figures xix

6.28 The separation between the process mechanism and the

classification mechanism makes it possible to represent
any type of process with the same process mechanism. 139
6.29 The interface plan produced output mechanism makes
it possible to update or change the model representing
a produced output without affecting the representation
of a process plan version. . . . . . . . . . . . . . . . . . 140

C.1 Project organization at Volvo Car Corporation. . . . . 177

C.2 Organizational scope of the Digital Plant - VCC project. 177
C.3 A locating feature for three guide functions (from Volvo
(1996)). . . . . . . . . . . . . . . . . . . . . . . . . . . 179
C.4 The 3-2-1 rule is used to determine the location of a part. 179
C.5 IDEF0-diagram of the master location and location point
preparation activity. . . . . . . . . . . . . . . . . . . . 182
C.6 IDEF0-diagram of the decomposed master location and
location point preparation activity. . . . . . . . . . . . 183
C.7 IDEF0-diagram of the weld spot preparation activity. . 185
C.8 IDEF0-diagram of the decomposed weld spot prepara-
tion activity. . . . . . . . . . . . . . . . . . . . . . . . . 185
C.9 Main coordinate system of vehicle (from Volvo (1994)). 188
C.10 Overview of systems for DMU-analysis. . . . . . . . . . 188
C.11 Overview of input data to Robcad for weld spot valida-
tion and OLP. . . . . . . . . . . . . . . . . . . . . . . . 189

D.1 IDEF0-diagram of the tender preparation activity. . . . 196

D.2 IDEF0-diagram of the decomposition of tender prepara-
tion activity. . . . . . . . . . . . . . . . . . . . . . . . . 197
D.3 IDEF0-diagram of the pre-study activity. . . . . . . . . 201
xx
Chapter 1

Introduction

The purpose of this chapter is to give context and motivation to the

thesis. In addition, the scope, objectives, and delimitation of the thesis
will be presented.

1.1 Product Innovation

One of the principal means by which welfare is created is manufacturing
(Bollinger et al., 1998; Sohlenius, 2000). Sohlenius (2000) mean that
there are three reasons for manufacturing to be the prime motor of
welfare, the need for products by the customers, the need for return on
investments by the share holders, and the need to earn a living by the
employees. That is, manufacturing fulfills the need of the customers
by providing products, which, when sold with profit, fulfills the need of
the share holders, and it fulfills the need of its employees by providing
employment and income.
Although manufacturing is considered to be the prime motor of welfare
by Bollinger et al. (1998) and Sohlenius (2000) it is only one of the
activities in the product realization process, cf. Figure1.1. Another
activity that can be identified is the innovation activity, the focus of
this thesis.

1
 ;;
;;
2 Chapter 1. Introduction

Product Realization

;;
;;;;;
(Production System)

Innovation Manufacturing
(Innovation System) (Manufacturing System)

Implementation, Development &

Development of Product
Installation & Ramp-Up of Implementation of ...
& Manufacturing System
Manufacturing System Service System

Figure 1.1. Relationship between the innovation process, the focus

area of thesis, and the product realization process.

Innovation is here considered as, in similarity with Cooper (2001); Dav-

enport (1993); Hubka and Eder (1988), and Sohlenius (2000), the trans-
formation of ideas into new products ready for the market. As such
it also includes, but not limited to, the development and implementa-
tion of a manufacturing system that can manufacture these products.
Hence, innovation is the process where many of the prerequisites for
manufacturing are set, cf. Figure 1.2 where innovation is represented
by the product development, the development and implementation of
manufacturing system, and the development and implementation of
service system.

Prod
uct Operation/Service
Dev /R
elop D/R
men
t
Innovation
tion
enta
lem
Imp Ope
ratio
nt Product Implementation n/Se
lopme rvice
Deve
D/R
/R
g
turin
ufac
Man source
Re

D/R/R = Disposal/Reuse/Recycle

Figure 1.2. Prerequisites for manufacturing are set during the inno-
vation process, the activities to the left.
1.1. Product Innovation 3

These prerequisites include prerequisites for product quality and pro-

ductivity. Product quality refers to the satisfaction of customers in
terms of, e.g. features, functionality, and aesthetical perception of the
product (Sohlenius, 2000; Taguchi et al., 1989), whereas productiv-
ity refers to the measuring of efficiency1 in manufacturing (Sohlenius,
2000).
The two concepts, product quality and productivity, are closely re-
lated and highly interdependent. To manufacture high quality product
a manufacturing system needs to be effective, i.e. it needs to manu-
facture products that are needed by customers. Another view is that
a manufacturing system that cannot manufacture products with the
wanted quality is not efficient.
The loss of quality, and thus of productivity, occur, according to Taguchi
et al. (1989), in three different activities, the product design, the pro-
cess design, and the production phases. These activities correspond to
the innovation (product development and manufacturing system devel-
opment), and the manufacturing activities in Figure 1.1. In addition,
the implementation of the manufacturing system could be considered
a source for poor quality, i.e. the manufacturing of the manufacturing
system.
Naturally, these activities have different criteria for decision making,
and there is a clear risk for conflicts between, e.g., the product de-
velopment and the manufacturing system development activities. On
the one hand, the product need to fulfill the needs of the customers
and, on the other hand, these needs need to be fulfilled at a reasonable
cost. Hence, innovation could be described as a struggle to find the
best possible balance between fulfilling the needs of the customers and
the manufacturing cost.

1
Efficiency is here considered to be the quality of being efficient, which is acting
effectively with a minimum of waste.
4 Chapter 1. Introduction

1.1.1 Concurrent Engineering

Traditionally, different needs like these have been considered separately

in a sequential manner. This have resulted in redesigns of the product
when it has been found out that, e.g., reasonable costs, and/or quality
could not be maintained with that particular design of the product.
Consequently, the rework have resulted in unnecessary long lead-times,
sometimes poor quality, and unnecessary high cost.
However, lead-times and costs can be reduced, and quality can be in-
creased by considering more than one aspect of a system2 during its
development (Krause et al., 1993; Liker et al., 1995; McGrath, 1996;
Sohlenius, 1992). This is usually called concurrent, or simultaneous,
engineering, and it implies an extensive communication of engineering
information (Fagerström et al., 2002) between different disciplines.
As a consequence of involving different disciplines, the communication
of engineering information may be hindered. The reason is that dif-
ferent disciplines use different terminology for the same concept and
sometimes have the same terminology for different concepts. This may
result in difficulties understanding each other, which may, in turn, re-
sult in unnecessary loss of quality and productivity.

1.1.2 Collaboration in the Extended Enterprise

Concurrent engineering is an important aspect of a company to stay

or increase its competitiveness. Another important aspect to stay or
increase the competitiveness of a company is its collaboration with
other companies. This can be seen as a network of competences that are
needed to provide products to the market, usually called an extended
enterprise.
As with concurrent engineering, collaboration in an extended enterprise
implies communication of engineering information. Naturally, the same
2
System is here considered to consist of the product and its manufacturing sys-
tem.
1.1. Product Innovation 5

problems of using different terminology may occur in the extended

enterprise too. In fact, the problem may be increased because not only
does the terminology depend on the different disciplines involved, but
also on the different companies. That is, the same disciplines may use
different terminology if they are part of different companies.

1.1.3 Communication and Management of Engi-

neering Information

So far one problematic aspect of concurrent and collaborative engineer-

ing have been identified, that of difference in terminology. This may
result in poor communication because the receiver of the engineering
information does not interpret the message as it was intended by the
sender (Davenport and Prusak, 1998; Schenck and Wilson, 1994).
The core of the problem, though, is that terminology is just a reference
to a concept, cf. Figure 1.3. Terms and concepts are associated with
each other during the interpretation of a message. As the receiver
interprets the message she, or he, associates a term with its concept
and, thus, understands the message. This, however, is only the case if
the sender and the receiver associate the term with the same concept.

Term
Close

CONCEPT
Term CONCEPT
Being near in space or
Near To shut, e.g., a door.
time.

Term
Proximate

Figure 1.3. Example of how a concept can be referenced by different

terms and how a term can reference different concepts.

Usually the problems with different concepts and terminology can be

solved by informal agreements on the concepts, and the terminology
to represent these concepts, e.g. through discussion and reasoning on
a meeting. However, this is only the case when humans are involved.
6 Chapter 1. Introduction

Computer applications are not as adaptable as humans, nor as intelli-

gent, and, thus, cannot discuss and reason with each other to reach an
informal agreement on terminology to use in the communication pro-
cess. Therefore, communication between computer applications need
to be based on formal agreements on terminology (Schenck and Wilson,
1994).
In addition, difference in terminology/concept is not the only cause
for poor communication. Other causes are that of not knowing what
to communicate, and not knowing where to find what to communi-
cate. Both causes are important issues of information management,
and will affect both the quality of the product and the productivity of
the innovation process.
These issues can be solved by: (i) understanding the activities, (ii)
understanding the need for information in the different activities, and
(iii) understanding how this information is related. Doing this and
formally documenting it will provide maps of required information.
Hence, there are needs to formally define concepts and terminology,
and to formally define a map of the required information. Activity and
information models are important to formally represent these defini-
tions.

Activity and Information Models - Maps of Required Infor-

mation

An activity model captures activities and the information flow between

activities. Hence, it is a tool to formally document the operations of
an organization. The documentation can then be used to analyze the
operations of the organization in terms of what the organization does
and what information that is necessary to do this.
As a result an activity model provides a requirements specification for
an information model (Al-Timimi and MacKrell, 1996) in two aspects.
First it provides a scope for the information model, i.e. it states ac-
tivities the information model is to support. Second, it provides the
1.1. Product Innovation 7

high level information types that are needed in the operations of an

organization.
An information model then provides a detailed description of the infor-
mation types. That is, it defines data that represents the information,
it defines the relationships between different data, and it defines the
interpretation rules of data.

Information Models - Formal Definitions of Terminology

An information model provides, besides a map of required information,

formal representation of the interpretation rules of the terminology,
i.e. an information model defines the terminology and its associated
information concepts. These formal rules of interpretation is then used
to implement import and export interfaces to the computer applications
that are to participate in the communication. If the information model
is computer interpretable much of this work can automated (Schenck
and Wilson, 1994).

Standardization for Increased Quality and Productivity

Standardization of information models is a way to establish world wide

common agreements on interpretation rules. Such standardization have
resulted in ISO10303 and complementary standards such as ISO 15296
(EPISTLE), and ISO 13584 (Parts Library). A wide usage of standards
like these would decrease the cost and effort for collaboration, and in-
crease competitiveness. Gallaher et al. (2002) report that the trans-
portation equipment industry in USA, i.e. automotive, aerospace, ship
building, and special tool and die industries, save $156 million (2001
currency) annually by using ISO10303 enabled CAx applications. This
report also estimates a potential benefit of $928 million annually.
Gallaher et al. (2002) categorize the benefits to: (i) decreased avoid-
ance costs, decreased mitigating costs, and (iii) decreased delay costs.
Included in avoidance costs are purchasing of redundant CAx systems,
train and maintain engineering skills in redundant CAx systems, and
8 Chapter 1. Introduction

productivity loss due to engineers working with less familiar CAx sys-
tems, i.e. costs to avoid communication problems. Mitigating costs are
costs that arise due to problems in an actual communication process,
i.e. costs of reworking CAx models, and costs of reentering data in
CAx systems. Delay costs include profit loss as a result of delays due
to communication problems.
Note that the benefits, current and potential, only include CAx appli-
cations. Hence, the benefits are potentially much higher if standards
are used for all types of information exchange, e.g. PDM information,
process planning information, and other types of project information.

1.1.4 Process Planning

Process planning, as it is considered in this thesis, play an important

role in the innovation process. It is the interface between product
development and manufacturing system development. It is in this ac-
tivity that the product specification is interpreted and translated to
manufacturing requirements. Hence, in this thesis, process planning
is considered to be an active part in the concurrent development of
products and their manufacturing systems, not only an activity where
manufacturing resources are selected.

Problem Areas of Process Planning

As an interface between product development and manufacturing sys-

tem development, the process planning activity deals with problems
of managing information about products and manufacturing resources,
as well as manufacturing processes. Not only does this result in com-
munication problems, but it also result in increased complexity as a
multitude of versions of product solutions, process plan solutions, and
manufacturing system solutions must be managed.
The communication problems arise because information from different
disciplines are involved in the communication process. This in combi-
1.1. Product Innovation 9

nation with the increased complexity requires information models that

defines terminology of different information concepts and that relate
the different concepts.
Usually the process planning activity occurs too late in the product
realization activity. The later the process planning activity is carried
out, the less freedom the engineers have to plan, and the less they can
affect the total cost positively, cf. Figure 1.4.

100%
Freedom
of action

Tied-up share
50%
of the total cost Actual
cash-flow

Study Project Detailed Imple- Running

Phase Phase Design mentation Phase

Figure 1.4. The impact of the early decisions on the total cost of
development, adapted from Schaub (1990) and Vallhagen (1996).

A conclusion is to focus the efforts where they affect the total cost
the most, i.e. in the early phases, cf. Figure 1.5. Process planning is
an important part of the product realization process as it is here the
product specification is interpreted and understood from a manufac-
turing perspective. Hence, process planning should start as early as
possible in the product realization process, which, in turn, affect the
requirements on information that is needed.
If process planning aspects were considered in the early phases, and
related decision making was documented, these aspects would be con-
sidered when they can affect the total cost the most. In addition,
process planning would be a more active part of the total innovation
process. An activity where manufacturing requirements where defined
rather than only selecting manufacturing resources.
10 Chapter 1. Introduction

100%

50%

Study Project Detailed Imple- Running

Phase Phase Design mentation Phase

Figure 1.5. Work efforts should be focused where they affect the
total cost most.

The agility3 in process plans has also been poor. Most process plans
have static relationships relating products to manufacturing resources
via the process plan, i.e. the process plans represent a particular type
of, or a particular, manufacturing resource that should carry out a
particular manufacturing process. At most this concept have the ability
to represent a portion of flexibility4 .

1.1.5 Related Research and Research Gap

In Section 1.1.4 some of the problems within the innovation process

was identified. These problems concern the following areas:

• information requirements (information models),

• process planning (conceptual and detailed), and

• agility in process plans.

Schenck and Wilson (1994) discuss information modeling in general and

information modeling with EXPRESS in particular. Their approach
3
Agility is the ability to adapt to unforeseen events.
4
Flexibility is the ability to adapt to foreseen events.
1.1. Product Innovation 11

may be used for any application area where there is a need to capture
information requirements and to formally define the interpretation rules
of data.
One such application area is process planning, which Juran (1988)
mean can be described as a process where goals are reviewed, pro-
cesses are chosen, facilities capable of meeting the goals are provided,
and methods are provided. Similar, but more specific, descriptions
are provided by Curtis (1988); Eversheim et al. (1991); Feng and Song
(2000); Ham and Lu (1988); Salomons (1995); and van Houten (1991).
Compared to the other, Feng and Song (2000) add an interesting aspect
of process planning, the conceptual process planning. With conceptual
process planning, Feng and Song (2000) mean the planning of pro-
cesses at a phase in the innovation process when the detailed design
of the product is not established. They also provide an information
model describing the information requirements for conceptual process
planning.
Other have also worked in the field of conceptual process planning, e.g.
Haudrum (1994) consider production methods during the design stage,
and Boothroyd et al. (2002); Boothroyd and Radovanovic (1989); and
Mileham et al. (1993) estimate the cost of manufacturing processes in
the early design stages before design details are available.
Related to process planning is the representation of capability. Whereas
Bergman and Klefsjö (1998) and Curtis (1988) discuss bot machine and
process capability, Algeo (1994); Gindy and Ratchev (1992); and Juran
(1988) mainly focus on process capability.
Close related to process planning is the research area of features and
feature technology. A large amount of research effort have been put in
this area, e.g. van Houten (1991) describe the use of features in the
PART computer aided process planning system, Salomons (1995) also
use a feature based approach to support design of mechanical prod-
ucts, Dürr and Schramm (1997) make use of features to feedback man-
ufacturing knowledge to the early design stages, and Wingȧrd (1991)
describe how form features can be used in CAD/CAM systems.
12 Chapter 1. Introduction

However, information management in process planning, where process

planning is part of the concurrent development of products and their
manufacturing systems in the extended enterprise, is not considered.
This means that typical problems in this area, such as how to define
and represent information that are relevant for process planning, have
not been considered to its full extent.
In addition, conceptual process planning have not fully been elaborated
as an activity where conceptual requirements on the manufacturing sys-
tem can be identified and documented. Many of the approaches related
to conceptual process planning either consider a traditional way of plan-
ning only earlier, or focus on evaluation-method aspects of process plan-
ning. Hence, the documentation-of-manufacturing-requirements aspect
is forgotten.
Finally, a future aspect of process planning is forgotten as well. The
aspect of eliminating the need of a static coupling between a manufac-
turing process and its executing manufacturing resources by having a
dynamic relationship based on requirement and capability. This would
increase the agility of the process plan and postpone the point in time
when the final decision on what particular manufacturing resource that
has to execute a particular manufacturing process, e.g. even as late as
at the actual execution of the on-the-fly generated production plan.

1.2 Objectives of the Thesis

Considering the identified gap in research, one main area of interest
is to identify and define information requirements for process planning
in the context of concurrent engineering. In particular the information
requirements concerning the early stages of the innovation process-
Naturally, these requirements include the important connections be-
tween products, manufacturing processes, and manufacturing resources
as well. Hence the following objectives were set:

Research objective 1. Identify and define information requirements

for process planning in the context of concurrent engineering.
1.3. Delimitation of the Thesis 13

Research objective 2. Identify and define important connections be-

tween product, process and manufacturing resource information for pro-
cess planning.

These objectives have been the base to formulate relevant research

questions to guide the project work:

Research question 1. What information is needed for process plan-

ning?

Research question 2. What information is needed to describe the re-

lationships between products, manufacturing processes, and manufac-
turing resources?

Research question 3. How can the information be structured in an

information model?

1.3 Delimitation of the Thesis

The innovation process is by nature complex and include a vast amount

of aspects. Therefore the work of limiting the scope of the thesis has
been an important, and difficult, activity.
Naturally, the scope has been dependent on available case study objects
at participating project partners. Since the project partners have been
Volvo Car Corporation, ABB Body-in-White5 , and Scania, it has been
natural to limit the scope to automotive industry. Particularly the
body-in-white operations, and more specific weld spot operations.
Hence, the scope of the thesis concern weld spot process planning as
part of the concurrent development of manufacturing systems in the
extended enterprise.
5
Although ABB Body-in-White has changed their name to ABB Automation
Technologies (ABB ATRM/AM) since the study they will still be referred to as
ABB Body-in-White throughout this thesis.
14 Chapter 1. Introduction

1.4 Structure of the Thesis

The structure of the thesis is as follows:
Chapter 1 give context and motivation to the thesis, as well as objec-
tives and research questions.
Chapter 2 discuss research methodology in general and present the
method of the work for this thesis in particular.
Chapter 3 give relevant theory for activity and information modeling,
as it is used in this thesis. The chapter also deals with the relationship
between activity and information modeling.
Chapter 4 give the main theoretical framework for the thesis. It is
within this framework the result has been developed and hypotheses
tested.
Chapter 5 present the main result and hypotheses. The result is pre-
sented in terms of an information model, the PPR information model.
This work have also resulted in two hypotheses, which are also pre-
sented in this chapter.
Chapter 6 discuss the testing of hypotheses and relevance of the result
in terms of validity.
Chapter 7 give a critical discussion of the results in terms of hypotheses
and information model, as well as indicate further work and conclude
the thesis.
Chapter 2

Research Methodology

The purpose of this chapter is to introduce the reader to the author’s

view on research and science, and to describe the research method that
was used. The hope is that this introduction will provide the reader
with what Ödman (1994) and Westin (1973) call pre-understanding of
the research approach, which will help the reader to understand and
interpret the research results.
Pre-understanding is the historically given understanding that is neces-
sary to understand an observation (Ödman, 1994). Pre-understanding
gives the direction of a search and determines the view from which an
object is observed. Considering these two aspects of pre-understanding,
it is obvious that describing the author’s view on research and science,
as well as the research method, will help the reader to interpret and
understand the results in their intentional meaning.
However, as this thesis is not about research methodologies, the theo-
ries presented and discussed in this chapter will, mainly, be the ones
that have had major impact on the methodology of this research project.

15
16 Chapter 2. Research Methodology

2.1 Research and Science

A reasonable question for a doctoral candidate to ask is, what is re-

search and science? Føllesdahl et al. (1993) mean that the main objec-
tive of research and science is to acquire knowledge and understanding.
Here, research is considered to be the process where knowledge and un-
derstanding about objects and phenomena in the Universe is acquired,
whereas science is considered to be the framework of valid methods that
are used to acquire the knowledge and understanding. In natural sci-
ence, for instance, researchers want to understand natural phenomena
such as nuclear fission.
A contrast to natural science is engineering science. In engineering sci-
ence the concerned objects and phenomena are those created and initi-
ated by humans to fulfill human needs. Hence, research in engineering
science is the process of understanding the principles of creating and
controlling these objects and phenomena. For instance, the effort made
by, e.g., Andreasen (1991); Pahl and Beitz (1996); and Suh (1990) to
understand and describe the principles of design.

2.2 Development of Theories

A description of, e.g., the principles of design is called a theory, which

can be used to explain the behavior of objects, or to predict phenomena
and their consequences. That is, the theory can be used to answer
questions about the concerned objects and phenomena. Fagerström
and Moestam-Ahlström (2001) describe the entities and activities that
are involved in the creation of a theory, as well as the direction of
information, in the Model of Research, cf. Figure 2.1.
It is clear that Fagerström and Moestam-Ahlström (2001) have an en-
tity focused approach describing research. Objects are the things, phys-
ical or non physical, in the Universe that are of concern for the research,
e.g. the design process. Subjects are those who conduct the research,
2.2. Development of Theories 17

Object Observation Subject

Validation Presentation

Theory

Figure 2.1. The Model of Research (Fagerström and Moestam-

Ahlström, 2001).

i.e. the researchers. Theories are the result of the research, e.g. the
law of gravity.
The subordinated activities describe what is happening in the research.
Mainly this is an interaction between the subject and the two other.
That is, the subject observe the object, the subject present the theory
as a result of its observation, analysis, and synthesis, and the subject
validate the theory to assure that it is a correct reflection of the object
within its Universe of discourse.
As indicated in the previous paragraph, analysis and synthesis are also
part of the research. These activities are not part of the Model of
Research, but if they are to be included they should probably be arrows
going out of and into the subject. This to indicate that the information
is still at the subject during these activities.
The validation activity is one of the most important activities in the
development of a theory. In Section 2.2.2 two fundamentally different
approaches to develop and validate theories are discussed, but first
hypotheses are discussed.
18 Chapter 2. Research Methodology

2.2.1 Hypotheses

Popper (2003) call the result of an observation for a singular statement.

It is a statement about a particular object in a particular place at a
particular time. That is, it is not a statement about swans in gen-
eral, but a statement about the color of a particular black swan in a
particular park in Sydney, Australia, at noon August 1, 2001.
Definition 2.1. A singular statement is a statement that accounts of
results from observations or experiments.

(Popper, 2003)

In contrast to singular statements are universal statements. Popper

(2003) mean that theories are universal statements. Hence, a univer-
sal statement is a statement that can be used to explain or predict a
singular statement. Another universal statement is the hypotheses, a
tentatively anticipated universal statement that is the subject of test-
ing.
Definition 2.2. A universal statement is a statement in terms of a
theory or a hypotheses.

(Popper, 2003)
Definition 2.3. A hypotheses is a tentatively anticipated universal
statement that is the subject of testing.

From (Popper, 2003)

2.2.2 The Way to Prediction - Induction or De-

duction?

There are two fundamentally different types of inference, induction and

deduction. These two inferences constitute two fundamentally different
approaches to create and validate theories.
2.2. Development of Theories 19

Inference is called inductive if it passes from singular statements to

universal statements (Popper, 2003), cf. Figure 2.2. That is, the devel-
opment of a theory is called inductive if it is concluded that the theory
is true because of the singular statements it is based on.

(True) Theory

Induction

Singular Statement

Observation and Conclusion

Phenomena

Figure 2.2. When inference passes from singular statement to uni-

versal statements it is called inductive.

Both Chalmers (1999) and Popper (2003) dispose inductive inference

by arguing that no matter how may observations that are made, there
is always the possibility that the next time an observation is made it
will prove that the theory does not hold. A classical example is the
observation of white swans resulting in the theory that all swans are
white. Independent of the thousands and millions of observations of
white swans, the first time a black swan was observed it proved that
the theory did not hold.
Popper (2003) further emphasize the shortcomings of an inductive ap-
proach by referring to history, which show that all theories have been
proven to not hold. This is obvious because a theory only reflect the
observers interpretation of a phenomena in the Universe, and as the
knowledge of the observers increase the understanding of the particu-
lar phenomena changes and, thus, so do the theory.
A deductive method also depend on induction to develop universal
statements, i.e. universal statements are developed by observing singu-
lar phenomena, draw conclusions from the observation, and generalize
20 Chapter 2. Research Methodology

these conclusions. However, in a deductive method it is not concluded

that universal statements are true because of the singular statements
they are based on.
On the contrary, Popper (2003) mean that a theory can never be estab-
lished as true, merely corroborated. This is done by critically testing
the theory, cf. Figure 2.3. A critical test is conducted by establish-
ing singular statements by means of deduction, and then comparing
the singular statements with one another and other statements to find
their logical relationships. Four different approaches to testing may,
according to Popper (2003), be distinguished.

Theory

Corroboration
Induction Deduction
or
Falsification

Singular Statement Singular Statement

Observation and Conclusion Test

Phenomena Phenomena

Figure 2.3. In a deductive approach a theory is never considered

true only corroborated or falsified.

First, a logical comparison of the deduced singular statements can be

made. This is done to evaluate logical consistency between the singular
statements, e.g to find equivalence, similarities, and contradictions.
Second, the logical form of a theory can be tested. That is, a test can
be conducted to find out whether the theory is of empirical or scientific
nature, or if it is, e.g., tautological.
Third, a theory can be compared with other theories. The aim is to
determine whether the theory have a scientific contribution or not.
2.3. Influences on the Research Result 21

That is, to determine if the theory constitute a scientific advancement

compared to already established and justified theories.
Fourth, a deduced singular statement can be compared with practical
applications and experiments. If the test verify a singular statement
then the theory has passed its test for time being and, thus, the hy-
pothesis has become more likely to be a reflection of the world within
its universe of discourse. If, on the other hand, the test falsify a singu-
lar statement then the hypothesis, from which the singular statement
was logically deduced, is falsified and, thus, the hypothesis is not valid.

2.3 Influences on the Research Result

It is natural to believe that research and the result of the research

are influenced by the environment in which they exist. Three such
influences, identified by Ejvegȧrd (1996), are the research problem, the
method and the objects of observation, cf. Figure 2.4.

Problem

Method Objects

Research result

Figure 2.4. The choice of problem, method and objects influence

the result of the research, adapted from Ejvegȧrd (1996).

It is obvious that the choice, and wording, of the problem is a ma-

jor influence because the problem is the starting point for all research.
When the problem is defined a suitable research method and suitable
22 Chapter 2. Research Methodology

objects of observation can be chosen (Yin, 1994). They in turn, influ-

ence each other (Chalmers, 1999) as well as the result of the research.
These influences and their relationships are shown in Figure 2.4.
A fourth influence can also be identified, namely the researcher. The
researcher choose and define the problem, as well as method and objects
to observe. All observations will be colored by the researcher and, thus,
influence the result (Chalmers, 1999).
Again, Ödman (1994) and Westin (1973) call this pre-understanding.
It is the pre-understanding that gives direction in a search and de-
termines the perspective that is put on the objects of observation. All
interpretation of events and things in an environment will be colored by
the assumptions and understanding the researcher already have of that
environment, or that the researcher have acquired during the research.
Therefore it is important to describe not only the environment in which
the observation have been made, but also the researchers view of that
environment, the objects of observation, and, perhaps most important,
the procedure of conducting the research, i.e. the research method.

2.4 Research Method

As discussed in Section 2.2, it is important to use a systematic and

structured method for research. In this research project a method
consisting of three phases were used. This phases were the preparation,
the creation, and the presentation phases, cf. Figure 2.5.

2.4.1 Preparation Phase

The setup of the research project was made in the preparation phase
by defining the research problem, defining the objectives and research
questions, and by configuring the research methodology. The purpose
of these activities was to define the necessary means to control and
guide the research.
2.4. Research Method 23

Preparation
Define
Configuration
Define Objectives
of
Problem and Reserach
Methodology
Questions

Test Result Theoretical

Development
Presentation and and Practical
of Result
Hypotheses Studies
Presentation Creation

Figure 2.5. A procedural description of the used research method.

The main prerequisite for everything in the research project has been to
identify and define a problem. Without understanding that there was
a problem, and what the problem was, there was no need to conduct
the research.
The objectives and research questions have, mainly, served as a con-
trol of the research project. In other words, activities that have not
contributed to (i) fulfillment of the objectives or (ii) the answers of the
research questions, have not been part of the research project. As a
consequence, the focus and aim have been maintained throughout all
the activities.
The configuration of the methodology was made by identifying suitable
methodologies, combining them and adapting them to the needs of the
research project. These needs were derived from a need of understand-
ing the innovation process as a whole. A whole that is dependent on
the interaction with, and between, its parts.
Considering these needs of understanding the whole and its parts, the
hermeneutics research method (Ödman, 1994) and, more specific, the
hermeneutics circle (Føllesdahl et al., 1993; Ödman, 1994) was used as
the overall research method. As a consequence, the incremental aspect
of the hermeneutics circle was introduced, cf. Figure 2.6.
In D1 a decision is made whether the new experience from the theo-
retical and practical studies have affected the earlier understanding of
problem. If the earlier understanding of the problem was affected a new
24 Chapter 2. Research Methodology

Preparation

Define
Configuration Theoretical
Define Objectives
of and Practical D1
Problem and Reserach
Methodology Studies
Questions

Test Result
Development
Presentation D2 and
of Result
Hypotheses

Presentation Creation

Figure 2.6. The incremental aspect of the hermeneutics circle, with

decision points D1 and D2, was introduced in the model of the re-
search method.

definition of the problem was made, research questions and methodol-

ogy was refined.
The D2 was the starting point for the main incremental loop. If the
result was found to be not satisfactory, further work had to be done to
study theory and practice, and to develop and test new results.
In addition to the hermeneutics circle, literature studies, case studies,
activity modeling1 , and information modeling2 were also used.
The different methods were used for different purposes in different
phases of the project. The hermeneutics method influenced the overall
research strategy. As a complement, the other methods influenced the
more practical approach of understanding the research problem, ob-
serving the research objects, and creating, documenting and verifying
the result.

2.4.2 Creation Phase

The development of result was carried out in the creation phase by

theoretical and practical studies, development of result, and test the
1
See Section 3.2.
2
See Section 3.3.
2.4. Research Method 25

result and resulting hypotheses. The purpose of these activities was

to identify the requirements for information about manufacturing pro-
cesses in the innovation process, and to develop an information model
that capture these requirements.
The theoretical studies were carried out as literature studies, whereas
the practical studies were carried out as case studies. Thus, the innova-
tion process in general, and the process planning activity in particular,
was studied from two perspectives. First, from theories and experi-
ences of other researchers, such as Andreasen and Hein (1987); Claus-
ing (1994); Hubka and Eder (1988); Kjellberg (1982); Pugh (1998);
Schenck and Wilson (1994); Suh (1990, 2001); Ueda et al. (2001); Ul-
rich and Eppinger (2000); van Houten (1991). Second, from experience
within the research project itself in terms of case studies at Volvo Car
Corporation, and ABB Body-in-White.
Considering the identified requirements, an information model was de-
veloped. This activity mainly involved the analysis of what was found
in the studies, the synthesis to develop an information model and the
presentation of the information model in EXPRESS3 /EXPRESS-G4 ,
cf. Section 3.3.
Furthermore, the result was verified by populating the information
model with data from fictive and real cases. The final verification
and test of hypotheses was made by data from the PDTnet project, cf.
Mȧrtensson et al. (2002).
To summarize and clarify, the hermeneutics circle was used in two
aspects here. First, in the overall process of the creation phase, i.e.
the iteration between the analysis, synthesis and verification activities.
Second, in the synthesis activity for the iteration between the activities
of modeling, population and verification of part of the information
model.

3
EXPRESS is a lexical modeling language.
4
EXPRESS-G is a graphical subset of EXPRESS.
26 Chapter 2. Research Methodology

2.4.3 Presentation Phase

As a last activity of the research project, the result was presented by

writing this thesis. In addition to the text and illustrations of the
thesis, the main findings were presented in an information model by
using the EXPRESS/EXPRESS-G modeling language.
Chapter 3

Activity and Information

Modeling

The purpose of this chapter is to provide a theoretical background to

what a model is in general, and what an activity and an information
model is in particular. In addition, several related terms such as data,
information, and knowledge will be elaborated and defined.

3.1 Model and Modeling

The term model have many definitions. The least common denomi-
nator seems to be that it is a simplification, an abstraction of some-
thing (Booch et al., 1999; Edlund and Högberg, 1997; Fishwick, 1995;
Føllesdahl et al., 1993; Mäntylä, 1988; Schenck and Wilson, 1994),
which may not be real; it can be an imaginary thing such as a model
of a product that has never been designed before. As a simplification
a model will not represent the whole, but merely some perspectives of
interest of what is being modeled at a certain level of detail. Hence,
the model is only valid for those perspectives, and to the level of detail,
it claim to represent (Ross, 1977).

27
28 Chapter 3. Activity and Information Modeling

In addition, Booch et al. (1999); Fishwick (1995) and Schenck and

Wilson (1994) mean that the overall purpose of a model is to provide
a way to better understand a particular perspective of the thing being
modeled, such as the shape of a product represented in a 3D CAD-
model. Obviously, the model must be able to answer questions about,
e.g., the shape of a product in order to help an observer understand it.
Combining the reasoning about simplification and understanding, a
model can be described as an abstraction that must be able to answer
questions about the thing being modeled. The answers are only valid
within the perspective and level of detail the model claim to represent.
Hence, the following definition of a model is used:

Definition 3.1. M is a model of a system S if M can answer questions

about S with an accuracy of A.

(Marca and McGowan, 1988)

Consequently, a theory is a model because it describes some phenomena

in the real world, i.e. it can answer questions about the real world phe-
nomena such as the relationship between energy, mass and the speed
of light (e = mc2 ).
When a model is created it is called modeling or, in other words, mod-
eling is the action of creating a model.

3.2 Activity Modeling

As this thesis focus on information modeling, a reasonable question to

ask is - why activity modeling? The answer to that question will be
elaborated in this section. However, before this answer are provided it
is important to understand what the term activity mean.
3.2. Activity Modeling 29

3.2.1 Activity

Of course, the definitions of the term activity are numerous. Never-

theless, words like happening, changing, and action are usually part of
the definitions.
Both ISO/TC184/SC4 (1999) and Ross (1977) mean that an activity
is something happening in a system. A difference between the two def-
initions of an activity is that ISO/TC184/SC4 (1999) explicitly define
that the happening (a process) makes a change to the universe, whereas
Ross (1977) does not.
Nevertheless, the two definitions are essentially the same. When some-
thing is happening in a system there is actually a change to the system,
which is part of the universe. This may not be a visible change, but
merely a change of the state of the system.
Both definitions are similar to the definitions by ISO/IEC/JTC1/SC7
(2001) and ISO/TC184/SC4 (2002). However, one important difference
exists; ISO/IEC/JTC1/SC7 (2001) emphasize that an activity always
consumes time and can, thus, never be instantaneous. This clearly
separates the activity from an event, which is instantaneous.

Definition 3.2. An event is an instantaneous happening that have an

effect on the universe.

Yet another difference is that whereas ISO/TC184/SC4 (1999) place

an activity on an equality with a process, ISO/IEC/JTC1/SC7 (2001)
does not. ISO/IEC/JTC1/SC7 (2001) mean that a process is a set of
interrelated activities that transform an input to an output, cf. the
term transformation process as it is used by Hubka and Eder (1988).
Instead ISO/IEC/JTC1/SC7 (2001) uses the term action to define an
activity, meaning that an activity is a set of actions. American Heritage
(2000) define an action as the state of acting or doing, indicating that
an activity need some kind of active participation to make the change.
30 Chapter 3. Activity and Information Modeling

Definition 3.3. An action is the state of acting or doing.

(American Heritage, 2000)

Obviously, this indication limits the use of the term to describe changes
to the universe that are due to an active participation from some part,
e.g. humans or machines. This limitation makes the use of the term
activity more clear, as the purpose of this thesis only concern activities
that are part of a transformation process, cf. Chapter 4, which always
involve an active participation of some resource.
Following the reasoning above, in this thesis an activity will be re-
garded as something that consumes time while it makes a change to
the universe. The start and end of the activity are events, which may
be triggered by other events.

Definition 3.4. An activity is a set of actions that consumes time

while it makes a change to the universe.

Adapted from ISO/TC184/SC4 (1999)

and ISO/IEC/JTC1/SC7 (2001)

3.2.2 Rationale Behind the Use of Activity Mod-

eling

The rationale behind the use of activity modeling in this thesis is that
it exists a strong interrelationship between activities and information.
Activities, as they are considered in this thesis, use1 information while
they make a change to the universe.
In addition, as the activities change the universe they create informa-
tion that itself contribute to the change of the universe. This infor-
mation may be used by other activities. In fact, it should be used by,
1
Naturally, it is not an activity itself that uses and creates the information but
rather the resources that carry out the activity.
3.2. Activity Modeling 31

at least, one other activity. Otherwise the creation of the information

would have been a waste.
What, then, is the information used for in an activity? The answer
is simple and straight forward, the information is used for decision
making (Fagerström et al., 2002; Fagerström and Moestam-Ahlström,
2001). Hence, following from the previous paragraph, the creation of
information that is not used for decision making is a waste2 .
Obviously, in order to minimize the waste it is necessary to under-
stand what information that is needed in an activity. Consequently,
understanding the activity is a necessity. Activity models will aid in
the process of understanding an activity by representing the identified
activities and the flow of information between them.
Since an activity model captures the information flow between activities
it provides a requirements specification for an information model (Al-
Timimi and MacKrell, 1996). As a requirements specification it also
provides the scope for an information model.

3.2.3 Activity Model

Then, what are the requisites of an activity model? It is clear form

Definition 3.4 that the purpose of an activity is to make a change to
the universe. Hence, the ability to represent a change to the Universe
is a necessity for an activity model.
In most activity models this is done by describing the change as an
output of the activity. In a graphical presentation it is usually an
arrow going out of a box, where the arrow correspond to the output
and the box correspond to the activity. This can be seen in, e.g., the
Structured Analysis and Design Techniques (SADT) (Ross, 1977).
As in any design, activity modeling is a type of design, once it is un-
derstood what to accomplish it is needed to know and control how to
2
The term waste is used with the assumption that specific effort have been put
into create this particular information.
32 Chapter 3. Activity and Information Modeling

accomplish it (Ross and Schoman, 1977; Suh, 1990). This is not often
considered in most activity models. Nevertheless, an important capa-
bility of an activity model is the capability to describe the control of
how to achieve the outputs, the goals, of the activity.
In addition, it is sometimes important to describe the resources that
are used to create the outputs of an activity (ISO/TC184/SC4, 2002;
Marca and McGowan, 1988). Marca and McGowan (1988) mean that
resource can be classified in two different types of resources, resources
that are consumed or manipulated during an activity, and resources
that are not.
These four aspects of activity models are all representable in the SADT
as output, control, input, and mechanism respectively, cf. Figure 3.1
or a description of SADT by, e.g., Ross (1977). Many other activity
models does not include these aspects in their models, e.g. UML Ac-
tivity diagrams (Booch et al., 1999). The reason is the difference in
purpose of the activity models.

Control

Activity
Input Output

A0

Mechanism

Figure 3.1. Under control, an activity transforms its input into

output with its mechanism (Marca and McGowan, 1988).

Whereas SADT have the purpose of describing the activities and the
flow of things between the activities, other activity models, including
UML activity diagrams, tend to focus on the sequencing of activities
instead. Hence, for the purpose of this thesis the SADT is more suit-
able.
3.3. Information Modeling 33

3.3 Information Modeling

The central theme of this thesis is the modeling of information about

manufacturing processes. But what is information? And what is infor-
mation modeling?
Davenport and Prusak (1998) describe information as a message sent
to inform a receiver, and indeed, information is created to be communi-
cated. A similar interpretation of information is made by Kent (1978)
and Schenck and Wilson (1994). Schenck and Wilson (1994) even con-
sider the possibility of sender and receiver being the same, and that
storage of information is only a special case of communication. In addi-
tion, Schenck and Wilson (1994) mean that “information is knowledge
of ideas, facts and/or processes”.
However, the interpretation of a message, as it was intended by the
sender, can only be ensured if there is an agreement between the sender
and the receiver of how to interpret the message (Kent, 1978; Scheller,
1990; Schenck and Wilson, 1994). A base for such agreements, or rules
of interpretation, is the information model.

3.3.1 Data, Information, Knowledge and Compe-

tence

The term interpret seems to be vital in the description of information.

The meaning of interpret is to conceive the significance of something
(American Heritage, 2000), and this something is what is called data.
Kjellberg (1982); and Schenck and Wilson (1994) define data as being
signs or symbols that, based on the rules of interpretation, can repre-
sent information. A slightly different definition is made by Davenport
and Prusak (1998); and Holmer et al. (1990), who mean that data is
discrete facts about the real world. Despite the difference in the defini-
tion, the essence of data as being the raw material, building blocks, or
representation of information is a least common denominator. Hence,
the following definition of data is used:
34 Chapter 3. Activity and Information Modeling

Definition 3.5. Data are symbols which represent information for pro-
cessing purposes, based on implicit or explicit interpretation rules.

Adapted from Schenck and Wilson (1994)

Obviously, data itself has little or no meaning, and says nothing about
its own importance or irrelevance (Davenport and Prusak, 1998; Ig-
nizio, 1991; Scheller, 1990). Data is merely the representation of a
concept, and it is the concept that brings meaning to the data. That
is, when data is interpreted it is associated with a concept that has a
particular meaning for the receiver of the data. When the association
between the data and the concept is made the data is understood and
becomes information.
What, then, if the data is associated with another concept than the
originator intended? Is it still information? For simplification, in-
formation will here be considered as data interpreted in its original
meaning.
Definition 3.6. Information is data interpreted in its original meaning.

Definition 3.6 differ from the definition of information that Schenck and
Wilson (1994) uses. Schenck and Wilson (1994) mean that informa-
tion is knowledge, whereas Davenport and Prusak (1998); Hicks et al.
(2002); Holmer et al. (1990) mean that knowledge originates and is
applied in the mind of people. Indeed, knowledge is created through a
cognitive process when an individual, or group of individuals, interpret
and understand information, both formal3 and informal4 .
Hicks et al. (2002) call this process the knowledge inference process
and it results in the creation of knowledge elements. The knowledge
elements are merely perspectives of information, which depend on fac-
tors such as knowledge of a person, the role of a person in an orga-
nization, environment and goals (Hicks et al., 2002). The division of
3
Formal information is structured information that provides a context and mea-
sure so that the same knowledge may be inferred (Hicks et al., 2002).
4
Informal information is unstructured information, such as verbal, expressions
and memory information (Hicks et al., 2002).
3.3. Information Modeling 35

knowledge into process and elements is similar to how Davenport and

Prusak (1998) describe knowledge as being both process and stock. In
addition, both Davenport and Prusak (1998); and Hicks et al. (2002)
mean that the knowledge stock, or elements, is derived from informa-
tion as information is derived from data. Considering this discussion
the following definition of knowledge seem adequate:

Definition 3.7. Knowledge form the sum of experiences and informa-

tion a person have collected and more or less consciously structured for
its needs.

(Holmer et al., 1990)

The ability to use the acquired knowledge and information to make ap-
propriate decisions and actions is here called competence. Competence
is not only knowledge about how to make decisions and how to act,
but also include the will and drive to make a change, cf. Figure 3.2.
Bergman and Klefsjö (1998) describe this as possessing the right skills
and knowledge to perform the service. Without the competence, and
underlying knowledge, no good decisions and actions would be made.

Decision/Action

Competence

Knowledge
Understanding

Information
Context

Data

Figure 3.2. The relationship between data, information, knowledge

and competence.

Definition 3.8. Competence is the ability to use the acquired knowl-

edge to make appropriate decisions and actions.
36 Chapter 3. Activity and Information Modeling

3.3.2 Information Model and Information Model-

ing

For a company it is important that individuals, and groups of individ-

uals, create the same knowledge from the same information. However,
it may be impossible to create the same knowledge from the same in-
formation because of different pre-understanding. Similar knowledge
creation can only be assured if the individuals have access to formal
information, which means that the elements of information are struc-
tured, provide a specific context, measure, and rules of interpretation.
Structure, context, measure, and rules of interpretation are what the
information model provide.
From Definition 3.6 (definition of information) and Definition 3.1 (def-
inition of model) the term information model mean a model of how
data should be interpreted to information. What does this mean? To
interpret the data correctly, implicit or explicit interpretation rules are
needed. That is, rules to control how to interpret the data. An in-
formation model provides the explicit interpretation rules of data in
a formal way. A guide in the interpretation of an information model
is the two basic rules that must always be stated for an information
model (any model actually), namely the purpose of the model and the
viewpoint of the model. This distinguish the usage and the user of the
model, and supports a correct interpretation.
Schenck and Wilson (1994) uses a formal approach to describe the
interpretation of data to form information, letting I and D stand for
information and data respectively. Then let R be the set of explicit
interpretation rules that produce information from data. Then formally

R(D) → I (3.1)

mean that data is transformed into information by applying the inter-

pretation rules. The opposite is also possible, by applying the inverse
rules R−1 to information, data is produced. This is formally expressed
as
3.3. Information Modeling 37

R−1 (I) → D (3.2)

Furthermore, if R is invariant then information can be exchanged with-

out a loss. This is formally described as

R(R−1 (I)) → I (3.3)

This reasoning is important in explaining the purpose of the informa-

tion model and information modeling, as will be shown by introducing
the interpretation rules of a sender (indexed by s) and a receiver (in-
dexed by r) in the description. Then formally

Rr (R−1s (Is )) → Ir (3.4)

mean that the information of a sender is transformed to data, which

in turn is interpreted and transformed to information by the receiver.
However, Is = Ir only if R−1s is the inverse of Rr and, thus, Rs =
Rr . In other words, information can only be exchanged fully and with
preserved meaning if the rules of interpretation is the same for both
the sender and the receiver. The information model is a set of explicit
interpretation rules to ensure that the intended meaning of information
is always preserved.

Definition 3.9. An information model is a formal model of data and

its interpretation rules.

Schenck and Wilson (1994) distinguish between two different types of

information models, a conceptual and a concrete information model. A
conceptual information model is independent of any particular instan-
tiation method. That is, it has not been constrained by any limitations
imposed by an instantiation method. In contrast, the concrete informa-
tion model is developed with a particular instantiation method in mind
and, thus, constrained by the limitations of that particular method.
38 Chapter 3. Activity and Information Modeling

This thesis will mainly concern conceptual information models. The

rationale for using conceptual models is to limit the influence and con-
straints by having a particular instantiation method in mind. Such
influence would, of course, limit the usability of the result presented in
this thesis.
Finally, information modeling can be summarized by the following quo-
tation:

The ultimate goal of information modeling is to formulate

descriptions of the real world information so that it may be
processed and communicated efficiently without any knowl-
edge of its source and without making any assumptions.

(Schenck and Wilson, 1994)

3.3.3 Representation of Information Models

An information model can be represented by using different techniques,

such as the EXPRESS-G (Schenck and Wilson, 1994), the Unified Mod-
eling Language (UML) (Booch et al., 1999), the Entity-Relationship
(ER) (Chen, 1976), and the Nijssen’s Information Analysis Method (Ni-
jssen and Halpin, 1989), as well as the EXPRESS (ISO/TC184/SC4,
1994; Schenck and Wilson, 1994) and the DAPLEX (Shipman, 1981)
among others.
The different techniques can be divided into graphical (EXPRESS-G,
UML, ER, NIAM) and lexical (EXPRESS, DAPLEX) representation
techniques. Whereas a graphical technique utilizes symbols or icons to
represent the major items in a model a lexical technique uses words
and mathematical symbols (Schenck and Wilson, 1994). The strength
of a graphical representations is their ability to visualize the structure
of a model. In contrast, the strength of a lexical representation is their
ability to formally represent the details and constraints of a model, as
well as being computer processible.
3.3. Information Modeling 39

A model constraint is a particular type of property that put restrictions

on properties, relationships and entities as a whole. Two examples
of common constraints are the cardinality and the data type. These
constraints are so commonly used that they are usually possible to
represent in both lexical and graphical languages. In Example 3.1
an attribute salary is constrained to only represent values larger than
or equal to 1000. This type of constraint is usually only possible to
represent in lexical languages.
Example 3.1.
ENTITY Employed INTEGER;
salary : INTEGER;
WHERE
{salary >= 1000};
END TYPE;

In this thesis the EXPRESS-G and EXPRESS techniques have been

used for information modeling, cf. Schenck and Wilson (1994) for a
description of the basic syntax. The rationale behind this decision is
that EXPRESS-G and EXPRESS in combination provide the strengths
of being both graphical and lexical. This can be achieved because
EXPRESS-G is a sub-set of EXPRESS. In other words, what can be
represented in EXPRESS-G can also be represented in EXPRESS. Usu-
ally, available EXPRESS-based modeling tools utilize EXPRESS-G for
graphical modeling, but the output for computer processing purposes
is EXPRESS. In addition, it is usually possible to define details and
constraints by using EXPRESS in these tools.
40
Chapter 4

The Innovation Process: A

Collaborative Effort

The purpose of this chapter is to provide a definition of the innovation

process as the term is used in this thesis. Furthermore, an overview
of the innovation process, from the viewpoint of the research, is also
given.
From this viewpoint, four characteristics have been identified as the
core characteristics of the innovation process, namely (i) decision mak-
ing, (ii) information, (iii) design methods and (iv) collaboration. If
mastered, they will have a great and positive impact on the result of
the innovation process and the performance of the company. The or-
ganization in which this process is executed is called the innovation
system.

4.1 Innovation
In the late 1970s the Japanese automotive industry, assuming the en-
ergy crisis to continue, had made large investments in engine plants for
small four-cylinder engines (Womack et al., 1990) to cope with demand
for small cars. The drop of fuel prices in the beginning of the 1980s

41
42 Chapter 4. The Innovation Process

resulted in an unexpected increase in demand for large cars with more

power.
Instead of investing in new engine plants for V6-engines, the Japanese
companies developed four-cylinder engines with technical features, such
as fuel injection, four valves per cylinder, turbochargers and double
overhead camshafts. Non of these features were new in itself, the 1924
Bentley had double camshafts, but the way they were combined and,
most important, the way they were adapted in terms of manufactura-
bility were new.
This adaptation resulted in a much higher quality of each feature than
had been possible before. The increased quality enabled the new en-
gines, using the combination of features, to run as smoothly and with
as high reliability as engines without the features did.
Womack et al. (1990) end their example of the four cylinders motor em-
phasize the weaknesses of the engineering system of a mass-producer.
This weakness was exposed when the rest of the automotive industry
tried to add the same features to their four cylinders motors. It took,
for instance, GM four years to introduce the features and two more
years to refine the design so that the engines could run without any
drivability problems. Still, GM was only able to provide these engines
in a narrow range of GM cars.
It is clear, from the example above, that not only does the product de-
sign impose requirements and constraints on its manufacturing system,
but it is also driven and, perhaps more often, limited by the capabil-
ities of the same. The example also indicates that there is a strong
interdependency between the properties of the product and the capa-
bilities of its manufacturing system, which must be considered during
the process of bringing new products to the market.
What the Japanese automotive industry did was to understand the
need of the customer, it was more power not V6-engines they needed,
in order to create a new solution that fulfilled the needs without com-
promising the requirements on cost and quality. In addition, they were
more skilled in terms of understanding the interdependency between
4.1. Innovation 43

the product and its manufacturing system, i.e. that either one can
impose constraints on the other, and in terms of organizing the work
to deal with this interdependency.
This process of understanding the needs, creating a new solution and
providing the solution to the customers is the innovation process, what
Davenport (1993) describes as the introduction of something new. Sim-
ilarly, Cooper (2001); Hubka and Eder (1988), and Sohlenius (2000)
describe innovation as bringing new products to the market, with the
emphasis on bringing. It is clear that innovation does not involve the
continuous process of producing products, but rather the process of
bringing products to the market. In this thesis the following definition
of innovation will be used:

Definition 4.1. Innovation is the transformation of customer needs

into new products on the market, from idea until a stable manufactur-
ing process is established.

It is important to remember that innovation, as it is considered here,

involves the development and realization aspects on two design objects;
the development and realization of (i) products, and (ii) processes and
manufacturing system. Furthermore, innovation involves the activities
of bringing a product to the market, up and until a stable manufactur-
ing process is established.
In a general aspect innovation can be seen as a process that transforms,
among other things, ideas, raw material and equipment to descriptions
of products and their manufacturing system, as well as stable manufac-
turing processes, physical products and their physical manufacturing
system. That is, things, e.g. raw material, are inputs to a process,
which then transforms them and releases them as outputs, e.g. prod-
ucts, cf. Figure 4.1.

Process Output
Input [add value]

Figure 4.1. Input is being transformed to output in a process.

44 Chapter 4. The Innovation Process

Essential for this transformation is, as it is created and initiated by

humans to fulfill human needs, that value is being added as the input
is transformed to output (Hitomi, 1979; Hubka and Eder, 1988; Slack
et al., 1998; Sohlenius, 2000; Wu, 1992). The input is transformed to
satisfy the needs of the customers.
Hence, the following definition is used:

Definition 4.2. A transformation process transforms an input to an

output by adding values to satisfy previously declared needs.

Adapted from Hubka and Eder (1988)

Of course, for a transformation process to take place, it needs to be

carried out by someone or something, e.g. humans, machines and com-
puters. The humans, machines, computers or other resources that carry
out or participate in a transformation process are all part of a system,
called a transformation system (Hitomi, 1979; Hubka and Eder, 1988).

INPUTS Transformation Process OUTPUTS

[SYSTEM]

[ENVIRONMENT]

Figure 4.2. A transformation system transform inputs to outputs

(Hitomi, 1979).

Hitomi (1979) describe a transformation system as a system that “re-

ceives input from its environment, transforms them to outputs, and
releases the outputs to the environment”, cf. Figure 4.2. Wu (1992)
on the other hand do not explicitly describe a transformation system,
but his description of a system is similar. That is, it receives inputs
and delivers outputs.
In their description, Hubka and Eder (1988) decompose the transfor-
mation system into sub-systems. They mean that a transformation
4.1. Innovation 45

system consist of the human system, the technical system, the infor-
mation system, and the management and goal system. Hubka and
Eder (1988) also provide a clearer separation of the components of a
transformation system and its process, cf. Figure 4.3.

Execution System
Environment Env: Space, Time
Transformation
System
Management
Human Technical Information
&
System System System
Goal System

Feedback

Operand in Operand in
Transformation Process
existing state desired state

Figure 4.3. A transformation system rely on several sub-systems to

execute the transformation process (Hubka and Eder, 1988).

Accordingly, a transformation system can be defined as follows:

Definition 4.3. The sum of all elements and influences (and their
relationships among them and to their environment) that participate
in a transformation is collectively termed a transformation system.

(Hubka and Eder, 1988)

Hitomi (1979); Hubka and Eder (1988); and Wu (1992), all mean that
the transformation system encapsulates the transformation process.
That is, the process is carried out within the system. This view can be
applied on all levels of a transformation system, from the level of large
enterprises to machine tools.
In addition, with their reasoning, Hitomi (1979); Hubka and Eder
(1988); and Wu (1992) provide two important perspectives of trans-
formation, the process and the system, or function, perspective. De-
pending on the purpose, either perspective can be used to analyze a
transformation.
46 Chapter 4. The Innovation Process

4.2 Successful Innovation

As mentioned in Section 4.1, innovation is a particular instance of a
transformation process. It transforms ideas to products, which are
ready for the marketplace, and their corresponding manufacturing sys-
tem with stable manufacturing processes. Of course, companies that
make the best use of their innovation process will have an advantage
against their competitors. But what makes an innovation process suc-
cessful?
Cooper (2001) mean that there are two fundamental principles for suc-
cessful innovation, “doing the right projects” and “doing the projects
right”, effectiveness and efficiency respectively. This relates to making
the right decisions and act upon those decisions in the best possible
way. Thus, a good innovation process model must support the organi-
zation to make the best decisions and actions in all situations.
Naturally, skilled people have the necessary prerequisites to make bet-
ter decisions than less skilled people. However, independent of the level
of skill, people, and machines, involved in a decision making process
need information as a base for their decisions. This information need
to be correct, at the right level of detail, and available at the right time
(Fagerström and Moestam-Ahlström, 2001; McGrath, 1996).
Skilled people and information are, however, not enough to ensure a
good decision making process. What is missing is the decision criteria, a
guideline that supports the decision maker to make decisions that meet
its objectives (CEN/TC310, 2002; Fagerström and Moestam-Ahlström,
2001). Note that decision criteria are part of a method that describe a
structured way, for humans or machines, to create and use information
for decision making.

4.3 The Innovation Process

There are different ways in which an organization can coordinate and
organize its operations. The toll-gate model is an often used and suc-
4.3. The Innovation Process 47

cessful way to structure and organize the innovation process (Cooper,

2001; McGrath, 1996).
In the toll-gate model the innovation process is divided into discrete
and identifiable phases, or stages, with the purpose to gather and create
information to progress to the next toll-gate. At the toll-gate the crit-
ical characteristics of the project are reviewed. These characteristics
are judged against criteria to decide whether to (i) continue (go), (ii)
terminate (kill), (iii) hold, or (iv) redirect the project, cf. Figure 4.4.
Both Cooper (2001) and McGrath (1996) mean that the gates, in com-
bination with well defined objectives, are one of the keys for successful
product innovation.

Phase 0 Phase I Phase III Phase IV

Phase II
Concept Planning & Test & Product
Development
Evaluation Specification Evaluation Release

Stability in
Volume
Manufacturing

Phase Phase Phase Phase Phase

Review Review Review Review Review
(Redirect, (Redirect, (Redirect, (Redirect, (Redirect,
Go, No) Go, No) Go, No) Go, No) Go, No)

Figure 4.4. The phase review process funnel (McGrath, 1996).

The design and definition of the phases are usually specific to the par-
ticular organization or company. Pahl and Beitz (1996) have described
four phases, namely (i) the clarification of task, (ii) conceptual design,
(iii) embodiment design, and (iv) detail design. These phases, as de-
scribed by Pahl and Beitz (1996), have a product design focus and only
consider the development of the manufacturing system in peripheral.
48 Chapter 4. The Innovation Process

Hitomi (1979) and Sohlenius (1998) have similar phase descriptions.

The innovation process start with the develop product and production
phase, continues with the process planning phase, and ends with the
produce product phase. The main difference here is that Sohlenius
(1998) clearly state that development of production is part of innova-
tion, cf. Figure 4.5, and Hitomi (1979) does not. That is, the first
stage of Hitomi (1979) does not include development of production,
but merely define the development of a product.

Market Demand

Product Model
Knowledge

Develop Product Process

Tools Model
& Production Planning
System
A1

Order
Create Process
Plan Process Plan

A2
Material & Product
Components
Produce Product

A3
Manufacturing System
Waste

Engineering work System Tool Energy Work

Figure 4.5. The innovation process according to Sohlenius (1998).

A more detailed description is provided by Prasad (1996) where the

innovation process is divided into seven phases, (i) definition of objec-
tives, (ii) product planning, (iii) design, (iv) production planning, (v)
production, (vi) manufacturing and assembly, and (vii) delivery and
service. The three first phases correspond to the first phase of Hitomi
(1979) and Sohlenius (1998). The fourth phase correspond to second
of Hitomi (1979) and Sohlenius (1998). The fifth and sixth phases
of Prasad (1996) correspond to the third phase of Hitomi (1979) and
Sohlenius (1998). The seventh phase that Prasad (1996) describe must
4.3. The Innovation Process 49

be seen as out of the scope of the models that Hitomi (1979) and Sohle-
nius (1998) provide. It is also clear that service, as an activity, is out
of the scope of the innovation process.
Several other also tend to describe the innovation process in simi-
lar ways, e.g. Askin and Stanridge (1993); Cooper (2001); Hubka
and Eder (1988); ISO/TC184/SC4 (2001); ISO/TC184/SC5 (2002a,b);
Mȧrtensson (2000); McGrath (1996); Pugh (1998); Ullman (1992); Ul-
rich and Eppinger (2000); and Wu (1992). These descriptions of the
innovation process are also similar to the innovation process of several
companies, e.g. Carlsberg (1997); Ericsson (2001); and Scania (1998).
In Fagerström et al. (2002) a functional view of an innovation system
is presented. This view has been adapted1 to present the activities of
the innovation process, cf. Figur 4.6.
It is interesting to see that Fagerström et al. (2002) have put more em-
phasis on the development and realization of manufacturing systems
than usual. It is clear that the development of the product and the
development of the manufacturing system are interdependent, which
is symbolized by the open product model and the open manufactur-
ing system model. This interdependency between the two activities
consists of constraints that are imposed by one activity on the other.
Usually these two activities are carried out in collaboration involving
several different organizations from different companies.
If the Develop Manufacturing System activity is decomposed it consists,
schematically, of three activities, cf. Figure 4.7. These activities are (i)
Create Process Plan (A21), (ii) Create Manufacturing System Solution
(A22), and (iii) Validate Manufacturing System Solution (A23).
Naturally, this decomposition of activities can be argued. As this thesis
main theme is manufacturing processes in the application of manufac-
turing system development, the choice was to include the Create Pro-
cess Plan as a separate activity in the Develop Manufacturing System
activity.

1
The adaption have included changes according to comments made by SAAB
Automobile and Dario Aganovic.
 50

Product Manufacturing
Plan Model Strategy Model Customer Order
Open
Experience
Manufacturin
g
System
Existing Open Model
Product Develop Product
Models Product Model

ström et al. (2002).

A1
Manufacturin
Develop g Manufacturing
Knowledge
Manufacturing System System
Manufacturing System Model
System Models A2
Configured Product &
Manufacturing System Model
Implement
Material,
Manufacturing Status
Components,
System Model
and Modules
A3
Product Model Configure
Product &
Production
System
A4

Manufacturing
Ramp-Up
Product
A5
Waste
Simulation & Digital Simulation & Digital
Prototyping-Systems Human Prototyping-Systems Human Human
Resources Tools Resources Planning Systems Resources

Figure 4.6. Activities in the innovation process, adapted from Fager-

Chapter 4. The Innovation Process
4.3. The Innovation Process 51

Models &
Experience

Process Plan
Create Process
Knowledge Plan Manufacturing
Resource Model
A21
Create Open
Manufacturing
System Solution
Manufacturing
Manufacturing System Model
System Models A22
Validate
Manufacturing Manufacturing
System Solution System Model
A23

Human Resources &

Information Systems

Figure 4.7. Schematic view of activities in the develop manufactur-

ing system activity.

In addition, the Create Process Plan and the Create Manufacturing

System Solution activity are thought of as being interdependent. This
interdependency consists of the process plan and the manufacturing
resource model that are used to control respectively process, and it
indicates that the process plan and the manufacturing resources are
developed concurrently. It may also be that a new product is intro-
duced into an existing manufacturing system, i.e. that the manufactur-
ing resource model represent the manufacturing resources that already
exist in the manufacturing system. The process plan describe the plan
of how to manufacture a product, including selected resources or re-
quirements on resources, whereas the manufacturing resource model
describe the available resources or resources that are being developed.
This is clearly a different view than, e.g. Hitomi (1979); McGrath
(1996); and Sohlenius (1998) have. The main difference is that process
planning is not considered at all, or it is considered to take place when
52 Chapter 4. The Innovation Process

all manufacturing resources are available. That is, the manufacturing

resources only need to be selected and do not need to be developed.

4.3.1 The Create Process Plan Activity

Juran (1988) mean that a general process planning activity consists

of four activities. These activities are: (i) review goals, (ii) choose
process, (iii) provide facilities capable of meeting the goals, and (iv)
provide methods.
First, in the review goals activity the goals of process planning is re-
viewed to understand them and their attainability. The result of the
activity, Juran (1988) mean, is a set of attainable goals, which are of-
ten represented in terms of, e.g., manufacturing features, tolerances,
surface finish, and materials (Azari, 1990; Eversheim et al., 1991).
Second, in the choose process activity the process to conduct, manu-
facture, the product is chosen, or designed. The result of the activity
is a specification of economic and feasible processes. The specification
consists of sequenced processes that are assigned to fulfill one or more
attainable goals.
Third, in the provide facilities capable of meeting the goals activity
the objective is to provide facilities, manufacturing resources, that are
capable of meeting the attainable goals. This include the specification
of capability requirements as well as physically providing the facilities,
e.g. make or buy the facilities. The result is, naturally, the capable
facilities.
Finally, in the provide methods activity the methods that are needed
to control human resources, machine tools, and robots are developed
and documented. The result of the activity is information required by
the resources, e.g. machine tools and human resources, to perform the
process.
The description by Juran (1988) above is a general description of a
process planning activity and can be applied to explain the process
4.3. The Innovation Process 53

planning activity as it is described by Azari (1990); Curtis (1988);

Eversheim et al. (1997, 1991); Nielsen and Kjellberg (2000); and van
Houten (1991), as well as the activities in Figure 4.8.
The Prepare Product Model & Prepare Strategy (A211) activity clearly
corresponds to the more general review goals activity, and its attainable
goals are represented in the prepared product model. An additional
result of the activity is a process plan strategy model, which represent
the manufacturing strategy in an applied strategy considering the goals
and resources for a specific process plan. The strategy is used to control
the rest of the create-process-plan activities.
The Engineer Process Methods (A212) and Establish Sequence of Pro-
cesses (A213) together correspond to the choose process activity. The
result, a specification of economic and feasible processes, is represented
by the structure of processes.
The Specify Resource Requirements or Select Resources (A214) activ-
ity partly correspond to the provide facilities activity. The difference
is that the actual development and implementation of facilities, e.g.
plants and machine tools, are carried out in the Create Manufacturing
Solution (A22) activity, cf. Figure 4.7. Instead of capable facilities, the
activity result in a preliminary process plan that specify requirements
on facilities, types of facilities, or the actual facilities.
The Validate Process Plan & Create Control Information (A215) activ-
ity partly correspond to the provide methods activity. The difference is
that this activity emphasize the importance of validating the process
plan before creating the control information, represented by the process
plan.
To summarize, the process plan activity is an activity where the prod-
uct requirements are interpreted and translated to manufacturing re-
quirements. That is, the language that are used to define the design
of a product is translated to the language that are used to define the
manufacturing of the same product. This may be done at a macro
or micro level of planning, but the principles of interpreting the prod-
uct requirements and translate these to manufacturing requirements
 54

Experience &
Manufacturing Process Plan Manufacturing
Product Model Strategy Model Resource Model
Strategy Model

Prepare Product
Model & Develop
Knowledge
Strategy
A211 Bill of Processes

Engineer
Process Methods
Structure of
A212 Processes
Prepared
Product Model Establish
Structure of
Processes Preliminary
A213 Process Plan
Specify
Resource
Requirements or
Select
Resources Process Plan
A214

Validate Process
Plan & Create
Control
Information
A215

Figure 4.8. Activities in the create process plan activity.

Human Resources &
Information Systems
Chapter 4. The Innovation Process
4.4. Organization of the Activities in the Innovation Process 55

remains.

4.4 Organization of the Activities in the

Innovation Process

As mentioned in Section 4.3, the innovation process does not involve

only one organization, and activities are often carried out in parallel.
The degree of parallelism of the activities is, to a large extent, affected
by the dependencies between the activities.

C E

A B

D F

Figure 4.9. Activities in the innovation process, adapted from Ep-

pinger et al. (1994) and Tátray (1998).

For instance, in Figure 4.9 activity B is dependent on the result of ac-

tivity A and, thus, A must precede B. Activities C and D, on the other
hand, have no dependency and can, thus, be carried out in parallel
without any interaction. An interdependency is much more complex,
activities E and F in Figure 4.9, and must be carried out incremen-
tally. An example of an interdependency is the dependencies between
the activities Develop product (A1) and Develop Manufacturing System
(A2) in Figure 4.10.
In general terms, the dependency between the develop product and
the develop manufacturing system activities originates from decision
making. A decision making that impose constraints not only on the
activity in which the decision was made, but also on the dependent
activity. In Figure 4.10 the constraints are implicitly and/or explicitly
represented in the Open Product Model and the Open Manufacturing
System Model.
56 Chapter 4. The Innovation Process

Open
Manufacturing
System Model
Open
Develop Product
Product Model
A1

Develop Mfg.
System
A2

Figure 4.10. Dependencies between the Develop Product and De-

velop manufacturing system activities.

The more activities that are involved in an interdependency, the more

complex are the information flow between the activities. For instance,
if four activities are coupled, e.g. activities A, B, C, and D there will
be twelve different communication paths that need to be maintained,
cf. Table 4.1.
A→B B→A C→A D→A
A→C B→C C→B D→B
A→D B→D C→D D→C
Table 4.1. Communication paths between the coupled activities A,
B, C, and D (McGrath, 1996).

Typically, this intense information exchange between activities occur

for activities organized according to the concurrent engineering philos-
ophy (Fagerström et al., 2002).

4.4.1 Concurrent Engineering

The term concurrent engineering refers to simultaneously consider more

than one aspect of a system during its design phase (Krause et al., 1993;
Liker et al., 1995; McGrath, 1996; Sohlenius, 1992), cf. Figure 4.11.
Like lean production, concurrent engineering is mainly an invention by
4.5. Managing Information in the Innovation Process 57

Toyota, who began moving to simultaneous development in the 1960s

(Liker et al., 1995).

Definition 4.4. Concurrent engineering is the simultaneous consider-

ation of more than one aspect of a system during its design phase.

Figure 4.11. Concurrent engineering at Toyota (Liker et al., 1995).

The effect of concurrent engineering on the design of a system is de-

creased innovation process lead-time and increased product quality
(Liker et al., 1995; Sobek et al., 1998; Sohlenius, 1992; Womack et al.,
1990). The cause for the effect is that problems are identified and high-
lighted earlier in the design phase. These problems have a base in a
conflict of interests between different objectives and functional areas
(Sobek et al., 1998). The conflict is then solved by a compromise be-
tween the conflicting functional interests. An engineer at Toyota put
this into words by meaning that “lots of conflict” makes a good car
(Sobek et al., 1998).

4.5 Managing Information in the Innova-

tion Process
As mentioned in Section 4.1, a key to a successful innovation process
is good decision making. Good decision making is dependent on the
58 Chapter 4. The Innovation Process

availability of the right information at the right time. Thus, managing

information is vital for the success of the innovation process.
This is especially true for an organization that have organized their
innovation process according to the concurrent engineering philosophy.
The reason is, as Kimura et al. (1992) describe it, that concurrent
engineering implies information sharing. This view is also shared by
Brunnermeier and Martin (1999) and Fagerström et al. (2002).
How then, can an effective and efficient information sharing be estab-
lished? Naturally, there are different approaches to solve this problem.
In Japanese automotive industry, for instance, a black-box sourcing
is used for subsystem suppliers (Liker et al., 1995). This approach
reduces the need for communication by specifying clear and stable in-
terface requirements along with the subsystem requirements. Conse-
quently, the subsystem supplier can rely on the requirements and work
independently without any unnecessary communication. Thus, using
a suitable method for the innovation process can minimize the need
for information sharing. Nevertheless, even companies using black-box
sourcing need to share information across functional boarders.
Information seems to be a common denominator that binds different or-
ganizations together. However, the different organizations usually use
different terminology or have different definitions for the same terms.
The difference in terminology complicates the communication process,
independent of if it is between humans, computers, or a mix of the
both. To overcome these difficulties common definitions need to be
agreed upon. Such agreements are defined and documented in an in-
formation model, cf. Section 3.3.

4.6 Information Models in the Innovation

Process

As ideas are transformed to ready-for-the-market products, informa-

tion about, and rationale behind, the design of the product and its
4.6. Information Models in the Innovation Process 59

manufacturing system is created. This information must, in order to

support the innovation process, represent several different aspects of
the product and its manufacturing system throughout their life cycles
(Kimura, 1993; Krause et al., 1993).
In addition to different aspects, the product and its manufacturing sys-
tem can also be divided in three main domains of information. The
three domains hold information about the product, the manufacturing
process, and the manufacturing resource respectively, cf. Figure 4.12.
This view is, to some extent, also shared by, e.g. Azari (1990); Ev-
ersheim et al. (1991); Eversheim and Westekemper (2001); Johansson
(2001); Kulvatunyou and Wysk (2000); Onosato and Iwata (1993); Ray
(1989) and Young et al. (2000). The three domains can also be iden-
tified in the structure of ISO 10303-214 (ISO/TC184/SC4, 2001) and
other standards.

Process

Product Resource

Figure 4.12. Three main domains of information: the product, the

manufacturing process and the manufacturing resource domains.

On the one hand, each domain need to capture its own design informa-
tion and rationale in its own information model. On the other hand, as
the different domains interact, it is important that design information
about, and design rationale behind, the interaction can be captured as
well (Krause et al., 1993).
The interaction between the different types of models could provide
a description of the products, how they should be manufactured, and
what manufacturing resources that should be used. This would provide
60 Chapter 4. The Innovation Process

an information platform upon which several different computer based

tools to support the innovation process can be built.

4.6.1 The Product Model

A product model represents all relevant information about a product

throughout its life cycle (Kjellberg, 1982; Krause et al., 1993). The
phrase all relevant information implies that the content of a product
model may differ. In fact, whereas Kjellberg (1982) only include infor-
mation describing the product itself in the concept of a product model,
Krause et al. (1993) also include information describing how and with
what resources the product is manufactured. In this thesis, the view
of the former is applied.
This is done to clearly separate different types of information for easier
interpretation and better understanding. Nevertheless, different orga-
nizations still consider different information about their product being
of different relevance. The relevance of the information about a product
depend on the scope and methods of concerned organizations.
Consequently, several different aspects in several different life cycle
stages must be representable in a product model. In general the as-
pects range from abstract, why, to concrete, how, representations of
the product, a view shared by Andreasen (1991); Krause et al. (1993);
Pahl and Beitz (1996); Ross and Schoman (1977); Suh (1990); and Ul-
rich and Eppinger (2000). These aspects can be grouped in four main
categories:

• requirements,
• functions,
• concepts, and
• concrete solutions.

In addition, Andreasen (1991); Ross and Schoman (1977); and Suh

(1990) mean that a product can be described in more or less detail.
4.6. Information Models in the Innovation Process 61

That is, each aspect may describe the product from low to high level
of detailing.
How, then, does this affect the product model? It affects the product
model in terms of general requirements of what type of information
the product model must be able to represent, and to what detailing
level. Of course, this is related to the questions the model is supposed
to answer, which, in turn, is related to the scope and methods of the
organization.

Different Types of Product Models

As already mentioned, in order to support different scopes and meth-

ods, different aspects of a product must be represented in a product
model. These aspects can be represented in different types of prod-
uct models. Krause et al. (1993) have identified an incomplete list of
different types of product models:

• structure-oriented product models,

• geometry-oriented product models,

• feature-oriented product models,

• knowledge-based product models, and

• integrated product models.

Structure-oriented product models represent some aspects of a product

from a product breakdown perspective Krause et al. (1993). For in-
stance, a product can be broken down in functions and components
(Hubka and Eder, 1988; Krause et al., 1993; Pahl and Beitz, 1996), in
terms of, e.g. function trees, bill-of-materials, and assembly structures.
Geometry-oriented product models represent the shape of a product
(Kjellberg, 1982; Krause et al., 1993). Naturally the shape of a prod-
uct can be described in different ways depending on the purpose of
62 Chapter 4. The Innovation Process

the description. Kjellberg (1982); Krause et al. (1993); and Salomons

(1995) have identified wire frame, surface, solid, and hybrid models. In
addition, Kjellberg (1982) have identified graph and lamina models.
Feature-oriented product models represent a product in terms of fea-
tures, cf. the next section for further discussion on feature-oriented
product models.
Knowledge-based product models formally represent accumulated knowl-
edge about a product (Krause et al., 1993). The accumulated knowl-
edge can then be used to guide the design and constrain the design
space (Holmer et al., 1990; Krause et al., 1993; McMahon and Browne,
1998). Consequently, a knowledge-based product model is used to guide
and control a designer in her, or his, use of other type of product mod-
els, rather than representing some aspect of a product itself.
Integrated product models represent a product by combining differ-
ent types of product models (Krause et al., 1993). An example of
an integrated product model is ISO 10303-214 (STEP AP214), which
combine structure-, geometry-, and feature-oriented product models
(ISO/TC184/SC4, 2001).
Of course, there are additional types of models that could be consid-
ered, e.g. material-oriented product models and kinematic-oriented
product models.

Feature-Oriented Product Models

As mentioned above, feature-oriented product models represent the

product in terms of features. A feature, though, is defined in sev-
eral different ways. The essence, however, is similar, describing a fea-
ture as something that provides engineering meaning, or application-
dependent semantics, to a product.
Eversheim et al. (1991); Krause et al. (1993); and Wingȧrd (1991) mean
that a feature is a form feature, which represent a shape, in combination
with application-dependent semantics. This definition introduce two
aspects of a feature, the shape aspect and the application-dependent
4.6. Information Models in the Innovation Process 63

semantic aspect. That is, the application-dependent semantics provide

an user-oriented view of the application-independent geometric shape
(Dürr and Schramm, 1997; Nyqvist and Nielsen, 2001).
Brown et al. (1992); McMahon and Browne (1998); and Salomons
(1995) extend the definition of a feature to include any information
that is useful to reason about the function, behavior, performance, and
manufacture of a product. In addition, they mean that this informa-
tion need not necessary be associated with some shape of a product.
Instead it can be associated with some other application-independent
information, such as a function of a product.
Consequently, a feature consists of two parts: (i) a part that is appli-
cation independent, and (ii) a part that is application dependent. This
provides a strong concept where different engineering applications can
share application-independent information and customize it for a par-
ticular purpose by adding application-dependent semantics.
In this thesis the following definition of a feature will be used, pro-
vided that what is perceived is represented by both an application-
independent and application-dependent part:

Definition 4.5. A feature is a perceived geometric element, functional

element, or property of an object useful in understanding the function,
behavior, performance, or manufacture of that object.

Adapted from Brown et al. (1992)

4.6.2 The Manufacturing Process Model

A Manufacturing process model represents all relevant information

about manufacturing processes throughout their life cycle. Here a
manufacturing process is considered to be a process that transforms
a physical object from one state to another.

Definition 4.6. A manufacturing process is a process that transforms

a physical object from one state to another.
64 Chapter 4. The Innovation Process

Then, what is a process? ISO/IEC/JTC1/SC7 (2001) describe a pro-

cess as a set of interrelated activities that transform inputs to outputs.
This is what Hitomi (1979); and Hubka and Eder (1988) call a trans-
formation process. American Heritage (2000) and Juran (1988) add
goal orientation, meaning that a process is a set of actions directed to
the achievement of a goal. Here the following definition is used:
Definition 4.7. A process is a systematic series of actions directed to
the achievement of a goal.

(Juran, 1988)

Consequently, a manufacturing process is a systematic series of actions

directed to the achievement of a goal. In this case the goal is to trans-
form inputs to outputs, i.e. transform raw material to finished products
and subassemblies.
Kulvatunyou and Wysk (2000) mean that information necessary to de-
scribe the transformation is represented by the manufacturing process
model. This include information that specify operations, resources, and
skills. A view that Kulvatunyou and Wysk (2000) share with Hubka
and Eder (1988); Johansson (2001); Nielsen and Kjellberg (2000); and
Tönschoff and Zwick (1998).
Whereas Hubka and Eder (1988); Johansson (2001); Kulvatunyou and
Wysk (2000); and Nielsen and Kjellberg (2000) clearly separates the
process representation from the resource representation, Tönschoff and
Zwick (1998) does not. Tönschoff and Zwick (1998) mean that the
manufacturing resources are represented by the process model as well.
This view is not representative for the view represented by the work of
this thesis. Here there is a clear separation between product, process,
and resource (PPR) data.
Nevertheless, Tönschoff and Zwick (1998) emphasize other aspects of
the process model that are important. These aspects, which are also
identified by Hubka and Eder (1988); Johansson (2001); Kulvatunyou
and Wysk (2000); Nielsen and Kjellberg (2000); and Ray (1989), in-
clude:
4.6. Information Models in the Innovation Process 65

• process structures - structural relationships between processes,

e.g. decomposition, alternative, and parallel,

• process sequences - sequential relationships between processes,

and

• process parameters - parameters and properties of processes, e.g.

process time, process temperature, and feed rate.

In addition, Tönschoff and Zwick (1998) mean that this information

is product independent. That is, the type of product does not change
how processes are represented. Having separated the representation of
products and processes, thus, makes it possible to reuse the represen-
tation of processes for many types of products. For the same reason,
it is important that the representation of processes and resources are
separated as well.

4.6.3 The Manufacturing Resource Model

Similar to a product model, cf. Section 4.6.1, a manufacturing resource

model represents all relevant information about a manufacturing re-
source throughout its life cycle. The type of information is, in general,
the same as for the product. Johansson (2001) mean that the same
model can be used for the development of both products and manufac-
turing resources.
This is supported by Hubka and Eder (1988) that draw no distinction
between different types of technical systems. That is, a car, which is
most often seen as a product, is a technical system and so is a machine
tool, which is most often seen as a resource.
However, both a car and a machine tool can be considered being both a
product and a resource. If the product is not needed, i.e. is not useful
(a resource) for someone, it will not be a successful product. Hence,
product and resource seem to be two different viewpoints of the same
object.
66 Chapter 4. The Innovation Process

Usually the different viewpoints are related to the manufacturer/vendor

of the product, and user of the resource. Consequently, the same ob-
ject, e.g. a car, is a product from a manufacturer/vendor viewpoint
and a resource from a user viewpoint.

Definition 4.8. A product is an object intended to be sold to, or

leased by, a customer.

Definition 4.9. A resource is an object that is used, or consumed, to

fulfill some need of the user.

Hence, for the purpose of manufacturing, categories of resources include

material, equipment, humans, and information. A view that, to some
extent, is shared with Hubka and Eder (1988); Kulvatunyou and Wysk
(2000); and Ray (1989).
To conclude this reasoning, in this thesis only one model will be consid-
ered to represent information about both products and manufacturing
respurces. That is, the product model, cf. Section 4.6.1.
However, as different types of information is considered important in
the different views, the information that is important in the resource
view will be elaborated further here.
In contrast to the product view information that are used to support
decisions concerning the development and realization of an object, the
resource view information is used to support decisions concerning the
operation and support of the object, e.g. capabilities, performance,
operative expenses, and costs of maintenance.
In addition, the hierarchical nature of a manufacturing system is of-
ten represented in structures with particular naming conventions for
each level of the hierarchy. Formalized manufacturing system struc-
ture models are provided by the National Institute of Standards and
Technology (NIST) and the International Organization of Standardiza-
tion (ISO) respectively, cf. Figure 4.13. Both these models can be used
to classify and structure the manufacturing resource model (Johansson,
2001).
4.6. Information Models in the Innovation Process 67

Facility Enterprise

Shop Facility/Plant

Cell Section/Area

Workstation Cell

Equipment Station

Equipment

Figure 4.13. The NIST-model, left, and the ISO-model, right,

(Bauer et al., 1991).

Capability Representation

American Heritage (2000) mean that capability is the quality of being

capable. Similarly, Bergman and Klefsjö (1998); and Curtis (1988)
mean that capability is the ability of a machine, or process, to repeat
and hold tolerances. The three can be summarized by Juran (1988)
who define capability as the inherent ability to perform. Hence, the
following definition is used:

Definition 4.10. Capability is the inherent ability to deliver perfor-

mance.

Adapted from Juran (1988)

Notable is that inherent ability to deliver performance indicate that

there is a difference between capability and performance. Juran (1988)
mean that the difference is that capability is what something could do
whereas performance is what something did do. Naturally, the per-
formance of, e.g., a machine tool depend on such things as operator,
variance in air temperature, variance in material properties of work-
piece, and tool that is used.
68 Chapter 4. The Innovation Process

There are usually two types of capability discussed in literature, process

and machine capability. Sometimes they refer to different capabilities
and sometimes they refer to the same. The confusion certainly stem
from a careless use, or misunderstanding, of the term process for both
manufacturing processes and manufacturing resources. For instance,
Bergman and Klefsjö (1998); and Juran and Gryna (1988) do make
a difference between process and machine capability whereas Curtis
(1988) does not.
Bergman and Klefsjö (1998); and Juran and Gryna (1988) mean that
process capability refers to the ability to perform over a long period
of time considering normal changes in workers, materials, and other
process conditions. Machine capability, on the other hand, is defined
by Bergman and Klefsjö (1998); and Juran and Gryna (1988) as the
ability to perform considering one set of process conditions, e.g. one
operator and no changes in material properties.
Definition 4.11. Machine capability refers to the reproducibility un-
der one set of process conditions.

(Juran and Gryna, 1988)

Definition 4.12. Process capability refers to the reproducibility over
a long period of time with normal changes in workers, material, and
other process conditions.

(Juran and Gryna, 1988)

Although agreeing with the differentiation of machine and process ca-

pability, for the purpose of this thesis the process is not considered to
have any capability itself, cf. Figure 4.14. It is the resources that are
used to carry out the process that have capabilities to perform the pro-
cess and achieve the goals that are set. In addition, the method that
are used to control how the process is carried out is also considered to
have capabilities.
Usually, capability is represented in mathematical and numerical mod-
els (Kulvatunyou and Wysk, 2000). The mathematical representation
4.6. Information Models in the Innovation Process 69

Capability

Have Have
Have Indirectly

Process
Controls
Executes
Indirectly

Resource Controls Method

Figure 4.14. The process capability is determined by the executing

resources and the method that controls the execution.

is often in terms of 6 σ, or six standard deviations (Juran, 1988), but

can also be represented by other mathematical models such as the loss
function (Taguchi et al., 1989). Several other capability representa-
tions, both mathematical and non mathematical, have been identified
by Algeo (1994), e.g. machine tool capability model by Gindy and
Ratchev (1992).
However, the mathematical and numerical models does not say if a
manufacturing resource is able to make, e.g., a particular shape or a
particular joint. A process engineer has to select manufacturing re-
sources both on the assumption on what they can perform, e.g. a hole,
and how well they can perform, e.g. in terms of 6 σ. This could be
considered to be a higher level of capability representation related to
shape and functional aspects of the manufacturing resource capability,
and would support the process engineer in the selection process.
In addition, and perhaps more important, it would also provide a mean
for early feedback on how to make the detailed design of a product.
For instance, in the early phase of product development it might only
70 Chapter 4. The Innovation Process

be decided that there is a need for a joint with some characteristics on

strength, surface finish, and so on. When manufacturing resources with
the capability of joining are considered, aspects of detailed design, such
as the shape aspect affect of clinching or spot welding, is highlighted
and can easily be considered as well, cf. Figure 4.15.

Figure 4.15. The detailed design of a product will be affected dif-

ferently when using clinching and spot welding.
Chapter 5

Information Requirements
for Process Planning

The purpose of this chapter is to present and discuss requirements

for a process model that support the create process plan activity, cf.
Section 4.3.1. The requirements have been identified in case stud-
ies at Volvo Car Corporation, cf. Appendix C, ABB Body-in-White
(ABB BiW), cf. Appendix D, and Scania. and literature studies, e.g.
Al-Timimi and MacKrell (1996); Andreasen (1991); Boothroyd et al.
(2002); Hubka and Eder (1988); ISO/TC184/SC4 (1996, 2000, 2001);
Slack et al. (1998); Suh (2000); and Wu (1992).

5.1 Hypotheses

Several different process information models exists today, including in-

ternational standards, standards under development, company specific
models, and computer application specific models. They all claim to
have different scopes and intention to justify their individual existence,
and, indeed, many have different scope and intention. However, there
are several components that are similar between the different process
information models.

71
72 Chapter 5. Information Requirements for Process Planning

The similarities between the models are, in general, the way products
and manufacturing resources are related to processes, cf. Figure 4.3.
That is, products are seen as inputs and outputs of processes, and man-
ufacturing resources are seen as executers of the processes. In addition,
the way process objects are related to other process objects are similar,
i.e. there is also a similarity in the process plan structure. Hence, it
seems that there are generic information concepts that are common
between the different process models and that there are specific infor-
mation concepts that are not.
A generic information concept is an information concept that are generic
within the scope of the information model whereas a specific informa-
tion concept add specific meaning within the scope of the information
model. For instance, the term turning process, which is commonly used
in information models for process planning, references two information
concepts, the concept for turning and the concept for process. The
turning concept is a specific information concept because it adds spe-
cific meaning to the generic information concept of a process, in this
case which type of process it is.
The reasoning about the generic and specific information concepts came
from an idea of how to develop information models that will not be
obsolete as soon as, e.g. a new type of process is developed or if not all
types of processes where though of when developing the model. The
idea is to use the generic information concepts as the building blocks
to create an information model that can remain stable over time. The
specific information concepts add specific semantical meaning to the
generic information concepts. Whereas the domain and structure of the
generic information concepts are to be stable the domain and structure
of specific semantical concepts may vary.
The specific semantical meaning to a generic information concept is
then set when an information model is instantiated. If a turning pro-
cess, for instance, are to be represented in an instantiated process in-
formation model then the representation of the generic information
concept for a process is used and added to this generic information
concept is the specific information concept for turning, which define in
5.1. Hypotheses 73

the instantiated model that it is a turning process. The same generic

information concepts would be used to represent a milling process and
the specific information concept for milling would define that it is a
milling process. Naturally, the information concepts for representing a
specific information concepts is a generic information concept.
This idea have resulted in the following hypothesis:

Hypothesis 5.1. Any information model is, within the scope of its
generic information concepts, made independent of the information it
represents by (i) separating generic and specific information concepts,
and (ii) provide generic information concepts for defining specific in-
formation concepts.

This is thought of to affect the longevity of any information model

positively. Are there complementary ways to increase the longevity?
Thinking about this question ended in thoughts about product modu-
larization.
In product modularization there are a number of module drivers that
have been identified by, e.g., Erixon (1998). Some of these module
drivers are carry over, functional separation, technology development,
variety, and quality. Companies want to carry over developed modules
between existing product families and to the next generation, they may
plan to introduce new technology in to an existing product family, and
so on.
In fact, these module drivers, and the reasons behind them, seem rel-
evant for information modeling too. For instance, if an organization
change their information requirements for information about employ-
ees then only that module of the information model must be changed.
Consequently, only that part of the information system must change
too. Different departments of the organization may share information
modules, but may also have specific information modules for their spe-
cific needs.
74 Chapter 5. Information Requirements for Process Planning

This idea of modularization have resulted in the following hypothesis:

Hypothesis 5.2. Modularization will have the same effect on infor-

mation models as on products.

This effect is reuse of information concepts, i.e. carry over, possibil-

ity to update information concepts without effecting other information
concepts, i.e. technology development and functional separation, and
quality, e.g. that the different information-concepts modules can be
tested separately.

5.2 The PPR Information Model

The two hypotheses, Hypothesis 5.1 and Hypothesis 5.2 have been the
base for the development of the information model in this thesis, the
product-process-resource (PPR) information model. In Figure 5.1 is
a schematic illustration of the (PPR) information model that consist
of three modules, the product module, the process plan core model
module, and the manufacturing resource module.

I I
n n
t t
e e
Process plan Manufacturing
Product r core r
resource
f f
a a
c c
e e

Figure 5.1. The product-process-resource information model with

its process plan core.

The purpose of the process plan core model is to represent information

that describe the process structure independent of any other informa-
tion, e.g. product information, manufacturing resource information,
documents, and properties. This is the generic information concepts
5.3. Requirements on Process Plan Core Model 75

related to process planning. The differences between different types of

process plans, e.g. macro and micro, and different types of processes,
e.g. spot welding and turning, are defined by the information that are
related to the process plan core model. Naturally, the interfaces in
Figure 5.1 can be extended to include interfaces for external reference
data libraries, document information, property information, etcetera.

5.3 Requirements on Process Plan Core

Model

The main purpose of the process plan core model is to represent in-
formation that solely describe processes and their structure for process
planning purposes. This include information to identify the manu-
facturing process necessary to manufacture a particular product, how
these processes are structured and how they are defined.

5.3.1 Representation of Process Plan

Perhaps the most basic requirement on a process model is the ability

to identify a set of processes that describe how a particular product is,
or should be, manufactured. The structured set of processes will here
be called a process plan, cf. Figure 5.2.

STRING
plan_identifier

process_plan

Figure 5.2. The representation of a process plan.

A process plan have a unique identity which distinguish it from other

process plans. This is represented by the plan identifier attribute in
Figure 5.2.
76 Chapter 5. Information Requirements for Process Planning

In addition, a process plan may have relationships to other process

plans. Typically these relationships indicate that a process plan may be
used as an alternative for another, or that a process plan is substituted
by another.

STRING

relation_type
relating

plan_relationship process_plan
related

Figure 5.3. The representation of a process plan relationship.

Figure 5.3 show how a relationship between two process plan objects is
represented. The attribute relation type specify the type of relationship
between two process plan objects, i.e. alternative and substitution. The
related specifies the process plan that are used as an alternative or is a
substitute for the process plan specified by the relating.
Naturally, a process plan also have a relationship to the product, which
manufacturing processes the process plan identify. However, this rela-
tionship is not part of the process plan core model and will be discussed
in Section 5.4.15.

5.3.2 Representation of Process Plan Version

The rationale behind the requirement for a process plan version is that
of keeping track of changes to a process plan. Although it is not the
only way to keep track of changes it is the most commonly used and
the process plan version mechanism, cf. Figure 5.4, may be used with
other ways to keep track of changes, e.g. by effectivity.
Figure 5.4 show the representation of a process plan version and its
relation to a process plan. Each process plan version must be associated
with a particular process plan, the associated plan relation. The inverse
(INV) associated version relation indicates that a process plan may not
exist without having at least one version specifying it as the associated
5.3. Requirements on Process Plan Core Model 77

STRING
plan_identifier version_identifier

associated_plan
process_plan process_plan_version
(INV) associated_version S[1:?]

Figure 5.4. The representation of a process plan and its version.

plan. Furthermore, the unique identification of a particular process plan

version is maintained by the use of the attribute version identifier.
In order to relate a process plan version to its successor and alter-
natives the process plan version relationship mechanism in Figure 5.5
was added. The mechanism has a similar functionality as the process
plan relationship mechanism. That is, the semantical meaning of the
relationship is defined by the attribute relation type, and the related
specifies the predecessor version of the relating version.

STRING

relation_type
relating

process_plan_version version_relationship
related

Figure 5.5. The representation of a process plan version relationship.

Typically, the attribute relation type can take the values sequence and
alternative. The value sequence indicate that the related version is the
successor of the relating version, whereas the value alternative indicate
that the related version may be used as an alternative for the relating
version. In addition, the values derivation and hierarchy may also be
used. The value derivation implies that the related version is based on
the relating version. The value hierarchy is used to indicate a hierar-
chy between versions, e.g. the relationship between version 1 and its
revision, revision 1.1.
78 Chapter 5. Information Requirements for Process Planning

5.3.3 Representation of Processes in a Process Plan

To be useful, a set of processes must be identifiable. The identification

of a set of processes is provided, as mentioned, by the process plan
mechanism. Each process, in a particular set of processes, identify a
particular version of a particular process plan to which all processes in
the set belong, cf. Figure 5.6.

process_plan_version

plan

process_identifier
STRING process

Figure 5.6. The representation of a process in a process plan version.

The plan attribute identify the particular process plan version to which
the process belong. Each process also have its own identification rep-
resented by the attribute process identifier.

5.3.4 Reuse of Processes in Process Plans

An important requirement for a process model is the ability to reuse

the definition of a process at different places in a process plan or in
different process plans. There are at least two aspects of the reuse of
the definition of a process.
First, library of available processes can be used to control the design of
a product. That is, by defining a set of standardized processes, a com-
pany may use these definitions to decide if a particular product feature
is possible to manufacture in the existing manufacturing system.
Second, manufacturing companies with many manufacturing sites may
develop a generalized process plan that describe how a particular prod-
uct should be manufactured, e.g. in terms of process sequence, and
manufacturing resources. If the definition of a process can be reused
5.3. Requirements on Process Plan Core Model 79

the generalized process plan may be adapted to fit a particular manu-

facturing site without creating a new definition.
The ability to reuse the definition of a process in a process plan is
provided by separating the process and its definition in the process
core model. A process is, thus, represented by a non reusable chunk of
information, the process, and a reusable chunk of information, the pro-
cess definition, cf. Figure 5.7. The process and its definition together
provide the information for a particular process in a particular process
plan.

plan definition
process_plan_version process process_definition

Figure 5.7. The representation of a process definition in a process

plan.

Figure 5.8 show information related to a process definition. The at-

tribute definition identifier represents the identifier of a particular pro-
cess definition. In addition, the type, i.e. class, of process that is
defined is also important information to represent. In fact, so impor-
tant that each process definition must have a classification associated
with it. However, this information has not been considered to be in
the process core model and, thus, it will not be discussed here but in
Section 5.4.3.

definition_identifier
process_definition STRING

Figure 5.8. The representation of a process definition.

Finally, the process relationship mechanism to relate two different pro-

cess definitions, cf. Figure 5.9. The attribute relation type define the
semantical meaning of the relationship. An example of such a relation-
ship is the substitution, where the relating definition is substituted by
the related definition.
80 Chapter 5. Information Requirements for Process Planning

STRING

relation_type
relating

process_definition definition_relationship
related

Figure 5.9. The representation of a process definition relationship.

5.3.5 Representation of Process Sequence

The most common relationship between two processes is the sequence

relationship. A sequence relationship define that a process is executed
before or after another. Figure 5.10 show the process relationship that
provides a mechanism to relate processes in sequence.

STRING

relation_type
relating

process process_relationship
related

Figure 5.10. The representation of process sequences.

The attribute relation type should have the value sequence to define
the correct semantical meaning of the relationship. The semantical
meaning of the relationship is, then, that the related process is a suc-
cessor of the relating process. Naturally, two processes in a sequence
relationship may not have an overlap in their time of execution. That
is, a process may not start until the execution of the predecessor has
ended.

5.3.6 Representation of Process Hierarchy

Another common relationship is the decomposition relationship. This

is used when a more detailed description of a process is necessary,
e.g. when a process is decomposed to describe each sub-process for a
5.3. Requirements on Process Plan Core Model 81

particular machine tool. Often a decomposition of a process is called

operation, a decomposition of an operation is called task and so on.
However, here they are all considered as a process at different levels of
detail.
Figure 5.10 show the representation of a process relationship. The at-
tribute relation type should have the value decomposition to define the
correct semantical meaning of the relationship. The meaning of a de-
composition relationship is that the related process is a decomposition
of the relating process. As such, the related process provides more de-
tailed information than the relating process, e.g. in terms of product
realization information.

5.3.7 Representation of Alternative Processes

Yet another common process relationship is the alternative relation-

ship. An alternative relationship specify that a process may be used as
an alternative for another process. The process plan core model make
use of the process relationship in Figure 5.10 to represent an alternative
relationship.
The attribute relation type should have the value alternative to define
the correct semantical meaning of the relationship. This, then, define
that the related process may be used as an alternative for the relating
process.
Notable is that two alternative processes may not have a common pro-
cess definition. The meaning of processes that have a common process
definition is that these processes are the same and, thus, not alternate
processes. In the case where two alternative processes have a common
process definition it should be interpreted as being alternative resources
instead. This may be controlled by the following rules:

1. two alternative processes may not have a common definition, un-

less

2. the two processes are executed by different resources.

82 Chapter 5. Information Requirements for Process Planning

Thus, the alternative relationship can be used to define alternative

processes, different process definitions, and alternative resources, com-
mon process definition but different resources. See Section 5.4.21 for a
discussion on alternative resources.

5.3.8 Representation of Arbitrary Ordered Pro-

cesses

A not so common relationship between two processes are the arbitrary

order relationship. The meaning of such a relationship is that the order
of execution of the processes does not matter. That is, either one of
them may be executed first. The only restriction is that they may not
have an overlap in their time of execution.
Even though the relationship is not used as often as a sequence relation-
ship it could still be useful when it is necessary to define the processes
needed to manufacture a product, but not their order of execution.
The decisions about the order may then be left until later when more
information is available. For instance, during production planning, or
even at the time of the execution.
Arbitrary ordered processes are grouped together by the process group-
ing mechanism in Figure 5.11.

process_plan_version

plan

grouping_type
process_grouping STRING

Figure 5.11. The representation of a group of processes.

The attribute grouping type should have the value arbitrary order to
define the correct semantical meaning of the grouping. With an arbi-
trary order value the meaning is that the processes belonging to the
5.3. Requirements on Process Plan Core Model 83

process group, i.e. the processes that are associated to the process group
with a decomposition relationship, may be executed in any order.

5.3.9 Representation of Parallel Processes

In a similar way as arbitrary ordered processes, parallel process are also

a set of processes grouped together to define that they are executed
in parallel. Hence, a major difference is that while arbitrary ordered
processes may not have an overlap in their time of execution, parallel
processes not only may have but must have an overlap in their time of
execution.
The process grouping mechanism in Figure 5.11 represent a grouping
of parallel processes. The attribute relation type must have a value
of parallel to define the correct semantical meaning of the grouping,
which is that the processes specified by the processes are, or should be,
executed in parallel.

5.3.10 Representation of Process Grouping Rela-

tionship

There is no significant difference between an ordinary process and a

group of processes when it comes to relationship to other processes,
including groups of processes. Consequently, a process grouping must
in a similar way have the ability to be related with other processes in
terms of sequence, decomposition, and alternative relationships.
Figure 5.12 show a mechanism that provide the ability to relate a pro-
cess object with another process object. Since the process object entity
itself is abstract it can only exist in terms of its subtypes, i.e. in terms
of a process or a process grouping. Hence, a process structure can
be created containing any number or variants of process and process
grouping objects.
84 Chapter 5. Information Requirements for Process Planning

process_plan_version
STRING

plan relation_type
relating

(ABS)process_object process_relationship
related

process_grouping

process

Figure 5.12. The representation of process object relationship.

The semantical meaning of the process relationship is, as usual, defined

by the attribute relation type. Applicable values for the relation type
attribute are: (i) alternative, (ii) decomposition, and (iii) sequence.
The relating and related have the same semantical meaning as described
in Section 5.3.5 to Section 5.3.7.
However, the meaning of the relationship is, perhaps, easier to interpret
if another construct is used. Figure 5.13 show the complex process and
process constituent mechanism. Here it is obvious that process group-
ing as well as process are types of both complex process and process
constituent, meaning that they can be specified by the relating as well
as the related.

5.4 Requirements on Outer Part of the

PPR Information Model

The purpose of the outer part of the PPR information model is to

represent information that can be used to define and describe, or are
related to, processes, but could not fulfill the requirements for infor-
mation represented in the process plan core model.
5.4. Requirements on Outer Part of the PPR Information Model 85

process_plan_version
STRING

plan relation_type

relating related
(ABS)complex_process process_relationship (ABS)process_constituent

process_grouping

process

Figure 5.13. A mechanism to represent process structures.

Therefore this information have been separated by adding an interface

model that separates the representation of non core information from
the representation of core information.
An example of a mechanism in the interface model that relates core in-
formation with non core information is presented in Figure 5.14. This
shows how a process is related with non core information, e.g. infor-
mation defining a product in terms of input to a process.

Core Information Interface Mechanism Non Core Information

STRING
ISO10303-214.item_instance

role

process element
process process_input_output input_output_element_select

Figure 5.14. An example of an interface mechanism relating core

information with non core information.

Similar interface mechanisms will be used to relate core information

with other non core information, e.g. classification, document, and
organization.
86 Chapter 5. Information Requirements for Process Planning

5.4.1 Representation of Process Definition Attribute

The purpose of using a process definition is to define a process. Not

only need a process definition provide a classification for a process, cf.
Section 5.4.3, it must also define the properties that characterizes a
process and the values that are allowed for those properties. Such a
mechanism is presented in Figure 5.15.

name
STRING

associated_definition
process_definition definition_attribute

ISO10303- allowed_value S[0:?]

214.property_value_representation

attribute_definition
ISO10303-214.(ABS) property

Figure 5.15. Representation of process definition attribute.

The semantical meaning of the mechanism in Figure 5.15 is that a

process must have a minimum set of properties according to the set of
definition attributes associated with the definition. That is, if a process
definition have a definition attribute named cycle time associated with
it, then the process must have a property called cycle time associated
with it as well. In addition, the property must be defined according
to the definition attribute and must be assigned values that do not
contradict the allowed values of the definition attribute.

5.4.2 Representation of Process Property

An important aspect of a process model is its ability to represent pro-

cess properties, such as cycle time, feed rates, and costs. Typically,
properties are associated with a single process or a set of processes.
5.4. Requirements on Outer Part of the PPR Information Model 87

Figure 5.16 show the representation of a property and the association

of it to a process element. Typical process properties are, e.g., cycle
time and feed rates.

process_plan process_plan_version (ABS)complex_process process_definition

process_resource_ described_element
process_property_select
assignment

definitional
process_property_association BOOLEAN

describing_property_value ISO10303-
214.property_value_representation

Figure 5.16. The representation of process properties.

The process property association is used to associate a process related

element with a property. If the definitional is assigned a value of true
then the property define the process related element. Definitional prop-
erties may be used to distinguish process related elements of the same
kind from each other.
The semantical meaning of an associated property depend on the pro-
cess related element it is assigned to. For instance, if a mean time
between failure property is assigned to a process, it means that all
manufacturing resources that are used to carry out the process have
the same mean time between failure. On the other hand, if the same
property is assigned to one of the manufacturing resource it means
that the particular manufacturing resource have the same mean time
between failure in all processes it carries out. A better solution, thus,
is to assigned a mean time between failure property on the process
resource assignment object, which would indicate that the particular
property is dependent on the combination of process and manufactur-
ing resource.
88 Chapter 5. Information Requirements for Process Planning

5.4.3 Representation of Process Classification

As mentioned above, the classification of a process is so important that

each process definition must have a classification associated with it.
Naturally, the classification may differ between different organizations.
Hence, a classification mechanism must be able to represent all types
of classifications.
Figure 5.17 show how a classification is associated to a process defini-
tion. The actual representation of the classification is provided by the
general classification mechanism in ISO10303-214 (ISO/TC184/SC4,
2001).

classified_element definitional
BOOLEAN

classificatied_element_select classification_association

role
associated_classification STRING

ISO10303-
process_definition
214.general_classification

Figure 5.17. The representation of process classification.

The use of the classification system may be to represent definitional

classifications and non definitional classifications. The former concern
classifications that define particular process definitions whereas the lat-
ter concern classifications that add useful classification information to
a process definition.
A definitional classification may define, e.g., the type of process, what
the process is capable of doing, and its capability requirements on man-
ufacturing resources. For instance, the classification system may be
used to classify the basic process definitions in a process library, e.g. in
terms of basic shapes they remove. These basic process definitions de-
fine the available basic shapes that can be made at the manufacturing
sites of a company. Thus, it helps controlling the product development
process in terms of available shape solutions.
5.4. Requirements on Outer Part of the PPR Information Model 89

In addition, the basic process definitions may be used to generate con-

trol programs for, e.g., CNC-machines. The interpretation of a basic
process definition, and combinations of basic process definitions in a
process plan, to generate control programs may be implemented in a
rule based system. In combination with parameterized and feature
based product models, the basic process definitions would provide a
powerful base for on-the-fly generation of control programs for manu-
facturing of customizable product parts.
Even though the reasoning above is on process definitions for removal
processes it may as well be used for other types of processes. For a
weld process the removal shapes cannot be used. However, the shape
of the joint and/or weld seam may be part of the classification. Other
parts of a definitional classification of a weld process may be surface
finish of the welded area and/or restrictions in current.
Nevertheless, the classification mechanism provides the means to choose
the most suitable process definitions to manufacture the product. It
may also be used to understand what process definitions that are avail-
able in the existing manufacturing system and adapt the product design
accordingly.

5.4.4 Representation of Capability

In Section 4.6.3 capability and its use were discussed. There it was
also stated that the process itself did not directly provide capabil-
ity. Instead the capability is provided by the manufacturing resources.
Nevertheless, there is an implicit relationship between a process and a
manufacturing resource via the capability. The manufacturing resource
provides the capability, which the process requires, cf. Figure 5.18.
The required capability is represented by the product function 1 , cf.
Section 5.4.13, and the capability. A process, or a process definition,
is related to a product function via the process function association
1
Here the product function represents a requirement on a manufacturing re-
source.
90 Chapter 5. Information Requirements for Process Planning

process process_definition

role
STRING

process function
process_select process_function_association product_function

capability function
capability capability_function_association

role
STRING
role

capability resource
resource_capability_association resource_definition_select

Figure 5.18. The representation of relationships between capability

and requirer or provider of capability.

with the value required assigned to the role attribute. The semantical
meaning of this is that the origin of the functional requirement on
the manufacturing resource is required by the process, or the process
definition.
The product function itself is, in this case, defined by the capability,
which is related to the product function by the capability function as-
sociation. That it is a definition relationship is defined by the role
attribute by assigning a value of definition.
The provided capability is distinguished from the required capability
by relating it to the manufacturing resource via the resource capability
association. The semantical meaning of provided capability is defined
by assigning a value of provided to the role attribute. The entities rep-
resenting manufacturing resources will be discussed in Section 5.4.20.
Figure 5.19 show the actual mechanism for representing capability. In
the center is the entity that represents the capability. The definition
of a capability is provided by an external reference data library mech-
anism, e.g. P-lib and Epistle (ISO/TC184/SC4/WG3, 1999). Hence,
the actual definition is represented externally.
5.4. Requirements on Outer Part of the PPR Information Model 91

ISO10303-
214.property_value_
representation

value

capability_property_
STRING value_association STRING

relation_type capability external_identifier

relating
definition external_reference_
capability_relationship capability
related data_library

library_type
capability_list
STRING
capabilities L[1:?]

Figure 5.19. The representation of capability.

Besides the main entities the capability relationship and capability prop-
erty value association also are part of the capability mechanism. The
former is used to relate two capabilities with each other and the latter
is used to relate different properties to a capability.
The semantical meaning of a relationship between two capabilities is
defined by the relation type attribute. The possible attribute values
are: (i) decomposition, (ii) dependency, (iii) equivalence, and (iv) sub-
stitution.
The advantage of using a reference data library is that such an mech-
anism provides an open environment for defining concepts without
changing anything in the information model. That is, the reference
data library enables the definition of concepts that can be referenced
from an instantiated information model. Hence, enabling the use of
different terminology in different organizations for the same concept.
Anyone who needs to know the definition of a capability may access it
from the reference data library by using the external identifier and li-
brary type. Hence, the structure and basic semantics of the model can
remain the same whereas the specific semantics of a particular, e.g.,
capability may be updated.
92 Chapter 5. Information Requirements for Process Planning

For further reading on reference data libraries the reader is kindly asked
to await the forthcoming doctor’s thesis by Olof Nyqvist at the Kung-
liga Tekniska Högskolan, department of Computer Systems for Design
and Manufacturing. The thesis is planned to be finished in 2004.

5.4.5 Representation of Process Condition

The ability to have a condition on sequential relationship between pro-

cesses is a not so often occurring requirement. However, it is a way
to control the execution of processes until a particular condition is ful-
filled, e.g. a process may not be executed until a particular period of
time have elapsed since a painting process was finished, and may be
useful for production planning purposes.
Figure 5.20 show the mechanism to represent conditions to control the
flow of processes.

ISO10303-
214.event_reference
STRING condition_element_select

ISO10303-
operation element
214.interval_of_time

condition_expression condition
ISO10303-
214.property_value_representation
operand S[1:?]

classified_element_select
condition_select
relation_type
STRING
condition
relating
controlled_element
condition_specification process_relationship process
related

Figure 5.20. The representation of a process condition.

The main functionality of the condition mechanism is the condition

specification. It provides the mean to control the relationship between
two processes, if the relation type of a process relationship has been
assigned the value of alternative, sequence, or substitution. A condition
5.4. Requirements on Outer Part of the PPR Information Model 93

specification assigned to a process relationship must evaluate to true

before the related process may be executed.
A condition specification specify a condition or a condition expression.
The condition is the representation of the actual condition that must
be fulfilled, whereas a condition expression represents an expression of
conditions, e.g. that condition A, B, and not C (and(A, B, not(C)))
must be fulfilled.
The semantics of a condition expression is defined by the operation.
The operation may be assigned the values and, or, xor, and not. An
and -operation defines that the conditions and/or condition expressions
specified by the operand all must be fulfilled. An or -operation de-
fines that at least one of the conditions and/or condition expressions
specified by the operand must be fulfilled, whereas in contrast, a xor -
operation defines that one, and only one, must be fulfilled. Lastly, a
not-operation defines the inversion of the Boolean value of its operand,
which may be only one.
Each condition use the ISO10303-214 mechanisms event reference, in-
terval of time, and property value representation to represent the value
of the condition. In addition, each condition may be classified with the
general classification mechanism, cf. Section 5.4.3.

5.4.6 Representation of Configuration Control of

Process Structures

Most manufacturing companies today have highly customizable prod-

ucts. Many companies do not consider a variant of a product to be a
different product with different identification. They control the prod-
uct variants by configuration mechanisms in their information systems.
However, depending on the configuration of the product the manufac-
turing of it will differ, i.e. process plans for variants of the product
will differ. Consequently, the number of process plans for a product
will be, at least, the same as the number of variants of the product.
94 Chapter 5. Information Requirements for Process Planning

The variant process plans will, to a great extent, have common process
definitions, sequence, properties and so on.
If instead one process plan was used, a lot of work could be reduced.
That is, work such as creating the same process plan information again
and again, and work of updating every single process plan whenever a
change need to be made that affect the common parts.
Not only does this type of work consume time directly, it also consumes
time due to its error prone nature. Humans tend to make errors in this
type of repetitive work. Each error may affect the quality of the final
product, resulting in time consuming activities tracing the source of the
error and then correcting the error. All while an unsatisfied customer
waits for her, or his, high quality product.
If instead the configuration specification of the product could be reused
to configure the process plan as well. Then the variants of a product
would be manufactured according to the variants of the same process
plan. Any changes would be made to the same process plan and, thus
affect all the variants of the processes. Not only would the initial
work of making the change consume less resources, the potential risk
of having product variants manufactured according to an old process
plan is eliminated.
Figure 5.21 show how the model make use of the configuration mech-
anism in ISO10303-214 (ISO/TC184/SC4, 2001) to configure process
plans, process plan versions, complex processes, and a manufacturing
resources.
In principle, the configuration will state which complex process, i.e.
process or process group, that is valid in a particular part of the process
plan. This statement depend on, as already mentioned, the configura-
tion of the product.
The configuration mechanism may also be used to control the use of a
particular process plan, or process plan version, depending on the con-
figuration of the product. This, however, correspond to the principle
of one process plan for each variant of a product. Consequently, this
does not reduce the work of creating the same information again and
5.4. Requirements on Outer Part of the PPR Information Model 95

ISO10303- is_solution_for
214.configured_specification_select

configured_element
configured_element_select configuration

process_plan

process_plan_Version

(ABS)complex_process

resource_definition_select

Figure 5.21. The representation of a process and its configuration.

again, nor does it eliminate the need for updating each process plan
when a change that affect common parts is made.
Which approach to use must depend on the type of production of the
particular company and their available process planning system. That
is, the effect of using the product configuration to configure the process
plan is higher if several variants are involved and the production vol-
ume is high. In addition, the company must have a process planning
system that can manage product and process plan configurations, or
the complexity will probably be too extensive for the process planner
to handle.
In addition, the same mechanism may be used for configuration of the
manufacturing resources as well. Then the configuration of the product
will determine not only the configuration of the process plan, but also
the configuration of the manufacturing resources used to carry out the
process plan. For instance, variant A of a car make use of the same
assembly robot, robot R, as variant B of the same car. However, at
the particular point in the process plan where they both use robot R,
they need different tools for the robot, e.g. weld guns or grippers. The
configuration of the product is then used to control the configuration
of robot R, so that variant A uses robot R and weld gun A in process
96 Chapter 5. Information Requirements for Process Planning

A, whereas variant B uses robot R and weld gun B in process B.

5.4.7 Representation of Process Constraint

During the design of a process, or a product, particular prerequisites

must be considered, e.g. that a particular vendor is preferable. These
prerequisites can be referred to as design constraints, because they
constrain the design by limiting the domain of solutions that can be
considered.
Naturally, it is important to document design constraints in such a
fashion that it can be communicated with concerned engineers. Fig-
ure 5.22 show the mechanism to represent design constraints.

name
STRING

design_constraint_ definition ISO10303-

occurrence 214.design_constraint

constrained_element

process_plan (ABS)complex_process
constrained_element_select

process_plan_version process_definition

Figure 5.22. The representation of process constraint.

The design constraint occurrence is an occurrence of its definition, the

design constraint. Process entities that have been considered important
to constrain are the process plan, the process plan version, the complex
process, and the process definition. For instance, a constrain of a process
plan may be a maximum cost per manufactured unit or a minimum of
tolerable faulty outputs.
As mentioned, the design constraint mechanism may also be used
for product design solutions. This will be discussed briefly in Sec-
tion 5.4.13.
5.4. Requirements on Outer Part of the PPR Information Model 97

5.4.8 Representation of Documentation

The reality today, and for a vast amount of time, is that companies
store a lot of information in what, traditionally, is called a document,
e.g. paper documents, and digital files of word processing applications,
but may also be a digital file for CNC-program. It is important to
keep track of these documents in terms of creator, creation date, and,
naturally, what objects they document.
Figure 5.23 show the representation of the document mechanism for
process entities. Naturally, other types of entities may also be docu-
mented, such as capability, and product and manufacturing resource
entities.

process_plan process_plan_version (ABS)complex_process process_definition

documented_element
documented_element_select

role
document_assignment STRING

assigned_document
ISO10303-214.document

Figure 5.23. The representation of document.

A document assignment object assigns a document object to a process

object. The role defines the semantical meaning of such an assignment,
e.g. mandatory if the object must match the content of the document,
and behavior if the objects behavior is described.

5.4.9 Representation of Organization

As with the documentation, the organizational information is also im-

portant to keep track of. The model must be able to represent orga-
98 Chapter 5. Information Requirements for Process Planning

nizations and persons, as well as their relationships to the information

in terms of, e.g. owner and creator.
Figure 5.24 show the representation of organizational information and
its association to process entities. Of course, as with documents, or-
ganizational information may be associated with other entities as well,
e.g. the creator of a particular document, or the person who updated
a particular part of a product.

process_plan process_plan_version process process_definition

is_applied_to
element_organization_select

role
person_organization_assignment STRING

assigned_person_organization ISO10303-
214.person_organization_select

Figure 5.24. The representation of organizational information.

A person organizational assignment object assigns a person in an or-

ganization, or an organization, to a process object. The role defines
the semantical meaning of the assignment, e.g. creator for the creator
of the object, and owner for the owner of the object.

5.4.10 Representation of Effectivity

To control the validity of a particular object, the effectivity mechanism

was included in the model, cf. Figure 5.25. For instance, the effectivity
can be used to control what version of a particular process plan that
is valid at the moment, and when it is due.
An effectivity is assigned to the effective element, e.g. process plan ver-
sion, process, and all the relationships in the process plan core model,
5.4. Requirements on Outer Part of the PPR Information Model 99

process_plan process_plan_version process_relationship (ABS)complex_process process_definition

effective_element
effectivity_element_select

role
effectivity_assignment STRING

assigned_effectivity
ISO10303-214.effectivity

Figure 5.25. The representation of effectivity.

via the effectivity assignment. The semantical meaning of the assign-

ment is defined by the role attribute, which can be assigned the follow-
ing values: actual defining an actual period of the effectivity, planned
defining a planned period of effectivity, and required defining a required
period of effectivity.
Naturally, other elements may also have an effectivity assigned, e.g.
documents, entities defining a product and a manufacturing resource.
However, they will not be considered here since the mechanism is the
same and the focus is on processes.

5.4.11 Representation of Coordinate Space

A reference coordinate space in which the process may be defined is

an important information requirement. Such a coordinate space would
provide a reference coordinate space in which the process is defined.
That is, the coordinate space in which all manufacturing resources
and products involved in the process are defined. This is represented
using the Cartesian coordinate space mechanism in ISO10303-214, cf.
Figure 5.26.
100 Chapter 5. Information Requirements for Process Planning

process process_coordinate_ coordinate_space ISO10303-

process
space_association 214.cartesian_coordinate_space

Figure 5.26. The representation of a reference coordinate space of

a process.

5.4.12 Representation of Product

Even though the representation of product definition is important it is

not the focus of this thesis. The information requirements in ISO10303-
214 (ISO/TC184/SC4, 2001) have been found to be sufficient for the
purpose of this thesis and, thus, those are used.
Some examples of information about the product that are necessary:

• intermediate states,

• product shape,

• tolerances,

• product volume, and

• documentation.

Figure 5.27 show the product definition mechanism of the ISO10303-

214 model. The purpose is to give an overview of the product definition
mechanism. Therefore, most of the attributes and some of the relation-
ships have been left out in order to simplify the interpretation.
The item and item version is mechanisms to identify an item, which
may be a finished product, raw material, or a manufacturing resource.
Yes, the manufacturing resources is represented using the same mech-
anisms, cf. reasoning in Section 4.6.3.
The difference between, e.g., an assembly and a part, or a product and
a manufacturing resource, is defined by the specific item classification.
The classification name is assigned values that define the type of item,
5.4. Requirements on Outer Part of the PPR Information Model 101

associated_item [1:?]
application_context (INV) item_classification [1:?]
initial_context

item specific_item_classification
collection_definition classification_name

associated_item STRING
(INV) associated_item_version [1:?]
assembly_definition
item_version single_instance

mating_definition
associated_item_version

process_state design_discipline_item_definition (ABS)item_instance

related_item_definition
definition

instance_definition_select

Figure 5.27. The representation of product and manufacturing re-

source.

e.g. part for parts, tool for manufacturing resources, and assembly for
assemblies.
The design discipline item definition defines a view of an item ver-
sion, which is used to collect information about an item version in a
particular application context. This mechanism enables the separation
of, e.g., information about the electrical design of a product from the
mechanical design of the same product.
Of the other types of design discipline item definitions, the assembly
definition, the mating definition, and the process state are the most
important for this thesis. The assembly definition defines an assembly
view of a product, cf. Figure 5.28, the mating definition defines a
mating view of a product, cf. Section 5.4.18, and the process state
defines an intermediate state of a product, e.g. in a sheet metal die
process where several process steps must be made to accomplish the
final shape of the metal sheet.
The item instance is a mechanism that is used when an instance of
an item version is needed. For instance, if an occurrence of an item
102 Chapter 5. Information Requirements for Process Planning

version is needed in an assembly.

relating related
(ABS)design_discipline_item_definition (ABS)item_definition_instance_relationship (ABS)item_instance

(RT) relating
assembly_definition assembly_component_relationship single_instance

Figure 5.28. The representation of assembly.

Figure 5.28 show the assembly mechanism. The assembly component

relationship is the center of this mechanism. It relates item instances,
the children in an assembly, to an assembly definition, the view of an
assembly. Here, the single instance will only be considered. The single
instance represents an instance of an item version which will occur in
an assembly at a particular location once. If the same item version is
to appear more than once, then a single instance need to be created
for each appearance.
Naturally, many of the entities in the product definition mechanism,
e.g. item, and item instance, may be assigned, e.g., documents, effec-
tivity, and organizational information in a similar way as the processes.

5.4.13 Representation of Product Concept

The purpose of the innovation process is to transform ideas into prod-

ucts that are ready for the market. In this process several requirements
must be considered from different interest groups, e.g. customers (those
who buy the product), owners, government, and so on, often called cus-
tomers.
The requirements are then transformed to functional requirements de-
scribing the function structure that are needed to fulfill the require-
ments of the different interest groups. From the functional require-
ments concept solutions are created. The concepts with best potential
5.4. Requirements on Outer Part of the PPR Information Model 103

of success is chosen and developed further by embodiment and detailed

design.
It is important to document the development from identified require-
ments to detailed design in order to, e.g., keep track of decisions, reuse
concepts, and reuse solutions. Figure 5.29 show the mechanism to rep-
resent requirements, functions, and concept solutions. The mechanism
is mainly the same as the ISO10303-214 complex product mechanism
with the difference of product requirement.

constrained_element design_constraint_ definition ISO10303-

constrained_element_select
occurrence 214.design_constraint

STRING
relation_type

relating related
(ABS)complex_product product_structure_relationship (ABS)product_constituent

id
product_requirement
STRING

product_function

product_component

Figure 5.29. The representation of a mechanism to represent prod-

uct requirements and concepts.

The main structuring mechanism consist of the complex product, the

product structure relationship, and the product constituent. That is, a
complex product may be related to a product constituent by the product
structure relationship. The complex product and the product constituent
must always be one of product requirement, product function, or product
component.
The semantical meaning of a product structure relationship is defined by
the relation type. The attribute may be assigned the following values:

• decomposition - define a hierarchy between two objects of the

same type, e.g. two product functions,
104 Chapter 5. Information Requirements for Process Planning

• dependency - define a dependency between two objects of the

same kind, e.g. two product requirements,

• functionality - define the functionality, product function, of a

product component,

• occurrence - define an occurrence of a product component,

• realization - define the realization of a product function in terms

of product component, and

• specialization - define that an object of the same kind fulfills the

requirements in a more specific way.

The relationship should be interpreted as a relationship where the re-

lating complex product is decomposed in, has function as, occur as,
is realized by, or is specialized by the related product constituent. The
only exception from this is the dependency, which should be interpreted
as a relationship where the related product constituent is dependent on
the relating complex product.
Naturally, a complex product may be assigned documentation, effectiv-
ity, properties, and organizational data in a similar way as the process
entities.

5.4.14 Representation of Project Management In-

formation

In a network of competences, especially where the competences belong

to different organizations, the management of a project becomes crucial
and difficult. One aspect of this problem is the ability to communicate
work requests, work orders, responsibilities for resolving the requests,
and much more. Here, the mechanism from ISO10303-214 is used, cf.
Figure 5.30 for a stripped version of the mechanism.
The work request represents a request for some work to be done and
the scope specify the design objects that are subject to the request.
5.4. Requirements on Outer Part of the PPR Information Model 105

process_plan process_plan_version (ABS)complex_process process_definition

scope S[0:?]
activity_element_select work_request work_order

resolved_request S[0:?] is_controlling

(INV) authorization S[0:1]
work_program S[0:?]
project activity
(INV) associated_project S[0:1]

Figure 5.30. The representation of project related information.

Naturally, other objects may be subject for a request as well, e.g. item
and document. A work request is solved by an activity that may be
part of a project, and authorized by a work order.
Each of these entities may be associated with organizations, persons,
and documents. This enables the representation of who made the re-
quest for a particular work to be done, who is responsible for a partic-
ular activity, and who authorized a particular activity. Effectivity and
date are other types of information that may be associated with these
entities in order to represent when a particular activity is planned to
be carried out and what date a particular request was issued.

5.4.15 Representation of Produced Output

Each process plan that is created will have, at least, one main output,
i.e. the finalized product or part. This is represented in Figure 5.31 by
the produced output mechanism.
The produced output mechanism consists of two entities, the plan pro-
duced output association and the produced output select. The former
is used to associate a process plan version with its produced output,
which is one of the choices of the produced output select, the item ver-
sion or the product component. An item version is the representation
106 Chapter 5. Information Requirements for Process Planning

plan produced_output
process_plan_version plan_produced_output_association produced_output_select

ISO10303-
214.item_version

ISO10303-
214.product_component

Figure 5.31. The representation of produced output.

of a version of a product whereas the product component represents a

conceptual product design.

5.4.16 Representation of Input and Output to and

from Processes

Obviously, to describe how to manufacture a product it is necessary to

describe the state of the product before and after the process is per-
formed. An input describe the state a product should have before a
particular process is performed and an output describe the state the
same product should have after the particular process. The represen-
tation of inputs and outputs are shown in Figure 5.32.
The process input output define an association of a process to its input
or output, the choices of the input output element select. The semanti-
cal meaning of the process input output is defined by the role. If the role
is assigned a value of input the relationship defines an input, whereas
a value of output defines an output.
The elements that may be selected as input or output may be raw ma-
terial, parts, semi-finished parts, sub-assemblies, and the final product.
These elements are represented by the item instance, the design disci-
pline item definition, and the product component.
An item instance is used when a particular instance of an item version
is needed to define the input or output of a process, the design disci-
5.4. Requirements on Outer Part of the PPR Information Model 107

STRING
process transformation_3d

role
process placement

concerned_detail [0:?] process_input_output element

concerned_detail_select input_output_element_select

ISO10303-
ISO10303-214.item_instance
214.shape_element

ISO10303-
mating_element
214.design_discipline_item_definition

ISO10303-214.product_component

Figure 5.32. The representation of input and output of a process.

pline item definition is used if that particular collection of information

about a product is needed, and the product component is used when
the detailed product design is not yet determined, e.g. during concept
design.
The concerned detail is used to specify the shape element or mating
element that may hold detailed product information that are necessary
to perform the process, e.g. a hole or a weld spot.

5.4.17 Representation of Location System

The location system is a system of master location points and location

points that are used to determine the location of a part for manu-
facturing purposes. The master location and location points defines
the contact points between products and manufacturing resources, e.g.
product and fixture contact, or product and gripper contact.
The outcome of a process is highly affected on the design of a prod-
uct’s contact points with its, e.g., fixture. Depending on the location
of contact points the variance of quality in the final product may be
108 Chapter 5. Information Requirements for Process Planning

minimized. The work of minimizing the variance is often referred to as

robust design, cf. work by Söderberg and Lindkvist (2000).
For further reading on location system, master location points, and
location points cf. Appendix C.
Figure 5.33 show the location system mechanism, which consists of
two main mechanisms. The two mechanisms are the location system
mechanism and the location point mechanism.

STRING BOOLEAN NUMBER

relation_type guide_direction A[1:3] coordinates A[1:3]

location_system_relationship guide_function cartesian_point

relating related
guide_function
part_of
(ABS)location_system location_point
(RT) part_of
(INV) consists_of S[6:6]

defined_in
master_system master_location_point

location_point_shape

ISO10303-
subpordinate_system
214.shape_element

design_discipline_
cartesian_coordinate_space_3d
item_definition

Figure 5.33. The representation of reference system.

The location system is a type of design discipline item definition that

defines a collection of location points that are used to determine the
position of an element, e.g. the product or the manufacturing resource.
A location system consists of a fixed number of master location point
objects, 3 + 2 + 1 points, and anything from zero to an infinite number
of other location point objects.
The six master location points are used to determine, in an unambigu-
ous way, the location of an element, such as a product or a manufac-
5.4. Requirements on Outer Part of the PPR Information Model 109

turing resource. The zero to infinite number of non-master location

points are used to support the six master location points in the case
of, e.g. slender bodies.
Two types of location systems exist, the master system and the sub-
ordinate system. A master system is used to determine the location
of the element itself whereas the subordinate system is used to locate
particular functions of an element, e.g. shape of openings or mountings.
The location system relationship is used to relate two location systems
with each other. The semantical meaning of the relationship is defined
by the relation type, which can be assigned the values dependency and
subordinate.
A dependency relationship define that the related location system is
dependent on the relating location system. This may, for instance, be
used to define that a master system of a fixture depend on the master
system of a product, or that a subordinate system of one part depend
on a subordinate system of another part.
A subordinate relationship define that the related subordinate system is
subordinated the relating master system. Consequently, in this type of
relationship the relating will always specify a master system whereas
the related will always specify a subordinate system.
The location point is a type of Cartesian point that are defined in a
three dimensional Cartesian coordinate space, specified by the defined
in of the master system. The coordinates in the Cartesian coordinate
space is defined by the coordinates, which is an array that is indexed
from one to three of number representing the X-, Y-, and Z-axis in the
coordinate space.
In addition to the coordinates, a location point also have a guide func-
tion, and, may have, a shape associated. The guide function define
the directions in which the location point guide the located element.
This is represented by the guide direction, which is an array indexed
from one to three of Boolean representing the X-, Y-, and Z-axis in
the coordinate space. A value of true in the first array element would
indicate that the location point guide in the direction of the X-axis,
110 Chapter 5. Information Requirements for Process Planning

whereas a value of false would indicate that it does not.

Figure 5.34. A location point, in the shape of a hole, that guide in

three directions (from Volvo (1996)).

The location point shape does, naturally, specify the shape that are
associated with the location point. This is the actual shape of the
location point in the physical world, cf. Figure 5.34.

5.4.18 Representation of Mating

Most products consists of more than one part and, thus, it is, in addi-
tion to the topological structure of a product, important to represent
how the parts are joined together. Usually the area where parts are
joined together is referred to as a joint, which add information to the
product that may be of concern for manufacturing.
However, here the terminology from ISO10303-214 (ISO/TC184/SC4,
2001) have been preserved. Hence, the area where parts are joined
together will be referred to as a mating.
In the automotive industry the body-in-white operations are important,
which include mating of metal sheets. An often used mating method
is spot welding, even though other mating methods may be used, e.g.
gluing, clinching, and press fit.
Figure 5.35 show the mechanism for representing matings. This mech-
anism may be used to represent any kind of matings including those
mentioned above.
5.4. Requirements on Outer Part of the PPR Information Model 111

associated_mating ISO10303- ISO10303-

214.mating_definition 214.mated_item_relationship

associated_mating_shape [1:?]

mating_element
placement
placement_select

definition

transformation_3d
mating_element_
definition_select

ISO10303-
cartesian_point
214.item_instance

coordinates A[1:3]
external_reference_
data_library NUMBER

Figure 5.35. The representation of a mating definition.

The main entity in the mating mechanism is the mating definition. This
is the mechanism in ISO10303-214 and define the mating itself. It has
been extended here to enable the representation of mating elements in
a mating, e.g. bolts, nuts, and weld spots. The aim has been to create
a mechanism where the mating can be defined with all its requirements
without the need to define the exact type of mating or detailed design
of the mating. This may be done later when a particular manufacturing
method has been chosen, e.g. to use spot welding or to use gluing.
Each mating definition may have two or more item instances associated,
which define the parts that are mated together. Their respective place-
ment in the mating is defined by the three dimensional transformation,
cf. Section 5.4.20, and their surface of actual mating is specified by the
mating surface.
The mating element is the representation of an element, physical or non
physical, that is used to join the different parts in a mating; a bolt is an
example of a physical element and a weld spot is an example of a non
physical element. Its definition is specified by the definition that can
be assigned to an item instance or an external reference data library.
Typically a bolt would be represented by an item instance whereas a
weld spot would be represented in an external reference data library.
112 Chapter 5. Information Requirements for Process Planning

The placement of a mating element is defined by either a transforma-

tion 3D or a Cartesian point. The transformation 3D is used when the
mating element is already defined in its own coordinate space, e.g. for
a bolt defined by an item instance. The Cartesian point, on the other
hand, is used to define the placement of mating elements that are not
defined in their own coordinate spaces, e.g. for a weld spot defined by
an external reference data library.
Last, but not least, is the representation of properties to a mating
definition and a mating element. This is shown in Figure 5.36.

mating_definition mating_element

described_element
item_property_select

definitional
item_property_association BOOLEAN

describing_property_value ISO10303-
214.property_value_representation

Figure 5.36. The representation and association of properties to

matings.

The item property association associates a property to the representa-

tion of a product. In this case the product representation is the mating
definition and the mating element. Each property may be definitional
or non definitional, which indicate whether the property can be used
to distinguish the element from elements of the same kind or not.

5.4.19 Representation of Material

Having access to the right material data is necessary for production

engineers to make the right decision about the type of process and
manufacturing resources that are needed. In addition, the material also
determines the value of different process parameters, such as current
5.4. Requirements on Outer Part of the PPR Information Model 113

and welding time, either explicitly by a weld robot programmer or

implicitly by an adaptive robot controller.

classified_element_select

material_name
STRING
ISO10303-
214.item_instance
described_element S[1:?]
material

described_element_select design_constraint
described_material
ISO10303-
definitional 214.design_discipline_
material_property_association BOOLEAN item_definition

associated_property_value ISO10303-
214.material_property_value_representation

Figure 5.37. The representation of material.

Figure 5.37 show the representation of material and its association to

described element, e.g. a product definition. The material itself have
a name and is defined by the material properties that are associated
with it. A property may be definitional, meaning that the particular
value of the property can be used to distinguish a particular material
from other materials of the same kind.
In addition, a material may also have a classification associated. The
classification define the type of material. The classification mechanism
also provide an external reference data library definition, which means
that external definitions may be used to classify materials.

5.4.20 Representation of Manufacturing Resource

The ability to describe resources is another important information re-

quirement for process planning. This is important in order to under-
stand which resource that is executing a particular process.
As was discussed in Section 4.6.3, a resource is only a usage view of
the product. During the development of a manufacturing resource it
114 Chapter 5. Information Requirements for Process Planning

could be considered a product with the purpose to be used for manu-

facturing of other products. Hence, no additional requirements on the
representation of information defining the manufacturing resources will
be made; instead cf. Section 5.4.12.
The mechanism to represent the usage of a manufacturing resource is
shown in Figure 5.38.
respource_definition

reference_resource
BOOLEAN
resource_definition_select

process ISO10303-
process process_resource_assignment
214.design_discipline_item_definition

reason
placement ISO10303-214.item_instance
transformation_3d
STRING

direction_of_axis A[1:3] A[1:3] ISO10303-214.physical_instance

NUMBER

ISO10303-214.product_component

ISO10303-
214.descriptive_specification

Figure 5.38. The representation of a resource and its association

with a process.

A process may be assigned a manufacturing resource that is to execute

that particular process. This is enabled by the process resource assign-
ment. Whether the coordinate system in which the resource is defined
is used as the reference coordinate system of the process is determined
by the reference resource attribute. The placement is used to place the
resource in relation to the reference coordinate system of process, in
case the resource is not a reference resource.
The definition of the resource may then be represented by a design dis-
cipline item definition, an item instance, a physical instance, a product
component, or a descriptive specification. The different entities will be
used for different purposes. For instance, the physical instance will be
5.4. Requirements on Outer Part of the PPR Information Model 115

used whenever the meaning is that an actual existing manufacturing

resource is used for a particular process.
In addition, it is important to represent different structures of the re-
sources. Beside the requirement-, functional-, and component-structures
of resources, as discussed in Section 5.4.13, at least one additional type
of structure can be identified, the mechanical structure. The mechan-
ical structure describe how the resources are related, mechanically, to
each other, e.g. a robot gripper is mounted at the end of a robot arm.
Usually manufacturing resources are grouped together according to the
process areas of a factory. A process area is an area where a character-
istic process is carried out, e.g. the line where an engine is assembled.
Usually these groupings are named line, zone, station or cell.
Whether a grouping of manufacturing resources is a line or a station
can be determined using the classification mechanism, cf. Section 5.4.3
and Figure 5.39.

classified_element
classified_element_select BOOLEAN

definitional

ISO10303-
classification_association
214.design_discipline_item_definition

associated_classification role
ISO10303-214.item_instance STRING
ISO10303-
214.general_classification
ISO10303-214.physical_instance

ISO10303-214.product_component

ISO10303-
214.descriptive_specification

Figure 5.39. The representation of a resource and its classification.

116 Chapter 5. Information Requirements for Process Planning

5.4.21 Representation of Alternative Resources

In Section 5.3.7 the representation of alternative processes was dis-

cussed. A similar requirement is the requirement to represent alterna-
tive resources. In fact, the mechanism is the same.
Alternative manufacturing resources are assigned to their own process
objects that are related to each other by an alternative relationship. It
is considered to be alternative manufacturing resources when the same
process definition object is used for all the involved process objects. If
two different process definitions are used then it would be considered to
be alternative processes running in different manufacturing resources.
Chapter 6

Validation of the Information

Model and Test of the
Hypotheses

The purpose of this chapter is to validate the PPR information model,

and to test the hypotheses. The validation and test activity was based
on a weld cell development project. This project was a collaborative
project between Scania in Oskarshamn, customer role, and ABB BiW
in Olofström, vendor role.
The validation and test activity was made by populating the PPR
information model by the information that was communicated between
Scania and ABB BiW in the project. Typically this information was
communicated in documents, e-mails, and speech, e.g. in meetings and
by telephone. The main flow of information is presented in Figure 6.1,
where the information sent by Scania is presented above the time line,
and information sent by ABB BiW is presented under the time line.

117
118 Chapter 6. Validation of the Information Model

Scania
Request for tender (3)

Comments on
Request for tender (2) Tender 2

Request for tender (1) Order Take-over report

0 1 2 3 4 5 6 7

-14 -13 -2 -1
Minutes:
Tender 1 Tender 3
project meeting 5
Tender 2 Tender 4
Minutes:
Minutes: project meeting
ABB BiW project meeting 1 on safety 1

Minutes: Minutes:
project meeting 2 follow-up meeting 1

Minutes:
Delivery: robot cell
project meeting 3
Minutes:
Minutes: follow-up meeting 2
project meeting 4
Delivery: documentation

Figure 6.1. The main flow of information between Scania and ABB
BiW.

6.1 Case: Development of Weld Cell at

Scania Oskarshamn

The case was, as mentioned, based on a weld cell development project

at Scania Oskarshamn, Sweden, in collaboration with ABB BiW Olof-
ström, Sweden. Even though the development project considered four
different subassemblies, the case was limited to consider the weld cell
development for one subassembly only, the 10310025 carrier frame as-
sembly. The carrier frame assembly was composed by the 10310325
door carrier reinforcement and 10310363 carrier cross member.
Further limitations were that only the mechanical aspect of the devel-
opment project and no manual processes were considered. This is due
to the limited time of the research project.
The Scania product model specified that the door carrier reinforcement
and carrier cross member were to be joined by 33 weld spots. Three of
these weld spots, decided by Scania, was welded manually outside the
weld cell. These were the, so called, geometrical weld spots, i.e. weld
spots that are welded first and located so that the geometrical shape of
6.1. Case: Development of Weld Cell at Scania Oskarshamn 119

the assembly can be maintained without the use of a particular fixture.

Hence, the task for ABB BiW was to develop a solution that could, in
terms of Hubka and Eder (1988), transform 10310325 door carrier rein-
forcement and 10310363 carrier cross member to the 10310025 carrier
frame assembly by welding 30 weld spots at predefined locations.
In this case, however, only one geometrical spot and three weld spots
will be considered. The purpose is to validate the information model
by testing the principles and not to represent all information in the
development project.

Figure 6.2. The weld cell as it was delivered to Scania.

The task was solved by ABB BiW by developing a weld cell that was
powered by an ABB robot with a gripper, and a stationary weld gun, cf.
Figure 6.2. Included in the solution was the manufacturing processes,
in this case the welding of 30 weld spots. The robot used the gripper to
move the carrier frame assembly and weld the 30 spots in the stationary
weld gun.
120 Chapter 6. Validation of the Information Model

6.2 Validation of the Information Model

In addition to the earlier limitations, the validation of the process in-

formation model mainly focused on three aspects of the model. These
aspects were the weld spot aspect, the process aspect and the manu-
facturing resource aspect.

6.2.1 Product Specification

The product specification specify the 10310025 carrier frame assembly

and its constituents. The carrier frame assembly is represented by the
item and item version in the PPR information model, cf. Figure 6.3.

name
Carrier Frame Assembly
assembly
id
10310025
classification_name

associated_item S[1:?]
specific_item_classification item
(INV) item_classification S[1:?]

process planning associated_item

application_domain (INV) associated_item_version S[1:?]
manufacturing

id
v2 item_version

life_cycle_stage

associated_item_version
id
10310025_0001
application_context mating_definition
initial_context

Figure 6.3. Representation of the mating of the carrier frame as-

sembly.

The mating definition is a view of the carrier frame assembly in terms of

how the constituents of the carrier frame assembly is joined to become
the assembly. In other words, the mating definition is a collector of
information about the carrier frame assembly that are necessary to
define how its constituents are joined. The application context specify
6.2. Validation of the Information Model 121

that the information define the assembly from a manufacturing and

process planning perspective.
Figure 6.4 show the 10310325 door carrier reinforcement and 10310363
carrier cross member as they have been joined.

Figure 6.4. The 10310025 carrier frame assembly.

The constituents of the 10310025 carrier frame assembly, i.e. the

10310325 door carrier reinforcement and 10310363 carrier cross mem-
ber, are represented analogously with two exceptions. The classifica-
tion name have the value of part instead of assembly and the mating
definition is replaced by a design discipline item definition.
The value of part for the classification name is used because neither of
the constituents are assemblies. The design discipline item definition
is used for the same reason, i.e. the constituents are not assemblies
and can, thus, not be specified in terms of matings (joints).
122 Chapter 6. Validation of the Information Model

In addition to the item, item version, and design discipline item defi-
nition, the constituents need to be represented by a single instance, cf.
Figure 6.5.
name
Door Carrier Reinfocement
id
10310325

mating_definition item

associated_item S[1:?]
associated_item (INV) item_classification S[1:?]
relating
(INV) associated_version S[1:?]

id
mating_item_association v1 item_version specific_item_classification

related associated_item_version classification_name

definition part
placement single_instance design_discipline_item_definition

id id
10310325_0001 10310325_0001

direction_of_axis A[1:3] A[1:3]

transformation_3d [[10, 0, 0], [0, 10, 0], [0, 0, 0]]

Figure 6.5. Representation of an instance of the 10310325 door

carrier reinforcement and its association with a mating definition.

The single instance represents and instance of a particular item version

in the mating definition. This mechanism enables the reuse of the same
item definition in several different product structures, or if the same
item occurs several time in the same product structure. For instance,
a wheel, which may occur four times in a car, front left, front right,
rear left, and rear right.
The transformation 3D is used to place the particular instance in the
coordinate space of the item defining the assembly, i.e. 10310025 carrier
frame assembly. The principle is shown in Figure 6.6, where the door
carrier reinforcement is placed in the coordinate system of the carrier
frame assembly.
Note that the door carrier reinforcement is a part and not an assembly
as the carrier frame assembly. Note also that the design discipline item
6.2. Validation of the Information Model 123

10

Z X

10
Z
X

Figure 6.6. The transformation of the door carrier reinforcement in

the coordinate space of the carrier frame assembly.

definition of the door carrier reinforcement should be assigned to the

same application context as the mating definition of the carrier frame
assembly.
The instances of the door carrier reinforcement and the carrier cross
member is related to the mating definition, cf. Figure 6.7. This indicate
that they are parts that are joined together in the mating.
The mated item relationship specify a relationship between the door
carrier reinforcement and the carrier cross member. The relationship
specifies the actual point of contact between the two instances. In this
case the contact is where a weld spot is located. Hence, there could
be a mated item relationship for each weld spot. The word could is
used because the relationship is only necessary when the shape1 and/or
material of the mating is needed.
The identification of a weld spot is represented by the mating element.
In Figure 6.8 a weld spot in the carrier frame assembly is represented.
It is associated with a mated item relationship specifying the shape of
it, cf. Figure 6.7, a Cartesian point defining its placement, and an
external reference data library that defines the weld spot.

1
Note that the shape in Figure 6.7 is a simplification to save space.
124 Chapter 6. Validation of the Information Model

id
10310325_0001

relating related
mated_item_association single_instance

relating

mated_shape S[1:?]
mating_definition mated_item_relationship

related

id
relating related
mated_item_association single_instance

id
10310025_0001 10310363_0001

Figure 6.7. The representation of the instances of door carrier rein-

forcement and the carrier cross member in a mating.

id
mating_definition 10310025_0001 mated_item_relationship

associated_mating
associated_mating_shape [1:?]

mating_element placement

definition

version
external_reference_data_library cartesian_point

library_type external_identifier coordinates A[1:3]

ISO13584 71DCCFE235594 001 [10.30, 120.0, 10.0]

Figure 6.8. The representation of a weld spot.

6.2. Validation of the Information Model 125

Without the external reference data library the mating definition would
not be a weld spot. In addition to defining the type of welding element,
the definition of a weld element in an external reference data library
can also be used to define data types that must be associated with a
weld spot.
Two data types have been identified, the diameter of the weld spot, and
an attribute to define whether the weld spot is a geometrical weld spot
or not. In addition, the definition was also used to define that a weld
spot must always be associated with a Cartesian point and not with
a transformation 3D. The definition was made using the ISO13584-25
(Parts Library), cf. Figure 6.9.

Figure 6.9. The presentation of the definition of a weld spot in the

PLibEditor application.

The definition of the mating element defines that the mating element
is a weld spot and should have an identifier (short name is id ), a
placement, and a weld spot diameter associated.
The identifier, or id, is a string that uniquely identifies a mating ele-
ment. The presentation of the id in PLibEditor is shown in Figure 6.10.
Consequently, the mating element must have a unique identifier associ-
ated. This is provided by using the property mechanism in ISO10303-
214. The id is represented by a string property called id.
The placement is a reference to the Cartesian point class in the dictio-
nary. It defines that a weld spot must have a placement specifying a
Cartesian point as its placement. Hence, the attribute placement of a
126 Chapter 6. Validation of the Information Model

Figure 6.10. The presentation of the definition of the identifier in

the PLibEditor application.

mating element must, if the mating element is a weld spot, specify a

Cartesian point and not a transformation 3D. The presentation of the
placement in PLibEditor is shown in Figure 6.11.

Figure 6.11. The presentation of the definition of the placement in

the PLibEditor application.

Similarly, the weld spot diameter define the diameter of a weld spot.
The value of the diameter is represented by a length property in the
metric system. The presentation of the weld spot diameter in PLibEd-
itor is shown in Figure 6.12.
It is clear that the use of external reference data libraries for defini-
tion of concepts is a strength. The strength is, among other things,
that information model structures can be maintained even though the
library of concepts is changed. For instance, if the concepts for some
particular mating elements have been defined and a new type of mating
element is developed, then the dictionary needs to be updated but not
the information model.
6.2. Validation of the Information Model 127

Figure 6.12. The presentation of the definition of the weld spot

diameter in the PLibEditor application.

6.2.2 Process Plan Specification

Along with the product specification was a process plan sent to ABB
BiW. The process plan specified a restriction in sequence of manufac-
turing processes on a macro level.
The mating of the carrier frame assembly was made in two processes.
First, the process plan specified that three geometrical spots were to
be made manually. Second, the rest of the weld spots were to be made
in an automated solution. The representation of the process plan is
presented in Figure 6.13.
The process plan and process plan version together represent a partic-
ular process plan. Each process in the process plan is assigned to the
particular version of the process plan, in this case version 001.
The sequence of the processes is not given by the process identifier, but
with the process relationship, indicated by the value sequence assigned
to the relation type. The process specified with the relating is preceding
the process indicated by the related.
The process definition objects define each process. The definition is
done by adding properties, documents, and classification to the process
definition. In Figure 6.14 the classification of the process definition 002
is presented.
The general classification assigned to the process definition in Fig-
ure 6.14 is definitional. This means that the classification defines the
128 Chapter 6. Validation of the Information Model

plan_identifier
process_plan 10310025

associated_plan
(INV) associated_version S[1:?]

version_identifier
process_plan_version 001

plan plan

process_identifier process_identifier
010 process sequence process 020

relatin_type
definition definition
process_definition process_definition
relating related
process_relationship
definition_identifier definition_identifier
001 002

Figure 6.13. The representation of a process plan and its two pro-
cesses.

definition_identifier classified_element definitional

002 process_definition classification_association TRUE

version
001 associated_classification

code classification_source
71DCDAE1432A3 plib_class_reference general_classification

Figure 6.14. The representation of a process definition and its clas-

sification.
6.2. Validation of the Information Model 129

process definition.
The general classification also uses a ISO13584 (Parts Library) refer-
ence. This is the source of classification, i.e. the concept in the dictio-
nary, to which the general classification refers, contain the specification
of the general classification, cf. Figure 6.15.

Figure 6.15. The representation of the definition of spot welding in

the PLibEditor application.

In this case it was already decided by Scania that it was a solution for
a spot weld process. However, in a concurrent engineering process the
process may at first only have a definition defining that it is a joining
process and not what type of joining process. Then the supplier of the
equipment have less constraints to deal with and can, perhaps, develop
a, better solution.

6.2.3 Work Request

In addition to the information defining the product to be manufactured

and the process plan, Scania also communicated a request for ABB
BiW to develop a solution for the process 020. This information is
represented to the left in Figure 6.16. The work request is a request for
a development activity that is required from a manufacturing point of
view, indicated by the work request type.
Together Scania and ABB BiW set up a project to develop a solution
for the concerned process, the Robot Cell - 0020 project. To the project
130 Chapter 6. Validation of the Information Model

work_order_type
design release

production requirement name

work_order organization Scania

work_request_type is_controlling
(INV) authorization S[0:1] concerned_organization

resolved_request S[0:?]
work_request activity

activity_type supplying_organization
scope S[0:?] work_program S[0:?]
(INV) associated_project S[0:1]
design
name
process project organization ABB BiW

process_identifier name
020 Robot Cell - 0020

Figure 6.16. The representation of a work order and related infor-

mation.

is also a design activity assigned to resolve the work request initiated

by Scania. The design activity is mainly carried out by ABB BiW,
indicated by the supplying organization, whereas Scania is the organi-
zation that is affected by the result of the activity, indicated by the
concerned organization.
Then Scania creates a work order for a design release. The work order
authorize and initiate the activity which was assigned to the project in
order to resolve the work request.

6.2.4 Process and Manufacturing System Solution

When the work is authorized by Scania, ABB BiW can start developing
a solution for process 020. This is done by further developing and
detailing the process, and developing a manufacturing solution that
realizes a set of functions that are required by the process. A function
required by a process is represented by a related product function, cf.
Figure 6.17.
Moreover, the product function realizes some capability that is required
by the process in order to fulfill some product property. In Figure 6.18
6.2. Validation of the Information Model 131

role name
required Joining 10310025

process requirement
process process_function_association product_function

id
001

Figure 6.17. The representation of a functional requirement on a

manufacturing resource.

the delivered capability is represented by the capability mechanism.

external_reference_ external_identifier
71DCDF1457C01
data_library

role
realizes
definition

related relating
capability capability_function_association product_function

id
capability 001

capability_property_value_association minimum 30 units/hour

limit

value limit_qualifier unit_name

specified_value unit
property_value_representation value_limit unit

Figure 6.18. The representation of a functional requirement and the

capability the function is required to realize.

In this case the joining capability is represented as the definition of the

product requirement in Figure 6.18. The capability is defined as the
ability to join two or more parts together. The property associated with
the capability specify that the function realizes a capability of joining a
minimum of 30 units per hour. The definition of the capability itself is
represented by an entry in an ISO13584-25 (Parts Library) dictionary,
cf. Figure 6.19.
For each functional requirements, such as the assembling 10310025
function, were then a conceptual manufacturing solution developed.
132 Chapter 6. Validation of the Information Model

Figure 6.19. The representation of the definition of the joining ca-

pability in the PLibEditor application.

The conceptual manufacturing solution for the assembling 10310025

function is presented in Figure 6.20.

name role
Conceptual sketch description

assigned_document
document document_assignment

is_assigned_to

relating product_structure_ related

product_function product_component
relationship

name relation_type name

Assembling 10310025 realization Spot weld cell

Figure 6.20. The representation of functional requirement and con-

ceptual solution.

The product component called spot weld cell represent the concept of
the solution that ABB BiW are developing for Scania. Different types
of information may be associated with it to describe the concept, e.g.
documents, as in Figure 6.20, and properties. Naturally, documents
and properties may also be used to describe a product function.
Another useful mechanism is the constraint mechanism. It enables
the assignment of a design constraint to, e.g., a product component.
A design constraint constrain the possible realizations to a concept
6.2. Validation of the Information Model 133

represented by a product component. This may be used to constrain,

for instance, the maximum cost of a concept, as in Figure 6.21.

name name
Spot weld cell Cost

is_constraining design_constraint_ is_based_on

product_component design_constraint
association

described_element

describing_property_value
property_value_representation item_property_association

specified_value unit
value_limit unit

limit_qualifier limit unit_name

maximum 1200000 SEK

Figure 6.21. The representation of the constraints on a product

component.

The constraint should be interpreted as an upper limit of the cost of the

product component. That is, the product component, i.e. the concept,
must not cost more that 1.2 million SEK to realize. Naturally, such a
limitation decreases the number of solutions that can be considered.
As the development process continues the description of the desired
function of the solution becomes more and more detailed by decompo-
sition, cf. Figure 6.22. This is, of course, succeeded by a decomposition
of the concepts too to match each functional requirement. Analogously,
a design constraint, such as the maximum cost, may also be decom-
posed and related to each, e.g., sub-component.
In Figure 6.22 the assembling function is decomposed in a spot weld-
ing function, a transporting function, and a storing function. These
functions can then be related to their conceptual solution respectively,
as in Figure 6.20. In this case the spot welding function was related
to a stationary spot welding component, the transporting function was
related to a robot with a gripper component, and the storing function
was related to a buffer component.
134 Chapter 6. Validation of the Information Model

name relation_type
Assembling decomposition

relating product_structure_ related name

product_function product_function Spot welding
relationship

relation_type
decomposition

relating product_structure_ related name

product_function Transporting
relationship

relation_type
decomposition

relating product_structure_ related name

product_function Storing
relationship

Figure 6.22. The representation of a decomposed function.

In parallel with the development of the manufacturing equipment, ABB

BiW also started to develop the process plan. This is mainly done by
adding information to the already existing process plan for a more
detailed description of how to manufacture the carrier frame assembly.
Hence, in a similar way as with the functions and the concepts, the
manufacturing process 020 was also decomposed. Two of the decom-
posed processes are shown in Figure 6.23. Analogous with process 020,
each of its subprocesses were associated with a process definition.

process_identifier
process 020
relation_type
decomposition

relating related process_identifier

process_relationship process 020.010

relation_type
decomposition

relating related process_identifier

process_relationship process 020.020

Figure 6.23. The representation of a decomposed process.

The same type of processes are, naturally, associated with the same
process definition, e.g. the weld processes for each weld spot. Conse-
6.2. Validation of the Information Model 135

quently, the processes in Figure 6.23 that represent the welding of two
different weld spots are both related to the same process definition.
As the process 020 is being detailed, information about the product
needed to describe what to do in a particular process is also associated
with that particular process. In Figure 6.24 a process state of the carrier
frame assembly is the input to the process020.020 and another process
state is the output.

020.020 input 10310025_0002 10310025_0001

process_identifier role id id

process element related_item_definition

process_input_output process_state

output 10310025_0003
process mating_definition
role id

process element
process_input_output process_state
related_item_definition

Figure 6.24. The representation of input and output of a process.

The input describe the product as it is before the process and the
output as it is after the process. The process state is used because
the 10310025 carrier frame assembly is in an intermediate state, i.e.
neither is this the first process nor the last process that are needed in
order to manufacture the carrier frame assembly.
If instead it would have been the first process of the process plan,
i.e. where the first geometrical weld spot was welded, the input would
have been the two single instance objects representing instances of the
constituents and the output would have been a process state. Similar,
if it would have been the last process the input would have been a
process state and the output would have been the mating definition,
which would represent the finished carrier frame assembly.
Note also that each process state is related to this mating definition by
the related item definition. This is to specify the final product of which
they are intermediate states.
136 Chapter 6. Validation of the Information Model

For each input a concerned detail may also be associated. The con-
cerned detail specify the detailed information about the product that
is necessary to carry out the process. In this case, a weld spot, mating
element, is a concerned detail, cf. Figure 6.25.

process_identifier
process 020.020
role
input

process element id
process_input_output process_state 10310025_0002

concerned_detail [0:?] placement

mating_element transformation_3d

direction_of_axis A[1:3] A[1:3]

[[0,0,0], [0,10,0],[0,0,0]]

Figure 6.25. The representation of concerned detail and transfor-

mation of a process input.

In addition, a transformation of the input may be associated. The

placement specify the transformation of coordinate space of the input
to the reference coordinate space of the process. The reference coordi-
nate space of the process is the coordinate space in which the process
is defined or the coordinate space in which the reference resource is
defined, cf. Figure 5.26 and Figure 6.26 respectively.
Later in the development process, when a decision to use a particular
manufacturing concept have been made, the particular manufacturing
concept is associated with the concerned manufacturing process. This
provide an ability to document, already in the conceptual phases, what
resources that are to carry out what processes.
In Figure 6.26 the weld process 020.020 is associated with the concept
of using a stationary spot welding unit, represented by the product
component, as a manufacturing resource. In addition to the stationary
spot welding unit, other resources may also be associated with the same
process, e.g. the manufacturing resource that will hold and position the
product in order for the weld spots to be welded.
6.2. Validation of the Information Model 137

process_identifier
process 020.020

reference_resource
TRUE

process
respource_definition
process_resource_assignment product_component

name

Stationary spot
welding unit

Figure 6.26. The representation of a process and its manufacturing

resource concept.

process_identifier reference_resource inventory_number

020.020 TRUE 3092852

process respource_definition
process process_resource_assignment physical_instance

serial_number
901206686

id is_realization_of
1000325_0001 design_discipline_item_definition

Figure 6.27. The representation of a process and its physical man-

ufacturing resource.
138 Chapter 6. Validation of the Information Model

Naturally, as the design of the manufacturing system solution evolves

more and more detailed information is created and stored in the model.
Finally, when the development project is finished, and all the serial
numbers and inventory numbers of the physical manufacturing equip-
ment is known, it is possible to represent exactly what physical resource
that are to carry out a particular process. In Figure 6.27 the station-
ary weld gun is presented. Its serial number is 901206686, which is
different from the Scania inventory identification 3092852.

6.3 Test of the Hypotheses

In Section 6.2 the PPR information model was validated. That is, it
was instantiated to test that it could represent the information it was
intended to represent. This was done by using information from a real
case at Scania involving spot welding processes. Since the model is a
reflection of Hypothesis 5.1 and Hypothesis 5.2, the hypotheses were
tested as well.
The first hypothesis deal with the effects of the separation between the
generic and specific information concepts. The information concepts
behind the process plan and its processes have been considered generic
information concepts and has, thus, been represented within the PPR
information model. The definitions of specific types of processes have
been considered specific information concepts and has, thus, been rep-
resented by instantiation of the PPR information model; in this case
with the general classification mechanism.
It was shown in the Scania case that the PPR information model could
represent a spot welding process. The definition of the process is repre-
sented by the process definition. The definition of the type of process,
i.e. the spot welding process, is represented by the general classification
and a reference to an external reference data library, in this case based
on ISO13584-25. It is clear from Figure 6.28 that adding instances of
general classification to represent any process type will not affect the
representation of a process.
6.3. Test of the Hypotheses 139

classified_element definitional
BOOLEAN

classificatied_element_select classification_association

role
associated_classification STRING

ISO10303-
process_definition
214.general_classification

Figure 6.28. The separation between the process mechanism and

the classification mechanism makes it possible to represent any type
of process with the same process mechanism.

The infrastructure of the PPR information model can remain and, still,
process types that were not thought of when the PPR information
model was developed can be represented. This has been achieved by
separating the generic information concept, the process represented by
the process definition, from the specific information concept, the type
of process represented by the general classification. The model can,
thus, represent any type of process with the same process mechanism.
Consequently, the test of the model has not been able to falsify Hy-
pothesis 5.1 and, thus, the hypothesis has been corroborated.
The second hypothesis deal with the effect of modularization of infor-
mation models. One affect is that of updating parts of the information
model without affecting other parts of the model, i.e. functional sepa-
ration. This has not been tested by the Scania case. However, it can be
tested by logical reasoning. The information in the process plan core
model is separated from non core information by interface mechanisms,
such as the plan produced output mechanism in Figure 5.31.
This mechanism is presented again in Figure 6.29 in two variants. The
upper variant is the same as the one that is used in the PPR information
model. The lower variant is modified to use another representation of
product information. It is clear that the part of the information model
representing the product is changed while the representation of the
process plan version remain unaffected. The change only affect one
side of the interface mechanism, the plan produced output association.
140 Chapter 6. Validation of the Information Model

plan produced_output
process_plan_version plan_produced_output_association produced_output_select

ISO10303-
214.item_version

ISO10303-
214.product_component

plan produced_output ISO10303-

process_plan_version plan_produced_output_association
41.product_definition_formation

Figure 6.29. The interface plan produced output mechanism makes

it possible to update or change the model representing a produced
output without affecting the representation of a process plan version.

Consequently, the hypothesis has been tested and was not falsified.
This leads to the conclusion that non of the hypotheses were falsified
by the tests. Hence, both Hypothesis 5.1 and Hypothesis 5.2 were
corroborated.
Chapter 7

Discussion and Conclusions

The purpose of this chapter is threefold. First, to interpret and ex-

plain the result by indicating its strengths and points of improvement.
Second, to relate the result to previous work in the area. Third, and
finally, to indicate neglected areas where further research is necessary
and conclude the thesis.

7.1 Discussion

In this thesis information requirements for process planning in the

context of concurrent engineering have been identified. The identi-
fied information requirements have been formalized and represented
in an information model using the EXPRESS-language. The informa-
tion model was then used to represent information from a Scania-ABB
BiW project, the Robot Cell - 0020 project, where a robot cell for spot
welding of the 10310025 Carrier Frame Assembly was developed.

141
142 Chapter 7. Discussion and Conclusions

7.1.1 Strengths and Implications of the Results

The use of information from the Robot Cell - 0020 project to popu-
late the PPR information model corroborated its practical use. It was
shown that the PPR information model could represent information
about such things as the carrier frame assembly in terms of, e.g. its
identification and weld spots, the project in terms of, e.g. work re-
quests and activities, and the processes in terms of, e.g. process plans
and processes. In addition, its ability to represent information about
capability, documents, functional requirements, and concepts was also
shown.
Furthermore, important connections between products, manufacturing
processes, and manufacturing resources were identified. These were
the obvious connections such as input and output of a process, and
executing manufacturing resource, but also connections such as the
connection between a process and a functional requirement on a man-
ufacturing resource. This connection provided a mechanism that can
document the source of a functional requirement, i.e. its reason to be.
An implication of this is that the PPR information model enables con-
ceptual process planning. The PPR information model can represent
information about products, manufacturing processes, and manufac-
turing resources at the early stages when the detailed design is not
yet established. In addition, the PPR information model can represent
information about detailed design, as well as its evolution from con-
ceptual design. Consequently, manufacturing related decisions taken
in the early product realization process can be documented in terms
of process and resource design objects. This enables traceability of the
evolution of the product, process, and manufacturing resource designs
and their interrelationship.
The rationale behind a particular decision may also be documented,
e.g. in a text-document, and related to a particular design object.
Hence, the rationale behind the decision taken to choose a particular
design solution can be traced as well.
Traceability of the result of a made decisions and its rationale, in turn,
7.1. Discussion 143

enables an efficient project follow-up for quality improvement of design

solutions, and improvement of the development process as a whole.
For instance, a malfunction in a final product may be traced back to
where the source for the malfunction was introduced. In some cases this
may lead back as far as to a bad decisions to use a particular function
to fulfill a customer requirement, or to use a particular concept to
realize a functional requirement. Documenting the decisions enables
an organization to trace this, identify the source of the problem, and
avoid it in future development projects.
Consequently, the PPR information model provides a base for imple-
menting an information system for concurrent engineering in an orga-
nization. This is independent of if the information system is human,
digital, or a mix thereof.
Furthermore, the two hypotheses that were developed and corroborated
have a positive affect on the longevity of information models. Modu-
larization, in turn, enables information modules to be updated without
affecting other information modules of an information model. In addi-
tion, an information model may, by modularization, be common for a
whole company; some modules will be common for all departments of
the company while other modules will differ. This would enable an ef-
ficient information sharing between departments through the common
information modules.
The lessons learned from the research have also been used in the PDT-
net1 project. The contributions have mainly been on the use of ISO103-
03-214 for communication of manufacturing system development data,
including process plans; on the content of the PDTnet-schema2 ; and on
the development of an export interface from Tecnomatix eM-Planner
to PDTnet-schema.

1
The PDTnet project is a joint European project involving companies within
the automotive industry, such as BMW, Bosch, DaimlerChrysler, Delphi, Scania,
and Volkswagen.
2
The PDTnet-schema is an XML-schema based on part of the ISO10303-214.
The schema was configured and developed in the PDTnet project.
144 Chapter 7. Discussion and Conclusions

Finally, a detail in the process plan mechanism of the PPR informa-

tion model, the process definition. The concept of a process definition
is a powerful mechanism that enables the reuse of process definitional
information in one or multiple process plans. This idea was, in collabo-
ration with Mattias Johansson3 , also introduced in ISO10303-214, and
accepted as part of the international standard.

7.1.2 Points of Improvement

A model can never be complete because it is a simplification of the

things in the real world. If it would be complete it would be the real
world. Consequently, the PPR information model has a limit universe
of discourse and does not cover all aspects of the real world.
Its universe of discourse is a reflection of how the researcher, i.e. the
author of this thesis, have interpreted the real world, and how the
researcher have decided to express this interpretation in the EXPRESS-
language. Hence, all aspects of the information model is colored by
how the researcher understand and interpret the real world and the
researchers ability to express this interpretation.
Other researchers may understand and interpret the real world differ-
ently, all colored by their own pre-understanding of, in this case, the
innovation process in general and the process planning activity in par-
ticular. They may identify requirements that they find important and
that have not been identified here. This will be more frequent in areas
where little, or no, research and modeling have been done, and the ar-
guments and criticism in these areas will probably be more aggressive.
Typically these areas are: (i) capability, (ii) location system, and (iii)
mating.
As these three areas are quite new in the information-modeling soci-
ety they are also, most likely, the parts of the PPR information model

3
Mattias Johansson is a former researcher in the research group at the Computer
Systems for Design and Manufacturing at Kungliga Tekniska Högskolan, Sweden.
7.1. Discussion 145

where most improvements can be made. Especially, more considera-

tion could have been put on how the feature concept is related to the
concepts of capabilities, location systems, and matings.
In addition to questions that may be raised about capability, location
system, and mating, questions related to terminology, definitions, rela-
tionships, level of detail of the model, level of abstraction of the model,
modeling technique, and modeling philosophy may also be raised. For
instance, can matings be represented in another and better way? Prob-
ably, or rather, most certainly, depending also on who you ask and this
persons interpretation of the intention and purpose of the model.
Misinterpretation is also minimized by using a consistency throughout
the information model. This concern both the terminology and the in-
formation concepts. It is important to decide, beforehand, on a naming
convention so that the same concept have the same name throughout
the model. This count for the information concepts as well, i.e. that
similar information concepts in the model will be represented by similar
modeling mechanisms.
This may be difficult, especially since there is a lack of established
and formally documented methodological approaches to information
modeling. It may even be difficult to keep the consistency when only
one person is involved in the modeling activity. In the PPR information
model this can be noted in, e.g., the use of reference data libraries
for classification of process definitions, and for definition of capability.
Naturally, a process definition could have been classified with the same
mechanism as a capability.
Furthermore, the use of ISO10303-214 also complicated the consistency
in naming convention and how similar concepts were represented. A
typical example is that the attribute used to identify a particular ob-
ject, e.g. a product, is called identifier in the PPR information model,
whereas ISO10303-214 usually call this id. The definition and meaning
is the same, but the references to the definition differ.
The naming and representation of some concepts in ISO10303-214 also
led to compromises in naming and representation of some concepts in
146 Chapter 7. Discussion and Conclusions

the PPR information model. In particular this is true for the mating
definition and the mating element. Terminology wise the preferable
terms would have been joint and joining element. Representation wise
the mating definition mechanism in ISO10303-214 need further devel-
opment. An example of a limitation is that the mating definition is not
actually a joint, it is a view of the product from a mating perspective.
In this view the equivalence to joints and joining elements cannot be
identified.
The attempt in the PPR information model has been to use the mating
definition not only as a view but as a joint. Then the mating element
was added to uniquely identify a single joining element within a par-
ticular joint. A better solution would have been to develop and add
a joint definition mechanism, which could have included joints, joining
elements, and new relations to the design discipline item definition and
the item instance entities.
Modularization of information models seem to have the same affect
on information models as on products, e.g. carry over and technology
development. However, modularization could have been used in a more
structured way and more consistent throughout the PPR information
model. For instance, could the Modular Function Deployment4 (MFD)
method have been applied? A more systematic and consistent way
could also have been used when developing the interfaces between the
different modules.
Finally, some thoughts on the choice of research subject. During the
course of the research project it has been identified, as already men-
tioned, that no real methodology for information modeling exist. This
would have been an interesting research subject with a high quality of
novelty. The subject was touched upon during the discussion and test-
ing of the hypotheses but need further investigation and development.
For instance, what modularization methods exists that can be applied
on information modeling, and how can they be applied?

4
For further reading on Modular Function Deployment see (Erixon, 1998)
7.1. Discussion 147

7.1.3 Fulfillment of Research Objectives

In the beginning of the research project two research objectives were

set, cf. Section 1.2. The two objectives were then used as a base
to formulate the three research questions that was used to guide the
research project. Have the effort made in the research project resulted
in answering these questions?
Research question 1. What information is needed for process plan-
ning?
Research question 2. What information is needed to describe the
relationships between products, manufacturing processes, and manu-
facturing resources?
Research question 3. How can the information be structured in an
information model?
From the discussion in Section 7.1.1 and Section 7.1.2 it is clear that
the first and second questions have been answered by the information
model. That is, the PPR information model represent the information
requirements for process planning in the context of concurrent engi-
neering.
The third question is also answered by the information model, i.e. the
information model describe how in terms of the relationships between
different information concepts. However, the third question could also
be interpreted so that the expected result would be an information
modeling methodology. The two corroborated hypotheses clearly is a
result that would apply within the methodology domain. They indicate
how information can be structured, and what the expected effects are.

7.1.4 Related Research

The findings of this thesis have similarities and differences to findings

made by other researchers. In this section, some of the similarities
and differences will be pointed out and discussed. Five aspects of the
148 Chapter 7. Discussion and Conclusions

findings will be discussed: (i) the overall structure of the information

model, (ii) representation of manufacturing processes, (iii) conceptual
process planning, (iv) capability, and (v) weld joints.

Structure of the Information Model

The PPR information model is structured according to the idea of

having a process plan core model, which is separated from other types
of information by an interface. In literature, when process planning is
discussed, different types of information is often clearly separated. For
instance, Eversheim et al. (1991); Eversheim and Westekemper (2001);
Feng and Song (2000); and Kimura (1993) clearly separate what is
manufactured, the manufacturing process itself, and the manufacturing
resources that carry out the manufacturing process.
However, Eversheim et al. (1991) and Kimura (1993) do not define
information models. Their focus is to discuss the relationships between
the different models and how the engineering task can benefit from
using information from different domains.
Eversheim and Westekemper (2001); and Feng and Song (2000), on
the other hand, define information models that have a similar content
as the PPR information model. However, the structural differences
are that both Eversheim and Westekemper (2001) and Feng and Song
(2000) do not clearly separate the representation of different types of
information with an interface. Consequently, a change to part of the
models may have considerable effects on other parts.
The separation between different types of information is more clear
in the work that Johansson (2001) has done on ISO10303-214. It is,
however, no indication that there is a formalized method behind this
separation, neither is the separation consistent throughout ISO10303-
214.
In general, the structure, and intention of separating different types of
information, are similar with what other have done. In more detail,
7.1. Discussion 149

though, other researchers do not seem to share the same philosophy of

how this separation should be modeled.
A clear disadvantage here is that no well defined information modeling
methodology exists today. Not in general and not when modulariza-
tion is considered. Within the ISO10303 there is a work focusing on
modularization of several of the different parts of the standard. Their
work have, however, not yet been documented, methodology wise.

Representation of Processes

When representing manufacturing processes two fundamentally differ-

ent approaches can be identified. These two approaches are here called
the specific and the generic approach. The difference between these
approaches is that whereas the specific approach specifically define dif-
ferent types of processes, e.g. the model developed by Feng and Song
(2000), the generic approach does not, e.g. the model developed by
Eversheim and Westekemper (2001) and the process plan core model.
Obviously, a specific approach will be obsolete whenever a new process
type is developed. This will also be the case if not all process types were
considered when the model was developed. A problem that does not
occur in the general approach as the process representation is general
and no specific process type is indicated in the model. On the other
hand, the generic approach has its limitations in that the semantics of
the type of process may be lost.
This problem can, however, be solved by using an external dictionary,
e.g. a reference data library like ISO13584. The process plan core
model make use of an external dictionary for representing classification
of processes. This is not the case in the model developed by Eversheim
and Westekemper (2001), but it has another advantage in terms of
generality. It is not limited to manufacturing processes. It can, in
fact, represent any types of processes, including product development
processes, which is also the case with the Process Specification Language
(ISO/TC184/SC4, 2000).
150 Chapter 7. Discussion and Conclusions

An important aspect of process representation that separates these

models from the process plan core model is that of the ability to reuse
different processes without redefining them. Lutters et al. (1999) indi-
cate that implemented methods, i.e. process definitions, may be used
as a set of capabilities that are available, which may be used as an
information base to constrain a product design. A process definition
mechanism is available in the process plan core model. Hence, the pro-
cess plan core model enables the reuse of process definitions, which in
turn may be used as an information base for product design constraints.
The concept of a process definition mechanism is also available in the
ISO10303-214. The reason is, which was mentioned earlier, that the
author of this thesis and Mattias Johansson have, in collaboration,
introduced this concept and mechanism in the standard.

Conceptual Process Planning

In Section 6.2 it was shown that the PPR information model can be
used to create a development process where process planning is an
active part of the development of a manufacturing system. This is
clearly different from traditional process planning, cf. Curtis (1988)
and Ham and Lu (1988), where manufacturing resources are selected
rather than developed.
Feng and Song (2000) use the term concept process planning for an ac-
tivity where manufacturability is assessed and cost is estimated. They
continue to describe this as determining the processes and selecting
the manufacturing resources. Hence, it is a traditional way of plan-
ning, only earlier. This is clearly different from being an active part of
manufacturing system development.

Capability

Capability is usually represented in mathematical and numerical mod-

els (Kulvatunyou and Wysk, 2000), such as the 6 σ or six standard
deviations (Juran, 1988), or the loss function (Taguchi et al., 1989).
7.1. Discussion 151

The focus of these models are usually on the probability of a manu-

facturing resource to achieve something within the tolerances, e.g. the
finish of a surface or the fitting of parts in an assembly. Naturally
this is an important aspect of manufacturing, but the mathematical
and numerical models that Bergman and Klefsjö (1998); Curtis (1988);
Juran and Gryna (1988); and Taguchi et al. (1989) use does not say
anything about the ability of a manufacturing resource to make, e.g.,
a particular shape or a particular joint, nor its ability to operate on a
particular material. The intention of the capability mechanism in the
information model of this thesis is to enable the definition of any type
of capability.

Weld Joints

A lot of research have been conducted in the area of weld joints. Mainly
the research have been related to how the material is affected, the weld
process itself, or how to design a weld joint, e.g. Ceglarek and Shi
(1998); Zhang et al. (2000); and Zhang et al. (2002). However, in the
area of information representation of weld joints the research work is
sparse.
Though a few exceptions exists. For instance, in Germany the GACI
project (German Automotive CATIA Initiative) have been working on
how to represent connections, including weld joints, in CATIA (Viel-
haber, 2003). Similarly, Porsche have started to work on how to rep-
resent fasteners, including weld joints, in ISO10303-214 (Rosenthal,
2002). Some initial approaches on joint representation have also been
made by Holmer et al. (1990); and Kjellberg (1984, 1987, 1988).

7.1.5 Identification of Further Studies

Most of the areas where further studies are necessary have already been
indicated in the previous text. Thus, this section will merely summarize
and make a list of these studies.
152 Chapter 7. Discussion and Conclusions

Further studies could take two directions, studies on principles of infor-

mation modeling, and information requirements on process planning:

• Principles of information modeling:

– Activity modeling - investigate and formalize the use of ac-

tivity modeling to support information modeling.
∗ Multiple activity models - investigate how different ac-
tivity models can be used together. Develop prototype
software that make use of different activity models, but
with the same information base.
∗ Support for information modeling - formalize the use of
activity modeling to support information modeling.
– Modularization - investigate how modularization can be used
in information modeling. How should modules be created
and what are the criteria? How should interfaces be cre-
ated?
– Reference data libraries, such as ISO13584 - investigate how
reference data libraries can best be used to benefit from
both having a generic and specific model. What reference
data libraries exist? How should the reference mechanism
be modeled? What should be part of the information model
and what should be part of the reference data library?
– Methods, such as axiomatic design (Suh, 1990) - structured
approaches for information modeling and criteria for infor-
mation models are needed. What constructs are better in
particular situations? What level of detail is suitable? What
level of abstraction is suitable?

• Information requirements on process planning:

– Capability - investigate further how capability should be

represented. What is capability? What characterizes differ-
ent types of capabilities?
7.2. Conclusions 153

– Joints5 - investigate further how joints should be represented.

What are the different types of joints? What characterizes
the different types of joints? How should these character-
istics be represented? How can ISO13548-511 be used for
classification/definition of joining elements, or fasteners?
– Location system - investigate further how location systems
should be represented. How should the relation between lo-
cation systems be represented, e.g. location point on prod-
uct and clamp on a fixture?

7.2 Conclusions
As already mentioned, the research project presented in this thesis have
identified information requirements for process planning in the context
of concurrent engineering. These requirements have been in an infor-
mation model using the EXPRESS-language. From the project and
the work with the PPR information model the following conclusions
have been made:

• The PPR information model represent identified information re-

quirements for process planning.

• Important connections between the product, process, and man-

ufacturing resource has been identified by the PPR information
model, e.g. input, output, and functional connections.

• The PPR information model provides a base for an information

platform in a concurrent engineering environment.

• Documentation of decisions made in the early stages of a product

realization project is important for traceability and continuous
improvements.
5
In the PPR information model joints have been called a matings. However,
there is a need to clearly separate these two concepts in an information model.
154 Chapter 7. Discussion and Conclusions

• Separation of generic and specific information concepts, as de-

scribed in this thesis, affect the longevity of information models
positively.

• Mating and joint are both important concepts and should be

clearly separated in an information model.

• Modularization of information models enables an efficient main-

tenance of information models and information systems.

• Modularization of information models enables the reuse of the

representation of information concepts.

• Modularization affect the longevity of information models posi-

tively.

• Modeling and representation of concepts must be further devel-

oped, e.g. the use of dictionaries and ontology.

• Better methods to support information modeling need to be de-

veloped.

• Modularization of information models need further investigation.

• Representation of joints, capability, and location systems need

further development.

• The ISO10303-214 need further development in terms of repre-

senting joints.
Bibliography

Al-Timimi, K. and MacKrell, J. (1996). STEP: Towards Open Systems.

CIMdata Inc. ISBN 1-889760-00-5.

Algeo, M. E. A. (1994). A State-of-theArt Survey of Methodologies for

Representing Manufacturing Process Capabilities. Technical report,
National Institute of Standards and Technology. NISTIR 5391.

American Heritage (2000). Dictionary of the English Language.

Houghton Mifflin Company.

Andreasen, M. M. (1991). The Theory of Domains. In Proceedings of

Workshop on Understanding Function and Funtion-to-Form Evolu-
tion. Cambridge University.

Andreasen, M. M. and Hein, L. (1987). Integrated Product Develop-

ment. Springer-Verlag. ISBN 0-948507-21-7.

Askin, R. G. and Stanridge, C. R. (1993). Modeling and Analysis of

Manufacturing Systems. John Wiley & Sons. ISBN 0-471-51418-7.

Azari, M. (1990). An Intergrated and Interactive Process Planning

System Based on Product Model and AI. Licentiate thesis, Kungliga
Tekniska Högskolan. ISSN 0280-2074.

Bauer, A., Bowden, R., Browne, J., Duggan, J., and Lyons, G. (1991).
Shop Floor Control Systems - from Design to Implementation. Chap-
man & Hall. ISBN 0-412-36040-3.

155
156 BIBLIOGRAPHY

Bergman, B. and Klefsjö, B. (1998). Quality - from Customer Need to

Customer Satisfaction. Studentlitteratur. ISBN 91-44-46331-6.

Bollinger, J. G., Benson, D. K., Cloud, N., Forward, G., Fossum, B. M.,
Frey, D. N., Hagen, D. F., Jordan, J., Majchrzak, A., Meieran, E. S.,
Miska, D., Rhoades, L. J., and Wong, E. (1998). Visionary Man-
ufacturing Challenges for 2020. National Academy Press. ISBN
0-309-06182-2.

Booch, G., Rumbaugh, J., and Jacobson, I. (1999). The Unified Mod-
eling Language User Guide. Addison-Wesley. ISBN 0-201-57168-4.

Boothroyd, G., Dewhurst, P., and Knight, W. (2002). Product Design

for Manufacturing and Assembly. Marcel Dekker. ISBN 0-8247-0584-
X.

Boothroyd, G. and Radovanovic, P. (1989). Estimating the Cost of

Machined Components During the Conceptual Design of a Product.
In Annals of the CIRP, volume 38, pages 157–160.

Brown, K. N., Sims Williams, J. H., and McMahon, C. A. (1992).

Grammars of Features in Design. In Gero, J. S., editor, Artificial
Intelligence in Design ’92. Kluwer Academic.

Brunnermeier, S. B. and Martin, S. A. (1999). Interoperability Cost

Analysis of the U.S. Automotive Supply Chain. Final report,
NIST/RTI. RTI 7007-03.

Carlsberg (1997). Produktionsutvecklingsprocessen. Carlsberg, Stock-

holm, Sweden. Internal document.

Ceglarek, D. and Shi, J. (1998). Design Evaluation of Sheet Metal

Joints for Dimensional Integrity. Journal of Manufacturing Science
and Engineering, 120(4):781–792.

CEN/TC310 (2002). Enterprise Integration - Decision Reference

Model. European Committee for Standardization. New work item
(NWI).
BIBLIOGRAPHY 157

Chalmers, A. F. (1999). What is This Thing Called Science. Open Up.

ISBN 0335201091.

Chen, P. P.-S. (1976). The Entity-Relationship Model - Towards a

Unified View of Data. ACM Transactions on Database Systems.

Clausing, D. P. (1994). Total Quality Deployment. ASME Press.

Cooper, R. G. (2001). Winning at New Products: Accelerating the

Process from Idea to Launch. Perseus Publishing.

Curtis, M. A. (1988). Process Planning. John Wiley & Sons. ISBN

0-471-83254-5.

Davenport, T. H. (1993). Process Innovation. Harward Business School

Press. ISBN0-87584-366-2.

Davenport, T. H. and Prusak, L. (1998). Working Knowledge. Harward

Business School Press. ISBN 0-87584-655-6.

Dürr, H. and Schramm, M. (1997). Feature Based Feedback into the

Early Stages of Design. European Journal of Operational Research,
100:338–350.

Edlund, P.-O. and Högberg, O. (1997). Beslutsmodeller i praktisk

tillämpning. Studentlitteratur. ISBN 91-44-44093-6.

Ejvegȧrd, R. (1996). Vetenskaplig metod. Studentlitteratur, second

edition. ISBN 91-44-36612-4.

Eppinger, S. D., Whitney, D. E., P., S. R., and Gebala, D. A. (1994). A

Model-Based Method for Organizing Tasks in Product Development.
In Research in Engineering Design, volume 6, pages 1–13.

Ericsson (2001). The RSA Development Process - A PROPS Applica-

tion. Ericsson Corporation, Stockholm, Sweden. Internal document.

Erixon, G. (1998). Modular Function Deployment - A Method for Mrod-

uct Modularisation. PhD thesis, Kungliga Tekniska Högskolan. ISSN
1104-2141.
158 BIBLIOGRAPHY

Eversheim, W., Bochtler, W., Gräß ler, R., and Kölscheid (1997). Si-
multaneous Engineering Approach to an Integrated Design and Pro-
cess Planning. European Journal of Operational Research, 100:327–
337.

Eversheim, W., Marczinski, G., and Cremer, R. (1991). Structured

Modeling of Manufacturing Processes as NC-Data Preparation. In
Annals of the CIRP, volume 40, pages 429–432.

Eversheim, W. and Westekemper, M. (2001). Integrated Product and

Process Model of SFB (Collaborative Research Center) 361. Science
& Research, (2).

Fagerström, J., Aganovic, D., Nielsen, J., and Falkman, P. (2002).

Multi-Viewpoint Modeling of the Innovation System - Using a
Hermeneutic Method. In International Conference on Axiomatic De-
sign - ICAD2002.

Fagerström, J. and Moestam-Ahlström, L. (2001). Demands on Meth-

ods for Development Work Focused on Concurrent Engineering.
In International Conference on Production Research. ISBN 80-02-
01438-3.

Feng, S. C. and Song, E. Y. (2000). Information Modeling of Concep-

tual Process Planning Integrated with Conceptual Design. In ASME
- Design for Manufacturing.

Fishwick, P. A. (1995). Simulation Model Design and Execution: Buld-

ing Digital Worlds. Prentice-Hall. ISBN 0-13-098609-7.

Føllesdahl, D., Walløe, L., and Elster, J. (1993). Argumentationsteori,

Språk och Vetenskapsfilosofi. Thales. ISBN 91-87172-69-0.

Gallaher, M. P., O’Connor, A. C., and Phelps, T. (2002). Economic

Impact Assessment of the International Standard for Exchange of
Product Model Data (STEP) in Transportation Equipment Indus-
tries. Final Report, NIST/RTI. RTI 7007-16.
BIBLIOGRAPHY 159

Gindy, N. and Ratchev, T. (1992). A Reference Model for Generative

Planning Systems. In CIRP International Seminar on Manufactur-
ing Systems, pages 61–69.
Ham, I. and Lu, C. Y. (1988). Computer-Aided Process Planning: The
Present and the Future. In Annals of the CIRP, volume 37, pages
591–601. Technische Rundschau. ISBN 3-905-277-10-7.
Haudrum, J. (1994). Creating the Basis for Process Selection in the
Design Stage. PhD thesis, Technical Univeristy of Denmark.
Hicks, B. J., Culley, S. J., Allen, R. D., and Mullineux, G. (2002). A
Framework for the Requirements of Capturing, Storing and Reusing
Information and Knowledge in Engineering Design. International
Journal of Information Management, 22:263–280.
Hitomi, K. (1979). Manufacturing Systems Engineering. Taylor &
Francis. ISBN 0-85066-177-3.
Holmer, B., Kjellberg, T., Fentorp, K.-O., Johansson, B., Stark, B., and
Stenviken, B. (1990). Verkstadsföretaget som informationssystem.
Styrelsen för Teknisk Utveckling. ISBN 91-7850-162-8.
Hubka, V. and Eder, W. E. (1988). Theory of Technical Systems -
A Total Concept Theory for Engineering Design. Springer-Verlag.
ISBN 3-540-17451-6.
Ignizio, J. P. (1991). Introduction to Expert Systems. McGraw-Hill.
ISBN 0-07-909785-5.
ISO/IEC/JTC1/SC7 (2001). Systems Engineering - System Life-
cycle Processes. International Organization for Standardiza-
tion/International Electrotechnical Commission. ISO/IEC CD 15288
FCD.
ISO/TC184/SC4 (1994). Industrial Automation Systems and Inte-
gration - Product Data Representation and Exchange - Part 11:
Description Methods: The EXPRESS Language Reference Manual.
International Organization for Standardization, first edition. ISO
10303-11.
160 BIBLIOGRAPHY

ISO/TC184/SC4 (1996). Industrial Automation Systems and Integra-

tion - Industrial Manufacturing Management Data - Resource Usage
Management: Overview and Fundamental Principles. International
Organization for Standardization, cd edition. ISO 15531-1.

ISO/TC184/SC4 (1999). Industrial Automation Systems and Integra-

tion - Integration of Life-Cycle Data for Oil and Gas Production
Facilities - Part 2: Data Model. International Organization for Stan-
dardization. ISO CD 15926-2.

ISO/TC184/SC4 (2000). Process Specification Language: Overview

and Basic Principles. International Organization for Standardiza-
tion. ISO/WD 18629-1.

ISO/TC184/SC4 (2001). Industrial Automation Systems and Integra-

tion - Product Data Representation and Exchange - Part 214: Appli-
cation Protocol: Core Data for Automotive Mechanical Design Pro-
cesses. International Organization for Standardization, first edition.
ISO 10303-214.

ISO/TC184/SC4 (2002). ISO 15531-1 - Manufacturing Management

Data Exchange: Resources Usage Management Data: Resources In-
formation Model: Basic Concepts. International Organization for
Standardization. ISO/DIS 15531-31.

ISO/TC184/SC4/WG3 (1999). Industrial Automation Systems and In-

tegration - Integration of Life-Cycle Data for Oil and Gas Production
Facilities - Part 1: Oveview and Fundamental Principles. Interna-
tional Organization for Standardization. ISO/CD 15926-1.

ISO/TC184/SC5 (2002a). Industrial Automation Systems - Require-

ments for Enterprise-Reference Architectures and Methodology. In-
ternational Organization for Standardization.

ISO/TC184/SC5 (2002b). Industrial automation systems and integra-

tion - Manufacturing software capability profiling - Part 1: Frame-
work for interoperability. International Organization for Standard-
ization. ISO/DIS 16100-1.
BIBLIOGRAPHY 161

Johansson, M. (2001). Information Management for Manufacturing

System Development. PhD thesis, Kungliga Tekniska Högskolan.
ISSN 1650-1888.
Juran, J. M. (1988). Juran on Planning for Quality. Free Press. ISBN
0-02-916681-0.
Juran, J. M. and Gryna, F. M., editors (1988). Juran’s Quality Control
Handbook. McGraw-Hill. ISBN 0-07-033176-6.
Kent, W. (1978). Data and Reality. North-Holland Publishing Com-
pany. ISBN 0-44-85187-9.
Kimura, F. (1993). Product and Process Modeling as a Kernel for
Virtual Manufacturing Environment. In Annals of the CIRP, pages
147–150. ISBN 3-905-277-19-0.
Kimura, F., Kjellberg, T., Krause, F.-L., Lu, S. C.-Y., Olling, G., Suh,
N. P., Tipnis, V. A., and Wozny, M. (1992). The First CIRP Interna-
tional Workshop on Concurrent Engineering for Product Realization.
In Annals of the CIRP, volume 41.
Kjellberg, T. (1982). Integrerat Datorstöd för Mänsklig Problemlösning
och Kommunikation inom Verkstadsteknisk Produktion - En syste-
mansats Baserad på Produktmodeller. PhD thesis, Kungliga Tekniska
Högskolan. ISBN 91-85212-90-3.
Kjellberg, T. (1984). The Integration of CAD/CAM based on Product
Modelling for Better Human Communication. In CIRP International
Seminar on Manufacturing Systems.
Kjellberg, T. (1987). Product Model - Knowledge Bases: A Concept for
Assembly Design, Assembly Systems Design and Assembly Planning.
In IFIP TC5/WG 5.3/IFORS Working Conference on Software for
Factory Automation. Elsevier Science Publisher.
Kjellberg, T. (1988). Tools for Intelligent Human Communication and
Collaboration for Better Manufacturing. In Second Toyota Confer-
ence: Organization of Engineering Knowledge for Product Modeling
in Computer Integrated Manufacturing.
162 BIBLIOGRAPHY

Krause, F.-L., Kimura, F., Kjellberg, T., and Lu, S. C.-Y. (1993).
Product Modelling. In Annals of the CIRP, pages 695–706. ISBN
3-905-277-20-4.

Kulvatunyou, B. and Wysk, R. A. (2000). A Functional Approach to

Enterprise-Based Engineering Activities. Journal of Manufacturing
Systems, 19(2).

Liker, J. K., Ettlie, J. E., and Cambell, J. C., editors (1995). Engineered
in Japan. Oxford University Press. ISBN 0-19-509555-3.

Lutters, D., Wijnker, T. C., and Kals, H. J. J. (1999). Information

Management in Process Planning. In Annals of the CIRP, volume 48,
pages 385–388.

Maglica, R. (1998). Weld Spot Management. Technical report, Volvo

Car Corporation. Volvo Car Corporation internal document.

Mäntylä, M. (1988). An Introduction to Solid Modeling. Computer

Science Press. ISBN 0-7167-8015-1.

Marca, D. A. and McGowan, C. L. (1988). SADT - Structured Analysis

and Design Technique. McGraw-Hill. ISBN 0-07-040235-3.

Mȧrtensson, P. (2000). Conceptual Design of Manufacturing Subsys-

tems. Licentiate thesis, Kungliga Tekniska Högskolan. ISSN 1104-
2133.

Mȧrtensson, P., Fagerström, J., and Nielsen, J. (2002). Co-operative

Digital Projecting of Manufacturing Equipment - Method and Im-
plementation based on STEP and XML. In International Symposium
on Robotics.

McGrath, M. E., editor (1996). Setting the Pace in Product Develop-

ment. Butteworth-heinemann.

McMahon, C. and Browne, J. (1998). CADCAM: Pronciples, Prac-

tice and Manufacturing Management. Addison-Wesley. ISBN 0-201-
17819-2.
BIBLIOGRAPHY 163

Mileham, A. R., Currie, G. C., Miles, A. W., and Bradford, D. T.

(1993). A Parametric Approach to Cost Estimating at Conceptual
Stage of Design. Journal of Engineering Design, 4(2).
Nielsen, J. and Kjellberg, T. (2000). The ISO 10303-214 Process Model
as a Core for a Process Planning Tool. In International CIRP Design
Seminar.
Nijssen, G. M. and Halpin, T. A. (1989). Conceptual Schema and
Relational Database Design: A Fact Oriented Approach. Prentice-
Hall.
Nyqvist, O. and Nielsen, J. (2001). Features as a Part of the Functional
Interface Between Product and Resource: An Approach Based on
Standards. In International CIRP Design Seminar.
Ödman, P. J. (1994). Tolkning Förståelse Vetande - Hermeneutik i
Teori och Praktik. Almqvist & Wiksell. ISBN 91-20-04890-4.
Onosato, M. and Iwata, K. (1993). Development of a Virtual Manufac-
turing System by Integrating Product Models and Factory Models.
In Annals of the CIRP, volume 42, pages 475–478.
Pahl, G. and Beitz, W. (1996). Engineering Design: A Systematic
Approach. Springer-Verlag. ISBN 3-540-19917-9.
Popper, K. (2003). The Logic of Scientific Discovery. Routledge Clas-
sics. ISBN 0-415-27844-9.
Prasad, B. (1996). Concurrent Engineering Fundamentals, volume 1-2.
Prentice-Hall.
Pugh, S. (1998). Total Design. Addison Wesley Longman Limited.
ISBN 0-201-41639-5.
Ray, S. (1989). A Modular Process Planning System Architecture. In
IIE Integrated Systems Conference.
Rosenthal, H. (2002). STEP Body in White Fasteners: A Proposal
for a Specification. Presentation at a meeting of the IGDP (Interest
Group Digital Plant) on November 27, 2002.
164 BIBLIOGRAPHY

Ross, D. T. (1977). Structured Analysis (SA): A Language for Com-

municating Ideas. IEEE Transactions on Software Engineering, SE-
3(1):16–34.

Ross, D. T. and Schoman, Jr., K. E. (1977). Structured Analysis for

Requirements Definition. IEEE Transactions on Software Engineer-
ing, SE-3(1):6–15.

Salomons, O. (1995). Computer Support in the Design of Mechanical

Products. PhD thesis, Univeristy of Twente. ISBN 90-9007877-0.

Scania (1998). Scania Basics - Projektledning - Worldwide. Scania,

Södertälje, Sweden. Internal document.

Schaub, M. (1990). LCC-kalkyl - ett sätt att kunna värdera och jämföra
olika investeringars livstidskostnad. Technical report, IVF/Svenska
Mekanförbundet.

Scheller, A. (1990). Information Modelling for Distributed Applica-

tions. In Second IEEE Workshop on Future Trends of Distributed
Computing Systems, pages 494–500. ISBN 0-8186-2088-9.

Schenck, D. A. and Wilson, P. R. (1994). Information Modeling: The

EXPRESS Way. Oxford University Press. ISBN 0-19-508714-3.

Shipman, D. W. (1981). The Functional Data Model and teh Data

Language DAPLEX. ACM Transactions on Database Systems.

Slack, N., Chambers, S., Harland, C., Harrison, A., and Johnston, R.
(1998). Operations Management. Pitman Publishing. ISBN 0 273
62688 4.

Sobek, II, D. K., Liker, J. K., and Word, A. C. (1998). Another Look
at How Toyota Integrates Product Development. Harvard Business
Review, (July).

Söderberg, R. and Lindkvist, L. (2000). Robust Design & Tolerancing

from Concept to Process Selection. In CIRP International Seminar
on Manufacturing Systems.
BIBLIOGRAPHY 165

Sohlenius, G. (1992). Concurrent Engineering. In Annals of the CIRP,

volume 41/2.

Sohlenius, G. (1998). Promising Principles of Creative and System-

atic Product Realization. In Innovative Produktionstechnik. Hanser
Verlag.

Sohlenius, G. (2000). The Manufacturing System - Our Motor of Wel-

fare. Kungliga Tekniska H¨(o)gskolan. ISSN 1650-1888.

Suh, N. P. (1990). The Principles of Design. Oxford University Press.

ISBN 0-19-504345-6.

Suh, N. P. (2000). Axiomatic Design. Seminar at the Kungliga Tekniska

Högskolan.

Suh, N. P. (2001). Axiomatic Design - Advances and Applications.

Oxford Univerisity Press. ISBN 0-19-513466-4.

Taguchi, G., Elsayed, E. A., and Hsiang, T. C. (1989). Quality Engi-

neering in Production Systems. McGraw-Hill. ISBN 0-07-062830-0.

Tátray, P. (1998). On Decision Structures and Information Require-

ments. PhD thesis, Kungliga Tekniska Högskolan. ISSN 1104-2125.

Tönschoff, H. K. and Zwick, M. (1998). An Integrated Product and

Process Model. In Globalization of Manufacturing in the Digital
Communications Era of the 21st Century, pages 209–219. Kluwer
Academic Publisher.

Ueda, K., Markus, A., Monostori, L., Kals, H. J. J., and Arai, T.
(2001). Emerging Synthesis Methodologies for Manufacturing. In
CIRP Annals 2001 Manufacturing Technology, volume 50.

Ullman, D. G. (1992). The Mechanical Design Process. McGraw-Hill.

ISBN 0-07-112871-9.

Ulrich, K. T. and Eppinger, S. D. (2000). Product Design and Devel-

opment. McGraw-Hill, second edition. ISBN 0-07-116993-8.
166 BIBLIOGRAPHY

Vallhagen, J. (1996). An Axiomatic Approach to Integrated Product

and Process Development. PhD thesis, Chalmers Tekniska Högskola.

van Houten, F. J. A. M. (1991). PART: A Computer Aided Process

Planning System. PhD thesis, Univerity of Twente. ISBN 90-900-
4127-3.

Vielhaber, M. (2003). GACI Project: Body-in-White Connections in

CATIA V5. Presentation at a meeting of the IGDP (Interest Group
Digital Plant) on February 2, 2003.

Volvo (1994). STD 5026,11: Coordinate Systems for Cars. Volvo

Group. Volvo standard.

Volvo (1996). STD 5026,2: Master Location System. Volvo Group.

Volvo standard.

Westin, C. (1973). Existens och Identitet. IMFO-group research report

1973:1, Rotobeckman.

Wingȧrd, L. (1991). Introducing Form Features in Product Models.

Licentiate thesis, Kungliga Tekniska Högskolan. ISSN 0280-2074.

Womack, J. P., Jones, D. T., and Roos, D. (1990). The Machine that
Changed the World. Rawson Associates. ISBN 0-89256-350-8.

Wu, B. (1992). Manufacturing Systems Design and Analysis. Chapman

& Hall, first edition. ISBN 0-412-40840-6.

Yin, R. K. (1994). Case Study Research - Design and Methods. Sage

Publications. ISBN 0-8039-5662-2.

Young, B., Canciglieri, Jr, O., Costa, C. A., Dorador, J. M., Zhao, J.,
and Cheung, W. M. (2000). Information Support in an Integrated
Product Development System. In Integrated Design and Manufac-
turing in Mechanical Engineering.

Zhang, H., Hu, S. J., Senkara, J., and Cheng, S. (2000). Statistical
Analysis of Expulsion Limits in Resistance Spot Welding. Journal
of Manufacturing Science and Engineering, 122:501–510.
BIBLIOGRAPHY 167

Zhang, Y. M., B., Z. S., and Jiang, M. (2002). Sensing and Control
of Double-Sided Arc Welding Process. Journal of Manufacturing
Science and Engineering, 124:695–701.
168
Appendix A

Definitions

Definition 2.1. A singular statement is a statement that accounts of

results from observations or experiments.

(Popper, 2003)

Definition 2.2. A universal statement is a statement in terms of a

theory or a hypotheses.

(Popper, 2003)

Definition 2.3. A hypotheses is a tentatively anticipated universal

statement that is the subject of testing.

From (Popper, 2003)

Definition 3.1. M is a model of a system S if M can answer questions

about S with an accuracy of A.

(Marca and McGowan, 1988)

169
170 Appendix A. Definitions

Definition 3.2. An event is an instantaneous happening that have an

effect on the universe.
Definition 3.3. An action is the state of acting or doing.

(American Heritage, 2000)

Definition 3.4. An activity is a set of actions that consumes time

while it makes a change to the universe.

Adapted from ISO/TC184/SC4 (1999)

and ISO/IEC/JTC1/SC7 (2001)

Definition 3.5. Data are symbols which represent information for

processing purposes, based on implicit or explicit interpretation rules.

Adapted from Schenck and Wilson (1994)

Definition 3.6. Information is data interpreted in its original mean-

ing.
Definition 3.7. Knowledge form the sum of experiences and informa-
tion a person have collected and more or less consciously structured for
its needs.

(Holmer et al., 1990)

Definition 3.8. Competence is the ability to use the acquired knowl-

edge to make appropriate decisions and actions.
Definition 3.9. An information model is a formal description of data
and its interpretation rules.
Definition 4.1. Innovation is the transformation of customer needs
into new products on the market, from idea until a stable manufactur-
ing process is established.
 171

Definition 4.2. A transformation process transforms an input to an

output by adding values to satisfy previously declared needs.

Adapted from Hubka and Eder (1988)

Definition 4.3. The sum of all elements and influences (and their
relationships among them and to their environment) that participate
in a transformation is collectively termed a transformation system.

(Hubka and Eder, 1988)

Definition 4.4. Concurrent engineering is the simultaneous consider-

ation of more than one aspect of a system during its design phase.
Definition 4.5. A feature is a perceived geometric element, functional
element, or property of an object useful in understanding the function,
behavior, performance, or manufacture of that object.

Adapted from Brown et al. (1992)

Definition 4.6. A manufacturing process is a process that transforms

a physical object from one state to another.
Definition 4.7. A process is a set of interrelated activities.

(ISO/IEC/JTC1/SC7, 2001)

Definition 4.8. A product is an object intended to be sold to, or

leased by, a customer.
Definition 4.9. A resource is an object that is used, or consumed, to
fulfill some need of the user.
Definition 4.10. Capability is the inherent ability to deliver perfor-
mance.

Adapted from Juran (1988)

172 Appendix A. Definitions

Definition 4.11. Machine capability refers to the reproducibility un-

der one set of process conditions.

(Juran and Gryna, 1988)

Definition 4.12. Process capability refers to the reproducibility over

a long period of time with normal changes in workers, material, and
other process conditions.

(Juran and Gryna, 1988)

Appendix B

List of Publications

1. Nielsen, J. and Kjellberg, T. The ISO 10303-214 Process Model

as a Core for a Process-Planning Tool. In International CIRP
Design Seminar, 2000.

2. Nielsen, J. and Bernard, B. Modeling and Discrete Event Simu-

lation Supporting Conceptual Design of Manufacturing Systems.
In The 33:rd CIRP International Seminar on Manufacturing Sys-
tems, 2000.

3. Nielsen, J. Inte bara frid och fröjd i den digitala fabriken. Verk-
stadsforum, 5, 2000.

4. Nyqvist, O. and Nielsen, J. Features as Part of the Functional

Interface Between Product and Resource: An Approach Based
on Standards. In International CIRP Design Seminar, 2001.

5. Kjellberg, T. and Nielsen, J. Digital Information System for World

Class Manufacturing. In The Fourth Workshop on Current CAx
Problems, 2001.

6. Aganovic, D. and Nielsen, J. Current Trends and Emerging Tech-

nologies in Digital Manufacturing. In CIRP Design Seminar,
2002.

173
174 Appendix B. List of Publications

7. Aganovic, D., Nielsen, J., Fagerström, J., Clausson, L., and Falk-
man P. A Concurrent Engineering Information Model based on
the STEP Standard and the Theory of Domains. In International
Design Conference - Design 2002, 2002.

8. Aganovic, D., Nielsen, J., Fagerström, J., and Falkman P. Multi-

Viewpoint Modeling of the Innovation System - Using a Hermeneu-
tic Method. In ICAD 2002, 2002.

9. Falkman P., Nielsen, J., and Lennartsson, B. A Formal Mapping

of Static Information Models into Dynamic Models for Process
Planning and Control Purposes. In Workshop on Discrete Event
Simulation (WODES) 2002, 2002.

10. Nielsen, J. Standards for the Digital Plant: An Overview. In

International Symposium on Robotics (ISR) 2002, 2002.
Appendix C

Volvo Car Corporation - A

Case Study Report 2000

Authors: Johan Nielsen, KTH/DKT, and

Petter Falkman, CTH/CAL.
Participants: Johan Nielsen, KTH/DKT.
Petter Falkman, CTH/CAL.
Jonas Rosén, KTH/DKT.
Supervisor: Niklas Andersson, VMC.
Interviewed persons: Anders Carlsson, VMC/PAS.
Andreas Westholm, team leader CADCAM.
Björn Söderberg, geometry assurance P2.
Carl Angervall, C-plant.
Christer Pettersson, FKB-process.
Fredrik Forsman, weld spot database.
Lars Johansson, DMU-project.
Negar Ghassemi, Corporate standards.
Niklas Andersson, VMC.
Olle Hansing, VMC/PAS.
Torbjörn Wissö, VMC/PAS.
Ulf Malmberg, Corporate standards.
Ulla Franke, VMC/PAS.

175
176 Appendix C. Volvo Car Corporation - A Case Study Report 2000

C.1 Introduction

Assar Gabrielsson and Gustaf Larson founded Volvo Car Corporation

(VCC) in 1927, since then the guiding principle has been safety. Today
VCC is part of Ford Motor Company within the Premium Automotive
Group (PAG). VCC has a total number of employees of 25 400 and
production cites all over the world, e.g. Sweden, Belgium, Malaysia
and South Africa. In 1999 the total number of produced cars was 408
150.
A vision at VCC is to provide engineers with the capability of Vir-
tual Manufacturing, i.e. a computer-based environment to model, test
and validate the manufacturing of any product. Ultimately, such an
environment will provide a solid base for all decisions without any
physical prototypes, but also a way to directly control the manufac-
turing without any manually generation of control code. However, to
be able to compare different test runs, both input (data/information)
and the working methods need to be unified. In other words, there is
a need for common representation of data/information as well as com-
mon definitions of how data/information is created and changed and
what data/information is needed for a particular test run.
Two crucial processes within the Body-in-White operations are the de-
velopment and management of process points, e.g., development and
management of reference points, or master location points as they are
named in the Volvo corporate standard STD 5026,2 (Volvo, 1996). Pro-
cess points are used, e.g., during the design of a car, development of
manufacturing and assembly processes, analysis of gaps and inspection
of the final results. Of course, process points are one of the inputs in
virtual manufacturing and thus falls under the same requirements of
unified input and working methods as stated in the paragraph above.
To accomplish unified inputs and working methods in the scope of
master location points, location points (or body handling points) and
weld spots within the VCC Body-in-White operations, a project (Dig-
ital Plant - VCC) was initiated. The project was subordinate the Pro-
cess and Assembly Structures (PAS) project, which deals with Product
C.1. Introduction 177

Data Management (PDM) issues such as information requirements for

the PDM-system Enovia from IBM. See Figure C.1 for an overview of
the project organization.

Project leader
Bernt Sollander

Operations
IT-tools PDM/PAS
development
Vacant Robert Maglica Anders Carlsson/
Ulla Franke

Digital Plant-VCC
Niklas Andersson

Figure C.1. Project organization at Volvo Car Corporation.

Although the Digital Plant - VCC (DPV) project was subordinated the

;
PAS project it worked as an interface between PDM and operations
development (OD), cf. Figure C.2.

;
Digital Plant - VCC

OD PDM

IT-tools

Figure C.2. Organizational scope of the Digital Plant - VCC project.

The scope of the state-of-the-art study at Volvo Car Corporation was,

therefore, limited to find in what extent virtual manufacturing has been
implemented within Body-in-White operations. The issues that are
highlighted are related to the development and management of master
location points, location points and weld spots. For instance, how
178 Appendix C. Volvo Car Corporation - A Case Study Report 2000

these process points are influencing the decisions made from analysis
of Digital Mock-Up´s (DMU´s), simulation of assembly processes or
Off-Line Programming (OLP) of weld robots.

C.2 Process Points

Process points are created for the purpose of handling, positioning, in-
specting, assembling, etcetera, product parts. These points are used to
specify the product and are essential for the outcome of the manufac-
turing process. Often different types of process points are exchanged
between the manufacturing system vendor and their customers. Fol-
lowing is an incomplete list of different process point types:

• master location point (reference point),

• location point,

• weld spot, and

• inspection point.

C.3 Master Location Point

The purpose of using a master location system is to determine the inter-
position of parts included in the vehicle and to ensure the right quality
of the final car (Volvo, 1996). By using a master location system, ini-
tial points for requirement specification, manufacturing and inspection
can be established consistently. It also simplifies analysis, e.g. finding
errors in the production.
A reference point, or master location point, is a point on a part, fixed
in a Cartesian coordinate system by the intersection of three coordi-
nate planes, i.e. X-, Y- and Z-plane (Volvo, 1996). It is intended for
theoretical determination of position of a part in a coordinate system
C.3. Master Location Point 179

and is represented in the physical world by a master location surface.

A master location surface is intended for practical use to determine the
location of a part, and the surface position is represented by a locat-
ing feature, e.g. guide lugs, guide pins, holes. Locating features are
not only part of the product but also represented in the manufacturing
system by a corresponding feature on the fixture. A locating feature is
used as a position indicator for part location, cf. Figure C.3.

Figure C.3. A locating feature for three guide functions (from Volvo
(1996)).

To determine the location of a part the 3-2-1-rule is used, i.e. at least

three points in the Z-plane, two points in the Y-plane and one point
in the X-plane are needed to fully determine the location of a part, cf.
Figure C.4.

Figure C.4. The 3-2-1 rule is used to determine the location of a

part.

At Volvo Car Corporation (VCC) Master Location points are defined

by the following data;

• 3D-location - defines the location of the reference point in a Carte-

sian coordinate space,
180 Appendix C. Volvo Car Corporation - A Case Study Report 2000

• guiding orientation - defines the direction in which the reference

point should locate the part,
• locating feature - defines the representation of a reference point
in the physical world, and
• project - the project in which the reference point is used.

C.4 Location Point

A location point, is a point on a part, fixed in a Cartesian coordinate
system by the intersection of three coordinate planes, i.e. X-, Y- and
Z-plane (Volvo, 1996). It is intended to supplement master location
points for theoretically determination of position of slender parts in
a coordinate system. Location points are represented in the physical
world by a location surface, which is intended for practical use to de-
termine the location of a part and its position. A locating surface is
represented by a locating feature, e.g. guide lugs, guide pins, holes
etcetera. A locating feature is used as a position indicator for part
location, cf. Figure C.3.

C.5 Weld Spots

A weld spot is a discrete point where two or more metal sheets are
joined in a weld joint. Weld spots are defined by the following data:

• spot identification - uniquely identifies the spot,

• 3D-location - defines the location of the spot in a Cartesian co-
ordinate space,
• geometrical point - defines if the spot is welded early in the pro-
duction process to keep the body together, and
• description - additional free text description of the spot,
C.6. Master Location and Location Point Preparation 181

• weld model - identifies the weld spots created within a certain

project of a certain module team,

• weld joint - identifies a set of one or more weld spots, and

• weld process - defines the properties that are needed to weld a

certain spot.

Several corporate standards are related to the development and man-

agement of weld spots, e.g.:

• Spot Welding - Symbolic representation and requirements

• Spot welding - Symbolic representation and definitions in 3D-

models

• Quality assurance spot welding - It gives references to the require-

ments for spot welding, test methods and routines for checking
and re-working operations.

• Welding date for spot welding of two-sheet combinations - The

standard specifies base values for welding data of various thick-
ness.

C.6 Master Location and Location Point

Preparation

The activity model in Figure C.5, is a result of interviews and review

of existing process documentation at VCC from a production point of
view. The results or the output of the master location and location point
preparation activity are change orders, existing product solution, new
product solution, identified consequences, and frozen master location
and location points. The inputs to the activity are existing product and
miscellaneous. Existing and new product solution and frozen master
182 Appendix C. Volvo Car Corporation - A Case Study Report 2000

location and location points are represented in the NUFO1 . Product re-
quirements and existing industrial system constrain whereas engineers
support the master location and location point preparation activity.

Product requirements Change orders

Existing
Change orders
industrial system

Master location & Existing product solution

location point
Existing product New product solution
preparation
Identified consequences
Miscellaneous
A0
Frozen master location &
location points
Engineers Software tools

Figure C.5. IDEF0-diagram of the master location and location

point preparation activity.

The master location and location point preparation activity can be de-
composed into product design, consequence identification, , and master
location and location point change, cf. Figure C.6.
During the product design activity, cross-functional module teams cre-
ate a proposed new product, represented by the NUFO. The proposal is
based on an existing product and constrained by product requirements,
existing industrial system and sometimes change orders. During the
activity, tolerance chain analysis takes place to identify and correct
system solutions that are not fault tolerant. For some system solu-
tions, tolerance chain analysis takes place before any geometry exists.
The location of master location and location points are verified by the
manufacturing engineers and documented by the product engineers.
The main purpose of the consequence identification is to result in a
basis for the decision activity. Consequence identification is divided
into three steps. The main objective of the first step is to identify areas
in the existing industrial system that are affected by the changes of the
master location and location points in the proposed new product. The
second step involves comparison of changed product prerequisites with
1
NUFO is the abbreviation for NUmerisk FOrmgivning, which is Swedish for
numerical shaping.
C.6. Master Location and Location Point Preparation 183

Product Existing
requirements industrial system

Existing product Proposed

Product design new product

Miscellaneous
A1
Identified consequences
Cost
Consequence
identification Lead time
Need of reconstruction
A2 of facilities

Change orders
Decision
Existing product solution

New product solution

A3
Engineers & tools

Master location &

location point Frozen master location &
change location points

A4

Master location Technical project

Product Manufacturing Software tools & location point Manufacturing
manager & project
engineers engineers coordinator engineers
managing group

Figure C.6. IDEF0-diagram of the decomposed master location and

location point preparation activity.

existing master location and location points for the identified areas
in the existing industrial system. The purpose of the second step is
to identify deviations in the proposed new product compared to the
existing industrial system. In the final step the identified deviations is
used as a base to identify and analyze the consequences of the proposed
new product. The result is identified consequences in terms of cost,
lead-time and need for reconstruction of facilities.
The identified consequences, i.e. cost, lead-time and need for recon-
struction of facilities, are used as a basis for decision. The result of
the decision is to use the existing product solution, in terms of mas-
ter location and location points, or to use the new product solution.
When a new product solution is rejected the master location and loca-
tion points of the existing product solution are used and thus a change
order to use the existing product solution is sent to product design.
The technical project manager & project-managing group (usually the
module team managers) participate in the decision-making activity.
When a new product solution is accepted the activity flow continues
with master location and location point change. The main objectives
184 Appendix C. Volvo Car Corporation - A Case Study Report 2000

with this activity are to change master location and location points
in the existing industrial system to fit the new product solution and
to assure the topicality of these points. The result is frozen master
location and location points of a modified industrial system.

C.7 Weld Spot Preparation

In 1998 a study of the weld spot management was conducted and doc-
umented in the Weld Spot Management-report (Maglica, 1998). The
purpose of the study was to identify and document the activities for the
development and management of weld spots. According to the author,
Robert Maglica, the proposed activities from 1998 is still valid and has
been the base for the development of a weld spot database where weld
spot data is stored. This section will briefly present and discuss the
activities for weld spot preparation.
In Figure C.7 an overview of the weld spot preparation activity is pre-
sented. The result or the output of the activity consists of change
orders, verified weld process specifications (WPS), verified process in-
spection and instructions (PII) and verified robot programs. The input
to the activity consist of the NUFO, describing the geometric prop-
erties of the metal sheets that make up the car body, and sheet data
(Excel-document), describing the material characteristics of the metal
sheets. The NUFO also include master location points as well as loca-
tion points. Engineers from various disciplines using a set of software
tools perform the activity, which is constrained by the product and
process requirements.
The weld spot preparation activity can be decomposed into weld joint
design, weld process planning and process instruction creation, cf. Fig-
ure C.8. The three activities are executed concurrently and have no
sequential priority.
During the weld joint design activity the designers create a set of weld
spots that are assigned to the car so that the product requirements and
change orders are fulfilled. Based on joint requirements the designer
C.7. Weld Spot Preparation 185

Product requirements Change orders

Process
Change orders
requirements

Weld spot Verified WPS

NUFO preparation
Verified PII
Sheet data
A0 Verified robot programs

Engineers Software tools

Figure C.7. IDEF0-diagram of the weld spot preparation activity.

Process
Product requirements requirements

NUFO

Weld joint design

Change orders
A1

Weld process Weld model

planning Simulation model
Sheet data
A2 Welding parameters

Process
instruction Verified WPS
creation Verified PII

A3
Verified robot programs

Designers Catia Robcad Excel Manufacturing Geometric Welding

engineers simulation engineers
engineers

Figure C.8. IDEF0-diagram of the decomposed weld spot prepara-

tion activity.
186 Appendix C. Volvo Car Corporation - A Case Study Report 2000

adds a number of weld spots to the NUFO using Catia. However, the
weld spots are stored separate from the sheet data in a weld model
within the NUFO.
The main purpose of the weld process planning activity is to assure that
it is possible to manufacture the car body in the proposed manufactur-
ing unit, which is either an existing unit or a unit under development.
The activity is very complex and therefore several different disciplines
collaborate resulting in:

• change orders - issued back to weld joint design when weld spots
need to be relocated (paper format),

• simulation model - geometric properties and dynamic behavior of

the manufacturing system including the product to be manufac-
tured (RobCAD-format),

• welding parameters - set of data defining the weld process (Access

database), and

• weld model 2 - same as weld model with the difference that some
weld spots may have been relocated and some weld spots may
have been designated as geometry points (Catia-format).

Inputs to the process planning activity are NUFO, weld model and sheet
data. The sheet data is an Excel-document describing the material
characteristics of the metal sheets of the car body. The content of the
Excel-document originates from the KDP2 -system.
During the product instruction creation activity the designers, manu-
facturing engineers, geometric simulation engineers and welding engi-
neers create and verify the weld process specification (WPS), process
instruction and inspection (PII) documents and robot programs. Some
times weld spots need to be relocated and thus change orders are cre-
ated. The weld process specifications are created manually and are
2
KDP is an information system that represents the product structure.
C.8. Use of Master Location Point and Weld Spot Data 187

downloaded to the welding controllers. The process instruction and in-

spections are created in Catia and shows the location of the weld spots.
Finally, the RobCAD-tool called VOLP (Volvo Off-Line Programming
tool) is used to create the robot programs that are to be downloaded
to the robot controllers.
Weld spot preparation is a complex activity and several engineers are
involved during the development and management of weld spots. A
large part of the weld spot definition is carried out by sub-contractors
outside of VCC and thus makes the matter even more complicated.

C.8 The Use of Master Location Point

and Weld Spot Data in Virtual Man-
ufacturing

Today, assembly of product parts is validated in digital mock-ups (DMU’s)

in VMAP, Dassault Systemes/Deneb (now Dassault Systemes/Delmia
Corporation) and 4D-Navigator, Dassault Systemes/CATIA and has
reduced the need for physical test objects significantly. In VMAP the
part trajectory is analyzed to detect collisions, assembly time estima-
tion etcetera. 4D-Navigator is mainly used for assembly method anal-
ysis to validate part sequence, dynamic fitting of parts, and simple
tool analysis. Master location points are, however, not used during
the DMU-analysis. The reason is that all product parts should defined
in the vehicle’s main coordinate system (Volvo, 1994), cf. Figure C.9.
Thus translations between local coordinate systems do not need to be
taken into consideration during the DMU validation.
The DMU-tools, VMAP and 4D-Navigator are fed product data from
VPM, PDM-system from Enovia, cf. Figure C.10. The product data
origins from the four in-house-built systems PM (main document for
3D-geometry), KDP (product structure), POS (position of geometry)
and PKI (process structure).
188 Appendix C. Volvo Car Corporation - A Case Study Report 2000

Figure C.9. Main coordinate system of vehicle (from Volvo (1994)).

KDP POS

PM PKI

VPM

VMAP
4D-navigator

Figure C.10. Overview of systems for DMU-analysis.

C.8. Use of Master Location Point and Weld Spot Data 189

Master location and location points are used in product design activity
as input to the RDT-tool (Robust Design and Tolerancing) (Söderberg
and Lindkvist, 2000) for analysis of the robustness of the design in
terms of placement of master location points. Depending on variance
in material and spring back etcetera, the placement of master location

;;
points can either damp or amplify the variance.
Weld spot data (1)

;;
Managed in
Weld spot data (2)

Weld model Weld data

Coordinates,
Weld spot joint, prel.
PM
database robot
allocation...

;;
Managed in Robot, tool, sequence
Weld spot data (1) Weld spot data (2)
NUFO Robcad Process data
Geometry, master Cycle time,
location & location current...
points

Robot weld gyuns Robot cycle time,

Verification
current
Manufacturing Robot
3D-clamp
model
Clamp
VOLP
data

Managed in Robot programs,

parameters,
calibration data

Figure C.11. Overview of input data to Robcad for weld spot vali-
dation and OLP.

In Figure C.11 an overview of necessary input data and systems for

validation and OLP of weld processes is presented. In the center is
Robcad, a robot simulation software from Tecnomatix. In Robcad
the sequence of weld spots, that weld spots are within reach of weld
robots and weld guns, that weld spots are not positioned to close to
master location points and collision detection are tested. Robcad is
also used to feed VOLP (Volvo OLP) with robot movements. VOLP
then creates robot programs that can be uploaded to all on-line robots.
VOLP manage calibration of the robots extremely well and thus on-
line touch-up can be reduced to a minimum. The information used in
Robcad originates from different sources, cf. Table B.1.
One of the largest problems related to the exchange of information in
Figure C.11 is to update the manufacturing model in the same pace as
190 Appendix C. Volvo Car Corporation - A Case Study Report 2000

Source Format Content

Weld model Catia Spot id, location, joint be-
longing, and lens diameter.
Weld data & Excel Part id, sheet thickness, ma-
process data terial, surface quality, weld-
ing time, welding current,
electrode force, electrode di-
ameter, welding gun, and
weld spot sequence.
NUFO Catia Geometry of the car, mas-
ter location and location
points.
Manufacturing Different Robots, tools (weld guns,
model CAD-formats grippers, etcetera), palettes,
fixtures, and peripheral
equipment.
Table C.1. Information sources for Robcad-simulation.

changes are introduced in the product model, e.g. changes of master

location points. For this reason the clamp data of the manufacturing
system design is continuously compared to the master location points
of the product model to verify that each clamp of the manufacturing
equipment have its corresponding master location point on the product.

C.9 Discussion and Conclusion

The case study at VCC has focused on the development, management
and use of master location points, location points, and weld spots in
virtual manufacturing within body-in-white. A key issue for virtual
manufacturing to take affect, which is well understood at VCC, is that
virtual manufacturing should not be an end in itself but a tool to sup-
port decisions. What decisions that are to be made must be understood
before modeling of a product or a manufacturing system takes place.
The modeling activity must provide the right information for the test.
C.9. Discussion and Conclusion 191

The quality and the content of the information must be uniform for
different test series. Otherwise the result of the different test series
cannot be compared on a fair base.
Working methods and management of information is crucial for the
outcome of virtual manufacturing. By using uniform working meth-
ods with a uniform information input it can be ensured that models
of different test series have the same quality and thus they can be
compared on a fair base. VCC has started this work by initiating the
VMC-project, which have three main areas operations development,
IT-tools, and PDM. Where the PDM efforts include product, process
and resource data management.
It is, of course, important that all information that is used during
design and testing is up to date. Today, information is often stored
redundantly and thus it is difficult to keep it updated. For instance,
weld spot data is stored in CATIA-files, Robcad-files and in the weld
spot database. A particular program has been implemented to verify
that weld spot data in the different storage medias is the same in terms
of position, joint belonging etcetera. This is not a special case but a
common problem that information is stored in files and thus the use and
management of the information is limited, e.g. engineers working with
DMU’s have estimated that 50-85% of their time is spent on finding
the right and updated information. One purpose of the PDM-efforts
in the VMC-project is to provide a logical place to store and retrieve
data to and from, and thus makes data easier to manage and update.
An increasing problem is how to share information with sub-contractors
and vendors. An important part of the product data that is shared is
master location and location points. For instance, master location and
location points are often the first and only data that is received by
ABB Body-in-White with a request for an offer of a robot cell.
Another problem for VCC is the recent merge with the Ford Motor
Company. Forthcoming products will be developed together and per-
haps manufactured in common plants. This means that representation
and presentation of information about master location points, location
points, and weld spots need to be unified between the two companies.
192 Appendix C. Volvo Car Corporation - A Case Study Report 2000

Of the two companies, VCC has reach much further with the ideas,
strategies and implementation of virtual manufacturing.
Although VCC uses virtual manufacturing to a great extent, there are
still areas that can be improved. Within the area of master location
point analysis and tolerance chain analysis, for instance, the simulation
of dynamic behavior needs to be improved. Today it does not exist
any means for this type of simulation and thus all product parts is
approximated with rigid bodies. This results in that the engineers
cannot simulate the behavior in material when two parts are welded
together. Another improvement area is that of visual aids that can scan
parts and by that locate their master location points, location points
and estimate the quality of the parts that are to be assembled. Then by
calculating the difference between the parts they could be positioned in
a better way or some parts may be scrap even before they are included
in an assembly.
From this case study it can be concluded that:

• Virtual manufacturing is a tool to support decision-making.

• Unified working methods for virtual manufacturing are needed.
• Unified information input to virtual manufacturing tools is needed.
• The implementation of virtual manufacturing at VCC has re-
duced the need for physical test objects significantly.
• Information is often stored in files.
• Information is often store redundantly.
• It is difficult to manage and update redundant information.
• Virtual manufacturing at VCC can be improved.
• The VMC-project is an effort to develop and implement virtual
manufacturing at VCC.
• The merge with Ford Motor Company has made the situation
even more complicated.
Appendix D

ABB Body-in-White - A
Case Study Report 2000

Authors: Petter Falkman, CTH/CAL, and

Johan Nielsen, KTH/DKT.
Participants: Johan Nielsen, KTH/DKT.
Petter Falkman, CTH/CAL.
Supervisor: Gordon Sjöqvist, simulation.
Interviewed persons: Rune Svensson, process preparation.
Gordon Sjöqvist, simulation.

D.1 Introduction
The Swedish company ABB Body-in-White1 (ABB BiW) is part of
the global organization of ABB Flexible Automation. ABB BiW is a
full service supplier with complete solutions for the vehicle industry.
Their total function systems include everything from pre-studies (si-
multaneous engineering), simulation, process and design, installation
1
Since the report was written ABB Body-in-White have changed name to ABB
Automation Technologies (ABB ATRM/AM).

193
194 Appendix D. ABB Body-in-White - A Case Study Report 2000

and commissioning to education, training, service and financing. The

head office is located in Olofström in southern Sweden. ABB BiW
also has regional offices throughout Sweden in Gothenburg, Malmö,
and Umeå. ABB BiW also has sister offices and/or representatives in
France, Spain, USA and Canada.
ABB BiW offer complete assembly lines as turn-key installations. Their
assembly systems are based on standardized and/or requirement-tailored
solutions, and they are designed to meet all production volumes for
cars and trucks. ABB BiW also offer separate, individual equipment
units for installation in existing assembly lines, for example hemming
units. Full service competence together with extensive, genuine process
knowledge and a project management organization that is a true team
will be working to find the best, most efficient solutions.
The scope of this state-of-the-art study is how tender preparations are
conducted at ABB BiW. The results are based on interviews with two
people at ABB BiW. The main contact at ABB BiW has been Gordon
Sjöqvist and interviews have also been conducted with Rune Svensson.
The main focus has been on:

• Which activities that are involved.

• What computer tools that is used.

• What information that is handled by the different activities and

how it is extracted to the specific activities.

• How and in what extent created information is reused.

• How ABB BiW would like to work in the future.

• How changes in the input to the tender preparation can be han-

dled and consequences can be analyzed quick and easy.

Another aspect that has been dealt with is weather there exist formal
methods that are followed during the tender preparation activity and
in which amount hands-on solutions are created.
D.2. Tender Preparation 195

D.2 Tender Preparation

The customer decides which company that gets an order based on the
tender, e.g. cost calculations, manufacturing solutions, cyclic times.
The costumer also to some extend decides which supplier gets the or-
der based on how the tender is presented and in what format the results
are presented in. It is becoming more important what tools that are
used and to if simulation models are delivered together with the man-
ufacturing system.
It is becoming more important that the supplier creates simulation
models early in a project and that these models are continuously up-
dated. It is demanded that these simulation models are in the specified
format so that the costumer can use these models when testing the
product solution or changes in the product design. This is a develop-
ment towards the main objective that a virtual manufacturing system
is concurrently with the design of the product and the process in order
to make simulations early in the projects.
This makes it important that the tender is prepared in a formalized
manner and that every solution is carefully analyzed in respect to cost,
efficiency, implementation etcetera. There must also be a balance be-
tween how much effort there is put in to a tender preparation and how
likely it is that the supplier gets the order.
In Figure D.1, an overview of the tender preparation activity is pre-
sented. The result of this activity is an evaluated tender that is sent
to the presumed customer. It is also created manufacturing solutions
and simulation models during this activity. A calculator delivers a cost
analysis that describes the cost for the total solution together with
cost calculations of the parts of the manufacturing solution. The input
to this activity is a product description, estimated product lifetime,
yearly production, reference to similar solutions, desired cyclic-time
and a description of the facility layout. The product description can
be presented in different format and in different detail depending on
how detailed the customer wants the tender to be. The tender prepa-
ration activity is constrained by the facility layout, regulations and
196 Appendix D. ABB Body-in-White - A Case Study Report 2000

Earlier solutions Requirements/laws

Layout Regulations

Product specification Tender

Cost analysis
Product lifetime Tender
Cycle time Preparation
Yearly production Simulation model
A0
Referens to similar solutions Manufacturing solutions

Human
Customer resources Software
financing Tools

Figure D.1. IDEF0-diagram of the tender preparation activity.

several different requirements that will be described in the decomposi-

tion of the tender preparation activity, see Figure D.2. Engineers from
various disciplines perform the activity using different software tools
and in some cases earlier solutions.
The tender preparation activity is decomposed into risk analysis, start-
up meeting, preparation and evaluation. In Figure D.2 this decomposi-
tion is presented as an IDEF0-diagram. A process planner conducts the
Risk analysis activity together with a salesman and the tender prepa-
ration project leader. The process planner and the tender preparation
project leader is usually the same person. The risk analysis activity in-
vestigates whether or not they should prepare a tender, this analysis is
based on the product description, the facility layout, estimated yearly
production and maximum cycle time. The product description can be
delivered in different formats, the most common formats are 3D/2D-
drawing, assembly structures and Excel sheets defining weld point and
process point locations.
The purpose of the risk analysis activity is to investigate if they can
build the manufacturing system for the specified product and if they
think they have a chance at getting the order of building the system.
Costumer relationships are one factor that lies as a constraint and can
influence the choice of supplier e.g. a customer has a close cooperation
D.2. Tender Preparation 197

with a specific supplier. If a decision is made that they are going to

prepare a tender then the project leader split up the input information
and prepare information folders for the participants involved.
If the Risk Analysis activity results in that a tender should be prepared
in the specific case a start-up meeting is conducted. This start-up
meeting is the second activity in Figure D.2 and is performed by the
tender preparation project leader and members from several different
disciplines, e.g. process planner, calculator, salesman, named partici-
pants in Figure D.2. In the Start-up meeting activity the project leader
presents the tender and a time plan for the tender preparation. Differ-
ent tasks and the information folders are handed out to the different
participants and a time-plan is presented.

Owner Earlier results and

Relationship other Consideration
Facility
layout

Cycle
time

Risk Analisys
Product
description
A2 National Regulations Rework is needed
laws
yearly Start-up meeting
production

A3

Preparation Simulation model

Manufacturing solutions

A4

Solution
Earlier presentation Tender
solutions Cost
A5 analysis

Costumer Salesman Tender preparation Participants Computer tools: Robcad,

finansiering project leader Catia, Excel

Figure D.2. IDEF0-diagram of the decomposition of tender prepa-

ration activity.

The preparation is activity is conducted by represents from all the

different disciplines and to their help they use different computer tools
198 Appendix D. ABB Body-in-White - A Case Study Report 2000

e.g. Catia, Robcad, Excel. The activity is divided into sub-activities

that represent different disciplines e.g. process-planning, simulation,
cost calculation. The information folders serve as input to the sub-
activities. There are constraints that depend on who the costumer is for
example national laws and different local and global regulations. Since
this activity is performed concurrently by several different disciplines
there are meetings during the preparation activity in order to get early
feedback about different manufacturing solutions. The result of this
activity is manufacturing solutions and robcad-simulation models and
also to some extent cost calculations from the different disciplines.
The last activity in the tender preparation is the solution presentation.
The solutions from the preparation activity are used in the solution
preparation activity in order to present the results and decide however
the tender is satisfactory or if rework is needed. A total cost analysis
is presented together with cost analysis of the different sub-activity
solutions.

D.3 Pilot Study of eMPlanner from Tec-

nomatix

ABB BiW has begun an evaluation of Tecnomatix eMPlanner. A pilot

study has been conducted at ABB BiW together with represents from
Tecnomatix. The purpose of this pilot study was to examine how it
would change the way ABB BiW is working today concerning infor-
mation handling between different activities and the reuse of earlier
solutions. Another important affect is weather or not it would simplify
working concurrently in a tender preparation and process preparation
in order to get early feedback on process solutions. One focus was also
to evaluate how the use of eMPlanner would support the version han-
dling of all kinds of documents in order to secure that it always is the
right version that is dealt with.
D.3. Pilot Study of eMPlanner from Tecnomatix 199

D.3.1 Background

ABB BiW and in particular the department of Process Planning wants

to reach a better information flow in the internal process and that it
is beneficial to reuse the information created in the tender preparation
activity. There is also a wish to use the solutions created in the tender
preparation later in the project and in that way avoid unnecessary
rework.

D.3.2 Goals with the Pilot Study

The project goals are to find the advantages and disadvantages using
Tecnomatix eMPlanner and in what way the introduction of this new
software is going to affect their way of working today. The main objec-
tive ABB BiW is to be able to use the same computer tools as today
but make it easier to extract the right information without making a
lot of translations. All the computer tools should use the same infor-
mation. Another important feature is to be able to reuse complete
solutions with all its documentation. Today solutions are reused but
these are just the ideas not the formal complete solutions.
The main focus was to evaluate how eMPlanner could improve and sim-
plify the their way of handling a number of activities that are specially
important.

• Handling of product data, how to get, view and organize the

data coming from ABB customers to ABB BiW. How to handle
changes during quotation.

• Handling of product structures.

• Layout, 2D to 3D.

• Operation- and resource descriptions, ABB wants to have a good

way of presenting the included operations in their design.
200 Appendix D. ABB Body-in-White - A Case Study Report 2000

• Manufacturing management, Weld point distribution in the pro-

cess, rivets, and glue strings.

• Sequence diagram.

• Cost estimate.

The result of this first study was according to the participants good
and therefore a new study is planned in order to enlarge the scope.
It is becoming more and more important to have an information struc-
ture that makes it fast and easy to extract useful information to certain
application in order to reuse earlier solutions. If it demands a lot of
time and work to gather information, e.g. earlier solutions, new solu-
tions are created instead.
This state-of-the-art report has focused on how tender preparation is
conducted and who is involved and what information that is required
and also in what extent the created information is used later in the
project. One of the purposes of introducing eMPlanner is to support
the wish to reuse the information created during the tender preparation
in the process planning activity later in the project. Today, the created
information is to a high degree re-created and the efforts in the tender
preparation are to some extent unnecessary. Another goal with the
introduction of eMPlanner is to create an information structure that
supports all the computer tools that are used during a project in order
to connect information together in a way so different data refers to each
other e.g. a product operation refers to the resource that is used for
this particular operation.
Today, the input to the supplier normally is a product description and
site layout and some constraints but a trend is that the supplier is
involved early in the design of the product and working in close coop-
eration with the costumer. This is advantageous both for the supplier
and the costumer because the supplier with their knowledge is able to
have influence on the design of the product and comment on solutions
that make the manufacturing system more complex and therefore more
D.3. Pilot Study of eMPlanner from Tecnomatix 201

expensive. The activity model described in Figure D.3 is therefore ex-

panded with an extra activity that describes this cooperation with the
costumer called a pre-study.

INPUT: Risk analasys

Product
Pre-study INPUT: Risk analisys
description

A(-1)

Costumer Earlier
Solutions

Figure D.3. IDEF0-diagram of the pre-study activity.

The first activity in the new decomposed tender preparation activity

is then the pre-study. The input to this activity is early product de-
scriptions and is delivered in co-operation with the customer. Process
planners from ABB BiW participate early in the product design to-
gether with the customer in order to influence them in the design of
the product.