customized product definitions can be derived. In our context, the products to be derived from the platformareshipspecifications,oftenwithaserieslengthofonlyone.

Modularization is related to product platforms in terms of being the building blocks from which the productplatformisbuilt.Byadding,removing,replacingorscalingmodules,theproductplatformcanbe targeted towards specific markets or customer requirements. Core research challenges include efficient strategies and methods for determining the subdivision into modules and the number of variants of each, the recombination of these modules into product families of products, and how these are leveraged to target specific market segments and niches. The primary tradeoff in the platform design process is between commonality and distinctiveness (Simpson 2003), or between costcutting and increasingmarketshares(EricssonandErixon1999).

ProductArchitecture
The product architecture describes the structure of a system, in defining the main function and entities ofthesystemandhowthesearerelatedtoeachother.Thus,theproductarchitecturecanbethoughtof asthemoreabstractskeletoninwhichtheconcretemodulescanbeplacedaccordingtogivenrules. Actual representations of product architectures sometimes focus on the functional structure of the product, and sometimes on the physical breakdown and quite often combining these two. To the extent we can consider the SFI system as a generic product architecture for a ship (for which there are manyargumentsagainst),wecanseethatitcontainsamixbetweenshipfunctions(e.g.cargohandling) andshipcomponents(e.g.601MainEngine). The main objective when constructing these system breakdown structures (SBSs), which often are function or systemoriented hierarchies, is that they should be wide enough to include all functions or systems that are relevant in the specific product family. For instance, it would be expected that an SBS for naval ships would highly focus functions related to weapons systems, which will not be the case in commercialships.Typically, companies useone ormoreSBSthatarecustomizedtoadequatelydescribe theproductstheyproduceortheirwayofdesigning,engineering,procuringorproducing. In practical applications, a group system like SFI is often the natural backbone for the product architecture in the specification and early design phases. It defines the boundaries for thetotal scope of the derived platforms, identifying a set of building blocks as well as the relations (typically kindof or partof)betweenthesebuildingblocksinahierarchicalstructure.

7/56

Figure1:TheSFIbreakdownstructure SFI is a hierarchical breakdown structure. The drawback with a hierarchal structure is that one single dimensions need to (or should) be selected for subdividing the system in this case being a partof function breakdown. Alternatively, a heterarchical model can be used, making it possible to capture a morecomplex,multidimensionalsystemstructure. Theproductarchitectureistypicallybasedonafunctionalmodeloftheproduct.OneexampleistheVDI model. Thismodel is thefoundation for a systematic method for design that has been developed by the German design community.Themethod was originally developed byPahlandBeitz (Pahl1984), and has laterbeenadoptedaspartoftheGermannationalstandardforthedesignoftechnicalproducts.

Figure2:IntheVDImodel,thebasicfunctioninalltechnicalsystemsinvolvestheconversionofenergy, material,and/orsignals(Pahl1984) The VDI model offers a problem oriented design strategy, where the emphasis is placed on a detailed problem analysis and a structured procedure to identify a solution. The first step is to identify the main

8/56

 function ofthedesign object fromtheproblem description. The main function is then broken down into a hierarchy of subfunction. All functions are seen as a conversion of energy, material, and/or signal (information),asillustratedinFigure2.Thetransformationfromahierarchyoffunctiontoahierarchyof solution elements is by means of design catalogues, relating elementary functions with alternative physical effect solutions. These solutions are then synthesised into a complete design, and further improvedintheembodimentdesignphase. Thus,thedefinitionofaproductarchitecturebasedonafunctionalmodeloftheproductisanimportant first step in a modularization strategy. There has been some work related to this in Norway some ten years ago, related to the MARINTEK lead project Procurement in the Sales Phase (Innkjp I salgsfasen). In this project, several diagrams were developed for the main systems of the vessel. One exampleofthiscanbeseeninFigure3
Included in main delivery 743 P Exh. syst. for prop. mach. 703.001 Fuel oil system main engine 2 793.001 Autom. equip for main eng 871.001 Main switchboard

15

634.025 Intermed. shaft

601063 ME couplings

601.001 Main engine

731 Starting air h.p. system 10

793 Autom. equip for prop mach

11

12

13

19

637.001 Main reduction gear

713.001 Lub. oil system main engine.

223.001 Main engine foundation

722 Fresh w. cool. syst

14

UMAS Alarm & monit.

18

17

16

634.025 Propeller shaft

667.001 Shaft generator

721 Sea w. cool syst.

