Design in 7 Days, The Vision and its
Implications
COT/1-5-V1.0
Centre for Object Technology
Revision history:
Author(s):
Status:
Publication:
Summary:
V0.1 dato
Morten Frank
Final
public
This Thesis is a Computer Science approach towards the Design in 7 Days vision. It describes a joint research project
between the Department of Computer Science at the University of Copenhagen, Odense Steel Shipyard Ltd. and the
Danish Maritime Institute. The research project is part of
.
the research done by the Center for Object Technology. .. Important conclusions made during the work with the project
are: (1) technology transfer between universities and private
companies is possible with benefits for all, (2) evolutionary
prototyping is a powerful strategy when requirements are
not well-defined and new ways of supporting an engineering
process is to be developed, (3) object oriented methods are
well-suited for domain modelling, and (4) domain experts
and IT experts in cooperation performs a strong team when
systems supporting an engineering process is to be developed.
c Copyright 1999
The Centre for Object Technology (COT)
is a three year project concerned with
research, application and implementation
of object technology in Danish companies. The project is financially supported
by The Danish National Centre for ITResearch (CIT) and the Danish Ministry
of Industry.
Participants are:
Maersk Line, Maersk Training Centre,
Bang & Olufsen, WM-data, Rambøll,
Danfoss, Systematic Software Engineering, Odense Steel Shipyard, A.P. Møller,
University of Aarhus, Odense University,
University of Copenhagen, Danish Technological Institute and Danish Maritime
Institute
Design in 7 Days
The Vision and its Implications
Master Thesis
Morten Frank,
DIKU,
Department of Computer Science
University of Copenhagen
Universitetsparken 1
DK–2100 Copenhagen
email:
[email protected]
March 15, 1999
1
Abstract
This Thesis is a Computer Science approach towards the Design in 7 Days vision. It describes
a joint research project between the Department of Computer Science at the University of
Copenhagen, Odense Steel Shipyard Ltd. and the Danish Maritime Institute. The research
project is part of the research done by the Center for Object Technology.
Design in 7 Days is a radical vision for the future way of designing highly complex one–off
products. The vision has emerged as the ultimate goal of the Concurrent Engineering efforts
made at Odense Steel Shipyard Ltd. where custom specific vessels are manufactured. Each
vessel manufactured is a very costly and highly complex adaption of a general kind. A key
characteristic of the manufacturing process is that product and production preparation are
complex and lengthy tasks—i.e. Design Time is Lead Time.
The core of the Design in 7 Days vision is to make the consequences of cross-functional
decisions visible to decision takers at a very early time in the design phase or even before
decisions actually are made. The ultimate goal is that all cross-functional issues are resolved
during the first 7 days of the design phase and that decisions hereafter can be made in parallel
in each design area without interfering with other design areas.
The fulfillment of the vision will require much work on both the theoretical and the
practical level, involving many research fields. Many research projects are therefore initiated
in different areas. The fulfillment will require extensive use of IT-support and therefore the
field of computer science is a very important aspect—this Thesis is part of the computer
science approach towards the fulfillment of the vision.
In this Thesis the vision is studied through analyses and empirical case projects. The
vision is clarified through analyses of related research and the environment in which the vision
is to be implemented. The implication of the vision with regard to IT-support and system
development are analyzed. Two case projects have been initiated and they are described and
related to the vision and the research goals.
Important conclusions made during the work with the project are: (1) technology transfer
between universities and private companies is possible with benefits for all, (2) evolutionary
prototyping is a powerful strategy when requirements are not well-defined and new ways of
supporting an engineering process is to be developed, (3) object oriented methods are wellsuited for domain modelling, and (4) domain experts and IT experts in cooperation performs
a strong team when systems supporting an engineering process is to be developed.
Keywords: IT-support for engineering processes, ship design, knowledge integration, concurrent
engineering, system development, technology transfer, evolutionary prototyping, object orientation,
Java, experience report.
i
Preface
This Thesis is the result of 7 months work of the Department of Computer Science at the
University of Copenhagen. The subject of this Thesis is the project Design in 7 Days—a
case project by the Center for Object Technology. This project is done in collaboration with
the Danish Maritime Institute and Odense Steel Shipyard Ltd.
During this work I have had Associate Professor Eric Jul as my advisor. I would like to
thank him for giving me the opportunity to write a Thesis with an industrial dimension. It
is a personal satisfaction that the work is intended to solve “real problems”. I would also like
to thank him for always having the time for a discussion “on the doorstep” and for protecting
my personal research interests.
I would also like to thank the persons involved in this project for their time and effort.
This thanks goes to Kim Henriksen and Kasper Bøgh Pedersen from DMI, Jan Tuxen, Claus
Risager and Christian Frost from OSS, Eric Jul and Niels Elgaard Larsen from DIKU and a
number of persons at OSS for their time for meetings and discussions.
This Thesis is written in English although my native tongue is Danish. Therefore a
number of people have assisted me in proofreading and commenting on both language, contents and structure. For this work I want to thank Eric Jul, Martin Fredfeldt, Allan Thrane
Andersen, Niels Elgaard Larsen, Kasper Bøgh Pedersen and Jan Tuxen.
The special thanks goes to Anne.
Frederiksberg, March 15, 1999
Morten Frank
ii
Contents
Abstract
i
Preface
ii
Table of Contents
iii
List of Figures
vii
List of Tables
viii
I
Introduction
1 Introduction
1.1 Fulfillment of the Vision
1.2 Project Context . . . . .
1.3 A Note on Terminology
1.4 Thesis Goals . . . . . .
1.5 Work Done . . . . . . .
1.6 Approach . . . . . . . .
1.7 Thesis Outline . . . . .
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
3
4
4
6
6
7
7
2 Background
2.1 Center for Object Technology . . . .
2.1.1 COT Organization . . . . . .
2.1.2 COT Goals . . . . . . . . . .
2.1.3 COT Research Activities . .
2.1.4 Conclusions Regarding COT
2.2 Odense Steel Shipyard . . . . . . . .
2.3 Danish Maritime Institute . . . . . .
2.4 D7D/COT Project Work Done . . .
2.5 Background Summary . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
9
9
10
10
15
16
17
18
19
3 Related Research
3.1 References Overview . .
3.2 Concurrent Engineering
3.3 Knowledge Integration .
3.4 Feature Modelling . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
20
20
21
24
26
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
iii
CONTENTS
3.5
3.6
3.7
3.8
Engineering of Engineering .
Design Levels . . . . . . . . .
Virtual Enterprises . . . . . .
Conclusion Regarding Related
iv
. . . . . .
. . . . . .
. . . . . .
Research
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
II Design in 7 Days
The Vision and Background
28
29
30
32
34
4 Design in 7 Days—The Vision
4.1 Background and Forces . . . . . . . . .
4.2 The D7D Vision . . . . . . . . . . . . .
4.2.1 Key Points . . . . . . . . . . . .
4.2.2 Design Space and Design Levels
4.3 Conclusion Regarding the D7D Vision .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
35
35
40
40
42
44
5 Departments and IT Tools at OSS
5.1 Main Areas and Departments . . . . . . . . . . . .
5.1.1 Planning, Development and IT . . . . . . .
5.1.2 Production . . . . . . . . . . . . . . . . . .
5.1.3 Design and Detailed Design . . . . . . . . .
5.2 IT Tools . . . . . . . . . . . . . . . . . . . . . . . .
5.2.1 Classification . . . . . . . . . . . . . . . . .
5.2.2 Description of the IT Tools . . . . . . . . .
5.3 Conclusions Regarding IT Tools and Organization
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
45
45
45
46
47
49
50
51
54
6 The Planning and Design Process at OSS
6.1 Planning . . . . . . . . . . . . . . . . . . . . .
6.1.1 Building Programs and A-Plans . . .
6.1.2 B-Plans . . . . . . . . . . . . . . . . .
6.1.3 C-Plans . . . . . . . . . . . . . . . . .
6.1.4 Other Documents . . . . . . . . . . . .
6.2 The Main Phases . . . . . . . . . . . . . . . .
6.2.1 Phase 0—The Project Phase . . . . .
6.2.2 Phase 1—The Design Phase . . . . . .
6.2.3 Phase 2—The Detailed Design Phase .
6.2.4 Phase 3—The Production Phase . . .
6.3 Conclusions Regarding Planning and Process
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
55
55
56
56
56
57
57
59
63
67
68
68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
III Design in 7 Days
The Implications
7 Implications
7.1 General Considerations . . . . . . . .
7.1.1 Viewpoints on Project Goals
7.1.2 Legacy Systems . . . . . . . .
7.1.3 Target Group . . . . . . . . .
70
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
71
71
72
72
73
CONTENTS
7.2
7.3
7.4
7.5
IV
v
7.1.4 Conclusions Regarding General Considerations . . . . .
D7D/COT System Development . . . . . . . . . . . . . . . . .
7.2.1 Development Strategy . . . . . . . . . . . . . . . . . . .
7.2.2 Implementation Platform . . . . . . . . . . . . . . . . .
7.2.3 Conclusions Regarding D7D/COT System Development
Fulfilling The D7D Vision . . . . . . . . . . . . . . . . . . . . .
7.3.1 Tasks, Parameters and Dependencies . . . . . . . . . . .
7.3.2 D7D Vision Characterization . . . . . . . . . . . . . . .
7.3.3 The Fulfillment of the D7D Vision . . . . . . . . . . . .
7.3.4 Conclusions Regarding Fulfillment of the D7D Vision . .
A D7D/COT Project Plan . . . . . . . . . . . . . . . . . . . . .
Conclusions Regarding Implications . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
D7D/COT Project Cases
75
75
76
78
79
80
80
82
83
85
85
86
88
8 Power Prediction
8.1 The Process of Power Prediction . . . . . . . .
8.1.1 The OSS Practice for Power Prediction
8.1.2 The DMI Practice for Power Prediction
8.2 The Visions for the Power Prediction Tool . . .
8.2.1 User Requirements . . . . . . . . . . . .
8.2.2 Data-owner Requirements . . . . . . . .
8.3 Design and Implementation Considerations . .
8.3.1 Implementation Platform . . . . . . . .
8.3.2 Security Considerations . . . . . . . . .
8.3.3 Architecture and Interface . . . . . . . .
8.4 The PP Prototype . . . . . . . . . . . . . . . .
8.4.1 Work Done . . . . . . . . . . . . . . . .
8.4.2 Goals and Status of the PP Tool . . . .
8.4.3 Using the Prototype . . . . . . . . . . .
8.5 Power Prediction and D7D/COT . . . . . . . .
8.5.1 PP and the D7D Vision . . . . . . . . .
8.5.2 PP and the COT goals . . . . . . . . . .
8.6 Future Work . . . . . . . . . . . . . . . . . . .
8.7 Conclusions Regarding Power Prediction . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
89
89
89
90
92
92
93
94
94
95
96
97
97
98
100
101
101
103
104
104
9 Assembly Plan for Grand Blocks
9.1 The Problem . . . . . . . . . . . . . . . . . . .
9.1.1 The Process as-is . . . . . . . . . . . . .
9.2 Objectives . . . . . . . . . . . . . . . . . . . . .
9.3 Development Strategy . . . . . . . . . . . . . .
9.4 Design and Implementation Considerations . .
9.4.1 Requirements . . . . . . . . . . . . . . .
9.4.2 Implementation Platform . . . . . . . .
9.5 The Prototype . . . . . . . . . . . . . . . . . .
9.6 Assembly Plans and D7D/COT . . . . . . . . .
9.6.1 Building Programs and the D7D Vision
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
106
106
107
108
109
109
109
112
113
113
113
CONTENTS
9.7
9.8
V
vi
9.6.2 Building Programs and COT goals . . . . . . . . . . . . . . . . . . . . 114
Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Conclusions Regarding Assembly Plan for Grand Blocks . . . . . . . . . . . . 116
Conclusion and Future Work
10 Conclusion
10.1 The Design in 7 Days Vision
10.2 System Development . . . . .
10.3 Technology Transfer . . . . .
10.4 COT Goals Revisited . . . . .
.
.
.
.
11 Future Work
11.1 Case Projects . . . . . . . . . .
11.2 Process Descriptions . . . . . .
11.3 D7D and the new CAD System
11.4 D7D Architecture . . . . . . . .
11.5 COT Goals . . . . . . . . . . .
117
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
References
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
118
119
120
121
121
.
.
.
.
.
123
123
124
124
124
125
126
A Terms and Abbreviations
130
A.1 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
A.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
B Project Schedule during August 1998 to March 1999
134
List of Figures
4.1
Committed Cost, Incurred Cost, and Known Committed Cost . . . . . . . . .
37
6.1
The Main Phases of Design, Manufacturing and Production . . . . . . . . . .
58
7.1
Main Phases with Tasks and Parameters . . . . . . . . . . . . . . . . . . . . .
80
8.1
Screen Dump for Power Prediction Prototype . . . . . . . . . . . . . . . . . .
98
9.1
Screen Dump for the APGB Planning Prototype . . . . . . . . . . . . . . . . 114
vii
List of Tables
5.1
5.2
5.3
Organization Overview—Planning, Development and IT . . . . . . . . . . . .
Organization Overview—Production . . . . . . . . . . . . . . . . . . . . . . .
Organization Overview—Design and Detailed Design . . . . . . . . . . . . . .
viii
46
47
48
Part I
Introduction
1
Chapter 1
Introduction
In this thesis I study the Design in 7 Days vision—a vision for the future way of designing
highly complex one-of-a-kind products [Tux96]. The vision has emerged as the ultimate goal
of the way ships are to be designed at Odense Steel Shipyard Ltd. (OSS), but the vision
covers other manufacturing industries where some key characteristics are present:
• Highly complex products are manufactured
• The products are custom specific adaption of a general kind
• Design time is lead time
The manufacturing areas are air planes, offshore platforms, large bridges and similar. An
important characteristics of these types of industries is that the products are so complex that
a major part of the costs are spent on initial design and detailed design of the product—i.e.
a major part of the costs (including time) are spent on production preparation, or as stated
above design time is lead time.
The initial product preparation phase for this type of manufacturing is a very complex
and iterative process where a huge number of decisions have to be made. The core of the
Design in 7 Days (D7D) vision is to make the consequences of decisions visible to the decision
takers at a very early time in the design phase or even before the decisions actually are made.
The ultimate goal is that the design can be completed in enough detail within 7 days, so that
decisions hereafter can be made in parallel without interfering with other design areas.
In this thesis the D7D vision is studied from the computer science aspect. As part of a
research project at the Department of Computer Science at the University of Copenhagen
(DIKU) (see chapter 2) this Thesis is intended to serve as an introduction to and documentation of the project at the present state. The Thesis is thus a step in the direction of the
fulfillment of the D7D vision—a contribution with a computer science aspect. I have in this
Thesis gathered the results from the project so far. The Thesis describes the background
for the project and the work done. Related research projects are described and the most
important conclusions of these are given. I have described the D7D vision and made an
analysis of the environment in which the vision is to be instantiated. This analysis will lead
to a number of conclusions on how to fulfill the vision from this viewpoint. Two case studies
are currently in progress. In the first case project a distributed power prediction tool has
been developed. In the second case project a planning tool is under development. These case
studies are described and concluded upon.
2
CHAPTER 1. INTRODUCTION
1.1
3
Fulfillment of the Vision
The fulfillment of the vision will require much more research than done during this project, but
some of the conclusions made in this Thesis might help to choose in what direction the projects
should head for and what development strategy to use. Two issues are regarded as the most
important conclusion in this Thesis: the tool types for the fulfillment of the vision (“what to
build”) and the way that these should be developed (“how to build”). These conclusions are
made with the analysis of the D7D vison and the surrounding environment together with the
results from past research projects carried out at OSS as theoretical background and with
the results from the two case studies done during this project as empirical background.
It is my belief that the most important issues to focus on with regard to “what to build”
are the following subjects:
1. Tools for simulation of decisions to be made (visualization of decisions to be made in
order to comprehense consequences)
2. Tools for early communication among different design viewpoints
3. Better reuse of old designs
4. Work on defining suitable product models
As it will be seen throughout the Thesis these items are not clearly distinguishable. E.g., if
reuse is to be exploited more radically a better product model might have to be defined and
if the simulation aspect has to be exploited to the full extend better means for reuse might
be necessary.
For the matter of “how to build” my belief is that the best way of introducing new tools
at a company like OSS is to engage the users in the development of the tools, e.g. through a
prototyping development. This is especially true in a project like this where the developers
have a computer science background and not an engineering background or are experienced
in the field of engineering. This has several reasons:
1. Precise requirements are hard to describe by the users in a way comprehensible for a
developer not trained in the design and manufacture of the products in scope—thus
prototyping helps both sides to capture requirements for the new tool.
2. The user has through frequent reviews/evaluations a good opportunity to lead the
development in the right direction.
3. The developers can quickly evaluate ideas not thought of by the user.
It might be the case that the developed tool will not be the final tool, i.e. a re-implementation
might be needed later. It might also be the case that additional requirements are to be
respected—requirements not thought about by the user but requirements demanded by the
management as part of strategic considerations. These could e.g. be: the need to interface to
other systems, the data-format might be predefined with regard to international standards,
means for making specific calculations might be needed. But I find the prototyping development the most suitable way to capture requirements: one ends up with a very good basis for
later re-implementation—a runnable tool that defines the requirements.
CHAPTER 1. INTRODUCTION
1.2
4
Project Context
This Thesis is addressing the Design in 7 Days (D7D) vision in the context of a Research
& Development (R&D) project carried out between the Department of Computer Science at
the University of Copenhagen (DIKU), Odense Steel Shipyard Ltd. (OSS) and the Danish
Maritime Institute (DMI) as a part of the research done be the Center for Object Technology
(COT).
OSS is a large industrial company where the above characteristics are present: OSS
manufactures highly complex products that are very custom specific and where the design
time surely is the lead time. OSS has e.g. manufactured the largest container vessels ever
build and the first double hulled super tanker. But in order to keep its market position the
yard must constantly improve its skills—that is, OSS must address the weak points in the
manufacturing process from design to finished product. As a consequence of this OSS has
invested a considerably amount of time and money in e.g. information technology (IT), in
robot technology and other automation technology and in development of IT tools to support
the work. The investments done need to be supported by research in how to optimize the
advantages of these investments. OSS has therefore a tradition for initiation of R&D projects,
and the project which this Thesis is part of is one of them.
DMI is a technological service organization which offers consultancy services in the fields
of hydro- and aerodynamics with special applications in the maritime, offshore, construction,
process and energy industries. DMI is an organization that typically has customers like
OSS. The use of an organization like DMI by OSS normally happens in order to verify design
decision and is typically applied somewhere in the middle of the design phase—i.e. during the
production preparation phase. The work carried out by DMI would normally be a verification
of the shape of the hull by numerical methods and through model experiments. This process
can take up to one month and thus increases the design lead time. It is in the interest of
both DMI and OSS that this time is reduced or that the service provided also could happen
at an earlier stage in the manufacturing process. DMI is therefore interested in this project
with the goal of in the future to be able to develop tools to help designers at an earlier stage
in the process than at present. The goal is that DMI can integrate the achieved knowledge
from e.g. model experiments in tools usable by customers.
COT is a national center for research in object technology. The aim is to integrate
research done at universities and likewise with knowledge from service institutes like DMI
into industrial companies like OSS in the scope of object technology. I.e. technology transfer
is a very important aspect of the COT goals.
1.3
A Note on Terminology
In order to understand the next parts of this Thesis some comments on the used terminology
have to be made.
The subject of this R&D project is a part of the Design in 7 Days (D7D) project at OSS.
The D7D project at OSS is a very important strategy for the development of the design and
manufacturing process at OSS, in particular the very early phases of the design process. OSS
has made much effort into the fulfilling of the D7D vision and it is important to know that
this R&D project is only a part of the overall project.
CHAPTER 1. INTRODUCTION
5
I will therefore make the following use of terminology:
• The Design in 7 Days Vision describes the ultimate goal of the overall project.
• The Design in 7 Days Project describes the work done and to be done to reach the goals
of the Vision.
• The Design in 7 Days/COT project describes the concrete R&D project with the above
mentioned participants and the goals described in section 2.1.
The first two items will be abbreviated as the D7D vision vs. the D7D project. The third
item will be coined as the D7D/COT project. This Thesis is part of the D7D/COT project.
Currently two people (Niels Elgaard Larsen and Morten Frank) at DIKU are working
full-time with the D7D/COT project. The terms us and we in the following refer to Niels
Elgaard Larsen and Morten Frank, and the term I refers to Morten Frank.
The terms design and manufacturing are used somehow fuzzy in the context of the projecting, planning and production of (in this case) a ship:
• sometimes the meaning of design is restricted to the process of specifying the physical
layout of the ship, including verification of the work done (e.g. strength calculations).
The design in this sense has the goal of producing drawings of the product to be
produced.
• sometimes the meaning of manufacturing is restricted to the process of planning how a
given design (in the sense as described above) is to be produced. This task covers e.g.
the specification of welding lines, where a specific part is to be produced, in what order
the parts are going to be assembled and what qualifications in terms of man-power is
needed during the production.
• sometimes both terms are overloaded and included to cover (parts of) each other. I will
e.g. sometimes write the manufacturing of... with the meaning to cover the complete
task from order to delivery, including the design task. I will on the other hand also write
the design process... with the meaning to cover (parts of) the manufacturing process.
The overloading of the terms is necessary to avoid clumsy descriptions in parts of this Thesis—
the specific meaning should be comprehensible when this have been read and by the context
in which the terms are used.
The term domain expert will be used generally to cover experts in ship building: Naval
Engineers, Production Engineers (working with manufacturing of ships), Ship Constructors,
Ship Designers etc. The term is at some places restricted to cover e.g. only Ship Designers—
the context in which the term appears should outline the restriction. The term will not be
used to cover IT experts, even if the context (domain) is e.g. system development. In those
cases the term IT experts or similar will be used.
The term he should be read as he or she throughout the Thesis when used to cover e.g.
a generic person belonging to a group.
A short note on how the references are given is also subject for this section. All the
used references which are used directly (first-hand) are given in the references section on
page 126. The references made in this Thesis that are given second-hand (i.e. through one
of the references given in the reference section) are shortly presented in a footnote. All the
second-hand references should be identifiable through the first-hand references.
CHAPTER 1. INTRODUCTION
1.4
6
Thesis Goals
I have the following four major goals with this Thesis:
Vision Capturing: To write a comprehensible introduction to the D7D/COT project in the
context of COT and with a computer science viewpoint. The Thesis should be usable as
a starting point for people at DIKU interested in making a concrete D7D/COT project
and the Thesis should document the status D7D/COT project at the time of writing.
Vision Clarification: To analyse the D7D vision in the context of COT and with a computer science viewpoint. The analysis should cover the background of the vision, the
environment in which the vision is to be fulfilled, the theoretical aspects of the vision
and the empirical results obtained in past projects.
Empirical Experimentation: To describe the two case studies done in this particular
project. The description should cover the work done, what decisions where made and
why, and the outcome of the case studies.
Project Synthesis: The Thesis should be able to answer the initial questions raised when
starting D7D/COT projects and be able to give recommendations on the “what to
build” and “how to build”. The conclusions should be based on the theoretical and
empirical work done.
1.5
Work Done
In order to fulfill the above described goals the author of this Thesis has participated in
the D7D/COT project during the period from August 1998 to March 1999 by the following
activities1 :
• Meetings at OSS, DMI and DIKU with the intend to define the project content in more
concrete terms and to achieve knowledge about OSS and DMI.
• Weekly visits at OSS with the intend to be “in-touch” with the domain experts.
• Reading of relevant documents related to the D7D project.
• Writing of two initial COT reports.
• Working on the prototype for the Power Prediction Tool and the Planning Tool for
block assembly.
• Training of Kasper Bøgh Pedersen from DMI in Object Oriented development2 .
• Participating in the COT seminar in Aarhus, August 24th and 25th 1998. Here the
project was presented as a part of the program.
• Presenting the project at the EPIC workshop on “software process developments and
new tools” at DELTA (Dansk Elektronik, Lys & Akustik) October 6th, 1998.
The Thesis was written during the period December 16th 1998 to March 15th 1999.
1
2
The activities done during the elapsed project period will be described further in 2.4 and in appendix B.
Analysis, Design, Programming and related concepts
CHAPTER 1. INTRODUCTION
1.6
7
Approach
In order to fulfill the Thesis goals a number of subjects have been selected for discussion and
analysis. The following approach is made with regard to the defined goals for the Thesis:
Vision Capturing: The background for the project is described with respect to both this
particular part of the D7D project (D7D/COT) and with respect to the D7D project.
This will include a description and analysis of the participants and their goals, a review
of the most important references to the D7D project and a description of the expiration
of the D7D/COT project so far. The documentation and status aspect is covered by a
description of the work done, especially the description of the two case studies.
Vision Clarification: This aspect is treated by the review of the most important references
and by an analysis of the D7D vision. This analysis is extended to cover the environment
in which the vision is to be fulfilled, i.e. the organizational aspects.
Empirical Experimentation: The two case studies done serve a basis for the empirical
aspect. The case studies will be described and analyzed upon with regard to the D7D
vision and with regard to the research goals defined by COT.
Project Synthesis: Based on the theoretical work and the case studies conclusions can be
drawn on how D7D/COT projects can help in the fulfillment of both the research goals
defined by COT and the concrete needs of DMI and OSS.
These items might not be clearly distinguishable in the Thesis—they cover a “subject” view
on the Thesis. Therefore the outline of the Thesis described in the next section is extended
with comments to cover the approach made in greater detail—a “structural” view.
1.7
Thesis Outline
The Thesis is divided into five parts:
Part I: Introduction
The introduction part of this Thesis consists of three chapters. Chapter 1 (this chapter)
gives an introduction to the Thesis. It includes an introduction to the subject of
interest (the Design in 7 Days vision), a description of the goals for the Thesis and
this description of the Thesis structure and the approach made. Chapter 2 gives a
description of the background for the Thesis. In this chapter a description of the
partners participating in the D7D/COT project is included. The research goals defined
by COT are described and discussed. This discussion serves as a basis for later analyses,
where an elaboration of the research aspects with regard to the case projects are done.
To describe the research context in which this project operates the chapter 3 is included.
This chapter gives an overview of the most important references to the D7D project with
particular emphasis on the engineering background. It is my belief that the engineering
aspect is necessary to understand in some extend before real progress can be made by
the participants from DIKU in the matter of concrete projects.
CHAPTER 1. INTRODUCTION
8
Part II: Design in 7 Days—The Vision and Background
To understand the subject of this Thesis and to be able to understand the D7D project
a thorough understanding of the D7D vision is necessary. The vision is described in a
paper by Jan Tuxen ([Tux96]) but this is mostly a description of the wishes for the future
together with a conceptual model for “the system”. It is my belief that this description
needs to be enhanced in various ways. At first, the vision needs to be described more
detailed from the conceptual viewpoint. Second, the vision can not stand alone but
needs to be understood in context of the surrounding environment. In this case this
means an understanding of the organization in which the changes are to be applied.
The organization should be understood as a broad term including the division of labour,
the IT-tools at use, the process of design and construction, the planning process etc.
This part of the Thesis describes these subjects: chapter 4 describes the D7D vision
from an overall perspective, chapter 5 gives an overview of the organizational structure
at OSS and the use of IT-tools and chapter 6 describes the planning and design process
as it is carried out at OSS.
Part III: Design in 7 Days—The Implications
The fulfilling of the D7D vision can not be done without an understanding of the implications of it. These implications ranges a large number of issues: general considerations
regarding the environment in which the D7D/COT project is operating, what development strategy to use in the D7D/COT context, what the overall implications of the
D7D vision are and how these implications of the vision should be manifested with regard to the type of systems needed. This broad number of implications are the subjects
for chapter 7
Part IV: D7D/COT Project Cases
Two case projects are currently in progress. The first case project was the development
of a prototype for a power prediction tool. The prototype is working at the time of
writing and is subject to evaluation by the partners (DMI and OSS). The second case
project is also a prototype experiment and the subject of this is a tool to help the
planning of the assembly sequence of grand blocks in the dry dock. This prototype
is under construction at the time of writing. These two case studies are described in
chapter 8 and in chapter 9 respectively.
Part V: Conclusions and Future Work
This part summarizes the conclusions and lessons learned during the project period and
the Thesis writing (chapter 10). As the D7D/COT project still is ongoing a number of
suggestions regarding future work is given in chapter 11.
Part VI: Appendix
People not trained in shipbuilding should be able to understand this Thesis, therefore
a terminology list is included as an appendix for reference. Also included is a list of
the used abbreviations. These can be found in appendix A on page 130. To document
the initial phase of the D7D/COT project a detailed schedule of the project is given in
appendix B
Chapter 2
Background
In August 1998 the Department of Computer Science at the University of Copenhagen
(DIKU), Odense Steel Shipyard Ltd. (OSS) and the Danish Maritime Institute (DMI) signed
a Research and Development contract as part of the Center for Object Technology (COT)
research program. The subject for this R&D project is the Design in 7 Days vision of the
future way of designing complex one-of-a-kind products in the scope of object technology.
In this chapter the background for the D7D/COT project is described. The participants
in the D7D/COT project are presented. This presentation will shortly describe the individual
partner (except DIKU) and give their main reasons to participate in the D7D/COT project.
The work done by the participants during this first 7 months of the project is described.
2.1
Center for Object Technology
The Center for Object Technology (COT) is an organization founded in 1997 under the Danish
National Center for IT Research (CIT). The objectives behind COT is described in [COT97]
and the most important background information is covered in this section.
2.1.1
COT Organization
A number of partners participates in COT and they are divided in three categories:
• Approved Technological Service Institutes (GTS institutes): Technological Institute
(TI), The Danish Maritime Institute (DMI)
• Research Institutions: Department of Computer Science at the University of Aarhus
(DAIMI), The Maersk Mc-Kinney Møller Institute at Odense University (MIP/OU),
Department of Computer Science at Copenhagen University (DIKU)
• Industrial Partners: Bang & Olufsen A/S (B&O), Danfoss A/S (DF), WM-data A/S
(WM), Odense Steel Shipyard (OSS), Mærsk Line (ML), A.P. Møller (APM), Mærsk
Training Center (MTC), Rambøll A/S (RB), Systematic Software Engineering (SSE)
9
CHAPTER 2. BACKGROUND
2.1.2
10
COT Goals
The goal of COT is to carry out research, development and knowledge integration in Object
Oriented technologies with the needs of the participating companies as initial starting point.
The overall goal is to develop software methodologies (understood very broadly) that address
the needs of the participating companies/institutes and to gather knowledge of how they in
an efficient manner can introduce this new knowledge in the organization. The goals are to
be fulfilled by concrete case projects carried out in cooperation between the participants.
The goal for the participating of the research institutes are:
• to test new theories (broadly understood) regarding object technology through practical
projects and thereby uncover the advantages, drawbacks and shortcomings of object
technology.
• to gather ideas for new theories regarding object technology.
• to contribute to a greater cooperation between the participating companies and research
institutions.
The goal for the participating service institutes are:
• to get increased competence in the field of object technology.
• to develop new services in form of e.g. courses and consultancy.
• to distribute the results obtained to a broader number of companies.
• to secure a suitable balance between the often long-range research interests and the
often more short-ranged interests of the companies.
The goal for the participating industrial companies are:
• to increase their competitiveness with regard to the development of software.
• to get increased competence in the field of object technology.
• to develop solutions of industrial problems based on the results obtained during the
project period.
• to become good examples to other companies on how object technology can be used
most efficiently.
2.1.3
COT Research Activities
The COT research activities are intended to cover a broad number of fields related to object
orientation, e.g. modelling of application domains, reuse in any aspect and integration (use
of object oriented methods through the whole life cycle of a project).
COT is intended to give both projects specific (in-depth) and general (in-breadth) research
results. COT is centered around 6 cases, each involving a number of the partners from all
three categories. These cases defines the in-depth background for the research projects. The
CHAPTER 2. BACKGROUND
11
in-breadth results are intended to be the outcome of cross-case workshops, seminars and
talks.
The research goals are to be achieved by a combination of theoretical and empirical
activities together with practical advises. This work is to be carried out in the case projects,
where three main areas are the focus points for each project:
1. The architecture of object systems
2. IT support for cooperative object oriented software development
3. Introduction of object technologies
A number of relevant subjects for each of these three focus points are defined by COT—the
content of these focus points are the subjects for the next sections. For each of the focus
points the relevant subjects are described together with some comments.
Architectures of object systems
It is well known that the use of object orientation in itself is not enough to secure reuse
of software. This focus point has the goal of developing new models and techniques for the
reuse of software. The following subjects are defined as interesting when addressing this focus
point:
• Application Frameworks: application frameworks (AF) are application specific program
blocks that are reusable in the development of programs in the application domain.
Good examples of AF’s are the graphical frameworks for development of GUI’s (e.g.
Motif and Java AWT) and frameworks for network programming (e.g. ACE [Sch94]).
Frameworks for other areas are also beginning to emerge, e.g. for simulation and hyper
media. A good general framework is often developed as a result of a specific problem,
but it requires an extra effort and it requires constant maintenance and improvements
to be useful in a greater perspective. This research subject has e.g. the following goals:
– How can more or less specialized AF’s be adapted to a more general kind
– Development of design patterns for use in connection with AF’s
– Development of tools to develop and use AF’s
The use of AF’s are becoming increasingly important as a way to build reusable OO
software. E.g. almost any development of an application with a GUI would build on
top of a graphical AF, and the effort required for not using an AF would be enormous.
A good example of an OO AF with great success is the Adaptive Communication
Environment (ACE).
• Design rules and Design Patterns: reuse should not only be applied at the code level
but should be understood as a general subject throughout the whole development cycle.
A hot topic in this context is the use of design patterns to communicate solutions to
re-occurring problems [GHJV94]. A research goal of COT is the development of design
rules and design patterns to support reuse in a general way. The term design pattern
should be understood broadly, which includes e.g. analysis patterns and meta patterns.
CHAPTER 2. BACKGROUND
12
Design patterns can be a powerful way of communicating well-designed object structures. But the technique is also in a state of misuse—today nearly everything is described as being a pattern. Another problem is the explosion in the number of patterns.
A great deal of the published patterns are more language specific than they at first appear to be. This is e.g. documented in the Thesis [AH98] where a comparison of the use
of patterns in two OO languages are given. A simple result of this study is e.g. that the
singleton pattern is very C++ specific and not necessary in other languages (in this case
the Emerald language). A paper presented at OOPSLA’98 ([AC98]) has also described
this problem in the context of the patterns given in the GoF book ([GHJV94]). The
conclusions of this paper is e.g. that the design patterns in general should be evaluated
with regard to whatever they are fundamental, language dependent, related patterns
or not design patterns at all. As examples they argue that the observer pattern is a
variation of the mediator pattern: the object structure is equal in both patterns, but
the communication pattern (sic!) is bounded in the case of the observer pattern. I.e.
the observer pattern is a restricted version of the mediator pattern. Another example
from [AC98] is that the strategy pattern is not qualified as being a design pattern at all
(it is merely a “normal” OO way of thinking) and they qualify the factory method to
be a language dependent design pattern because the effect can be expressed directly in
languages that have virtual classes.
The use of design patterns for both documentation purpose and to describe a rational
use of the AF is also beginning to be accepted as a reasonable thing to do. A good
example of this is the Adaptive Computing Environment where patterns are used to
express the “correct” use of the framework.
I find the ideas behind patterns in all aspects interesting and useful—but, as the above
discussion also expresses, there is much research left to be done in the area of patterns.
• Component Based Development: the use of software components as building blocks in
software development has emerged as a powerful way of enabling reuse. A number of
new standards for components have been presented, e.g. MS-COM/OLE, MS-DCOM,
OpenDoc and JavaBeans. Some of these are standards for adapting a binary component
into an application (e.g. COM/OLE) whereas others are standards for an intermediate
format (e.g. JavaBeans). One of the benefits is that existing applications (e.g. written
in another programming language) can be wrapped into a component type and used in
another language environment or in a completely different system than original thought
of. But a number of problems exists, e.g. regarding the requirements to the development
environment: currently the typical software development environment has little or now
support for the wrapping of code into components.
• Distributed Objects: modern computing environments are becoming more and more
distributed. Most machines are today somehow network connected, e.g. on a LAN. This
has the effect that more and more applications are distributed where people working
on different machines accesses and updates the same data model at the same time or
uses other shared resources placed “somewhere”. The object abstraction has proved
useful as an abstraction mechanism when developing distributed applications (e.g. the
CORBA standard and the Java Remote Method Invocation mechanism). This research
subject is also related to the above subject of component based development. Some
of the proposed standards for components are also standards for the distribution of
CHAPTER 2. BACKGROUND
13
objects. This research subject should also cover distribution aspect in the analysis and
design phase of software development.
• Open Implementations: in [COT97] described as components/applications where “handles” are present in order for an adaption to be able to take place. In this way the
implementation can be adapted to a new or changed environment. I will in this Thesis
use a broader understanding of the subject and thereby include e.g. implementation
that are easy to integrate in a existing environment.
• Extreme Objects: extreme objects are defined to be objects not fitting the normal
concept of an object, e.g. very large objects, transverse objects and local objects. As
an example of a very large object an account is used. In the modelling phase the object
representing an account might end up to be very large if all aspects are to be covered.
This might cause the object to be so exhaustive that a practical implementation is
impossible. Means for the handling of those situations are by COT defined as research
subjects.
• New Language Constructs: as a result of work done in the other subjects it might
turn out that new language constructions could be proposed. An example of this was
presented in the discussion of the design patterns subject: virtual classes can be used
to express a design pattern directly in the language.
• Documentation: the documentation of OO software is important (this is naturally also
the case for software written in non-OO languages). Especially with regard to reuse the
documentation is important. This subject was also addressed in the design patterns
discussion—design patterns could turn out to be a very powerful way documenting
software.
IT support for cooperative object oriented software development
The intention of this focus point is to cover two important aspects of the development of
OO software: cooperation and informal analysis. Most current software development environments are single user systems. Many development projects requires the involvement of
many people, there is need for environments where cooperation can be made easier. Another
problem with current environments is the need for support of more unformal part of the
analysis phase. This focus point has the goal of the development of tools to support cooperation and informal analysis. The tools should enable the users to make the analysis and
design process faster than today. The tools should also ensure a higher degree of quality in
the result by capturing all the decisions taken and by securing that all relevant aspects have
been considered. The following subjects are defined as interesting when addressing this focus
point:
• Tools for Unformal Analysis and Design: development of tools where initial and unformal analysis and design decisions can be kept. The tools should enable the work with
outlines and unformal drawings that through stepwise refinement are made more and
more formal. The COT description of these subjects are referenced to the DEVISE
tool.
I believe that great care should be taken not to transform informal work into a formalized framework. It might be the case that the use of tools for a “brainstorm” session
CHAPTER 2. BACKGROUND
14
turns out to be a greater drawback than benefit because the tool imposes a certain way
of doing the work and thereby the possibility of “killing” the creativity needed in this
phase.
• Conference support for Object Oriented Development Tools: the integration of tools
developed (e.g. as described above) with conference support, e.g. shared drawing tools.
The intent is to enhance the communication aspect in discussion situation.
• Use of Electronic Blackboards and Integration with non-electronic Tools: often the
initial phase takes place with blackboards and pen/paper as the most important tools.
After this the decisions are to be transfered into the development tool at use. It might
be possible to integrate the process more, e.g. by use of electronic blackboards.
• Development of Techniques and Integration of new Tools: the tools developed as a
result of the above research subjects needs to be integrated within the existing user
environment. Therefore work should be done regarding a further development of the
tools to cover aspects of user involvement, rapid prototyping etc.
Introduction of Object Technologies
The introduction of OO software, OO software development and other aspects of OO technology are often difficult in practice. The introduction of e.g. an OO development strategy
requires training of the people who are going to use it. The introduction of OO technology
might also cause a shift in the culture of the company where it is going to be exploited,
e.g. regarding design with reuse in mind. The goal of this focus point is that the aspect of
technology transfer regarding OO technology is to be uncovered. The goal is of course that
the participating companies are “matured” with regard to OO technology and in the future
will use it. The following subjects are defined as interesting when addressing this focus point:
• Object Oriented Development Processes: models for the analysis, design and implementation of OO software is to be developed that fits the needs of the participating
companies. The models should address important questions on how to ensure product
quality, estimation of time, process management etc.
• Introduction of Object Technology: the introduction of OO technology in the participating companies and service institutes will require training. This training must fit in
with the culture of the company. Means to introduce OO technology should therefore
be investigated—should workshops be used, are mentoring a better idea, could pilot
projects help etc.
Two ways of introducing new technology is often considered: the “big bang” way where
tools, process and methods are changed “over the night” and the step-wise introduction
where a gradually shift is made. Both ways have benefits and drawbacks and it might
be worth investigating what method to use given a specific situation.
The problem of visualizing the results of an introduction of new technology is another
aspect. Often the introduction first “pays off” at a later time when the methods have
been well established. It could therefore be interesting to develop better means for
measuring the benefit of the introduction.
CHAPTER 2. BACKGROUND
15
The cultural aspect is also to be considered. It might e.g. be a good idea to send people
to attend a course in small groups over a longer period of time instead of all at once.
Thereby a constant influence of new ideas are enforced.
The training aspect is also very important. How should people be trained in OO
technology. This is of course dependent on their background and the reasons for the
training process. Research on how to train people in a given situation is needed.
• Introduction of Reuse: the problem of reuse has already been addressed several times.
One of the greater aspects of this subject is how to develop a company politic on
reuse. The question of how people should be trained in considering the reuse aspect is
important. The problems covers both organizational, technical and cultural issues.
• Maturing through step-wise Introduction: this subject is closely related to the subject
regarding introduction of OO technology described above. In this context this subject
is regarded as a part of the above discussion.
• Methods to handle Heterogeneous Platforms: in many companies object technology
has to work together with other technologies, e.g. relational databases. Many problems
regarding the integration of OO technology with other non-OO systems are still present.
This subject will focus on these problems and try to give solutions to as many as
possible.
• Scenario Based Prototyping: in the COT description the DEVISE tool is mentioned as
the starting point for work regarding this subject. In the context of this Thesis (and the
D7D/COT) project the subject should be broadened to cover prototyping development
in a larger perspective. Prototyping can be a powerful way of capturing requirements
when developing applications within an “unknown” domain and this subject is regarded
as important in this particular case.
The importance of this subject is further qualified when the success of the COT case
5 is kept in mind. In this project ([CCD+ 98]) a prototype of a global customer service
system was developed. The outcome of the project must from a research viewpoint be
regarded as a great success, and the conclusions and lessons learned from this project
should be investigated with regard to this D7D/COT project
2.1.4
Conclusions Regarding COT
This completes the discussion of the Center for Object Technology. Many aspects have
been discussed and I find this discussion necessary to keep in mind when working with the
particular D7D/COT project. The participants from DIKU are required to consider these
subjects and try to make progress on (some of) the described problems. Some of the subjects
are not relevant for this project whereas others are very important. The COT goals are
further elaborated later in this Thesis—the two case projects are e.g. related to the goals
where the research possibilities are extracted. By keeping the goals of COT in mind relevant
results from the work can be extracted and captured for a more theoretical analysis and
description—which after all is the goal for the participants from DIKU.
CHAPTER 2. BACKGROUND
2.2
16
Odense Steel Shipyard
Odense Steel Shipyard (OSS) is a large shipyard founded in 1917–18 by A.P. Møller. In 1959
the yard moved to its present location at Lindø (the yard is also called Lindøværftet, which
is Danish for “the Lindø Yard”) and is today among the most modern shipyards. The yard
employs more than 3000 people and has manufactured over 340 ships to customers all over
the world. OSS has invested many resources and much effort in the development of suitable
IT-tools, advanced partly automated assembly lines, welding robots etc. The result of this is
that the yard today has a very advanced production system and is capable of manufacturing
many different kinds of highly specialized ships. Among the ships manufactured at OSS
are: the panamax container vessel series (the first container vessel able to pass through the
Panama Canal with 11 containers across in its cargo holes instead of 10 which was the limit
for all panamax vessels up till then. The total capacity of these vessels are 4300 TEU), the
first double hulled VLCC (super tanker) and the largest container vessels ever build with a
capacity of 6600 TEU.
The production facilities includes three dry docks, where only one of these is large enough
for new buildings and the other two only are used occasionally. The capacity of the largest
dry dock is 415m × 90m × 10m. The cranes at OSS includes a number of cranes with lifting
capacity up to 50 tonnes, two with lifting capacity up to 100 tonnes and one very large gantry
crane with a lifting capacity up to 800 tonnes.
The product strategy at OSS is not to build the cheapest ships (as a competition parameter), but to offer the customer a ship that has the lowest life-cycle costs and to a very high
degree meets individual requirements. In other words, the main competition parameter for
OSS is to be able to meet new market demands faster than other yards ([DF97], page 131).
OSS is part of the Danish concern A.P. Møller Group that besides OSS includes: Mærsk
Line (the largest containership shipping company in the world), Mærsk Tankers, Mærsk Bulk,
Mærsk Supply Service, Mærsk Contractors, Mærsk Oil and Gas, Mærsk Air, Mærsk Container
Industries and a large number of other industries and retail companies. This construction is
special for a shipyard—the owner of the yard is also the largest customer. This gives benefits
for both OSS and the Mærsk shipping companies: if OSS are competitive the yard normally
gets the contract, and the shipping companies receives ships of very high technical standards
that OSS does not offer the competitors.
OSS has experience in both cooperation with other yards and with subcontracting of
work. In 1993–94 OSS bought the Loksa Yard in Estonia. The reason for this was to let the
Loksa Yard produce the deck hatches for a new series of container vessels. Deck hatches are
reasonable simple constructions (only straight components), and the Loksa Yard had already
experience in producing hatches. In April 1997 OSS bought a part of the Baltija Yard in
Lithuania (OSS now owns 90% of the stocks). The Baltija Yard used to manufacture navy
vessels but through great investments the yard is now able to produce curved sections for
OSS. The reason for relocating this work to the Baltija Yard is that this type of sections
are work intensive and the time wages in Lithuania are low. In 1996 OSS bought a machine
factory in Estonia. This factory now produces various manufactured subjects for OSS.
OSS has a long tradition for R&D projects with both research institutes, other companies
and in EU Framework Programs. A number of the most important projects and results are
presented throughout this Thesis. One of the most important projects at the time of writing
is the design of a business specific next-generation CAD system. This project is a cooperation
CHAPTER 2. BACKGROUND
17
between OSS and a number of international ship yards. This work is of great importance
to the yard, and this project is also referenced where appropriate in this Thesis. OSS is
involved in two of the COT cases: case 1 (the D7D/COT project) and COT case 6 (Object
Oriented Simulation Technologies). The research programs which OSS has participated in
ranges subjects like: Computational Fluid Dynamics in the Ship Design Process, software
components and open application frameworks for cellular manufacturing, inter-operability of
standards for robotics, user oriented production support in distributed shop-floor environments, evolutionary algorithms for industrial applications, concurrent engineering, residual
stresses in hot rolled steel plates—to name a few.
2.3
Danish Maritime Institute
The Danish Maritime Institute (DMI) is a technological service organization which offers
consultancy services in the fields of hydro- and aerodynamics with special applications in
the maritime, offshore, construction, process and energy industries. DMI is a private nonprofit organization. DMI is international and has provided consultancy services to both
private companies and public authorities in over 40 countries [DMI] [COT97]. DMI has a
tradition for involvement in R&D projects, e.g. EU Framework Programs, the COT case 1
(the D7D/COT project) and the COT case 6 (Object Oriented Simulation Technologies).
The physical facilities at DMI ranges:
• Five full-mission real-time marine simulators, which can be operated interactively in
clusters or as individual units. These simulators are used for training purpose where
critical situations can be simulated without danger. Simulation experience, e.g. regarding use of object technology and training courses, are the main input from DMI to the
COT case 6.
• Three wind tunnels including a 14m wide boundary layer wind tunnel. These are used
to carry out model experiments on bridges, ships, offshore platforms etc.
• A 240m×12m×5, 5m towing tank with powerful wavemaker and PMM apparatus. The
towing tank is used to carry out model experiments on hull forms. Models are build in
wood or some other material like fibre glass. The models are dragged through the water
basin and various hydrodynamic experiments are done: water resistance, leakage tests,
self propulsion tests (to test the propeller type and shape), sea keeping tests under
different wether conditions, maneuver tests etc. The models are normally build at DMI
based on line drawings from the customer. DMI has a range of stock model propellers
that can be applied to the model in the self propulsion tests.
The services provided at DMI ranges:
•
•
•
•
•
Model experiments in the towing tank.
Wind tunnel experiments.
Various simulation courses.
Advanced numerical analyses.
Field tests.
CHAPTER 2. BACKGROUND
18
Of particular interest to the D7D project is a database at DMI with model experiments
carried out at the DMI towing tank regarding speed prognosises of vessels. DMI has a vision
for a distributed speed prognosis tool. This tool should be accessible through a browser over
the Internet. The tool should be able to make a speed prognosis based on an initial hull form
and the database stored at DMI. The working prototype version as well as the vision for the
final tool is described in chapter 8.
2.4
D7D/COT Project Work Done
In this section the work done during the elapsed project period is documented.
The initial phase was begun by August 1998. The intent was that knowledge about OSS
and DMI was captured by us for later use and reference. After the initial meetings a number
of activities where carried out. The project period has more or less covered the following
activities:
• Initial meetings and discussions at OSS and DMI. These meetings where held to ensure
a tight coupling between the participants. The initial phase started with 10 meetings
at OSS and 1 meeting at DMI. The goal of this phase was for us to capture knowledge
about the domain of interest. In appendix B a detailed description of these meetings
is given.
• Weekly meetings at OSS with domain experts relevant for particular subjects of interest,
e.g. regarding the work on the prototype for the planning tool (see chapter 9).
• Reading of relevant documents and reports regarding OSS and other subjects. (See
chapter 3 for a review of the most important references).
• The writing of two initial COT reports (work in progress):
– An “as-is” report, describing the organization, use of IT-tools and the design
process at OSS together with the current way of making a speed prediction at
both OSS and at DMI. ([FLHF98]).
– A “to-be” report, describing the D7D vision and some of the D7D/COT project
ideas. ([FLP98]).
• Training of Kasper Bøgh Pedersen from DMI in Object Oriented techniques: analysis,
design, programming etc.
• Work on a prototype of the speed prediction tool. ([Ped99], [HP99]) (See chapter 8 for
a description of this project).
• Work on a prototype for planning the assembly sequence of grand blocks in the dry
dock. (See chapter 9 for a description of this project).
• We attended the COT seminar in Aarhus, August 24th and 25th 1998. Here the project
was presented as a part of the program.
• The project was presented at the EPIC workshop on ”software process improvements
and new technologies” at DELTA (Dansk Elektronik, Lys & Akustik) October 6th,
1998 [FL98].
The initial meetings were without question of great importance for us. The initial presentations given served as a good basis for our work, and the description of the organization
CHAPTER 2. BACKGROUND
19
and design process later in this Thesis could not have been done without these meetings. The
direct contact where the actual people doing a specific task explained the task for us where
of great value. A number of discussions with Claus Risager from OSS were also of central importance towards the understanding of the D7D vision and of the work done so far regarding
the fulfillment of the vision. A remark on the information gathered on the meetings should
be made at this point: it had happened that there were disagreement among the people on
exactly how a specific task is done at OSS. This point indicates that the total process is
very complicated and very difficult for individual people to comprehend in detail and/or that
different people solves a particular task differently. I will describe the inconsistency among
the information from the meetings where appropriate.
2.5
Background Summary
This chapter has covered the background of the D7D/COT project. The Center for Object
Technology was covered with the intention to clarify the research goals towards this project.
The two other partners—the Danish Maritime Institute and Odense Steel Shipyard Ltd.—
where described to clarify their capabilities and interests towards this project. Finally the
work done during the elapsed project period was described to give an impression of what
type of activities the project has covered so far.
Chapter 3
Related Research
A number of research topics are related to the D7D project, most notably the field of Concurrent Engineering. The D7D vision can be seen as the ultimate goal of Concurrent Engineering
and therefore this topic is described in this chapter. Other topics of interest is covered by
the broad term Knowledge Integration which also is treated. Some other fields serves in this
context of ways to obtain Concurrent Engineering and Knowledge Integration. This includes
Features and Virtual Enterprises and they are also described. I have omitted a description
of Object Oriented research (OO analysis, OO Design, OO programming languages etc.)—in
this context I expect the reader to be familiar with these concepts. I have structured the description in this chapter by topic—the description could also have been structured according
to the references, but I find the by-topic structure most readable. The presented topics are
interrelated and mutual references cannot be avoided—the presentation of the topics should
therefore be considered “in its whole”.
Although most of the related research presented in this chapter is in the field of engineering
it is very important to be acquainted with it, because it defines the background for the D7D
vision and project. Because the D7D/COT project is a part of the overall vision and project
the information presented here also serves as an introduction to the background for the
D7D/COT project.
A note on the Thesis structure has to be made: in the description of the references some
of the concepts are just described in enough detail to be understandable on an overview basis.
These concepts are nevertheless important to understand but the full comprehension can first
be obtained throughout the rest of the Thesis. This chapter might therefore be subject to a
review after reading the other parts of this Thesis.
3.1
References Overview
Ways of obtaining both the goals of Concurrent Engineering and Knowledge Integration have
been explored by a number of projects at OSS. With respect to this Thesis and the D7D/COT
project the most important are the following:
• The work on Concurrent Engineering done by Kåre Groes Christiansen. This was a
Ph.D. project, and the results can be obtained through the following three reports:
20
CHAPTER 3. RELATED RESEARCH
21
1. Concurrent Engineering—A Knowledge Production Concept for a Shipyard
([Chr96]). This is the Ph.D. Thesis.
2. Analyse af forretningsgangen på Lindø1
([Chr94a]). A supplementary report to [Chr96]. Parts of this report are outdated.
3. Funktionsanalyse af forretningsgangen på Lindø2
([Chr94b]). A supplementary report to [Chr96]. Parts of this report are outdated.
Especially the Thesis (item one above) is regarded as a central reference for the D7D/
COT project.
• The work on Knowledge Integration by means of product modelling done by Thomas
Sandholdt Pedersen presented in his Master Thesis: Knowledge Integration through
Feature Modelling ([Ped97b]).
• The work on achieving Knowledge Integration through Virtual Enterprises done by Bo
Ensted Danielsen and Torben Siggaard Frederiksen documented in their Master Thesis:
Den Virtuelle Virksomhed — Videnintegration3 ([DF97]).
These references are the most general, i.e. they serve as a good basis for the understanding
of the challenges in the the D7D vision. All of these addresses the the D7D project by trying
to solve a particular part of the vision.
Other references are used for more specific purposes. The case studies done during this
D7D/COT project have required the use of additional background material. This is particular
true for the Power Prediction case (described in chapter 8), but it is out of the scope of this
Thesis to describe all the used references. Also the use of background material for the more
computer science related issues will not be described in detail here (as mentioned above), but
the use of these are documented where needed. Please consult the bibliography on page 126
for a complete overview of the references to this Thesis
A number of the used references (or parts of them) are classified and not available to
the general. This is particular true for the material regarding the planned replacement for
the CAD system at OSS. Also two chapters of [Ped97b] are classified and cannot be moved
outside OSS.
3.2
Concurrent Engineering
The primary source for the information in this section is [Chr96], but useful information has
also been gathered from [Ped97b] and from [DF97].
In [Chr96] the concept of Concurrent Engineering (CE) is studied both through a literature review and through discussions. Christiansen describes CE from a Knowledge Integration viewpoint, which should be kept in mind when reading both this section and when
reading [Chr96]. (Please refer to section 3.3 for a description of the concept of Knowledge
Integration).
1
The report is written in Danish. The translated title would be: An analysis of the business process at
Lindø.
2
The report is written in Danish. The translated title would be: A functional analysis of the business
process at Lindø.
3
The report is written in Danish. The translated title would be: The Virtual Enterprise—Knowledge
Integration.
CHAPTER 3. RELATED RESEARCH
22
An important goal of [Chr96] is to try to define the concept of CE properly. A definition
from the literature study done by Christiansen is4 :
Concurrent Engineering is a systematic approach to the integrated, concurrent
design of products and their related processes, including manufacture and support.
This approach is intended to cause the developers, from the outset, to consider
all elements of the product life cycle from conception through disposal, including
quality, cost, schedule, and user requirements.
The CE concept is often associated with the parallelization of the tasks needed to develop
and manufacture the product. But CE is more than a mere concurrent activity plan. In the
literature study done in [Chr96] three features of CE are identified:
• The reliance of multi functional teams to integrate the design, the manufacturing and
the supporting engineering process.
• The support of IT tools and computer integrated methods (CAD, CAM, CAE etc.) in
the design integration through shared product and process models and databases.
• The use of a variety of analytical methods to optimize the design, manufacturing and
supporting engineering process.
The goals of CE is to improve product quality, lower the costs and shorten the development
lead-time. The idea is to mass produce one-of-a-kind products. Christiansen illustrates this
with a so-called Concurrent Engineering Window: when e.g. a number of ships is view through
the CE window a customer sees different/customized ships whereas the engineers sees identical
ships from an design/manufacturing viewpoint. The fulfillment of the CE goals—improved
quality, lower costs and shorter development time— might not necessarily mean that CE
has successfully been deployed. The matter on how the degree of CE deployment can be
measured is discussed. The basis for this discussion is the observation that CE typically takes
an outset in the design phase of products. The design phase is typically the activity where
costs are committed for later phases. In [Chr96] it is mentioned that several investigations
show that the design activities typically only requires 5–10% of the total life cycle costs
but commits over 70–80% of the costs incurring in later phases. The problem is that the
costs actually committed during design can be very hard to monitor, e.g. opposite the costs
during manufacturing—the problem is to actually know what consequences in terms of costs
a specific decision will have. In respect to this Christiansen chooses to define a good CE
process to be the following:
A good Concurrent Engineering process is established if a product designer can
describe and estimate the committed life cycle costs of any significant design
decision before the design decisions are finally committed. ([Chr96], page 83)
This subject is very central in the D7D vision and will be described in more detail in section 4.1
on page 35.
The goals of CE in the context of OSS is the central issue in [Chr96] and a number of
hypotheses are given as central goals to justify. They are5 :
4
From Winner et. al.: The Role of Concurrent Engineering in Weapons Systems Acquisition. The quote
presented here is from [Chr96], page 12.
5
The hypotheses are taken directly from [Chr96], page 79.
CHAPTER 3. RELATED RESEARCH
23
1. Product models—developed with an engineering of engineering perspective—can enforce knowledge integration.
2. Product modelling can be approached with object oriented modelling methods.
3. A proper development of engineering enterprises requires that domain experts are responsible for product modelling.
4. Different knowledge production forms can be identified and described.
These hypotheses are justified by Christiansen through both theoretical work (literature study
and discussion) and by empirical studies. The empirical studies done were:
• A study of the engineering process at OSS.
• The development of a Concurrent Engineering concept for OSS. This work included the
development of both a product model and a prototype.
• The testing of the developed model and prototype in a workshop with engineers from
OSS. The workshop where focused on teaching the engineers Object Oriented modelling (the methodology used for the product model) and to test their ability as model
managers.
Based on this work a number of conclusions are made in [Chr96] (page 147–153). A brief
summary of these are:
1. Tasks in the engineering development process should be Knowledge Integrated in order
to accomplish CE. This can be done by developing company generic product models in
the development phase (not tied to a specific order of a ship) and use these to instantiate
a specific model/ship according to customer requirements.
2. The degree of CE should be measured by how good the committed costs can be measured
before the decisions leading to the commitment of costs actually are taken.
3. The “concurrent” aspects of CE can be achieved by either an automatic transformation
between the different viewpoints of engineering (e.g. between design and manufacturing)
or by constructing a very iterative process with feedback loops.
4. Christiansen suggests a merge between domain theory and an engineering of engineering
concept. This leads to domain models on a generic and on a specific level. The knowledge integration can then occur at both levels: on the generic level cross-functional
teams develops generic models and on the operational level the generic models are
instantiated through an iterative process where both the product model and the production process are developed—i.e. the “what” and “how” questions on the operational
level requires iteration to be answered. This approach was tested on a workshop and
turned out to be useful and feasible—Christiansen therefore concludes that hypothesis 1
is verified.
5. Based on discussions of various modelling methods Christiansen concludes (on the theoretical level) that object oriented modelling techniques are a fair choice when product
models are to be specified. This was also tested at the workshop where the conclusion
was that OO modelling techniques indeed are useful for product modelling. However,
CHAPTER 3. RELATED RESEARCH
24
the conclusion also is that these techniques needs to be enhanced by engineering theories. The conclusion is that hypothesis 2 is verified but that the OO techniques must
be enhanced with design theories and engineering architectures—which is concluded to
be a very strong approach to the development of an engineering enterprise.
6. Through the work done by Christiansen an architecture for CE was developed. It is
then argued on a theoretical level that domain experts needs to be in charge of the
models represented in the architecture. This was further supported by the testing of
the architecture by domain experts. Christiansen therefore regards hypothesis 3 as
verified.
7. Christiansen identified four different knowledge production forms during his work: dedicated, flexible, creative and virtual. These should be regarded as ideal forms but useful
as guidelines when designing the engineering enterprise in industrial companies. Please
refer to [Chr96] page 104–119 for a detailed discussion.
3.3
Knowledge Integration
The term Integration has already been mentioned a number of times in this Thesis, e.g.
Knowledge Integration, Computer Integrated Design/Manufacturing, tool integration and integration of object technology. It is therefore reasonable that the meaning of integration in
some of the varieties is discussed—especially for the concept of Knowledge Integration which
is the subject for this section.
Knowledge Integration is a general and broad term. In all the OSS specific references the
achievement of Knowledge Integration (KI) is regarded as essential to the overall goals, e.g.
shorter lead time and better products (e.g. [Chr96] page 83 and [Ped97b] page 26–28). The
topic is considered to one of the means to deploy e.g. Concurrent Engineering. It is therefore,
with regard to the D7D/COT project, useful to understand the concept—i.e. understanding
what is meant by it when reading the references or discussing the D7D vision.
The information in this section is based on parts of both [Ped97b] and [Chr96].
I will first describe the different forms of integration ending with KI in the context of
the description and definitions done in [Ped97b] page 26–28 because this reference is clear
and useful on the subject. Pedersen presents three different models of integration from the
literature and they are described in the following.
In the first reference a number of integration phases is first considered based on work
done on standardizing the term6 . With this viewpoint each phase in the integration is build
on top of the prior—i.e. the next step in integration requires the step below it. The different
integration phases are:
1. Physical Integration: the integration of inter-system communication. When this level
is reached systems can communicate at a certain level, e.g. hardware from different
vendors can accept each others work at once.
2. Application Integration: the integration of applications to be able to exchange information without concern about e.g. the specific vendors.
6
From Dansk Standardiseringråd (a Danish standardization organization):
Manufacturing—Systems Architecture—Framework for Enterprise Modelling, 1990.
Computer Integrated
CHAPTER 3. RELATED RESEARCH
25
3. Business Integration: the integration of business functions such as design, manufacturing, marketing and finance within the enterprise.
This model can be criticized for being to simplistic concerning the so-called Business Integration aspect. The second model7 addresses this aspect in more detail by focusing on
integration on specific tasks:
• Strategy Integration: the integration of viewpoints from the product strategy, production strategy and market strategy with the goal to form/define a company strategy
based on local company viewpoints and objectives.
• Product Planning Integration: the co-ordinating of the product development phases of
various products within an enterprise.
• Project Integration: the integration or co-ordination of various task groups within a
single product development phase. I.e. increasing the focus from single projects to cover
projects within a specific company function.
The last model8 presented by Pedersen is also the one adopted in his Thesis for the definition
of Knowledge Integration. The important distinction of this model is between Information
and Knowledge integration, here quoted from [Ped97b], page 27–28:
Information Integration: exchange of information between different functions based on
the same explicit semantic definition. A system is information integrated if it is secured
that the right information is at the right place at the right time for the right person and
the right task/function to perform. System information integration can be obtained
using different semantic definitions methods (from written definition to more formal
methods like IDEF19 models) and different information transfer mediums or means i.e.
speech10 written communication be it linguistic or graphical (i.e. types or symbols as
drawings), or IT-based solutions in different forms.
Knowledge Integration: implies information integration. Two functions are knowledge
integrated if their execution or carrying through is mutually adapted, co-ordinated and
attuned (i.e. integrated). Knowledge integration consequently concerns the way the
functions are performed (analogy to traditional work analysis: determination of work
elements and work procedure—today we lack concepts to describe knowledge work).
Knowledge integration can be obtained in different ways, i.e. through for instance work
description procedures (if convenient also IT-supported), teams work with clear goals
and holding the right qualifications (knowledge domains), product modelling based on
knowledge object definitions, etc.
This last definition regarding Information and Knowledge Integration is an adaption/enhancement of the definition given by Christiansen ([Chr96], page 23).
The goals of KI is clearly given in the above definition together with some way of obtaining
KI. This definition is also accepted for this Thesis.
7
From Myrup: Integreret Produktudvikling, 1995.
From Esprit Project: EP 7752, Work Package 3, Task 3.2, Deliverable 3.2 by Vesterager, Tuxen, Christiansen et. al., 1994.
9
IDEF stands for ICAM Definition, see page 82.
10
Might have been e.g. speech or written..., personal note.
8
CHAPTER 3. RELATED RESEARCH
3.4
26
Feature Modelling
As part of the overall D7D project Thomas S. Pedersen has studied the concept of features
resulting in the Master Thesis Knowledge Integration Through Feature Modelling ([Ped97b].
In the context of his work a feature is defined to be:
A carrier of product information that may aid the design or communication between design and manufacturing, or between other engineering tasks.
The feature concept originates from the attempts to integrate Computer Aided Design
(CAD) systems and Computer Aided Manufacturing (CAM) systems. Both CAD and CAM
systems where introduced around 40 years ago with the intend to help engineers develop
better products and better manufacturing procedures respectively. The meaning with the
term “better” in this context is shorter lead-time, time-to-market and higher quality at lower
price. But the difference in nature of the domains of design and manufacturing resulted in
the evolution of different types of systems, i.e. the systems lacked integration. This problem
led to the introduction of Computer Aided Process Planning (CAPP) systems. The purpose
of CAPP systems were to identify manufacturing information from the geometrical models
stored in the CAD systems and transform this into manufacturing information like NCcode (numerical code for machinery). The integration of these systems into a CAD–CAPP–
CAM systems led to the Computer Integrated Manufacturing (CIM) systems. However, this
integration was harder than expected. The problem was that the information stored in CAD
models was not sufficient for the CAPP systems. This problem, together with the desire
to evolve the CAD systems into more sophisticated systems, brought the feature concept in
focus. The latest systems are combinations of automatic feature recognition and design by
feature systems. The feature technology is now spread among a number of disciplines such
as engineering design, process planning and engineering analysis. The use of features has in
other words evolved from manufacturing systems to design systems, and it is widely accepted
as a key element in achieving CIM but is nevertheless still mostly on research basis ([Ped97b],
page 10–11, page 16).
Different types of features exists, e.g. functional features, assembly features, form features, tolerance features and material feature. As an example a form feature is described by
([Ped97b], page 16):
Features which represent portions of a parts geometry. Does not encapsulate
functional knowledge, hence they are seen as serving specific purpose within manufacturing, design, and geometry tasks.
An example of a concrete feature could be the welding of a profile on a steel plate. This is done
to ensure the strength of the combined element. From a design viewpoint this combination has
the purpose of stiffening the combined element and is viewed as such whereas the production
engineer has focus on what the assembly procedure is: how should the profile be welded to
the plate and can the welding robots access the structure in the given configuration.
A major goal in [Ped97b] is to explore the use of features to achieve knowledge integration. It is emphasized that concepts like Concurrent Engineering and Knowledge Integration
demands facilities in order to succeed. One of the conclusions in both [Ped97b] and [Chr96]
CHAPTER 3. RELATED RESEARCH
27
is that product modelling is a way of obtaining Knowledge Integration (i.e. product models and product modelling is one such facilities). The approach towards product modelling
in [Ped97b] is by feature modelling. This leads to the approach of achieving Knowledge Integration through feature modelling ([Ped97b], page 71). I.e. the goal of feature modelling is
the development of generic product models which should lead to better KI.
What a feature exactly is or how it is represented is also an interesting part of the work
done by Pedersen. Features are often defined as an entity with some attached variables/values
and with some behavior (e.g. what happens to the values of the variables when inserting the
feature in a context). Features are often ordered in a hierarchical way where inheritance is
exploited. This is strikingly close to a description of what object oriented methods are—
and this is often exploited when implementing features, e.g. expressed through the following
quote11 :
...feature-based models ... often realised through object-oriented programming as
a collection of classes with inheritance.
This way of describing the relation between features and object oriented methods is however
not the best way of answering the question “is object oriented method well-chosen when
features are to be described, modelled and implemented?”. Pedersen elaborates over this
question and ends with the following conclusion:
The advantages of the objects as means for communication between engineers and
programmers mean that object oriented programming is by far the preferred implementation technique. If one wants to utilise these advantages, object oriented
models have to be created. This means that the transition from feature models
into object oriented models, i.e. the mapping of features into objects, becomes
the key linking these two technologies. ([Ped97b], page 66)
One could now ask the question whatever features are objects—this is also elaborated by
Pedersen and he makes reference to the to him only known work done on this subject. The
work cited in [Ped97b] is the Ph.D. work done by Lars Hvam12 . In this work a feature based
model is mapped into an object oriented model. Hvam makes a domain analysis and an
object oriented analysis. In the latter part features are used to identify the objects: first the
domain is described through a set of features and then the feature model forms the input to
the object model. Each object can cover many features since Hvam classifies some features
as objects and some features as attributes to objects.
The use of an OO methodology is also used by Christiansen. In his work ([Chr96]
page 131–133) the object model developed during his prototype development is briefly described. The object model contains around 80 objects (classes) where each object describes
an element used by the designers during their job. The model covered the main structures
of a double hulled VLCC—i.e. a product model was developed through OO modelling. The
model covers the product from a functional viewpoint and to some extend from a structural
viewpoint. Although Christiansen never uses the concept of features explicitly he has analyzed the domain of the designers and adopted the terminology used by them. After this he
has mapped this domain analyze to an object oriented model.
11
From Mäntyla et. al.: Challenges in Feature-Based Manufacturing Research, 1996.
from [Ped97b], page 66.
12
Lars Hvam: Anvendelse af produktmodellering — set ud fra en arbejdssynsvinkel, 1994.
Here quoted
CHAPTER 3. RELATED RESEARCH
28
I will conclude this discussion of features as means for product modelling with the observation from a computer science perspective: whatever the concept is called features or
objects is irrelevant—no real difference is observed in the context of the references. What
is important in the context of the D7D/COT project is that object oriented modelling techniques have been established as a useful way of modelling the engineering domain. This proof
of concept has been done by engineers and based on engineer work—it is a useful proof in
the context of this project.
3.5
Engineering of Engineering
Engineering of Engineering is a concept that is relevant to know about in the context of
this Thesis. The concept has already been used in the hypotheses quoted from page 79
in [Chr96]. The description in this section is based upon the description given in [Chr96]
page 20–22 and [Ped97b] page 24–25.
The concept of manufacturing of the manufacturing system was introduced with the
ICAM13 project. This approach meant that the responsibilities for the industrial engineer
were extended to cover the manufacturing process and the control of the systems responsible for supporting the “classical” engineering work. Vesterager14 has described a similar
approach to engineering work of the future—Engineering of Engineering (EoE).
EoE is based on the postulate that work contains three elements: an intellectual, a sensoric
and a motoric element. Engineering is mostly intellectual based and is by Vesterager defined
as15 :
...the preparatory work carried out before the actual work is done. Among other
things this preparatory work aims at defining which tools are worth acquiring
(buying or developing) to carry out or aid the work in production. The preparatory work should also address how to apply the tools.
The next observation made is that a great part of the actual production in manufacturing industries can be / is done by advanced manufacturing technology—e.g. in the form of
computer and robot technology. I.e. the sensoric and motoric elements are taken over by
automation technology. This is (as said) particular true on the production level. On the
engineering level the intellectual work is mostly controlled by engineers—but IT-based tools
and systems have the potential to change this situation and has already done it in certain
areas. The following quote from Vesterager addresses this and describes thereby the EoE
concept16 :
... as a symbol processing machine the computer will be applied as mechanism for
executing the intellectual work. Administrative computer systems have already
taken over the routine part of the intellectual work. Now we are facing a situation
in which the complex and non routine work can and will be supported or carried
out by computers. The intellectual work in an industrial company will in the
13
Integrated Computer Aided Manufacturing, a project during 1975–1985 under the US-Airforce.
Johan Vesterager: Produktionsforberedelse på produktionsforberedelse, 1986.
15
Quoted from Christiansen’s translation of the article which was written in Danish.
16
Again taken from Christiansen’s translation.
14
CHAPTER 3. RELATED RESEARCH
29
future consist of solving new tasks in new ways with new tools. This is the
essence of engineering of engineering.
In the context of this D7D/COT project the words complex and non routine work are
interesting—the essence of this project is exactly to focus on this type of work. In the
same way that engineering can be seen as the production preparation EoE can be seen as
preparation of the engineering work. The ... new tasks ... new tools that Vesterager talks
about should hopefully be some of the outcome of this D7D/COT project.
3.6
Design Levels
The topic of a differentiation between the levels on which the design tasks takes place has
already been touched in this chapter. Both Christiansen and Pedersen advocates for a clear
distinction between the work tasks taken place when making generic product models and
when instantiating these to a specific product.
In [Chr96] (page 81–82) the distinction is described in the following way, where the activities are described as either belonging to the development or the operational phase:
• Design of company generic models: the development of product models as the basis for
computer aided product configuration. The results of this is models of how to make
e.g. drawings. This activity takes place in the development phase.
• Design of company specific models: the development of products based on product
configurators. The result is specific, e.g. drawings. This activity takes place in the
operational phase.
In [Ped97b] (page 86–88) the concept is elaborated in more detail. The description is
based on work done at OSS in the extension of the work done by Christiansen as described
above. The distinction is coined as follows:
• Strategic Phase: the level of industry specific decisions, e.g. specific for shipbuilding at
OSS. On this level the strategy for the company is decided—what kind of products to
build, which facilities to invest in, what methods to develop, which virtual enterprises
to engage in and equal.
• Tactical Phase: the level of generic domain modelling. Families of products, facilities
and methods are defined and modelled. This happens accordingly to the strategic
decisions specified at the strategic level. The models are generic in the sense that they
do not describe a specific product of facility but describes e.g. a generic object model
of double hulled VLCC’s.
• Operational Phase: the level where a specific request by a customer is translated into a
specific product or where the management decides that new ideas are to be tested. The
main activity in this phase is to instantiate the models specified on the tactical level.
The instantiation takes place as the assignment of values to the attributes describing
the generic product in focus (e.g. the generic double hulled VLCC). The assignment of
values to attributes is the same as assigning behavior to the objects/features used in
the product description. Through this assignment a specific product is specified (design
viewpoint) and the facilities and techniques to be used is specified (manufacturing
viewpoint).
CHAPTER 3. RELATED RESEARCH
30
In light of this discussion and the project context as described in [COT97] the D7D/COT
project is mainly related to the development of support for the tactical level. This will be
further elaborated upon in this Thesis.
3.7
Virtual Enterprises
The description of the concept of Virtual Enterprises (VE) in this section is based on [DF97].
This Master Thesis describes the concept in relation to the ship building industry and with
OSS and Loksa Shipyard Ltd. in Estonia as case study. VE’s are in [DF97] seen as a possibility
for how Agile Manufacturing (AM) can be realized—this section will therefore start with the
introduction of this concept.
AM is in [DF97] described as a concept used as synonym of the “post mass production”
paradigm. The concepts covers an ability in the industry/company to be able to make changes
quickly, flexible and with the individual customer as focus point. Unanticipated changes in
the market situation are responded to without compromising the profit of the company. I.e.
an agile company is able to deliver custom specific products that still pay-off.
The demand for individual customized products are explained in terms of the so-called
market window: the life-cycle of products is becoming shorter and shorter. This demands
that companies in order to exploit the market window optimal have to be able to quickly
adapt to the situation—i.e. be agile.
The hypothesis in [DF97] is that VE’s are a way of adapting a company or group of
companies to the agile manufacturing environment—i.e. a way of transforming the traditional
mass production company to the company concept of “tomorrow”.
Two concepts are needed to understand in this context: core-competence and business
process. Without going in two much detail the following descriptions are adopted for this
Thesis:
Core-competence: a chain of value-increasing functions are applied to material of some
sort in order to produce a final product—the refinement of raw material to salable
product. A company should be aware of what functions are its core capabilities—i.e.
identify the links in the chain that “pay-off”. These functions are the core-competences
of the company. The core-competences are the platform from where the company can
develop new products and services. The core-competences consists of the resources accessible to the company in form of physical items (buildings, cranes, machines), human
factors (man-power, capabilities available in form of trained people, the mix of different capabilities and their composition in an organization), financial resources (financial
capability, assets available etc.) and some “impalpable” resources (knowhow, image,
goodwill).
Business Process: the overall processes of the business: management, product development, logistics etc. Business processes are cross-functional and is the way that customers views the business—from customer needs to final product.
In this way the core-competences of a company can be seen as the potential of the company to
meet future customer needs and the business processes as the way that the core-competences
are exploited.
VE’s are in [DF97] (page 83–84) described/defined as:
CHAPTER 3. RELATED RESEARCH
31
A structuralized combination of a number of companies from a network of companies. The network of companies is thought of as an alliance where companies
can enter end leave dynamically and where they “offer” some services. When a
specific customer need is realized a number of the companies in the network can
be structured to form a virtual enterprise with the goal of fulfilling the customer
need. The idea is that each company should contribute with its core-competence
and in that way capabilities arises that could not be offered by a single one of the
participating companies.
This definition is of course very general and many practical experiments needs to be done in
order to uncover the problems that are present—these include the problems of management,
profit sharing, jurisdictions and law, customer contact, product specifications etc. [DF97]
represents an attempt to solve a number of these problems especially the specification problems involved when parts are build at different places but have to be assembled to a complete
product. Although the broad definition of VE’s and the great number of problems existing
the model is still useful in a number of ways towards this project which will be explained in
the following.
In the above definition a number of realization structures are possible, e.g.:
1. Parent/Subsidiary relationships (dependent companies)
2. Supplier/Receiver relationships (independent companies)
3. Peer/Peer relationships (independent companies)
The two first items above are particular interesting with regard to OSS—OSS owns a number
of subsidiary companies and OSS is also very dependent on suppliers especially for equipment
(e.g. the engine).
In [DF97] the focus point is how to specify blocks in enough detail to be produced at
different places without over-specifying. The problem is to build a reference frame useful and
understandably by both sides (in this case OSS and the Loksa Shipyard)—the relationship
is therefore of type parent/subsidiary. The hypothesis is that Knowledge Integration (KI) is
the best way to view or attack the problem. This work is in direct extension of the work
done in [Ped97b] and [Chr96]. In [Chr96] the KI concept was to be ensured by means of
Concurrent Engineering (CE) and product modelling. The CE aspect of VE’s is somewhat
difficult: with the CE concept cross-functional teams work on structuring their knowledge
in different company specific models over a period of time and the models need constant
maintenance. This can not be done in a VE: they only exist over a short period of time
and mostly operate on the operational level (a specific product has to be build). The way of
solving this in [DF97] is to focus on the relationship between OSS and Loksa Shipyard: it is
a reasonable stable relation so the dynamical aspect of VE’s are not explored in detail. I.e.
the stable situation makes a solution on the tactical level feasible.
The approach in [DF97] is to analyze the domain of core-competences at OSS regarding
the block division and the manufacturing of the blocks. The acquired knowledge was then
used to build three generic domain models using features as semantic basis. The focus was
to build product models with “enough” knowledge to be useful and without over-specifying:
1. A partial product model for the design of blocks with regard to the design capabilities
at OSS.
CHAPTER 3. RELATED RESEARCH
32
2. A partial product model for the manufacturing methods of blocks with regard to the
manufacturing preparation capabilities at OSS.
3. A partial product model for the facilities at both OSS and Loksa Shipyard.
These models were then used to build a prototype for a tool to help deciding where to
build the blocks. The prototype was evaluated by domain experts and considered as a useful
step in the right direction. The prototype was judged as useful for the survey of production
competences that could not be comprehended on a manual basis.
A number of interesting conclusions are made in [DF97]—here they are summarized in
no particular order:
• The use of prototyping as development strategy turned out to be very useful for capturing the requirements and ideas of domain experts ([DF97], page 156).
• Domain models are useful as the semantic basis for applications targeting the goal of
Knowledge Integration ([DF97], page 174).
• The concept of “enough” knowledge regarding models to be useful without being overspecified turned out to be meaningful—it was possible to concentrate on partial knowledge and model this in an useful application ([DF97], page 174).
• The use of Object Oriented modelling techniques to map the domain models into useful
implementation models was successful ([DF97], page 175).
I will end the discussion of VE’s with the following observation: the work done in[DF97]
is very focused at products and manufacturing—but there are plenty of areas where the
knowledge possible to offer as service in a VE (the core-competences) is on the form of “pure”
service products (i.e. a product that e.g. only exists as results in an IT-tool). This is also true
for OSS. An example of this knowledge could be experience regarding the main dimensions
of ships, their engine power and their physically properties (speed, maneuver characteristics,
fuel consumption etc.). This could be especially interesting for full-scale ships—i.e. the true
data from real ships. These data could be exploited through a VE in a number of ways, e.g.
different tools for verifying ships in the design phase. This form of VE’s is in some sense the
model for the vision of a Power Prediction tool as described in chapter 8.
3.8
Conclusion Regarding Related Research
The purpose of this chapter was to describe the research context in which the D7D/COT
project has to operate. A number of relevant topics have been selected and discussed—they
are in the following shortly summarized where the key points mentioned also briefly describes
the adaption of the concepts towards this Thesis:
• Concurrent Engineering: engineering activities are in a CE environment carried out
in parallel tasks that are tightly integrated. Keywords are: cross-functional teams
integrate different viewpoints, IT-support integrate the product view through shared
product and process models, analytical methods are used for optimization.
• Knowledge Integration: the mutual adaption and synchronization of the execution of
different functions and tasks. Implies information integration.
CHAPTER 3. RELATED RESEARCH
33
• Feature Modelling: a carrier of product information that may aid the design or communication between design and manufacturing, or between other engineering tasks. A
syntactical and semantical object that can be instantiated in a larger configuration. A
possibility towards the integration of different viewpoints in product modelling.
• Engineering of Engineering: the situation where engineering work is shifting from traditional engineering (product preparation) towards the engineering of e.g. engineering
methods (preparation of preparation).
• Design Levels: the clear distinction of work tasks belonging to either the strategic,
tactical or operational level. On the strategic level company specific decisions are made,
e.g. what products to produce. On the tactical level the strategic decisions imply what
to adapt the company generic “bereitschaft”17 towards. Generic models are defined on
this level. On the operational level a request triggers an instantiation of the generic
models to a specific product.
• Virtual Enterprises: a number of companies offer their core-competences to form a new
structure where a synergic effect arises for all the participants. The products that in
this way could be offered to customers could not easily be offered by a single of the
participating companies alone. The VE’s are a possibility in the market demand for an
agile manufacturing concept: individual customer needs are in focus where customized
products are manufactured in a mass-production fashion.
It is my opinion that these concepts/topics are necessary to know about in the context
of this project. The terminology alone is necessary in order to be able to communicate
effectively with the participants from OSS when discussing the overall goals. (In the same
way other terminology is necessary to know about in the case studies done, e.g. regarding
the manufacturing of ships or the description of hull forms).
Some of the presented concepts are very valuable to know about whereas others are mainly
interesting in their conclusions. The first is true for the Concurrent Engineering concept—
very valuable information and elaborations are presented in [Chr96], e.g. also regarding what
type of tools should support the CE approach. On the other hand the important result
of the Feature concept is that object oriented modelling is considered as useful for product
modelling—what the models are going to contain is mostly an issue to be solved by the domain experts (users), the participants from DIKU should mainly focus on the more technical
considerations regarding the architecture and implementation of the support tools. A clear
distinction is of course not feasible but the distinction should at least cover the “in charge
of” issue.
17
The term used in [Chr96] to describe the union of generic product/facility/method etc. models. A translation could be Preparedness.
Part II
Design in 7 Days
The Vision and Background
34
Chapter 4
Design in 7 Days—The Vision
In this chapter the main vision of the D7D project is analyzed. The analysis is from a top
view—no direct connections are drawn to actual projects or project ideas. The intention is
to line up the forces that give the constraints for the D7D project and to analyze the D7D
vision given these constraints—in other words, the intention is to clarify what the vision is
about and outline a conceptual architecture. If concrete examples are needed to enhance the
description these will be actual examples from OSS.
Many of the concepts needed to understand the vision have been presented in chapter 3 and therefore the description of the actual D7D vision will in some places seem to be
repetitions—but the focus of this chapter is to extract the essence of the vision and describe it
as clear as possible. It therefore seemed useful to describe the research background separately.
4.1
Background and Forces
OSS manufactures ships by order. Potential customers invite OSS to make a bid for a contract
for building a ship (or a series of ships) and OSS then makes a bid involving price, delivery
dates, cargo capacity, maximum speed, fuel economy, etc. These factors are more or less
open to negotiation from contract to contract. If OSS gives a too weak bid (too high a price,
too late delivery date), the yard will not get the contract. If OSS gives too strong a bid
(a price that cannot be met, a delivery date that is impossible, etc.) OSS will lose money
and possibly prestige. OSS typically has weeks or a few months to make a bid. The general
market tendency is that manufacturing of new ships is highly competitive (see e.g. [DF97],
page 130–131).
The yard produces several ships at a time. Not necessarily from the same series. The
products produced at OSS are one-of-a-kind products: the number of ships in a series is
ranging 1–20, normally around 6–12. The ships in a new series are typically of the same
type as previously build ships (e.g. container vessels or double hulled VLCC’s) but with
some modifications—the ships designed typically gets larger and larger. I.e. an evolutionary
approach is made towards the design and manufacturing process—new designs are only done
within the range of well-known ship designs. The ships build are very complex, typically
involving over 100.000 individual identified parts. The products are very costly (approximate
100 million US$) and the margins are very low, which makes the risks high.
35
CHAPTER 4. DESIGN IN 7 DAYS—THE VISION
36
When a ship is to be designed and manufactured at OSS several opportunities regarding
production place and suppliers of parts have to be considered. This involves the decisions to
produce parts of the steel structures at the (partially) owned yards in the Baltic region and the
choice of where to buy e.g. equipment and main engine. Parts of design and manufacturing
are therefore possibly performed by groups separated both physically and organizational.
The above discussion implies that the main force for OSS is Price and Time to Market—
the demand from the customer is fast delivery of custom specific products at a low cost.
Therefore the main target of any change at OSS—whatever this change is in the process,
production technique, IT tools, organization etc.—is:
Shortest possible production1 time at the lowest possible cost
It is informative for the further discussion and analysis to divide the cost (for a single
ship) into some quantities. This division was first made by Kåre Christiansen in his Ph.D.
thesis ([Chr96], page 83–85), and is useful for the analysis because it discriminates between
what is known and what is decided but unknown. The division done in [Chr96] is an adaption
of work done by J. Altenhoff in 1990 regarding life cycle costs (described in [Chr96], page
12–13). The main observation is that although the design phase typically only requires 5–10%
of the total life cycle cost it dictates 70–80% of the cost incurring later in the products life
cycle. Therefore the control of the “dictated” cost is essential—i.e. it is of vital importancy
to know the cost committed by design decisions.
The quantities to discriminate between are:
Cost of Ship: the total cost of the ship.
Incurred life cycle cost: this is the actual cost paid at a given moment during the life
cycle of the ship. It is a function over time. When the ship is delivered to the costumer
the value is the same as the total cost of the ship. This function describes the actual
flow of money from OSS to suppliers, employees, consultants etc.
Ex ante known committed cost: this function over time describes the committed cost
known during the design and production of the ship. It describes the cost that is
committed but not necessarily used, e.g. ordered steel with a later date of payment. It
is important to keep in mind that the curve describes the known committed cost during
the life cycle phases of the ship. In [Chr96] the curve is explained as ...These costs are
measured simultaneously with the engineering work throughout the product life-cycle....
Ex post known committed cost: this function over time describes the total committed
cost at a given moment in time. It will be made up by the ex ante known committed
cost and the cost that is committed but not known to be so. I.e., the curve could first
be completed after the delivery of the ship2 . In [Chr96] the curve is explained as ...The
costs that we later realise were committed at the time when decisions were made. These
costs are measured after the product life-cycle is completed....
1
The production time is included to cover the design and manufacturing phases, i.e. it is the time period
from initial request to delivery
2
Part of the curve might theoretical be drawn at some moment during the process but after the decision
committing the cost.
CHAPTER 4. DESIGN IN 7 DAYS—THE VISION
37
The quantities are illustrated in figure 4.1 where the committed cost, the incurred cost and
the known committed cost are shown. The “life cycle phases” axis is a time axis where the
life cycle period of the ship is divided into the four major phases and ends with the delivery
of the ship. The phases are described in section 6.2.
Figure 4.1: Committed Cost, Incurred Cost, and Known Committed Cost
During the life cycle of the ship decisions are made. It is the making of decisions that
commits costs, e.g. when the decision to use a specific engine is made the price for the engine
will contribute to both the known committed cost curves. When the engine is paid for, the
price will contribute to the incurred cost curve. Some decisions will have influence on the
cost without this being known, often in complicated patterns. E.g.: The engine in the above
example requires a larger engine room that is planned for and the extra space needed is taken
from the space planned for cargo. This implies that some steel structures have to be moved,
i.e. a decision to move steel structure has indirectly been made. The time from the decision
to use the specific engine until the department designing the steel structures are made aware
of this is a state of uncertainty—cost has been committed without directly knowing this.
The “state of uncertainty” is exactly the area between the two committed cost curves. To
summarize, the presence of the Ex ante known committed cost curve represents the fact
that only partial knowledge about the extent of the consequences of a decision exists at the
time the decision is made. For this reason the curve reaches a certain height later than the
curve for Ex post known committed costs. In other words: consequences are discovered while
decisions are implemented.
Based on the above discussion a number of general things can be said about how the
graphs for a ship should look:
Cost of ship: should be as low as possible. This is part of the main target—shortest possible
production time at the lowest possible cost.
CHAPTER 4. DESIGN IN 7 DAYS—THE VISION
38
Time: the life cycle should be as short as possible—i.e. the point where the three curves
meet should be dragged to the left. Again, this is part of the main target—shortest
possible production time at the lowest possible cost.
Incurred life cycle cost: should be dragged to the right. This means fewer resources
bound in the ship and therefore less interest to be paid. Implies that decisions should
be made early for expenses in the future and that the actual decision to spend the cost
(e.g. to buy steel) should be delayed as much as possible.
Ex ante known committed cost: should be dragged to the left and upwards—i.e. toward
the Ex post known cost curve. This means the consequences in terms of cost of decisions
are known earlier—the known committed cost should morrow the actual committed
cost.
Ex post known committed cost: should be dragged to the right. This means that the
number of indirectly and (for a period) unknown committed cost are reduced, or in
other words to understand the consequences of a decision when (or even before) it is
made.
Overall: the objective of D7D is to make the two committed cost curves meet (full knowledge) and finding a suitable placement of the combined curve (flexibility). The reduction in
the gap between the two committed cost curves should also reduce the total cost and the life
cycle time—i.e., the main target. The reduction in the gap is in [Chr96] (page 84) used as a
measurement of the Concurrent Engineering efforts.
At this point it should be clear that a key focus point should be to resolve cross-functional
issues very fast, because this is the only way consequences can be understood when (or even
before) a decision is made. This resolving has to be coordinated—first when the crossfunctional issues are “negotiated” decisions with impact on other engineering tasks should
be committed. This is the essence of the Knowledge Integration definition given in section 3.3 (page 25—Knowledge Integration requires that the execution of engineering tasks
are mutually adapted, co-ordinated and attuned. In [Ped97b] (page 71–72) these problems
are discussed in more detail.
The question of a suitable placement for the combined curve is another point subject to
discussions. Decisions have of course to be committed at some point prior to the implementation of the decision. It would be nice if the committing of a decision could be delayed until
the point of “cash flow”—i.e. that full flexibility is ensured by melting all the three curves to
one curve. This is for several obvious reasons not possible:
• The customer will require precise knowledge of the product prior to the payment of the
product.
• The ordering from suppliers have to be made at some point prior to the production, e.g.
the ordering of the engine is necessary before the engine room is completely designed.
• The physical productions cannot be done instantly but requires a period of time—this
alone will lock decisions before all the costs are spend.
These three items are examples of the general observation that many decisions are build on
top of other more basic decision—i.e. the decisions are in some sense ordered hierarchically
where the most basic decisions have to be committed before the decisions dependent on these.
CHAPTER 4. DESIGN IN 7 DAYS—THE VISION
39
The other extreme would be to commit all the costs more or less instantly or more realistic
as fast as possible. This would most likely not be possible to do if all the committed cost are
to be known—i.e. this approach would most likely make the gap between the two committed
cost curves larger.
The problem is when to commit a certain decision without compromising flexibility. The
problem is discussed in e.g. [Ped97b] (page 19) where the idea of design-by-least-commitment
is referenced. The idea is that the designer should not make arbitrary decisions (assigning
of values to parameters) but leave parameters unspecified until the time where it is strictly
required that a value is assigned. This is of course a fine principle but not usable in praxis—
the tasks of assigning values to parameters in the early phases are exactly the tasks that are
highly recursive, i.e. mutually dependent. This could have the impact that the locally optimal
solution for a single parameter alone would be to wait for the assignments of values to all the
others parameters—then a local optimal solution can be selected. This is also true the other
way around (the mutual dependency). But local optimal solutions might be very far from
a global optimal solution. An optimal global solution is of course not possible to obtain—
the number of parameters are large, the dependencies can not be completely formalized, the
timing requires a fast design etc. In [Chr96] (page 85) it is argued that the commitment of
cross-functional issues/dependencies should happen in an iterative way with small cycles:
...e.g. suggest a product structure and suggest an assembly sequence, evaluate
consequences, “freeze” some of the parameters and suggest a new or modified
product, etc. Evaluations from the first iteration can be used as an input to the
next iteration...
This quote shows that Christiansen also admits that decisions/parameters are somehow ordered, and that basic parameters should be given values before more secondary parameters.
The length and numbers of the cycles are also subject to discussion.
Other possibilities also exists, e.g. moving complete tasks to later phases if it can be assured that the overall deadline still can be fulfilled and without compromising the achieved
knowledge at any point—this subject is further elaborated in chapter 7, especially in section 7.3 on page 80.
The above discussions have so far only been with regard to a single production (one ship).
There might be more complex considerations when a number of productions (several ships)
are manufactured in parallel/pipelined and where some of the ships are very similar (e.g. ships
in the same series). A very simple example of this might be that it may be better to put more
effort (time and money) into a new production if this could pay-off in future productions.
This might be the case if better means for re-using designs were established. This idea is
already accepted (by some) at OSS and some work has been put into this field. An example
of this is that OSS is working on a tool/process support for a more catalogue based design of
the major production blocks. The idea is that these blocks (the so called grand blocks) are
to become more uniform and thereby more re-usable. On a long term the plan is to operate
on the three levels of strategic, tactical and operational design. The catalogue of blocks are
e.g. a part of the tactical design, where both previous built ships and new ideas should be
represented. The design level concept is an integrated part of the vision and is covered again
later in this chapter.
CHAPTER 4. DESIGN IN 7 DAYS—THE VISION
4.2
40
The D7D Vision
The D7D vision is to fulfill the main target—shortest possible production time at the lowest
possible cost—by enhancements in the very early design phases: the project phase and the
design phase [FLHF98]. The vision is to have the necessary tools (production tools, process
and management tools etc.—not necessarily all IT based) to understand consequences before
or while decisions are made and be able to resolve all cross-functional issues within 7 days.
The core of the D7D vision is described in a working paper written by Jan Tuxen from
OSS. Many of the central ideas in the vision are invented by Claus Risager from OSS, but have
not yet been described by him in written form—nevertheless he is a central person regarding
the work done at OSS on matters of knowledge integration and knowledge modelling. Some
quotations from [Tux96] are presented here to serve as a basis for further discussions:
Design in 7 Days is a vision for the future way of designing highly complex, one-off
products. In 7 days, all major viewpoints in the design process shall be known,
including their consequences and mutual influences. All major aspects shall be
known in sufficient detail to make the decisions that determine all life cycle phases
for the product. This includes full knowledge about committed cost, timing and
environmental impacts.
The vision does not imply that all design activities are to be completed within 7
days, but that all cross-functional issues are resolved to a level enabling all functions to complete their work in parallel without committing further costs.
Design in 7 Days is a systematic approach to achieving the ultimate goal of Concurrent Engineering: Minimize the cost (in every interpretation of the term ’cost’)
of a product by providing full knowledge of the consequences of major decisions
that are yet to be made.
This vision is very radical—the required reduction in time and the imposed level of
achieved knowledge before and during the commitment of decision are magnitudes away
from the current standard. It is most likely that the vision only can be fulfilled in small steps
and it might not be possible to fulfill it at all. The vision is nevertheless visionary and useful
as an ultimate goal for the development of tools and process enhancement.
In the rest of this section different aspects of the vision are discussed further.
4.2.1
Key Points
To make the discussion more operational some key points from the above quote [Tux96] are
discussed:
Highly Complex Products: the products that are manufactured are, as discussed in section 4.1, very complex and costly. In [Tux96] a complex products is defined as consisting
of at least 100.000 individual identified and designed components. No single person can
have a complete overview of such a product. This implies that there is a strong need
for tools to support co-operation, e.g. the resolving of dependencies and component
structuring to higher level components.
CHAPTER 4. DESIGN IN 7 DAYS—THE VISION
41
One-of-a-kind Products: unique designs and production plans are made for each product,
and products are made in very small series, e.g. 1–20. This implies that a major part
of the resources are bound in the product and production preparation phase.
Major Viewpoints: the vision is not to make a complete design of a product in 7 days,
but to know with certainty that the company can build the product within time and
to know the cost of building the product with a certain precision.
Consequences and Mutual Influence: the major viewpoints of a complex product are
not single and isolated but are interconnected in a complicated pattern. If the vision
is to be fulfilled a major consideration has to be how to visualize this in such a way
that the consequences of decisions can be analyzed and that mutual dependencies can
be resolved.
The problem of effective manufacturing of customized products is in [Ped97b] coined as
mass customization instead of mass production. Mass production has proved its worth in this
century with regard to reducing the manufacturing costs of non-customized products. Can
the techniques of mass production be adapted to cover individually customized products?
In [Chr96] (page 81) the concept of Concurrent Engineering is visualized by the Concurrent
Engineering Window (also described in section 3.2) where customers sees individual customized products and the engineers sees identical products—i.e. Concurrent Engineering is
in [Chr96] seen as the adaption of mass production techniques to one-of-a-kind products.
This can only be done by a process that supports these techniques. IT can only be a
tool in this process, not the solution. This is documented in e.g. [Chr96] and also addressed
in [Tux96]:
Design in 7 Days will require new methodologies in organizing our work within
and between companies, it will require new architectures for our IT systems, but
it will also need to take into account the wealth of legacy systems (particularly
CIM) already in use, establishing and controlling the new way in which these
systems will be used.
OSS has already done much work in adapting mass production techniques in the latter
part of the process. For example a major part of the welding is done by robots controlled by
programs that are made automatically from the CAD-Model. But the D7D vision is to fulfill
the target of lowering the costs and reducing the time by enhancing the overall process by
improvements in the very early design phase. This is radical different than the above example
because the example illustrates a functional oriented process where drawings are transformed
into programs in an one-to-one manner. The very early design phase is characterized by a
very iterative process with many creative tasks—a different way of enhancing and supporting
this phase has to be found.
CHAPTER 4. DESIGN IN 7 DAYS—THE VISION
4.2.2
42
Design Space and Design Levels
An important part of the vision is the distinction between the three design levels as described
in section 3.6. This is in [Tux96] described together with the use of models and agents (here
together coined as design space) in the following way:
Design in 7 Days will be based on a clear distinction between tactical level design
and operational level design. (On the tactical level, domain experts in design
and production engineering will formulate their knowledge in a company “bereitschaft”3 .) The modeling framework will be based on an integral set of product,
facilities and methods models controlled by a set of agents acting on behalf of and
interacting with domain experts.
This quote is already addressing a conceptual architecture and organizational changes:
domain experts should use time to formulate their knowledge into some sort of knowledge
base where it can be re-used. A number of points from the quote have to be discussed:
• The key resource is the domain experts. It is by OSS considered vital that they are
in scope and doing the actual work on formulating their knowledge. This implies that
(new) tools should be tailored to this target group. It is also important that the domain
experts stay as domain experts, i.e. there should not be “tool experts” acting on behalf
of (other) domain experts.
• Forcing domain experts to do tactical design most likely requires a shift in the management and organization because resources (time) have to be devoted to do the actual
tactical design, e.g. to formulate block definitions of “fictive” productions. This is a
common problem whenever re-use is to be implemented in companies—the required
time to make products re-usable and to develop new components independent of a
particular order has to be assigned in order for this strategy to work.
• A meta-model is imposed. The modeling framework—the knowledge base—is described
as being based on an integral set of product, facilities and methods models4 . This
requires that these models have to be described in a suitable way. For example the
production facilities has to be described and modeled in a way that domain experts can
change and/or extend the description. This requires a high degree of flexibility. Also,
tools have to be able to access this framework in a for domain experts suitable way.
Traditional management and organization typical only addresses the operational level of
design. The operational level is characterized by being the task of fulfilling a specific costumer
request or order. Re-use of old designs and development of re-usable designs not bound to a
specific production (kind of “fictive” productions) can only be done if the organization of the
work allows the workers to enhance their solutions to be re-usable. This typically means that
resources must be allocated to do this, mostly in form of time but also in form of guidelines
or equal of how to make the design re-usable. I.e., the process of design and production must
include more generic activities that are not bound to a specific production. The conceptual
way of describing this is to divide the process into the three distinct design levels—here the
description is quoted from [Tux96]:
3
4
Preparedness
A division original proposed by Claus Risager
CHAPTER 4. DESIGN IN 7 DAYS—THE VISION
43
Strategic Level: On this level, decisions are made as to which kinds of products to build,
which production facilities and methods to develop and which kinds of virtual enterprises to form.
Tactical Level: On the tactical level, models are developed and maintained for the products, facilities and manufacturing methods decided on the strategic level. The models
are generic in the sense that they describe families of products by means of design
and production engineering objects, but specific with respect to present and future
manufacturing facilities and methods.
Operational Level: The operational level design is to be kicked-off by customer requests
or orders. The operational level is to instantiate specific designs based on the models
developed on the tactical level. The term Design in 7 Days refers to the initial phase of
design at this level where all significant decisions are to be made before detailed design
and production engineering are carried out in parallel.
In the D7D vision the main target of improvements is the tactical level but aimed at the
operational phase. The operational phase is thought of as a being split in two [Tux96]:
1. The decision phase (which is the phase that the Design in 7 Days term refers to)
where key domain experts5 —representing each of the functional viewpoints—forms a
group that is responsible for the transformation of a customer request into a virtual
instantiation of the product including production plans, schedule and the estimated
costs associated with the complete manufacturing. An integrated set of tools are to be
used in this phase. The tools should allow the domain experts to swiftly approximate
the consequences of their decision, especially the of vital importancy consequences of
decisions crossing functional boundaries—i.e. consequences from one expert domain into
the other. The tools should provide insight in each others areas and thereby allow the
influence from one domain to the other. The phase will end when all viewpoints and
consequences are known and an optimal compromise has been agreed upon.
2. A phase where design and production preparation happens in parallel. All major consequences will be known in this phase—which is not the case currently. The mutual
consequences are known and therefore no further costs are committed in other functional domains which gives considerable room for rationalizations in all functions. It
might end with a computer controlled product and manufacturing specification. This
phase is still in the far reaching corner of the D7D project.
Overall the shift to such a design strategy will require a shift in the organization: fewer
designers are needed on the operational level and more designers are needed to develop
and maintain the tactical “bereitschaft”—i.e. a shift has to be made from engineering to
engineering-of-engineering. The multi functional approach the the early design phase on the
operational level will require intense involvement from functions only loosely coupled today.
5
In the case of a shipyard consisting of naval architects, structural engineers, production engineers, automation experts, production schedulers etc.
CHAPTER 4. DESIGN IN 7 DAYS—THE VISION
4.3
44
Conclusion Regarding the D7D Vision
In this chapter the Design in 7 Days vision has been described and analyzed from an overall
perspective. D7D is a radical vision for the future way of designing one-of-a-kind products.
Although the vision has emerged at OSS it is adaptable to a number of similar industries
where some key characteristics are present:
• Highly complex products are manufactured
• The products are custom specific adaption of a general kind
• Design time is lead time
The main target for any change at OSS should always be kept in mind:
Shortest possible production time at the lowest possible cost
Concurrent Engineering (CE) is seen as the answer to the problem of reducing the time and
enhancing the estimation of the costs during all the life-cycle phases of a product—the D7D
vision can be seen as the ultimate goal of Concurrent Engineering (CE):
• A possible measurement of the CE efforts is in [Chr96] argumented to be to measure
the reduction in the gap between the known committed costs and actual committed
costs.
In the D7D vision the required reduction is as close to total as possible.
• CE is striving for mutual dependencies to be resolved using cross-functional teams, but
only with the overall goal of a reduction of the lead-time.
In the D7D vision the mutual dependencies are to be resolved within 7 days.
• CE is striving for parallel execution of the all preparational phases covering the main
functional domains. The execution should involve cross-functional teams in iterative
an iterative process:
In the D7D vision the tasks in the main functional domains should happen
independently and completely in parallel—all the cross functional issues are
resolved at this point. The far reaching corner of the vision is that this
phase is a computer controlled product and manufacturing preparation.
The fulfillment of the vision is to be obtained by Engineering-of-Engineering efforts: a
shift is required in the way work is performed. Domain experts are to model their knowledge
in generic product, facility and method models. These models are the core of the tactical
“bereitschaft”—developed and maintained as part of the work performed on the tactical
level. On the operational level the models are to be instantiated to a specific product with
complete manufacturing plans. This will require a number of integrated systems by which
the information in the models is used to outline the product and manufacturing preparation
by a group of domain experts. The outline is to be completed within 7 days with all major
viewpoints covered and cross-functional issues resolved in enough detail for the rest of the
design and manufacturing preparation tasks to proceed in parallel without committing any
further cross-domain costs.
Chapter 5
Departments and IT Tools at OSS
This chapter analyzes the organization at OSS and the used IT tools. This is necessary
in order to understand the design process in use at OSS. The first section in this chapter
will give an overview of OSS, that is, a description of the organizational structure, a list of
the departments and their main responsibilities. The second section will give a descriptive
list of some of the IT tools used. This section is included for later reference, especially for
chapter 6, and therefore much of the information regarding the responsibilities of the various
departments will first be described in that chapter.
5.1
Main Areas and Departments
OSS is a large shipyard with approximate 3000 employees. The main part of the employees
are working in the production areas (workshops)—the production halls, the dock, in pipe
workshops etc. Approximate 300 people are working with design and detailed design, i.e.
with product preparation.
OSS is divided into a number of main areas and departments that again are divided into a
number of sub departments. For the purpose of later reference (especially in the section about
the design process, chapter 6) the departments of interest to D7D will be listed and briefly
be described in this section. For each of the main areas the departments and subdepartments
of interest are shown in a table together with their department code and the number of
people working in that department1 . This number is only the salaried (white collar) workers2
involved with planning, design etc., and not the blue collar workers. The indention level
shows how a sub department is related to a main department—this can also be read from
the department code. All departments involved in the production preparation are shown in
full detail, that is PTA (manufacturing preparation) and Design/Detailed Design (product
preparation).
5.1.1
Planning, Development and IT
The Planning and IT Development area consists of three departments: Planning, IT and
Automation. The Planning department makes the overall planning and supervises all the
1
According to [OSS98], the department list of January 1998. Note, that the total number may exceed the
sum of the other numbers, because not all sub departments are shown in the tables.
2
In Danish called funktionærer
45
CHAPTER 5. DEPARTMENTS AND IT TOOLS AT OSS
46
decentralized detailed planning made (see section 6.1). The IT department is a development
unit, and has been/is involved in a number of research projects (see section 2.2 and chapter 3).
Some people from this department are physically placed in other departments working on
specific projects. The Automation department is manly involved in developing control systems for the industrial robots in use at OSS. This department has also done research projects
regarding e.g. line detection algorithms.
Dept.
Code
Department
01.00
01.50
01.60
01.70
Planning, Development and IT
Planning
IT Development
Automation
Number of
persons
In Dept. Total
1
77
3
24
49
Table 5.1: Organization Overview—Planning, Development and IT
5.1.2
Production
The production departments are those departments that are directly involved in the production, e.g. detailed planning of painting. Some of the suppliers are also a part of the production
area, e.g. the two shipyards in Lithuania and Estonia. The people working here are not shown
the table 5.2. These departments are not especially important in the main part of the D7D
vision and will not be considered in detail in this Thesis.
An exception to this is the Production Engineering (PTA3 ) department. Important parts
of the production planning is done by this department, and PTA is involved in all the phases
of design, detailed design and production. PTA has major influence in the way the design is
split into produceable units. In other words, it is the PTA department that makes the manufacturing preparation, and this has major influence on the design (the product preparation).
The most important tasks done by PTA is the contribution of knowledge regarding the
production facilities to the Detailed Design Area (40.00) and to accumulate new knowledge
from the manufacturing of new series os ships. The tasks done by PTA can be divided into
5 categories [Chr94a]:
1.
2.
3.
4.
5.
Optimization of the product to match the manufacturing facilities
Establishing of manufacturing methods
Planning and calculation of work hours in the production
Elaboration of technical specifications
Preparing of work hour agreements
The work done by PTA will be described in more detail in section 6.2
3
The department is in Danish called Produktmodning/Produktionsteknisk Afdeling, which can be translated
to Product Maturing/Technical Production. The department is organizational correctly placed in the Design/
Detailed Design Area (40.00) but was formerly placed in the Production Area (10.00) which the department
number (18.00) also indicates. This little historical problem was first discovered late in the process of writing
and therefore the PTA department is in this Thesis described as belonging to the Production Area.
CHAPTER 5. DEPARTMENTS AND IT TOOLS AT OSS
Dept.
Code
Department
10.00
11.00
12.00
13.00
14.00
16.00
18.00
18.01
18.02
18.03
18.10
18.10
18.10
18.20
18.30
18.30
18.31
Production
Production Halls
Dock and Painting Hall
”1300”
Deck House, Engine Room, Workshops
Compression, Pipes
Production Maturing/Technical Production (PTA)
Welding Technic/Administration
Welding Lab
Scaffolding
Technical Instructions
Lifting/Sections/Investments/Supplies
Q–Specification
Steel Maturing
Equipment Maturing
Maturing/B–Plans
Painting
47
Number of
persons
In Dept. Total
275
3
82
2
82
47
2
7
2
23
3
24
1
1
1
2
3
2
5
1
2
3
Table 5.2: Organization Overview—Production
5.1.3
Design and Detailed Design
The Detailed Design4 area (40.00) covers a number of departments involved in product preparation, including both design and detailed design. This area is in number of employees the
largest at the yard with regard to preparation, see table 5.3. The most important responsibility of the Detailed Design area is to specify the ship and make a breakdown of it into
components. Three major viewpoints are always present as guidelines for this area:
• A functional viewpoint—what are the main characteristics of the structure of the ship
and its systems.
• A component viewpoint—what components are used to build the structure and systems
• A manufacturing viewpoint—what considerations regarding the manufacturing facilities
must be included in the design considerations.
The last viewpoint is special. A part of the production preparation is placed decentralized
in the sub departments of this main area, but with PTA as the superior and coordinating
instance.
This main area is divided into a number of sub departments, where the most important
are:
• Ship Design (41.00). This department is responsible for making the initial design of a
new ship. The most important activities for this department takes place in the first
4
Translation note: In Danish this main area is called Konstruktion which is best translated with Detailed
Design. Nevertheless it is important to know that this area (40.00) covers both Design and Detailed Design.
5
This is actually an independent company working for OSS. The number is not accumulated in the total
number
CHAPTER 5. DEPARTMENTS AND IT TOOLS AT OSS
Dept.
Code
40.00
40.03
40.04
40.20
41.00
41.10
41.11
42.00
42.11
42.12
42.14
44.00
44.10
44.10
44.20
45.00
45.01
45.10
45.11
45.12
45.13
45.15
45.16
45.17
45.20
Department
Detailed Design
Dyeline Print
Planning/Standards
CAD Development
Ship Design
Design, General Arrangement, Lines
Noise and Vibrations
Electrics and Automatics
Electrics/Communications–Ships
Automatics–Ships
Electric Installations–Production
Engine Design and Detailed Design
Machinery
Diagrams
Machine Construction
EDB–CAD
Arrangement/Detail Drawings
Pipe Plans
Design/Detailed Design, Hull/Deck House
Hicadec Hull System
Design/Detailed Design—Steel
Astern peek and Engine room
Fore peek and Cargo part
Plating
Part Structure, Deckhouse
Supply Management/TPF
Kneefactory
Robot Programming
Calculation
Detailed Design–Equipment
IPSOS/Partlist/Planning
CAD Systems/Fireequipmen
Hydrolics
Pipes in Tanks
Deck Equipment/Engineer Paths
Ship Equipment
48
Number of
persons
In Dept. Total
4
165
3
3
5
2
9
5
2
2
17
8
7
245
2
36
6
3
13
1
8
3
2
88
10
9
12
14
3
2
6
2
3
2
12
1
3
1
1
2
3
Table 5.3: Organization Overview—Design and Detailed Design
part of the design process. The most important deliveries are the General Arrangement
and a fully faired hull (a hull is said to be fully faired when the surface is completely
specified, see section 6.2.2). The output from this department is needed in many of the
other departments, e.g. Engine Design and Detailed Design (44.00), Design/Detailed
Design, Hull/Deck House (45.00) and also by the classification societies.
• Engine Design and Detailed Design (44.00). The main responsibilities of this department are the engine and equipment for the engine room. This assignment requires
that the department is in close contact to the suppliers (OSS does not produce this
CHAPTER 5. DEPARTMENTS AND IT TOOLS AT OSS
49
equipment by itself and therefore has to choose among a number of suppliers). The
department has to gather prices among the suppliers and evaluate these with regard
to technical as well as economical issues. Manuals for the equipment also has to be
gathered for later use. This cooperation with suppliers also results in that the department participates in the specification of equipment manufactured by suppliers. The
department is involved in all the life cycle phases of the ship and much of the work is
to check that requirements are met. Examples of this is quality checking at delivery
and testing when the equipment has been installed.
• Design/Detailed Design, Hull/Deck House (45.00). This department is responsible for
the steel design and detailed design. The department is in close contact with PTA. The
department is the largest in this area, which should be no surprise when reminding that
OSS is manufacturing most of the steel elements by itself. The department is divided
into three main groups:
– Astern peek and Engine room
– Fore peek and Cargo part
– Part Structure, Deckhouse
In each of these groups both design and detailed design is done. The people doing
these tasks are physically placed side by side and are working together. The difference
between the design and detailed design is, that the people doing design often have
a theoretical background (e.g. as Ship Engineers) whereas the people doing detailed
design often have a practical background (e.g. as Ship Constructors).
5.2
IT Tools
A large number of IT tools are in use at OSS. They are a very important part of the organization, and serves a broad number of purposes, ranging from the very general to the highly
specialized tools, e.g. general spreadsheet programs to very domain specific application for
doing calculations regarding ships.
Some of these tools are of interest to the D7D project, and this section gives an overview
of a number of identified tools in use at OSS. The tools are interesting in two ways:
1. First of all, it is necessary for the understanding of the process to know about the use
of the tools.
2. Second, some of the tools could later be subject to interface to or integrate with during
case studies in the D7D/COT project.
The tools are here divided into a number of categories that describes their main purpose.
The list is not intended to be complete but should give an impression of just how broad the
types of the used tools are, and how different the data representation is. The list is intended
to cover the most important tools with regard to the D7D project, some of the tools are
from [Chr94a] and some has come to our knowledge at the initial talk sessions at OSS. An
interesting point should be mentioned here—among the people interviewed at OSS there were
disagreement on exactly which tool was used for some specific purpose, which again implies
two things:
CHAPTER 5. DEPARTMENTS AND IT TOOLS AT OSS
50
• The process is so complicated, that no one person has complete knowledge of it
• Different people use different tools for the same task
5.2.1
Classification
For the purpose of a rough classification the identified and described tools are divided into
three categories. These categories and the corresponding tools are given in the following.
Modeling and Calculation Tools Modeling and calculation tools are very important,
especially in the early phases. They are used to enter models of the ship to build at various
detailing and the models are used for calculations regarding strength, speed, stability etc.
Some of these tools are commercial products, e.g. NAPA whereas others are experimental
applications. In this category of tools is also present some calculation tools, that are required
by the classification societies for doing standardized test, e.g. regarding leak stability.
1.
2.
3.
4.
5.
6.
7.
NAPA
NAUTICUS
NISA
PARNASSOS
Rapid
ShipFlow
Tribon
Planning and Management Tools A number of tools at OSS are used for planning and
management. These range general (off-the-shelf) products like ARTEMIS to special in-house
developed products like PROMOS. This list includes those tools, that act as “data-vehicles”
for other tools, see the detailed description of the tools in section 5.2.2
1.
2.
3.
4.
5.
6.
7.
8.
ARTEMIS
DPS
IPSOS
MAPSOS
PMS
PrideOS
PROMOS
PTModeler
Drawing, Layout and CAD Tools Drawings and diagrams, both electronic and physical,
play an important role at OSS. They range a number of different types, from the early line
drawings of the hull to detailed drawings showing the placement of pipes in the ship. At OSS
different tools are used for those purposes, and they are used as design tools (CAD), general
drawing tools and tools for doing logical layout of equipment.
1. GRADE-G
CHAPTER 5. DEPARTMENTS AND IT TOOLS AT OSS
2.
3.
4.
5.
51
Hicadec-H
Hicadec-P
Microstation
Pipestar
5.2.2
Description of the IT Tools
This section gives a short overview of the above listed tools. This description serves as a
reference to the tools, to the use of them6 and partly how the data flow is between the tools.
ARTEMIS is a planning tool used for making A-plans. Artemis is used in department
01.50, the Planning Department.
DPS (Decentral Planning System) is a planning tool used to make building plans/programs,
B-plans and C-plans. It uses input from both PMS and ARTEMIS together with
activities (e.g. a welding line number with data about type and amount of work) to
produce the plans. DPS is used by department 18.00, PTA.
GRADE-G is a general drawing tool. It is e.g. used to place components (fire alarms,
machinery, electrical installations etc.) in the deck house. GRADE-G is also used to
draw the General Arrangement. The use of GRADE-G is currently being out-phased
by Microstation, because it is difficult to share data with other system with GRADE-G.
GRADE-G is very general and is used where a general drawing tool is needed. The
tool is made by Hitachi Zosen Systems and is a prior system to Hicadec-H. GRADE-G
is not a 3D system, drawings can only be made in 2D.
Hicadec-H (Hitachi Zosen Systems 3D CAD System for steel design) is an advanced CAD
system. Hicadec-H is vital in the detailed design of the steel elements and for almost
all drawings of these. It is an old program, that has its own internal database to store
the elements of a diagram, and its own way of introducing data into it. This is done
by a pointing device on a large table with predefined geometrical elements. The input
is then translated into a sort of macro-language which generates the actual diagrams.
This makes it very difficult to integrate/interface Hicadec-H with other systems. OSS
is currently involved in the development of a next generation CAD tool to replace
a number of the currently used systems, including Hicadec-H. Hicadec-H is used in
all departments starting with department code 45—all the departments working with
design and detailed design of the steel elements. It is also used in department 18.00,
PTA. At OSS Hicadec-H is run on NT-stations.
Hicadec-P (Hitachi Zosen Systems 3D CAD System for pipe design) is an advanced CAD
system mainly used for drawing the equipment plans of e.g. pipes. Hicadec-P has two
parts: Flow and Layout. Hicadec-P Flow is for diagrams and Hicadec-P Layout is
used for doing the physical layout. The drawings are checked for consistency with
the database in Pipestar. Even though Hicadec-H and Hicadec-P are produced by
the same company the two CAD systems are very different They have their own data
representation and cannot share data. Hicadec-P is used in department 44.00, Design
and detailed design of engine.
6
Some of the used terms in this description (e.g. “A-plans”) are first explained in chapter 6
CHAPTER 5. DEPARTMENTS AND IT TOOLS AT OSS
52
IPSOS is a system for handling part-lists. It is a general tool in the equipment and production departments, and is also used in the workshops, e.g. in the pipe workshop. IPSOS
can get input from Hicadec-P.
MAPSOS is used to generate production plans and instructions for machines (NC code).
The input comes from IPSOS. MAPSOS is, like IPSOS, used in the equipment and
production departments and also in the workshops.
Microstation is a general drawing tool like GRADE-G. It is used to place components in
the deck house. Microstation is also used to make the General Arrangement and to
make the class drawings. It is intended as the replacement for GRADE-G and it is
therefore also used where a general drawing tool is needed.
NAPA is one of the tools that are used very intensely in the very early phases. NAPA
is used to enter the lines of the hull. The tool is divided into 7 modules: Geometry,
Hydrostatics, Capacity, Loading & Stability, Hydrodynamics, Weight Calculations and
Administration. It is not necessary to use all the modules, and in fact, not all modules
are in use at OSS. A ship is introduced in NAPA by a specification of its geometry. This
specification is hierarchical—first points and angels are defined, then curves, surfaces,
rooms and finally the arrangement. This model of the ship is then used for various
calculations:
• Volume analysis, e.g. the load capacity
• Stability analysis, e.g. leakage calculation for different loads
• Capacity
NAPA could be used as far as for the fairing of the hull, but at OSS NAPA is not used
for this process. Also, NAPA is at OSS not used for power prediction nor is it used
for making the General Arrangement. NAPA is used by the Ship Design Department
(41.00) and is run on UNIX-stations. Data is introduced by means of a command
prompt and the tool is a purely text based system, where the model of the ship can be
specified and “questioned”. The geometry model can be exported in various ways, e.g.
the lines (also called master curves) can be exported and used by other systems. This
is exploited at OSS.
NAUTICUS is a software system by “Det Norske Veritas”. NAUTICUS is used for performing strength calculations. NAUTICUS can input the line representation used by
NAPA to store the geometry model.
NISA is an American system used for structural analysis for the classification process. Data
is entered manually. NISA could get data from NAUTICUS, but information regarding
joins would be lost. NISA is used by the group in department 45.00, Design and Detailed
Design of the Hull and Deck House performing the advanced calculations regarding the
strength of the steel structures. Also used in department 41.11, Noise and Vibrations.
PARNASSOS is used to make CFD computations. This application is currently only used
for experimental projects in department 41.00, Ship Design.
Pipestar is a database system with some drawing tools attached to it. It is used to make
the logical layout of pipes and equipment, which is done in department 44.00, Engine
Design/Detailed Design.
CHAPTER 5. DEPARTMENTS AND IT TOOLS AT OSS
53
PMS (Production Management System) is a database system describing a large number of
information regarding the production of a ship. Examples are: welding data, ordering
specifications, painting data, time planning etc. (in short: steel BoM: Bill of Material).
The data is stored in a traditional relational database system (Ingress). PMS is used
for all the detailed planning and ordering. The input to PMS comes as a result of
computations done with the data in the PROMOS system. PMS is a vital system to
OSS and is used generally all over the yard. A lot of other systems are dependent on
PMS, and the full extent of the use of the system is not even known at OSS.
PrideOS (Preliminary Design System for Odense Shipyard) is a project, that glues PROMOS, NAUTICUS and Microstation together. PrideOS was developed as part of the
D7D project and is used twofold7 :
• To act as a data vehicle for Microstation
• To introduce data into PROMOS at a very early stage in the design process. This
is done to make calculation regarding resources before the model is entered in
Hicadec-H (see PROMOS). The representation in NAUTICUS is a strength based
model, so a conversion takes place to the product based model used in PROMOS.
PROMOS (PROduct MOdel system at Odense Steel Shipyard) is a general information
system. PROMOS imports steel structure from Hicadec-H and stores it in an Object
Oriented database (Itasca is used). The database is organized according to the assembly
network. Applications under the PROMOS system are used to e.g. compute resources
needed for scaffolding and compute the number of working hours needed to build the
ship or parts of it. PROMOS is also used to generate the assembly network. PROMOS
is a general tool, or more precisely, PROMOS is a core database system and a number
of applications attached to it. PROMOS is used by many departments.
PTModeler is used to make plans and drawings for scaffolding. This task is done by
department 18.00, PTA.
Rapid is used for CFD computations. The program is currently only used for research
projects in department 41.00, Ship Design.
ShipFlow is used for CFD computations. ShipFlow computes wave resistance and pressure
distribution. As for the use of PARNASSOS and Rapid, ShipFlow is only used for
research projects. It is used in department 41.00, Ship Design.
Tribon is suit of programs used for fairing the hull and converting the representation into
a format that can be used as input to Hicadec-H. This is a hard task because of the
difficulties with introducing data into Hicadec-H. The Tribon program suit consists of
a number of applications, where some are run on UNIX-stations and some are run on
NT-stations. As described above, the initial design tools (e.g. NAPA) are run on UNIXstations and the detailed design tools (most notably Hicadec-H) is run on NT-stations.
The most important parts of the Tribon program suit are:
7
PrideOS is part of the Claus Risager’s Ph.D. project. At the time of writing no documentation of the
PrideOS project were obtainable.
CHAPTER 5. DEPARTMENTS AND IT TOOLS AT OSS
54
B-LINES is a tool for fairing the hull. The master curves from NAPA are introduced
into the program and the fairing is done. B-LINES is used in department 41.10,
Design, General Arrangement and Lines.
BL2LIF is an application for converting the representation in B-Lines to a “line”
format suitable for Hicadec-H. BL2LIF is used in the early phases before the
fairing is complete to get a rough model of the hull into Hicadec-H as early as
possible. Thereby the steel design can begin with use of Hicadec-H before the
exact shape of the hull is known.
Surface is also an application for converting the representation in B-Lines into a format suitable as input to Hicadec-H. Surface is used when the hull is fully faired
and the output format is different than that from BL2LIF. Surface converts the
representation into a “patch” representation of surfaces. It is used in the Shell
Plating department, 45.12.
5.3
Conclusions Regarding IT Tools and Organization
OSS is a large organization and a lot of different people are involved in the phases of interest
to the D7D project. The organization is structural divided into product preparation and
manufacturing preparation. The Planning, Development and IT area is independent of this,
but is responsible for the overall planning and support for concrete projects and development.
The later is often made by people from either the IT or the Automation department physically
being placed in the department where a project is being carried through.
The IT tools in use at the time of writing are large in number and broad in type. Both
commercial (“of-the-shelf” products) and locally developed products are in use. Many different formats are used for storing data, and the data “travels” through the system of tools
in various ways. The transformation can be seen as a transformation from a rough product
description to a very detailed manufacturing description. An example of the first is the lines
of the hull initially specified by means of NAPA to the automatic generated NC code for
machine control (e.g. the programs for cutting plates automatically and the programs for the
welding robots).
People working at OSS are of course placed somewhere in the organizational structure
and it is important for the participants from DIKU to know about this structure: it helps in
the understanding of their overall responsibilities. When people are being interview at OSS
regarding their work they typically describes a lot of the tasks done by means of the tools they
use and what operations are carried through with help of the tools. It is therefore important
to have knowledge about the tools in use in order to improve communication between the
participants from DIKU and the people being interviewed or engaged in a D7D/COT case
study.
Chapter 6
The Planning and Design Process
at OSS
The D7D vision is mainly a vision for the enhancement and revision of the process for building ships at OSS—therefore the process is important to know about be anyone involved in
the D7D project. The process consists not only of ship design (product preparation)—both
manufacturing preparation and planning are important parts of the overall process. These
items are the subjects for this chapter.
6.1
Planning
The planning at OSS is a very important part of the control means of the management.
The planning ranges from the very long-term planning of new series to very detailed plans
for specific jobs in the workshops. As will be seen in this description of the planning the
philosophy is to control both the product/manufacturing preparation and the production to
a very high degree of detailing. The planning is static—very little space is given to change a
task in duration in order to adapt to the current situation during the process. The information
in this section comes from three sources: the supplementary report [Chr94a] written by Kåre
Christiansen, the Master Thesis [DF97] (page 133–134) and the initials meetings with people
from the planning department.
The planning at OSS involves four levels of plans ranging from the very high-level strategic
plans for the future of the yard to very specific plans for individual jobs:
Building Programs: The planning of new series of ships. The horizon is 3–5 years.
A-Plans: The planning of a new ship in a series. The horizon is 1–4 years.
B-Plans: The planning of activities in the individual departments. The horizon is 2–3
months.
C-Plans: The planning of specific jobs. The horizon is 1–2 weeks.
55
CHAPTER 6. THE PLANNING AND DESIGN PROCESS AT OSS
6.1.1
56
Building Programs and A-Plans
It is the planning department (01.50) that produces the building plans and the A-plans. The
department coordinates the planning on all the other levels of planning.
In the A-plans there are four main deadlines:
1.
2.
3.
4.
Production start
Laying of the keel
Launching
Departure
The planning on the A-level is the main planning for the yard regarding a new ship to be build
(the first ship in a new series). The A-plan considers all the main areas—e.g. detailed design
(see section 5.1). For each of the main areas important parts are planned—e.g. detailed design
of steel. For each part important activities are planned—e.g. element drawing in Hicadec-H.
The plan describes the activity, the start date and deadline, important milestones during
the activity etc. The planning department uses ARTEMIS for this task. Included in the
planning on the A-level are tasks like analysis of resource needs: what people are needed
(qualifications) and how many to match the job ahead. The planning also includes a followup each month where each area planned for is analyzed with respect to the plans made and
plans are eventually changed/revised (not common).
6.1.2
B-Plans
The planning on the B-level is controlled by the A-plan. B-plans are the activity and project
plans for the yard. The B-plans are made in the individual main areas. The most important
role of the B-plans are to secure that the right documentation (often by means of drawings)
is exchanged in time, so that the overall deadlines are met and the planning is fulfilled. The
most important tool for making B-plans is the DPS system. The two departments Detailed
Design and PTA have important planning responsibilities on their own:
• PTA makes the internal planning by itself. PTA is also the department that makes the
planning for all the individual production sections. The internal planning consists of a
B-plan that pinpoints the main tasks for the department itself. The planning for the
production sections are B-plans, or so called building programs for steel and equipment,
e.g. an assembly plan for the dry dock.
• The Detailed Design department (40.00) has a planning section that makes planning
on the B-level (but not the C-plans) for all the departments involved in design and
detailed design.
6.1.3
C-Plans
The C-plans are plans for individual and clearly well-defined tasks in both Detailed Design,
PTA and in the production area (workshops). The B-plans are used for the task of making
C-plans. B-plans are divided into individual activities and thereby an activity structure is
CHAPTER 6. THE PLANNING AND DESIGN PROCESS AT OSS
57
made matching the actual job assignments during the work together with a specification of
deadlines for the activities. PMS and DPS are important tools in the process of making
C-plans.
In the detailed design area the C-plans are made decentralized in the three departments
44.00 (Engine Design and Detailed Design), 45.00 (Design/Detailed Design, Hull/Deck House)
and in 45.20 (Detailed Design–Equipment). As an example the C-plans made in the department 45.00 are done to coordinate the activities to be done on the aft part, cargo section,
forward part and the deck house respectively. The C-plan has to ensure that the right information is exchanged at the right time in each of these areas. When a start date and end date
for an activity has been specified in the C-plan it is very uncommon to change them. Therefore many activities are ahead of schedule and many activities are behind schedule during
the process. Similar to the this, C-plans are made internally in the PTA department.
In the production area the C-plans are made decentralized for each of the following areas: Production Halls (11.00), Dock and Painting Hall (12.00), Deck House/Detailed Design
(1350/1390) and Compression, Pipes (16.00). A detailed example of the production of C-plans
in this main area is described in [Chr94a] page 33–35.
6.1.4
Other Documents
A number of other documents should be known in order to understand the rest of this chapter:
• Product Description: A short (4–5) document describing the initial choices made regarding the main dimensions of the ship.
• Product Specification: A document with the length of about 10–20 pages. It is a forerunner to the Construction Specification. The Product Specification is later extended
to an outline specification.
• Construction Specification1 : A detailed specification of the ship. The specifications
must be kept at delivery. In the specification steel structures and engine are e.g. described.
6.2
The Main Phases
The process of design and manufacturing of ships at OSS is a very complex task. As discussed
in chapter 4 this task currently mostly involves operational design, i.e. a specific instance of
the manufactured product has to be made. But this process is still very complicated and
it is also very variable from ship to ship—the process can e.g. change to meet the deadlines
given by the costumer or by management decisions (e.g. the decision that a new CAD system
must be used for the next series of ships to be build). The classical design spiral is a good
way of picturing this, that is, a great deal of iteration is done, especially in the early phases.
But it would be very difficult to actually “draw” an instance of the design spiral for the
process at OSS, and it would be of no real use. Almost all techniques for describing complex
work processes involves a breakdown of the work into phases and tasks of some sort, but
this has the consequence, that the highly iterative nature of the process does not stand clear.
1
In Danish called Byggespecification. A more descriptive term would be Product Specification, but that
term is already in use with another meaning.
CHAPTER 6. THE PLANNING AND DESIGN PROCESS AT OSS
58
Nevertheless, this breakdown into phases is also done at OSS and is used in the following
walk-through of how a ship is designed at OSS.
As an important part of the planning there are three major milestones. These milestones
ends the three first phases out of four well-defined phases of the ship building process. The
four phases are:
1. Phase 0: The Project Phase. This phase is from the initial enquiry from a potential
customer to the contract is signed.
2. Phase 1: The Design Phase. This phase is from the signing of the contract until
the start of the detailed design. The phase ends with the delivery of a report called
Phase 1 Report.
3. Phase 2: The Detailed Design Phase. This phase starts 4–5 months before the
first steel is transported into the production halls, i.e. the first manufacturing of steel
plates. The phase ends about a month after laying the keel of the vessel.
4. Phase 3: The Production Phase. From production start untill the delivery of the
ship.
The phases are shown in figure 6.1.
Figure 6.1: The Main Phases of Design, Manufacturing and Production
The tasks which make up the actual work to do in the phases are also more or less defined.
The most common way at OSS for describing these tasks are by means of their deliverables,
and the above phases are mostly defined by their result or output:
1.
2.
3.
4.
Contract
Phase 1 Report
Completed plans and drawings
Completed ship
The way the tasks are described currently is mostly by an activity name and the resulting
output, e.g. element drawing in Hicadec-H during a finite period of time, results are finished
diagrams showing some part of the ship from a certain viewpoint, e.g. equipment. The
CHAPTER 6. THE PLANNING AND DESIGN PROCESS AT OSS
59
specific tasks during one of the above phases are therefore mostly identified by a specific
phase having certain requirements regarding the output of the phase, and that a number
of tasks are required for the production of this output. But tasks can be moved from one
phase to another depending on the current situation—most commonly a task is moved to
an earlier phase if the time permits it. Often tasks that strictly belong to a specific phase
are started as soon as possible in an earlier phase. The number of tasks that make up the
above phases is huge—therefore only a number of the actual tasks are known to the author.
Also, the tasks known are more or less important to the D7D project, e.g. caused by the way
the initial meeting were organized (the subjects for the meetings were chosen by the project
participants at OSS).
In the rest of this section the work done in the two first phases will be described in
reasonable detail. The choice of focusing on these two phases are again made with regard to
the overall D7D vision. The last two phases are only described very briefly in this Thesis,
but a good description can be found in [Chr94a].
6.2.1
Phase 0—The Project Phase
The Project Phase starts when a “serious” enquiry from a potential customer is made. It is
the management at OSS that estimates if the enquiry is “serious”, that is if the ship type is
suitable for the yard, the customer can pay the price required for the ship, the production
capacity is idle, no better contract is in sight etc. The purpose of this phase is to make
a contract that gives OSS the order and still pay-off. If OSS chooses to make a bid for
the contract a vast number of factors regarding the manufacturing of the ship have to be
estimated before OSS can give a bid for the price. The overall characteristics of this phase
is that it is highly dynamic, iterative and hectic. The right price and the timing are major
factors resulting in the yard eventually getting the contract for the ship.
The first activities in this phase are to determine the main dimensions of the ship and in
conjunction with this the shape of the hull. The main dimensions naturally have to comply
to the customers initial requirements regarding the main dimensions and use for the ship,
most notable:
• Type of ship, e.g. VLCC, Container Vessel or Bulk Carrier.
• Minimum cargo capacity, e.g. number of TEU or volume of crude oil tanks.
• Special cargo requirements, e.g. that some type of cargo most be placed at certain
locations in the cargo rooms, or that some types of cargo may need to be moved easily
between different locations at sea.
• The minimum volume of the fuel tanks.
• A minimum cruise speed, e.g. 25 knots (typical for container vessels).
• Requirements regarding speed and fuel consumption for certain levels of travel speeds,
e.g. a list of speeds and their corresponding maximum fuel consumption.
• Requirements regarding the deck house, e.g. that it must have space for a certain
number of crew members and extra space for passengers.
• That equipment must be placed where it is easy repairable/replaceable when maintaining the ship.
• That the classification must be done by a customer chosen classification society.
CHAPTER 6. THE PLANNING AND DESIGN PROCESS AT OSS
60
• Other Special requirements, e.g. a maximum width as was the case for the Panamax
series.
The main dimensions also have to comply with requirements regarding the manufacturing
facilities and techniques, e.g.:
• The size of the ship must not exceed the capacity of the dry dock.
• The steel structures must be arranged in a way suitable for the decomposition of the
ship into produceable elements. The decomposition must be possibly in a cost effective
way.
• The construction must be safe for the workers.
The determination of the main parameters and the shape of the hull is done by the Ship
Design Department (41.00). The dimensions that must be decided upon are:
Main Dimensions:
•
•
•
•
•
•
•
Length between perpendiculars, LPP
Beam, B (width of the ship at deck level)
Depth, D
Height, H
Dead Weight
Displacement
Block Coefficient, cB
Shape:
•
•
•
•
Prismatic Coefficient, cP
Waterline Coefficient, cWP
Midship Coefficient, cM
Angle of entrance with water
These parameters are determined manually, when possible based on earlier designs/productions. The parameters are iterated to produce a satisfactory result. The tools at use
at this very early stage are mostly pen and paper and the results are outline drawings. It
should be mentioned that the shape determined is not the exact surface of the hull but only
the above dimensions and the initial lines (the lines are body-plans seen from the end of the
ship and the expanded lines of the hull). The full fairing, which determines the exact surface
of the hull, is first done later in the process.
When time allows it the first use of the program NAPA happens at this point—at the
end of phase 0. In NAPA the lines of the hull can be defined. This is done in a hierarchical
specification of the geometry as explained in section 5.2.2—first points and angels are defined, then curves, surfaces, rooms and finally the arrangement. The geometry model (a line
representation, or the so called master curves) build up in NAPA is used for various purposes:
• Calculation inside NAPA, e.g. volume analysis
CHAPTER 6. THE PLANNING AND DESIGN PROCESS AT OSS
61
• As input to other systems:
– NAUTICUS, where strength calculations are done
– B-LINES (part of the Tribon suite), which is used for the fairing
– Various simulation tools, e.g. ShipFlow, Rapid, PARNASSOS etc.
The coefficients and lines (from NAPA) that describe the shape of the hull are used to
calculate the resistance of the ship in water and an initial power prediction (power of engine
needed for the required cruise speed). This is done in part manually and in part by CFD
simulations and other tools. The later mostly as research projects at this time, but the
subject of CFD simulations is becoming more and more important for OSS as an early design
tool. OSS is involved in a large project regarding this (the CALYPSO project). It is also an
area subject to research independent of the production of individual ships, e.g. the design of
bulbs. In other words, the research projects regarding CFD calculations are already targeting
the tactical design level. The first use of prototype models and towing tank experiments are
sometimes also done at this stage.
The department (41.00) makes an initial General Arrangement (GA) showing the spatial
division of the ship. This is a drawing showing the decks and compartments that makes
up the ship. It also shows the type of these, e.g. engine room, cargo, tanks etc. This
initial GA is needed by the other departments, especially the PTA department and the
department responsible for the equipment of the ship. One of the first deliveries from the
Design Department (41.00) is a so called product description, a document of about 4–5 pages
describing the most important results and decisions of the above considerations. After this, a
product specification is worked out. This is a more detailed description which includes e.g. an
elaboration of the design with regard to the international safety specifications (as specified
by MARPOL and SOLAS) and the classification societies rules for stability and strength.
The product specification is returned to the Sales department and is used as a basis for a
price calculation.
The Engine Design and Detailed Design Department (44.00) also begins its work in
phase 0. As soon as possible the department receives an initial GA and the initial line
drawings from the Design Department (41.00) which combined with the requirements and
demands from the shipping company (the customer) gives the constraints for the decisions
to be made. The most important decision that has to be made is what main engine should
be used. The deliveries from the department in phase 0 is a contribution to the product
specification. In this contribution the main engine is specified together with a list of other
components. Optionally a makers list is included which specifies the suppliers for the components. Based on the initial GA together with the initial line drawings the department
eventually (if timing allows it) starts to place components in the engine room. This is done
to ensure that all the necessary equipment will fit into the engine room. This task has to be
done as early as possibly because the requirements almost always are that the engine room
has to take up as little space as possibly. If the equipment needs more space than initially
designed for, steel structures will have to be moved. If this first is discovered late in the
process it will be very costly.
The Design/Detailed Design, Hull/Deck House Department (45.00) also starts its activities in phase 0, but the major part of their tasks are done in phase 1 and in phase 2. In this
initial phase some calculations regarding the strength of the ship is done based on the initial
output from the Ship Design Department (41.00)—GA, tank plans, Line Drawings etc.
CHAPTER 6. THE PLANNING AND DESIGN PROCESS AT OSS
62
The above described activities are the most important in phase 0 regarding the final
manufactured product. But in order to give a bid for the contract serious considerations
must be done regarding the manufacturing process, i.e. it is already in this phase demanded
that a good idea of how the ship will have to be build is obtained and how many hours of
work it will require—this is the job of the PTA department (18.00). PTA is involved in all
the phases, but most heavily in phase 2 (in [Chr94a] the work hours approximate 1000 hours
in phase 0, approximate 4000 hours in phase 1 and approximate 9000 hours in phase 2 are
reported). In phase 0 PTA receives the first initial class drawings on paper and an iteration
takes place where more and more detailed class drawings are worked out. This is an informal
process, where people from the production are consulted and comments are made on the
drawings. Typical 10 iterations takes place.
The PTA department is also responsible for the division of the ship into produceable units.
These units are denoted Grand Blocks (GB’s), and are the greatest elements constructed on
land to be assembled in the dry dock. Grand Blocks are large steel constructions which are
lifted into the dry dock with help of the so called gantry crane—the largest crane at OSS. A
grand block is a partial finished block of the ship up to 32m × 20m × 12m and with a weight
up to 800 tonnes (the limit for the gantry crane). These steel structures are build at land for
several reasons:
• The assembling of elements in the dry dock is highly serialized (caused by the physical
conditions), whereas the work on land can be scheduled in parallel. This makes the dry
dock a serious bottleneck in the construction line.
• The work on land can mostly be done inside large construction halls independent of the
wether conditions which is not the case for the work in the dry dock.
These conditions makes the construction on land both cheaper and faster. The construction
strategi for the GB’s are, that every possible part inside the block is finished at land. This
means that a GB is a structure consisting of the steel elements with pipes and equipment
installed to the extend possible and with partial painting finished. The GB’s are again
decomposed into smaller blocks in a hierarchical way described by the so-called assembly
network.
PTA begins the work with the above described decomposition in phase 0, but the major
part of this work is done in phase 1. The description of this task will therefore be done in
the next section. But at the end of phase 0 an initial decomposition has been made, i.e. the
GB’s are roughly defined. A part of the planning tasks in PTA is to make an assembly plan
for GB’s in the dry dock. This is a plan showing the sequence in which the GB’s are to be
assembled in the dry dock. This plan is initially made in phase 0 but undergoes a number of
refinements in the first phases.
An interesting point is to be said about this department with regard to D7D—PTA is
very involved in the initial phases of the design but uses almost no (design) tools at all. Also,
the communication between PTA and the Detailed Design departments are mostly done by
paper at this stage in the process. In the last phases (detailed design and production) PTA
uses many tools and systems, especially for planning purposes. These includes DPS, PMS,
PROMOS, IPSOS and MAPSOS.
CHAPTER 6. THE PLANNING AND DESIGN PROCESS AT OSS
6.2.2
63
Phase 1—The Design Phase
In phase 1 a number of activities from phase 0 are finished as the first activities of the Ship
Design Department (41.00):
• The geometry model build up in NAPA is finished. This is needed to do the last
calculation inside NAPA and as an input model for the fairing. The calculations inside
NAPA that are finished in the first part of phase 1 are:
– Volume analysis. On basis of the present line drawings and tank plan a volume
analysis is done. This is a calculation of the volume of the individual compartments
of the ship, e.g. the capacity for cargo, the volume of fuel tanks, the division of
the ship by means of bulkheads etc.
– Stability and Trim analysis. This analysis is done to ensure, that the ship is stable
under different conditions. The center of mass and loads are calculated, leakage
calculations are done, the trim regarding the tanks are calculated. The latter has
to do with waves inside the tanks when these are not fully filled and with how
much ballast should be used under different load conditions.
• The fairing of the hull is done. The master curves defined in NAPA are used as input
to the program suit Tribon. The first part used here is called B-LINES. The work is
done on 10–20 cross sections at a time. Each cross section has to be smoothed and the
derivative is used as an indicator (in principle, the optimal is that each possible curve
defined by a cross section is a so called c2-continuous curve). This work is done in 5–6
iterations. When all the cross sections are smoothed the hull is said to be faired.
The hull form is needed as input to the following design tasks which mostly involves
the use of a CAD system (Hicadec-H). It is therefore important that the shape of the
hull is determined as early as possible. An approach is used to get the initial “rough”
shape as input to Hicadec-H before the fairing is finished. This is done with help of
the part of Tribon called BL2LIF. This program is used to convert the representation
of the hull used in B-LINES to a format suitable as input to Hicadec-H. When the
fairing is finished another part of Tribon is used (Surface) to convert the representation
from B-LINES to a “patch” format. This representation is also suitable as input to
Hicadec-H. When the import of this fully faired hull is done the diagrams and drawings
already made in Hicadec-H are adjusted to fit the final shape.
• The General Arrangement is finished. As explained earlier the GA is a plan over the
division of the ship (compartments, decks, tanks etc.) and the use of these (machinery,
ventilation, cargo etc.). For the last series of ships build at OSS the system called
PrideOS was used as a “data vehicle” in this process.
• The tank plan is finished. This is done in a number of iterations where the plan is coordinated with the Engine Design Department (44.00) and the Steel Design Department
(45.10).
• The light weight of the ship is calculated. The light weight is the sum of the weight of
the steel used to build the hull, the engine and the equipment. The weight of the steel
is calculated with help of an empirical formula known as Wattson’s formula and a yard
specific constant K. The light weight is communicated to others on a number of info
papers.
CHAPTER 6. THE PLANNING AND DESIGN PROCESS AT OSS
64
• The longitudinal strength is calculated. This has to do with torque and displacement
forces.
• Prototype Experiments are done. Model experiments are used to verify the shape of the
hull. The prototype models are build in wood or some other material like fibre glass.
The models are then dragged trough a water basin and the results are compared with
the design demands. Different kinds of hydrodynamic experiments are done: water
resistance, leakage tests, self propulsion tests (to test the propeller type and shape),
sea keeping tests under different wether conditions (the test basins normally have wave
generators), maneuver tests etc. These experiments are costly (approximate 70.000–
80.000 US$) and typically take over a month to do.
The above activities are done in parallel, and the activities are iterated to produce the
final results. For example regarding the use prototype: when a prototype has to be build and
tested this is done by another company, e.g. DMI. This is an expensive and time consuming
process (actually, it is the the timing constraint that is most important to reduce if possibly).
Model experiments require that the shape of the hull is determined to a nearly finished state.
But if the model experiment gives unsatisfactory results regarding some part of the shape,
the shape has to be changed somehow. Iteration also takes place between the line drawing
in NAPA and the fairing done with B-Lines. Other analyses that takes place can also have
influence on the final shape of the hull and the final GA.
The activities are finally documented in a number of papers. The first document is an
outline specification which describes the considerations and decisions made in the work with
the above aspects. The final decisions are documented in construction specifications, both
for the ship part and for the engine/equipment part. The strategi in this phase is that it
must by all means be a cost effective solution and PTA has therefore major influence in this
part of the work.
In this phase the Engine Design and Detailed Design (44.00) department continues the
work from phase 0—that is, the machinery and equipment that is going to be used is ordered
(in cooperation with the purchasing department) from the sub-suppliers. The sub-suppliers
returns drawings and specifications which are used to make the physical and logical layout of
pipes etc. The order in which the components are going to be placed in the ship is decided
upon. This work is very dependent on the sub-suppliers in the sense, that OSS uses them
extensively for the equipment (but handles the steel work “in-house”). The work is also very
dependent on the finished line drawings (especially for the stern part), so that the constraints
for the placement of engine and equipment are precisely known.
In phase 1 the Design/Detailed Design, Hull/Deck House Department (45.00) is responsible for the design of the steel structures inside the hull which divides the ship into compartments and gives it the required strength. This work is based on the output from the
Ship Design Department—the lines of the hull, the GA, tank plans etc. Ideally, the design
of the steel structures should first begin when the work done by the Design Department is
completed because the fully faired hull is needed. Also the work to be done by the PTA
department is ideally needed at this point (the decomposition of the ship into blocks, see
below). But as explained in the description of the fairing task, the preliminary results are
used, and when the fairing is completed the work done is adapted to the final shape of the
hull.
CHAPTER 6. THE PLANNING AND DESIGN PROCESS AT OSS
65
The first part of the steel design is to build up the major structures of the ship. These
are the decks, the shell, longitudinal and transversal bulkheads. This is done by dividing the
ship into 4–7 suitable units. On basis of the block division made by PTA the structure is
outlined. By using the Hicadec-H CAD system a number of sections are defined:
1. Vertical sections—longitudinal bulkheads.
2. Waterline sections—decks.
3. Cross sections.
Profiles are then defined in the longitudinal directions. These are expanded to the whole unit
and are defined between the frames.
The CAD system is used in a way where well-defined bounds between elements constantly
are defined, e.g. this plate is limited by this plate etc. This is also how the system is able to
adapt to a change in the fairing as described—only few points are absolute in placement, the
rest is defined relative to those and with some “rubber” build into the model. This work is
iterated up to 3 times.
The defined blocks are divided into 5–20 elements. An element is the normal unit of work
in Hicadec-H. The element drawing contains all the information regarding lengths, widths,
thicknesses and borders. There is no clear division between phase 1 and phase 2 regarding
the work done by the steel design department. The most clear distinction is who actually
does the task—ship designers makes the initial structures and ship constructors makes the
final detailed design.
The final specification of the breakdown of the ship into grand blocks is done by PTA
(18.00) in the very beginning of this phase (i.e. before and during the start of the above
described tasks done regarding steel design). This process is informally denoted as Fonseca’s2
kitchen table. The process is very complicated and iterative. A constant evaluation of the
steel design on one side and the manufacturing decomposition into grand blocks have to take
place. The problem is that from the viewpoint of manufacturing the GB have to be as large as
possible. This is problematic from the steel design viewpoint because larger GB’s means that
they also become heavier. When the GB’s are made larger/heavier then they also need to
be more strengthened on order to be able to be strong enough to be lifted and thus carrying
their own weight without collapsing. I.e., when the GB’s are made larger the steel structures
inside are made “clumsier”. Therefore the total wight of the ship is increased in comparison
with a ship build completely out of plates and profiles directly in the dry dock. The problem
is therefore to find a suitable balance between the wish to build a ship having a optimal
design and a ship having the cheapest manufacturing costs.
The initial decomposition is done using pen, paper and creativity. The main dimensions
of the ship is known and have to be respected. But many solutions to the problem are
present. The division normally is made in 3–4 levels vertically and 2 levels across horizontally
(a starboard and a portside part). The bottom most blocks are the blocks mostly welldefined—this should be understood as blocks that typically are cut the same places from
series to series, i.e. the parameters defining the blocks can to a good degree be re-used from
previously designs. The blocks in the upper layer of the ship typically are those blocks that
are cut differently from ship to ship, i.e. elements from blocks are “moved” from one block
to another from design to design.
2
The name of the head of the PTA department is Robin Fonseca
CHAPTER 6. THE PLANNING AND DESIGN PROCESS AT OSS
66
An example of this could be the engineer path. This is a path along the deck where a
complete walk around the ship is possible (also when the ship is fully loaded). This path
is used for maintenance on board during travel. The path is full of heavy equipment and
therefore the weight of the construction making up the path is large. The path has to be
placed on top of the shell plating. The shell plating at this height is “thin” (of course it is stong
enough for the ship at sea) and can therefore not carry to much load during construction.
Several possibilities now exits for the placement of this path during construction:
1. It can be attached separately, i.e. the path is cut up in blocks on its own and these are
lifted into the dry dock and attached to the surrounding blocks. This means that a large
portion of extra blocks have to be build and lifted into the dry dock separately—this
increases the manufacturing costs and maybe also the time required for the ship to be
assembled in the dock.
2. It can be a part of the deck-blocks. This increases the weight of these blocks (they are
already among the blocks that have the greatest weight) by a great amount. This is
not always acceptable.
3. It can be made part of the blocks also containing the shell plating. This is also difficult
because the support structures for the shell plating then also would have to carry the
load of the engineer path during construction. This might increase the weight of these
structures considerably.
When the decomposition takes place many parameters are constantly being estimated,
e.g. the weight of a block. This is done by means of a normal spreadsheet program where
the estimated weight is accumulated for a given block. The final block division is drawn on
outlines and the root of the assembly network can now be defined.
Many groups are dependent on the choices made at this stage. The steel designers have
to know how to cut the ship into elements and they have to make calculation of the strength
of the ship on background of a given decomposition and a given initial design for the main
structures of the ship. The people making manufacturing plans need to know what blocks
have to be made in order for the more detailed planning of the production line.
When the grand blocks are finally defined and the specification of these into sections
are made the drawings for the manufacturing of the sections are done. For each section
an isometric drawing is produced with information on placement and connections to other
sections. In parallel with this work the production plans for the steel constructions are
initiated. This is a table showing the building method, production place, etc. for each section.
An initial B-plan for the steel production is also made in this phase, based on the use of
PROMOS, DPS and PMS.
The work is documented in the Phase 1 Report typically including (among other):
•
•
•
•
•
•
Product Description.
Grand Block division.
Layout for deck house (the type of areas and where they are placed).
Layout for cargo part.
Layout for engine part.
Product distribution (what parts are to be build, how the assembly should be made,
where the parts should be build etc.).
CHAPTER 6. THE PLANNING AND DESIGN PROCESS AT OSS
67
• Construction method descriptions.
• Special conditions: use of robots, principal welding techniques, equipment, painting,
scaffolding etc.
6.2.3
Phase 2—The Detailed Design Phase
The main result of this phase is the detailed and complex description of the complete ship
from the point of view of manufacturing. An important part is the assembly network which
precisely describes how the ship is divided into grand blocks, sections, subsections etc. and
finally ending with plates and profiles. A complete specification of all the nesting data,
welding lines, painting areas, etc. is produced. All this is needed to make the final planning
and the programs for the work areas (e.g. NC code for the welding robot). The tools used
here are HICADEC, PROMOS, PMS, DPS and others.
In this phase the Engine Design and Detailed Design Department (44.00) completes the
work from the design phase. This work involves the production of detailed arrangement
specifications, e.g. where components are to be placed and in what order. A major part of
this work is with regard to pipes and the pipelines. The result is a complete list of what pipes
are to be produced. This work is complicated by the fact that there are many constraints.
These are in the form of demands regarding the mounting of the pipes. Also the fact that
much of the equipment have to be placed in the grand blocks before the assembly of the
blocks has some major implications. A pipe typical runs through a number of blocks, but it
has to be split and mounted separately in each block. The final drawings and part-lists are
send to the workshop (department 16.01) where the final job list and the C-plans are made.
The Design/Detailed Design, Hull/Deck House Department completes the breakdown of
the structures of the ship into finer and finer parts. The result of this is the assembly network.
The root of the assembly network is the whole ship. The next level defines the grand blocks.
The grand blocks are those defined by PTA in the design phase. This very detailed description
of the whole ship is done using PROMOS. The results from various calculations in PROMOS
are then stored in PMS and used for planning. The final results are as detailed as description
of the individual welding lines, nesting data for the cutting of steel plates etc.
The PTA department continuous to work on plans for the production in this phase.
The product distribution for steel is completed, showing what to build, where to build it,
techniques to use etc. An analogous product distribution for equipment is made. This plan
is based on the product distribution for steel but is targeted towards the engine (attached
to sections) and towards the systems (attached to areas). The product distributions are
completed about three months before the production starts.
PTA documents this phase in a number of so-called maturing reports which are completed
approximate two weeks before the production begins in the respective area covered by the
individual report. These reports includes among other:
• Section and block division.
• Work-hour tables.
• Production distribution.
Other tasks are done by PTA in this phase, e.g. welding instructions and testing instructions. The specific tasks and their output are not in scope in this Thesis—a good description
of the tasks during this phase can be found in [Chr94a] page 25–30.
CHAPTER 6. THE PLANNING AND DESIGN PROCESS AT OSS
6.2.4
68
Phase 3—The Production Phase
The production of the ship is done using the results of the very detailed work done in the first
phases. Especially Construction Method Description3 and C-plans are needed. The detailed
description of the production phase is outside the scope of this Thesis but the overall process
for the construction of the ship is given in the following:
1. The steel plates and profiles are sailed into a small harbor at OSS and stored outside the
start of the large assembly lines inside the production halls. The plates and profiles are
registered, rolled to ensure an uniform surface, sandblasted and the priming is done.
After this the plates are ready for further manufacturing into either shell plates or
profiles manufactured at the yard.
2. The plates and profiles are cut into the required pieces. These are all registered with
an unique number and a bar-code is printed on them for later reference. The pieces are
welded into profiles, panels or other “basic” elements.
3. Using the detailed plans made the sections are build on suitable assembly lines. This
work is highly automated using welding robots (but it still requires many blue collar
workers).
4. The finished blocks are transported to the painting halls and are partially painted.
Equipment is installed into the blocks to the extend possible.
5. The blocks are welded together to form the Grand Blocks (GB’s). Again equipment is
maybe installed and painting done.
6. The blocks are lifted into the dock and assembled to produce the final ship.
7. When the first GB’s are welded together in the dry dock the engine is brought in place
(the first GB’s to be placed are normally the blocks housing the engine).
8. When the ship can float it is taken from the dry dock to the outfitting quay.
9. While the ship is finished installation of equipment and painting are done in parallel.
This description should give a good idea of how the construction takes place from an overall
viewpoint—many details have been left out.
6.3
Conclusions Regarding Planning and Process
The planning process at OSS is fairly static. The philosophy is that no task is initiated before
it has been planned. This is especially true for the three last phases (phase 0 is somewhat
more loosely planned). In the production area every movement of sections and steel has been
planned with a high degree of detailing. This amount of planning takes up a great deal of
time. On the other hand it might be necessary to ensure the profit of the ship—constant
monitoring of the construction costs are done. But revisions of the planning process at OSS
have been made. It is especially the very detailed planning for the production area that is in
focus. Projects are started to estimate the consequences of a more dynamic (“just in time”)
planning for production hall. This comes from the fact that many of the deadlines in the
halls cannot (and are not) met either due to late delivery from the former group along the
assembly line or due to to early delivery. Therefore much of the planning today uses so-called
3
In Danish: Metode Oplæg
CHAPTER 6. THE PLANNING AND DESIGN PROCESS AT OSS
69
buffers. A number of days are typically inserted between important steps in the assembly
line. A more dynamic scheduling of work might be able to attack this problem—buffers have
great impact on the money bound at any moment in time.
The process of designing and manufacturing a ship is very complicated and complex.
In this chapter the process is described from a certain viewpoint of detailing—a very large
amount of details have been left out, especially for the last two phases. The process is carried
out by approximate 3000 people, so a complete description of the tasks, the work flow and
use of tools would be enormously if possible at all. Nevertheless the description given should
serve as a good basis for understanding what the D7D vision really is about and for the
discussion of possible solutions on the way to the fulfilling of the vision. This is the subject
for the next part of this Thesis.
Part III
Design in 7 Days
The Implications
70
Chapter 7
Implications
Based on the work done so far—the analysis of the results from prior projects, the analysis
of the D7D vision, the analysis of the organization in which the vision is to be implemented
and the analysis of the process that is subject to the change—the central questions of “what”
to build and “how” to build is now subject to analysis.
The fulfillment of the D7D vision will without doubt depend heavily on IT technology—
including new systems, legacy systems, integration of both new and old systems and organizational changes needed to exploit the technological improvements. It might also involve
management problems—the introduction of new systems will require a change in the tasks
to perform and this is a decision to be taken by the management.
These problems are the subjects for this chapter—with the computer science viewpoint.
The viewpoint is made for the simple reason of the competence of the author and the fact
that this work is part of a computer science project in the COT context. The viewpoint
taken will have the impact that some of the problems cannot be answered in a competent
manner, e.g. what management steps should be taken to make organizational changes without
compromising labor union agreements1 . On the other hand a number of interesting subjects
can be discussed based on the analyses done so far—this includes what the impact of the user
profiles are, what development process might be well suited when developing new systems,
and how the systems can be evaluated with regard to the D7D vision.
A number of subjects in this chapter are highly interrelated—this gives some structural
problems concerning the order in which the subjects are treated. The result is that a number
of issues are discussed with relation to more than one of the subjects and thus might seem to
be repetitions—another way of seeing this is that certain issues are discussed with different
viewpoints defined by the subject in focus. But repetitions and forward references are present.
7.1
General Considerations
The subjects of this chapter have a number of general considerations in common. These are
discussed in this section.
1
In Danish: Faglige overenskomster og aftaler
71
CHAPTER 7. IMPLICATIONS
7.1.1
72
Viewpoints on Project Goals
The D7D/COT project has the overall subject of object orientation. In the COT context
research (in a broad sense) is the goal as explained in section 2.1.2. The goals of the participating companies (in this case both DMI and OSS) are solutions to problems and increased
competence in the field of object technology. With this in mind a pragmatic approach to
finding the “mix” of interests has to be taken. This regards e.g. what systems to develop.
It might e.g. be very interesting from a research viewpoint to document design patterns in
existing systems at OSS but this would most likely not be interesting for OSS. It might on
the other hand be very valuable for OSS to be able to transform data from one system to
another but this might not necessary be an interesting research problem.
The above discussion is summarized with the following suggestion regarding the definition
of goals in the context of the D7D/COT project:
Implication 1 All the participants must respect each other goals and strive for the right
combination regarding the (often counteracting) goals.
7.1.2
Legacy Systems
A large number of legacy systems are in use at OSS—here the term ’legacy’ is included to cover
the implementation platforms of systems, e.g. specific database systems and programming
languages. This fact has to be considered when developing new systems for a number of
reasons:
1. It might be necessary to integrate with / interface to legacy systems. This might restrict
the possibilities when deciding upon implementation platform.
2. When deciding upon an implementation platform the problem of maintenance should
be considered: if successfully systems are developed during the D7D/COT these are to
be maintained by OSS after the D7D/COT project is ended. This might restrict the
possibilities regarding the implementation language.
On the other hand it should be remembered that this is a research project. If it seems
very feasible from a research viewpoint to use a specific technology and this technology is
not in use at OSS it might still be considered to use it anyway. A possible way of doing
this in praxis could be to make a pilot project where pros and cons are evaluated. If the
technology is chosen the matter of technology transfer must be considered: how are people
at OSS trained to use the new technology and maintain the developed system—which also is
a COT research subject.
This discussion leads to the following suggestion regarding use of technology (in a broad
sense) in the context of the D7D/COT project:
Implication 2 The right combination of technology must be chosen with regard to legacy
systems, present expertise and future goals. If technological problem arises (clash between
present expertise and future goals) means for solving these must be found, e.g. by training.
CHAPTER 7. IMPLICATIONS
7.1.3
73
Target Group
The target group of new systems at OSS are highly skilled domain experts. These ranges
ship designers, production engineers, ship constructors etc. To a high degree these domain
experts also are skilled IT users. Nevertheless it is important to remember that their key
focus point is the creation of a new ship—the use of IT is a complexity driven necessity.
The problems concerning the use of IT systems (both new and legacy) by this target
group is elaborated in [Chr96]. The conclusions made in this reference together with a
general discussion of the problems is the subject for this section.
In [Tux96] and in [Chr96] the general conceptual architecture of the D7D “solution” is
discussed. The main result is that the engineering work is to be done on (mainly) the two
levels of tactical design and operational design. The architecture prescribes the use of a
threefold model containing information about facilities, products and methods. The information in these models needs to be defined and maintained. This raises the important issue
of who should be in-charge of this work. The problem is more general than just the threefold
model—the whole engineering enterprise needs to be defined. The problem is in [Chr96]
(page 101) described as:
...Who should define the functionality of the engineering enterprise? We need
information technology experts to consider the automability level (technological
possibilities) and we need domain expert to consider the humanizability level,
but who should be responsible for determining the appropriate extent of automation?...
The core of the problem is knowledge extraction: the problem domain in this context is very
company specific, a company specific work process has to be supported. The company specific
process includes local traditions of product design and manufacturing. I.e. company specific
products, facilities and methods have to be defined and the functionality of how to exploit
these models has to be detected.
In [Chr96] the two options are given to the above raised problem:
• Information Technology experts (involving domain experts through interviews).
• Domain experts (qualified to model but aided by information technology experts).
Christiansen is a strong advocate for the second approach which in [Chr96] is called domain
experts as model managers. Two main reasons are given as support for this:
1. It is a necessary approach: the control of knowledge inside an organization is a power
source. Currently engineers are in control of product information inside a company
and IT experts facilitate the knowledge and information processing—engineers request
systems that can process the products they want to work with. If IT experts are
allowed to gain more control of engineering knowledge and information processing they
will gain their power position within the organization on behalf of the domain experts.
This could leed to a situation where the domain experts not volunteerly would give up
their power position and begin to be critical towards the systems needed to support
their work.
CHAPTER 7. IMPLICATIONS
74
2. It is a reasonable approach: motivation is known to be a great factor when a work task
has to be done. The argument is that if this approach has the result of a highly skilled
and motivated engineering work-force the approach is reasonable. If the enhancements
of the design process (in [Chr96] called the implementation of the Engineering of Engineering principle) has the result of shorter lead-time, better quality etc. then it would
be a high motivation factor to be a part of this productivity gain. If the same goals are
obtained without the engineering control resignation could be the result.
The two supporting arguments above are reasonable but if this approach (domain experts
as model managers) is chosen a number of issues must be clarified. First of all a number of
items are “mixed” in the description given in [Chr96], in the following the most important
are given:
1.
2.
3.
4.
5.
The
The
The
The
The
development
development
development
maintenance
maintenance
of
of
of
of
of
ideas in form of IT systems supporting the work process.
knowledge models.
applications to exploit the knowledge models.
knowledge models.
applications to exploit the knowledge models.
For each of these items it must be clarified if domain experts are capable of being in-charge.
In [Chr96] and in [Ped97b] the focus is on modelling the problem domain, that is the
second and fourth item above. It was proved that domain experts were capable of modelling
the problem domain using object oriented techniques to a sufficient level appropriate for
generic models. A number of other projects have addressed the other items but with varying
results. Unfortunately these projects have not been documented in references known to
the author of this Thesis—knowledge about these projects and their results has only been
obtained by discussions with people at OSS2 . I will therefore conclude that more research is
still needed to find the right “mix” of competences when systems are to be developed—this
Thesis is part of this work, and a suggestion of the right “mix” in the D7D/COT context is
given in section 7.2.1.
I will conclude this section with some general observations and the implications hereof
made during the D7D/COT project so far. In the elapsed project period experience has been
established with regard to the cooperation with domain experts. The focus of this project
has so far been with regard to the development of systems to support the work process of
domain experts—i.e. in areas where little documentation exists regarding the involvement
of domain experts. The experience so far suggests a more balanced mix of capabilities and
responsibilities than expressed in [Chr96]. The D7D vision is a still a vision and new ideas
are still needed to be elaborated. The experience obtained so far supports the following
hypothesis: domain experts and IT experts in collaboration constitutes a strong team when
new ideas are to be developed. The domain expert is necessary as a team member because
he has key knowledge about the domain and the general experiences of what is feasible.
The IT expert has key knowledge about more abstract methodologies (e.g. regarding the
structuralization of object hierarchies) and is able to suggest ideas not immediate thought
of by the domain expert. I.e. key knowledge is important but a “fresh” viewpoint can be
2
Especially Claus Risager. A number of these projects will be described in his Ph.D. Thesis which currently
is being written.
CHAPTER 7. IMPLICATIONS
75
very valuable. The possibility of the IT expert being in total control of the development is
considered out of the question for several reasons: it would be a very hard task to develop
ideas and the accept of new systems by the domain experts would be questionable—to name
a few problems.
This discussion leads to the following conclusion of the general work division when new
systems are to be developed. The systems thought of here are especially the applications
needed to fulfill the D7D vision and the context is both the D7D/COT project and the
overall D7D project:
Implication 3 When systems are to be developed it must be a cooperative task involving both
the domain expert(s) and the IT expert(s).
The subject of this section is very important if successfully systems are to be developed,
and the issues are further elaborated in the rest of this chapter where appropriate.
7.1.4
Conclusions Regarding General Considerations
A number of general issues must be considered when defining a concrete project idea in
the context of the D7D/COT project. In this section these issues have been discussed and
suggestions are given on how to tackle the problems. A summary of the conclusions are given
in the following.
The concrete project ideas will have a twofold purpose: helping the participating companies (in this case OSS and DMI) in solving real problems and satisfying the research goals of
(in this case) DIKU. All the participants must therefore respect each other goals and strive
for the right combination regarding the (often counteracting) goals.
The wealth of legacy systems in use at OSS and the general experience regarding systems
and implementation platforms in use should be appreciated when deciding what systems to
develop and by what means the systems should be developed by, e.g. choice of implementation language. On the other hand the research goals must be appreciated which can lead
to decisions not immediate accepted as a good choice by OSS or DMI. Finding the right
combination of technology to use is very important and if problems arise (e.g. regarding use
of technology) means for solving these must be considered, e.g. by training of relevant staff
members (in this case from OSS or DMI).
The control of the systems to-be at OSS is an issue of discussion. Distinction should be
made between controlling the use of the systems (e.g. when models are defined and maintained) and the development of the systems. A very valuable synergic effect could be obtained
if the domain experts and the IT experts are cooperating on both the development and the
maintenance, but with different emphasis of the work division regarding the more detailed
tasks. If success is to be obtained with new systems it should be strived for that the domain
experts (the users) feel that it is their system and model.
7.2
D7D/COT System Development
The development process of systems as part of the D7D/COT project is restricted by a
number of factors ranging man-power issues to domain knowledge. The impact of these
factors on the development process is the subject for this section.
CHAPTER 7. IMPLICATIONS
76
The development process needs to be outlined on beforehand. A number of issues are
relevant to consider and decide upon before actual development is begun:
1. Development Strategy
2. Implementation Platform
7.2.1
Development Strategy
The development of new systems in the context of the D7D/COT project will require the
consideration of a number of issues regarding the development strategy. These issues are
due to the shear facts that the systems to be developed are new and experimental (both
with regard to the goals of the systems and the research context in which they are to be
developed), the developers (most likely the DIKU group) are not trained engineers and that
the development group is small measured in man-power. These issues will be discussed in
this section with the intend to analyze the impact of these with regard to the development
strategy of new systems. The analysis should be regarded as an restriction to the more
general considerations regarding the target group done in section 7.1.3.
When constructing new systems for a particular domain, knowledge about this target
domain is essential—knowledge has to be captured and modelled on a sufficient high level to
be integrated in the new system. Knowledge about the domain is therefore a key resource
needed during the development of new systems. Domain experts are the key resource to
domain knowledge and domain experts are therefore needed in the development process—
either in the analysis phase were requirements are to be specified or as an integrated part of the
whole development period. The systems to be developed in this project are experimental:
a new way of designing ships is to be supported through proof of concept studies in the
context of a research project. This makes the precise requirements of such systems very hard
to specify on beforehand, if possible at all. This implies that flexibility in the development
phase is essential—building the “right” system at the first attempt is most likely not possible.
Based on this the following two hypothesizes/advises are proposed as essential to a successful development of new systems:
Implication 4 Domain experts needs to be an integrated part of the development process.
The basic reasons for this are:
• The systems to be developed will be experimental and only loosely defined on beforehand.
• Requirements are hard to capture by system developers not trained in engineering.
• The domain experts are not trained in formalizing requirements.
Implication 5 The development process must be iterative and step-wise.
The basic reasons for this are:
• The systems are new and experimental, new ideas are constantly emerging while other
ideas are implemented.
CHAPTER 7. IMPLICATIONS
77
• The needs of the domain expert are to a great extend to be “discovered”—both by the
system architect and by the domain expert.
These statements are further encouraged and supported by the results obtained in a
number of references—in the following three of the most important are emphasized:
• In [Chr96] one of the main results is that Knowledge Integration (as part of the Concurrent Engineering efforts) is necessary for the development of a new process for the
design of ships. The development of new systems to support the process enhancements
is a part of the overall development of the ship design process. It therefore seems naturally that the considerations regarding Knowledge Integration are extended to cover
the development of new systems. In [Chr96] it is concluded that cross-functional teams
is a necessary approach to obtain the goals—the first implication above is exactly an
example of a cross-functional team: domain experts and IT experts have to cooperated
closely in order to obtain success.
• In [DF97] a prototype was developed as part of the project. The important conclusion
made regarding this approach (page 156) is:
The developed prototype turned out to be well suited for discussions with
the domain experts regarding the development of a future application. The
use of prototyping has thus enhanced the communication with the users to
uncover their demands and needs.3
This conclusion supports the above discussion about Knowledge Integration.
• The success of the M.A.D. project ([CCD+ 98], part of the COT case 5) is a strong
encouragement to the statements. In this project a number of aspects are very close to
the aspects of the D7D/COT project, here the most important are given:
– The assembled development team had no knowledge about the problem domain.
– Domain knowledge could not be obtained before system development was started
due to time constraints.
– A multi perspective system was to be developed.
– The initial requirements and formal specifications to the system were vague.
– High degree of uncertainty regarding the specifics of the potential application.
– A flexible architecture had to be developed to ease local customization.
Based on the above aspects the development strategy chosen in the M.A.D. project was
an evolutionary prototyping approach with the following characteristics:
– Rapid prototyping: 5 major iterations of analysis-design-implementation were
done. The analysis model was developed during all the iterations. The approach
was radical with no real ’sequence’ of work.
– User collaboration: active involvement of users during the complete period of
development.
– Experimentations: ideas were constantly tested by users reviewing implementations.
3
Translated by Morten Frank from the Danish original.
CHAPTER 7. IMPLICATIONS
78
In [CCD+ 98] a number of important and interesting conclusions are made regarding
the success:
– Practice: focus on the work practice which the application has to support.
– Experimentation: user involvement radical improved requirement capturing and
system specification during the complete period of development.
– Multi perspective: use of different perspectives (ethnographical, cooperative design, object oriented design etc.) with overlapping activities helped defining the
work practice.
This discussion leads to the proposal of experimental prototyping as a well-suited strategy
for the development process in the D7D/COT context. In section 7.4 a proposal of the tasks
to be done prior and during the development phase is given. This proposal will require some
other issues to be discussed first, and it is therefore not placed at this point in the Thesis.
7.2.2
Implementation Platform
The technology aspect was discussed on the general level in section 7.1.2—in this section a
number of more concrete issues are discussed: object oriented methodology, implementation
language and development tools.
In the context of the D7D project object oriented methods have been established as a
useful technique to model the problem domain, see e.g. section 3.2 and section 3.4. It is
therefore a natural decision made by OSS to join the COT project (OSS is participating in
both case 1 and case 6, see section 2.2). In the context of COT object oriented technology
is the natural choice when deciding on the concrete implementation platform—but it is also
a natural choice by OSS in light of the results obtained by prior projects. There is therefore
a general but very natural restriction regarding the implementation platform: it should be
object oriented.
This general restriction is nevertheless further restricted by a number of issues with relation to both the considerations done regarding legacy systems (section 7.1.2) and with regard
to the choice of development strategy (section 7.2.1). The further restrictions should be done
with regard to whatever legacy systems (in a broad) sense or new systems are in focus—this
is elaborated in the next.
If legacy systems are in focus, e.g. if the concrete goals of a case study are to interface
between existing systems, to extend existing systems or the use of a specific standard is very
important—then the implementation platform might very well be given: the language might
be restricted to e.g. C++, the database might be restricted to existing systems in use, the
exchange standard between tools might be chosen to be e.g. MS-DCOM etc.
If the focus is the development of a new system, e.g. a new communication tool, a new
planning tool, a simulation application—then the implementation platform most likely is
more freely choosable. It might still be the case that the new system has to interface with
existing systems, but the focus should be on the new functionality. This type of systems will
be experimental and it is therefore necessary with an experimental approach. Experimental
Prototyping is suggested as the best possibility towards the development of such systems.
If this approach is used then the implementation platform must support the development
strategy and the developers must have capabilities to use the implementation platform.
CHAPTER 7. IMPLICATIONS
79
The theoretic background in this Thesis has not included an analyses of the pros and
cons of various implementation platforms and supporting development tools for experimental
prototyping—therefore no “hard” suggestions are made regarding the possibilities. But a
number of general guidelines can still be given based on personal experience:
• The language environment is often more important than the actual language used, this
includes:
– Class libraries (including means for building and changing GUI’s fast)
– Debuggers
– Syntax editors (e.g. Emacs with language mode)
• Languages with garbage collection are well suited for fast prototyping.
Other relevant issues are covered in greater detail in [CCD+ 98].
As a final comment the use of CASE tools in this type of development is judged as
questionable. If a CASE tool is used the problem most often faced with is the matter of
consistency: the model in the CASE tool should be consistent with the model defined by
the source code. This can be a hard task if the CASE tool and the editor in use are not
integrated. Two possibilities should be evaluated:
1. The use of an integrated environment like DEVISE (used for the M.A.D. project) where
the two models are automatically kept consistent.
2. The use of a CASE tool only for “drawing” the model: if used this way the time used
for working with the CASE tool should be restricted, e.g. only to make updates when
major reviews are to be performed or for final documentation purpose.
7.2.3
Conclusions Regarding D7D/COT System Development
When a concrete case study has to be done in the D7D/COT context a number of important
decisions have to be made regarding what development strategy and what implementation
platform to use.
The development strategy is restricted by a number of facts e.g. regarding the manpower available and the experimental characteristics of the systems to develop. Based on
these restrictions in conjunction with general conclusions made both at OSS and by similar
projects it is concluded that an experimental prototyping strategy might be a very beneficial
approach because:
1. Domain experts needs to be an integrated part of the development process.
2. The development process must be iterative and step-wise.
When the concrete implementation platform is to be decided upon a number of restrictions
are narrowing the possibilities. These restrictions are both general because of the industrial
character of this project and more specialized because capabilities have to be present by the
developers in order to use a specific technology and because of the overall goal of the project:
research in object technology.
CHAPTER 7. IMPLICATIONS
7.3
80
Fulfilling The D7D Vision
In this section the enhancements to be considered in order to fulfill the D7D vision are
analyzed. The discussion will be made on a high-level where tasks and dependencies are considered, and the analyze will start with some elaborations regarding tasks and dependencies.
The discussion is divided into the two main aspects of faster design—time—and increased
knowledge about committed costs—knowledge. Other ways of dividing this discussion could
have been done, e.g. based on the design levels.
7.3.1
Tasks, Parameters and Dependencies
The figure 7.1 gives an abstract overview of the activities during the design and building of
a new ship. The time line is calendar time, and the milestones between the main phases are
displayed (but not necessarily with correct scaling).
KCP = Known Committed Parameters, CP=Committed Parameters
KCC = Known Committed Cost, CC = Committed Costs
Horizontal bars are tasks, shading indicates different work content.
Figure 7.1: Main Phases with Tasks and Parameters
Tasks
The horizontal bars represent tasks during the process. These tasks could be as fine-grained
as the making of a C-plan or as course-grained as the making of an A-plan, but the meaning is
that a task is a single and identifiable piece of work. In that sense a process is the conjunction
of a number of disjoint tasks. In this description it is very important that a task is not the
CHAPTER 7. IMPLICATIONS
81
work done by a single person or a specific department. For example, the work done by a
single person for a closed period of time could be a task, if in this period the work done
is a single identifiable piece of work. Otherwise, a person can be involved in a number of
tasks at the same period of time. This description of a task is a very functional oriented
description, because it fits the input-computation-output nature of a functional viewpoint. It
should be emphasized that a task very often is the work done be a department or a group in
a department during a fixed period of time—e.g. the work of deciding the main parameters is
a task performed by the Ship Design Department during the project phase. In figure 7.1 the
horizontal bars representing tasks are shaded. This is done because the tasks in the beginning
of a life cycle are very different from the tasks done at the end. For example the task of the
block breakdown of the ship into grand blocks is radical different from the task of buying
steel. The former task is characterized by a very high degree of uncertainty, cross-functional
issues, creativity, domain knowledge etc. The latter task is characterized by being a more
“tactical” (not to be confused with a task performed at the tactical level) task—the right
moment to buy steel, where to buy it and what to order. This distinction is very important
with regard to the D7D project because the objective in the vision is to speed up the initial
part of the overall process—that is, especially tasks that can be characterized in the same way
as the breakdown of the ship into grand blocks is characterized above. General experience
at OSS shows about 20% creative work and 80% routine work in typically tasks in the early
phases. Therefore, the focus must be on helping the user to do the routine part of the task
better and leave more time to the creative part. Important experience is that the typical
end-user asks for tools to do the 20% creative work better. This has to be kept in mind as a
very important issue when discussing specific projects with the target group.
Parameters and Costs
The vertical dotted lines represents a specific moment in calendar time. At such a moment in
time a number of parameters are committed (locked). At the very beginning, when a possible
customer makes a request, the committed parameters are typically the number of containers
the new ship should be able to load (for a container vessel), the final speed required (typically
25 knots) and similar quantities as described in section 6.2.1. At a later time the number
of committed parameters has grown. For example when the Phase 1 Report is completed a
large number of important parameters are decided upon (both with respect to the physical
“layout” of the ship and with respect to the production): the main engine, the lines of
the hull, the main dimensions, a number of plans, ordering of steel etc. When the ship is
completed, all the parameters are committed. In figure 7.1 the set of committed parameters
is called CP . At each moment in time a number of the committed parameters are known.
For example when the initial inquiry is made the final speed of the ship is known. Other
parameters are committed, but might yet not be known. An example of the last kind could be
that a decision has been made about how the ship is to be divided into grand blocks (known
committed parameter)—but this decision (could) impose a certain amount of extra time for
the ship in the dry dock not yet calculated with (unknown committed parameter). The known
committed parameters are called KCP , and are a subset of the committed parameters CP .
In the same way the committed costs can be viewed as a set at each moment in time. The
committed costs and the known committed costs are called CC and KCP in figure 7.1. The
sum of the committed costs is a function over time (ΣCC(t)), and it is this function, that is
drawn in figure 4.1 as the Ex-post known committed cost curve. Remark, that in this way
CHAPTER 7. IMPLICATIONS
82
the committed costs are seen as a set of values—i.e., more fine-grained than just a number.
In this discussion CC is a set of values, where a value e.g. could be the cost of steel or the
cost of using the dry dock for a certain number of days needed to assemble the grand blocks.
The question of whatever CP and CC are two different viewpoints off the same fundamental concept or if they are separate sets arises. In a broad sense they are just different
viewpoints because every parameter committed has a certain cost. From a technical viewpoint the (known) committed parameters are more interesting than the costs, because they
are more directly connected to the process. It is a conceptual easier task to describe a solution
for the communication of certain parameters from the locking point (where the parameters
are decided upon) than to describe it by means of the costs. But the costs should always be
kept in mind when working on a solution to a (part of) the vision—the effort should somehow
match the size of the problem.
Dependencies
The above description can only give a rough description of the work done when designing
a new ship but it is comprehensible enough to clearly describe the intend with the D7D
vision. When possible proposals are to be evaluated with regard to the vision a more detailed
description might be needed. This comes from the fact that there are a number of difficulties,
that comes from the very nature of designing a complicated product. The most important
is cross-functional dependencies—that is, output from other tasks are required to finish a
task, possible in a cyclic way. This give raise to the typical problems of design: locking of
decisions, counteracting groups, iteration, synchronization etc., all related to dependencies.
In [Chr96]4 the IDEF approach is used to describe dependencies in the above sense. This is
a methodology for a graphical description of functions in e.g. a business process (see [Chr96],
page 65–67). Christiansen uses the analysis done to evaluate where costs are committed (see
for example [Chr94b], page 3). But the developed model has mainly been used for discussions
and as an analysis tool—a way for Christiansen to structure and obtain knowledge about the
process. The approach is most likely too static to be used in other ways—the process is
changing too fast for such a detailed model to be useful.
The interesting conclusions in [Chr96] regarding dependencies are made with regard to
the suggestions for a work flow for highly coupled tasks (page 85), which will be discussed
later in section 7.3.3.
7.3.2
D7D Vision Characterization
The discussion and analysis done so far in this section can be used to describe the intent with
the D7D vision at a high level of abstraction:
• Important milestones (most notably t2 in figure 4.1) must be dragged to the left without compromising the knowledge achieved at this point (the set of known committed
parameters) and without delaying the completion of the ship—this means faster design.
• At every moment in time the set KCC (KCP ) should be close to or equal to the set
CC (CP )—this means more precise knowledge.
4
Especially the supplementary report [Chr94b].
CHAPTER 7. IMPLICATIONS
7.3.3
83
The Fulfillment of the D7D Vision
The fulfillment of the D7D vision can in the same manner as the above characterization
be made at a high level of abstraction using the concepts of this section. Two issues are
important: time and knowledge.
The D7D vision is very radical with regard to the reduction in time and the knowledge
achieved at any moment in time. It should again be emphasized that it is not a complete
design of the ship that is strived for during the 7 day period, it is strived for all crossfunctional issues to be resolved to an acceptable level enabling all functions to proceed in
parallel without committing further costs in each other functional areas.
On the general level a number of possibilities exists regarding the fulfillment of the vision
on the operational level—i.e. the following discussion is with regard to the operational phase
of the D7D vision, but where some of the possibilities will require tactical level work. It
must be emphasized that the following list is not intended to cover all possibilities nor to
give in-depth solutions to each item presented—the intention is to describe a framework by
which a concrete project can be characterized with regard to the D7D vision.
1. Remove tasks from the initial phase(s):
If tasks (especially tasks on the critical path regarding time) can be removed from the
initial phase(s) this would reduce the time to perform the phase(s), i.e. milestones are
moved to the left. When tasks are to be removed one of the following items must be
established as true:
(a) The task to be removed is unnecessary.
This item will most likely not be the case: the tasks performed at OSS are the
result of many years of experience and it must thus be assumed that unnecessary
tasks have been removed. It is still possible that existing tasks are to become
unnecessary when a new operational design level process is developed—but this
will then be a positive side effect.
(b) The task can be performed at a later stage during the process without comprising the overall knowledge at any given moment and without delaying the overall
process.
This item is more interesting: proving a certain task to be delayable without
compromising the knowledge or the overall timing constraint would be a part of
fulfilling the vision. An example of such a task might be found in some of the
planning tasks currently performed at OSS. The planning done is very static and
is always done in good time before the activities that are planned are performed.
It might be worth investigating a more dynamically planning process, where some
of the activities are planned while they are performed on a dynamically schedule.
Proof of concept projects are required in this area.
2. Reduce the length of tasks:
If the length of tasks can be reduced, especially for tasks on the critical path, the overall
process could be performed faster. This must of course be done without compromising
the achieved knowledge at any moment. The length of tasks could be reduced in a
number of (interrelated) ways:
CHAPTER 7. IMPLICATIONS
84
(a) Better initial knowledge.
This should be understood as more well-defined initial parameters as input to a
certain task—this is a promising approach, e.g. by development of the tactical
“bereitschaft”. I will put one possibilities of obtaining a better set of initial parameters to a task forward: generation of a initial set of parameters to a certain
task by means of generic models. If generic models are defined it might be possible
to develop systems that can produce a “design-space”: a set of initial parameters
and their given range. The system should use these models and a set of constraints
for the instantiation of these to a specific instance.
A very simple example of this could be the following: a new container vessel is to
have a capacity of 7000 TEU and a cruise speed of 25 knots—these a the specific
constraints. The thought system should then exploit the knowledge contained in
the generic models to produce a set of main parameters and their relations, e.g.
length of ship between L1 and L2 and the beam between B1 and B2 together with
a relation between the two parameters (e.g. as a function mapping the one to the
other in the suggested range).
This is an example of a decision support system. The purpose is to support the
engineering process by suggesting a design-space in which values of parameters
are to be found and relations between these parameters. In order for this type of
systems to be a success it must support the process better than the used approach
today: more well-defined parameters and better relationships, better overview of
a huge number of parameters etc.
The overall goal of these types of systems would be reducing the time spend by
the domain expert on trivial tasks and more time for evaluating the chosen range.
(b) Less communication or movement of communication.
Communication between tasks are dependencies between tasks. If two tasks are
very communication intensive they are highly-coupled—the parameters to decide
on in one or both of the tasks are mutually dependent. On the theoretical level
the tasks could be performed faster is communication were reduced or moved to
the initial part of the tasks. This might be achieved if better systems for communicating decisions were established or if the parameters dependent on each other
could be separated and decided on in the initial part of the tasks. Communication
might be reduced if the knowledge that is communicated each time the tasks are
performed could be modelled in the tactical models, e.g. if the models allowed a
faster evaluation of the interaction of cross-functional parameters. I.e. some of the
communication might actually be modelled on the generic level.
3. Break tasks into smaller tasks and perform them in parallel.
This is one of the main ideas of CE: the parallelization of tasks. If it is possible to
break a task on the critical path into smaller tasks and perform them in parallel then
the overall time used would be shorter. This might be possible if a task consists of
some identifiable subtasks—i.e. the tasks is not as strictly defined as in section 7.3.1.
This approach might only be possible if the subtasks are clearly identifiable and the
number of dependencies between them are low or simple. It might also be possible that
tasks currently not fulfilling this will be dividable in the future: if product models are
defined in a way as described above with the result that communication is reduced.
CHAPTER 7. IMPLICATIONS
85
4. Melt the tasks into larger tasks.
When the length of the initial phase is due to a large amount of dependencies present
between a number of tasks (high coupling) groups of tasks with high coupling could
theoretical be melted into one tasks. This approach will only work if the compound
task reduces the internal communication / number of dependencies—otherwise it is just
make-up where complexity is hidden.
7.3.4
Conclusions Regarding Fulfillment of the D7D Vision
The analyses and discussions made in this section have operationalized the steps necessary
to fulfill the D7D vision. It is not claimed that all possibilities are considered but the main
problems—parameters and dependencies—have been discussed and means for fulfilling the
vision have been presented on a theoretical level. This should be usable as a framework for
characterizing a concrete project, e.g.: (very simple example) if a concrete project has the
goal of reusing past assembly plans as templates when making new plans then this project
is trying to reduce the length of a task by establishing a more well-defined initial set of
parameters.
During the discussion some conclusions have been made with regard to the tactical design
level and with regard to the engineering support systems needed. Here these conclusions are
extracted:
• Generic models are to be defined. This is already a part of the conceptual architecture
of the D7D vision. In the above discussion the use of such models were described as
being a possibility for the fulfillment of the vision on the operational level, e.g. by
enhancing the initial knowledge to a specific tasks.
• Dynamic scheduling of work. Today almost all planning are static and made before
the activity planned for is carried out. It might be very feasible to reduce the initial
planning if it can be done “on the fly” while the activity is in progress.
• More well-defined initial parameters: the example given above suggested the generation
of initial parameters and the relationships between them: a design-space. This will leave
time for the domain expert to make more precise decisions. This latter tasks could
further be supported by simulation tools where the parameters could be evaluated
further.
• Support for communication. Much communication is currently done by e.g. paper. It
might be feasible to build systems to support the communication of locked parameters (decisions taken) on a more formal basis. This item is closely related to product
models—if a company-wide specific product model is made when a new ship is designed
this might just be the right infrastructure to enhance communication on the operational
level.
7.4
A D7D/COT Project Plan
At this point a large number of issues have been analyzed and discussed. This analysis is now
used to make a proposal for how a concrete D7D/COT project might be tackled regarding
what considerations to make prior to a case study.
CHAPTER 7. IMPLICATIONS
86
The description takes an outset in D7D/COT case studies between DIKU and OSS—DMI
is thus not directly addressed. Nevertheless the needs of DMI should also be considered but
with less weight than OSS. In many places the DMI viewpoint can be interchanged with the
OSS viewpoint.
The initial considerations must include the following items:
1. An clear idea of the immediate goals for the new system should be developed. This will
include the following considerations:
• How should the system to be developed help in fulfilling the D7D vision—OSS
viewpoint. Might be answered by using the framework described in section 7.3.3
• What are the research possibilities—DIKU viewpoint. The project should be
evaluated with regard to the COT goals described in section 2.1.3.
• How can the two above goals be combined to achieve a positive effect for all
participants, see section 7.1.1.
2. What implementation platform to use—see section 7.1.2 and section 7.2.2. This decision
must be made with respect to the two main issues:
(a) The industrial experience: are legacy problems involved, could maintenance be a
problem after the development and if so what means could be done with respect
to training and technology transfer—OSS viewpoint
(b) The research possibilities: could interesting points be evaluated better with this
platform contrary to another—DIKU viewpoint.
3. What particular domain experts should use the system to-be and how are they integrated in the system development process, see section 7.1.3.
4. What development strategy to use—see section 7.2.1.
When evaluating a concrete project idea other considerations might also be in focus, but the
above list is intended to cover the subjects that as a minimum must be considered.
7.5
Conclusions Regarding Implications
The D7D vision implies a large number of issues to be tackled when projects are to be defined
and carried through, both as part of the D7D project and especially in this context as part of
the D7D/COT project. In this chapter these issues have been clarified to some extent, based
on the achieved knowledge during the D7D/COT project period and the process of writing
this Thesis.
These issues ranges a large number of subjects:
• General considerations: different or only partial overlapping goals and viewpoints, the
wealth of legacy systems in use, and the impact of the target group characteristics
on the systems to be developed and on the development process itself. These general
issues have to be regarded when a project idea is to be evaluated: how can the goals
of all participant be fulfilled, what is the impact of the presence of the legacy systems
and achieved knowledge regarding implementation platforms, and what should be done
in order to integrate the domain experts in feeling responsibility both for the system
development and the use of the final system.
CHAPTER 7. IMPLICATIONS
87
• The development strategy: when a new system is to be developed an implementation
platform and a development strategy must be chosen. The experimental characteristics of the D7D/COT project and the restrictions in man-power available will require
that domain experts are integrated in the development process and that the process is
iterative. Experimental prototyping is considered as a suitable approach.
• The D7D vision: when a new project idea is to be evaluated it should be clarified how
the project goals are interacting with the D7D vision—i.e. how does the new system
eventually reduce the time required in the operational phase and how is knowledge in
any aspect increased. This can be done by evaluating how tasks are to be reduced,
parameters are made more well-defined, dependencies are removed etc.
I will conclude this part and chapter with the following: the fulfillment of the D7D vision
will still require much work to be done—both through practical projects but certainly also by
decisions to be taken on the management level. Many of the ideas in the vision—e.g. the very
promising approach of using generic models—will require that the management decides that
considerable amounts of resources (most notably time) are allocated to the implementation
of the ideas.
Part IV
D7D/COT Project Cases
88
Chapter 8
Power Prediction
A part of the goals for the D7D/COT project is the development of an application for making
a prediction of the final speed of a vessel based on the initial parameters describing the shape
of the hull and a given engine power—alternative a prediction of the necessary engine power
given the shape and a required speed.
The subject of power prediction (PP) is very important in the early phases of design.
A customer usually has a requirement for the final cruise speed—e.g. typically 25 knots for
container vessels. When the ship is delivered a sea trial is performed and the tolerance of the
cruise speed is normally only 0,1 knots. Because the overall shape of the hull and the engine
are decided upon at an early stage in the design, the manufacturing yard has to be certain
that the required cruise speed can be met with the decisions made.
DMI and OSS have in cooperation described a vision for a distributed PP tool. The
intention is to develop a tool that can be used over the Internet with access to a number
of databases containing both model and sea trial data. A number of problems arise with
this vision because the owners of the databases typically regard the contents of these as
confidential. This will require that the users of such a tool are unable to uncover the actual
data stored in the databases but nevertheless are able to make some sort of queries. Another
problem is the reverse—a user typically would not allow the owner of the databases (which
most likely is another company) to know what dimensions etc. the new project ship has.
The vision of this PP tool to-be, the work done on a prototype and the research goals are
the subjects for this chapter.
8.1
The Process of Power Prediction
As explained in section 6.2 the initial predictions are done in phase 0 and prototype experiments to verify the shape of the hull are typically done in phase 1, sometimes also in phase 0.
Today both OSS and DMI are capable of making a power prediction based on the initial
parameters. In this section the as-is process at OSS and DMI are described.
8.1.1
The OSS Practice for Power Prediction
OSS currently uses two statistical methods for power prediction based on existing ships. It
is the ship designers (department 41.00) responsibility to make the power prediction. The
89
CHAPTER 8. POWER PREDICTION
90
description in this section is based on Christian Frost’s description in [FLHF98].
The first approach is applied in the preliminary design phase. The method is based on a
computer program called DESP. As input to DESP the main dimensions, a few form parameters and some other parameters are required. The input is known or can be guessed within
enough precision at this stage in the design process. The data for the propeller is modelled
using Wageningen B-series polynomials1 . DESP is capable of producing predictions for the
speed and propulsion characteristics of displacement (non-planing) ships. The calculations
done is based on formulas obtained from a regression analysis on results from both prototype
experiments (models) and actual sea trials (Holtrop–Mennen)2 . The method is improved by
making a correlation with the data from sea trials from similar ships. This method is a calibration of the tool, where a correlation allowance is tuned to match the result from a similar
design with the actual measured power required at sea trial. The correlation addition is then
used as input for the new design. The output from DESP is the efficiency and resistance
components for the design speed or the design power, a review of the resistance, the thrust
and the propulsive power as a function of the speed and tables of the pulling performance at
both constant torque and moment.
The second approach is applied later in the design process where more information about
the shape of the hull is known. The method is based on a suite of applications developed by
MARIN on order of the Cooperative Research Ships (CRS)-HULL Working Group of which
OSS is a member of. The input from the designer comes in form of a data table with 20
equally spaced stations (points on the surface of the hull). The application then calculates
approximately 80 parameters describing the shape of the hull. These parameters are then
used as input to the power prediction. The power prediction is done using a combination of
regression analysis and neural network analysis. The output is of similar form as that of the
DESP method described above.
8.1.2
The DMI Practice for Power Prediction
The description in this section is based on Kim Henriksen’s description in [FLHF98]. At DMI
several methods are used to make an early power prediction for a new project:
1.
2.
3.
4.
5.
6.
Oracle Database
LINRES Regression
Effektprognose3
NavCad
HOLTROP
Guldhammer
The first approach uses the model database at DMI. This is an Oracle based database
where model results from all open water, resistance and self-propulsion tests done by DMI
since 1970 are stored. The data is stored in model scale. For each series of model tests there
1
A number of empirical formulas describing the relation between a number of parameters like power,
diameter, pitch, RPM etc.
2
Empirical formulas developed around 1982 by Holtrop and Mennen working for MARIN (a Dutch test
facility). The formulas can give the resistance given the shape of the hull.
3
Danish for “Power Prediction”.
CHAPTER 8. POWER PREDICTION
91
are data sheets with the corresponding hull data, resistance data, prognosis data and (if
relevant) propeller coefficients and self-propulsion data. The database is currently running
under VMS on an old Micro-Vax. This gives a problem with interfacing to the system.
Application for the transfer of data between the data sheets and the database exists, but a
new strategi for analysis based on the data has been implemented and this tool is executed on
standard PC-platforms. The database is not updated any longer and plans for the transfer of
the data to a new systems are currently in progress. The database is linked with to the DMI
analysis application RESPAN. This tool makes it possible to search the database for model
test results for ships with similar characteristic as the subject ship. The similar characteristics
in this case means that similar hull coefficients have to be found. This search can use either
an ID parameter based on the DMI numbering system or it can use up to six non-dimensional
hull form parameters: Block Coefficient, Fineness Coefficient, Prismatic Coefficient, LengthBeam Ratio, Beam-Draft Ration, Bulb Area Ratio and the highest Froude Number. The
result of a search is a table with model tests sorted in a rated order based on the query. After
this it is possible to perform an on-line analysis for each project. This involves a scaling of
all the data to match the subject ship. The scaling is done on either the Length Between
Perpendiculars (LBP) or the displacement. This process might give different results for a new
subject depending on which model test was the basis for the prediction. Often the person
performing the test will make a plot of the wave resistance coefficients and thereby perform
a manually regression. The final result of this method is the Effective Power and/or the
Propeller Power by use of stock propeller data.
The second approach is a LINRES regression analysis. This method is based on selected
DMI model test results. The data is taken directly from the DMI reports regarding the
specific test, i.e. after the analysis to full scale is done. The analysis from model scale to full
scale is done by ship extrapolation methods in use at the time of the writing of the reports.
The data is stored in ASCII files with one file for each ship. Therefore the search for a best fit
with regard to the subject ship is more complicated than with the database approach (it has
to be done manually). All the data in a given file (for a single ship) is used in the regression
analysis. The data is however subject to a weighting procedure where hull forms closer to
the subject ship is given a greater weight during the analysis. As the regression analysis is
made for specific Froude number the data set is influenced by a further weighting process.
This is done to limit the use of those datasets, where the speed range does not cover that
required by the subject ship. The data files includes propulsive coefficients and the propeller
diameter, but other propeller parameters are not included. Also the open water test results
are not included. The regression analysis is therefore at present limited to the determination
of residuary resistance (CR ), the wetted surface and the form factor. All in all the output
from the LINRES regression analysis is limited to the determination of the effective power
for the subject ship.
The third approach is a tool called Effektprognose. The tool is developed by Kasper
Bøgh Pedersen as a master project and it is described in [Ped97a]. The basis for the tool is a
selection of 67 ships from the LINRES data files. The selected data is entered in a spreadsheet
program and all the calculations are done by macros defined in the spreadsheet program.
These calculations include another regression analysis with the purpose of correcting the
resistance coefficient based on a method described in [Hol84]. The analysis take form of
an interactive session where the user is prompted for some limits of good or bad data with
respect to main dimensions and resistance. In this way the user performs a weighting of the
data to be used and thus influences the prediction. The output of the tool are three resistance
CHAPTER 8. POWER PREDICTION
92
curves (effective power) for 10%, 50% and 90% fractal results. Furthermore, a simple analysis
is done to calculate the effect on the resistance if the length, beam or draft is changed by 1%.
After the use of one of the three methods described so far a final effective power curve
has been calculated as output. After this the propeller dimension is subject to optimization.
This work is based on standard propeller data sheets accessed through a simple application. The optimization process is mostly a manually task where the evaluation of propulsive
characteristics is based on experience. The final output is a propeller power curve with the
corresponding propeller revolution and efficiency.
The last three approaches are the NavCad, Holtrop and Guldhammer methods. All these
are commercially available methods and all three are included in the NavCad application.
The methods are based on regression analysis of model tests. DMI is only using these methods
if their databases only contain ships with a very poor correlation with the subject ship.
8.2
The Visions for the Power Prediction Tool
The vision is to build a distributed power prediction tool based on both model and trial
experiments. The goal is a tool that can make both a power prediction based on initial
parameters and give a proposal of the lines of the hull given a few initial parameters like
length and breadth. The latter is a very hard task and should be seen as an ultimate goal.
Both DMI and OSS have databases with prototype experiments and trial experiments
for the same ships. As described in [Ped97a] and in the above description of the practise of
power prediction such a collection of data can be used to make a prediction of the required
propulsion power. Such databases are the intended basis for the PP tool.
8.2.1
User Requirements
The requirements for the power prediction tool are described in [HP99] and in [FLP98]
(page 16–21). An indispensable requirement is, that the new tool has to be more accurate
than various existing empirical methods like Holtrop ([Hol84]). This should be achieved by
an interactive use of databases containing model tests results where similar models regarding
geometry, speed range, use of bulb etc. are chosen and used as basis for a regression analysis.
Compared to other methods this should minimize the error caused by generalization. Also,
the addition of new data to the databases should ensure that the method is up to date. The
tool is intended to give the client a power prognosis at an earlier design stage than usual.
The prognosis should be accurate enough to be used as an important parameter in the choice
of engine and the main dimensions and hull coefficients for a desired cruise speed.
The most important requirements are:
1. It must be possible to use the tool at any stage in the design process with various numbers of fixed parameters. These parameters should then be used to search the databases
for models with similar characteristics. The databases are either stored locally or they
are distributed. The search in different databases may not necessary be simultaneous.
The reason for the latter is that different towing tanks have slightly different “traditions” for the interpretation of the test results. The results from the different databases
can therefore not easily be “mixed”. It is a better solution for the designer to get e.g.
CHAPTER 8. POWER PREDICTION
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
93
two different results when querying two databases than one averaged result. It is then
a task of the designer to interpret the results based on experience. In other words, a
mixing of the results would most likely result in information being lost.
The databases can include results from full scale trials or results from CFD analysis.
Also model tests where some of the parameters are unknown can be included.
On the basis of the selected models it must be possible to perform a resistance analysis
(prediction of CR and wetted surface), an estimation of the wake, trust and relativerotative efficiency.
The tool must allow the optimization of the propeller diameter and revolutions by
choosing either a B-series propeller or a DMI stock propeller. A first check of the
required blade area should be possible.
The tool must provide a power prediction (in the form of tables and plots) at both trial
and service conditions.
The plots of power should contain 10%, 50% and 90% percentiles of power based on
percentiles of the CR values.
The calculated results must include an indication of the confidence of the prediction.
The level of confidence will be dependent on the number of fixed parameters and the
number of matching models that are found. Also suggestions for optimizations of the
main dimensions and non-dimensional hull parameters with regard to power vs. speed
and building costs.
It should be possible to enter the input to the tool either manually or as the output of
some other tools (typically NAPA or similar).
Other empirical methods for the prediction of the speed should be included, e.g. Holtrop
or similar.
The client should be able to choose the hull parameters for the analysis on both data
available and subject for the regression analysis.
The tool should also include means for exploiting a maneuver prediction tool created
at DMI.
The tool should be accessible over the Internet by a web browser.
These requirements are based on the viewpoint of the ship designer. It should be noted, that
this list is a list of “wishes”—some of the items may not be possible to fulfill—but the list is
an important goal to aspire to.
8.2.2
Data-owner Requirements
Another important viewpoint in this case is the viewpoint of the database owners. Some
very important security problems are evident because the owner typically do not want to
compromise the integrity of their databases—the data are company classified knowledge and
represents a valuable asset. Nevertheless a positive effect can be made for all partners if the
vision is possible to fulfill without compromising the data-integrity.
As a consequence of these problems a number of requirements have been made by the
data-owner—in this case DMI, but the requirements are of a general kind and should be
acceptable for others interested in “joining the tool”. These requirements are described
in [HP99] and in [FLP98]:
CHAPTER 8. POWER PREDICTION
94
• It should not be possible for the user to infer the contents of a database while querying
it through the tool.
• It should not be possible for the owners of a databases to infer the main dimensions of
the subject ship while a user queries the database through the tool.
It might not be possible to completely fulfill these requirements, but e.g. the inferring of the
contents of the databases by making a large number of “well-chosen” queries should be made
as hard as possible—in other words, not worth the costs of the use of the database4 Another
possibility is that the tool can work in two modes—e.g. when a user at DMI uses the tool on
the locally stored database at DMI full access should be granted.
8.3
Design and Implementation Considerations
The above listed (section 8.2.1 and section 8.2.2) requirements to the tool can be exploited to
extract some idea of the design and implementation of such a tool. The architecture, design
and implementation considerations are the subjects for the rest of this section.
First of all it should be emphasized that the “wishes” described in section 8.2.1 will require
the development of suitable mathematical models. This is not in the scope of the participants
from DIKU, but is the responsibility of the partners from DMI and OSS—and this work is
in progress: at DMI one person is working near full-time with the PP tool and along with
this the development of the mathematical models.
8.3.1
Implementation Platform
The first consideration was the choice of implementation platform. The requirement that
the (client) tool should be able to run inside a web browser leaves only a small number of
possibilities [FM96]:
1. A client side HTML-forms solution.
2. A client side Active-X solution.
3. A client side Java-applet solution.
The first choice must be rejected based on security reasons. In this case no client code can be
run, which means that the server side has to do all the calculations. This would compromise
the requirement that the server side should not be aware of the main dimensions. Also the
requirement that the tool is to be used interactively would be made hard, because the server
side would have to produce dynamic generated HTML documents as response to each queries.
When a large number of queries are to be done this would mean that the client had to manage
a great number of documents inside the browser—hardly a user-friendly solution. The second
possibility would tie the tool to the MS-Explorer browser—the optimal solution is that the
tool is as browser independent as possible. Therefore a client side Java applet solution seems
to be a reasonable choice. This is also a good solution with regard to communication volume
and server load [FM96]. The client side code can be made completely responsible for the
graphical depiction of the interface (both input and output part). This reduces the network
4
It is of course a possibility, that the use of the tool will require a payment to the data-owner.
CHAPTER 8. POWER PREDICTION
95
traffic (no large graphic plots of results have to be send from the server to the client) and it
reduces the server load (the graphical depicted results have not to be dynamically generated
on the server side).
The client side must be able to communicate with the server side(s). It is possible to use
e.g. TCP/IP from a Java applet, which leaves the choice for the implementation of the server
side open. If the client side runs as a Java applet and the choice for the server side is open it
would be an obvious solution also to choose Java as the implementation platform for the server
side. This would make it possible to use the Remote Method Invocation (RMI) mechanism
for communication between the client and the server side. Herby an easier integration of the
sides would be possible, because the object model on both sides would be the same.
It therefore seems to be a reasonable choice to write both the client and the server side
in Java and use RMI for communication purpose. This should of course later be reviewed,
when other aspects have been discussed.
8.3.2
Security Considerations
The problem of data integrity was shortly described in section 8.2.2. The security problems
can be expressed as five more or less independent items treated below. The possible solutions
to a number of these items are obvious whereas others are more complicated.
1. Clients should not be able to identify ships or models in the database.
The problem here is that the data-owner typically only makes model tests after a specific
request from a customer—i.e. the towing tank typically has model data that matches
a specific ship. This ship is of course to be build at a yard (the above mentioned
customer) and this yard normally regards the dimensions and other details of the ship
as confidential knowledge which should not be communicated to a third party directly.
On the other hand, the data-owner normally has the right to exploit the data, e.g. in
the in section 8.1.2 mentioned process of power prediction.
A solution to this might be to restrict the exchanged data to be non-dimensional values
(like the block coefficient and likewise). If this solution is enough, the mathematical
models to be developed must ensure, that the non-dimensional values are sufficient for
the client to make a prediction of the required quality.
2. Clients should not be able to extract the content of the databases.
This problem was already mentioned in section 8.2.2. The problem is, that the dataowner sees the specific content of the database as a valuable asset of the company. A
reasonable solution would be to make it a “hard” problem for the client to re-build the
database from statistics on a large number of queries compared to the eventually price
of using the database in connection with the PP tool.
Several possibilities exists. Some very low-level “tricks” are possible, e.g.: if the
database only could be inferred from a very large number of queries a possible solution could be to restrict the number of queries per day and eventually also insert a
time delay between the queries. It might also be enough regarding this matter to use
non-dimensional values as in the former problem. This should be thought about by the
people knowing about the mathematical models—i.e. DMI should for example try to
develop a method to re-build the database given the non-dimensional quantities. If this
is possible, the method is not enough.
CHAPTER 8. POWER PREDICTION
96
3. Description of client queries must be kept from third party.
A reasonable and normal requirement regarding the exchange of information in a business process
This is easily secured by encrypting the messages send between the client and the server.
4. It would be preferable if the client queries are kept confidential even with respect to
the owners of the database. This would make the business foundation greater because
clients would be able to use the tool without fearing the integrity of their own business—
in this case details about a specific order in process, where the contract might not be
signed yet.
This depends on the level of confidence between the customer (client) and the dataowner. If the problem is the specific main dimensions it might again be enough to use
non-dimensional values. If the client and server are competitive yards the only solution
might be to use an “independent” mediator acting on behalf of both sides.
5. Database owners should not be able to “see” each others data.
Analog to the requirement regarding the clients possibility of inferring the content of
the databases.
If problem 1 and 2 are solved, this problem should also be solved because the dataowners should only have the same means for exploiting each others databases as a “real”
client have.
Most of the above problems are largely dependent on the choices to be made by the dataowners eventually participating in the final tool. If they decide that all these problems are
in scope and have to be solved to a high degree of security, second thought have to be given
to this. But at the time of writing the use of cryptography to ensure the integrity of data
in transport and the use of purely non-dimensional values as means for data exchange is
considered as enough.
A solution where customers can purchase a grant to use one or more databases might
also be considered. In this way some competitors can be excluded from the use. Legal
considerations should be done on this part which is out of the scope of this Thesis.
A last problem involving the use of several databases is that it might be possible that the
same ship has been tested at several towing tanks independently. Therefore, the possibility
that the same data is being used with “double” weight exists. This might not be a problem
when the results are not “mixed”, as described in section 8.2.1. If it is a problem a way
to determine that two ships eventually are identical should be considered. At the time of
writing this is not considered as a problem.
8.3.3
Architecture and Interface
Based on the choices made the system is now identified to consists of at least the following
components:
• One or more databases with model, trial and other relevant data.
• A server for each database. This server is responsible for the communication with
the client side and to extract the information from the database. The server might
CHAPTER 8. POWER PREDICTION
97
be divided in two parts or there might be two servers, because local access should be
granted greater capabilities. The server is responsible for the accept of client requests
based on non-dimensional values. The request should be matched with a number of
matching database entries. The extracted entries should then be transformed to nondimensional values and given as response to the request.
• A client side Java applet. This component implements the user interface and performs
the calculations required to transform the request (entered main dimensions) into nondimensional values. The values are send and the response is then used to calculate
the required quantities. These are then depicted in a suitable way. This will be a
graphical representation of the candidates. Based on this the user can select suitable
candidates (from experience and knowledge not given to the tool) and enter other design
parameters. These can then be send back to the server etc.
The possibility of independent mediator systems adds a layer between the server and client,
but are not given more attention in this Thesis.
8.4
The PP Prototype
The above requirements and design issues were discussed among the partners in the fall 1998.
Several possibilities for further progress were evaluated, but the decision to develop a prototype was finally taken. The decision to use a prototyping approach was made due to both
general and concrete reasons. The general reasons are due to the experimental characteristics
of the PP tool which was elaborated on section 7.2.1.
The concrete reasons for making a prototype was as follows:
• The mathematical models have yet to be developed. If the final tool for reasons unknown
would be impossible to build the resources spend on this matter might be wasted.
• The participants from DIKU felt that the choices described so far (e.g. the use of Java
as implementation platform) were the right choices. The easiest way of convincing the
partners would be proof by construction.
• The design and implementation of the prototype would make it possible for the responsible person at DMI to participate in this work and thus achieve valuable knowledge
about issues not strictly related to the process of power prediction but to issues regarding the system overall.
8.4.1
Work Done
During December 1998 and part of January 1999 a prototype for the Power Prediction tool
was developed. The development was done by Niels Elgaard Larsen in cooperation with
Kasper Bøgh Pedersen from DMI. In the same period Kasper Bøgh Pedersen was trained in
OO programming and design by Morten Frank.
This work ended with the finished prototype and a very valuable knowledge transfer of
object oriented design and implementation to DMI.
CHAPTER 8. POWER PREDICTION
8.4.2
98
Goals and Status of the PP Tool
The goal was to develop a WWW application that could compute the resistance of a subject
ship based on a small number of main dimensions—a dump of the graphical user interface
can be seen in figure 8.1.
Figure 8.1: Screen Dump for Power Prediction Prototype
The main purpose was not to make an accurate prediction, but to gain experience in
the layout of the user interface, the distributed aspects, security problems, implementation
problems etc. Hence, the PP tool is not to be regarded as a tool for power prediction. The
algorithms in use for making the prediction were not in scope.
We chose to use the method described in [Ped97a] and in section 8.1.2 because the final
method would include an enhancement of this method and because the participant from DMI
had great knowledge about it (he had developed the method).
CHAPTER 8. POWER PREDICTION
99
The interfacing to the database in the final tool was regarded as a minor problem (low
risk) but possible with much work attached to it. Therefor the server was implemented as a
program, where the test database (67 ships) was read from a file at startup time.
A number of the ship designers requirements should be discussed in conjunction with the
choices made for the prototype. I will only repeat part of the requirements, please hold this
list against the lists in section 8.2.1 and section 8.2.2—the items are treated in the same
order.
1. The prototype works with a fixed number of main dimensions. Five parameters are
mandatory (maximal length of waterline (L), maximal beam in waterline (B), draft aft
and for (TA and TF ) and volumetric displacement (∇). The use of models with either
bulb or without bulb is possible. Other more variable methods, where other main
dimensions could be entered, would require, that other algorithms for the prediction
were used. This is not done in the prototype. The database considerations present in
the requirement list are not present for the prototype. As described, we chose to read
a file containing 67 ships at startup time. We plan to add an interface to database
systems using ODBC/JDBC. Our initial experience with the prototype suggests that
the size of the model test data needed for the tool is fairly small (can be hold in main
memory) and can be manipulated most efficiently directly by the server side of the
prototype.
2. The problem of developing suitable databases with interesting data is not in scope of
the participants from DIKU.
3. The prototype estimates the wetted surface. The resistance is estimated according
to Froude’s law by use of the form factor method. CR and 1 + k are predicted. A
resistance prognosis is done (estimation of CT ). The estimation of wake, thrust and
relative-rotative efficiency have yet to be done.
4. The optimization of the propeller is still to be implemented.
5. The prototype currently only makes prediction of one speed. We plan to extend the
prototype to make graphs and prediction tables for a speed range. This should be a
simple task in the current implementation.
6. The plots done contains the 10%, 50% and 90% percentiles of power based on percentiles
of the CR values.
7. The level of confidence is currently being implemented as a computation of the total
standard deviation of CR , 1 + k and the wetted surface (if estimated). The vision of
the suggestion of design optimizations are as described a hard task and therefore would
mean use of algorithms yet to be invented.
8. Currently the prototype only supports manual input. It should be straightforward
to implement input from files generated by NAPA or similar software. However, the
algorithm currently in use do not need other input as the few parameters typed in
manually—i.e. the need for input from a NAPA generated file is first present when new
algorithms have been developed.
9. It is possible to include other algorithms in the prototype, but it would not be interesting
since they would not be reused in the final tool: DMI are developing new algorithms
and the implementation of others would therefore be wasted time.
10. The client should be able to choose the hull parameters for the analysis on both data
available and subjects for the regression analysis: this is not implemented because it
requires the development of suitable mathematical methods.
CHAPTER 8. POWER PREDICTION
100
11. It should be easily possible to link from the tool to a maneuver prediction tool at DMI
once this has been developed.
12. The tool is indeed accessible over the Internet by a web browser. Currently the tool is
working with both Netscape and with MS-Explorer. However, browser-specific security
issues are still to be solved—e.g. regarding saving the output from the power prediction
on local disk.
Regarding the security considerations described the choice have been made to use only
non-dimensional geometry parameters for data in transport. This should ensure that the
client can not read the content of the database while the server-side can not read the specific
main dimension of the project ship. Considerations on where critical code is executed have
also been made. The encryption of data in transport is still to be implemented, but should
not be a hard task.
8.4.3
Using the Prototype
The use of the prototype is described in [Ped99]. Here is a short description of how the tool
is used:
1. Ensure that the browser in use has a Java Virtual Machine and that the use of it is
enabled.
2. Open one of the web pages:
http://amigos01.diku.dk/cot/index.html
http://amigos10.diku.dk/cot/index.html
(On test state—these machines do not run the server program at any one moment)
3. Enter some name for the subject.
4. Choose “Start speed prediction”. After this the Java applet is executed.
5. Main dimensions can now be entered and the “ok” button be pressed.
When this is done the tool does the following:
AF P
L B
1. Non-dimensional parameters are calculated (CP , L∇3 , B
T , LCB, AM , CB and Fn ).
2. The non-dimensional parameters, the value of the bulb check-box (ship with or without
bulb) and the preferred number of models for analysis is send to the server.
3. The server searches the model data for matches. The selection criteria is as follows:
(a) A model test is only selected if it is performed at the given Froude number (Fn )
or close to it.
(b) If the bulb check-box is not selected the search ranges all project ships. If the bulb
check-box is selected and the subject ship is without bulb (can be inferred from
the value of AA-field, if the value is zero the subject is without bulb, if the value
is greater than zero the subject is with bulb) only project ships without bulbous
bows are selected. If the bulb check-box is selected and the subject ship has a
bulbous bow only project ships with bulbous bows are selected.
(c) If the preferred number of models is lower than the number of found matches
based on the above criteria models are sorted out. This is based on the greatest
standard deviation in non-dimensional geometry.
CHAPTER 8. POWER PREDICTION
101
4. The measured CR value is calculated using spline interpolation for each found model.
5. The measured CR value is converted to match the geometry of the project ship. This
is done by use of Holtrop’s empirical formula for calculating CR :
(a) CR is calculated according to Holtrop for the project ship (denoted CRHOLP )
(b) CR is calculated according to Holtrop for each found model (denoted CRHOLMi )
(c) The converted values are calculated by
RHOLP
CRConvertedi = CRM easuredi · CCRHOLM
i
6. The 10%, 50% and 90% percentiles of CRConverted is sent to the client along with the
calculated standard deviation on CR and a matrix containing the deviations in nondimension geometry used for plots. As only the percentiles are sent to the client, the
client can not infer the measured CR 5
7. At the client side the following calculations are done:
(a) CF is calculated according to ITTC-78: the calculation of e.g. CF requires use of
empirical formulas, the ITTC-78 defines a standard for this calculation.
(b) The form factor is calculated from empirical formulas (Holtrop’s formulas modified
to fit the DMI data).
(c) The relative standard deviation on the calculated resistance. This is a combination
between the standard deviation on CR , the form factor and the wetted surface if
the latter is estimated.
(d) The 10%, 50% and 90% percentiles of CT , RT and PE .
(e) A plot of the difference in non-dimensional geometry. The client can select the
parameters for the two dimensions in the plot from a pull-down menu.
8.5
Power Prediction and D7D/COT
Both the vision of the Power Prediction tool and the developed prototype is a part of the
D7D/COT project which makes an evaluation of these in relation to both the D7D vision
and the COT objectives necessary. This is the subject for this section.
8.5.1
PP and the D7D Vision
The D7D vision has been described in chapter 4 and conclusions have in section 7.3.3 been
made with regard to what steps are necessary to achieve the goals. The conclusions relevant
for the Speed Prediction drawn both in this Thesis and in the relevant references are given
in the following:
1. Making initial tasks shorter could help in making a faster overall (rough) design.
In some ship series model experiments (prototype experiments) are already done in
phase 0 before the signing of a contract. This can be necessary when the type of the
ship differs largely from the usually (does not fit well with accumulated knowledge at
the yard). At this stage typically only very few parameters are clearly known, like
easured
In practise only percentiles of CRM
is calculated at the server side and send back to the client,
CRHOlM
where they are multiplied by CRHOLP
5
CHAPTER 8. POWER PREDICTION
102
length and beam. A physical prototype is expensive both in time and money and a
prototype approach would only uncover a fixed set of the parameters and leave little
space for experimentations. Therefore, if a PP tool can be build with the required level
of confidence much more room for experimentation with combinations of the various
parameters are left open. Also, the final vision of giving the ship designer suggestions
for optimizations would clearly help at this stage in the design process.
In most series model experiments are done during the end of phase 1 where the shape
of the hull is nearly completely defined. If the PP tool also can be exploited with great
accuracy at this point, eventually also as in combination with a maneuver prediction
tool, then the effect might be that also phase 1 could be made considerably shorter
(the biggest problem with prototype experiments at this stage is the amount of time it
takes to perform).
2. Making the parameters more well-defined earlier than at present gives a better basis
for making decisions.
One of the problems discussed in connection with the D7D visions was, that the basis
for making decisions should be enhanced. If greater knowledge is achieved by using
the PP tool in regard to the parameters to decide upon much uncertainty vanishes.
If, for example, the situation at present is that the ship designers only experiments
with a certain range and combinations of the parameters to decide upon (due to lack
of time and tools), then a PP tool (which fulfills the visions described) could make the
basis better. It might not be the case, that the actual values at last chosen for the
parameters changes with regard to the “old” method—but the amount of uncertainty
would be reduced.
3. Virtual Enterprises is a way of achieving the right competence and the right knowledge
at the right time in the process.
If a number of database-owners join the PP project the sum might very-well exceed the
individual contributions, i.e. a positive effect for all the participants could be obtained
without anyone loosing business assets. A truly distributed PP tool with a number of
databases attached to it is a Virtual Enterprise—a number of independent companies
is brought together to solve a problem, each contributing with their knowledge in a safe
manner. The problem that in this way is solved could not be solved by a single of the
companies individually (with the same confidence regarding the prediction).
4. Simulations is a way of making tactical design.
A PP tool would be fast and easy to use compared to real model experiments. If the
level of confidence is great, then such a tool can be used by the yard to enhance their
tactical design. A part of the tactical design could be to define generic product models
as described in [Chr96]. These product models could be enhanced if they are evaluated
with a PP tool. Product models that might have been accepted can then be sorted out,
if they have bad characteristics regarding the shape of the hull. Other product models
not usually accepted could be verified to have good characteristics, and thus should be
included in the generic product database.
As it can be seen from this discussion the development of a PP tool fulfilling the visions
could help in fulfilling the D7D vision in a number of ways. It should therefore be concluded,
that OSS should give this development attention. It might be the case, that the complete
CHAPTER 8. POWER PREDICTION
103
development is not worth the trouble (if the tool fails the required level of confidence), but
it might be hard to make this conclusion without actually trying it.
8.5.2
PP and the COT goals
The research goals defined by COT have been described and discussed in section 2.1.2. A
number of the given research goals are relevant to review based on the work done by developing
the Power Prediction prototype:
1. The architecture of object systems: At least the following two subjects defined by COT
are relevant:
(a) Distributed Objects: The PP tool is clearly a distributed tool. Objects are distributed among the clients and servers using the Java RMI technology. A considerable amount of the work done was to ensure that security problems were clarified,
and that means for distributing objects among business competitors were developed.
(b) Open Implementations: The PP tool is designed to be an open implementation in
the sense, that new database-owners can join the project when wanted.
This main focus area also has the overall goal of better re-use at all levels. In this
project the re-use of code is evident. A large part of the prototype-code should be
re-usable, especially the code written for communication purpose.
2. IT support for cooperative object oriented software development: Not in scope in this
case study.
3. Introduction of object technologies: Very relevant in this case study. At least the
following subjects defined by COT are relevant:
(a) Introduction of Object Technology: The question in scope was how can OO technology best be introduced/integrated in a company. Before the concrete D7D/COT
case was defined DMI had not given the architecture and implementation platform
of the tool much attention. This cannot be blamed because their main competence
is model experiments and numerical methods. But nevertheless the issue of architecture and implementation platform is an important part when designing a
new tool. The situation has now changed: DMI has gained experience in OO
technology, mainly through the training of a key person in the development of the
tool.
(b) Introduction of Re-use: In a broad sense, DMI had already experience of re-use—
the use of old model test data to make a new power prediction. The use of re-use
in the more OO aspect has yet to be done, but the value of code re-use have been
accepted by DMI, in particular the person involved in the prototype development.
(c) Maturing through step-wise Introduction: The experiences by DMI with the use
of e.g. Java throughout this project might very well mean that they will consider
the use of OO technology in other areas. DMI is as explained in section 2.3 also
involved in the COT case 6, so the interest in OO technology is present.
(d) Methods to handle Heterogeneous Platforms: In the future version a bridge between the server-side and various databases has to be made. The databases in use
will most certainly all be of the relational type, so this subject will in the future
have to be regarded.
CHAPTER 8. POWER PREDICTION
104
(e) Scenario Based Prototyping: The precise way by COT to express this subject is
by introducing the project DEVISE which is a EuroCode project developed to
support iterative analysis and design through prototyping and simulation. We
have not considered using this approach but the subject of prototyping must fall
into this category.
As a final note, a number of research fields might be of interest to this project in the future:
• Security: a more elaborate treatment of the security problems might be necessary.
• Architecture: what should the final architecture of the system be. It might be necessary
to use some kind of mediator system between the client and database (e.g. independent
servers).
• Databases: it might be necessary to elaborate the similarity search done to find good
candidates in greater detail.
8.6
Future Work
Many of the visions for the final PP tools are still to be fulfilled. We feel assure, that the final
tool can be build if suitable mathematical models are developed and if suitable databases are
defined.
The work on the databases is currently in progress at DMI. The data in the old database
is transferred to a new system. This work will include a re-definition of the structure of the
database. The structure of the database was also discussed on a meeting at DMI, where
the participants from DIKU made several suggestions to ensure a suitable structure—the
structure of the database is still open to discussion, and the possibility that we still can make
valuable suggestions exists.
The development of suitable mathematical models and corresponding algorithms is also
in progress by people at DMI. When the models are defined it could be a possibility, that
participants from DIKU could make valuable suggestions regarding the transformation of
these into suitable algorithms.
Browser specific problems still need further attention. This work can be done on the
prototype in parallel with the above described work to be done.
The work on a more precise definition of the requirements is in progress. This will include
a definition of the user interface. The participants from DMI are now directly doing this work
by themselves—a opportunity that in least partially must be subscribed to the training done
by the participants at DIKU. The definition already done by DMI is described in the working
document [HP99]. A new version of the user interface is already implemented at DMI by
Kasper Bøgh Pedersen.
8.7
Conclusions Regarding Power Prediction
The conclusions that can be drawn so far are:
1. Prototyping: The use of this approach has been successful in at least two ways:
CHAPTER 8. POWER PREDICTION
105
(a) The proof by construction is a very good argument when discussing the technical
aspects of the implementation, architecture etc.
(b) It was a very valuable way of training the person from DMI involved in the project.
2. Training: Training of people from other areas can be of great benefit for the partners.
3. The Java language and platform:
(a) The Java language is suitable as a prototyping language.
(b) The language is simple enough to learn by persons with a technical background
(ship engineer) but without great experience in programming.
(c) The Java platform, in this case in the form of browsers with a Java Virtual Machine
integrated, is a suitable platform for developing distributed applications of this
kind.
4. Browsers: The use of JVM capable Browsers and Java RMI is not without problems:
(a) The tool currently only works with Netscape and MS-Explorer6 .
(b) The amount of work to get the tool running inside MS-Explorer was substantial,
especially the RMI/communication part.
All in all I would qualify this D7D/COT case study to be of great success. The fulfilling of
the D7D vision is gone a step further. DMI has gained experience and a platform to develop
from. The members from DIKU have fulfilled some of the COT goals.
6
The PP tool has not been tested with other browsers.
Chapter 9
Assembly Plan for Grand Blocks
At the initial meetings and discussions at OSS the planning process was described to us, see
section 6.1. A part of the process of making B-plans is to make so-called Building Programs.
Building programs are plans for the individual production sections at the yard. One of the
building programs is an assembly plan for the grand blocks in the dry dock. This work is
currently done by “hand” with paper and pencil. The planning department and the PTA
department (which produces the building program) have a wish to make this process ITsupported. Not only the assembly plan for grand blocks (APGB) is on this list of “wishes”,
but the problem of IT-support for the process of making an APGB was for several reasons
chosen as a good starting point for a case study. This will be further explained throughout
this chapter, which describes the problem, our approach, the work done so far and what
conclusions can be made at this point.
It should be emphasized, that this D7D/COT case study was started later than the PP
prototype so this chapter will be more brief on the subjects of design and implementations—
this case study is still in its development phase.
9.1
The Problem
During the production phase the large sections are brought to the assembly hall in conjunction
with the dry dock. Here the sections are assembled to the largest steel elements constructed
on land to be placed as part of the ship in the dry dock—the so-called grand blocks (GB’s).
The grand blocks are lifted into the dry dock by means of a gantry crane. This is the largest
crane at OSS (can lift up to 800 tonnes) and it is the only crane with capacity to lift grand
blocks. The GB’s are lifted one at a time, transported into the place in the ship where they
are welded to the part of the ship already assembled. The welding of a GB into the ship falls
in two parts. The first part is during the fastening of the GB to the ship. This requires that
the GB is hold by the crane during the welding. The second part of the welding does not
require the use of the crane. This part is to finish the assembling of the GB to the ship. I.e.
after the fastening of a GB the crane can be used to lift the next GB into the dry dock, but
it might e.g. not be possible to fasten this GB to the prior GB because the prior GB might
only be stable enough to hold itself. This means, that the order in which the GB’s are lifted
into the dry dock is constrained by many factors, including the load of the the gantry crane
and the part of the ship already assembled.
106
CHAPTER 9. ASSEMBLY PLAN FOR GRAND BLOCKS
107
The dry dock is the bottleneck at the yard. A dry dock is a very expensive investment,
and at OSS their is only one1 . This means, that the number of ships possible to produce
during a given period of time (say a year) is limited by the time it takes to assemble a ship
in the dry dock. The time it takes to assemble the ship is again limited by the load on the
gantry crane and the time it takes to weld the GB’s together in the dry dock. An important
part of the planning done by PTA is therefore to optimize the assembly order of the GB’s in
the dry dock.
9.1.1
The Process as-is
The subject of this section is to describe the process of making an assembly plan for GB’s
as it is done today. The description will include tasks done in PTA which have influence on
the plan. These tasks together with the assembly plan are done in an iterative manner and
are subject to change during the phase 0 and phase 1 of the overall process—i.e. the plans
made can change a number of times during the design phase of the ship, but this change is
best described as a re-finement. Also included in this description is a rationale for deciding
to start with the assembly plan for GB’s in this case study.
When PTA makes the initial B-plans during the end of phase 0 and the beginning of
phase 1, the following items are in focus:
1. The ship is divided into grand blocks (described in section 6.2.2). This task is very complex and takes place in an iterative fashion together with the Ship Design Department
(41.00).
2. The initial building programs for the individual production sections are made, most
notably the assembly plan for GB’s (other building programs are mostly made during
the end of phase 1 and in phase 2).
3. The calculation of work-hours are begun. This is a task that takes place during all the
three first phases. The task is to estimate how many people should be assigned to a
specific task, e.g. welding in the dry-dock.
The first activity is a very complex task. It requires a high degree of creativity and
knowledge about the product and the manufacturing facilities together with engineering expertise. Therefore, this task is not well-suited for automation. But the task could maybe
be enhanced by tools suitable for better communication. When a decision is considered or
taken, the influence of this should be made aware to others that are dependent on it. One of
the tasks that is dependent of the GB division taken place is the task of making an assembly
plan for GB’s.
The task of making the APGB is at the time of writing done by hand with paper and
pencil. The produced plan shows when a particular GB is to be lifted into the dock, some
of the constraints between the GB’s (a constraint is in this case a dependency between two
blocks, showing that a particular GB is to be placed before another particular GB), crane
time for each GA, work-hours needed to weld the GA and other quantities. The plan made
is fairly simple which requires domain knowledge when reading it—i.e. an interpretation has
to be made. E.g. not all the constraints are shown, but are indirectly present both as domain
knowledge and as the transitive closure of other constraints. One of the objectives with the
1
In fact there are three dry docks but only one of these is large enough to hold new ships.
CHAPTER 9. ASSEMBLY PLAN FOR GRAND BLOCKS
108
plan is to find a critical path. This path is the longest sequence of GB’s where only minimal
“buffers” (extra time inserted between to operations in the dry dock) exits. The plan should
strive for a solution where the number of critical paths are low, where the load on the crane
is distributed equally on the total time for the ship in the dry dock and where the amount
of people needed for welding etc. also is equally distributed. The final APGB is often a refinement of 3–4 plans done in an iterative process, where the knowledge regarding the precise
weight, size etc. about the GB is increased as a result of the first activity described shortly
above. But also during the GB definition the assembly plan is considered, hence the iterative
approach done in the PTA department.
The task of calculating work-hours and equal is mainly done during phase 3. This work
involves the DPS tool described in section 5.2.2. The wish in the PTA department is that
this task can be made more precise at an earlier point than now. We considered this problem
and came to the conclusion that such an approach would require domain models (in this case
product models) at a certain level of precision to be useful. The problem is that in order to
calculate the amount of work to produce a ship the knowledge about the product has to be
fairly large. This is most often not the case in the early phases.
9.2
Objectives
On basis of the above described observations and consideration it was chosen that this case
study should emphasize on the APGB at the beginning. The hope is that if a suitable tool
can be build this tool might be extensible to cover some of the other problems. Most notably
the tool might include a GB definition module where information regarding the GB’s could
be entered and used in the planning part of the tool. At the moment this communication is
done by “paper and mouth”. This has the consequence that the APGB has to be re-done
when important changes are made or when parameters are fixed—this change then requires,
that the changed APGB has to be re-drawn on a new sheet of paper.
The observations done strive for a tool that can help the planner in the process of making
an APGB. The tool should make it possible for the planner to make better decisions by
reducing the time to make an APGB and thus releasing time for creativity. In other words:
it should reduce the trivial time consuming activities and free time for engineering tasks. We
do not consider it possible to build a tool that can find an optimized APGB given a formal
description of GB’s, crane capacity etc. The problem is not to the eventually algorithm for
optimizing the plan—the problem is that we do not consider it possible to make a formal
description that covers the complete problem. The tool should be used for enhancing the
possibilities of evaluating alternative APGB, hopefully also enhance the communication inside
the PTA department and finally maybe later be used when making the initial decomposition
of the ship into GB’s.
The more detailed objectives with this case study is therefore to construct a tool with the
following characteristics:
1. Provide a simple interface for defining grand blocks and assigning parameters to these.
2. Provide a simple interface for defining constraints between grand blocks and assigning
parameters to the constraints.
3. Provide an interface for manipulating the assembly order.
CHAPTER 9. ASSEMBLY PLAN FOR GRAND BLOCKS
109
4. Provide algorithms to answer questions like:
• “Give me a suggestion for the assembly order”
• “How many days are needed in the dry dock if we use X man-hours?”
• “Given this plan, how many extra man-hours are needed to save X days in the dry
dock?”
• “Identify critical days with regard to crane load”
5. Provide means for printing the plan on paper.
6. Provide means for saving a plan for later re-use; both with regard to the particular ship
and with regard to a new ship.
9.3
Development Strategy
The first problem that we had to solve was the development strategy for the tool to-be. Two
immediate observations were done:
1. The person in charge of making the APGB is not trained in defining requirements on a
formal basis. The best he could do (with regard to consideration regarding use of time)
was to explain the process to us and give suggestions of the features he would like to
be able to use.
2. We are not trained in engineering disciplines and are therefore not able to express a
precise set of requirements based on observations and interviews of the planner.
It was therefore chosen to use prototyping as the development strategy. This has to be seen in
conjunction with the general considerations done in chapter 7 and in particular section 7.2.1.
Also the success of this development strategy in the power prediction case study further
encouraged us to chose prototyping for this case study.
The development process takes place on a weekly evaluation of the work done. This is done
in cooperation with the planner, where features implemented are discussed, new features are
proposed and requirements are refined. After this the plan for the following week is discussed
and an agreement is made on the focus for the next phase in the prototyping.
9.4
Design and Implementation Considerations
A number of initial considerations regarding the case study had to be done. These are ranging
the initial capturing of requirements to the choice of implementation platform. These items
are the subjects for this section.
9.4.1
Requirements
The tool has to solve a particular problem in the PTA department. It is therefore necessary
to define at least some initial requirements. These ranges a number of direct requirements expressed by the planner and a number of derived requirements deduced on basis of interviewing
the planner.
The tasks involved can roughly be divided into three categories:
CHAPTER 9. ASSEMBLY PLAN FOR GRAND BLOCKS
110
Domain Modelling and Data Representation: the domain has to be modelled. In a
project involving object technology this is naturally done using an OO approach. The
choice has been made to model the particular problem as close as possible, i.e. elements
identifiable by the planner should be made objects in the tool that the planner directly
can manipulate (e.g. grand blocks and constraints). Other yard specific traditions
should be modelled. As an example of this can be mentioned, that OSS has a tradition
of drawing the assembly plan not only in the “time” direction using the sheet of paper
from left to right, but also the vertical placement of blocks is depicted on the paper
by drawing the blocks at “the right height”. If this approach is established as a good
way of working there is no sense in not modelling this in the tool. On the other hand,
other traditions might be changed. An example of the latter is the shape of the blocks
on the drawing. Currently the planner uses circles of nearly equal size to represent the
blocks. A good idea could be to draw the GB’s as rectangles where the length matches
the sum of the time for lifting (crane time), initial welding to fasten the block and the
time required to finish the welding in order for other blocks to could be fastened to this
one. This modelling can be enhanced by integrating functions for visualizing e.g. the
load on the crane during the whole assembly period. The information is present in the
model (the crane time for each block is to be defined when the block is instantiated)
so a graph of the load could easily be made. This would be “new”—currently the
planner only looks for local problems with overloading of the crane. In this way more
global considerations are possible for the planner. Other domain specific requirements
exists, e.g. regarding the time-line. The planner normally represents the time for a
certain job to be finished in work-hours. The whole period is represented by work-days.
These two quantities are not the same as “real” hours and days. In the category of
data representation the matter of interfacing with other systems also is present. Much
information regarding the blocks are present in other systems (e.g. PMS), mostly in the
last phases where the blocks are completely defined. It could be of great use for the
planner, that relevant information regarding the blocks are imported directly by the
tool when the information is stable/defined.
Algorithms: several algorithmic problems seems to be of interest. The problem of suggesting an optimal solution to the planner could be one. We expect the general problem
to be hard but the number of grand blocks is limited (≈ 100) and there are many
constraints on the sequence of assembling the blocks. Therefore it might be possible
to implement the algorithm with an acceptable performance. The graphical layout on
the screen might be a subject to several problems. The constraints will be drawn as
lines between the blocks, the domain modelling will require constraints on the vertical
positioning of the blocks and therefore the task of reducing the number of overlapping
lines could be interesting. The matter of representing the time also falls in this category
(the problem was described above). It should be straightforward to define a mapping
between the planners use of time and calendar time. The printing of the plan on paper could also be of interest. Here a transformation will have to take place in order
to generate a printable format. The plans are normally done on large sheets of paper
(DIN A3). This gives probably more space for the drawing than used in the tool, and
the horizontal and vertical spacing can change (not necessarily with the same amount).
Therefore an algorithm for printing the plan on paper in an “optimal” fashion could
be of interest. Other problems, like deducing the load on the crane during the whole
CHAPTER 9. ASSEMBLY PLAN FOR GRAND BLOCKS
111
assembly period, should be straightforward to implement.
Human-Computer Interaction: a natural way for the planner to specify blocks and constraints has to be found. Also the manipulation of these with help of the tool has to
be solved in a way naturally to the planner. These subjects are challenging, but the
prototype approach should give a good way of actually making good choices regarding
these problems.
The task of producing a plan is an optimization problem. But it stands not clear what
actually is being optimized. For the yard at all it is of course time and money, but to
map these to the optimization of the variables in the problem of making an APGB is not
straightforward. Several candidates for optimization functions have been identified:
Time in Dry Dock: this is the bottleneck at OSS. If the time used to assemble the ship in
the dry dock is reduced more ships can be manufactured each year.
Man-Hours: the wages are an important factor for the revenue of a ship. For a given ship
it might not be profitable to save a few days by assigning more people, for another ship
it might be the case. This has also to do with the overall assignments on the yard, e.g.
if the days eventually saved could be used for the next ship in line—i.e. the problem
might include considerations not bound to one ship.
The constraints defined by the planner are not necessary strict constraints for the following
reasons:
• They should be regarded as “qualified guesses”. A constraint specifies that a given
block cannot be placed before another block(s). The timing constraints are attached to
blocks, e.g. that a given block needs a certain amount of time after placement before
other blocks can be attached to it. But constraints can also be attached with time
periods used as buffer time if problems occur. The actual time to be used is also
dependent on wether conditions, manpower available etc.
• If the assembly plan turns out to require to much time in the dry dock more resources
(e.g. more welders) can be allocated. However the physical conditions sets a limit on
the assignment of extra resources, e.g. the space inside grand blocks sets a limit on the
number of welders that can work inside the block.
These considerations suggests that the constraints in the tool also are made flexible. This
can be done with floating parameters and exchangeable parameters attached to the object
representing a given constraint, e.g. representing time as intervals (3–4 days), allow values
like 4 days, 3 days with two more welders and maximal 5 extra welders this week.
The blocks defined are more straightforward to model than the constraints. Three main
parameters attached to blocks are given: crane time, fastening time and finishing time. Other
parameters are plan specific: start of lifting time and neighbor blocks.
However, we presume that an automatic produced plan would still be unsuperior to a
well-made plan done “by hand”. The tool must therefore be iterative, e.g. by allowing the
definition of blocks and constraints, using these to make a suggestion of a plan and then
allowing the planner to change the plan suitable for the actual conditions to meet. This would
CHAPTER 9. ASSEMBLY PLAN FOR GRAND BLOCKS
112
then give the planner the opportunity to see the effects of different changes immediately and
thus be superior to the current way of making a plan (directly on paper).
When the planner makes an APGB accumulated knowledge is used. Much of this knowledge would be impossible to specify with e.g. rules, so the tool should allow the planner to
exploit his knowledge in a flexible way. Also, much of the acquired knowledge is based on
experience from previous ships. Therefore means for re-using past plans should be enabled.
This can be done in different ways:
1. By importing an old APGB as template for the new plan. This would be a very simple
task to do. A plan can be saved, renamed and imported into the tool. After this the
changes are straightforward to make.
2. By allowing the planner to define generic templates for plans. This would be the next
step in making re-use of knowledge. The planner would define generic plans, e.g. one
for each main type of ship (container vessel, VLCC etc.), and these plans could then be
imported to the tool and be adapted to the specific plan to be made. It might be the
case that the generic plans had to be defined on a more fine-grained level, e.g. double
hull VLCC at least 300 meters long etc. But the basic idea would be the same. It is up
to the planner at OSS to decide whatever this approach would be superior to the re-use
of specific plans as described above (i.e. worth the trouble of defining generic plans).
3. By allowing blocks from old plans to be imported separately and used as templates for
new blocks. It might be the case that it is not the old plans that are important to reuse but instead old block definitions. Therefore the possibility of saving the individual
blocks for re-use should be considered.
4. By allowing the planner to define generic template blocks. When making the re-use
as fine-grained as individual blocks it might be very feasible to make this approach
more generic. This could be done by defining blocks of a more general kind, e.g. a
basic block in the lowest part of the ship. Then a division of the parameters assigned
to the block would have to be made—those always assigned values on basic of the
generic type and those that should be assigned values when instantiating the block for
a specific plan/ship. This approach also opens the tool for later integration with the
block definition process or maybe as a communication vehicle for the group in charge
of the block devision and the planner so that rapid evaluations of a division could be
investigated with regard to the APGB.
5. By allowing the planner to define general rules for constraints. This case is somewhat
orthogonal to the above described possibilities—some rules for constraints should be
able to be defined independent of the particular plan. The rules that might be possible
to define this way might be the “obvious” cases, e.g.: when a block is placed on top
of another block the bottom most block is to be placed first. If the generic block
approach actually is going to be probed for, then it might also be worth defining generic
constraints between these generic blocks.
Currently we are only working with the first case of re-use. It is up to a later decision
whatever the other approaches should be investigated.
9.4.2
Implementation Platform
The tool will have to be implemented in some kind of programming language. With the
objectives of COT in mind an OO language is obvious. Furthermore, the discussion in
CHAPTER 9. ASSEMBLY PLAN FOR GRAND BLOCKS
113
section 7.2 and especially section 7.2.2 also reviewed the positive experience done by OSS
with the use of object technology as suitable for product modelling. In this case study the
domain has to be modelled—an OO language is therefore also a natural choice with regard
to the experience already established and the needs to be fulfilled.
The prototype language has to be useful for exploiting GUI’s and for modelling the
domain. The positive experiences with Java and the general knowledge about this language
made us choose it as the implementation platform. Java is flexible in terms of defining and
modifying a GUI. Also the number and contents of the library makes it suitable. C++ would
have been another possibility, but we did not consider it flexible enough for prototyping.
9.5
The Prototype
The prototype currently implements the following items:
• Grand blocks can be defined. The definition involves the assignment of the block
number, crane time, fastening time and finishing time.
• Constraints can be defined. This involves giving the constraint an optional name and
defining between which two blocks the constraint is attached and in what direction.
• The blocks can be moved by means of the mouse. The movement is restricted so that
“impossible” placements are rejected.
The block number is exploited in the tool for graphical purpose. This can be done because
OSS has a convention on how the number is to be interpreted regarding where in the ship
the block is going to end.
A screen dump of the graphical user interface of the prototype is shown in figure 9.1.
9.6
Assembly Plans and D7D/COT
The subject of a tool development for helping the planner to make an APGB was chosen as
part of the D7D/COT project which makes an evaluation of this choice and the subject in
relation to both the D7D vision and the COT objectives necessary. This is the subject for
this section.
9.6.1
Building Programs and the D7D Vision
Complete B-plans takes long time to produce, so the 7 days vision cannot include complete
B-plans. But important parts can be done and the important matter is only a “rough”
estimation of the consequences of decisions to make. The decisions in focus here are those
taken when making a block division and their impact on the APGB. This work is already
started in the end of phase 0 or in the beginning of phase 1, so it surely falls into the main
area of the D7D vision. The steps chosen to make the D7D vision real focus among others
on simulation, tactical design and early estimation of consequences. If a tool for making an
APGB could be made in a way where the tool allows a rapid planning process and a better
evaluation of the plan with regard to the overall objectives of the yard it most surely could
be useful in several ways:
CHAPTER 9. ASSEMBLY PLAN FOR GRAND BLOCKS
114
Figure 9.1: Screen Dump for the APGB Planning Prototype
Simulations: The tool could be used to simulate various grand block divisions of the ship
and thus support the process of block division. The term consequence estimation is also
covered by this—the consequences of block division are visualized through simulation.
Tactical Design: If means for defining generic blocks are build into the tool this would
be work on the tactical level. With generic block definition and simulation of various
instances of these the planner and the group responsible for the block division could
achieve knowledge useful for the next series of ships. This work could be done in “quiet”
periods and thus preparing the department for the hectic period where a block division
of a new ship to build has to be made.
It must therefore be concluded that tool support for making the APGB falls into the objectives
of the D7D project.
9.6.2
Building Programs and COT goals
The research goals defined by COT have been described and discussed. A number of these
goals are relevant to review based on the work done so far on this case study:
1. The architecture of object systems: at least the following three subjects defined by
COT are relevant:
(a) Design Rules and Design Patterns: it is stated in the COT objectives, that “...it
is important to emphasize that re-use is interesting on other levels than the level
of code re-use. Also the higher levels a subject to re-use, e.g. re-use of design,
CHAPTER 9. ASSEMBLY PLAN FOR GRAND BLOCKS
115
templates, examples and plans...” [COT97] page 17. This should be covered by
the idea of making re-use of plans and other previous design decisions.
(b) Component Based Systems: as mentioned in other parts of this Thesis OSS is
currently involved in defining and implementing a next-generation CAD system.
This system will be a component based system. The new CAD system is intended
to be enhanced by locally developed yard specific components that are “plugged
in”. A very interesting possibility would be to try to integrate the planning tool
with this new CAD system. The new CAD system will include a product model
and a manufacturing model. These are thought to be organized in a database
fashion, i.e. operations on the model are immediate “known” by other tools. At
the beginning of our development of a planning tool for making APGB a similar
planning tool was on the analysis/design level as a component for the new CAD
system. This project has at the time of writing been cut out of the project. The
block devision is a part of the new CAD system. This makes the following question
interesting: could our tool be “packed” into the chosen component format and
plugged into the new system? If possible how much work is needed to transform
such a yard specific application to the required format and to integrate it?
(c) Open Implementations: we have suggested a number of opportunities for later
development of the tool in other directions. A possibility that seems feasible is
to use the ideas for communication purpose between the planner and the group
making the block devision. This should be considered to fall in the area of open
implementations.
2. IT support for cooperative object oriented software development: this case study is not
in the field of making tools for software development. Nevertheless some similarities are
present between software development and the process at OSS: both are complicated
processes, possible performed by a large number of people in parallel with a need to
exchange decisions. Therefore the IT support for cooperative development processes
done in this case study should be regarded as a COT objective.
3. Introduction of object technologies: only the following topics are of some interest in
this case study:
(a) Introduction of Re-use: the considerations regarding re-use of old plans or by
means of generic definitions of domain objects have been treated above. The next
step would be to actually convince the planner to make use of this. Our approach
is, at this stage, that the needs expressed by the planner have to be fulfilled at
first. He has already suggested the use of old plans in a tool like this—he might
later be interested in exploiting the other options. Therefore this case study also
considers the introduction of re-use.
(b) Scenario Based Prototyping: the same arguments are present in this case study
than in the PP case study. We are doing prototyping which is an objective defined
by COT worth investigating.
9.7
Future Work
The prototype is still in its initial phase and much work still have to be done regarding
completing an acceptable and stable prototype. This will be the main focus area for the work
CHAPTER 9. ASSEMBLY PLAN FOR GRAND BLOCKS
116
in the next phase of this case study.
After this a number of possibilities have already been mentioned:
1.
2.
3.
4.
Enhancing the tool to cover more re-use aspects.
Establishing the tool as a way to communicate decisions.
Interfacing the tool with existing systems at OSS.
Integrate the tool in the new CAD system.
The actual choice made after an acceptable prototype has been developed will be based
on what the needs of the planner and the rest of the department (PTA) is, what the project
leaders find to be of most importance and what research possibilities the different choices
have.
9.8
Conclusions Regarding Assembly Plan for Grand Blocks
The problem of making an assembly plan for the grand blocks is interesting. This comes from
the fact that many possibilities exists in solving the needs of the planner with respect to the
D7D vision and the COT objectives.
The vision of this case study is to solve a particular problem for a specific task, but if
it turns out as a success greater integration is possible: the tool can be enhanced to cover
central aspects of the D7D vision—simulation, tactical design and visualization of decisions.
An enhancement of the tool in these directions would hopefully help the iterative process
done by PTA by establishing better means for communication internally in the department.
Another interesting possibility has emerged: the PTA department has already considered
the ideas present in the tools as very valuable towards other planning problems. The idea is
that the tool is generalized and the objects representing blocks instead are used to represent
activities. This possibility would be very interesting to investigate further and it might be
possible to build a very useful tool for a large part of the work done by the PTA department.
Part V
Conclusion and Future Work
117
Chapter 10
Conclusion
In this Thesis I have studied the D7D vision, the D7D project and the D7D/COT project—
that is, I have studied the concept of Design in 7 Days through a number of descriptions and
analyses:
•
•
•
•
•
•
•
A background description of the D7D/COT project.
A background study of the D7D concept and vision.
A study of the D7D vision.
A study of the organizational frame in which D7D is to be integrated.
A study of the process that is going to be changed by the D7D project.
An analysis of what means should be done in order to fulfill the vision.
An analysis of the two case studies done with regard to both the vision and the COT
objectives.
All the items are nevertheless influenced by one fact—this work is done at the Computer
Science Department which means that all the analyses, descriptions, case studies and conclusions are somehow saturated by this fact. It might not be a negative issue to have a/this
viewpoint when doing a research project like this: a lot of the research projects done at
OSS regarding the D7D vision have been carried out by Engineers—a fresh look at it from a
different viewpoint is in my opinion very valuable for the yard.
Furthermore, I have participated in the fulfillment of the COT goals. This has been done
through a number of activities:
• Training of Kasper Bøgh Pedersen from DMI.
• Presenting the project and results obtained at the EPIC workshop on “software process
developments and new tools” at DELTA (Dansk Elektronik, Lys & Akustik) October
6th, 1998.
• Writing of two COT reports.
• Working on the prototype for the Power Prediction Tool and the Planning Tool for
block assembly.
• Documenting the project by writing this Thesis.
118
CHAPTER 10. CONCLUSION
119
A number of conclusions can be drawn from the work done. Because the Thesis is very
broad in its subjects—ranging from human computer interaction and tool development for
work processes to the description of a vision for the future way of designing ships—the
conclusions are divided on a number of subjects, which are concluded upon in the rest of this
chapter:
•
•
•
•
The Design in 7 Days Vision and Project
System Development
Technology transfer
Design in 7 Days and COT goals
These subjects are interrelated and overlapping conclusions cannot be avoided. The most
important conclusion that can be made are the following four:
1. Technology transfer between universities and private companies is possible with benefits
for all.
2. Evolutionary prototyping is a powerful strategy when requirements are not well-defined
and new ways of supporting an engineering process is to be developed.
3. Object Oriented methods are well-suited for domain modelling.
4. Domain experts and IT experts in cooperation performs a strong team when systems
supporting an engineering process is to be developed.
10.1
The Design in 7 Days Vision
The D7D vision is a radical vision for the future way of designing complex one-off products.
The vision is to reduce the time from idea to a “rough” outline considerably without compromising the knowledge about the product (in fact, still striving for more knowledge than
is the case today).
Concurrent Engineering (CE) is seen as the answer to the problem of reducing the time and
enhancing the estimation of the costs during all the life-cycle phases of a product—the D7D
vision can be seen as the ultimate goal of Concurrent Engineering (CE). The fulfillment of the
vision is to be obtained by Engineering-of-Engineering efforts: a shift is required in the way
work is performed. Domain experts are to model their knowledge in generic product, facility
and method models. These models are the core of the tactical “bereitschaft”—developed
and maintained as part of the work performed on the tactical level. On the operational
level the models are to be instantiated to a specific product with complete manufacturing
plans. This will require a number of integrated systems by which the information in the
models is used to outline the product and manufacturing preparation by a group of domain
experts. The outline is to be completed within 7 days with all major viewpoints covered and
cross-functional issues resolved in enough detail for the rest of the design and manufacturing
preparation tasks to proceed in parallel without committing any further cross-domain costs.
The vision is to be implemented ate OSS which is a large organization. Many different
people are involved in the phases of interest to the D7D project. The organization is structural
divided into product preparation and manufacturing preparation. It is important to know
CHAPTER 10. CONCLUSION
120
about the organization in the context of the D7D/COT project: it helps in the understanding
of overall responsibilities.
The IT tools in use at the time of writing are large in number and broad in type. Many
different formats are used for storing data, and the data “travels” through the system of tools
in various ways. The transformation can be seen as a transformation from a rough product
description to a very detailed manufacturing description. When people are being interview
at OSS regarding their work they typically describes many of the tasks done by means of
the tools they use and what operations are carried through with help of the tools. It is
therefore important to have knowledge about the tools in use in order to improve communication between the participants from DIKU and the people being interviewed or engaged in
a D7D/COT case study.
Important conclusions made during the work with the vision and the related research are:
• Generic models are important to define and implement before the vision can be fulfilled.
• Object Oriented methods are well-suited for domain modelling.
• Prototyping as development process is suitable for requirement capturing and communication with domain experts.
10.2
System Development
The systems to be developed in order for the fulfillment of the D7D vision in the context of
D7D/COT are experimental: requirements are hard to capture and specify, the developers
are not trained engineers, the man-power available is highly limited etc. This resulted in the
following conclusions:
1. Domain experts needs to be an integrated part of the development process.
2. The development process must be iterative and step-wise.
Therefore experimental prototyping is suggested as the best development strategy to use.
The two case studies carried out by the participants from DIKU used prototyping as the
development strategy. The case projects confirmed prototyping as being very well-suited,
and the approach is evaluated as being successful in a number of ways:
• The proof by construction is a very good argument when discussing the technical aspects
of the implementation, architecture etc.
• Requirement capturing is enhanced considerably.
• Communication with domain experts is enhanced considerably.
• It was a very valuable way of training the person from DMI involved in the project.
The Java language and its language environment was chosen as the implementation platform for both the case studies. This makes the language and its environment a good subject
for an evaluation as a prototyping platform:
• The Java language is suitable as a prototyping language.
CHAPTER 10. CONCLUSION
121
• The language environment is important: garbage collection and libraries for graphical
user interfaces are useful features.
• The language is simple enough to learn by persons with a technical background (ship
engineer) but without great experience in programming.
• The Java platform, regarding the Power Prediction case, in the form of browsers with
a Java Virtual Machine integrated, is a suitable platform for developing distributed
applications of the PP tool kind.
10.3
Technology Transfer
A part of the goals for the COT projects are to help the service institutes and the industrial
partners with technology transfer—that is, knowledge about OO technology is to be integrated from the research institutes into the other partners. In this particular COT project
(case 1) the service institute DMI had clarified that one of their main reasons for participating is the technology transfer aspect. The other main reason is the development of the final
PP tool, but the two items are interrelated. The addressed target for DMI is to get enough
knowledge to be able to do the final development largely “in-house” and be able to maintain
all aspects of the final tool by itself.
At the time of project start DMI realized that the required knowledge was not present
(or at least not available for this project). They have at the beginning of the project employed a person (Kasper Bøgh Pedersen) to be in charge of these aspects. This has required
training which was in part done by the participants from DIKU. The outcome of this must
be considered as a success.
The following conclusions can be made regarding technology transfer and training1 :
• Technology transfer between universities and private companies is possible with benefits
for all.
• The participating in prototyping of the system to be developed is a good way of training,
if this approach is combined with more basic exercises.
10.4
COT Goals Revisited
Based on the work done so far the COT goals are now subject for a review. The following
goals defined by COT have been worked with:
• Distributed Objects: the PP tool is clearly a distributed tool. Objects are distributed
among the clients and servers using the Java RMI technology. A considerable amount
of the work done was to ensure that security problems were clarified, and that means
for safe distribution of objects among business competitors were developed.
• Open Implementations: the PP tool is designed to be an open implementation in the
sense, that new database-owners can join the project when wanted. The APGB tool is
also designed with integration later integration in mind.
1
The person trained in this case has a technical background but no programming experience
CHAPTER 10. CONCLUSION
122
• Introduction of Object Technology: DMI has gained experience in OO technology,
mainly through the training of a key person in the development of the tool.
• Maturing through step-wise Introduction: The experiences by DMI with the use of e.g.
Java throughout this project might very well mean that they will consider the use of
OO technology in other areas.
• Scenario Based Prototyping: prototyping was used with success as development strategy
in both case projects.
Chapter 11
Future Work
This Thesis is part of an ongoing research project, therefore some remarks of what future
work might be considered are given.
11.1
Case Projects
The two case projects in progress have a number of interesting possibilities for future work.
This was described with regard to the Power Prediction Tool in section 8.6 and with regard
to the APGB Prototype in section 9.7—here the possibilities are summarized.
Many of the visions for the final PP tools are still to be fulfilled. At the current stage the
further improvement is mostly dependent on work to be done by DMI: suitable mathematical
models have to be developed and databases of test and trial data are to be defined. If this is
done the developed prototype would be subject for revision. The architecture of the prototype
is in most aspects considered suitable for the final tool, but a number of improvements must
be made:
• Cryptography must be implemented for data in transport.
• Browser specific security problems still exists.
• The use of independent mediators must be considered.
• The vision is to make a tool that can suggest design parameters / the lines of the hull
based on very few initial parameters. The user interface to such a tool should be given
considerations.
The APGB prototype is still in its initial phase and much work still have to be done regarding completing an acceptable and stable prototype. When a stable prototype is obtained
a large variety of interesting possibilities are present:
1. Enhancing the tool to cover more reuse aspects.
2. Adding a grand block definition module.
3. Establishing the tool as a way to communicate decisions.
123
CHAPTER 11. FUTURE WORK
124
4. Interfacing the tool with existing systems at OSS.
5. Integrate the tool in the new CAD system.
11.2
Process Descriptions
The process description and analysis in this Thesis is done on two levels: a textual analysis of
the process as-is and mix of textual and graphical description usable to characterize projects.
This work could be enhanced in a number of ways:
• Other possibilities for a graphical description/framework that could be used in the
description of the design process, e.g. Colored Petri Nets.
• A further analysis of tasks, parameters and dependencies: what parameters are dependent on each other, what concrete tasks are present, what are the required input
parameters to these tasks, etc.
This work should result in a framework usable when defining projects—the goal of the
D7D/COT project is to develop systems, and work in the area of process descriptions should
only be done if it helps the process of finding areas where systems are needed and what these
systems should cover.
11.3
D7D and the new CAD System
The new CAD system currently being developed with OSS as participating partner is regarded
as very important by the yard. The new system is component based and the intention is
that yard-specific components are developed. The new system will include various models
(product, facilities etc.) and an in-depth evaluation of the possibilities to use this system as
infrastructure for the D7D vision is needed: is it possible to develop tools for the very early
design phase as part of the D7D project and integrated these tools as components in the new
system. This subject described here is a generalization of the issues discussed in relation with
the APGB discussion: can yard specific applications written in e.g. Java be wrapped into the
required component format and plugged into the new CAD system.
11.4
D7D Architecture
The architecture for the D7D vision is still mostly a conceptual architecture. An in-depth
analysis of the more concrete possibilities would be interesting. The work could take outset
in an analysis of the engineering architectures covered e.g. in [Chr96]. This work should end
up with very concrete recommendations of what systems are needed to fulfill the vision and
how the systems are to be integrated.
CHAPTER 11. FUTURE WORK
11.5
125
COT Goals
The objectives of COT will need further work to be done:
• Reports describing results obtained so far. These should be research reports with clear
focus on one or more of the COT goals worked with and the results obtained.
• Further work regarding the COT goals might take an outset in the case projects and
consider the following items:
– Design Rules and Design Patterns: the APGB tool is at the time of writing already
of considerable size and complexity. Restructuring the tool with a design viewpoint
and further goals to be obtained with this tool in mind might give positive results
towards design rules and design patterns.
– Component Based Systems: a very interesting possibility would be to try to integrate the APGB tool with the new component based CAD system.
– Introduction of Reuse: much work is still needed in order to introduce reuse of e.g.
old plans in the APGB. The work will have to start with an elaboration of what
type of reuse to implement—generic vs. specific, plan level vs. block level, etc.
– Methods to handle Heterogeneous Platforms: in the future version of the Power
Prediction tool a bridge between the server-side and various databases has to be
made. The databases in use will most certainly all be of the relational type, so
this subject will in the future have to be regarded.
Bibliography
[AC98]
Ellen Agerbo and Aino Cornils. How to Preserve the Benefits of Design Patterns.
In Chambers [Cha98], pages 134–143.
[AG96]
Ken Arnold and James Gosling. The Java Programming Language. AddisonWesley Publishing Company, 1996.
http://www.aw.com/cp/arnold-gosling.html.
[AH98]
Allan Thrane Andersen and Ole Høegh Hansen. Teoretiske og praktiske forhold
ved brugen af mønstre, i forbindelse med udvikling af objektorienteret software.
Master’s thesis, Department of Computer Science, University of Copenhagen, December 1998.
[CCD+ 98] Michael Christensen, Andy Crabtree, Christian Heide Damm, Klaus Marius
Hansen, Ole Lehrmann Madsen, Pernille Marqvardsen, Preben Mogensen, Elmer
Sandvad, Lennert Sloth, and Michael Thomsen. The M.A.D. Experience: Multiperspective Application Development in Evolutionary Prototyping. In Jul [Jul98],
pages 13–40. LNCS 1445.
[Cha98]
Craig Chambers, editor. OOPSLA’98—Object-Oriented Programming, Systems,
Languages, and Application, volume 33. ACM/SIGPLAN, Addison-Wesley, October 1998.
[Chr94a]
Kåre Groes Christiansen. Analyse af forretningsgangen på Lindø. Technical report, OSS, February 1994. Bilagsrapport til Erhversforskerprojektet ”Concurrent
Engineering”. Supplement report to [Chr96].
[Chr94b]
Kåre Groes Christiansen. Funktionsanalyse af forretningsgangen på Lindø. Technical report, OSS, August 1994. Bilagsrapport til Erhversforskerprojektet ”Concurrent Engineering”. Supplement report to [Chr96].
[Chr96]
Kåre Groes Christiansen. Concurrent Engineering — A Knowledge Production
Concept for a Shipyard. PhD thesis, Department of Production Management and
Industrial Engineering, Technical University of Denmark (DTU), August 1996.
Advisor: Johan Vesterager, Industrial Ph.D. Project ATV 492.
[COT97]
Center for Objekt Teknologi — COT, March 1997. 60 pages describing the objective with COT
Online information about COT: http://www.cit.dk/COT/.
126
BIBLIOGRAPHY
127
[DF97]
Bo Ensted Danielsen and Torben Siggaard Frederiksen. Den Virtuelle Virksomhed
— Videnintegration. Master’s thesis, Department of Industrial Management and
Engineering (IPV), Technical University of Denmark (DTU), July 1997. Advisor:
Johan Vesterager, IPV Publication number: IPV.97.12-C.
[DMI]
DMI. Danish Maritime Institute Website. Web Pages. General information about
the Danish Maritime Institute.
[FL98]
Morten Frank and Niels Elgaard Larsen. Design in Seven Days—A vision for
the future way of designing highly complex one-of products. Slides, October 1998.
Presentation given at the EPIC workshop on ”software process improvements and
new technologies” at DELTA (Dansk Elektronik, Lys & Akustik) the 6th October
1998.
[FLHF98] Morten Frank, Niels Elgaard Larsen, Kim Henriksen, and Christian Frost. Design in Seven Days — Report 1 — Organization, Process, and IT-support at
OSS. Technical report, DIKU, OSS, DMI, COT, September 1998. First internal
D7D/COT report.
[FLP98]
Morten Frank, Niels Elgaard Larsen, and Kasper Bøgh Pedersen. Design in Seven
Days — Report 2 — The Visions. Technical report, DIKU, OSS, DMI, COT,
November 1998. Second internal D7D/COT report.
[FM96]
Morten Frank and Max Melchior. Java og WWW Services. Technical Report
DIKU-TR-96/38, ISSN 0107-8283, DIKU, 1996.
Online: http://www.diku.dk/research/published/96-38.ps.gz.
[GHJV94] Erich Gamma, Richard Helms, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison Wesley, 1994.
[Hol84]
J. Holtrop. A Statistical Re-Analysis of Resistance and Propulsion Data. International Shipbuilding Progress, 31(363), November 1984.
[HP99]
Kim Henriksen and Kasper Bøgh Pedersen. User Requirements—Speed Prediction. Technical report, DMI, 1999. Working draft, 2nd revision. The DMI and
the OSS requirements regarding the Speed Prediction tool to be developed in CIT
project 74.2—Design in 7 Days.
[HZC]
HZC. Structural design & engineering to be processes. Technical report, OSS.
Description of processes for the engineering of steel structures. Confidential.
[Int95]
International Organisation for Standardisation (ISO). Application Protocol: Ship
Moulded Forms, May 1995. ISO TC184/SC4/WG3 N 394 (T12). Part 216 of ISO
10303. Abstract: This part provides the application protocol for the exchange of
ship hull moulded forms. The geometric shape and the hydrostatic properties of
the hull are in scope.
[JT98]
Eric Jul and Jan Tuxen. Statusrapport CIT 74.2 (1/1–30/6 1998. Technical
report, CIT, September 1998. COT Case 1 Status Report (first half-year).
BIBLIOGRAPHY
128
[JTL99]
Eric Jul, Jan Tuxen, and Niels Elgaard Larsen. Statusrapport CIT 74.2 (1/7–
31/12 1998. Technical report, CIT, January 1999. COT Case 1 Status Report
(second half-year).
[Jul98]
Eric Jul, editor. ECOOP’98—Object-Oriented Programming, Lecture Notes in
Computer Science. Aito, ACM Sigplan, Springer-Verlag, July 1998. LNCS 1445.
[OSSa]
OSS. Odense Steelshipyard Website. Web Pages. General information about
Odense Steel Shipyard Ltd.
[OSSb]
OSS. Skibsudtryk. Danish–English/English–Danish dictionary of maritime and
ship specific terms.
[OSS98]
OSS. Telefonliste for Odense Staalskibsværft A/S, January 1998. Department list
and telephone numbers for the employees at OSS.
[Ped97a]
Kasper Bøgh Pedersen. Program til beregning af effektprognose mm. for et skib på
projektstadiet. Master’s thesis, Technical University of Denmark (DTU), January
1997. Advisor: Poul Wadskjær.
[Ped97b]
Thomas Sandholdt Pedersen. Knowledge integration through feature modelling.
Master’s thesis, Department of Industrial Management and Engineering (IPV),
Technical University of Denmark (DTU), February 1997. Advisor: Johan Vesterager, IPV Publication number: IPV.97.04-C.
[Ped99]
Kasper Bøgh Pedersen. Documentation for the pilot project. DMI, 1999. Short
manual and introduction to the speed prognosis prototype.
[Pol97]
M.A. Polini. Data modeling overview. Technical report, July 1997. Description
of the new CAD system at OSS. Confidential.
[Ris98a]
Claus Risager. Background and objectives. Work in progress, Chapter of Ph.D.
Thesis, 1998.
[Ris98b]
Claus Risager. PROSHIP. Web Pages, May 1998. Copies of PROSHIP Web
Pages, used for description of a number of research projects. The web pages are a
copy of a presentation given by the author the 14th May 1998
Online: http://www.mip.sdu.dk/∼risager/proship/public/index.html.
[Ris98c]
Claus Risager. Ship hull. Work in progress, Chapter of Ph.D. Thesis, 1998.
[Sch94]
Douglas C. Schmidt. The ADAPTIVE Communication Environment. An ObjectOriented Network Programming Toolkit for Developing Communication Software.
Technical report, Department of Computer Science, Washington University, 1994.
Online: http://www.cs.wustl.edu/∼schmidt/SUG-94.ps.gz
Online information on ACE: http://www.cs.wustl.edu/∼schmidt/ACE.html.
[Syy]
Umar Syyid. The Adaptive Communication Environment: ”ACE”—Tutorial.
Hughes Network Systems. 148 pages tutorial on ACE.
Online: http://www.cs.wustl.edu/∼schmidt/PDF/ACE-tutorial.pdf.gz
Online information on ACE: http://www.cs.wustl.edu/∼schmidt/ACE.html.
BIBLIOGRAPHY
[Tux96]
129
Jan Tuxen. Design in 7 days. Technical report, OSS, November 1996. Working
Draft.
Appendix A
Terms and Abbreviations
In this thesis a number of terms and abbreviations are used, and therefore a list of these is presented here. The terms and abbreviations are coherent with those used in [OSSb], [Chr94b],
[DF97] and most of the other references. Others are general terms and abbreviations. I have
divided the list in two, the first is a list of abbreviations with no explanation, the other is
a list of used terminology with explanations. Some of the abbreviations are present in both
lists.
A.1
Abbreviations
AF: Application Framework
AM: Agile Manufacturing
AP: Aft Perpendicular
APGB: Assembly Plan for Grand Blocks
CAD: Computer Aided Design
CAE: Computer Aided Engineering
CAM: Computer Aided Manufacturing
CE: Concurrent Engineering
CIM: Computer Integrated Manufacturing
CIMOSA: CIM Open Systems Architecture
CIT: The Danish National Center for IT Research
CFD: Computational Fluid Dynamics
COT: Center for Object Technology
CR: Residuary Resistance
CRS: Cooperative Research Ships
D7D: Design in 7 Days
D7D/COT: Design in 7 Days/Center for Object Technology
DIKU: Department of Computer Science, University of Copenhagen
DMI: The Danish Maritime Institute
DTI: Danish Technological Institute
130
APPENDIX A. TERMS AND ABBREVIATIONS
131
DTU: Danish Technical University
EoE: Engineering of Engineering
FEU: Forty ft. Equivalent Unit
FP: Forward Perpendicular
GA: General Arrangement
GB: Grand Block
GUI: Graphical User Interface
ICAM: Integrated Computer Aided Manufacturing
IDEF: ICAM Definition
IMO: International Maritime Organisation
ISO: International Standard Organisation
IT: Information Technology
ITTC: International Towing Tank Conference
JVM: Java Virtual Machine
KI: Knowledge Integration
LAN: Local Area Network
MARPOL: MARine POLution
MO: Metode Oplæg
NC: Numerical Controlled
PMM: Planar Motion Mechanism
PP: Power Prediction
PTA: Production Maturing/Production Engineering
DK: Produktionsmodningmodning/Produktionsteknisk afdeling
RMI: Remote Method Invocation
R&D: Research and Development
OO: Object Oriented
OSS: Odense Steel Shipyard Ltd.
DK: Odense Staalskibsværft A/S or Lindø Værftet
SOLAS: Safety Of Life At Sea
STEP: Standard To Exchange Product modeling data
TEU: Twenty ft. Equivalent Unit
UN: United Nations
VE: Virtual Enterprise
VLCC: Very Large Crude Carrier
A.2
Terminology
Aft Perpendicular: The plane defined to be perpendicular to the center symmetry plane
(the vertical plane from the forward to the aft end that divides the ship into starboard
and portside) and where the centerline of the rudderstock is in the plane.
APPENDIX A. TERMS AND ABBREVIATIONS
132
Assembly Network: A network description (more precisely a tree-structure) of the ship
and its devision into grand blocks, blocks, section etc.—ends with leaves consisting of
plates and profiles. This is a manufacturing breakdown of the ship. The assembly
network describes the steel structures, the order of assembly of these, where and what
the assembly consists of (e.g. a specified welding procedure using a specific robot etc.).
Beam-Draft Ratio: The ratio between the beam of the ship and its draft.
Block Coefficient (cB): The ratio between the volume of the ship and a surrounding box.
Normally in the interval 0.6–0.8.
Block Division: A drawing showing the division of the ship into blocks as an outline draft.
(See Assembly Network).
Bulb: The bulb is a bulbous extension of the hull placed on the stem in or below the waterline. The purpose of a bulb is to generate an additional wave system with destructive
interference with some of the other wave systems generated by the hull. Thereby a
more stable motion of the ship is achieved.
Bulb Area Ratio: The ratio between the maximum transverse area of the bulb and the
maximum transverse area of the ship.
Bulb Length Ratio: The ratio between the length of the bulb and the length of the ship.
Class Drawings: The drawings documenting the ship in accordance to the rules from the
class society.
Class Society: A independent company that approves all the details of the ship (e.g. steel
drawings, strength, equipment). A ship is normally approved by a class society in
order to be accepted by the customer, the local maritime authorities and the insurance
company.
Fairing: The final complete specification of the surface of the hull.
Fineness Coefficient: The ratio between the displacement of the ship (volume under water)
and the length to the third power.
Forward Perpendicular: The plane parallel to AP and where the point where the design
waterline intersects with the stem is in the plane.
Froude Number: Dimensionless speed function defined to be: √v , where v is the speed,
g·l
g is the surface gravity and l is the length of the ship.
General Arrangement: The General Arrangement is a number of documents and diagrams
describing the initial physical layout of the ship. It shows the compartments that the
ship is divided into and what type these are, e.g. for cargo, fuel oil, water tanks,
accommodation, engine room.
Grand Block: Grand Blocks (GB’s) are the greatest elements constructed on land to be
assembled in the dry dock. Grand Blocks are large steel constructions which are lifted
into the dry dock with help of the gantry crane. A grand block is a partial finished
block of the ship up to 32m × 20m × 12m and with a weight up to 800 tonnes (the limit
APPENDIX A. TERMS AND ABBREVIATIONS
133
for the gantry crane). Every possible part inside a GB is finished at land. This means
that a GB is a structure consisting of the steel elements with pipes and equipment
installed to the extend possible and with partial painting finished. The GB’s are again
decomposed into smaller blocks in a hierarchical way. (See Assembly Network above)
Hull: A ship hull is in this Thesis defined to be the steel structures, which forms the skeleton
of a ship. The steel structures divides the ship into a number of different types of
compartments and gives the ship its strength [Ris98c].
International Maritime Organisation: An international organization under United Nations giving rules for the safety on board of ships and other international maritime
matters.
International Towing Tank Conference: An international organization of towing tanks,
which e.g. DMI also is a member of. ITTC is e.g. developing standards regarding
nomenclature and computations.
Length-Beam Ratio: The ratio between the length of the ship and the beam.
Length Between Perpendiculars (LPP): The distance between AP and FP.
MARPOL: The “MARine POLlution” are international rules defined by IMO for the Prevention of Pollution from Ships. The rules are extensions of the OILPOL convention
from 1954 covering only oil pollution from ships. In 1973 the rules were extended to
MARPOL and included to cover:
1. Pollution by oil (the original OILPOL)
2. Pollution by noxious liquid substances carried in bulk
3. Pollution by harmful substances carried in packages, portable tanks, freight containers, or road or rail tank wagons, etc.
4. Pollution by sewage from ships
5. Pollution by garbage from ships
Metode Oplæg: The used term at OSS for a detailed drawing showing a block of some
steel structures for use in the workshops. A corresponding English term is not in use at
OSS, and I was not able to invent one. The direct translation is Method Introduction,
but a more descriptive term would be Construction Method Description.
Midship Coefficient (cM): The ratio between the maximum transverse area and the product of the maximum beam and the maximum draught in the design condition.
Prismatic Coefficient (cP): The ratio between cB and cM.
SOLAS: The “Safety Of Life At Sea” are the rules defined by IMO covering aspects like
the number of life rafts given the number of people on board of the ship, the physical
dimensions of escape routes etc.
TEU: Twenty Feet Container Unit. A standardized unit of measurement regarding the
capacity of a container vessel.
Waterline Coefficient (cWP): The ratio between the area of the water plane and the
product of the length and the beam.
Appendix B
Project Schedule during August
1998 to March 1999
This appendix is included to document the subjects of the initial meetings.
The initial phase was begun by August 1998. The intend was that knowledge about OSS
and DMI was captured by us for later use and reference. To ensure a tight coupling between
the participants meetings and discussions were hold once a week at OSS from the beginning
of the project. The initial phase started with 10 meetings at OSS and 1 meeting at DMI. The
goal of this phase was for us to capture knowledge about the domain of interest, in particular:
•
•
•
•
•
•
•
Production facilities at OSS
Production process at OSS
Planning at OSS
Design process at OSS
Experimental facilities at DMI
The type of model experiments done at DMI
The speed prognosis process at DMI
As a further goal was to become acquainted with people at OSS and DMI, so that direct
contact later in the COT project could be done easily.
At OSS 10 initial meetings were held1
August 21st 1998: A half day tour at OSS to inspect the production facilities:
• Plates: storage, surface preparation, nesting, welding of profiles, sorting of plates
and profiles
• Sections: assembly line for large straight sections in the cargo area with 12 welding
robots, feeding system to the assembly line with 4 independent Gantry robots,
assembly line for curved panels with advanced AMROSE robot, assembly line for
large curved sections (front and astern sections)
• Pipes: workshops, equipment, installation
1
Terminology and names of IT-tools etc. are covered in the main part of the Thesis.
134
APPENDIX B. PROJECT SCHEDULE DURING AUGUST 1998 TO MARCH 1999 135
• Painting: halls
• Mounting: hall where the large sections are assembled
• Dry dock: gantry crane, assembly in the dock, equipment quay
After this the production preparation was presented as an overview:
• Job cards, nesting, nesting data, robot programs, CAD, strength, assembly network
• B-plans, time/work calculation, construction method description (in Danish called
“metode oplæg”, see section A.2), construction strategi
• Cell-control and robot programming
• Definition of shell plating, general arrangement, stability, vibrations
• Engine room, electricity, ventilation, equipment
• Economics, ordering and purchasing, IT, automation
August 21st 1998: A presentation by Allan Dinesen: The hierarchical planning process at
OSS, main areas as control means
August 21st 1998: Discussion of the production preparation with focus on the dynamics
of the process and the often counteracting goals in the process
August 27th 1998: A presentation by Thomas Eefsen: NAPA, shell plating, General Arrangement, Stability, Vibration
August 27th 1998: A presentation by Thomas S. Pedersen: “Fonseca´s kitchen table”
September 2nd 1998: A presentation by Kåre G. Christiansen: Steel design, construction
method description, detailed design of steel structures
September 2nd 1998: A presentation by Thomas S. Pedersen: Work contents calculation
and B-plans
September 9th 1998: A presentation by Peter Solgaard: Outfitting
September 9th 1998: A presentation by Hans Jørgen B. Lynggaard: Robot programming,
floor planning in the workshops
A discussion with Allan Dinesen, Hans Erik Sommer and Johnnie B. Rasmussen regarding
their ideas of a tool for automatic production of initial B-plans at an early stage in the
design process.
At DMI a full day tour with the following plan was hold the 31st August 1998:
• Inspection of the experimental facilities:
– Workshops and towing tank
– Wind tunnels
– Simulators
• Meeting and discussion:
– The process of speed prognosis at DMI
– ISESO—maneuver predictions
– Initial discussion of the visions for the speed prognosis tool