This page contains a Flash digital edition of a book.
Trans RINA, Vol 152, Part A2, Intl J Maritime Eng, Apr-June 2010 AUTHOR’S RESPONSE


The authors are grateful for the comments by Professor Andrews, who has been a very important voice in the field of broadening the perspective and role of the ship design process. We appreciate the support.


Professor Andrews points out that we, with our focus on ships in a maritime transport system, seem to rule out ships that perform work and represent functions other than transport. This is a good point which could have been mentioned in the paper, but the discussion was omitted due to place constraints. Our aim is to enable any ship to be viewed as integral part in its overall system. Though transport work is a quite easily measured value and as such is well suited for the “extended system” approach, the principle that the design of a ship may influence the design of the system in which the ship is to perform should be universally valid.


He highlights an apparent inconsistency when we on one hand advocate that the ship designer should be free to influence the overall system in which the ship is to exist, at the same time as we in Andrews view endorses the “design spiral” view on ship design. We appreciate the opportunity to make this point clearer.


We actually intended to lead on to a critical view to the design spiral by postulating that “most prevailing models on the cyclic and converging nature of design attempt to defined more or less clearly defined stages…”. Though the design spiral in our view is a practical and pragmatic, and very much pedagogic, description of how design is performed efficiently in a traditional manner, it is nevertheless


risky in the sense that it argues for a


sequential (though converging) orchestration of largely pre-defined activities. It may allude that the requirements are fixed once and for all at the outset. To be sure; our own view is (a) that it must be possible to re-negotiate the starting point at any time in the process and (b) to arrange, perform and revisit tasks upon need, even if this creates instances of divergence in a design process that is designed for convergence.


Professor Andrews notes that it is impossible to represent such complex processes in a flawless manner. We fully agree. Each design and each design process must be viewed for itself. That is also the reason behind our stance as indicated above; we implicitly argue for an ordered chaos; breaking up the rigorous models, allowing for


divergence, allowing for changing The mentioned State of Art Report the on design


premises and allowing for activities to be performed “out of order”.


Design


Methodology presented at IMDC 2009 [27] is an impressive collection of different models/visualizations. Place limits the extent of the discussion here, so we will be to-the-point.


As stated in our paper, we feel most at ease with the design spiral showing constraints. We also see inspiration in the design spiral as presented by Rawson and Tupper, given our comments above and provided we can use the spokes


as “wormholes” – to


rapidly/instantaneously move back and forth (or do entry and re-entry) in the design process.


However, we feel that a new model is needed that reflects the less rigorous approach we advocate, a model that reflects what both we and Andrews state; that it is actually first when we see that job at hand that we can construct a model of the design process. The most important


is


resources and tools are available, a facility to monitor the designs and design decisions as they


to be able to know what (analytical) develop and


mechanisms to make a rapid loop-out, change higher order premises that are affected by lower order decisions, for then to rapidly loop-in and not have to redo all the work! In effect, we would like to see a service oriented architecture of a design process.


We appreciate the kind words of Professor


Papanikolaou and for his insightful comments. We have had the pleasure to meet with both the professor and Ms Ghokari and have also seen the PDT and its capabilities, and fully agree that this could be a valuable contribution and one step towards a more holistic design process as described in our paper.


Similarly, the LOGBASED project and the developed


methodology are well known to us through DNV participation. Whereas we will agree that the chain view is prominent throughout the proposed design process, it does nonetheless retain much of the linear characteristic that we argue should be avoided.


To the specific comments: 1.


The groups of measures identified in the Figure 2 contain


both technical and


operational


measures, as pointed out. What we think is the most interesting aspect of this figure is that it points to a number of quick wins that are both easily implementable and that have a negative marginal cost, i.e. that the Owners will save money. Weather routing is certainly one such quick win, and also one that will not require any changes to the ship design. Trim optimization will both be an operational and a design issue, where the designer should try to balance the drop in hull efficiency for floating conditions offset from the design conditions, and the shipboard management


should optimize the


balance of the vessel accordingly. With the increasing use of CFD tools to complement towing tank tests, there really are no reasons not to include trim/ballast optimisation at design time. Onboard advice may then, on the back of such calculations, be provided through the


© 2010: The Royal Institution of Naval Architects


A - 95


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45  |  Page 46  |  Page 47  |  Page 48  |  Page 49  |  Page 50  |  Page 51  |  Page 52  |  Page 53  |  Page 54  |  Page 55  |  Page 56  |  Page 57  |  Page 58  |  Page 59  |  Page 60  |  Page 61  |  Page 62  |  Page 63  |  Page 64