Figure3:Systemdiagramforthemainpropulsionsystem,from(Marintek1998) Though these systems diagram was primarily developed to serve as a basis for the specification of procurement packages, they may be used as the architectural backbone for defining modular product platforms for ships. This process would involve the grouping of a set of functional entities as a modular chunk, and the definition of the interface towards other modules based on the various relations between functional units depicted as different types of arrows in the diagram. A more detailed descriptionofthisprojectisgivenlaterinthisreport.

9/56

ConfigurationBasedSystems
We may define a ship design configuration system as: A (software) system that enables a structured definition of a valid design solution from a given set of customer requirements, by applying predefined rulesandtemplatestoselect,scaleandsynthesizeacollectionofmodules(Brathaugetal.2008). Configuration may be described as a particular class of routine design, in which the major design elements modules are known, and that these can be combined into a solution that meets the customerrequirementswithoutinvolvingthedevelopmentofnewsolutionelements.Configurationisin many aspects the opposite of the more common copyandedit approach taken in projects with short leadtimesandonlyalimitedsetofchangesfromexistingprojects.

Figure4:Configurationofamodulebasedplatformasaspecificclassofshortleadtime,routinedesign process In ship design, the application of configurationbased design has been relatively limited, particularly in segments other than lowcomplexity, standardized vessels. Possible causes may be the complexity related to highly customized requirements and the extensive interrelationships between different systems. Further, nontechnical factors may be important, such as the shipbuilding culture for handicraft, and less tradition for longterm thinking. This leads to a focus on the individual projects rather than process improvements. And, compared to many other industries facing a similar complexity level(say, automotive and aviation),thetypical lengthof a seriesinparticularlyEuropeanshipbuilding is short.Thisimpliesfewerprojectstosharethecostsofdevelopingaconfigurableproductplatform. Aproductconfigurationsystemwillcomprisethreemainelements: 1. A design (object) representation. The primary representation will be a collection of modules, combined with parameter sets both on a vessel and on a module level. The parameters will further be divided into those representing customer and functional requirements, and those representing a description of the design solution. The secondary representation contains a 3D model, a textual specification and performance documentation, all which can be derived from theprimaryrepresentation. 10/56

 Further, the initial focus will be a configurator for a nondistributed design team for the internal use by the sales or design department (though the future possibility of external use has been voiced, for the tender invitation development by customers, enabling a better understanding of design opportunities andconsequencesofrequirementsrequirementselucidation). Thecomplexitylevelofaconfiguratorcanbeclassifiedasprimitive,interactiveorautomatic.Aprimitive configurator will mainly provide a predefined structure in which the designer fills out the blanks, resembling a pure templatebased approach. It is useful for providing a structured and quality assured process, but will be too limited in achieving the required level of decision support. In an interactive configurator the human still has a significant role, but with added capacity of checking the validity of decisions, and guiding the configuration process. Automatic configurators further extend this into actually driving the configuration process forward in terms of adding parts and determining parameter values. While this may be applicable for certain subprocesses, it is likely that the general approach still need to be that the human designer will have a central and decisive role also in a configurationbased designprocess. Integration level is an important issue in determining the most efficient path towards a full scale implementation. While it is required that a configurator will need to be tightly integrated towards existing PDM, CAD and TDM applications, previous implementationprojectshaveshowedthathavingto take into account the full complexity level of such solutions will impede the development of the underlying processes, structures (modules) and knowledge base required for a longterm, robust solution. Thus, we believe a standalone frontend is currently a better approach, alternatively an application where the end result is a collection of production type rules that can be imported into existingengineeringsystemstoproducethetenderingdocumentationatanappropriatelevelofdetail. To summarize, modularization and product configuration go handinhand, in terms of configuration defining a process in which the modules defined in the product platform development process are recombinedspecificproductvariantscustomizedtowardstheendcustomer.

LeanManufacturingPrinciples
The underlying principle in Lean Manufacturing is to shorten the production flow by eliminating waste (LikerandLamb2000).Thisparadigmgrewoutofthemassproductionphilosophy,thatbyeconomiesof scalehadleadtosubstantialproductivityincreases,themostprominentbeingthecarindustrywithFord as a frontrunner. The traditional mass production concept thrived in a situation where the industry was able to sell whatever they produced, despite involving batch production that tended to pile up as inventories in the production chain. However, the problems with this approach became more apparent asmoremodelsandvariantswerebeingproducedtoservetheindividualneedsofdifferentcustomers. As a response to this, Toyota started to develop the Lean Manufacturing principles in the 1950s, with the goal of simultaneously achieving high quality, low cost, short lead time and flexibility (Liker and Lamb 2000). This approach was further migrated to the Toyota suppliers, and then to the US in the late 70s. In parallel to this, Japanese shipbuilders adopted lean principles, that together with other similar

13/56

 initiatives such as TQM, JIT and 5S1, helped them have an impressive productivity increase in the whole periodfrom1960to1995. TheconnectionbetweenLeanManufacturingandModularizationisnotobvious,butislikelytocomprise someofthefollowingelements: The relation between short lead time/JIT value chains, and the procurement strategies enabled byapropermodularizedapproach Modularizationstrategysizestosynchproduction? ModularizationopensupforoutsourcinghavingimpactonJITandproductquality Modularity related to product management, while lean thinking is a process management principle

TQM Total Quality Management, JIT Just In Time

14/56

Earlyprocurement (Innkjpisalgsfasen)

Marintek Ulstein

Containextensivematerialrelatedtothe functionalmodelingofcoreshipsystems. Inthisprojectthisismainlyusedtoform thebackboneoftheprocurementplan andthecontentofthespecification packages.Thisislikelytousefulasanaid todefinethemodulararchitectureas partofanmodularizationstrategy Developandtestnewmethodsfor busienssdevelopment,design, production,operationandsalesof modulbasedshipsolutionsfromaglobal collaboratingindustrialresourcenetwork the Utviklerogtesterutnyemetoderfor forretningsutvikling,prosjektering, produksjon,driftogsalgavmodulbaserte skipslsningerfraglobaltsamvirkende industrielleressursnettverkMODNET konseptet

MODNET(2004)

Ulstein Brunvoll Kongsberg DNV m.fl.

Equipment,modularizationandarrangement(1992)
TheprojectEquipment,modularizationandarrangement(Utstyr,modulariseringogarrangement)was a preprojectwithparticipation fromMARINTEK, together withAndersUtkilens Rederi, AukraIndustrier, Barber Ship Management, Wilhelm Wilhelmsen Lines, Kvrner Warnow Werft, Det Norske Veritas, and UNI Storebrand. The purpose of this preproject was to identify those factors being most important for selecting and designing modulebased arrangement solutions. Life cycle cost factors for a chemical tankerandaROROvesselwasusedasabasis. Theconclusionsfromthisprojectcanbesummarizedasfollows: There is no free lunch the benefits of modulebased solutions will need to offset cost increasesinotherareas The lifecycle cost distribution among various types of vessels was fairly similar, indicating that thepotentialsavingsaswellcanbefoundinthesameareas

25/56

 From a ship owners perspective, there are substantial potential benefits if the correct decisions aremadealreadyatthedesignstage The most important cost driver in a life cycle perspective are the machinery systems, and the systemsforcargohandling The recommended focus for a larger main project should be on developing an LCCbased modularization framework for the machinery and cargo handling system, and to develop robust andefficientinterfacesforfoundations,pipingandcabling.

As we can see in the figure below, the incentives are different for the various stakeholders with respect to modularization. While the ship owner is inclined to focus on solutions that are efficient in operation, theyardwillgivepreferencetothosesolutionsthatwillleadtodecreasedtimeorcostinproduction.As aconsequence,thesolutionsspecifiedfromtheshipownerintheoutlinespecification,beingconsidered preferable from a pure operations pointofview, may show up to have a higher lifecycle cost than alternative solutions due to a high realization cost for the yard. Thus, care should be given in the specification process in order to strike a good balance between the multiple stakeholders interest. Alternatively, the yard and ship owner, as well as main systems suppliers, should jointly develop the overalldesignandgeneralarrangement.

Figure17:Differentstakeholdershavedifferentincentivesformodularization(Hagen1998) The project report also summarizes some of the mechanisms that may impede or hinder modularization inshipbuilding.Thisincludes:

26/56

 Technical factors, such as reduced freedom to exactly specify exact performances (but rather select from a limited set of predefined or configurable variants), and reduced freedom to optimizearrangementsuchasplacementandminimizationofpipinglength. Technoeconomical factors, such as increased weight because of standardized foundations, increasedareaandvolumerequirements. Price competition vs. collaboration, i.e. the degree of interaction required to define and develop good modularized solutions may be in conflict with a competitive tendering/souring policy to keeppricesdown Procurement, capital binding, larger system modules may require a larger share of the equipment to be installedat an early stage in the production process (say, complete cabins with furniture).Thismayincreasethefinancecostofthevessel.However,thisislikelytobethesame asforanalternativeearlyoutfittingstrategy. Production, in terms of requiring an increased capability in handling larger modules, and for maintainingopeningsandpassagewaysforaccessandtransport.

Rationalconstruction(1993)
The purpose of the project was to develop methods and tools for increasing the flexibility of product configuration. This resulted in a QFDbased method for improving the product structure and design basedonthegroupingofrequirementsandthecorrespondingmappingtocomponentsandmodules. The method was based on subdivision of the product into functional elements, for which the interfaces were defined for power, mass and signal transfers and interactions. This is illustrated in Figure 17. Transferring these elements and interactions into a diagram (Figure 18), a mapping to physical component can be made.Based onthe interactionsidentfiedhere, anappropriate modular architecture canbefound,asillustratedinFigure19.

27/56

Figure18:Blockdiagramforathrusterunit(BuhaugandLangset1999)

28/56

Figure19:Connectingfunctionalandphysicalelementsforathrustersystem(BuhaugandLangset1999)

Figure20:Identifyingpossiblemodulararchitecturesbyusingthediagramtoidentifyopportunitiesfor splitting,grouping,redesignandusingadapters(BuhaugandLangset1999)

EarlyOutfitting
The focus of this project was primarily on the splitting of the vessel into zones that to a certain extent can be outfitted independently of other zones. The topics covered were mainly Zone oriented 29/56

 production, Outfitting Matrix, Module building work packages, aimed at reduced lead times through standardizationandleanproduction. Designforproductioncoreprinciples 1. 2. 3. 4. 5. 6. 7. Standardisation Interfaceminimization Aggregation Integration Modularization Flexibility CADsystemssupportingearlyoutfittingandmodularization(topologicalblackboxmodeling)

SalesPhaseProcurement(1999)
Theaimofthisprojectwastodeveloparationalmethodologysupportingtheprocurementprocessin shipyards.ThiswasacollaborationprojectbetweenUlsteinYardandMARINTEK.Acoretopicwasthe procurementofprojectcriticalequipment,whereacoherentframeworkforperformancebased specificationswasdeveloped.

402.016 LUBR: EQUIP.

403.012 STO. TANK

875.010 POWER SUPP. 24V

402.007 AXEL BEARING

403.012 EXP. TANK

403.055 CONTROL SYSTEM

401.001 RUDDER

402.001 RUDDER AXEL

403.007 STEERING GEAR

403.060 STARTER

875.010 POWER SUP. Relay box

263 FOUNDATION

Thesespecificationswerebasedonafunctionalmodelingofcoreshipsystems.Theseareusedasa backbonefortheprocurementplan,andforidentifyingthescope,contentandinterfacesofthe individualspecificationpackages.Thus,thisprojectmayprovidevaluableinputtotheprocessofdefining therequiredmodulararchitecturetoserveaglobalsourcingstrategy.

30/56

Figure26:ThenumberofconfigurationelementsbeforeandafterPDMprojectatRollsRoyceDeck Machinery.Source:(Andreassen2005) Similar to the tender specification platform described earlier, primarily covering the needs of yards and shipconsultants,modularizationmaybeusedforefficientlygeneratingcustomspecificproductmanuals forshipequipmentsuppliers.OneexampleofthisisillustratedinFigure26.

43/56

Figure27:Amodularizedshipequipmentcatalogueforderivingcustomizedmanualfromacommon platformofmanualelements(DNVP,2003)

ModularizationinShipDesignProcesses
In ship design and engineering, the application of product platform technologies has been more limited, particularly in segments other than standardized tonnage. Some of the important factors explaining this situation may be the complexity resulting from highly customized requirements and extensive inter relationships between different systems. Further, shipbuilding has a culture for handicraft and less tradition for longterm thinking, with an inherent focus on the individual projects rather than process improvements. And, compared to many other industries facing a similar complexity level (say, automotiveandaviation),thetypicallengthofaseriesinparticularlyEuropeanshipbuildingisshort.This impliesfewerprojectstosharethecostsofdevelopingaconfigurableproductplatform. One of the forerunners in Norway in this technology area has been Ulstein Design. Ulstein Design has developedaproductplatformforoffshoresupplyandservicevessels,andusesthisplatformtoconfigure individual vessels based on customer requirements. Their vision is that the design reflected in the very

44/56

 early specification phase shall be as consistent as possible with the downstream detail engineering, and intheendproduction,withaslittle(re)workaspossible.

Figure28:SelectedproductsintheUlsteinDesignportfolio.Source:UlsteinDesign Andrews (Andrews 2003; Andrews and Pawling 2007; 2009) have during the last twenty years published numerous papers on early ship design methodology, advocating the importance of establishing a model that can be configured in different ways to support the exploration of alternative solutions, as well as providingabasisforunderstandingtheimpactoftheinitialrequirements.

45/56