Ship Product Modeling

R I Whitfield A H B Duffy J Meehan and Z Wu

CAD Centre Department of Design Manufacture and Engineering Management University of Strathclyde Glasgow United Kingdom

This paper is a fundamental review of ship product modeling techniques with a focuson determining the state of the art to identify any shortcomings and propose futuredirections The review addresses ship product data representations product model-ing techniques and integration issues and life phase issues The most significantdevelopment has been the construction of the ship Standard for the Exchange ofProduct Data (STEP) application protocols However difficulty has been observedwith respect to the general uptake of the standards in particular with the applicationto legacy systems often resulting in embellishments to the standards and limiting theability to further exchange the product data The EXPRESS modeling language isincreasingly being superseded by the extensible mark-up language (XML) as amethod to map the STEP data due to its wider support throughout the informationtechnology industry and its more obvious structure and hierarchy The associatedXML files are however larger than those produced using the EXPRESS languageand make further demands on the already considerable storage required for the shipproduct model Seamless integration between legacy applications appears to bedifficult to achieve using the current technologies which often rely on manual inter-action for the translation of files The paper concludes with a discussion of futuredirections that aim to either solve or alleviate these issues

Introduction

THE SHIP DESIGN process typically involves a large number ofdisparate software tools evaluating a variety of characteristics andlife phases (structural operational performance production sched-uling etc) in order to enable the production of a ship design thatsatisfies the customerrsquos requirements The software tools generallyproduce discrete solutions to a particular problem with respect toa set of requirements That is they have their own model andsolution representations (Erikstad amp Fathi 1999) and are rarelyinfluenced by the interactions with other tools As such a largecomplex ship design project may have multiple representations ofdifferent aspects of the same design model distributed either or-ganizationally or more commonly globally Managing the datawithin these models to maintain consistency is an important butcomplicated task

This paper addresses product modeling techniques and systemsthat attempt to address these issues by providing a central store of

(neutrally formatted) data that is common to all of the design andsimulation tools The tools can then access these data add theirown embellishments if required and perform design analysis orsimulation while maintaining consistency with all of the othersoftware tools Because the data are shared among the simulationtools the store of data has often been called the common modelHowever within shipbuilding it is more commonly referred to asthe ship product model

It is generally accepted that each individual life cycle within thedevelopment of the ship product is associated with the productionand management of a large quantity of complicated and interre-lated product data (Polini amp Meland 1997 Catley 1999) The dataoften relate to geometrical topological functional material pro-duction operational and other aspects of the product Within theshipbuilding industry the full life cycle of the product is expectedto last more than 20 years (Wyman et al 1997) and in some casessuch as the naval industry it may be as long as 40 years posingsome important issues with respect to the organization and man-agement of the product model The representation requirementand usage of the ship product model will also vary depending onthe current life phase For example three-dimensional geometricalManuscript received by JSP Committee July 2003 accepted October 2003

data may be used more extensively within the design and produc-tion life phases whereas the bill of materials would be morerelevant to recycling during the disposal life phase

These issues have never before been considered within the ad-vent of digital product modeling techniques because these tech-niques have become prevalent only within the last 10 years or soand have in general been developed and applied only to the pre-commissioning life-cycle stages The structure and definitions forthe data types within the precommissioning stages are becomingincreasingly realized and standardized However little consider-ation has been given regarding the nature of the ship productmodel for the postcommissioning stages such as operation main-tenance refit and disposal and the predesign stages of require-ments analysis and feasibility studies More importantly due tothe duration of the full life cycle of the ship product it is essentialthat the data contained within the product model conform toagreed-upon standards such that support may be maintainedthrough a number of generations of computer architectures oper-ating systems and ship development environments

In a brief review of the state of the art of the product modelingtechnologies Ross and Garcia (1998) identify a number of char-acteristics that advanced product models possess a single inte-grated database graphical user interface with a consistent formattopological relationships among components of the ship designmacros and parametric tools and open structure to allow for dataretrieval to support manufacturing functions This paper discussesthese characteristics and aims to identify important others throughthe review of a number of key reports and papers that generallyfocus on the ship product model

The paper consists of an introduction to ship product data for-mats a review of ship product modeling tools techniques andprojects life-cycle issues and a speculation for future develop-ments for ship product modeling

Ship product data

The effective management of information within a database wasconsidered by Martin (1980) to improve the management of thedesign configuration and to increase the speed and accuracy withwhich design documentation may be produced Models containedwithin the database were created to represent the physical char-acteristics of the product Figure 1 for example represents a sim-plified design model for the structure of the ship

The central component of this model is the structural definitionentity (SDE) which represented either a point a line a surface avolume (or region) a plate part a stiffener or a group of partsInformation derived from other information contained within thedatabase was not stored in order to reduce the size of the databaseOther models were defined based on the SDE to represent pipingand so forth Despite being one of the earliest pieces of work onproduct modeling Martin discussed a number of important char-acteristics of product models that have since been adopted asstandard such as relationships between models to enable thechecking of interferences between geometrical components andstorage of information relating to the drawings that may be af-fected by a change to an SDE to improve design management

The International Standards Organisation (ISO) has for sometime been developing a Standard for the Exchange of Product Data

Nomenclature

AP application protocolARPA Advanced Research Projects

AgencyASE Advanced Shipbuilding EnterpriseCAD computer-aided design

CE concurrent engineeringCORBA common object request brokerage

architectureDARPA Defence Advanced Research

Projects AgencyDFP design for productionEJB Enterprise Java Beans

EMSA European Marine STEPAssociation

ESPRIT European Strategic Programme forResearch and Development inInformation Technology

GOBS geometry object structureGUI graphical user interface

IGES initial graphic exchangespecification

ISO International StandardsOrganisation

JMSA Japan Marine StandardsAssociation

NIAM Nijssen information analysismethod

NIDDESC NavyIndustry Digital Data

Exchange Standards CommitteeOSEB object serialization early bindingPDES product definition exchange

standardSBD simulation-based designSDE structural definition entitySPM Smart Product Modelling

SHIIP Shipbuilding InformationInfrastructure Project

SPARS Shipbuilding Partners andSuppliers

STEP Standard for the Exchange ofProduct Data

XML extensible mark-up language

Fig 1 Simplified structural design model (Martin 1980)

(STEP) STEP is being developed to tackle the issues associatedwith cross-platform and cross-application development of any de-sign artifact through the production of a system-independent rep-resentation of the product data Data types such as geometrytopology functionality cost materials strength and so forth maybe modeled using STEP The STEP application layer contains theneutral data models and the implementation layer contains theactual implementation of these models The EXPRESS data mod-eling language was specifically developed for use within the ap-plication layer STEP has been described as ldquonot only for neutralfile exchange but also as a basis for implementing and sharingproduct databases and archivingrdquo (ISO 1996)

STEP is organized as the following series description methods(10s) implementation methods (20s) conformance testing meth-odology and framework (30s) integrated generic resources (40s)integrated application resources (100s) application protocols(200s) abstract test suites (300s) and application interpreted con-structs (500s)

Established in 1985 the NavyIndustry Digital Data ExchangeStandards Committee (NIDDESC) was involved in defining anactivity model and information models for ship design and con-struction The ISO is continuing this work through the STEP ShipTeam (ISO TC184SC4WG3T23) and has developed a numberof application protocols (APs) to represent various aspects of theship product model (Fig 2) Herzog and Torne (1999) defined anapplication protocol as being ldquoan information and process modelfor an engineering domainrdquo as well as providing additional defi-nitions to the various STEP series

The ship arrangements model (AP215) was developed to sup-port functional and detail design and production engineering life-cycle phases to support damage stability structural analysis in-terference analysis and so forth

The ship molded forms model (AP216) was designed to repre-

sent any geometrical shape for the hull form or internal surfacesthat may be used within the design production and operationlife-cycle phases for hydrodynamic and intact stability analysis

The ship structures model (AP218) defines the structural partsof the ship such as the hull structure superstructure and internalstructures for the predesign design production and inspectionlife-cycle phases The ship structures model has links to AP215and AP216

The ship mechanical systems model (AP226) is used to definemechanical components such as main and auxiliary engines fuelpumps air compressors and so forth AP226 also defines theconnectivity between components geometry materials topologyand operational characteristics for the mechanical components

The electrical design and installation model (AP212) defines theelectrical design and installation information for electrical cablesand harnessing for power transmission distribution generationand so forth The AP has been finalized

The piping and heating ventilation and air conditioning(HVAC) model (AP227) provides the information to support func-tional design detail design production fabrication assembly andtesting of piping heating ventilation and air conditioning TheAP supports pipe flow stress and interference analyses as well asenables configuration management version control change track-ing and the production of a bill of materials The AP has beenfinalized

The European Marine STEP Association (EMSA) the JapanMarine Standards Association (JMSA) and the Korea STEP Cen-tre organization have undertaken additional STEP standardizationwithin the shipbuilding industry For additional information re-garding the STEP shipbuilding APs implementation history andimplementation technology see Grau and Koch (1999)

Wyman et al (1997) stated ldquoShipyards will be required in thefuture to adhere to certain data standards To remain competitive

Fig 2 ISO application protocols for the ship product model

it will become necessary to support international data standardsSTEP is the proposed solution to this data exchange challenge andis the basis for the Advanced Research Projects Agency (ARPA)Maritech project ldquoDevelopment of STEP Ship Model Databaseand Translators for Data Exchange Between Shipyardsrdquo

The ship product was developed within the NEUTRABAS proj-ect (Welsh et al 1992) as a large number of interrelated physicaland abstract object instances that were described and representedusing natural language to describe the context in which the objectsare used graphical Nijssen information analysis method (NIAM)diagrams that illustrate the relationships between the objects (Fig3) and using the EXPRESS information modeling language

Rando (2001) described the use of an XML mapping of STEPinstead of EXPRESS for application-to-application interoperabil-ity Product data sharing was enabled using object serializationearly binding (OSEB) The objective of the standard was to pro-vide a means of serializing (or persistently storing) the state of(ship data) objects contained within an object-oriented databaseinto a neutral format that may be communicated from applicationto application One of the benefits of using XML as the informa-tion syntax is the amount of development of parsing queryingtransformation validation and presentation tools for the supportof the language across all aspects of the information technologyindustry Rando argues that the lack of such development and thereliance on special-purpose tools for STEP is one of the maininhibitors for the wide-scale acceptance of STEP technologywithin small and medium enterprises a point that is also made byRoss and Garcia (1998) OSEB is also geared toward being able torepresent a complex web of a large number of interrelated objectsas a series of more manageable chunks corresponding closely tothe userrsquos conceptual model The technique addresses one of themajor shortcomings related to STEP mapped using EXPRESS thereferences contained within a STEP-EXPRESS file restrictthe deconstruction of the file into more manageable chunks TheOSEB is illustrated within Fig 4 as a layered architectureThe first layer is an object model that defines the stored productdata using either EXPRESS or some other modeling languageThe second is described as the object model of the object inter-faces that are presented to applications The third is the objectmodel that underlies the classes that implement the OSEB ldquowrap-perrdquo The last is the object model that underlies the contents of theOSEB file itself

Finally Rando states that the objective of the OSEB was tominimize complexity and not the size of the XML files XML fileshave an unavoidable concession in that they are not specificallydesigned with compactness in mind due to the necessary inclusionof tags for instance and the lack of a binary format However thefiles are generally more readable and have a more obvious datahierarchy than EXPRESS

As well as developing standards for the mapping between XMLand STEP the Maritech Evolution of STEP (ESTEP) project(Gischner et al 2001) is continuing the development alongsideNIDDESC of the STEP shipbuilding product model standards anddata exchange of the Defence Advances Research Projects Agency(DARPA)Maritech MariSTEP project It is intended that ESTEPwill enable the efficient transfer of data among shipyards designagents and regulatory agencies

Gischner et al state that the current STEP APs take 3 to 5 yearsto develop and a great deal of time has been wasted developingsimilar standards by different industries Figure 5 illustrates theevolution of STEP from individual APs to a plug and play ap-proach through STEP modules

Advancements within both the ship design process and theavailability of cheap and powerful computational resources wereidentified as being the main drivers for the explosion in theamount of data contained within the ship product model (Catley

Fig 3 NIAM diagram of the NEUTRABAS high-level model

(Welsh 1992)

Fig 4 Layered object models in OSEB (Rando 2001)

Fig 5 STEP evolution (Gischner et al 2001)

1999) Catley states that a modern commercial vessel may beexpected to have an associated product data model 2 to 10gigabytes in size depending on its complexity Archiving ver-sion management and a robust product information solution areseen as essential requirements for a competitive shipbuilding in-dustry

Catley also discusses the translation of the AP215 compartmen-tation and AP216 ship molded forms schemas between theTRIBON system and either SEASPRITE or MariSTEP represen-tations Despite an increasing demand for the standardization ofproduct information to enable a common-model representationCatley recognizes the need for openness between specialist sub-contractors and partners in order to achieve common access Fig-ure 6 demonstrates the data flow between KCS and Calypso

Crawford et al (1999) defined a geometry object structure(GOBS) as being organizational to enable the data to be accessedby logical groupings or views topological to define the physicalrelationships between model elements and representational as aresult of the topology The resulting structure enabled both topo-logical views (a view of space not the space itself) and commonviews (compartments machinery spaces)

The development of ship product data formats and structureshas seen a great deal of focus on the ship STEP APs as well asusing EXPRESS and more recently XML as languages to modelthe data The ship STEP APs are clearly required to represent largeamounts of complex data However they also require a concertedand constant effort for finalization to avoid stagnation and toimprove general uptake across the industry These technologiesrely heavily on information technology which is notorious forprogressing more quickly than standards are produced Informa-tion technology considerations are therefore vital in the develop-ment of the data formats and the supporting mechanisms in orderto ensure that the standard does actually ensure the exchange ofproduct data In addition the operational maintenance and de-

commissioning life phases need to be thoroughly supported withinthese data structures

Ship product modeling

Martin (1980) was perhaps one of the first people to discussproduct information systems within shipbuilding and defined theproduct model as ldquoa logically-structured product-oriented data-baserdquo The product model term was however considered by Mar-tin to be a misnomer because the inclusion of nonproduct infor-mation specifically information relating to the yard facility wasconsidered to be one of the most important benefits of the systemThe product model was described as consisting of a number oflogically complete database subsets that contain overlappingstructural and material information for the product (Fig 7)

Martin realized that the product model was not simply a designtool but the information contained within it may be utilized byother yard functions to determine material requirements issuepurchase orders schedule activities and so forth Indeed since theadvent of numerically controlled machines the product model hasbeen viewed as a tool to automate parts of the production process(Johansson 1995 Ross amp Garcia 1998 Ross amp Abal 2001)

During the early 1990s Schmidt et al (1990) explored the fol-lowing options for the format for the product modeling and digitaldata transfer (DDT) within the US Navyrsquos AEGIS destroyerprogram

1 ldquoFlavoredrdquo initial graphic exchange specification (IGES) orstandard IGES ldquoFlavoringrdquo is the term used to define theprocess of augmenting the shortcomings of the implementedstandard in order to adapt it to the required task

2 Deferment until the completion of product definition ex-change standard (PDES) and its commercial implementa-tion

Fig 6 Data communication within Calypso project (Catley 1999)

3 Development of direct translators by a software developerspecializing in computer-aided design (CAD) direct transla-tors

4 Use of a neutral file that defines object data

Option 1 was rejected due to the associated shipyardsrsquo usingobject- rather than entity-oriented CAD software PDES was con-sidered to result with a delay of several years to implement aproduction translator hence option 2 was rejected Flexibility andexpansion were considered as restricting factors for option 3 Fi-nally option 4 was accepted due to the ability to develop a neutralmodel in the available time and the flexibility and future expan-sion of such a model

Schmidt et al also introduced the concept of the ldquodesign win-dowrdquo to transfer only the part of the model that was required ratherthan the entire model by specifying boundaries for the design zoneto be transferred One important aspect related to the transfer ofpartial data was the requirement for effective configuration man-agement such that changes made to the partial models were re-flected within the overall model Higney and Ouilette (1994) fol-lowed up the discussion of Schmidt with a description of a STEP-based product model for the AEGIS destroyer The product modelwas split into two parts a graphical model and a relational data-base containing nongraphical data NIAM diagrams were initiallyused to define the relationships within the relational database Themodel was developed based on the more fully developed STEPpiping AP However other APs were to be included when theybecame available

Welsh et al (1992) focussed on the precommissioning life-cyclestages of the shipbuilding product model while developing aframework to integrate disparate computer-based information sys-tems within the ESPRIT IIndashfunded NEUTRABAS project (Fig 8)The underlying mechanism to achieve this integration was a prod-uct model database to contain and manage neutral shipbuildingdata specifically spatial structural integration outfitting and en-gineering systems data It was identified that the structure of thedata was as important as the data themselves in order to effectively

manage the exchange of the data across various complex andheterogeneous ship development applications

Baum and Ramakrishnan (1997) suggested that associativitydata are extremely useful additions to the product model becausethey enable changes made to any one of the objects within thedatabase to be reflected in all associated objects Baum and Ra-makrishnan however did not suggest how this change propaga-tion is managed because without due coordination the impact ofthe change may result in chaotic behavior in complex systems(Whitfield et al 2000) Additionally there is no discussion regard-ing the requirement to simulate the reflected change using thesimulation software to determine the adequacy of the initialchange

The overall aims of the NEUTRABAS project were defined as

The standardization of the way in which information con-cerning marine-related products is represented

The development of standard methods for the exchangeand storage of product definition data in the marine industry

The specification and development of a suitable databasearchitecture that will facilitate the exchange and storage of suchproduct definition data

The implementation of a prototype data exchange andstorage system based on the previously defined database ar-chitecture which will demonstrate the feasibility of a trulyintegrated product life cycle

The authors identified a number of benefits associated with theabove aims such as the reduction of project time scales throughthe adoption of a single managed information store Managing theinformation within a single database is intended to avoid infor-mation mismatches and hence reduce the amount of rework which

Fig 7 Product information system layout (Martin 1980)

Fig 8 The NEUTRABAS system architecture (Welsh et al 1992)

has indeed been reported within a number of publications How-ever there has never been any consideration of the database con-trol mechanisms required to prevent the database from becomingan information bottleneck despite the assumption that a benefitwould be more effective information management or the in-creased duration associated with searching a single (extremely)large database for the required piece of data despite the assump-tion that a benefit would be rapid information disseminationThere is also the suggestion that using such a representation ofproduct data will avoid the need to transcribe the data betweendifferent application systems eliminating the introduction of errorthrough human interaction However a number of papers havesince reported on the requirement of application interfaces totranslate the product data into a format suitable for the intendedapplication Indeed Rando (2001) reported that in some cases adegree of human interaction has been required to ensure that thisprocess runs smoothly Conversely Catley (1999) suggested thatthe minimization of human interaction within the data exchangeprocess has resulted in more consistent design Finally the authorsidentified the benefit associated with improving the interface be-tween the supplier and the client through the introduction of elec-tronic product definition databases

The NEUTRABAS system was composed of an application-independent EXPRESS model defining the shipbuilding producta data dictionary to manage requests to the database a mappingbetween the model and the dictionary in the form of an EXPRESSimport tool the data management component to enable the cre-ation communication modification and querying of productmodel data a number of application interfaces to enable the in-dividual applications to interact with the database a number ofdatabase interfaces to enable communication between specific da-tabase management systems and the NEUTRABAS database anda database generator that enables the mapping of data within aspecific database to the data within the NEUTRABAS database

Von Haartman et al (1994) described the ship product modelwithin the NAPA project and realized the potential of the productmodel as a basis for concurrent engineering (CE) The use ofcomputers within the shipbuilding industry was previously re-stricted to the computationally intensive applications such as thecalculation of hydrostatics and stability These applications havehad a great deal of development to produce tools that represent andmodel a particular characteristic of the design quite accuratelyThey have generally received a great deal of investment of timeand money (Crawford et al 1999) Von Haartman et al suggest thatthe modern ship design process should ideally consist of a singlesystem that augments all of the disparate design tools but that oneshould recognize that such a system is far from reality The alter-native was to provide a framework to interlink these design toolsto give the impression of a single system The ship product modelwas the key to interlinking these tools

Von Haartman et al also stated ldquoAny model merely reflectsselected properties of the object it is intended to describe and theappropriate selection of properties is of central importance whendesigning the modelrdquo Within the NAPA ship product modelglobal properties of the ship were identified such as the maindimensions hull form and so forth and although not explicitlystated it is assumed that these global properties were chosenpartly for the reason that they are common among the design toolsbeing utilized These properties within the model may also be usedto evaluate the economic and technical requirements of the ship

Finally Von Haartman et al stated that the lack of detail of theglobal properties within the ship product model is not synonymouswith inaccuracy

Johansson (1995) described the challenge of modern shipbuild-ing as ldquoto manage and control the design and assembly process togain efficiency and short delivery timesrdquo By summarizing theshipbuilding process life-cycle stages as tendering design pro-duction planning materials finance and follow-up the require-ment for the effective management of the extremely large amountsof information was established in order to ensure the efficientorganization of the shipbuilding process Johansson suggested thatthis requirement could be satisfied only through the developmentof ldquoan information flow solution specifically designed for thisindustryrdquo and suggested that it was not sufficient just to automateexisting manual activities Rather the organization should beadapted to the use of new tools to streamline the information flowwherever possible The discussion appeared however to be re-stricted to information flows within a single shipbuilding organi-zation with the main focus on how the information may be utilizedto improve the production process

The product model concept was regarded by Johansson as beingone such tool whereby the organization may be streamlinedthroughout the precommissioning stages by providing a consis-tent model to enable well thought-out build strategies to be de-veloped early ordering of materials and material handling pre-fabrication preoutfitting and the use of numerically controlledmachines

Additional information was contained within the productmodel such as material codes weights surface treatments and soforth For this reason Johansson suggested that a more appropriateterm may be product information model because the modelshould contain all technical product definition data and may beused to provide for example graphical representations of geom-etry as well as lists and reports of material requirements Addi-tionally Johansson stated that the generation of a graphical rep-resentation should be produced only when it is required and to theextent that is suitable in order to avoid unnecessary computationThe graphical representation is regarded as secondary informationof the (primary) information stored in the product model Theinformation flow may be streamlined by the manipulation of theprimary information rather than the secondary information

Johansson also recognized that it was important that ldquoa productmodel based system must understand what the different parts ofthe system really represent and be able to interpret the rules andrestrictions connected to each type of objectrdquo

Erikstad and Fathi (1999) described how a STEP-based shipproduct model could be used within the ShipX project for theintegration of the data within a number of hydrodynamic analysisapplications for a ship The applications were previously devel-oped as stand-alone applications to specific aspects of the hydro-dynamic performance of the ship such as propulsion and seakeeping Previous integration among the applications wasachieved through the development of translators to allow for theexchange of information However the technique was difficult toimplement and maintain and was not considered to be seamlessThe communication of information among applications is clearlya central issue that has been discussed in a number of reports(Wyman et al 1997 Gischner et al 2001) Essentially the optionsare either to develop a direct interface between every pair ofcomponents or develop the interfaces based on a consistent inter-

face standard A common product model (Fig 9) was imple-mented within ShipX and from the application developmentviewpoint it enabled

Developers to concentrate more on the specific simulationproblem rather than the modeling of the data This benefit isrealized every time a particular application goes through rede-velopment or when new applications are developed

Guaranteed synchronization of data between the applica-tions and the product model Translators were previously usedto convert the product data to and from the required formats foreach application Changes could potentially be made to theproduct model after data translation to the application resultingin a discrepancy in the translated data The product modeltechnique ensures that each application has a common repre-sentation of the ship

Reuse of previous applications and graphical user inter-faces eliminating the need for the end user to relearn how touse the application

Despite integrating existing applications with the productmodel it is not clear within the ShipX project whether integrationexisted between applications For example two discrete applica-tions may be considered as damage stability assessment andevacuation simulation both integrated via the product model It ispossible to make assessments of the performance of the ship withrespect to both the damage stability and the evacuation in isola-tion via the integration with the product model However inte-gration is required between the damage stability and evacuationapplications in order to assess the evacuation time while compart-ments are flooding

The ShipX product model was developed using the relevantshipbuilding protocols developed within STEP which were imple-mented into a class library and stored using an object-orienteddatabase

Erikstad gave a number of useful guidelines for the develop-ment of the ShipX system

Simplicity The development of a comprehensive productmodel tool was considered to be prohibitive both from theaspects of timeliness and cost effectiveness Wherever pos-sible commercial off-the-shelf components were used Thedevelopment of the actual product model was undertaken usingthe STEP shipbuilding protocols rather than developing anin-house product model from scratch

Flexibility and extensibility The model was initially lim-ited to representing data that were specific to hydrodynamicperformance However consideration was given to the struc-ture of the model such that it could be extended to representother performance aspects Also the use of STEP to producethe common product model enables the scope of ShipX to beextended without restructuring the model The facade designpattern was also used to hide the complexity of the productmodel from the client applications define the correct usage ofthe product model by the client applications and enable theupdating of the product model without affecting the client ap-plications

Weak bindings to platform and programming language toenable the cross-platform and cross-language integration of theproduct model

Baum and Ramakrishnan (1997) regarded three-dimensionalproduct model technology as being fundamental for the imple-mentation of concurrent engineering (CE) within shipbuilding dueto the ability to develop capture represent integrate and coor-dinate data and permit simultaneous access to a number of usersBaum defined the product model as ldquothe integration of the 3Dgeometric model and non-geometric database informationrdquo whichmay be a logical integration of distributed information (Fig 10)

Simulation and interaction with the objects within the productmodel through the introduction of anthropomorphic models into avirtual environment to test functionality and operability were dis-cussed as being a useful technique to test the validity of the modelin a way similar to what would be achieved with the final productThe resulting model is essentially an electronic ldquomock-uprdquo Baumsuggested therefore that it is important to also represent the nor-mal behavior of the objects within the ship product model suchthat their behavior may also be analyzed enabling the product tobe designed manipulated analyzed constructed tested operatedsupported and disposed of in a virtual environment

Ross and Garcia (1998) and Ross and Abal (2001) discussed theutilization of product modeling technologies within two differentshipyard applications new build and conversion with the focus ofaiding shipyard managers with the decision to adopt such tech-nologies Ross suggests that the key characteristic of the productmodel for achieving a high level of integration is the adoption ofa single database allowing a number of designers to simulta-neously work on the same design through effective database man-agement and reducing or preventing altogether the inconsistency

Fig 9 From data translators to data integration within the ShipX project (Erikstad amp Fathi 1999)

of information A number of small shipyards that have incorpo-rated product-modeling technologies are used as case studies todiscuss the techniquersquos effectiveness with the conclusions thatthese shipyards have an improved production quality and signifi-cant savings in material cost labor cost construction cost andlabor hours Despite being a more complex representation thantraditional techniques Ross and Abal (2001) concluded that stafftraining was straightforward and that staff were considered com-petent after the design of the first vessel

Polini and Meland (1997) discussed the extension of a prototypeproduct modeling system through to the development of a pro-duction implementation that was capable of supporting concur-rent multiuser access Life-cycle data and behavior were modeledwithin the classes contained in the Smart Product Modelling(SPM) system The differentiation between a standard productmodel and an SPM system is shown in Fig 11 To appreciate theamount of effort involved in developing the SPM Polini andMeland state ldquoTo date nearly 45 man-years of software devel-opment have been invested in the SPM and its GUI approxi-mately 1000 classes with over 30000 methods have been devel-oped object oriented databases on the order of 25 gigabytes arecommonplace 24 concurrent users have modeled five shipclasses and tens of thousands of structural parts have been manu-facturedrdquo

This development was undertaken entirely within a shipyardwithout any commercial input Polini and Meland justified thisdevelopment by surveying the requirements of the shipyard andconcluding that there were no commercially available systemscapable of dealing with the degrees of specialization within theshipbuilding industry a point that has also been made by Jo-hansson (1995)

One of the questions asked by Shin and Han (1998) and others(Baum amp Ramakrishnan 1997) is whether it is possible to imple-ment paperless design because designers often spend a great dealof time trying to extract useful information from two-dimensionalpaper drawings The shipbuilding building blocks within the STEPshipbuilding APs were used as the basis to produce a ship product

model Shin used the STEP toolkit ST-Developer to produce C++classes using the EXPRESS data definition language for the mid-ship section of a bulk carrier

The classes were enhanced to enable all life-cycle product in-formation to be stored within a single data structure as well as fortranslating data formats by one-to-one mapping and includingexplicit information (Youngrsquos modulus Poissonrsquos ratio) from de-sign conventions available within the product model The systemarchitecture can be seen in Fig 12 This enhancement was re-quired because Shin suggested that it was not sufficient to simplytranslate data from a neutral format into the format required byeach application Rather it is a requirement of each applicationthat associated functions and information specific to each appli-cation is also incorporated into the model

This requirement for functional data was also discussed byCrawford et al (1999) Rather than relying on a flat neutral file tocontain geometry and topology information it was considereduseful that the topological data for example were provided withsome sort of intelligence to facilitate the translation between ap-plications The STEP standards were adhered to wherever pos-sible However achieving intelligent topology required extensionof the standards Crawford defined the Newport News Shipbuild-ing view of a product model as ldquoan all encompassing model of a

Fig 11 Product model definitions (Polini amp Meland 1997)

Fig 10 Representation of a ship three-dimensional product model (Baum amp Ramakrishnan 1997)

ship project taking advantage of the available computer toolsfor describing the geometry of a ship but it also includes allattributes necessary for the design production and operation ofthe shiprdquo

Again it was considered unlikely that the ship could be definedby a single computer system rather than by a number of moremanageable systems grouped according to some arbitrarily de-fined domains (Fig 13)

Crawford demonstrated the use of intelligent topological andgeometric STEP-based data through the use of the GOBS commonobject request brokerage architecture (CORBA) server that pro-vides a number of methods to enable legacy tools to extract therequired data Two analysis tools were used to model the ship

vulnerability and hydrostatics which obtained their data from theGOBS server The analysis concluded that within the majority ofthe cases the STEP standard for geometric data (Part 42) wassufficient to represent the geometry for the ship

Rando and Fernholz (2000) describes how the DARPA Mar-itech Shipbuilding Information Infrastructure Project (SHIIP) andShipbuilding Partners and Suppliers (SPARS) projects used acombination of component-based software internet protocols anda portable computing platform to satisfy the following shipbuild-ing information technical requirements

An information technology gap separates the large me-dium and small shipyards

Fig 12 System architecture of the STEP manager (Reprinted from Shin amp Han 1998 with permission from Elsevier)

The information technology staffs at most shipyards areexperts in shipbuilding process requirements but not in system-level computer technologies

Shipyard information systems must be reliable and main-tainable yet often need to be customized to suit an individualshipyard

As with many other projects (Rando 2001 Gischner et al 2001)integration within the shipbuilding industry was considered pos-sible only by the reuse of existing software components becausethe number of shipbuilding system requirements is so diverse thatit is unrealistic to assume that it is possible to produce a singleoverarching solution The integrated system was considered toconsist of a number of independent components to be assembledand reused by third parties in order to create a new complexsystem The initial task of the SHIIP project was to define areference architecture to support the composition of the indepen-dent components

The management of the product data was achieved using En-terprise Java Beans (EJB) that enable persistent storage secureaccess and load balancing for multiple users wishing to access thedata simultaneously At the start of the SHIIP project however

EJB was not available and the project relied instead on CORBAtechnology The project learned the following lessons from usingCORBA

Technology independence although useful in theoryshould not be pursued at the expense of developing workingimplementations

Technical interoperability is not a requirement for the de-velopment of an industrial information infrastructure Support-ing applications and software components for the informationinfrastructure are homogeneous enough to be implemented in asingle implementation technology

The Object Management Group (OMG) while advocatingseparation of components has produced in the arena of do-main standards wrappers for monolithic applications

OMG has been hampered by the inability to reach timelyconsensus

The Integrated Shipbuilding Environment (ISE) project withinthe Maritech Advanced Shipbuilding Enterprise (ASE) is usingXML as the basis for achieving interoperability between ship-building systems technologies specifically between application toapplication (Rando 2001) Rando differentiates this problem fromthat of other industries by stating that many of the applicationcomponents used within the shipbuilding industry have alreadybeen developed as well as the having little control over the de-velopment of these systems The shipbuilding product model mayalso contain millions of instances of a large number of differenttypes of information that need to be managed as they evolve overthe productrsquos life cycle It is also suggested that not only is therea need to rely on an enterprise system that augments the manyspecialist applications but due to the diversity of informationwithin the life cycle of the ship no single information system issufficient to deal with the entire ship product Indeed previousalliances between shipyards have been one-off solutions and thereis a definite requirement for a standardized effort for the shipproduct model

Rando identified a number of business drivers in order toachieve interoperability within the shipbuilding industry and pro-

Fig 13 Domain-based ship system (Crawford et al 1999)

Fig 14 ISE reference architecture three levels of interoperability (Rando 2001)

posed an architecture in order to respond to these drivers (Fig 14)The architecture represents three interoperability levels within theshipbuilding environment intercomponent refers to the interac-tions between the software components within a system intersys-tem refers to the interactions between the systems and is boundedby a business system domain and interenterprise interoperabilityrefers to interactions between business systems domains at differ-ent shipyards and organizations

The key elements for achieving this interoperability were acommon syntax using XML to facilitate communication a sharedstandard information model using STEP and an interoperabilityinfrastructure using web-based technologies XML is a neutralformat that may be viewed by humans (although this is not gen-erally a primary requirement) and that enables the sharing of in-formation between different technologies different operating sys-tems and different programming languages Five keyrequirements were identif ied to facilitate application-to-application integration

Should ldquoreuserdquo widely available standards-based tools Should be implementable with tools that allow for recon-

figuration by nonprogrammers Should support transformation to and from a canonical or

neutral format Should utilize a representation that is as simple and con-

cise as possible Should be able to marshalunmarshal every semantic con-

cept representable in the EXPRESS information modeling lan-guage (ISO 10303-11)

One of the most significant issues relating to the use and inte-gration of ship product models with existing applications appearsto be the need to ldquoflavorrdquo the model and specifications to suit theparticular requirements of the design and simulation applicationsWithout these embellishments the fully automated data integra-tion appears quite often difficult to achieve There are howeverconflicting opinions regarding the effectiveness of automating thisprocess generally arising due to the complexity of the problem andthe level of support The application of ldquoflavoredrdquo standards doeshowever entirely go against the point of creating a standard es-pecially when it is with respect to the transfer of product data Itcould therefore be concluded that the solution to the effectiveintegration of STEP lies not in the modification of a new tech-nology to satisfy the requirements of legacy applications but inthe updating of the legacy applications to satisfy the new technol-ogy

Life-cycle issues

The NEUTRABAS project (Welsh et al 1992) was limited tothe precommissioning stages that is marketing conceptual de-sign detailed design drafting materials ordering productionplanning and control scheduling and quality control However itwas recognized that significant benefits would be achievedthrough extending the life cycle through to disposal Welsh et alqualified the limitation to the precommissioning stages by statingthat ldquothe definition and implementation of a complete product datamodel covering all of these aspects of the life-cycle of an engi-neering product as complex as a ship is an onerous task and one

which would require the commitment of a vast amount of time andeffortrdquo

Limiting the project to the precommissioning stages would ap-pear to have been a wise judgment because in the 10 years fol-lowing this project the standards created to describe the shipproduct model have still not yet been finalized

Welsh et al suggest that the physical representation of the prod-uct within each life cycle stage would ldquonormally be unchanged inthe global sense although the information associated with theproduct and the techniques used to represent it will vary consid-erablyrdquo that is the information contained within the productmodel would mature as more detail becomes available as well asrequiring different viewpoints at each life-cycle stage The productmodel must therefore be developed not only with the associateddata and structure in mind but also with the life-cycle stages Toenable the support of the precommissioning life-cycle stagesWelsh et al identified four views that need to be supported by theship product model

Marketing-oriented view Management-oriented view Design-oriented view Production-oriented view

Von Haartman et al (1994) briefly discussed life phase issues ofthe ship product model and suggested that a number of systemsmodel the design with too much detail and hence are not appli-cable to the concept design stage A solution to this was thedevelopment of a concept design product model that could then betransferred to the detailed design stage It is not clear from thiswhether Von Haartman et al were proposing separate models forthe two stages or if the detail product model would simply consistof the concept product model plus the additional required detail

The mechanism of having multiple different views for the shar-ing of a product model among designers and production engineersfor example has been considered and implemented in a number ofcases (Polini amp Meland 1997 Johansson 1995) Johansson indi-cated that it is common for parts of the product to be in differentlife-cycle stages at the same time that is the ldquomanufacture of onepart of the product is going on at the same time as the detaileddesign of anotherrdquo This is one aspect of concurrent engineeringwith the result of reducing the lead times because the manufactureof the product has started before the design of the product has beencompleted However it is necessary to ensure both that manufac-turing starts only on parts that require no further design and thatother parts that are currently being designed do not propagatechanges to the manufactured parts The management and controlof the information flow were recognized as being the key elementsin increasing the overlapping of life cycles However no expla-nation was given by Johansson regarding the nature of the man-agement other than through the relationships between the objectscontained within the model These relationships were described asa mechanism to enable both interdisciplinary and cross-disciplinary communication among designers

The three-dimensional product model was described by Baumand Ramakrishnan (1997) as being a mechanism to enable a num-ber of different life-cycle stage simulations such as interferencechecking crew traffic flow studies yard-specific designs and fi-nite capacity scheduling through the use of a virtual environmentdesign review technology using data contained within the productmodel (Fig 15)

Coupled with simulation-based design (SBD) Baum describedthe combined technology as ldquothe new frontierrdquo that would enablethe virtual prototyping of the ship which previously could not beachieved due to the cost and complexity More importantly Baumrecognized that just as interference-checking software may beused to determine discrepancies between geometric parts duringthe design and production phases SBD may be used to reduce oreliminate design errors that would have previously have beendiscovered years later in the operational stage for example Es-sentially SBD and product modeling enable the validation of thedesign production and operation stages of the ship product

Baum also finally suggested that the product model provides asignificant benefit to the owneroperator by enabling the analysisand support of life-cycle maintenance

A generic shipyard computer modeling tool for evaluating de-sign for production (DFP) is discussed by Lamb et al (2000) Thetool enables shipyards to be modeled such that the impacts ofchanges to the ship design may be determined on the basis of theresulting material manpower and schedule The shipyard modelrepresents details of the buildingsmdashtheir arrangement and size aswell as equipment capacity and flow The tool also enables aninvestigation of the necessary changes required for a shipyard inorder to produce a new design The key foundations in order toevaluate these impacts are the interim product catalogue and thebuild strategy approach

Lamb et al identified a number of important concepts for DFP

All designs should be prepared to suit a shipyardrsquos facili-ties and preferred production methods

DFP takes into account production methods and tech-niques that reduce the product work content but still meet thespecified design requirements and quality

DFP must be incorporated into a design from the start Traditional engineering leaves it up to another department

such as production or manufacturing engineering to developthe technical documentation required for the production work-ers This is an unnecessary duplication of effort and is a nonndashvalue-added task that takes time

An objective of the CE approach is to accommodate DFPby bringing all the necessary people together right from dayone on a project

The time to influence the cost of a product is during theearly stages After the design has been developed in conceptmost of the opportunity to positively affect cost is gone

World-class ship designers know how their shipyardbuilds ships and design accordingly Many ship designers donot consider this and the designs may or may not be efficientlybuilt in their facilities More shipbuilders have taken steps toremedy this situation through the use of the build strategyapproach

Engineering should be prepared and transmitted to theusers in a way that best suits block construction advanced andzone outfitting

An object-oriented approach was adopted for the constructionof the model (Fig 16) The model represents shipyards worksta-tions products equipment processes manufacturing processesmaterial handling processes and interim products The tool wasapplied to the evaluation of two design alternatives for the bottomstructure of a ship The authors demonstrated that the tool enabledreliable evaluations of the man-hours for manufacturing and ma-terial handling such that the best design alternative could beadopted

Future directions

It is believed that the ship STEP APs will become the standardunit of shipbuilding data but that it will probably be an evolution-ary process as advances in technology and modeling capabilitiesand requirements are incorporated It is however crucial that thedevelopment of the standards comes to a timely consensus at eachevolutionary stage The literature reviewed has discussed the useof ldquointelligentrdquo data the inclusion of useful functionality accord-ing to the data type and of behavioral aspects It is anticipated thatthis functionality behavioral aspects and so forth will increas-

Fig 15 Ship design workflow using three-dimensional product model (Baum amp Ramakrishnan 1997)

ingly become part of the model to the extent that the model nolonger has any need for interfaces and translators to legacy soft-ware For example the piping model would automatically calcu-late interferences and the structures model would automaticallycalculate stress characteristics The simulation would essentiallybe part of the model and the model would contain additionalinformation and knowledge to effectively manage the simulationThis is not to say that the model would become a monolithicsystem despite such a system being potentially computationallyviable in 10 years Rather than being monolithic current andfuture distributed information technologies such as EnterpriseJava Beans may be utilized in order to distribute the model acrossa network while giving the impression to the user that the systemis monolithic Ship product data and functionality would be dis-tributed either within a single company or as partnerships withother companies

In a similar way that the ship product data has become stan-dardized benefits are to be gained from standardizing the inter-faces between applications to support the flow of standardizeddata and achieve a truly seamless integration The unfortunateshortcoming of application standardization is the necessity to re-develop the legacy systems to support this level of integration

The VRShips project addresses the management of ship productdata within a neutrally formatted common model The geometry

data contained within the common model are based on STEPAP203 are described using XML and are considered as beingcommon data if two or more applications access it Integration isprovided between the legacy applications and the common modelvia ldquogeneric wrappersrdquo that provide the general management re-quired in order to operate the applications The wrappers convertthe data to and from the native format using modular conversionalgorithms that can be plugged into the wrappers and provide thedomain-specific management for the applications Data are auto-matically downloaded from the common model and converted intothe native format when the application is started When the appli-cation is complete the designer has the option of undertaking thereverse process to convert the data back into the neutral format andupload into the common model Despite being a complex processconverters have been produced for a number of design applica-tions such as Tribon and AVPro and have been demonstrated tooperate without the need for manual interaction However theissues relating to the lack of integration between tools and con-tinuous product models remain to be addressed

The VRShips system also has an additional management layerconsisting of a process controller and an inference engine that arejointly responsible for maintaining data consistency and versionconstraint and process management Visualizing of product datavia the legacy applications is managed through the exporting of

Fig 16 Object diagram for generic shipyard computer model (Lamb et al 2000)

the displays via a virtual interaction environment These controlmechanisms ensure that designers may modify the data containedwithin the common model from any location either organization-ally or geographically distributed with network access using anapplication that they are familiar with and that any changes madeto the product model are correctly propagated such that the dataremain consistent

Every product modeling tool and technique discussed withinthis review is common from the perspective that the data containedwithin the model are a ldquosnapshotrdquo of the actual design activity Forinstance a designer may download data from the ship productmodel for use within a general design package which may take aweek to design During this design period the data within theproduct model do not change until the designer decides that thedesign process is complete and the data are uploaded into theproduct model The product model therefore does not contain acontinuous representation of either the design work that is cur-rently being undertaken or the form that the data are in This posesa number of significant project management issues with respect toversion control consistency management and conflict resolutionespecially in the situation where the design process is being un-dertaken in a distributed manner as is increasingly becomingcommon

A paradigm shift in the techniques used to enable the distributeddesign of ships while enabling a continuous product model andfacilitating the management of conflicts and consistency would bethe adoption of a technology that is more often seen within thecomputer games industry Graphics servers are commonly usedwithin the games industry to enable the user to immerse them-selves within an environment and interact both with the environ-ment and with other users High-level graphical objects are com-municated between the server side and the client side rather thanusing structured files This technique bypasses the need to trans-late the communicated data into the client side format alleviatingunnecessary computation It also results in a model containedwithin the server and represented within the clients that is a con-tinuous depiction of what everyone is undertaking The ship prod-uct data would remain within the ship STEP formats Howeverthe description method would be the graphical object representa-tion that would also exhibit behavioral properties Within the ship-building context individual graphics servers would represent do-mains similar to those identified by Crawford et al (1999) Clientsconnecting to the servers would immediately get an up-to-dateview of that particular domain which would be consistent with theviews of all of the other clients The client software would operatein a manner similar to conventional design applications There isalso clearly a requirement for integration between the differentdomain servers to enable conflicts to be resolved across domainsSimulation servers would integrate all of the scenarios that wouldenable an evaluation of the performance within any particular lifephase There would still remain the need to provide an effectivemanagement of different versions as well as a high-level coordi-nation structure to manage conflicts constraints design goals andcollaboration among designers However the underlying frame-work would provide the basis on which to construct this Despitebeing a significant step-change compared with current practicethis future technique proposes a viable solution to the effectivemanagement of a ship product model that may be manipulated andoperated upon in a distributed manner

This type of architecture does however raise a number of

issues relating to partnerships between the shipbuilding industryand the shipbuilding software industry because the system wouldrepresent an amalgamation of existing design and simulation ap-plications into a number of domain-specific servers The intellec-tual property rights as well as the ownership of both the technol-ogy and the data contained would clearly need to be resolved Inaddition the system calls upon the need to implement a standardfor the communication of the graphical objects that is both secureand robust whereas the standard for the data may be ldquoflavoredrdquoand managed effectively within the system via the ability to dy-namically load classes

Just as many of the precommissioning life phases are currentlybeing modeled it is anticipated that the rather poorly supportedpostcommissioning life phases will be catered for The most sig-nificant difference between pre- and postcommissioning is that itwill be the ship product model in its entirety that will be consid-ered For example there currently appears to be a significantopportunity for the specialization of the immersion of an entireship product model into an artificial environment to determine theoperational performance both at virtual sea (modeling existingshipping lanes to determine sea-keeping characteristics) within avirtual port (modeling existing ports to determine cargo-handlingcharacteristics) within a virtual shipyard for recommissioning(modeling existing shipyards to determine recommissioning capa-bility) and within a virtual breakers yard for disposal (to deter-mine scrap value) Increased opportunity would therefore be madefor designing the ship to meet a more rigorous set of customer-specified life-phase requirements and would represent a signifi-cant commercial advantage

It is also interesting at this point to note that a number of thecited papers have stated the need to avoid a reliance on computerprogrammers which in order to maintain even the simplest ofproduct data modeling systems seems unachievable

Conclusions

From the increasing amount of literature and the papers re-viewed within this paper related to the ship product model theprimary focus is on developing a standard representation for thedata contained within the model Despite not having yet finalizedthe standards for all aspects of the ship the STEP APs go a longway toward achieving this It is almost inconceivable to considerthat an alternative could compete against such a massive thrusttoward ship data standardization A number of instances havearisen however when the APs have been adhered to with theresult that ldquoflavorsrdquo or minor changes to the standard have beenrequired in order to utilize the structured well-defined and stan-dardized data within the legacy applications The question there-fore arises as to whether there is a requirement to standardize thelegacy applications such that they adhere to the data standard toenable a modular plug-in approach to ship design and simulation

Behavioral aspects have been considered within a number of thecited papers to be an important addition to the data in order toprovide the designer with additional feedback with respect to theoperation of the design This behavior may however be betterrepresented as high-level rules within a standard that are used todefine the operation of the ship rather than in existing standardsin order to minimize its impact on applications that have no needfor such data

A number of the tools and techniques discussed have described

the use of the ship STEP formats as being a mechanism for inte-grating existing legacy applications with a common model of shipproduct data Considerable benefit would be obtained from pro-viding similar integration between applications to progress fromthe limitations of discrete design and simulation toward having aholistic approach

The design tasks that are undertaken as part of the ship designprocess may well take a considerable amount of time and wouldconventionally result in ldquosnapshotsrdquo of the design artifact coin-ciding with the designer uploading data into the common modelA number of future directions have been discussed which wouldindividually require considerable development in order to imple-ment but which represent possible solutions to issues relating to

Continuous rather than ldquosnapshotrdquo ship product models Integration between the ship product model and the design

and simulation applications as well as across applications Removal of information translation problems through the

use of high-level graphical objects that are consistent betweenservers and applications

A collaborative framework on which to develop versionconflict and consistency management

Acknowledgments

The review was undertaken as part of an investigation intocommon model techniques within the VRShips-ROPAX2000project The authors gratefully acknowledge the support given bythe European Commission Community Research 5th Frameworkprogram under the area of Competitive and Sustainable Growthwhich provided the grant (G3RD-CT-2001-00506) that enabledthis work to be undertaken

References

BAUM S J AND RAMAKRISHNAN R 1997 Applying 3D product modelingtechnology in shipbuilding Marine Technology 34 1 56ndash65

CATLEY D 1999 Prototype STEP data exchanges in ship initial design andprovision of an application programmer interface to TRIBON Proceedings10th International Conference on Computer Applications in ShipbuildingJune Cambridge MA

CRAWFORD A K HARRINGTON G AMES R M AND VAN ESELTINE RT 1999 Neutral format data exchanges between ship product models andanalysis interfaces Proceedings 10th International Conference on Com-puter Applications in Shipbuilding June Cambridge MA

ERIKSTAD S O AND FATHI D E 1999 Applying the STEP shipbuildingprotocols as a basis for integrating existing in-house ship design applica-tions Proceedings 10th International Conference on Computer Applica-tions in Shipbuilding June Cambridge MA

GISCHNER B KASSEL B LAZO P WOOD R AND WYMAN J 2001 Evolution of STEP (ESTEP) exchange of shipbuilding productmodel data JOURNAL OF SHIP PRODUCTION 17 3 151ndash160

GRAU M AND KOCH T 1999 Applying STEP technology to shipbuildingProceedings 10th International Conference on Computer Applications inShipbuilding June Cambridge MA

HERZOG E AND TOumlRNE A 1999 A seed for a STEP application protocolfor systems engineering Proceedings 12th International Conference andWorkshop on the Engineering of Computer Based Systems Institute ofElectrical and Electronics Engineers Press Piscataway NJ 174ndash180

HIGNEY J T AND OUILETTE J J 1994 An engineering product modelbased on STEP protocols JOURNAL OF SHIP PRODUCTION 10 4 281ndash286

ISO 1996 Product Data Representation and Exchange Part 218 Ship Struc-

tures International Standards Organization Hamburg GermanyJOHANSSON K 1995 The product model as a central information source in

a shipbuilding environment Proceedings National Shipbuilding ResearchProgram 1995 Ship Production Symposium June Seattle WA

LAMB T CHUNG H AND SHIN J G 2000 A generic shipyard computermodel a tool for design for production Proceedings 7th IMDC NovemberKyung-Ju Korea

MARTIN D J 1980 The shipyard product information system as an aid toimplementing more productive strategies Proceedings Research and Engi-neering for Automation and Productivity in Shipbuilding IIT Research In-stitute October Chicago IL 81ndash101

POLINI M A AND MELAND K E 1997 The development and implemen-tation of a SMART product model for ship structure Proceedings 9thInternational Conference on Computer Applications in Shipbuilding Octo-ber Yokohama Japan

RANDO T C AND FERNHOLZ D 2000 MARITECHrsquos shipbuilding infor-mation infrastructure JOURNAL OF SHIP PRODUCTION 16 2 110ndash120

RANDO T C 2001 XML-based interoperability in the integrated shipbuild-ing environment (ISE) JOURNAL OF SHIP PRODUCTION 17 2 69ndash75

ROSS J M AND GARCIA L 1998 Making the jump to product modeltechnology JOURNAL OF SHIP PRODUCTION 14 1 15ndash26

ROSS J M AND ABAL D 2001 Practical use of 3D product modeling inthe small shipyard JOURNAL OF SHIP PRODUCTION 17 1 27ndash34

SCHMIDT W R VANDER J R AND SHIELDS V R 1990 Modelling andtransfer of product model digital data for the DDG 51 class destroyer pro-gram Proceedings National Shipbuilding Research Program 1990 ShipProduction Symposium August Milwaukee WI

SHIN Y AND HAN S H 1998 Data enhancement for sharing of shipdesign models Computer-Aided Design 30 12 931ndash941

VON HAARTMAN J KUUTTI I AND SCHAUMAN C 1994 Improving designproductivity with a product model for initial ship design Proceedings 8thInternational Conference on Computer Applications in Shipbuilding Sep-tember Bremen Germany

WELSH M LYNCH J AND BRUN B 1992 A data model for integration ofthe precommissioning life-cycle stages of the shipbuildingproduct JOURNAL

OF SHIP PRODUCTION 8 4 220ndash234WHITFIELD R I COATE S G DUFFY A H B AND HILLS

W 2000 Coordination approaches and systemsmdashpart I a strategic per-spective Research in Engineering Design 12 73ndash89

WYMAN J WOOLEY D GISCHNER B AND HOWELL J 1997 Development of STEP ship model database and translators fordata exchange between shipyards JOURNAL OF SHIP PRODUCTION 13 2111ndash124

Internet addresses

European Marine STEP Association httpemsagermanlloydorg

ISO STEP ship team http wwwnsnetcomNIDDESCt23html

Japan Marine Standards Association http wwwjecalsjipdecorjp

Korea STEP Centre httpksteporkr

data may be used more extensively within the design and produc-tion life phases whereas the bill of materials would be morerelevant to recycling during the disposal life phase

These issues have never before been considered within the ad-vent of digital product modeling techniques because these tech-niques have become prevalent only within the last 10 years or soand have in general been developed and applied only to the pre-commissioning life-cycle stages The structure and definitions forthe data types within the precommissioning stages are becomingincreasingly realized and standardized However little consider-ation has been given regarding the nature of the ship productmodel for the postcommissioning stages such as operation main-tenance refit and disposal and the predesign stages of require-ments analysis and feasibility studies More importantly due tothe duration of the full life cycle of the ship product it is essentialthat the data contained within the product model conform toagreed-upon standards such that support may be maintainedthrough a number of generations of computer architectures oper-ating systems and ship development environments

In a brief review of the state of the art of the product modelingtechnologies Ross and Garcia (1998) identify a number of char-acteristics that advanced product models possess a single inte-grated database graphical user interface with a consistent formattopological relationships among components of the ship designmacros and parametric tools and open structure to allow for dataretrieval to support manufacturing functions This paper discussesthese characteristics and aims to identify important others throughthe review of a number of key reports and papers that generallyfocus on the ship product model

The paper consists of an introduction to ship product data for-mats a review of ship product modeling tools techniques andprojects life-cycle issues and a speculation for future develop-ments for ship product modeling

Ship product data

The effective management of information within a database wasconsidered by Martin (1980) to improve the management of thedesign configuration and to increase the speed and accuracy withwhich design documentation may be produced Models containedwithin the database were created to represent the physical char-acteristics of the product Figure 1 for example represents a sim-plified design model for the structure of the ship

The central component of this model is the structural definitionentity (SDE) which represented either a point a line a surface avolume (or region) a plate part a stiffener or a group of partsInformation derived from other information contained within thedatabase was not stored in order to reduce the size of the databaseOther models were defined based on the SDE to represent pipingand so forth Despite being one of the earliest pieces of work onproduct modeling Martin discussed a number of important char-acteristics of product models that have since been adopted asstandard such as relationships between models to enable thechecking of interferences between geometrical components andstorage of information relating to the drawings that may be af-fected by a change to an SDE to improve design management

The International Standards Organisation (ISO) has for sometime been developing a Standard for the Exchange of Product Data

Nomenclature

AP application protocolARPA Advanced Research Projects

AgencyASE Advanced Shipbuilding EnterpriseCAD computer-aided design

CE concurrent engineeringCORBA common object request brokerage

architectureDARPA Defence Advanced Research

Projects AgencyDFP design for productionEJB Enterprise Java Beans

EMSA European Marine STEPAssociation

ESPRIT European Strategic Programme forResearch and Development inInformation Technology

GOBS geometry object structureGUI graphical user interface

IGES initial graphic exchangespecification

ISO International StandardsOrganisation

JMSA Japan Marine StandardsAssociation

NIAM Nijssen information analysismethod

NIDDESC NavyIndustry Digital Data

Exchange Standards CommitteeOSEB object serialization early bindingPDES product definition exchange

standardSBD simulation-based designSDE structural definition entitySPM Smart Product Modelling

SHIIP Shipbuilding InformationInfrastructure Project

SPARS Shipbuilding Partners andSuppliers

STEP Standard for the Exchange ofProduct Data

XML extensible mark-up language

Fig 1 Simplified structural design model (Martin 1980)

(STEP) STEP is being developed to tackle the issues associatedwith cross-platform and cross-application development of any de-sign artifact through the production of a system-independent rep-resentation of the product data Data types such as geometrytopology functionality cost materials strength and so forth maybe modeled using STEP The STEP application layer contains theneutral data models and the implementation layer contains theactual implementation of these models The EXPRESS data mod-eling language was specifically developed for use within the ap-plication layer STEP has been described as ldquonot only for neutralfile exchange but also as a basis for implementing and sharingproduct databases and archivingrdquo (ISO 1996)

STEP is organized as the following series description methods(10s) implementation methods (20s) conformance testing meth-odology and framework (30s) integrated generic resources (40s)integrated application resources (100s) application protocols(200s) abstract test suites (300s) and application interpreted con-structs (500s)

Established in 1985 the NavyIndustry Digital Data ExchangeStandards Committee (NIDDESC) was involved in defining anactivity model and information models for ship design and con-struction The ISO is continuing this work through the STEP ShipTeam (ISO TC184SC4WG3T23) and has developed a numberof application protocols (APs) to represent various aspects of theship product model (Fig 2) Herzog and Torne (1999) defined anapplication protocol as being ldquoan information and process modelfor an engineering domainrdquo as well as providing additional defi-nitions to the various STEP series

The ship arrangements model (AP215) was developed to sup-port functional and detail design and production engineering life-cycle phases to support damage stability structural analysis in-terference analysis and so forth

The ship molded forms model (AP216) was designed to repre-

sent any geometrical shape for the hull form or internal surfacesthat may be used within the design production and operationlife-cycle phases for hydrodynamic and intact stability analysis

The ship structures model (AP218) defines the structural partsof the ship such as the hull structure superstructure and internalstructures for the predesign design production and inspectionlife-cycle phases The ship structures model has links to AP215and AP216

The ship mechanical systems model (AP226) is used to definemechanical components such as main and auxiliary engines fuelpumps air compressors and so forth AP226 also defines theconnectivity between components geometry materials topologyand operational characteristics for the mechanical components

The electrical design and installation model (AP212) defines theelectrical design and installation information for electrical cablesand harnessing for power transmission distribution generationand so forth The AP has been finalized

The piping and heating ventilation and air conditioning(HVAC) model (AP227) provides the information to support func-tional design detail design production fabrication assembly andtesting of piping heating ventilation and air conditioning TheAP supports pipe flow stress and interference analyses as well asenables configuration management version control change track-ing and the production of a bill of materials The AP has beenfinalized

The European Marine STEP Association (EMSA) the JapanMarine Standards Association (JMSA) and the Korea STEP Cen-tre organization have undertaken additional STEP standardizationwithin the shipbuilding industry For additional information re-garding the STEP shipbuilding APs implementation history andimplementation technology see Grau and Koch (1999)

Wyman et al (1997) stated ldquoShipyards will be required in thefuture to adhere to certain data standards To remain competitive

Fig 2 ISO application protocols for the ship product model

it will become necessary to support international data standardsSTEP is the proposed solution to this data exchange challenge andis the basis for the Advanced Research Projects Agency (ARPA)Maritech project ldquoDevelopment of STEP Ship Model Databaseand Translators for Data Exchange Between Shipyardsrdquo

The ship product was developed within the NEUTRABAS proj-ect (Welsh et al 1992) as a large number of interrelated physicaland abstract object instances that were described and representedusing natural language to describe the context in which the objectsare used graphical Nijssen information analysis method (NIAM)diagrams that illustrate the relationships between the objects (Fig3) and using the EXPRESS information modeling language

Rando (2001) described the use of an XML mapping of STEPinstead of EXPRESS for application-to-application interoperabil-ity Product data sharing was enabled using object serializationearly binding (OSEB) The objective of the standard was to pro-vide a means of serializing (or persistently storing) the state of(ship data) objects contained within an object-oriented databaseinto a neutral format that may be communicated from applicationto application One of the benefits of using XML as the informa-tion syntax is the amount of development of parsing queryingtransformation validation and presentation tools for the supportof the language across all aspects of the information technologyindustry Rando argues that the lack of such development and thereliance on special-purpose tools for STEP is one of the maininhibitors for the wide-scale acceptance of STEP technologywithin small and medium enterprises a point that is also made byRoss and Garcia (1998) OSEB is also geared toward being able torepresent a complex web of a large number of interrelated objectsas a series of more manageable chunks corresponding closely tothe userrsquos conceptual model The technique addresses one of themajor shortcomings related to STEP mapped using EXPRESS thereferences contained within a STEP-EXPRESS file restrictthe deconstruction of the file into more manageable chunks TheOSEB is illustrated within Fig 4 as a layered architectureThe first layer is an object model that defines the stored productdata using either EXPRESS or some other modeling languageThe second is described as the object model of the object inter-faces that are presented to applications The third is the objectmodel that underlies the classes that implement the OSEB ldquowrap-perrdquo The last is the object model that underlies the contents of theOSEB file itself

Finally Rando states that the objective of the OSEB was tominimize complexity and not the size of the XML files XML fileshave an unavoidable concession in that they are not specificallydesigned with compactness in mind due to the necessary inclusionof tags for instance and the lack of a binary format However thefiles are generally more readable and have a more obvious datahierarchy than EXPRESS

As well as developing standards for the mapping between XMLand STEP the Maritech Evolution of STEP (ESTEP) project(Gischner et al 2001) is continuing the development alongsideNIDDESC of the STEP shipbuilding product model standards anddata exchange of the Defence Advances Research Projects Agency(DARPA)Maritech MariSTEP project It is intended that ESTEPwill enable the efficient transfer of data among shipyards designagents and regulatory agencies

Gischner et al state that the current STEP APs take 3 to 5 yearsto develop and a great deal of time has been wasted developingsimilar standards by different industries Figure 5 illustrates theevolution of STEP from individual APs to a plug and play ap-proach through STEP modules

Advancements within both the ship design process and theavailability of cheap and powerful computational resources wereidentified as being the main drivers for the explosion in theamount of data contained within the ship product model (Catley

Fig 3 NIAM diagram of the NEUTRABAS high-level model

(Welsh 1992)

Fig 4 Layered object models in OSEB (Rando 2001)

Fig 5 STEP evolution (Gischner et al 2001)

1999) Catley states that a modern commercial vessel may beexpected to have an associated product data model 2 to 10gigabytes in size depending on its complexity Archiving ver-sion management and a robust product information solution areseen as essential requirements for a competitive shipbuilding in-dustry

Catley also discusses the translation of the AP215 compartmen-tation and AP216 ship molded forms schemas between theTRIBON system and either SEASPRITE or MariSTEP represen-tations Despite an increasing demand for the standardization ofproduct information to enable a common-model representationCatley recognizes the need for openness between specialist sub-contractors and partners in order to achieve common access Fig-ure 6 demonstrates the data flow between KCS and Calypso

Crawford et al (1999) defined a geometry object structure(GOBS) as being organizational to enable the data to be accessedby logical groupings or views topological to define the physicalrelationships between model elements and representational as aresult of the topology The resulting structure enabled both topo-logical views (a view of space not the space itself) and commonviews (compartments machinery spaces)

The development of ship product data formats and structureshas seen a great deal of focus on the ship STEP APs as well asusing EXPRESS and more recently XML as languages to modelthe data The ship STEP APs are clearly required to represent largeamounts of complex data However they also require a concertedand constant effort for finalization to avoid stagnation and toimprove general uptake across the industry These technologiesrely heavily on information technology which is notorious forprogressing more quickly than standards are produced Informa-tion technology considerations are therefore vital in the develop-ment of the data formats and the supporting mechanisms in orderto ensure that the standard does actually ensure the exchange ofproduct data In addition the operational maintenance and de-

commissioning life phases need to be thoroughly supported withinthese data structures

Ship product modeling

Martin (1980) was perhaps one of the first people to discussproduct information systems within shipbuilding and defined theproduct model as ldquoa logically-structured product-oriented data-baserdquo The product model term was however considered by Mar-tin to be a misnomer because the inclusion of nonproduct infor-mation specifically information relating to the yard facility wasconsidered to be one of the most important benefits of the systemThe product model was described as consisting of a number oflogically complete database subsets that contain overlappingstructural and material information for the product (Fig 7)

Martin realized that the product model was not simply a designtool but the information contained within it may be utilized byother yard functions to determine material requirements issuepurchase orders schedule activities and so forth Indeed since theadvent of numerically controlled machines the product model hasbeen viewed as a tool to automate parts of the production process(Johansson 1995 Ross amp Garcia 1998 Ross amp Abal 2001)

During the early 1990s Schmidt et al (1990) explored the fol-lowing options for the format for the product modeling and digitaldata transfer (DDT) within the US Navyrsquos AEGIS destroyerprogram

1 ldquoFlavoredrdquo initial graphic exchange specification (IGES) orstandard IGES ldquoFlavoringrdquo is the term used to define theprocess of augmenting the shortcomings of the implementedstandard in order to adapt it to the required task

2 Deferment until the completion of product definition ex-change standard (PDES) and its commercial implementa-tion

Fig 6 Data communication within Calypso project (Catley 1999)

3 Development of direct translators by a software developerspecializing in computer-aided design (CAD) direct transla-tors

4 Use of a neutral file that defines object data

Option 1 was rejected due to the associated shipyardsrsquo usingobject- rather than entity-oriented CAD software PDES was con-sidered to result with a delay of several years to implement aproduction translator hence option 2 was rejected Flexibility andexpansion were considered as restricting factors for option 3 Fi-nally option 4 was accepted due to the ability to develop a neutralmodel in the available time and the flexibility and future expan-sion of such a model

Schmidt et al also introduced the concept of the ldquodesign win-dowrdquo to transfer only the part of the model that was required ratherthan the entire model by specifying boundaries for the design zoneto be transferred One important aspect related to the transfer ofpartial data was the requirement for effective configuration man-agement such that changes made to the partial models were re-flected within the overall model Higney and Ouilette (1994) fol-lowed up the discussion of Schmidt with a description of a STEP-based product model for the AEGIS destroyer The product modelwas split into two parts a graphical model and a relational data-base containing nongraphical data NIAM diagrams were initiallyused to define the relationships within the relational database Themodel was developed based on the more fully developed STEPpiping AP However other APs were to be included when theybecame available

Welsh et al (1992) focussed on the precommissioning life-cyclestages of the shipbuilding product model while developing aframework to integrate disparate computer-based information sys-tems within the ESPRIT IIndashfunded NEUTRABAS project (Fig 8)The underlying mechanism to achieve this integration was a prod-uct model database to contain and manage neutral shipbuildingdata specifically spatial structural integration outfitting and en-gineering systems data It was identified that the structure of thedata was as important as the data themselves in order to effectively

manage the exchange of the data across various complex andheterogeneous ship development applications

Baum and Ramakrishnan (1997) suggested that associativitydata are extremely useful additions to the product model becausethey enable changes made to any one of the objects within thedatabase to be reflected in all associated objects Baum and Ra-makrishnan however did not suggest how this change propaga-tion is managed because without due coordination the impact ofthe change may result in chaotic behavior in complex systems(Whitfield et al 2000) Additionally there is no discussion regard-ing the requirement to simulate the reflected change using thesimulation software to determine the adequacy of the initialchange

The overall aims of the NEUTRABAS project were defined as

The standardization of the way in which information con-cerning marine-related products is represented

The development of standard methods for the exchangeand storage of product definition data in the marine industry

The specification and development of a suitable databasearchitecture that will facilitate the exchange and storage of suchproduct definition data

The implementation of a prototype data exchange andstorage system based on the previously defined database ar-chitecture which will demonstrate the feasibility of a trulyintegrated product life cycle

The authors identified a number of benefits associated with theabove aims such as the reduction of project time scales throughthe adoption of a single managed information store Managing theinformation within a single database is intended to avoid infor-mation mismatches and hence reduce the amount of rework which

Fig 7 Product information system layout (Martin 1980)

Fig 8 The NEUTRABAS system architecture (Welsh et al 1992)

has indeed been reported within a number of publications How-ever there has never been any consideration of the database con-trol mechanisms required to prevent the database from becomingan information bottleneck despite the assumption that a benefitwould be more effective information management or the in-creased duration associated with searching a single (extremely)large database for the required piece of data despite the assump-tion that a benefit would be rapid information disseminationThere is also the suggestion that using such a representation ofproduct data will avoid the need to transcribe the data betweendifferent application systems eliminating the introduction of errorthrough human interaction However a number of papers havesince reported on the requirement of application interfaces totranslate the product data into a format suitable for the intendedapplication Indeed Rando (2001) reported that in some cases adegree of human interaction has been required to ensure that thisprocess runs smoothly Conversely Catley (1999) suggested thatthe minimization of human interaction within the data exchangeprocess has resulted in more consistent design Finally the authorsidentified the benefit associated with improving the interface be-tween the supplier and the client through the introduction of elec-tronic product definition databases

The NEUTRABAS system was composed of an application-independent EXPRESS model defining the shipbuilding producta data dictionary to manage requests to the database a mappingbetween the model and the dictionary in the form of an EXPRESSimport tool the data management component to enable the cre-ation communication modification and querying of productmodel data a number of application interfaces to enable the in-dividual applications to interact with the database a number ofdatabase interfaces to enable communication between specific da-tabase management systems and the NEUTRABAS database anda database generator that enables the mapping of data within aspecific database to the data within the NEUTRABAS database

Von Haartman et al (1994) described the ship product modelwithin the NAPA project and realized the potential of the productmodel as a basis for concurrent engineering (CE) The use ofcomputers within the shipbuilding industry was previously re-stricted to the computationally intensive applications such as thecalculation of hydrostatics and stability These applications havehad a great deal of development to produce tools that represent andmodel a particular characteristic of the design quite accuratelyThey have generally received a great deal of investment of timeand money (Crawford et al 1999) Von Haartman et al suggest thatthe modern ship design process should ideally consist of a singlesystem that augments all of the disparate design tools but that oneshould recognize that such a system is far from reality The alter-native was to provide a framework to interlink these design toolsto give the impression of a single system The ship product modelwas the key to interlinking these tools

Von Haartman et al also stated ldquoAny model merely reflectsselected properties of the object it is intended to describe and theappropriate selection of properties is of central importance whendesigning the modelrdquo Within the NAPA ship product modelglobal properties of the ship were identified such as the maindimensions hull form and so forth and although not explicitlystated it is assumed that these global properties were chosenpartly for the reason that they are common among the design toolsbeing utilized These properties within the model may also be usedto evaluate the economic and technical requirements of the ship

Finally Von Haartman et al stated that the lack of detail of theglobal properties within the ship product model is not synonymouswith inaccuracy

Johansson (1995) described the challenge of modern shipbuild-ing as ldquoto manage and control the design and assembly process togain efficiency and short delivery timesrdquo By summarizing theshipbuilding process life-cycle stages as tendering design pro-duction planning materials finance and follow-up the require-ment for the effective management of the extremely large amountsof information was established in order to ensure the efficientorganization of the shipbuilding process Johansson suggested thatthis requirement could be satisfied only through the developmentof ldquoan information flow solution specifically designed for thisindustryrdquo and suggested that it was not sufficient just to automateexisting manual activities Rather the organization should beadapted to the use of new tools to streamline the information flowwherever possible The discussion appeared however to be re-stricted to information flows within a single shipbuilding organi-zation with the main focus on how the information may be utilizedto improve the production process

The product model concept was regarded by Johansson as beingone such tool whereby the organization may be streamlinedthroughout the precommissioning stages by providing a consis-tent model to enable well thought-out build strategies to be de-veloped early ordering of materials and material handling pre-fabrication preoutfitting and the use of numerically controlledmachines

Additional information was contained within the productmodel such as material codes weights surface treatments and soforth For this reason Johansson suggested that a more appropriateterm may be product information model because the modelshould contain all technical product definition data and may beused to provide for example graphical representations of geom-etry as well as lists and reports of material requirements Addi-tionally Johansson stated that the generation of a graphical rep-resentation should be produced only when it is required and to theextent that is suitable in order to avoid unnecessary computationThe graphical representation is regarded as secondary informationof the (primary) information stored in the product model Theinformation flow may be streamlined by the manipulation of theprimary information rather than the secondary information

Johansson also recognized that it was important that ldquoa productmodel based system must understand what the different parts ofthe system really represent and be able to interpret the rules andrestrictions connected to each type of objectrdquo

Erikstad and Fathi (1999) described how a STEP-based shipproduct model could be used within the ShipX project for theintegration of the data within a number of hydrodynamic analysisapplications for a ship The applications were previously devel-oped as stand-alone applications to specific aspects of the hydro-dynamic performance of the ship such as propulsion and seakeeping Previous integration among the applications wasachieved through the development of translators to allow for theexchange of information However the technique was difficult toimplement and maintain and was not considered to be seamlessThe communication of information among applications is clearlya central issue that has been discussed in a number of reports(Wyman et al 1997 Gischner et al 2001) Essentially the optionsare either to develop a direct interface between every pair ofcomponents or develop the interfaces based on a consistent inter-

face standard A common product model (Fig 9) was imple-mented within ShipX and from the application developmentviewpoint it enabled

Developers to concentrate more on the specific simulationproblem rather than the modeling of the data This benefit isrealized every time a particular application goes through rede-velopment or when new applications are developed

Guaranteed synchronization of data between the applica-tions and the product model Translators were previously usedto convert the product data to and from the required formats foreach application Changes could potentially be made to theproduct model after data translation to the application resultingin a discrepancy in the translated data The product modeltechnique ensures that each application has a common repre-sentation of the ship

Reuse of previous applications and graphical user inter-faces eliminating the need for the end user to relearn how touse the application

Despite integrating existing applications with the productmodel it is not clear within the ShipX project whether integrationexisted between applications For example two discrete applica-tions may be considered as damage stability assessment andevacuation simulation both integrated via the product model It ispossible to make assessments of the performance of the ship withrespect to both the damage stability and the evacuation in isola-tion via the integration with the product model However inte-gration is required between the damage stability and evacuationapplications in order to assess the evacuation time while compart-ments are flooding

The ShipX product model was developed using the relevantshipbuilding protocols developed within STEP which were imple-mented into a class library and stored using an object-orienteddatabase

Erikstad gave a number of useful guidelines for the develop-ment of the ShipX system

Simplicity The development of a comprehensive productmodel tool was considered to be prohibitive both from theaspects of timeliness and cost effectiveness Wherever pos-sible commercial off-the-shelf components were used Thedevelopment of the actual product model was undertaken usingthe STEP shipbuilding protocols rather than developing anin-house product model from scratch

Flexibility and extensibility The model was initially lim-ited to representing data that were specific to hydrodynamicperformance However consideration was given to the struc-ture of the model such that it could be extended to representother performance aspects Also the use of STEP to producethe common product model enables the scope of ShipX to beextended without restructuring the model The facade designpattern was also used to hide the complexity of the productmodel from the client applications define the correct usage ofthe product model by the client applications and enable theupdating of the product model without affecting the client ap-plications

Weak bindings to platform and programming language toenable the cross-platform and cross-language integration of theproduct model

Baum and Ramakrishnan (1997) regarded three-dimensionalproduct model technology as being fundamental for the imple-mentation of concurrent engineering (CE) within shipbuilding dueto the ability to develop capture represent integrate and coor-dinate data and permit simultaneous access to a number of usersBaum defined the product model as ldquothe integration of the 3Dgeometric model and non-geometric database informationrdquo whichmay be a logical integration of distributed information (Fig 10)

Simulation and interaction with the objects within the productmodel through the introduction of anthropomorphic models into avirtual environment to test functionality and operability were dis-cussed as being a useful technique to test the validity of the modelin a way similar to what would be achieved with the final productThe resulting model is essentially an electronic ldquomock-uprdquo Baumsuggested therefore that it is important to also represent the nor-mal behavior of the objects within the ship product model suchthat their behavior may also be analyzed enabling the product tobe designed manipulated analyzed constructed tested operatedsupported and disposed of in a virtual environment

Ross and Garcia (1998) and Ross and Abal (2001) discussed theutilization of product modeling technologies within two differentshipyard applications new build and conversion with the focus ofaiding shipyard managers with the decision to adopt such tech-nologies Ross suggests that the key characteristic of the productmodel for achieving a high level of integration is the adoption ofa single database allowing a number of designers to simulta-neously work on the same design through effective database man-agement and reducing or preventing altogether the inconsistency

Fig 9 From data translators to data integration within the ShipX project (Erikstad amp Fathi 1999)

of information A number of small shipyards that have incorpo-rated product-modeling technologies are used as case studies todiscuss the techniquersquos effectiveness with the conclusions thatthese shipyards have an improved production quality and signifi-cant savings in material cost labor cost construction cost andlabor hours Despite being a more complex representation thantraditional techniques Ross and Abal (2001) concluded that stafftraining was straightforward and that staff were considered com-petent after the design of the first vessel

Polini and Meland (1997) discussed the extension of a prototypeproduct modeling system through to the development of a pro-duction implementation that was capable of supporting concur-rent multiuser access Life-cycle data and behavior were modeledwithin the classes contained in the Smart Product Modelling(SPM) system The differentiation between a standard productmodel and an SPM system is shown in Fig 11 To appreciate theamount of effort involved in developing the SPM Polini andMeland state ldquoTo date nearly 45 man-years of software devel-opment have been invested in the SPM and its GUI approxi-mately 1000 classes with over 30000 methods have been devel-oped object oriented databases on the order of 25 gigabytes arecommonplace 24 concurrent users have modeled five shipclasses and tens of thousands of structural parts have been manu-facturedrdquo

This development was undertaken entirely within a shipyardwithout any commercial input Polini and Meland justified thisdevelopment by surveying the requirements of the shipyard andconcluding that there were no commercially available systemscapable of dealing with the degrees of specialization within theshipbuilding industry a point that has also been made by Jo-hansson (1995)

One of the questions asked by Shin and Han (1998) and others(Baum amp Ramakrishnan 1997) is whether it is possible to imple-ment paperless design because designers often spend a great dealof time trying to extract useful information from two-dimensionalpaper drawings The shipbuilding building blocks within the STEPshipbuilding APs were used as the basis to produce a ship product

model Shin used the STEP toolkit ST-Developer to produce C++classes using the EXPRESS data definition language for the mid-ship section of a bulk carrier

The classes were enhanced to enable all life-cycle product in-formation to be stored within a single data structure as well as fortranslating data formats by one-to-one mapping and includingexplicit information (Youngrsquos modulus Poissonrsquos ratio) from de-sign conventions available within the product model The systemarchitecture can be seen in Fig 12 This enhancement was re-quired because Shin suggested that it was not sufficient to simplytranslate data from a neutral format into the format required byeach application Rather it is a requirement of each applicationthat associated functions and information specific to each appli-cation is also incorporated into the model

This requirement for functional data was also discussed byCrawford et al (1999) Rather than relying on a flat neutral file tocontain geometry and topology information it was considereduseful that the topological data for example were provided withsome sort of intelligence to facilitate the translation between ap-plications The STEP standards were adhered to wherever pos-sible However achieving intelligent topology required extensionof the standards Crawford defined the Newport News Shipbuild-ing view of a product model as ldquoan all encompassing model of a

Fig 11 Product model definitions (Polini amp Meland 1997)

Fig 10 Representation of a ship three-dimensional product model (Baum amp Ramakrishnan 1997)

ship project taking advantage of the available computer toolsfor describing the geometry of a ship but it also includes allattributes necessary for the design production and operation ofthe shiprdquo

Again it was considered unlikely that the ship could be definedby a single computer system rather than by a number of moremanageable systems grouped according to some arbitrarily de-fined domains (Fig 13)

Crawford demonstrated the use of intelligent topological andgeometric STEP-based data through the use of the GOBS commonobject request brokerage architecture (CORBA) server that pro-vides a number of methods to enable legacy tools to extract therequired data Two analysis tools were used to model the ship

vulnerability and hydrostatics which obtained their data from theGOBS server The analysis concluded that within the majority ofthe cases the STEP standard for geometric data (Part 42) wassufficient to represent the geometry for the ship

Rando and Fernholz (2000) describes how the DARPA Mar-itech Shipbuilding Information Infrastructure Project (SHIIP) andShipbuilding Partners and Suppliers (SPARS) projects used acombination of component-based software internet protocols anda portable computing platform to satisfy the following shipbuild-ing information technical requirements

An information technology gap separates the large me-dium and small shipyards

Fig 12 System architecture of the STEP manager (Reprinted from Shin amp Han 1998 with permission from Elsevier)

The information technology staffs at most shipyards areexperts in shipbuilding process requirements but not in system-level computer technologies

Shipyard information systems must be reliable and main-tainable yet often need to be customized to suit an individualshipyard

As with many other projects (Rando 2001 Gischner et al 2001)integration within the shipbuilding industry was considered pos-sible only by the reuse of existing software components becausethe number of shipbuilding system requirements is so diverse thatit is unrealistic to assume that it is possible to produce a singleoverarching solution The integrated system was considered toconsist of a number of independent components to be assembledand reused by third parties in order to create a new complexsystem The initial task of the SHIIP project was to define areference architecture to support the composition of the indepen-dent components

The management of the product data was achieved using En-terprise Java Beans (EJB) that enable persistent storage secureaccess and load balancing for multiple users wishing to access thedata simultaneously At the start of the SHIIP project however

EJB was not available and the project relied instead on CORBAtechnology The project learned the following lessons from usingCORBA

Technology independence although useful in theoryshould not be pursued at the expense of developing workingimplementations

Technical interoperability is not a requirement for the de-velopment of an industrial information infrastructure Support-ing applications and software components for the informationinfrastructure are homogeneous enough to be implemented in asingle implementation technology

The Object Management Group (OMG) while advocatingseparation of components has produced in the arena of do-main standards wrappers for monolithic applications

OMG has been hampered by the inability to reach timelyconsensus

The Integrated Shipbuilding Environment (ISE) project withinthe Maritech Advanced Shipbuilding Enterprise (ASE) is usingXML as the basis for achieving interoperability between ship-building systems technologies specifically between application toapplication (Rando 2001) Rando differentiates this problem fromthat of other industries by stating that many of the applicationcomponents used within the shipbuilding industry have alreadybeen developed as well as the having little control over the de-velopment of these systems The shipbuilding product model mayalso contain millions of instances of a large number of differenttypes of information that need to be managed as they evolve overthe productrsquos life cycle It is also suggested that not only is therea need to rely on an enterprise system that augments the manyspecialist applications but due to the diversity of informationwithin the life cycle of the ship no single information system issufficient to deal with the entire ship product Indeed previousalliances between shipyards have been one-off solutions and thereis a definite requirement for a standardized effort for the shipproduct model

Rando identified a number of business drivers in order toachieve interoperability within the shipbuilding industry and pro-

Fig 13 Domain-based ship system (Crawford et al 1999)

Fig 14 ISE reference architecture three levels of interoperability (Rando 2001)

posed an architecture in order to respond to these drivers (Fig 14)The architecture represents three interoperability levels within theshipbuilding environment intercomponent refers to the interac-tions between the software components within a system intersys-tem refers to the interactions between the systems and is boundedby a business system domain and interenterprise interoperabilityrefers to interactions between business systems domains at differ-ent shipyards and organizations

The key elements for achieving this interoperability were acommon syntax using XML to facilitate communication a sharedstandard information model using STEP and an interoperabilityinfrastructure using web-based technologies XML is a neutralformat that may be viewed by humans (although this is not gen-erally a primary requirement) and that enables the sharing of in-formation between different technologies different operating sys-tems and different programming languages Five keyrequirements were identif ied to facilitate application-to-application integration

Should ldquoreuserdquo widely available standards-based tools Should be implementable with tools that allow for recon-

figuration by nonprogrammers Should support transformation to and from a canonical or

neutral format Should utilize a representation that is as simple and con-

cise as possible Should be able to marshalunmarshal every semantic con-

cept representable in the EXPRESS information modeling lan-guage (ISO 10303-11)

One of the most significant issues relating to the use and inte-gration of ship product models with existing applications appearsto be the need to ldquoflavorrdquo the model and specifications to suit theparticular requirements of the design and simulation applicationsWithout these embellishments the fully automated data integra-tion appears quite often difficult to achieve There are howeverconflicting opinions regarding the effectiveness of automating thisprocess generally arising due to the complexity of the problem andthe level of support The application of ldquoflavoredrdquo standards doeshowever entirely go against the point of creating a standard es-pecially when it is with respect to the transfer of product data Itcould therefore be concluded that the solution to the effectiveintegration of STEP lies not in the modification of a new tech-nology to satisfy the requirements of legacy applications but inthe updating of the legacy applications to satisfy the new technol-ogy

Life-cycle issues

The NEUTRABAS project (Welsh et al 1992) was limited tothe precommissioning stages that is marketing conceptual de-sign detailed design drafting materials ordering productionplanning and control scheduling and quality control However itwas recognized that significant benefits would be achievedthrough extending the life cycle through to disposal Welsh et alqualified the limitation to the precommissioning stages by statingthat ldquothe definition and implementation of a complete product datamodel covering all of these aspects of the life-cycle of an engi-neering product as complex as a ship is an onerous task and one

which would require the commitment of a vast amount of time andeffortrdquo

Limiting the project to the precommissioning stages would ap-pear to have been a wise judgment because in the 10 years fol-lowing this project the standards created to describe the shipproduct model have still not yet been finalized

Welsh et al suggest that the physical representation of the prod-uct within each life cycle stage would ldquonormally be unchanged inthe global sense although the information associated with theproduct and the techniques used to represent it will vary consid-erablyrdquo that is the information contained within the productmodel would mature as more detail becomes available as well asrequiring different viewpoints at each life-cycle stage The productmodel must therefore be developed not only with the associateddata and structure in mind but also with the life-cycle stages Toenable the support of the precommissioning life-cycle stagesWelsh et al identified four views that need to be supported by theship product model

Marketing-oriented view Management-oriented view Design-oriented view Production-oriented view

Von Haartman et al (1994) briefly discussed life phase issues ofthe ship product model and suggested that a number of systemsmodel the design with too much detail and hence are not appli-cable to the concept design stage A solution to this was thedevelopment of a concept design product model that could then betransferred to the detailed design stage It is not clear from thiswhether Von Haartman et al were proposing separate models forthe two stages or if the detail product model would simply consistof the concept product model plus the additional required detail

The mechanism of having multiple different views for the shar-ing of a product model among designers and production engineersfor example has been considered and implemented in a number ofcases (Polini amp Meland 1997 Johansson 1995) Johansson indi-cated that it is common for parts of the product to be in differentlife-cycle stages at the same time that is the ldquomanufacture of onepart of the product is going on at the same time as the detaileddesign of anotherrdquo This is one aspect of concurrent engineeringwith the result of reducing the lead times because the manufactureof the product has started before the design of the product has beencompleted However it is necessary to ensure both that manufac-turing starts only on parts that require no further design and thatother parts that are currently being designed do not propagatechanges to the manufactured parts The management and controlof the information flow were recognized as being the key elementsin increasing the overlapping of life cycles However no expla-nation was given by Johansson regarding the nature of the man-agement other than through the relationships between the objectscontained within the model These relationships were described asa mechanism to enable both interdisciplinary and cross-disciplinary communication among designers

The three-dimensional product model was described by Baumand Ramakrishnan (1997) as being a mechanism to enable a num-ber of different life-cycle stage simulations such as interferencechecking crew traffic flow studies yard-specific designs and fi-nite capacity scheduling through the use of a virtual environmentdesign review technology using data contained within the productmodel (Fig 15)

Coupled with simulation-based design (SBD) Baum describedthe combined technology as ldquothe new frontierrdquo that would enablethe virtual prototyping of the ship which previously could not beachieved due to the cost and complexity More importantly Baumrecognized that just as interference-checking software may beused to determine discrepancies between geometric parts duringthe design and production phases SBD may be used to reduce oreliminate design errors that would have previously have beendiscovered years later in the operational stage for example Es-sentially SBD and product modeling enable the validation of thedesign production and operation stages of the ship product

Baum also finally suggested that the product model provides asignificant benefit to the owneroperator by enabling the analysisand support of life-cycle maintenance

A generic shipyard computer modeling tool for evaluating de-sign for production (DFP) is discussed by Lamb et al (2000) Thetool enables shipyards to be modeled such that the impacts ofchanges to the ship design may be determined on the basis of theresulting material manpower and schedule The shipyard modelrepresents details of the buildingsmdashtheir arrangement and size aswell as equipment capacity and flow The tool also enables aninvestigation of the necessary changes required for a shipyard inorder to produce a new design The key foundations in order toevaluate these impacts are the interim product catalogue and thebuild strategy approach

Lamb et al identified a number of important concepts for DFP

All designs should be prepared to suit a shipyardrsquos facili-ties and preferred production methods

DFP takes into account production methods and tech-niques that reduce the product work content but still meet thespecified design requirements and quality

DFP must be incorporated into a design from the start Traditional engineering leaves it up to another department

such as production or manufacturing engineering to developthe technical documentation required for the production work-ers This is an unnecessary duplication of effort and is a nonndashvalue-added task that takes time

An objective of the CE approach is to accommodate DFPby bringing all the necessary people together right from dayone on a project

The time to influence the cost of a product is during theearly stages After the design has been developed in conceptmost of the opportunity to positively affect cost is gone

World-class ship designers know how their shipyardbuilds ships and design accordingly Many ship designers donot consider this and the designs may or may not be efficientlybuilt in their facilities More shipbuilders have taken steps toremedy this situation through the use of the build strategyapproach

Engineering should be prepared and transmitted to theusers in a way that best suits block construction advanced andzone outfitting

An object-oriented approach was adopted for the constructionof the model (Fig 16) The model represents shipyards worksta-tions products equipment processes manufacturing processesmaterial handling processes and interim products The tool wasapplied to the evaluation of two design alternatives for the bottomstructure of a ship The authors demonstrated that the tool enabledreliable evaluations of the man-hours for manufacturing and ma-terial handling such that the best design alternative could beadopted

Future directions

It is believed that the ship STEP APs will become the standardunit of shipbuilding data but that it will probably be an evolution-ary process as advances in technology and modeling capabilitiesand requirements are incorporated It is however crucial that thedevelopment of the standards comes to a timely consensus at eachevolutionary stage The literature reviewed has discussed the useof ldquointelligentrdquo data the inclusion of useful functionality accord-ing to the data type and of behavioral aspects It is anticipated thatthis functionality behavioral aspects and so forth will increas-

Fig 15 Ship design workflow using three-dimensional product model (Baum amp Ramakrishnan 1997)

ingly become part of the model to the extent that the model nolonger has any need for interfaces and translators to legacy soft-ware For example the piping model would automatically calcu-late interferences and the structures model would automaticallycalculate stress characteristics The simulation would essentiallybe part of the model and the model would contain additionalinformation and knowledge to effectively manage the simulationThis is not to say that the model would become a monolithicsystem despite such a system being potentially computationallyviable in 10 years Rather than being monolithic current andfuture distributed information technologies such as EnterpriseJava Beans may be utilized in order to distribute the model acrossa network while giving the impression to the user that the systemis monolithic Ship product data and functionality would be dis-tributed either within a single company or as partnerships withother companies

In a similar way that the ship product data has become stan-dardized benefits are to be gained from standardizing the inter-faces between applications to support the flow of standardizeddata and achieve a truly seamless integration The unfortunateshortcoming of application standardization is the necessity to re-develop the legacy systems to support this level of integration

The VRShips project addresses the management of ship productdata within a neutrally formatted common model The geometry

data contained within the common model are based on STEPAP203 are described using XML and are considered as beingcommon data if two or more applications access it Integration isprovided between the legacy applications and the common modelvia ldquogeneric wrappersrdquo that provide the general management re-quired in order to operate the applications The wrappers convertthe data to and from the native format using modular conversionalgorithms that can be plugged into the wrappers and provide thedomain-specific management for the applications Data are auto-matically downloaded from the common model and converted intothe native format when the application is started When the appli-cation is complete the designer has the option of undertaking thereverse process to convert the data back into the neutral format andupload into the common model Despite being a complex processconverters have been produced for a number of design applica-tions such as Tribon and AVPro and have been demonstrated tooperate without the need for manual interaction However theissues relating to the lack of integration between tools and con-tinuous product models remain to be addressed

The VRShips system also has an additional management layerconsisting of a process controller and an inference engine that arejointly responsible for maintaining data consistency and versionconstraint and process management Visualizing of product datavia the legacy applications is managed through the exporting of

Fig 16 Object diagram for generic shipyard computer model (Lamb et al 2000)

the displays via a virtual interaction environment These controlmechanisms ensure that designers may modify the data containedwithin the common model from any location either organization-ally or geographically distributed with network access using anapplication that they are familiar with and that any changes madeto the product model are correctly propagated such that the dataremain consistent

Every product modeling tool and technique discussed withinthis review is common from the perspective that the data containedwithin the model are a ldquosnapshotrdquo of the actual design activity Forinstance a designer may download data from the ship productmodel for use within a general design package which may take aweek to design During this design period the data within theproduct model do not change until the designer decides that thedesign process is complete and the data are uploaded into theproduct model The product model therefore does not contain acontinuous representation of either the design work that is cur-rently being undertaken or the form that the data are in This posesa number of significant project management issues with respect toversion control consistency management and conflict resolutionespecially in the situation where the design process is being un-dertaken in a distributed manner as is increasingly becomingcommon

A paradigm shift in the techniques used to enable the distributeddesign of ships while enabling a continuous product model andfacilitating the management of conflicts and consistency would bethe adoption of a technology that is more often seen within thecomputer games industry Graphics servers are commonly usedwithin the games industry to enable the user to immerse them-selves within an environment and interact both with the environ-ment and with other users High-level graphical objects are com-municated between the server side and the client side rather thanusing structured files This technique bypasses the need to trans-late the communicated data into the client side format alleviatingunnecessary computation It also results in a model containedwithin the server and represented within the clients that is a con-tinuous depiction of what everyone is undertaking The ship prod-uct data would remain within the ship STEP formats Howeverthe description method would be the graphical object representa-tion that would also exhibit behavioral properties Within the ship-building context individual graphics servers would represent do-mains similar to those identified by Crawford et al (1999) Clientsconnecting to the servers would immediately get an up-to-dateview of that particular domain which would be consistent with theviews of all of the other clients The client software would operatein a manner similar to conventional design applications There isalso clearly a requirement for integration between the differentdomain servers to enable conflicts to be resolved across domainsSimulation servers would integrate all of the scenarios that wouldenable an evaluation of the performance within any particular lifephase There would still remain the need to provide an effectivemanagement of different versions as well as a high-level coordi-nation structure to manage conflicts constraints design goals andcollaboration among designers However the underlying frame-work would provide the basis on which to construct this Despitebeing a significant step-change compared with current practicethis future technique proposes a viable solution to the effectivemanagement of a ship product model that may be manipulated andoperated upon in a distributed manner

This type of architecture does however raise a number of

issues relating to partnerships between the shipbuilding industryand the shipbuilding software industry because the system wouldrepresent an amalgamation of existing design and simulation ap-plications into a number of domain-specific servers The intellec-tual property rights as well as the ownership of both the technol-ogy and the data contained would clearly need to be resolved Inaddition the system calls upon the need to implement a standardfor the communication of the graphical objects that is both secureand robust whereas the standard for the data may be ldquoflavoredrdquoand managed effectively within the system via the ability to dy-namically load classes

Just as many of the precommissioning life phases are currentlybeing modeled it is anticipated that the rather poorly supportedpostcommissioning life phases will be catered for The most sig-nificant difference between pre- and postcommissioning is that itwill be the ship product model in its entirety that will be consid-ered For example there currently appears to be a significantopportunity for the specialization of the immersion of an entireship product model into an artificial environment to determine theoperational performance both at virtual sea (modeling existingshipping lanes to determine sea-keeping characteristics) within avirtual port (modeling existing ports to determine cargo-handlingcharacteristics) within a virtual shipyard for recommissioning(modeling existing shipyards to determine recommissioning capa-bility) and within a virtual breakers yard for disposal (to deter-mine scrap value) Increased opportunity would therefore be madefor designing the ship to meet a more rigorous set of customer-specified life-phase requirements and would represent a signifi-cant commercial advantage

It is also interesting at this point to note that a number of thecited papers have stated the need to avoid a reliance on computerprogrammers which in order to maintain even the simplest ofproduct data modeling systems seems unachievable

Conclusions

From the increasing amount of literature and the papers re-viewed within this paper related to the ship product model theprimary focus is on developing a standard representation for thedata contained within the model Despite not having yet finalizedthe standards for all aspects of the ship the STEP APs go a longway toward achieving this It is almost inconceivable to considerthat an alternative could compete against such a massive thrusttoward ship data standardization A number of instances havearisen however when the APs have been adhered to with theresult that ldquoflavorsrdquo or minor changes to the standard have beenrequired in order to utilize the structured well-defined and stan-dardized data within the legacy applications The question there-fore arises as to whether there is a requirement to standardize thelegacy applications such that they adhere to the data standard toenable a modular plug-in approach to ship design and simulation

Behavioral aspects have been considered within a number of thecited papers to be an important addition to the data in order toprovide the designer with additional feedback with respect to theoperation of the design This behavior may however be betterrepresented as high-level rules within a standard that are used todefine the operation of the ship rather than in existing standardsin order to minimize its impact on applications that have no needfor such data

A number of the tools and techniques discussed have described

the use of the ship STEP formats as being a mechanism for inte-grating existing legacy applications with a common model of shipproduct data Considerable benefit would be obtained from pro-viding similar integration between applications to progress fromthe limitations of discrete design and simulation toward having aholistic approach

The design tasks that are undertaken as part of the ship designprocess may well take a considerable amount of time and wouldconventionally result in ldquosnapshotsrdquo of the design artifact coin-ciding with the designer uploading data into the common modelA number of future directions have been discussed which wouldindividually require considerable development in order to imple-ment but which represent possible solutions to issues relating to

Continuous rather than ldquosnapshotrdquo ship product models Integration between the ship product model and the design

and simulation applications as well as across applications Removal of information translation problems through the

use of high-level graphical objects that are consistent betweenservers and applications

A collaborative framework on which to develop versionconflict and consistency management

Acknowledgments

The review was undertaken as part of an investigation intocommon model techniques within the VRShips-ROPAX2000project The authors gratefully acknowledge the support given bythe European Commission Community Research 5th Frameworkprogram under the area of Competitive and Sustainable Growthwhich provided the grant (G3RD-CT-2001-00506) that enabledthis work to be undertaken

References

BAUM S J AND RAMAKRISHNAN R 1997 Applying 3D product modelingtechnology in shipbuilding Marine Technology 34 1 56ndash65

CATLEY D 1999 Prototype STEP data exchanges in ship initial design andprovision of an application programmer interface to TRIBON Proceedings10th International Conference on Computer Applications in ShipbuildingJune Cambridge MA

CRAWFORD A K HARRINGTON G AMES R M AND VAN ESELTINE RT 1999 Neutral format data exchanges between ship product models andanalysis interfaces Proceedings 10th International Conference on Com-puter Applications in Shipbuilding June Cambridge MA

ERIKSTAD S O AND FATHI D E 1999 Applying the STEP shipbuildingprotocols as a basis for integrating existing in-house ship design applica-tions Proceedings 10th International Conference on Computer Applica-tions in Shipbuilding June Cambridge MA

GISCHNER B KASSEL B LAZO P WOOD R AND WYMAN J 2001 Evolution of STEP (ESTEP) exchange of shipbuilding productmodel data JOURNAL OF SHIP PRODUCTION 17 3 151ndash160

GRAU M AND KOCH T 1999 Applying STEP technology to shipbuildingProceedings 10th International Conference on Computer Applications inShipbuilding June Cambridge MA

HERZOG E AND TOumlRNE A 1999 A seed for a STEP application protocolfor systems engineering Proceedings 12th International Conference andWorkshop on the Engineering of Computer Based Systems Institute ofElectrical and Electronics Engineers Press Piscataway NJ 174ndash180

HIGNEY J T AND OUILETTE J J 1994 An engineering product modelbased on STEP protocols JOURNAL OF SHIP PRODUCTION 10 4 281ndash286

ISO 1996 Product Data Representation and Exchange Part 218 Ship Struc-

tures International Standards Organization Hamburg GermanyJOHANSSON K 1995 The product model as a central information source in

a shipbuilding environment Proceedings National Shipbuilding ResearchProgram 1995 Ship Production Symposium June Seattle WA

LAMB T CHUNG H AND SHIN J G 2000 A generic shipyard computermodel a tool for design for production Proceedings 7th IMDC NovemberKyung-Ju Korea

MARTIN D J 1980 The shipyard product information system as an aid toimplementing more productive strategies Proceedings Research and Engi-neering for Automation and Productivity in Shipbuilding IIT Research In-stitute October Chicago IL 81ndash101

POLINI M A AND MELAND K E 1997 The development and implemen-tation of a SMART product model for ship structure Proceedings 9thInternational Conference on Computer Applications in Shipbuilding Octo-ber Yokohama Japan

RANDO T C AND FERNHOLZ D 2000 MARITECHrsquos shipbuilding infor-mation infrastructure JOURNAL OF SHIP PRODUCTION 16 2 110ndash120

RANDO T C 2001 XML-based interoperability in the integrated shipbuild-ing environment (ISE) JOURNAL OF SHIP PRODUCTION 17 2 69ndash75

ROSS J M AND GARCIA L 1998 Making the jump to product modeltechnology JOURNAL OF SHIP PRODUCTION 14 1 15ndash26

ROSS J M AND ABAL D 2001 Practical use of 3D product modeling inthe small shipyard JOURNAL OF SHIP PRODUCTION 17 1 27ndash34

SCHMIDT W R VANDER J R AND SHIELDS V R 1990 Modelling andtransfer of product model digital data for the DDG 51 class destroyer pro-gram Proceedings National Shipbuilding Research Program 1990 ShipProduction Symposium August Milwaukee WI

SHIN Y AND HAN S H 1998 Data enhancement for sharing of shipdesign models Computer-Aided Design 30 12 931ndash941

VON HAARTMAN J KUUTTI I AND SCHAUMAN C 1994 Improving designproductivity with a product model for initial ship design Proceedings 8thInternational Conference on Computer Applications in Shipbuilding Sep-tember Bremen Germany

WELSH M LYNCH J AND BRUN B 1992 A data model for integration ofthe precommissioning life-cycle stages of the shipbuildingproduct JOURNAL

OF SHIP PRODUCTION 8 4 220ndash234WHITFIELD R I COATE S G DUFFY A H B AND HILLS

W 2000 Coordination approaches and systemsmdashpart I a strategic per-spective Research in Engineering Design 12 73ndash89

WYMAN J WOOLEY D GISCHNER B AND HOWELL J 1997 Development of STEP ship model database and translators fordata exchange between shipyards JOURNAL OF SHIP PRODUCTION 13 2111ndash124

Internet addresses

European Marine STEP Association httpemsagermanlloydorg

ISO STEP ship team http wwwnsnetcomNIDDESCt23html

Japan Marine Standards Association http wwwjecalsjipdecorjp

Korea STEP Centre httpksteporkr

(STEP) STEP is being developed to tackle the issues associatedwith cross-platform and cross-application development of any de-sign artifact through the production of a system-independent rep-resentation of the product data Data types such as geometrytopology functionality cost materials strength and so forth maybe modeled using STEP The STEP application layer contains theneutral data models and the implementation layer contains theactual implementation of these models The EXPRESS data mod-eling language was specifically developed for use within the ap-plication layer STEP has been described as ldquonot only for neutralfile exchange but also as a basis for implementing and sharingproduct databases and archivingrdquo (ISO 1996)

STEP is organized as the following series description methods(10s) implementation methods (20s) conformance testing meth-odology and framework (30s) integrated generic resources (40s)integrated application resources (100s) application protocols(200s) abstract test suites (300s) and application interpreted con-structs (500s)

Established in 1985 the NavyIndustry Digital Data ExchangeStandards Committee (NIDDESC) was involved in defining anactivity model and information models for ship design and con-struction The ISO is continuing this work through the STEP ShipTeam (ISO TC184SC4WG3T23) and has developed a numberof application protocols (APs) to represent various aspects of theship product model (Fig 2) Herzog and Torne (1999) defined anapplication protocol as being ldquoan information and process modelfor an engineering domainrdquo as well as providing additional defi-nitions to the various STEP series

The ship arrangements model (AP215) was developed to sup-port functional and detail design and production engineering life-cycle phases to support damage stability structural analysis in-terference analysis and so forth

The ship molded forms model (AP216) was designed to repre-

sent any geometrical shape for the hull form or internal surfacesthat may be used within the design production and operationlife-cycle phases for hydrodynamic and intact stability analysis

The ship structures model (AP218) defines the structural partsof the ship such as the hull structure superstructure and internalstructures for the predesign design production and inspectionlife-cycle phases The ship structures model has links to AP215and AP216

The ship mechanical systems model (AP226) is used to definemechanical components such as main and auxiliary engines fuelpumps air compressors and so forth AP226 also defines theconnectivity between components geometry materials topologyand operational characteristics for the mechanical components

The electrical design and installation model (AP212) defines theelectrical design and installation information for electrical cablesand harnessing for power transmission distribution generationand so forth The AP has been finalized

The piping and heating ventilation and air conditioning(HVAC) model (AP227) provides the information to support func-tional design detail design production fabrication assembly andtesting of piping heating ventilation and air conditioning TheAP supports pipe flow stress and interference analyses as well asenables configuration management version control change track-ing and the production of a bill of materials The AP has beenfinalized

The European Marine STEP Association (EMSA) the JapanMarine Standards Association (JMSA) and the Korea STEP Cen-tre organization have undertaken additional STEP standardizationwithin the shipbuilding industry For additional information re-garding the STEP shipbuilding APs implementation history andimplementation technology see Grau and Koch (1999)

Wyman et al (1997) stated ldquoShipyards will be required in thefuture to adhere to certain data standards To remain competitive

Fig 2 ISO application protocols for the ship product model

it will become necessary to support international data standardsSTEP is the proposed solution to this data exchange challenge andis the basis for the Advanced Research Projects Agency (ARPA)Maritech project ldquoDevelopment of STEP Ship Model Databaseand Translators for Data Exchange Between Shipyardsrdquo

The ship product was developed within the NEUTRABAS proj-ect (Welsh et al 1992) as a large number of interrelated physicaland abstract object instances that were described and representedusing natural language to describe the context in which the objectsare used graphical Nijssen information analysis method (NIAM)diagrams that illustrate the relationships between the objects (Fig3) and using the EXPRESS information modeling language

Rando (2001) described the use of an XML mapping of STEPinstead of EXPRESS for application-to-application interoperabil-ity Product data sharing was enabled using object serializationearly binding (OSEB) The objective of the standard was to pro-vide a means of serializing (or persistently storing) the state of(ship data) objects contained within an object-oriented databaseinto a neutral format that may be communicated from applicationto application One of the benefits of using XML as the informa-tion syntax is the amount of development of parsing queryingtransformation validation and presentation tools for the supportof the language across all aspects of the information technologyindustry Rando argues that the lack of such development and thereliance on special-purpose tools for STEP is one of the maininhibitors for the wide-scale acceptance of STEP technologywithin small and medium enterprises a point that is also made byRoss and Garcia (1998) OSEB is also geared toward being able torepresent a complex web of a large number of interrelated objectsas a series of more manageable chunks corresponding closely tothe userrsquos conceptual model The technique addresses one of themajor shortcomings related to STEP mapped using EXPRESS thereferences contained within a STEP-EXPRESS file restrictthe deconstruction of the file into more manageable chunks TheOSEB is illustrated within Fig 4 as a layered architectureThe first layer is an object model that defines the stored productdata using either EXPRESS or some other modeling languageThe second is described as the object model of the object inter-faces that are presented to applications The third is the objectmodel that underlies the classes that implement the OSEB ldquowrap-perrdquo The last is the object model that underlies the contents of theOSEB file itself

Finally Rando states that the objective of the OSEB was tominimize complexity and not the size of the XML files XML fileshave an unavoidable concession in that they are not specificallydesigned with compactness in mind due to the necessary inclusionof tags for instance and the lack of a binary format However thefiles are generally more readable and have a more obvious datahierarchy than EXPRESS

As well as developing standards for the mapping between XMLand STEP the Maritech Evolution of STEP (ESTEP) project(Gischner et al 2001) is continuing the development alongsideNIDDESC of the STEP shipbuilding product model standards anddata exchange of the Defence Advances Research Projects Agency(DARPA)Maritech MariSTEP project It is intended that ESTEPwill enable the efficient transfer of data among shipyards designagents and regulatory agencies

Gischner et al state that the current STEP APs take 3 to 5 yearsto develop and a great deal of time has been wasted developingsimilar standards by different industries Figure 5 illustrates theevolution of STEP from individual APs to a plug and play ap-proach through STEP modules

Advancements within both the ship design process and theavailability of cheap and powerful computational resources wereidentified as being the main drivers for the explosion in theamount of data contained within the ship product model (Catley

Fig 3 NIAM diagram of the NEUTRABAS high-level model

(Welsh 1992)

Fig 4 Layered object models in OSEB (Rando 2001)

Fig 5 STEP evolution (Gischner et al 2001)

1999) Catley states that a modern commercial vessel may beexpected to have an associated product data model 2 to 10gigabytes in size depending on its complexity Archiving ver-sion management and a robust product information solution areseen as essential requirements for a competitive shipbuilding in-dustry

Catley also discusses the translation of the AP215 compartmen-tation and AP216 ship molded forms schemas between theTRIBON system and either SEASPRITE or MariSTEP represen-tations Despite an increasing demand for the standardization ofproduct information to enable a common-model representationCatley recognizes the need for openness between specialist sub-contractors and partners in order to achieve common access Fig-ure 6 demonstrates the data flow between KCS and Calypso

Crawford et al (1999) defined a geometry object structure(GOBS) as being organizational to enable the data to be accessedby logical groupings or views topological to define the physicalrelationships between model elements and representational as aresult of the topology The resulting structure enabled both topo-logical views (a view of space not the space itself) and commonviews (compartments machinery spaces)

The development of ship product data formats and structureshas seen a great deal of focus on the ship STEP APs as well asusing EXPRESS and more recently XML as languages to modelthe data The ship STEP APs are clearly required to represent largeamounts of complex data However they also require a concertedand constant effort for finalization to avoid stagnation and toimprove general uptake across the industry These technologiesrely heavily on information technology which is notorious forprogressing more quickly than standards are produced Informa-tion technology considerations are therefore vital in the develop-ment of the data formats and the supporting mechanisms in orderto ensure that the standard does actually ensure the exchange ofproduct data In addition the operational maintenance and de-

commissioning life phases need to be thoroughly supported withinthese data structures

Ship product modeling

Martin (1980) was perhaps one of the first people to discussproduct information systems within shipbuilding and defined theproduct model as ldquoa logically-structured product-oriented data-baserdquo The product model term was however considered by Mar-tin to be a misnomer because the inclusion of nonproduct infor-mation specifically information relating to the yard facility wasconsidered to be one of the most important benefits of the systemThe product model was described as consisting of a number oflogically complete database subsets that contain overlappingstructural and material information for the product (Fig 7)

Martin realized that the product model was not simply a designtool but the information contained within it may be utilized byother yard functions to determine material requirements issuepurchase orders schedule activities and so forth Indeed since theadvent of numerically controlled machines the product model hasbeen viewed as a tool to automate parts of the production process(Johansson 1995 Ross amp Garcia 1998 Ross amp Abal 2001)

During the early 1990s Schmidt et al (1990) explored the fol-lowing options for the format for the product modeling and digitaldata transfer (DDT) within the US Navyrsquos AEGIS destroyerprogram

1 ldquoFlavoredrdquo initial graphic exchange specification (IGES) orstandard IGES ldquoFlavoringrdquo is the term used to define theprocess of augmenting the shortcomings of the implementedstandard in order to adapt it to the required task

2 Deferment until the completion of product definition ex-change standard (PDES) and its commercial implementa-tion

Fig 6 Data communication within Calypso project (Catley 1999)

3 Development of direct translators by a software developerspecializing in computer-aided design (CAD) direct transla-tors

4 Use of a neutral file that defines object data

Option 1 was rejected due to the associated shipyardsrsquo usingobject- rather than entity-oriented CAD software PDES was con-sidered to result with a delay of several years to implement aproduction translator hence option 2 was rejected Flexibility andexpansion were considered as restricting factors for option 3 Fi-nally option 4 was accepted due to the ability to develop a neutralmodel in the available time and the flexibility and future expan-sion of such a model

Schmidt et al also introduced the concept of the ldquodesign win-dowrdquo to transfer only the part of the model that was required ratherthan the entire model by specifying boundaries for the design zoneto be transferred One important aspect related to the transfer ofpartial data was the requirement for effective configuration man-agement such that changes made to the partial models were re-flected within the overall model Higney and Ouilette (1994) fol-lowed up the discussion of Schmidt with a description of a STEP-based product model for the AEGIS destroyer The product modelwas split into two parts a graphical model and a relational data-base containing nongraphical data NIAM diagrams were initiallyused to define the relationships within the relational database Themodel was developed based on the more fully developed STEPpiping AP However other APs were to be included when theybecame available

Welsh et al (1992) focussed on the precommissioning life-cyclestages of the shipbuilding product model while developing aframework to integrate disparate computer-based information sys-tems within the ESPRIT IIndashfunded NEUTRABAS project (Fig 8)The underlying mechanism to achieve this integration was a prod-uct model database to contain and manage neutral shipbuildingdata specifically spatial structural integration outfitting and en-gineering systems data It was identified that the structure of thedata was as important as the data themselves in order to effectively

manage the exchange of the data across various complex andheterogeneous ship development applications

Baum and Ramakrishnan (1997) suggested that associativitydata are extremely useful additions to the product model becausethey enable changes made to any one of the objects within thedatabase to be reflected in all associated objects Baum and Ra-makrishnan however did not suggest how this change propaga-tion is managed because without due coordination the impact ofthe change may result in chaotic behavior in complex systems(Whitfield et al 2000) Additionally there is no discussion regard-ing the requirement to simulate the reflected change using thesimulation software to determine the adequacy of the initialchange

The overall aims of the NEUTRABAS project were defined as

The standardization of the way in which information con-cerning marine-related products is represented

The development of standard methods for the exchangeand storage of product definition data in the marine industry

The specification and development of a suitable databasearchitecture that will facilitate the exchange and storage of suchproduct definition data

The implementation of a prototype data exchange andstorage system based on the previously defined database ar-chitecture which will demonstrate the feasibility of a trulyintegrated product life cycle

The authors identified a number of benefits associated with theabove aims such as the reduction of project time scales throughthe adoption of a single managed information store Managing theinformation within a single database is intended to avoid infor-mation mismatches and hence reduce the amount of rework which

Fig 7 Product information system layout (Martin 1980)

Fig 8 The NEUTRABAS system architecture (Welsh et al 1992)

has indeed been reported within a number of publications How-ever there has never been any consideration of the database con-trol mechanisms required to prevent the database from becomingan information bottleneck despite the assumption that a benefitwould be more effective information management or the in-creased duration associated with searching a single (extremely)large database for the required piece of data despite the assump-tion that a benefit would be rapid information disseminationThere is also the suggestion that using such a representation ofproduct data will avoid the need to transcribe the data betweendifferent application systems eliminating the introduction of errorthrough human interaction However a number of papers havesince reported on the requirement of application interfaces totranslate the product data into a format suitable for the intendedapplication Indeed Rando (2001) reported that in some cases adegree of human interaction has been required to ensure that thisprocess runs smoothly Conversely Catley (1999) suggested thatthe minimization of human interaction within the data exchangeprocess has resulted in more consistent design Finally the authorsidentified the benefit associated with improving the interface be-tween the supplier and the client through the introduction of elec-tronic product definition databases

The NEUTRABAS system was composed of an application-independent EXPRESS model defining the shipbuilding producta data dictionary to manage requests to the database a mappingbetween the model and the dictionary in the form of an EXPRESSimport tool the data management component to enable the cre-ation communication modification and querying of productmodel data a number of application interfaces to enable the in-dividual applications to interact with the database a number ofdatabase interfaces to enable communication between specific da-tabase management systems and the NEUTRABAS database anda database generator that enables the mapping of data within aspecific database to the data within the NEUTRABAS database

Von Haartman et al (1994) described the ship product modelwithin the NAPA project and realized the potential of the productmodel as a basis for concurrent engineering (CE) The use ofcomputers within the shipbuilding industry was previously re-stricted to the computationally intensive applications such as thecalculation of hydrostatics and stability These applications havehad a great deal of development to produce tools that represent andmodel a particular characteristic of the design quite accuratelyThey have generally received a great deal of investment of timeand money (Crawford et al 1999) Von Haartman et al suggest thatthe modern ship design process should ideally consist of a singlesystem that augments all of the disparate design tools but that oneshould recognize that such a system is far from reality The alter-native was to provide a framework to interlink these design toolsto give the impression of a single system The ship product modelwas the key to interlinking these tools

Von Haartman et al also stated ldquoAny model merely reflectsselected properties of the object it is intended to describe and theappropriate selection of properties is of central importance whendesigning the modelrdquo Within the NAPA ship product modelglobal properties of the ship were identified such as the maindimensions hull form and so forth and although not explicitlystated it is assumed that these global properties were chosenpartly for the reason that they are common among the design toolsbeing utilized These properties within the model may also be usedto evaluate the economic and technical requirements of the ship

Finally Von Haartman et al stated that the lack of detail of theglobal properties within the ship product model is not synonymouswith inaccuracy

Johansson (1995) described the challenge of modern shipbuild-ing as ldquoto manage and control the design and assembly process togain efficiency and short delivery timesrdquo By summarizing theshipbuilding process life-cycle stages as tendering design pro-duction planning materials finance and follow-up the require-ment for the effective management of the extremely large amountsof information was established in order to ensure the efficientorganization of the shipbuilding process Johansson suggested thatthis requirement could be satisfied only through the developmentof ldquoan information flow solution specifically designed for thisindustryrdquo and suggested that it was not sufficient just to automateexisting manual activities Rather the organization should beadapted to the use of new tools to streamline the information flowwherever possible The discussion appeared however to be re-stricted to information flows within a single shipbuilding organi-zation with the main focus on how the information may be utilizedto improve the production process

The product model concept was regarded by Johansson as beingone such tool whereby the organization may be streamlinedthroughout the precommissioning stages by providing a consis-tent model to enable well thought-out build strategies to be de-veloped early ordering of materials and material handling pre-fabrication preoutfitting and the use of numerically controlledmachines

Additional information was contained within the productmodel such as material codes weights surface treatments and soforth For this reason Johansson suggested that a more appropriateterm may be product information model because the modelshould contain all technical product definition data and may beused to provide for example graphical representations of geom-etry as well as lists and reports of material requirements Addi-tionally Johansson stated that the generation of a graphical rep-resentation should be produced only when it is required and to theextent that is suitable in order to avoid unnecessary computationThe graphical representation is regarded as secondary informationof the (primary) information stored in the product model Theinformation flow may be streamlined by the manipulation of theprimary information rather than the secondary information

Johansson also recognized that it was important that ldquoa productmodel based system must understand what the different parts ofthe system really represent and be able to interpret the rules andrestrictions connected to each type of objectrdquo

Erikstad and Fathi (1999) described how a STEP-based shipproduct model could be used within the ShipX project for theintegration of the data within a number of hydrodynamic analysisapplications for a ship The applications were previously devel-oped as stand-alone applications to specific aspects of the hydro-dynamic performance of the ship such as propulsion and seakeeping Previous integration among the applications wasachieved through the development of translators to allow for theexchange of information However the technique was difficult toimplement and maintain and was not considered to be seamlessThe communication of information among applications is clearlya central issue that has been discussed in a number of reports(Wyman et al 1997 Gischner et al 2001) Essentially the optionsare either to develop a direct interface between every pair ofcomponents or develop the interfaces based on a consistent inter-

face standard A common product model (Fig 9) was imple-mented within ShipX and from the application developmentviewpoint it enabled

Developers to concentrate more on the specific simulationproblem rather than the modeling of the data This benefit isrealized every time a particular application goes through rede-velopment or when new applications are developed

Guaranteed synchronization of data between the applica-tions and the product model Translators were previously usedto convert the product data to and from the required formats foreach application Changes could potentially be made to theproduct model after data translation to the application resultingin a discrepancy in the translated data The product modeltechnique ensures that each application has a common repre-sentation of the ship

Reuse of previous applications and graphical user inter-faces eliminating the need for the end user to relearn how touse the application

Despite integrating existing applications with the productmodel it is not clear within the ShipX project whether integrationexisted between applications For example two discrete applica-tions may be considered as damage stability assessment andevacuation simulation both integrated via the product model It ispossible to make assessments of the performance of the ship withrespect to both the damage stability and the evacuation in isola-tion via the integration with the product model However inte-gration is required between the damage stability and evacuationapplications in order to assess the evacuation time while compart-ments are flooding

The ShipX product model was developed using the relevantshipbuilding protocols developed within STEP which were imple-mented into a class library and stored using an object-orienteddatabase

Erikstad gave a number of useful guidelines for the develop-ment of the ShipX system

Simplicity The development of a comprehensive productmodel tool was considered to be prohibitive both from theaspects of timeliness and cost effectiveness Wherever pos-sible commercial off-the-shelf components were used Thedevelopment of the actual product model was undertaken usingthe STEP shipbuilding protocols rather than developing anin-house product model from scratch

Flexibility and extensibility The model was initially lim-ited to representing data that were specific to hydrodynamicperformance However consideration was given to the struc-ture of the model such that it could be extended to representother performance aspects Also the use of STEP to producethe common product model enables the scope of ShipX to beextended without restructuring the model The facade designpattern was also used to hide the complexity of the productmodel from the client applications define the correct usage ofthe product model by the client applications and enable theupdating of the product model without affecting the client ap-plications

Weak bindings to platform and programming language toenable the cross-platform and cross-language integration of theproduct model

Baum and Ramakrishnan (1997) regarded three-dimensionalproduct model technology as being fundamental for the imple-mentation of concurrent engineering (CE) within shipbuilding dueto the ability to develop capture represent integrate and coor-dinate data and permit simultaneous access to a number of usersBaum defined the product model as ldquothe integration of the 3Dgeometric model and non-geometric database informationrdquo whichmay be a logical integration of distributed information (Fig 10)

Simulation and interaction with the objects within the productmodel through the introduction of anthropomorphic models into avirtual environment to test functionality and operability were dis-cussed as being a useful technique to test the validity of the modelin a way similar to what would be achieved with the final productThe resulting model is essentially an electronic ldquomock-uprdquo Baumsuggested therefore that it is important to also represent the nor-mal behavior of the objects within the ship product model suchthat their behavior may also be analyzed enabling the product tobe designed manipulated analyzed constructed tested operatedsupported and disposed of in a virtual environment

Ross and Garcia (1998) and Ross and Abal (2001) discussed theutilization of product modeling technologies within two differentshipyard applications new build and conversion with the focus ofaiding shipyard managers with the decision to adopt such tech-nologies Ross suggests that the key characteristic of the productmodel for achieving a high level of integration is the adoption ofa single database allowing a number of designers to simulta-neously work on the same design through effective database man-agement and reducing or preventing altogether the inconsistency

Fig 9 From data translators to data integration within the ShipX project (Erikstad amp Fathi 1999)

of information A number of small shipyards that have incorpo-rated product-modeling technologies are used as case studies todiscuss the techniquersquos effectiveness with the conclusions thatthese shipyards have an improved production quality and signifi-cant savings in material cost labor cost construction cost andlabor hours Despite being a more complex representation thantraditional techniques Ross and Abal (2001) concluded that stafftraining was straightforward and that staff were considered com-petent after the design of the first vessel

Polini and Meland (1997) discussed the extension of a prototypeproduct modeling system through to the development of a pro-duction implementation that was capable of supporting concur-rent multiuser access Life-cycle data and behavior were modeledwithin the classes contained in the Smart Product Modelling(SPM) system The differentiation between a standard productmodel and an SPM system is shown in Fig 11 To appreciate theamount of effort involved in developing the SPM Polini andMeland state ldquoTo date nearly 45 man-years of software devel-opment have been invested in the SPM and its GUI approxi-mately 1000 classes with over 30000 methods have been devel-oped object oriented databases on the order of 25 gigabytes arecommonplace 24 concurrent users have modeled five shipclasses and tens of thousands of structural parts have been manu-facturedrdquo

This development was undertaken entirely within a shipyardwithout any commercial input Polini and Meland justified thisdevelopment by surveying the requirements of the shipyard andconcluding that there were no commercially available systemscapable of dealing with the degrees of specialization within theshipbuilding industry a point that has also been made by Jo-hansson (1995)

One of the questions asked by Shin and Han (1998) and others(Baum amp Ramakrishnan 1997) is whether it is possible to imple-ment paperless design because designers often spend a great dealof time trying to extract useful information from two-dimensionalpaper drawings The shipbuilding building blocks within the STEPshipbuilding APs were used as the basis to produce a ship product

model Shin used the STEP toolkit ST-Developer to produce C++classes using the EXPRESS data definition language for the mid-ship section of a bulk carrier

The classes were enhanced to enable all life-cycle product in-formation to be stored within a single data structure as well as fortranslating data formats by one-to-one mapping and includingexplicit information (Youngrsquos modulus Poissonrsquos ratio) from de-sign conventions available within the product model The systemarchitecture can be seen in Fig 12 This enhancement was re-quired because Shin suggested that it was not sufficient to simplytranslate data from a neutral format into the format required byeach application Rather it is a requirement of each applicationthat associated functions and information specific to each appli-cation is also incorporated into the model

This requirement for functional data was also discussed byCrawford et al (1999) Rather than relying on a flat neutral file tocontain geometry and topology information it was considereduseful that the topological data for example were provided withsome sort of intelligence to facilitate the translation between ap-plications The STEP standards were adhered to wherever pos-sible However achieving intelligent topology required extensionof the standards Crawford defined the Newport News Shipbuild-ing view of a product model as ldquoan all encompassing model of a

Fig 11 Product model definitions (Polini amp Meland 1997)

Fig 10 Representation of a ship three-dimensional product model (Baum amp Ramakrishnan 1997)

ship project taking advantage of the available computer toolsfor describing the geometry of a ship but it also includes allattributes necessary for the design production and operation ofthe shiprdquo

Again it was considered unlikely that the ship could be definedby a single computer system rather than by a number of moremanageable systems grouped according to some arbitrarily de-fined domains (Fig 13)

Crawford demonstrated the use of intelligent topological andgeometric STEP-based data through the use of the GOBS commonobject request brokerage architecture (CORBA) server that pro-vides a number of methods to enable legacy tools to extract therequired data Two analysis tools were used to model the ship

vulnerability and hydrostatics which obtained their data from theGOBS server The analysis concluded that within the majority ofthe cases the STEP standard for geometric data (Part 42) wassufficient to represent the geometry for the ship

Rando and Fernholz (2000) describes how the DARPA Mar-itech Shipbuilding Information Infrastructure Project (SHIIP) andShipbuilding Partners and Suppliers (SPARS) projects used acombination of component-based software internet protocols anda portable computing platform to satisfy the following shipbuild-ing information technical requirements

An information technology gap separates the large me-dium and small shipyards

Fig 12 System architecture of the STEP manager (Reprinted from Shin amp Han 1998 with permission from Elsevier)

The information technology staffs at most shipyards areexperts in shipbuilding process requirements but not in system-level computer technologies

Shipyard information systems must be reliable and main-tainable yet often need to be customized to suit an individualshipyard

As with many other projects (Rando 2001 Gischner et al 2001)integration within the shipbuilding industry was considered pos-sible only by the reuse of existing software components becausethe number of shipbuilding system requirements is so diverse thatit is unrealistic to assume that it is possible to produce a singleoverarching solution The integrated system was considered toconsist of a number of independent components to be assembledand reused by third parties in order to create a new complexsystem The initial task of the SHIIP project was to define areference architecture to support the composition of the indepen-dent components

The management of the product data was achieved using En-terprise Java Beans (EJB) that enable persistent storage secureaccess and load balancing for multiple users wishing to access thedata simultaneously At the start of the SHIIP project however

EJB was not available and the project relied instead on CORBAtechnology The project learned the following lessons from usingCORBA

Technology independence although useful in theoryshould not be pursued at the expense of developing workingimplementations

Technical interoperability is not a requirement for the de-velopment of an industrial information infrastructure Support-ing applications and software components for the informationinfrastructure are homogeneous enough to be implemented in asingle implementation technology

The Object Management Group (OMG) while advocatingseparation of components has produced in the arena of do-main standards wrappers for monolithic applications

OMG has been hampered by the inability to reach timelyconsensus

The Integrated Shipbuilding Environment (ISE) project withinthe Maritech Advanced Shipbuilding Enterprise (ASE) is usingXML as the basis for achieving interoperability between ship-building systems technologies specifically between application toapplication (Rando 2001) Rando differentiates this problem fromthat of other industries by stating that many of the applicationcomponents used within the shipbuilding industry have alreadybeen developed as well as the having little control over the de-velopment of these systems The shipbuilding product model mayalso contain millions of instances of a large number of differenttypes of information that need to be managed as they evolve overthe productrsquos life cycle It is also suggested that not only is therea need to rely on an enterprise system that augments the manyspecialist applications but due to the diversity of informationwithin the life cycle of the ship no single information system issufficient to deal with the entire ship product Indeed previousalliances between shipyards have been one-off solutions and thereis a definite requirement for a standardized effort for the shipproduct model

Rando identified a number of business drivers in order toachieve interoperability within the shipbuilding industry and pro-

Fig 13 Domain-based ship system (Crawford et al 1999)

Fig 14 ISE reference architecture three levels of interoperability (Rando 2001)

posed an architecture in order to respond to these drivers (Fig 14)The architecture represents three interoperability levels within theshipbuilding environment intercomponent refers to the interac-tions between the software components within a system intersys-tem refers to the interactions between the systems and is boundedby a business system domain and interenterprise interoperabilityrefers to interactions between business systems domains at differ-ent shipyards and organizations

The key elements for achieving this interoperability were acommon syntax using XML to facilitate communication a sharedstandard information model using STEP and an interoperabilityinfrastructure using web-based technologies XML is a neutralformat that may be viewed by humans (although this is not gen-erally a primary requirement) and that enables the sharing of in-formation between different technologies different operating sys-tems and different programming languages Five keyrequirements were identif ied to facilitate application-to-application integration

Should ldquoreuserdquo widely available standards-based tools Should be implementable with tools that allow for recon-

figuration by nonprogrammers Should support transformation to and from a canonical or

neutral format Should utilize a representation that is as simple and con-

cise as possible Should be able to marshalunmarshal every semantic con-

cept representable in the EXPRESS information modeling lan-guage (ISO 10303-11)

One of the most significant issues relating to the use and inte-gration of ship product models with existing applications appearsto be the need to ldquoflavorrdquo the model and specifications to suit theparticular requirements of the design and simulation applicationsWithout these embellishments the fully automated data integra-tion appears quite often difficult to achieve There are howeverconflicting opinions regarding the effectiveness of automating thisprocess generally arising due to the complexity of the problem andthe level of support The application of ldquoflavoredrdquo standards doeshowever entirely go against the point of creating a standard es-pecially when it is with respect to the transfer of product data Itcould therefore be concluded that the solution to the effectiveintegration of STEP lies not in the modification of a new tech-nology to satisfy the requirements of legacy applications but inthe updating of the legacy applications to satisfy the new technol-ogy

Life-cycle issues

The NEUTRABAS project (Welsh et al 1992) was limited tothe precommissioning stages that is marketing conceptual de-sign detailed design drafting materials ordering productionplanning and control scheduling and quality control However itwas recognized that significant benefits would be achievedthrough extending the life cycle through to disposal Welsh et alqualified the limitation to the precommissioning stages by statingthat ldquothe definition and implementation of a complete product datamodel covering all of these aspects of the life-cycle of an engi-neering product as complex as a ship is an onerous task and one

which would require the commitment of a vast amount of time andeffortrdquo

Limiting the project to the precommissioning stages would ap-pear to have been a wise judgment because in the 10 years fol-lowing this project the standards created to describe the shipproduct model have still not yet been finalized

Welsh et al suggest that the physical representation of the prod-uct within each life cycle stage would ldquonormally be unchanged inthe global sense although the information associated with theproduct and the techniques used to represent it will vary consid-erablyrdquo that is the information contained within the productmodel would mature as more detail becomes available as well asrequiring different viewpoints at each life-cycle stage The productmodel must therefore be developed not only with the associateddata and structure in mind but also with the life-cycle stages Toenable the support of the precommissioning life-cycle stagesWelsh et al identified four views that need to be supported by theship product model

Marketing-oriented view Management-oriented view Design-oriented view Production-oriented view

Von Haartman et al (1994) briefly discussed life phase issues ofthe ship product model and suggested that a number of systemsmodel the design with too much detail and hence are not appli-cable to the concept design stage A solution to this was thedevelopment of a concept design product model that could then betransferred to the detailed design stage It is not clear from thiswhether Von Haartman et al were proposing separate models forthe two stages or if the detail product model would simply consistof the concept product model plus the additional required detail

The mechanism of having multiple different views for the shar-ing of a product model among designers and production engineersfor example has been considered and implemented in a number ofcases (Polini amp Meland 1997 Johansson 1995) Johansson indi-cated that it is common for parts of the product to be in differentlife-cycle stages at the same time that is the ldquomanufacture of onepart of the product is going on at the same time as the detaileddesign of anotherrdquo This is one aspect of concurrent engineeringwith the result of reducing the lead times because the manufactureof the product has started before the design of the product has beencompleted However it is necessary to ensure both that manufac-turing starts only on parts that require no further design and thatother parts that are currently being designed do not propagatechanges to the manufactured parts The management and controlof the information flow were recognized as being the key elementsin increasing the overlapping of life cycles However no expla-nation was given by Johansson regarding the nature of the man-agement other than through the relationships between the objectscontained within the model These relationships were described asa mechanism to enable both interdisciplinary and cross-disciplinary communication among designers

The three-dimensional product model was described by Baumand Ramakrishnan (1997) as being a mechanism to enable a num-ber of different life-cycle stage simulations such as interferencechecking crew traffic flow studies yard-specific designs and fi-nite capacity scheduling through the use of a virtual environmentdesign review technology using data contained within the productmodel (Fig 15)

Coupled with simulation-based design (SBD) Baum describedthe combined technology as ldquothe new frontierrdquo that would enablethe virtual prototyping of the ship which previously could not beachieved due to the cost and complexity More importantly Baumrecognized that just as interference-checking software may beused to determine discrepancies between geometric parts duringthe design and production phases SBD may be used to reduce oreliminate design errors that would have previously have beendiscovered years later in the operational stage for example Es-sentially SBD and product modeling enable the validation of thedesign production and operation stages of the ship product

Baum also finally suggested that the product model provides asignificant benefit to the owneroperator by enabling the analysisand support of life-cycle maintenance

A generic shipyard computer modeling tool for evaluating de-sign for production (DFP) is discussed by Lamb et al (2000) Thetool enables shipyards to be modeled such that the impacts ofchanges to the ship design may be determined on the basis of theresulting material manpower and schedule The shipyard modelrepresents details of the buildingsmdashtheir arrangement and size aswell as equipment capacity and flow The tool also enables aninvestigation of the necessary changes required for a shipyard inorder to produce a new design The key foundations in order toevaluate these impacts are the interim product catalogue and thebuild strategy approach

Lamb et al identified a number of important concepts for DFP

All designs should be prepared to suit a shipyardrsquos facili-ties and preferred production methods

DFP takes into account production methods and tech-niques that reduce the product work content but still meet thespecified design requirements and quality

DFP must be incorporated into a design from the start Traditional engineering leaves it up to another department

such as production or manufacturing engineering to developthe technical documentation required for the production work-ers This is an unnecessary duplication of effort and is a nonndashvalue-added task that takes time

An objective of the CE approach is to accommodate DFPby bringing all the necessary people together right from dayone on a project

The time to influence the cost of a product is during theearly stages After the design has been developed in conceptmost of the opportunity to positively affect cost is gone

World-class ship designers know how their shipyardbuilds ships and design accordingly Many ship designers donot consider this and the designs may or may not be efficientlybuilt in their facilities More shipbuilders have taken steps toremedy this situation through the use of the build strategyapproach

Engineering should be prepared and transmitted to theusers in a way that best suits block construction advanced andzone outfitting

An object-oriented approach was adopted for the constructionof the model (Fig 16) The model represents shipyards worksta-tions products equipment processes manufacturing processesmaterial handling processes and interim products The tool wasapplied to the evaluation of two design alternatives for the bottomstructure of a ship The authors demonstrated that the tool enabledreliable evaluations of the man-hours for manufacturing and ma-terial handling such that the best design alternative could beadopted

Future directions

It is believed that the ship STEP APs will become the standardunit of shipbuilding data but that it will probably be an evolution-ary process as advances in technology and modeling capabilitiesand requirements are incorporated It is however crucial that thedevelopment of the standards comes to a timely consensus at eachevolutionary stage The literature reviewed has discussed the useof ldquointelligentrdquo data the inclusion of useful functionality accord-ing to the data type and of behavioral aspects It is anticipated thatthis functionality behavioral aspects and so forth will increas-

Fig 15 Ship design workflow using three-dimensional product model (Baum amp Ramakrishnan 1997)

ingly become part of the model to the extent that the model nolonger has any need for interfaces and translators to legacy soft-ware For example the piping model would automatically calcu-late interferences and the structures model would automaticallycalculate stress characteristics The simulation would essentiallybe part of the model and the model would contain additionalinformation and knowledge to effectively manage the simulationThis is not to say that the model would become a monolithicsystem despite such a system being potentially computationallyviable in 10 years Rather than being monolithic current andfuture distributed information technologies such as EnterpriseJava Beans may be utilized in order to distribute the model acrossa network while giving the impression to the user that the systemis monolithic Ship product data and functionality would be dis-tributed either within a single company or as partnerships withother companies

In a similar way that the ship product data has become stan-dardized benefits are to be gained from standardizing the inter-faces between applications to support the flow of standardizeddata and achieve a truly seamless integration The unfortunateshortcoming of application standardization is the necessity to re-develop the legacy systems to support this level of integration

The VRShips project addresses the management of ship productdata within a neutrally formatted common model The geometry

data contained within the common model are based on STEPAP203 are described using XML and are considered as beingcommon data if two or more applications access it Integration isprovided between the legacy applications and the common modelvia ldquogeneric wrappersrdquo that provide the general management re-quired in order to operate the applications The wrappers convertthe data to and from the native format using modular conversionalgorithms that can be plugged into the wrappers and provide thedomain-specific management for the applications Data are auto-matically downloaded from the common model and converted intothe native format when the application is started When the appli-cation is complete the designer has the option of undertaking thereverse process to convert the data back into the neutral format andupload into the common model Despite being a complex processconverters have been produced for a number of design applica-tions such as Tribon and AVPro and have been demonstrated tooperate without the need for manual interaction However theissues relating to the lack of integration between tools and con-tinuous product models remain to be addressed

The VRShips system also has an additional management layerconsisting of a process controller and an inference engine that arejointly responsible for maintaining data consistency and versionconstraint and process management Visualizing of product datavia the legacy applications is managed through the exporting of

Fig 16 Object diagram for generic shipyard computer model (Lamb et al 2000)

the displays via a virtual interaction environment These controlmechanisms ensure that designers may modify the data containedwithin the common model from any location either organization-ally or geographically distributed with network access using anapplication that they are familiar with and that any changes madeto the product model are correctly propagated such that the dataremain consistent

Every product modeling tool and technique discussed withinthis review is common from the perspective that the data containedwithin the model are a ldquosnapshotrdquo of the actual design activity Forinstance a designer may download data from the ship productmodel for use within a general design package which may take aweek to design During this design period the data within theproduct model do not change until the designer decides that thedesign process is complete and the data are uploaded into theproduct model The product model therefore does not contain acontinuous representation of either the design work that is cur-rently being undertaken or the form that the data are in This posesa number of significant project management issues with respect toversion control consistency management and conflict resolutionespecially in the situation where the design process is being un-dertaken in a distributed manner as is increasingly becomingcommon

A paradigm shift in the techniques used to enable the distributeddesign of ships while enabling a continuous product model andfacilitating the management of conflicts and consistency would bethe adoption of a technology that is more often seen within thecomputer games industry Graphics servers are commonly usedwithin the games industry to enable the user to immerse them-selves within an environment and interact both with the environ-ment and with other users High-level graphical objects are com-municated between the server side and the client side rather thanusing structured files This technique bypasses the need to trans-late the communicated data into the client side format alleviatingunnecessary computation It also results in a model containedwithin the server and represented within the clients that is a con-tinuous depiction of what everyone is undertaking The ship prod-uct data would remain within the ship STEP formats Howeverthe description method would be the graphical object representa-tion that would also exhibit behavioral properties Within the ship-building context individual graphics servers would represent do-mains similar to those identified by Crawford et al (1999) Clientsconnecting to the servers would immediately get an up-to-dateview of that particular domain which would be consistent with theviews of all of the other clients The client software would operatein a manner similar to conventional design applications There isalso clearly a requirement for integration between the differentdomain servers to enable conflicts to be resolved across domainsSimulation servers would integrate all of the scenarios that wouldenable an evaluation of the performance within any particular lifephase There would still remain the need to provide an effectivemanagement of different versions as well as a high-level coordi-nation structure to manage conflicts constraints design goals andcollaboration among designers However the underlying frame-work would provide the basis on which to construct this Despitebeing a significant step-change compared with current practicethis future technique proposes a viable solution to the effectivemanagement of a ship product model that may be manipulated andoperated upon in a distributed manner

This type of architecture does however raise a number of

issues relating to partnerships between the shipbuilding industryand the shipbuilding software industry because the system wouldrepresent an amalgamation of existing design and simulation ap-plications into a number of domain-specific servers The intellec-tual property rights as well as the ownership of both the technol-ogy and the data contained would clearly need to be resolved Inaddition the system calls upon the need to implement a standardfor the communication of the graphical objects that is both secureand robust whereas the standard for the data may be ldquoflavoredrdquoand managed effectively within the system via the ability to dy-namically load classes

Just as many of the precommissioning life phases are currentlybeing modeled it is anticipated that the rather poorly supportedpostcommissioning life phases will be catered for The most sig-nificant difference between pre- and postcommissioning is that itwill be the ship product model in its entirety that will be consid-ered For example there currently appears to be a significantopportunity for the specialization of the immersion of an entireship product model into an artificial environment to determine theoperational performance both at virtual sea (modeling existingshipping lanes to determine sea-keeping characteristics) within avirtual port (modeling existing ports to determine cargo-handlingcharacteristics) within a virtual shipyard for recommissioning(modeling existing shipyards to determine recommissioning capa-bility) and within a virtual breakers yard for disposal (to deter-mine scrap value) Increased opportunity would therefore be madefor designing the ship to meet a more rigorous set of customer-specified life-phase requirements and would represent a signifi-cant commercial advantage

It is also interesting at this point to note that a number of thecited papers have stated the need to avoid a reliance on computerprogrammers which in order to maintain even the simplest ofproduct data modeling systems seems unachievable

Conclusions

From the increasing amount of literature and the papers re-viewed within this paper related to the ship product model theprimary focus is on developing a standard representation for thedata contained within the model Despite not having yet finalizedthe standards for all aspects of the ship the STEP APs go a longway toward achieving this It is almost inconceivable to considerthat an alternative could compete against such a massive thrusttoward ship data standardization A number of instances havearisen however when the APs have been adhered to with theresult that ldquoflavorsrdquo or minor changes to the standard have beenrequired in order to utilize the structured well-defined and stan-dardized data within the legacy applications The question there-fore arises as to whether there is a requirement to standardize thelegacy applications such that they adhere to the data standard toenable a modular plug-in approach to ship design and simulation

Behavioral aspects have been considered within a number of thecited papers to be an important addition to the data in order toprovide the designer with additional feedback with respect to theoperation of the design This behavior may however be betterrepresented as high-level rules within a standard that are used todefine the operation of the ship rather than in existing standardsin order to minimize its impact on applications that have no needfor such data

A number of the tools and techniques discussed have described

the use of the ship STEP formats as being a mechanism for inte-grating existing legacy applications with a common model of shipproduct data Considerable benefit would be obtained from pro-viding similar integration between applications to progress fromthe limitations of discrete design and simulation toward having aholistic approach

The design tasks that are undertaken as part of the ship designprocess may well take a considerable amount of time and wouldconventionally result in ldquosnapshotsrdquo of the design artifact coin-ciding with the designer uploading data into the common modelA number of future directions have been discussed which wouldindividually require considerable development in order to imple-ment but which represent possible solutions to issues relating to

Continuous rather than ldquosnapshotrdquo ship product models Integration between the ship product model and the design

and simulation applications as well as across applications Removal of information translation problems through the

use of high-level graphical objects that are consistent betweenservers and applications

A collaborative framework on which to develop versionconflict and consistency management

Acknowledgments

The review was undertaken as part of an investigation intocommon model techniques within the VRShips-ROPAX2000project The authors gratefully acknowledge the support given bythe European Commission Community Research 5th Frameworkprogram under the area of Competitive and Sustainable Growthwhich provided the grant (G3RD-CT-2001-00506) that enabledthis work to be undertaken

References

BAUM S J AND RAMAKRISHNAN R 1997 Applying 3D product modelingtechnology in shipbuilding Marine Technology 34 1 56ndash65

CATLEY D 1999 Prototype STEP data exchanges in ship initial design andprovision of an application programmer interface to TRIBON Proceedings10th International Conference on Computer Applications in ShipbuildingJune Cambridge MA

CRAWFORD A K HARRINGTON G AMES R M AND VAN ESELTINE RT 1999 Neutral format data exchanges between ship product models andanalysis interfaces Proceedings 10th International Conference on Com-puter Applications in Shipbuilding June Cambridge MA

ERIKSTAD S O AND FATHI D E 1999 Applying the STEP shipbuildingprotocols as a basis for integrating existing in-house ship design applica-tions Proceedings 10th International Conference on Computer Applica-tions in Shipbuilding June Cambridge MA

GISCHNER B KASSEL B LAZO P WOOD R AND WYMAN J 2001 Evolution of STEP (ESTEP) exchange of shipbuilding productmodel data JOURNAL OF SHIP PRODUCTION 17 3 151ndash160

GRAU M AND KOCH T 1999 Applying STEP technology to shipbuildingProceedings 10th International Conference on Computer Applications inShipbuilding June Cambridge MA

HERZOG E AND TOumlRNE A 1999 A seed for a STEP application protocolfor systems engineering Proceedings 12th International Conference andWorkshop on the Engineering of Computer Based Systems Institute ofElectrical and Electronics Engineers Press Piscataway NJ 174ndash180

HIGNEY J T AND OUILETTE J J 1994 An engineering product modelbased on STEP protocols JOURNAL OF SHIP PRODUCTION 10 4 281ndash286

ISO 1996 Product Data Representation and Exchange Part 218 Ship Struc-

tures International Standards Organization Hamburg GermanyJOHANSSON K 1995 The product model as a central information source in

a shipbuilding environment Proceedings National Shipbuilding ResearchProgram 1995 Ship Production Symposium June Seattle WA

LAMB T CHUNG H AND SHIN J G 2000 A generic shipyard computermodel a tool for design for production Proceedings 7th IMDC NovemberKyung-Ju Korea

MARTIN D J 1980 The shipyard product information system as an aid toimplementing more productive strategies Proceedings Research and Engi-neering for Automation and Productivity in Shipbuilding IIT Research In-stitute October Chicago IL 81ndash101

POLINI M A AND MELAND K E 1997 The development and implemen-tation of a SMART product model for ship structure Proceedings 9thInternational Conference on Computer Applications in Shipbuilding Octo-ber Yokohama Japan

RANDO T C AND FERNHOLZ D 2000 MARITECHrsquos shipbuilding infor-mation infrastructure JOURNAL OF SHIP PRODUCTION 16 2 110ndash120

RANDO T C 2001 XML-based interoperability in the integrated shipbuild-ing environment (ISE) JOURNAL OF SHIP PRODUCTION 17 2 69ndash75

ROSS J M AND GARCIA L 1998 Making the jump to product modeltechnology JOURNAL OF SHIP PRODUCTION 14 1 15ndash26

ROSS J M AND ABAL D 2001 Practical use of 3D product modeling inthe small shipyard JOURNAL OF SHIP PRODUCTION 17 1 27ndash34

SCHMIDT W R VANDER J R AND SHIELDS V R 1990 Modelling andtransfer of product model digital data for the DDG 51 class destroyer pro-gram Proceedings National Shipbuilding Research Program 1990 ShipProduction Symposium August Milwaukee WI

SHIN Y AND HAN S H 1998 Data enhancement for sharing of shipdesign models Computer-Aided Design 30 12 931ndash941

VON HAARTMAN J KUUTTI I AND SCHAUMAN C 1994 Improving designproductivity with a product model for initial ship design Proceedings 8thInternational Conference on Computer Applications in Shipbuilding Sep-tember Bremen Germany

WELSH M LYNCH J AND BRUN B 1992 A data model for integration ofthe precommissioning life-cycle stages of the shipbuildingproduct JOURNAL

OF SHIP PRODUCTION 8 4 220ndash234WHITFIELD R I COATE S G DUFFY A H B AND HILLS

W 2000 Coordination approaches and systemsmdashpart I a strategic per-spective Research in Engineering Design 12 73ndash89

WYMAN J WOOLEY D GISCHNER B AND HOWELL J 1997 Development of STEP ship model database and translators fordata exchange between shipyards JOURNAL OF SHIP PRODUCTION 13 2111ndash124

Internet addresses

European Marine STEP Association httpemsagermanlloydorg

ISO STEP ship team http wwwnsnetcomNIDDESCt23html

Japan Marine Standards Association http wwwjecalsjipdecorjp

Korea STEP Centre httpksteporkr

it will become necessary to support international data standardsSTEP is the proposed solution to this data exchange challenge andis the basis for the Advanced Research Projects Agency (ARPA)Maritech project ldquoDevelopment of STEP Ship Model Databaseand Translators for Data Exchange Between Shipyardsrdquo

The ship product was developed within the NEUTRABAS proj-ect (Welsh et al 1992) as a large number of interrelated physicaland abstract object instances that were described and representedusing natural language to describe the context in which the objectsare used graphical Nijssen information analysis method (NIAM)diagrams that illustrate the relationships between the objects (Fig3) and using the EXPRESS information modeling language

Rando (2001) described the use of an XML mapping of STEPinstead of EXPRESS for application-to-application interoperabil-ity Product data sharing was enabled using object serializationearly binding (OSEB) The objective of the standard was to pro-vide a means of serializing (or persistently storing) the state of(ship data) objects contained within an object-oriented databaseinto a neutral format that may be communicated from applicationto application One of the benefits of using XML as the informa-tion syntax is the amount of development of parsing queryingtransformation validation and presentation tools for the supportof the language across all aspects of the information technologyindustry Rando argues that the lack of such development and thereliance on special-purpose tools for STEP is one of the maininhibitors for the wide-scale acceptance of STEP technologywithin small and medium enterprises a point that is also made byRoss and Garcia (1998) OSEB is also geared toward being able torepresent a complex web of a large number of interrelated objectsas a series of more manageable chunks corresponding closely tothe userrsquos conceptual model The technique addresses one of themajor shortcomings related to STEP mapped using EXPRESS thereferences contained within a STEP-EXPRESS file restrictthe deconstruction of the file into more manageable chunks TheOSEB is illustrated within Fig 4 as a layered architectureThe first layer is an object model that defines the stored productdata using either EXPRESS or some other modeling languageThe second is described as the object model of the object inter-faces that are presented to applications The third is the objectmodel that underlies the classes that implement the OSEB ldquowrap-perrdquo The last is the object model that underlies the contents of theOSEB file itself

Finally Rando states that the objective of the OSEB was tominimize complexity and not the size of the XML files XML fileshave an unavoidable concession in that they are not specificallydesigned with compactness in mind due to the necessary inclusionof tags for instance and the lack of a binary format However thefiles are generally more readable and have a more obvious datahierarchy than EXPRESS

As well as developing standards for the mapping between XMLand STEP the Maritech Evolution of STEP (ESTEP) project(Gischner et al 2001) is continuing the development alongsideNIDDESC of the STEP shipbuilding product model standards anddata exchange of the Defence Advances Research Projects Agency(DARPA)Maritech MariSTEP project It is intended that ESTEPwill enable the efficient transfer of data among shipyards designagents and regulatory agencies

Gischner et al state that the current STEP APs take 3 to 5 yearsto develop and a great deal of time has been wasted developingsimilar standards by different industries Figure 5 illustrates theevolution of STEP from individual APs to a plug and play ap-proach through STEP modules

Advancements within both the ship design process and theavailability of cheap and powerful computational resources wereidentified as being the main drivers for the explosion in theamount of data contained within the ship product model (Catley

Fig 3 NIAM diagram of the NEUTRABAS high-level model

(Welsh 1992)

Fig 4 Layered object models in OSEB (Rando 2001)

Fig 5 STEP evolution (Gischner et al 2001)

1999) Catley states that a modern commercial vessel may beexpected to have an associated product data model 2 to 10gigabytes in size depending on its complexity Archiving ver-sion management and a robust product information solution areseen as essential requirements for a competitive shipbuilding in-dustry

Catley also discusses the translation of the AP215 compartmen-tation and AP216 ship molded forms schemas between theTRIBON system and either SEASPRITE or MariSTEP represen-tations Despite an increasing demand for the standardization ofproduct information to enable a common-model representationCatley recognizes the need for openness between specialist sub-contractors and partners in order to achieve common access Fig-ure 6 demonstrates the data flow between KCS and Calypso

Crawford et al (1999) defined a geometry object structure(GOBS) as being organizational to enable the data to be accessedby logical groupings or views topological to define the physicalrelationships between model elements and representational as aresult of the topology The resulting structure enabled both topo-logical views (a view of space not the space itself) and commonviews (compartments machinery spaces)

The development of ship product data formats and structureshas seen a great deal of focus on the ship STEP APs as well asusing EXPRESS and more recently XML as languages to modelthe data The ship STEP APs are clearly required to represent largeamounts of complex data However they also require a concertedand constant effort for finalization to avoid stagnation and toimprove general uptake across the industry These technologiesrely heavily on information technology which is notorious forprogressing more quickly than standards are produced Informa-tion technology considerations are therefore vital in the develop-ment of the data formats and the supporting mechanisms in orderto ensure that the standard does actually ensure the exchange ofproduct data In addition the operational maintenance and de-

commissioning life phases need to be thoroughly supported withinthese data structures

Ship product modeling

Martin (1980) was perhaps one of the first people to discussproduct information systems within shipbuilding and defined theproduct model as ldquoa logically-structured product-oriented data-baserdquo The product model term was however considered by Mar-tin to be a misnomer because the inclusion of nonproduct infor-mation specifically information relating to the yard facility wasconsidered to be one of the most important benefits of the systemThe product model was described as consisting of a number oflogically complete database subsets that contain overlappingstructural and material information for the product (Fig 7)

Martin realized that the product model was not simply a designtool but the information contained within it may be utilized byother yard functions to determine material requirements issuepurchase orders schedule activities and so forth Indeed since theadvent of numerically controlled machines the product model hasbeen viewed as a tool to automate parts of the production process(Johansson 1995 Ross amp Garcia 1998 Ross amp Abal 2001)

During the early 1990s Schmidt et al (1990) explored the fol-lowing options for the format for the product modeling and digitaldata transfer (DDT) within the US Navyrsquos AEGIS destroyerprogram

1 ldquoFlavoredrdquo initial graphic exchange specification (IGES) orstandard IGES ldquoFlavoringrdquo is the term used to define theprocess of augmenting the shortcomings of the implementedstandard in order to adapt it to the required task

2 Deferment until the completion of product definition ex-change standard (PDES) and its commercial implementa-tion

Fig 6 Data communication within Calypso project (Catley 1999)

3 Development of direct translators by a software developerspecializing in computer-aided design (CAD) direct transla-tors

4 Use of a neutral file that defines object data

Option 1 was rejected due to the associated shipyardsrsquo usingobject- rather than entity-oriented CAD software PDES was con-sidered to result with a delay of several years to implement aproduction translator hence option 2 was rejected Flexibility andexpansion were considered as restricting factors for option 3 Fi-nally option 4 was accepted due to the ability to develop a neutralmodel in the available time and the flexibility and future expan-sion of such a model

Schmidt et al also introduced the concept of the ldquodesign win-dowrdquo to transfer only the part of the model that was required ratherthan the entire model by specifying boundaries for the design zoneto be transferred One important aspect related to the transfer ofpartial data was the requirement for effective configuration man-agement such that changes made to the partial models were re-flected within the overall model Higney and Ouilette (1994) fol-lowed up the discussion of Schmidt with a description of a STEP-based product model for the AEGIS destroyer The product modelwas split into two parts a graphical model and a relational data-base containing nongraphical data NIAM diagrams were initiallyused to define the relationships within the relational database Themodel was developed based on the more fully developed STEPpiping AP However other APs were to be included when theybecame available

Welsh et al (1992) focussed on the precommissioning life-cyclestages of the shipbuilding product model while developing aframework to integrate disparate computer-based information sys-tems within the ESPRIT IIndashfunded NEUTRABAS project (Fig 8)The underlying mechanism to achieve this integration was a prod-uct model database to contain and manage neutral shipbuildingdata specifically spatial structural integration outfitting and en-gineering systems data It was identified that the structure of thedata was as important as the data themselves in order to effectively

manage the exchange of the data across various complex andheterogeneous ship development applications

Baum and Ramakrishnan (1997) suggested that associativitydata are extremely useful additions to the product model becausethey enable changes made to any one of the objects within thedatabase to be reflected in all associated objects Baum and Ra-makrishnan however did not suggest how this change propaga-tion is managed because without due coordination the impact ofthe change may result in chaotic behavior in complex systems(Whitfield et al 2000) Additionally there is no discussion regard-ing the requirement to simulate the reflected change using thesimulation software to determine the adequacy of the initialchange

The overall aims of the NEUTRABAS project were defined as

The standardization of the way in which information con-cerning marine-related products is represented

The development of standard methods for the exchangeand storage of product definition data in the marine industry

The specification and development of a suitable databasearchitecture that will facilitate the exchange and storage of suchproduct definition data

The implementation of a prototype data exchange andstorage system based on the previously defined database ar-chitecture which will demonstrate the feasibility of a trulyintegrated product life cycle

The authors identified a number of benefits associated with theabove aims such as the reduction of project time scales throughthe adoption of a single managed information store Managing theinformation within a single database is intended to avoid infor-mation mismatches and hence reduce the amount of rework which

Fig 7 Product information system layout (Martin 1980)

Fig 8 The NEUTRABAS system architecture (Welsh et al 1992)

has indeed been reported within a number of publications How-ever there has never been any consideration of the database con-trol mechanisms required to prevent the database from becomingan information bottleneck despite the assumption that a benefitwould be more effective information management or the in-creased duration associated with searching a single (extremely)large database for the required piece of data despite the assump-tion that a benefit would be rapid information disseminationThere is also the suggestion that using such a representation ofproduct data will avoid the need to transcribe the data betweendifferent application systems eliminating the introduction of errorthrough human interaction However a number of papers havesince reported on the requirement of application interfaces totranslate the product data into a format suitable for the intendedapplication Indeed Rando (2001) reported that in some cases adegree of human interaction has been required to ensure that thisprocess runs smoothly Conversely Catley (1999) suggested thatthe minimization of human interaction within the data exchangeprocess has resulted in more consistent design Finally the authorsidentified the benefit associated with improving the interface be-tween the supplier and the client through the introduction of elec-tronic product definition databases

The NEUTRABAS system was composed of an application-independent EXPRESS model defining the shipbuilding producta data dictionary to manage requests to the database a mappingbetween the model and the dictionary in the form of an EXPRESSimport tool the data management component to enable the cre-ation communication modification and querying of productmodel data a number of application interfaces to enable the in-dividual applications to interact with the database a number ofdatabase interfaces to enable communication between specific da-tabase management systems and the NEUTRABAS database anda database generator that enables the mapping of data within aspecific database to the data within the NEUTRABAS database

Von Haartman et al (1994) described the ship product modelwithin the NAPA project and realized the potential of the productmodel as a basis for concurrent engineering (CE) The use ofcomputers within the shipbuilding industry was previously re-stricted to the computationally intensive applications such as thecalculation of hydrostatics and stability These applications havehad a great deal of development to produce tools that represent andmodel a particular characteristic of the design quite accuratelyThey have generally received a great deal of investment of timeand money (Crawford et al 1999) Von Haartman et al suggest thatthe modern ship design process should ideally consist of a singlesystem that augments all of the disparate design tools but that oneshould recognize that such a system is far from reality The alter-native was to provide a framework to interlink these design toolsto give the impression of a single system The ship product modelwas the key to interlinking these tools

Von Haartman et al also stated ldquoAny model merely reflectsselected properties of the object it is intended to describe and theappropriate selection of properties is of central importance whendesigning the modelrdquo Within the NAPA ship product modelglobal properties of the ship were identified such as the maindimensions hull form and so forth and although not explicitlystated it is assumed that these global properties were chosenpartly for the reason that they are common among the design toolsbeing utilized These properties within the model may also be usedto evaluate the economic and technical requirements of the ship

Finally Von Haartman et al stated that the lack of detail of theglobal properties within the ship product model is not synonymouswith inaccuracy

Johansson (1995) described the challenge of modern shipbuild-ing as ldquoto manage and control the design and assembly process togain efficiency and short delivery timesrdquo By summarizing theshipbuilding process life-cycle stages as tendering design pro-duction planning materials finance and follow-up the require-ment for the effective management of the extremely large amountsof information was established in order to ensure the efficientorganization of the shipbuilding process Johansson suggested thatthis requirement could be satisfied only through the developmentof ldquoan information flow solution specifically designed for thisindustryrdquo and suggested that it was not sufficient just to automateexisting manual activities Rather the organization should beadapted to the use of new tools to streamline the information flowwherever possible The discussion appeared however to be re-stricted to information flows within a single shipbuilding organi-zation with the main focus on how the information may be utilizedto improve the production process

The product model concept was regarded by Johansson as beingone such tool whereby the organization may be streamlinedthroughout the precommissioning stages by providing a consis-tent model to enable well thought-out build strategies to be de-veloped early ordering of materials and material handling pre-fabrication preoutfitting and the use of numerically controlledmachines

Additional information was contained within the productmodel such as material codes weights surface treatments and soforth For this reason Johansson suggested that a more appropriateterm may be product information model because the modelshould contain all technical product definition data and may beused to provide for example graphical representations of geom-etry as well as lists and reports of material requirements Addi-tionally Johansson stated that the generation of a graphical rep-resentation should be produced only when it is required and to theextent that is suitable in order to avoid unnecessary computationThe graphical representation is regarded as secondary informationof the (primary) information stored in the product model Theinformation flow may be streamlined by the manipulation of theprimary information rather than the secondary information

Johansson also recognized that it was important that ldquoa productmodel based system must understand what the different parts ofthe system really represent and be able to interpret the rules andrestrictions connected to each type of objectrdquo

Erikstad and Fathi (1999) described how a STEP-based shipproduct model could be used within the ShipX project for theintegration of the data within a number of hydrodynamic analysisapplications for a ship The applications were previously devel-oped as stand-alone applications to specific aspects of the hydro-dynamic performance of the ship such as propulsion and seakeeping Previous integration among the applications wasachieved through the development of translators to allow for theexchange of information However the technique was difficult toimplement and maintain and was not considered to be seamlessThe communication of information among applications is clearlya central issue that has been discussed in a number of reports(Wyman et al 1997 Gischner et al 2001) Essentially the optionsare either to develop a direct interface between every pair ofcomponents or develop the interfaces based on a consistent inter-

face standard A common product model (Fig 9) was imple-mented within ShipX and from the application developmentviewpoint it enabled

Developers to concentrate more on the specific simulationproblem rather than the modeling of the data This benefit isrealized every time a particular application goes through rede-velopment or when new applications are developed

Guaranteed synchronization of data between the applica-tions and the product model Translators were previously usedto convert the product data to and from the required formats foreach application Changes could potentially be made to theproduct model after data translation to the application resultingin a discrepancy in the translated data The product modeltechnique ensures that each application has a common repre-sentation of the ship

Reuse of previous applications and graphical user inter-faces eliminating the need for the end user to relearn how touse the application

Despite integrating existing applications with the productmodel it is not clear within the ShipX project whether integrationexisted between applications For example two discrete applica-tions may be considered as damage stability assessment andevacuation simulation both integrated via the product model It ispossible to make assessments of the performance of the ship withrespect to both the damage stability and the evacuation in isola-tion via the integration with the product model However inte-gration is required between the damage stability and evacuationapplications in order to assess the evacuation time while compart-ments are flooding

The ShipX product model was developed using the relevantshipbuilding protocols developed within STEP which were imple-mented into a class library and stored using an object-orienteddatabase

Erikstad gave a number of useful guidelines for the develop-ment of the ShipX system

Simplicity The development of a comprehensive productmodel tool was considered to be prohibitive both from theaspects of timeliness and cost effectiveness Wherever pos-sible commercial off-the-shelf components were used Thedevelopment of the actual product model was undertaken usingthe STEP shipbuilding protocols rather than developing anin-house product model from scratch

Flexibility and extensibility The model was initially lim-ited to representing data that were specific to hydrodynamicperformance However consideration was given to the struc-ture of the model such that it could be extended to representother performance aspects Also the use of STEP to producethe common product model enables the scope of ShipX to beextended without restructuring the model The facade designpattern was also used to hide the complexity of the productmodel from the client applications define the correct usage ofthe product model by the client applications and enable theupdating of the product model without affecting the client ap-plications

Weak bindings to platform and programming language toenable the cross-platform and cross-language integration of theproduct model

Baum and Ramakrishnan (1997) regarded three-dimensionalproduct model technology as being fundamental for the imple-mentation of concurrent engineering (CE) within shipbuilding dueto the ability to develop capture represent integrate and coor-dinate data and permit simultaneous access to a number of usersBaum defined the product model as ldquothe integration of the 3Dgeometric model and non-geometric database informationrdquo whichmay be a logical integration of distributed information (Fig 10)

Simulation and interaction with the objects within the productmodel through the introduction of anthropomorphic models into avirtual environment to test functionality and operability were dis-cussed as being a useful technique to test the validity of the modelin a way similar to what would be achieved with the final productThe resulting model is essentially an electronic ldquomock-uprdquo Baumsuggested therefore that it is important to also represent the nor-mal behavior of the objects within the ship product model suchthat their behavior may also be analyzed enabling the product tobe designed manipulated analyzed constructed tested operatedsupported and disposed of in a virtual environment

Ross and Garcia (1998) and Ross and Abal (2001) discussed theutilization of product modeling technologies within two differentshipyard applications new build and conversion with the focus ofaiding shipyard managers with the decision to adopt such tech-nologies Ross suggests that the key characteristic of the productmodel for achieving a high level of integration is the adoption ofa single database allowing a number of designers to simulta-neously work on the same design through effective database man-agement and reducing or preventing altogether the inconsistency

Fig 9 From data translators to data integration within the ShipX project (Erikstad amp Fathi 1999)

of information A number of small shipyards that have incorpo-rated product-modeling technologies are used as case studies todiscuss the techniquersquos effectiveness with the conclusions thatthese shipyards have an improved production quality and signifi-cant savings in material cost labor cost construction cost andlabor hours Despite being a more complex representation thantraditional techniques Ross and Abal (2001) concluded that stafftraining was straightforward and that staff were considered com-petent after the design of the first vessel

Polini and Meland (1997) discussed the extension of a prototypeproduct modeling system through to the development of a pro-duction implementation that was capable of supporting concur-rent multiuser access Life-cycle data and behavior were modeledwithin the classes contained in the Smart Product Modelling(SPM) system The differentiation between a standard productmodel and an SPM system is shown in Fig 11 To appreciate theamount of effort involved in developing the SPM Polini andMeland state ldquoTo date nearly 45 man-years of software devel-opment have been invested in the SPM and its GUI approxi-mately 1000 classes with over 30000 methods have been devel-oped object oriented databases on the order of 25 gigabytes arecommonplace 24 concurrent users have modeled five shipclasses and tens of thousands of structural parts have been manu-facturedrdquo

This development was undertaken entirely within a shipyardwithout any commercial input Polini and Meland justified thisdevelopment by surveying the requirements of the shipyard andconcluding that there were no commercially available systemscapable of dealing with the degrees of specialization within theshipbuilding industry a point that has also been made by Jo-hansson (1995)

One of the questions asked by Shin and Han (1998) and others(Baum amp Ramakrishnan 1997) is whether it is possible to imple-ment paperless design because designers often spend a great dealof time trying to extract useful information from two-dimensionalpaper drawings The shipbuilding building blocks within the STEPshipbuilding APs were used as the basis to produce a ship product

model Shin used the STEP toolkit ST-Developer to produce C++classes using the EXPRESS data definition language for the mid-ship section of a bulk carrier

The classes were enhanced to enable all life-cycle product in-formation to be stored within a single data structure as well as fortranslating data formats by one-to-one mapping and includingexplicit information (Youngrsquos modulus Poissonrsquos ratio) from de-sign conventions available within the product model The systemarchitecture can be seen in Fig 12 This enhancement was re-quired because Shin suggested that it was not sufficient to simplytranslate data from a neutral format into the format required byeach application Rather it is a requirement of each applicationthat associated functions and information specific to each appli-cation is also incorporated into the model

This requirement for functional data was also discussed byCrawford et al (1999) Rather than relying on a flat neutral file tocontain geometry and topology information it was considereduseful that the topological data for example were provided withsome sort of intelligence to facilitate the translation between ap-plications The STEP standards were adhered to wherever pos-sible However achieving intelligent topology required extensionof the standards Crawford defined the Newport News Shipbuild-ing view of a product model as ldquoan all encompassing model of a

Fig 11 Product model definitions (Polini amp Meland 1997)

Fig 10 Representation of a ship three-dimensional product model (Baum amp Ramakrishnan 1997)

ship project taking advantage of the available computer toolsfor describing the geometry of a ship but it also includes allattributes necessary for the design production and operation ofthe shiprdquo

Again it was considered unlikely that the ship could be definedby a single computer system rather than by a number of moremanageable systems grouped according to some arbitrarily de-fined domains (Fig 13)

Crawford demonstrated the use of intelligent topological andgeometric STEP-based data through the use of the GOBS commonobject request brokerage architecture (CORBA) server that pro-vides a number of methods to enable legacy tools to extract therequired data Two analysis tools were used to model the ship

vulnerability and hydrostatics which obtained their data from theGOBS server The analysis concluded that within the majority ofthe cases the STEP standard for geometric data (Part 42) wassufficient to represent the geometry for the ship

Rando and Fernholz (2000) describes how the DARPA Mar-itech Shipbuilding Information Infrastructure Project (SHIIP) andShipbuilding Partners and Suppliers (SPARS) projects used acombination of component-based software internet protocols anda portable computing platform to satisfy the following shipbuild-ing information technical requirements

An information technology gap separates the large me-dium and small shipyards

Fig 12 System architecture of the STEP manager (Reprinted from Shin amp Han 1998 with permission from Elsevier)

The information technology staffs at most shipyards areexperts in shipbuilding process requirements but not in system-level computer technologies

Shipyard information systems must be reliable and main-tainable yet often need to be customized to suit an individualshipyard

As with many other projects (Rando 2001 Gischner et al 2001)integration within the shipbuilding industry was considered pos-sible only by the reuse of existing software components becausethe number of shipbuilding system requirements is so diverse thatit is unrealistic to assume that it is possible to produce a singleoverarching solution The integrated system was considered toconsist of a number of independent components to be assembledand reused by third parties in order to create a new complexsystem The initial task of the SHIIP project was to define areference architecture to support the composition of the indepen-dent components

The management of the product data was achieved using En-terprise Java Beans (EJB) that enable persistent storage secureaccess and load balancing for multiple users wishing to access thedata simultaneously At the start of the SHIIP project however

EJB was not available and the project relied instead on CORBAtechnology The project learned the following lessons from usingCORBA

Technology independence although useful in theoryshould not be pursued at the expense of developing workingimplementations

Technical interoperability is not a requirement for the de-velopment of an industrial information infrastructure Support-ing applications and software components for the informationinfrastructure are homogeneous enough to be implemented in asingle implementation technology

The Object Management Group (OMG) while advocatingseparation of components has produced in the arena of do-main standards wrappers for monolithic applications

OMG has been hampered by the inability to reach timelyconsensus

The Integrated Shipbuilding Environment (ISE) project withinthe Maritech Advanced Shipbuilding Enterprise (ASE) is usingXML as the basis for achieving interoperability between ship-building systems technologies specifically between application toapplication (Rando 2001) Rando differentiates this problem fromthat of other industries by stating that many of the applicationcomponents used within the shipbuilding industry have alreadybeen developed as well as the having little control over the de-velopment of these systems The shipbuilding product model mayalso contain millions of instances of a large number of differenttypes of information that need to be managed as they evolve overthe productrsquos life cycle It is also suggested that not only is therea need to rely on an enterprise system that augments the manyspecialist applications but due to the diversity of informationwithin the life cycle of the ship no single information system issufficient to deal with the entire ship product Indeed previousalliances between shipyards have been one-off solutions and thereis a definite requirement for a standardized effort for the shipproduct model

Rando identified a number of business drivers in order toachieve interoperability within the shipbuilding industry and pro-

Fig 13 Domain-based ship system (Crawford et al 1999)

Fig 14 ISE reference architecture three levels of interoperability (Rando 2001)

posed an architecture in order to respond to these drivers (Fig 14)The architecture represents three interoperability levels within theshipbuilding environment intercomponent refers to the interac-tions between the software components within a system intersys-tem refers to the interactions between the systems and is boundedby a business system domain and interenterprise interoperabilityrefers to interactions between business systems domains at differ-ent shipyards and organizations

The key elements for achieving this interoperability were acommon syntax using XML to facilitate communication a sharedstandard information model using STEP and an interoperabilityinfrastructure using web-based technologies XML is a neutralformat that may be viewed by humans (although this is not gen-erally a primary requirement) and that enables the sharing of in-formation between different technologies different operating sys-tems and different programming languages Five keyrequirements were identif ied to facilitate application-to-application integration

Should ldquoreuserdquo widely available standards-based tools Should be implementable with tools that allow for recon-

figuration by nonprogrammers Should support transformation to and from a canonical or

neutral format Should utilize a representation that is as simple and con-

cise as possible Should be able to marshalunmarshal every semantic con-

cept representable in the EXPRESS information modeling lan-guage (ISO 10303-11)

One of the most significant issues relating to the use and inte-gration of ship product models with existing applications appearsto be the need to ldquoflavorrdquo the model and specifications to suit theparticular requirements of the design and simulation applicationsWithout these embellishments the fully automated data integra-tion appears quite often difficult to achieve There are howeverconflicting opinions regarding the effectiveness of automating thisprocess generally arising due to the complexity of the problem andthe level of support The application of ldquoflavoredrdquo standards doeshowever entirely go against the point of creating a standard es-pecially when it is with respect to the transfer of product data Itcould therefore be concluded that the solution to the effectiveintegration of STEP lies not in the modification of a new tech-nology to satisfy the requirements of legacy applications but inthe updating of the legacy applications to satisfy the new technol-ogy

Life-cycle issues

The NEUTRABAS project (Welsh et al 1992) was limited tothe precommissioning stages that is marketing conceptual de-sign detailed design drafting materials ordering productionplanning and control scheduling and quality control However itwas recognized that significant benefits would be achievedthrough extending the life cycle through to disposal Welsh et alqualified the limitation to the precommissioning stages by statingthat ldquothe definition and implementation of a complete product datamodel covering all of these aspects of the life-cycle of an engi-neering product as complex as a ship is an onerous task and one

which would require the commitment of a vast amount of time andeffortrdquo

Limiting the project to the precommissioning stages would ap-pear to have been a wise judgment because in the 10 years fol-lowing this project the standards created to describe the shipproduct model have still not yet been finalized

Welsh et al suggest that the physical representation of the prod-uct within each life cycle stage would ldquonormally be unchanged inthe global sense although the information associated with theproduct and the techniques used to represent it will vary consid-erablyrdquo that is the information contained within the productmodel would mature as more detail becomes available as well asrequiring different viewpoints at each life-cycle stage The productmodel must therefore be developed not only with the associateddata and structure in mind but also with the life-cycle stages Toenable the support of the precommissioning life-cycle stagesWelsh et al identified four views that need to be supported by theship product model

Marketing-oriented view Management-oriented view Design-oriented view Production-oriented view

Von Haartman et al (1994) briefly discussed life phase issues ofthe ship product model and suggested that a number of systemsmodel the design with too much detail and hence are not appli-cable to the concept design stage A solution to this was thedevelopment of a concept design product model that could then betransferred to the detailed design stage It is not clear from thiswhether Von Haartman et al were proposing separate models forthe two stages or if the detail product model would simply consistof the concept product model plus the additional required detail

The mechanism of having multiple different views for the shar-ing of a product model among designers and production engineersfor example has been considered and implemented in a number ofcases (Polini amp Meland 1997 Johansson 1995) Johansson indi-cated that it is common for parts of the product to be in differentlife-cycle stages at the same time that is the ldquomanufacture of onepart of the product is going on at the same time as the detaileddesign of anotherrdquo This is one aspect of concurrent engineeringwith the result of reducing the lead times because the manufactureof the product has started before the design of the product has beencompleted However it is necessary to ensure both that manufac-turing starts only on parts that require no further design and thatother parts that are currently being designed do not propagatechanges to the manufactured parts The management and controlof the information flow were recognized as being the key elementsin increasing the overlapping of life cycles However no expla-nation was given by Johansson regarding the nature of the man-agement other than through the relationships between the objectscontained within the model These relationships were described asa mechanism to enable both interdisciplinary and cross-disciplinary communication among designers

The three-dimensional product model was described by Baumand Ramakrishnan (1997) as being a mechanism to enable a num-ber of different life-cycle stage simulations such as interferencechecking crew traffic flow studies yard-specific designs and fi-nite capacity scheduling through the use of a virtual environmentdesign review technology using data contained within the productmodel (Fig 15)

Coupled with simulation-based design (SBD) Baum describedthe combined technology as ldquothe new frontierrdquo that would enablethe virtual prototyping of the ship which previously could not beachieved due to the cost and complexity More importantly Baumrecognized that just as interference-checking software may beused to determine discrepancies between geometric parts duringthe design and production phases SBD may be used to reduce oreliminate design errors that would have previously have beendiscovered years later in the operational stage for example Es-sentially SBD and product modeling enable the validation of thedesign production and operation stages of the ship product

Baum also finally suggested that the product model provides asignificant benefit to the owneroperator by enabling the analysisand support of life-cycle maintenance

A generic shipyard computer modeling tool for evaluating de-sign for production (DFP) is discussed by Lamb et al (2000) Thetool enables shipyards to be modeled such that the impacts ofchanges to the ship design may be determined on the basis of theresulting material manpower and schedule The shipyard modelrepresents details of the buildingsmdashtheir arrangement and size aswell as equipment capacity and flow The tool also enables aninvestigation of the necessary changes required for a shipyard inorder to produce a new design The key foundations in order toevaluate these impacts are the interim product catalogue and thebuild strategy approach

Lamb et al identified a number of important concepts for DFP

All designs should be prepared to suit a shipyardrsquos facili-ties and preferred production methods

DFP takes into account production methods and tech-niques that reduce the product work content but still meet thespecified design requirements and quality

DFP must be incorporated into a design from the start Traditional engineering leaves it up to another department

such as production or manufacturing engineering to developthe technical documentation required for the production work-ers This is an unnecessary duplication of effort and is a nonndashvalue-added task that takes time

An objective of the CE approach is to accommodate DFPby bringing all the necessary people together right from dayone on a project

The time to influence the cost of a product is during theearly stages After the design has been developed in conceptmost of the opportunity to positively affect cost is gone

World-class ship designers know how their shipyardbuilds ships and design accordingly Many ship designers donot consider this and the designs may or may not be efficientlybuilt in their facilities More shipbuilders have taken steps toremedy this situation through the use of the build strategyapproach

Engineering should be prepared and transmitted to theusers in a way that best suits block construction advanced andzone outfitting

An object-oriented approach was adopted for the constructionof the model (Fig 16) The model represents shipyards worksta-tions products equipment processes manufacturing processesmaterial handling processes and interim products The tool wasapplied to the evaluation of two design alternatives for the bottomstructure of a ship The authors demonstrated that the tool enabledreliable evaluations of the man-hours for manufacturing and ma-terial handling such that the best design alternative could beadopted

Future directions

It is believed that the ship STEP APs will become the standardunit of shipbuilding data but that it will probably be an evolution-ary process as advances in technology and modeling capabilitiesand requirements are incorporated It is however crucial that thedevelopment of the standards comes to a timely consensus at eachevolutionary stage The literature reviewed has discussed the useof ldquointelligentrdquo data the inclusion of useful functionality accord-ing to the data type and of behavioral aspects It is anticipated thatthis functionality behavioral aspects and so forth will increas-

Fig 15 Ship design workflow using three-dimensional product model (Baum amp Ramakrishnan 1997)

ingly become part of the model to the extent that the model nolonger has any need for interfaces and translators to legacy soft-ware For example the piping model would automatically calcu-late interferences and the structures model would automaticallycalculate stress characteristics The simulation would essentiallybe part of the model and the model would contain additionalinformation and knowledge to effectively manage the simulationThis is not to say that the model would become a monolithicsystem despite such a system being potentially computationallyviable in 10 years Rather than being monolithic current andfuture distributed information technologies such as EnterpriseJava Beans may be utilized in order to distribute the model acrossa network while giving the impression to the user that the systemis monolithic Ship product data and functionality would be dis-tributed either within a single company or as partnerships withother companies

In a similar way that the ship product data has become stan-dardized benefits are to be gained from standardizing the inter-faces between applications to support the flow of standardizeddata and achieve a truly seamless integration The unfortunateshortcoming of application standardization is the necessity to re-develop the legacy systems to support this level of integration

The VRShips project addresses the management of ship productdata within a neutrally formatted common model The geometry

data contained within the common model are based on STEPAP203 are described using XML and are considered as beingcommon data if two or more applications access it Integration isprovided between the legacy applications and the common modelvia ldquogeneric wrappersrdquo that provide the general management re-quired in order to operate the applications The wrappers convertthe data to and from the native format using modular conversionalgorithms that can be plugged into the wrappers and provide thedomain-specific management for the applications Data are auto-matically downloaded from the common model and converted intothe native format when the application is started When the appli-cation is complete the designer has the option of undertaking thereverse process to convert the data back into the neutral format andupload into the common model Despite being a complex processconverters have been produced for a number of design applica-tions such as Tribon and AVPro and have been demonstrated tooperate without the need for manual interaction However theissues relating to the lack of integration between tools and con-tinuous product models remain to be addressed

The VRShips system also has an additional management layerconsisting of a process controller and an inference engine that arejointly responsible for maintaining data consistency and versionconstraint and process management Visualizing of product datavia the legacy applications is managed through the exporting of

Fig 16 Object diagram for generic shipyard computer model (Lamb et al 2000)

the displays via a virtual interaction environment These controlmechanisms ensure that designers may modify the data containedwithin the common model from any location either organization-ally or geographically distributed with network access using anapplication that they are familiar with and that any changes madeto the product model are correctly propagated such that the dataremain consistent

Every product modeling tool and technique discussed withinthis review is common from the perspective that the data containedwithin the model are a ldquosnapshotrdquo of the actual design activity Forinstance a designer may download data from the ship productmodel for use within a general design package which may take aweek to design During this design period the data within theproduct model do not change until the designer decides that thedesign process is complete and the data are uploaded into theproduct model The product model therefore does not contain acontinuous representation of either the design work that is cur-rently being undertaken or the form that the data are in This posesa number of significant project management issues with respect toversion control consistency management and conflict resolutionespecially in the situation where the design process is being un-dertaken in a distributed manner as is increasingly becomingcommon

A paradigm shift in the techniques used to enable the distributeddesign of ships while enabling a continuous product model andfacilitating the management of conflicts and consistency would bethe adoption of a technology that is more often seen within thecomputer games industry Graphics servers are commonly usedwithin the games industry to enable the user to immerse them-selves within an environment and interact both with the environ-ment and with other users High-level graphical objects are com-municated between the server side and the client side rather thanusing structured files This technique bypasses the need to trans-late the communicated data into the client side format alleviatingunnecessary computation It also results in a model containedwithin the server and represented within the clients that is a con-tinuous depiction of what everyone is undertaking The ship prod-uct data would remain within the ship STEP formats Howeverthe description method would be the graphical object representa-tion that would also exhibit behavioral properties Within the ship-building context individual graphics servers would represent do-mains similar to those identified by Crawford et al (1999) Clientsconnecting to the servers would immediately get an up-to-dateview of that particular domain which would be consistent with theviews of all of the other clients The client software would operatein a manner similar to conventional design applications There isalso clearly a requirement for integration between the differentdomain servers to enable conflicts to be resolved across domainsSimulation servers would integrate all of the scenarios that wouldenable an evaluation of the performance within any particular lifephase There would still remain the need to provide an effectivemanagement of different versions as well as a high-level coordi-nation structure to manage conflicts constraints design goals andcollaboration among designers However the underlying frame-work would provide the basis on which to construct this Despitebeing a significant step-change compared with current practicethis future technique proposes a viable solution to the effectivemanagement of a ship product model that may be manipulated andoperated upon in a distributed manner

This type of architecture does however raise a number of

issues relating to partnerships between the shipbuilding industryand the shipbuilding software industry because the system wouldrepresent an amalgamation of existing design and simulation ap-plications into a number of domain-specific servers The intellec-tual property rights as well as the ownership of both the technol-ogy and the data contained would clearly need to be resolved Inaddition the system calls upon the need to implement a standardfor the communication of the graphical objects that is both secureand robust whereas the standard for the data may be ldquoflavoredrdquoand managed effectively within the system via the ability to dy-namically load classes

Just as many of the precommissioning life phases are currentlybeing modeled it is anticipated that the rather poorly supportedpostcommissioning life phases will be catered for The most sig-nificant difference between pre- and postcommissioning is that itwill be the ship product model in its entirety that will be consid-ered For example there currently appears to be a significantopportunity for the specialization of the immersion of an entireship product model into an artificial environment to determine theoperational performance both at virtual sea (modeling existingshipping lanes to determine sea-keeping characteristics) within avirtual port (modeling existing ports to determine cargo-handlingcharacteristics) within a virtual shipyard for recommissioning(modeling existing shipyards to determine recommissioning capa-bility) and within a virtual breakers yard for disposal (to deter-mine scrap value) Increased opportunity would therefore be madefor designing the ship to meet a more rigorous set of customer-specified life-phase requirements and would represent a signifi-cant commercial advantage

It is also interesting at this point to note that a number of thecited papers have stated the need to avoid a reliance on computerprogrammers which in order to maintain even the simplest ofproduct data modeling systems seems unachievable

Conclusions

From the increasing amount of literature and the papers re-viewed within this paper related to the ship product model theprimary focus is on developing a standard representation for thedata contained within the model Despite not having yet finalizedthe standards for all aspects of the ship the STEP APs go a longway toward achieving this It is almost inconceivable to considerthat an alternative could compete against such a massive thrusttoward ship data standardization A number of instances havearisen however when the APs have been adhered to with theresult that ldquoflavorsrdquo or minor changes to the standard have beenrequired in order to utilize the structured well-defined and stan-dardized data within the legacy applications The question there-fore arises as to whether there is a requirement to standardize thelegacy applications such that they adhere to the data standard toenable a modular plug-in approach to ship design and simulation

Behavioral aspects have been considered within a number of thecited papers to be an important addition to the data in order toprovide the designer with additional feedback with respect to theoperation of the design This behavior may however be betterrepresented as high-level rules within a standard that are used todefine the operation of the ship rather than in existing standardsin order to minimize its impact on applications that have no needfor such data

A number of the tools and techniques discussed have described

the use of the ship STEP formats as being a mechanism for inte-grating existing legacy applications with a common model of shipproduct data Considerable benefit would be obtained from pro-viding similar integration between applications to progress fromthe limitations of discrete design and simulation toward having aholistic approach

The design tasks that are undertaken as part of the ship designprocess may well take a considerable amount of time and wouldconventionally result in ldquosnapshotsrdquo of the design artifact coin-ciding with the designer uploading data into the common modelA number of future directions have been discussed which wouldindividually require considerable development in order to imple-ment but which represent possible solutions to issues relating to

Continuous rather than ldquosnapshotrdquo ship product models Integration between the ship product model and the design

and simulation applications as well as across applications Removal of information translation problems through the

use of high-level graphical objects that are consistent betweenservers and applications

A collaborative framework on which to develop versionconflict and consistency management

Acknowledgments

The review was undertaken as part of an investigation intocommon model techniques within the VRShips-ROPAX2000project The authors gratefully acknowledge the support given bythe European Commission Community Research 5th Frameworkprogram under the area of Competitive and Sustainable Growthwhich provided the grant (G3RD-CT-2001-00506) that enabledthis work to be undertaken

References

BAUM S J AND RAMAKRISHNAN R 1997 Applying 3D product modelingtechnology in shipbuilding Marine Technology 34 1 56ndash65

CATLEY D 1999 Prototype STEP data exchanges in ship initial design andprovision of an application programmer interface to TRIBON Proceedings10th International Conference on Computer Applications in ShipbuildingJune Cambridge MA

CRAWFORD A K HARRINGTON G AMES R M AND VAN ESELTINE RT 1999 Neutral format data exchanges between ship product models andanalysis interfaces Proceedings 10th International Conference on Com-puter Applications in Shipbuilding June Cambridge MA

ERIKSTAD S O AND FATHI D E 1999 Applying the STEP shipbuildingprotocols as a basis for integrating existing in-house ship design applica-tions Proceedings 10th International Conference on Computer Applica-tions in Shipbuilding June Cambridge MA

GISCHNER B KASSEL B LAZO P WOOD R AND WYMAN J 2001 Evolution of STEP (ESTEP) exchange of shipbuilding productmodel data JOURNAL OF SHIP PRODUCTION 17 3 151ndash160

GRAU M AND KOCH T 1999 Applying STEP technology to shipbuildingProceedings 10th International Conference on Computer Applications inShipbuilding June Cambridge MA

HERZOG E AND TOumlRNE A 1999 A seed for a STEP application protocolfor systems engineering Proceedings 12th International Conference andWorkshop on the Engineering of Computer Based Systems Institute ofElectrical and Electronics Engineers Press Piscataway NJ 174ndash180

HIGNEY J T AND OUILETTE J J 1994 An engineering product modelbased on STEP protocols JOURNAL OF SHIP PRODUCTION 10 4 281ndash286

ISO 1996 Product Data Representation and Exchange Part 218 Ship Struc-

tures International Standards Organization Hamburg GermanyJOHANSSON K 1995 The product model as a central information source in

a shipbuilding environment Proceedings National Shipbuilding ResearchProgram 1995 Ship Production Symposium June Seattle WA

LAMB T CHUNG H AND SHIN J G 2000 A generic shipyard computermodel a tool for design for production Proceedings 7th IMDC NovemberKyung-Ju Korea

MARTIN D J 1980 The shipyard product information system as an aid toimplementing more productive strategies Proceedings Research and Engi-neering for Automation and Productivity in Shipbuilding IIT Research In-stitute October Chicago IL 81ndash101

POLINI M A AND MELAND K E 1997 The development and implemen-tation of a SMART product model for ship structure Proceedings 9thInternational Conference on Computer Applications in Shipbuilding Octo-ber Yokohama Japan

RANDO T C AND FERNHOLZ D 2000 MARITECHrsquos shipbuilding infor-mation infrastructure JOURNAL OF SHIP PRODUCTION 16 2 110ndash120

RANDO T C 2001 XML-based interoperability in the integrated shipbuild-ing environment (ISE) JOURNAL OF SHIP PRODUCTION 17 2 69ndash75

ROSS J M AND GARCIA L 1998 Making the jump to product modeltechnology JOURNAL OF SHIP PRODUCTION 14 1 15ndash26

ROSS J M AND ABAL D 2001 Practical use of 3D product modeling inthe small shipyard JOURNAL OF SHIP PRODUCTION 17 1 27ndash34

SCHMIDT W R VANDER J R AND SHIELDS V R 1990 Modelling andtransfer of product model digital data for the DDG 51 class destroyer pro-gram Proceedings National Shipbuilding Research Program 1990 ShipProduction Symposium August Milwaukee WI

SHIN Y AND HAN S H 1998 Data enhancement for sharing of shipdesign models Computer-Aided Design 30 12 931ndash941

VON HAARTMAN J KUUTTI I AND SCHAUMAN C 1994 Improving designproductivity with a product model for initial ship design Proceedings 8thInternational Conference on Computer Applications in Shipbuilding Sep-tember Bremen Germany

WELSH M LYNCH J AND BRUN B 1992 A data model for integration ofthe precommissioning life-cycle stages of the shipbuildingproduct JOURNAL

OF SHIP PRODUCTION 8 4 220ndash234WHITFIELD R I COATE S G DUFFY A H B AND HILLS

W 2000 Coordination approaches and systemsmdashpart I a strategic per-spective Research in Engineering Design 12 73ndash89

WYMAN J WOOLEY D GISCHNER B AND HOWELL J 1997 Development of STEP ship model database and translators fordata exchange between shipyards JOURNAL OF SHIP PRODUCTION 13 2111ndash124

Internet addresses

European Marine STEP Association httpemsagermanlloydorg

ISO STEP ship team http wwwnsnetcomNIDDESCt23html

Japan Marine Standards Association http wwwjecalsjipdecorjp

Korea STEP Centre httpksteporkr

1999) Catley states that a modern commercial vessel may beexpected to have an associated product data model 2 to 10gigabytes in size depending on its complexity Archiving ver-sion management and a robust product information solution areseen as essential requirements for a competitive shipbuilding in-dustry

Catley also discusses the translation of the AP215 compartmen-tation and AP216 ship molded forms schemas between theTRIBON system and either SEASPRITE or MariSTEP represen-tations Despite an increasing demand for the standardization ofproduct information to enable a common-model representationCatley recognizes the need for openness between specialist sub-contractors and partners in order to achieve common access Fig-ure 6 demonstrates the data flow between KCS and Calypso

Crawford et al (1999) defined a geometry object structure(GOBS) as being organizational to enable the data to be accessedby logical groupings or views topological to define the physicalrelationships between model elements and representational as aresult of the topology The resulting structure enabled both topo-logical views (a view of space not the space itself) and commonviews (compartments machinery spaces)

The development of ship product data formats and structureshas seen a great deal of focus on the ship STEP APs as well asusing EXPRESS and more recently XML as languages to modelthe data The ship STEP APs are clearly required to represent largeamounts of complex data However they also require a concertedand constant effort for finalization to avoid stagnation and toimprove general uptake across the industry These technologiesrely heavily on information technology which is notorious forprogressing more quickly than standards are produced Informa-tion technology considerations are therefore vital in the develop-ment of the data formats and the supporting mechanisms in orderto ensure that the standard does actually ensure the exchange ofproduct data In addition the operational maintenance and de-

commissioning life phases need to be thoroughly supported withinthese data structures

Ship product modeling

Martin (1980) was perhaps one of the first people to discussproduct information systems within shipbuilding and defined theproduct model as ldquoa logically-structured product-oriented data-baserdquo The product model term was however considered by Mar-tin to be a misnomer because the inclusion of nonproduct infor-mation specifically information relating to the yard facility wasconsidered to be one of the most important benefits of the systemThe product model was described as consisting of a number oflogically complete database subsets that contain overlappingstructural and material information for the product (Fig 7)

Martin realized that the product model was not simply a designtool but the information contained within it may be utilized byother yard functions to determine material requirements issuepurchase orders schedule activities and so forth Indeed since theadvent of numerically controlled machines the product model hasbeen viewed as a tool to automate parts of the production process(Johansson 1995 Ross amp Garcia 1998 Ross amp Abal 2001)

During the early 1990s Schmidt et al (1990) explored the fol-lowing options for the format for the product modeling and digitaldata transfer (DDT) within the US Navyrsquos AEGIS destroyerprogram

1 ldquoFlavoredrdquo initial graphic exchange specification (IGES) orstandard IGES ldquoFlavoringrdquo is the term used to define theprocess of augmenting the shortcomings of the implementedstandard in order to adapt it to the required task

2 Deferment until the completion of product definition ex-change standard (PDES) and its commercial implementa-tion

Fig 6 Data communication within Calypso project (Catley 1999)

3 Development of direct translators by a software developerspecializing in computer-aided design (CAD) direct transla-tors

4 Use of a neutral file that defines object data

Option 1 was rejected due to the associated shipyardsrsquo usingobject- rather than entity-oriented CAD software PDES was con-sidered to result with a delay of several years to implement aproduction translator hence option 2 was rejected Flexibility andexpansion were considered as restricting factors for option 3 Fi-nally option 4 was accepted due to the ability to develop a neutralmodel in the available time and the flexibility and future expan-sion of such a model

Schmidt et al also introduced the concept of the ldquodesign win-dowrdquo to transfer only the part of the model that was required ratherthan the entire model by specifying boundaries for the design zoneto be transferred One important aspect related to the transfer ofpartial data was the requirement for effective configuration man-agement such that changes made to the partial models were re-flected within the overall model Higney and Ouilette (1994) fol-lowed up the discussion of Schmidt with a description of a STEP-based product model for the AEGIS destroyer The product modelwas split into two parts a graphical model and a relational data-base containing nongraphical data NIAM diagrams were initiallyused to define the relationships within the relational database Themodel was developed based on the more fully developed STEPpiping AP However other APs were to be included when theybecame available

Welsh et al (1992) focussed on the precommissioning life-cyclestages of the shipbuilding product model while developing aframework to integrate disparate computer-based information sys-tems within the ESPRIT IIndashfunded NEUTRABAS project (Fig 8)The underlying mechanism to achieve this integration was a prod-uct model database to contain and manage neutral shipbuildingdata specifically spatial structural integration outfitting and en-gineering systems data It was identified that the structure of thedata was as important as the data themselves in order to effectively

manage the exchange of the data across various complex andheterogeneous ship development applications

Baum and Ramakrishnan (1997) suggested that associativitydata are extremely useful additions to the product model becausethey enable changes made to any one of the objects within thedatabase to be reflected in all associated objects Baum and Ra-makrishnan however did not suggest how this change propaga-tion is managed because without due coordination the impact ofthe change may result in chaotic behavior in complex systems(Whitfield et al 2000) Additionally there is no discussion regard-ing the requirement to simulate the reflected change using thesimulation software to determine the adequacy of the initialchange

The overall aims of the NEUTRABAS project were defined as

The standardization of the way in which information con-cerning marine-related products is represented

The development of standard methods for the exchangeand storage of product definition data in the marine industry

The specification and development of a suitable databasearchitecture that will facilitate the exchange and storage of suchproduct definition data

The implementation of a prototype data exchange andstorage system based on the previously defined database ar-chitecture which will demonstrate the feasibility of a trulyintegrated product life cycle

The authors identified a number of benefits associated with theabove aims such as the reduction of project time scales throughthe adoption of a single managed information store Managing theinformation within a single database is intended to avoid infor-mation mismatches and hence reduce the amount of rework which

Fig 7 Product information system layout (Martin 1980)

Fig 8 The NEUTRABAS system architecture (Welsh et al 1992)

has indeed been reported within a number of publications How-ever there has never been any consideration of the database con-trol mechanisms required to prevent the database from becomingan information bottleneck despite the assumption that a benefitwould be more effective information management or the in-creased duration associated with searching a single (extremely)large database for the required piece of data despite the assump-tion that a benefit would be rapid information disseminationThere is also the suggestion that using such a representation ofproduct data will avoid the need to transcribe the data betweendifferent application systems eliminating the introduction of errorthrough human interaction However a number of papers havesince reported on the requirement of application interfaces totranslate the product data into a format suitable for the intendedapplication Indeed Rando (2001) reported that in some cases adegree of human interaction has been required to ensure that thisprocess runs smoothly Conversely Catley (1999) suggested thatthe minimization of human interaction within the data exchangeprocess has resulted in more consistent design Finally the authorsidentified the benefit associated with improving the interface be-tween the supplier and the client through the introduction of elec-tronic product definition databases

The NEUTRABAS system was composed of an application-independent EXPRESS model defining the shipbuilding producta data dictionary to manage requests to the database a mappingbetween the model and the dictionary in the form of an EXPRESSimport tool the data management component to enable the cre-ation communication modification and querying of productmodel data a number of application interfaces to enable the in-dividual applications to interact with the database a number ofdatabase interfaces to enable communication between specific da-tabase management systems and the NEUTRABAS database anda database generator that enables the mapping of data within aspecific database to the data within the NEUTRABAS database

Von Haartman et al (1994) described the ship product modelwithin the NAPA project and realized the potential of the productmodel as a basis for concurrent engineering (CE) The use ofcomputers within the shipbuilding industry was previously re-stricted to the computationally intensive applications such as thecalculation of hydrostatics and stability These applications havehad a great deal of development to produce tools that represent andmodel a particular characteristic of the design quite accuratelyThey have generally received a great deal of investment of timeand money (Crawford et al 1999) Von Haartman et al suggest thatthe modern ship design process should ideally consist of a singlesystem that augments all of the disparate design tools but that oneshould recognize that such a system is far from reality The alter-native was to provide a framework to interlink these design toolsto give the impression of a single system The ship product modelwas the key to interlinking these tools

Von Haartman et al also stated ldquoAny model merely reflectsselected properties of the object it is intended to describe and theappropriate selection of properties is of central importance whendesigning the modelrdquo Within the NAPA ship product modelglobal properties of the ship were identified such as the maindimensions hull form and so forth and although not explicitlystated it is assumed that these global properties were chosenpartly for the reason that they are common among the design toolsbeing utilized These properties within the model may also be usedto evaluate the economic and technical requirements of the ship

Finally Von Haartman et al stated that the lack of detail of theglobal properties within the ship product model is not synonymouswith inaccuracy

Johansson (1995) described the challenge of modern shipbuild-ing as ldquoto manage and control the design and assembly process togain efficiency and short delivery timesrdquo By summarizing theshipbuilding process life-cycle stages as tendering design pro-duction planning materials finance and follow-up the require-ment for the effective management of the extremely large amountsof information was established in order to ensure the efficientorganization of the shipbuilding process Johansson suggested thatthis requirement could be satisfied only through the developmentof ldquoan information flow solution specifically designed for thisindustryrdquo and suggested that it was not sufficient just to automateexisting manual activities Rather the organization should beadapted to the use of new tools to streamline the information flowwherever possible The discussion appeared however to be re-stricted to information flows within a single shipbuilding organi-zation with the main focus on how the information may be utilizedto improve the production process

The product model concept was regarded by Johansson as beingone such tool whereby the organization may be streamlinedthroughout the precommissioning stages by providing a consis-tent model to enable well thought-out build strategies to be de-veloped early ordering of materials and material handling pre-fabrication preoutfitting and the use of numerically controlledmachines

Additional information was contained within the productmodel such as material codes weights surface treatments and soforth For this reason Johansson suggested that a more appropriateterm may be product information model because the modelshould contain all technical product definition data and may beused to provide for example graphical representations of geom-etry as well as lists and reports of material requirements Addi-tionally Johansson stated that the generation of a graphical rep-resentation should be produced only when it is required and to theextent that is suitable in order to avoid unnecessary computationThe graphical representation is regarded as secondary informationof the (primary) information stored in the product model Theinformation flow may be streamlined by the manipulation of theprimary information rather than the secondary information

Johansson also recognized that it was important that ldquoa productmodel based system must understand what the different parts ofthe system really represent and be able to interpret the rules andrestrictions connected to each type of objectrdquo

Erikstad and Fathi (1999) described how a STEP-based shipproduct model could be used within the ShipX project for theintegration of the data within a number of hydrodynamic analysisapplications for a ship The applications were previously devel-oped as stand-alone applications to specific aspects of the hydro-dynamic performance of the ship such as propulsion and seakeeping Previous integration among the applications wasachieved through the development of translators to allow for theexchange of information However the technique was difficult toimplement and maintain and was not considered to be seamlessThe communication of information among applications is clearlya central issue that has been discussed in a number of reports(Wyman et al 1997 Gischner et al 2001) Essentially the optionsare either to develop a direct interface between every pair ofcomponents or develop the interfaces based on a consistent inter-

face standard A common product model (Fig 9) was imple-mented within ShipX and from the application developmentviewpoint it enabled

Developers to concentrate more on the specific simulationproblem rather than the modeling of the data This benefit isrealized every time a particular application goes through rede-velopment or when new applications are developed

Guaranteed synchronization of data between the applica-tions and the product model Translators were previously usedto convert the product data to and from the required formats foreach application Changes could potentially be made to theproduct model after data translation to the application resultingin a discrepancy in the translated data The product modeltechnique ensures that each application has a common repre-sentation of the ship

Reuse of previous applications and graphical user inter-faces eliminating the need for the end user to relearn how touse the application

Despite integrating existing applications with the productmodel it is not clear within the ShipX project whether integrationexisted between applications For example two discrete applica-tions may be considered as damage stability assessment andevacuation simulation both integrated via the product model It ispossible to make assessments of the performance of the ship withrespect to both the damage stability and the evacuation in isola-tion via the integration with the product model However inte-gration is required between the damage stability and evacuationapplications in order to assess the evacuation time while compart-ments are flooding

The ShipX product model was developed using the relevantshipbuilding protocols developed within STEP which were imple-mented into a class library and stored using an object-orienteddatabase

Erikstad gave a number of useful guidelines for the develop-ment of the ShipX system

Simplicity The development of a comprehensive productmodel tool was considered to be prohibitive both from theaspects of timeliness and cost effectiveness Wherever pos-sible commercial off-the-shelf components were used Thedevelopment of the actual product model was undertaken usingthe STEP shipbuilding protocols rather than developing anin-house product model from scratch

Flexibility and extensibility The model was initially lim-ited to representing data that were specific to hydrodynamicperformance However consideration was given to the struc-ture of the model such that it could be extended to representother performance aspects Also the use of STEP to producethe common product model enables the scope of ShipX to beextended without restructuring the model The facade designpattern was also used to hide the complexity of the productmodel from the client applications define the correct usage ofthe product model by the client applications and enable theupdating of the product model without affecting the client ap-plications

Weak bindings to platform and programming language toenable the cross-platform and cross-language integration of theproduct model

Baum and Ramakrishnan (1997) regarded three-dimensionalproduct model technology as being fundamental for the imple-mentation of concurrent engineering (CE) within shipbuilding dueto the ability to develop capture represent integrate and coor-dinate data and permit simultaneous access to a number of usersBaum defined the product model as ldquothe integration of the 3Dgeometric model and non-geometric database informationrdquo whichmay be a logical integration of distributed information (Fig 10)

Simulation and interaction with the objects within the productmodel through the introduction of anthropomorphic models into avirtual environment to test functionality and operability were dis-cussed as being a useful technique to test the validity of the modelin a way similar to what would be achieved with the final productThe resulting model is essentially an electronic ldquomock-uprdquo Baumsuggested therefore that it is important to also represent the nor-mal behavior of the objects within the ship product model suchthat their behavior may also be analyzed enabling the product tobe designed manipulated analyzed constructed tested operatedsupported and disposed of in a virtual environment

Ross and Garcia (1998) and Ross and Abal (2001) discussed theutilization of product modeling technologies within two differentshipyard applications new build and conversion with the focus ofaiding shipyard managers with the decision to adopt such tech-nologies Ross suggests that the key characteristic of the productmodel for achieving a high level of integration is the adoption ofa single database allowing a number of designers to simulta-neously work on the same design through effective database man-agement and reducing or preventing altogether the inconsistency

Fig 9 From data translators to data integration within the ShipX project (Erikstad amp Fathi 1999)

of information A number of small shipyards that have incorpo-rated product-modeling technologies are used as case studies todiscuss the techniquersquos effectiveness with the conclusions thatthese shipyards have an improved production quality and signifi-cant savings in material cost labor cost construction cost andlabor hours Despite being a more complex representation thantraditional techniques Ross and Abal (2001) concluded that stafftraining was straightforward and that staff were considered com-petent after the design of the first vessel

Polini and Meland (1997) discussed the extension of a prototypeproduct modeling system through to the development of a pro-duction implementation that was capable of supporting concur-rent multiuser access Life-cycle data and behavior were modeledwithin the classes contained in the Smart Product Modelling(SPM) system The differentiation between a standard productmodel and an SPM system is shown in Fig 11 To appreciate theamount of effort involved in developing the SPM Polini andMeland state ldquoTo date nearly 45 man-years of software devel-opment have been invested in the SPM and its GUI approxi-mately 1000 classes with over 30000 methods have been devel-oped object oriented databases on the order of 25 gigabytes arecommonplace 24 concurrent users have modeled five shipclasses and tens of thousands of structural parts have been manu-facturedrdquo

This development was undertaken entirely within a shipyardwithout any commercial input Polini and Meland justified thisdevelopment by surveying the requirements of the shipyard andconcluding that there were no commercially available systemscapable of dealing with the degrees of specialization within theshipbuilding industry a point that has also been made by Jo-hansson (1995)

One of the questions asked by Shin and Han (1998) and others(Baum amp Ramakrishnan 1997) is whether it is possible to imple-ment paperless design because designers often spend a great dealof time trying to extract useful information from two-dimensionalpaper drawings The shipbuilding building blocks within the STEPshipbuilding APs were used as the basis to produce a ship product

model Shin used the STEP toolkit ST-Developer to produce C++classes using the EXPRESS data definition language for the mid-ship section of a bulk carrier

The classes were enhanced to enable all life-cycle product in-formation to be stored within a single data structure as well as fortranslating data formats by one-to-one mapping and includingexplicit information (Youngrsquos modulus Poissonrsquos ratio) from de-sign conventions available within the product model The systemarchitecture can be seen in Fig 12 This enhancement was re-quired because Shin suggested that it was not sufficient to simplytranslate data from a neutral format into the format required byeach application Rather it is a requirement of each applicationthat associated functions and information specific to each appli-cation is also incorporated into the model

This requirement for functional data was also discussed byCrawford et al (1999) Rather than relying on a flat neutral file tocontain geometry and topology information it was considereduseful that the topological data for example were provided withsome sort of intelligence to facilitate the translation between ap-plications The STEP standards were adhered to wherever pos-sible However achieving intelligent topology required extensionof the standards Crawford defined the Newport News Shipbuild-ing view of a product model as ldquoan all encompassing model of a

Fig 11 Product model definitions (Polini amp Meland 1997)

Fig 10 Representation of a ship three-dimensional product model (Baum amp Ramakrishnan 1997)

ship project taking advantage of the available computer toolsfor describing the geometry of a ship but it also includes allattributes necessary for the design production and operation ofthe shiprdquo

Again it was considered unlikely that the ship could be definedby a single computer system rather than by a number of moremanageable systems grouped according to some arbitrarily de-fined domains (Fig 13)

Crawford demonstrated the use of intelligent topological andgeometric STEP-based data through the use of the GOBS commonobject request brokerage architecture (CORBA) server that pro-vides a number of methods to enable legacy tools to extract therequired data Two analysis tools were used to model the ship

vulnerability and hydrostatics which obtained their data from theGOBS server The analysis concluded that within the majority ofthe cases the STEP standard for geometric data (Part 42) wassufficient to represent the geometry for the ship

Rando and Fernholz (2000) describes how the DARPA Mar-itech Shipbuilding Information Infrastructure Project (SHIIP) andShipbuilding Partners and Suppliers (SPARS) projects used acombination of component-based software internet protocols anda portable computing platform to satisfy the following shipbuild-ing information technical requirements

An information technology gap separates the large me-dium and small shipyards

Fig 12 System architecture of the STEP manager (Reprinted from Shin amp Han 1998 with permission from Elsevier)

The information technology staffs at most shipyards areexperts in shipbuilding process requirements but not in system-level computer technologies

Shipyard information systems must be reliable and main-tainable yet often need to be customized to suit an individualshipyard

As with many other projects (Rando 2001 Gischner et al 2001)integration within the shipbuilding industry was considered pos-sible only by the reuse of existing software components becausethe number of shipbuilding system requirements is so diverse thatit is unrealistic to assume that it is possible to produce a singleoverarching solution The integrated system was considered toconsist of a number of independent components to be assembledand reused by third parties in order to create a new complexsystem The initial task of the SHIIP project was to define areference architecture to support the composition of the indepen-dent components

The management of the product data was achieved using En-terprise Java Beans (EJB) that enable persistent storage secureaccess and load balancing for multiple users wishing to access thedata simultaneously At the start of the SHIIP project however

EJB was not available and the project relied instead on CORBAtechnology The project learned the following lessons from usingCORBA

Technology independence although useful in theoryshould not be pursued at the expense of developing workingimplementations

Technical interoperability is not a requirement for the de-velopment of an industrial information infrastructure Support-ing applications and software components for the informationinfrastructure are homogeneous enough to be implemented in asingle implementation technology

The Object Management Group (OMG) while advocatingseparation of components has produced in the arena of do-main standards wrappers for monolithic applications

OMG has been hampered by the inability to reach timelyconsensus

The Integrated Shipbuilding Environment (ISE) project withinthe Maritech Advanced Shipbuilding Enterprise (ASE) is usingXML as the basis for achieving interoperability between ship-building systems technologies specifically between application toapplication (Rando 2001) Rando differentiates this problem fromthat of other industries by stating that many of the applicationcomponents used within the shipbuilding industry have alreadybeen developed as well as the having little control over the de-velopment of these systems The shipbuilding product model mayalso contain millions of instances of a large number of differenttypes of information that need to be managed as they evolve overthe productrsquos life cycle It is also suggested that not only is therea need to rely on an enterprise system that augments the manyspecialist applications but due to the diversity of informationwithin the life cycle of the ship no single information system issufficient to deal with the entire ship product Indeed previousalliances between shipyards have been one-off solutions and thereis a definite requirement for a standardized effort for the shipproduct model

Rando identified a number of business drivers in order toachieve interoperability within the shipbuilding industry and pro-

Fig 13 Domain-based ship system (Crawford et al 1999)

Fig 14 ISE reference architecture three levels of interoperability (Rando 2001)

posed an architecture in order to respond to these drivers (Fig 14)The architecture represents three interoperability levels within theshipbuilding environment intercomponent refers to the interac-tions between the software components within a system intersys-tem refers to the interactions between the systems and is boundedby a business system domain and interenterprise interoperabilityrefers to interactions between business systems domains at differ-ent shipyards and organizations

The key elements for achieving this interoperability were acommon syntax using XML to facilitate communication a sharedstandard information model using STEP and an interoperabilityinfrastructure using web-based technologies XML is a neutralformat that may be viewed by humans (although this is not gen-erally a primary requirement) and that enables the sharing of in-formation between different technologies different operating sys-tems and different programming languages Five keyrequirements were identif ied to facilitate application-to-application integration

Should ldquoreuserdquo widely available standards-based tools Should be implementable with tools that allow for recon-

figuration by nonprogrammers Should support transformation to and from a canonical or

neutral format Should utilize a representation that is as simple and con-

cise as possible Should be able to marshalunmarshal every semantic con-

cept representable in the EXPRESS information modeling lan-guage (ISO 10303-11)

One of the most significant issues relating to the use and inte-gration of ship product models with existing applications appearsto be the need to ldquoflavorrdquo the model and specifications to suit theparticular requirements of the design and simulation applicationsWithout these embellishments the fully automated data integra-tion appears quite often difficult to achieve There are howeverconflicting opinions regarding the effectiveness of automating thisprocess generally arising due to the complexity of the problem andthe level of support The application of ldquoflavoredrdquo standards doeshowever entirely go against the point of creating a standard es-pecially when it is with respect to the transfer of product data Itcould therefore be concluded that the solution to the effectiveintegration of STEP lies not in the modification of a new tech-nology to satisfy the requirements of legacy applications but inthe updating of the legacy applications to satisfy the new technol-ogy

Life-cycle issues

The NEUTRABAS project (Welsh et al 1992) was limited tothe precommissioning stages that is marketing conceptual de-sign detailed design drafting materials ordering productionplanning and control scheduling and quality control However itwas recognized that significant benefits would be achievedthrough extending the life cycle through to disposal Welsh et alqualified the limitation to the precommissioning stages by statingthat ldquothe definition and implementation of a complete product datamodel covering all of these aspects of the life-cycle of an engi-neering product as complex as a ship is an onerous task and one

which would require the commitment of a vast amount of time andeffortrdquo

Limiting the project to the precommissioning stages would ap-pear to have been a wise judgment because in the 10 years fol-lowing this project the standards created to describe the shipproduct model have still not yet been finalized

Welsh et al suggest that the physical representation of the prod-uct within each life cycle stage would ldquonormally be unchanged inthe global sense although the information associated with theproduct and the techniques used to represent it will vary consid-erablyrdquo that is the information contained within the productmodel would mature as more detail becomes available as well asrequiring different viewpoints at each life-cycle stage The productmodel must therefore be developed not only with the associateddata and structure in mind but also with the life-cycle stages Toenable the support of the precommissioning life-cycle stagesWelsh et al identified four views that need to be supported by theship product model

Marketing-oriented view Management-oriented view Design-oriented view Production-oriented view

Von Haartman et al (1994) briefly discussed life phase issues ofthe ship product model and suggested that a number of systemsmodel the design with too much detail and hence are not appli-cable to the concept design stage A solution to this was thedevelopment of a concept design product model that could then betransferred to the detailed design stage It is not clear from thiswhether Von Haartman et al were proposing separate models forthe two stages or if the detail product model would simply consistof the concept product model plus the additional required detail

The mechanism of having multiple different views for the shar-ing of a product model among designers and production engineersfor example has been considered and implemented in a number ofcases (Polini amp Meland 1997 Johansson 1995) Johansson indi-cated that it is common for parts of the product to be in differentlife-cycle stages at the same time that is the ldquomanufacture of onepart of the product is going on at the same time as the detaileddesign of anotherrdquo This is one aspect of concurrent engineeringwith the result of reducing the lead times because the manufactureof the product has started before the design of the product has beencompleted However it is necessary to ensure both that manufac-turing starts only on parts that require no further design and thatother parts that are currently being designed do not propagatechanges to the manufactured parts The management and controlof the information flow were recognized as being the key elementsin increasing the overlapping of life cycles However no expla-nation was given by Johansson regarding the nature of the man-agement other than through the relationships between the objectscontained within the model These relationships were described asa mechanism to enable both interdisciplinary and cross-disciplinary communication among designers

The three-dimensional product model was described by Baumand Ramakrishnan (1997) as being a mechanism to enable a num-ber of different life-cycle stage simulations such as interferencechecking crew traffic flow studies yard-specific designs and fi-nite capacity scheduling through the use of a virtual environmentdesign review technology using data contained within the productmodel (Fig 15)

Coupled with simulation-based design (SBD) Baum describedthe combined technology as ldquothe new frontierrdquo that would enablethe virtual prototyping of the ship which previously could not beachieved due to the cost and complexity More importantly Baumrecognized that just as interference-checking software may beused to determine discrepancies between geometric parts duringthe design and production phases SBD may be used to reduce oreliminate design errors that would have previously have beendiscovered years later in the operational stage for example Es-sentially SBD and product modeling enable the validation of thedesign production and operation stages of the ship product

Baum also finally suggested that the product model provides asignificant benefit to the owneroperator by enabling the analysisand support of life-cycle maintenance

A generic shipyard computer modeling tool for evaluating de-sign for production (DFP) is discussed by Lamb et al (2000) Thetool enables shipyards to be modeled such that the impacts ofchanges to the ship design may be determined on the basis of theresulting material manpower and schedule The shipyard modelrepresents details of the buildingsmdashtheir arrangement and size aswell as equipment capacity and flow The tool also enables aninvestigation of the necessary changes required for a shipyard inorder to produce a new design The key foundations in order toevaluate these impacts are the interim product catalogue and thebuild strategy approach

Lamb et al identified a number of important concepts for DFP

All designs should be prepared to suit a shipyardrsquos facili-ties and preferred production methods

DFP takes into account production methods and tech-niques that reduce the product work content but still meet thespecified design requirements and quality

DFP must be incorporated into a design from the start Traditional engineering leaves it up to another department

such as production or manufacturing engineering to developthe technical documentation required for the production work-ers This is an unnecessary duplication of effort and is a nonndashvalue-added task that takes time

An objective of the CE approach is to accommodate DFPby bringing all the necessary people together right from dayone on a project

The time to influence the cost of a product is during theearly stages After the design has been developed in conceptmost of the opportunity to positively affect cost is gone

World-class ship designers know how their shipyardbuilds ships and design accordingly Many ship designers donot consider this and the designs may or may not be efficientlybuilt in their facilities More shipbuilders have taken steps toremedy this situation through the use of the build strategyapproach

Engineering should be prepared and transmitted to theusers in a way that best suits block construction advanced andzone outfitting

An object-oriented approach was adopted for the constructionof the model (Fig 16) The model represents shipyards worksta-tions products equipment processes manufacturing processesmaterial handling processes and interim products The tool wasapplied to the evaluation of two design alternatives for the bottomstructure of a ship The authors demonstrated that the tool enabledreliable evaluations of the man-hours for manufacturing and ma-terial handling such that the best design alternative could beadopted

Future directions

It is believed that the ship STEP APs will become the standardunit of shipbuilding data but that it will probably be an evolution-ary process as advances in technology and modeling capabilitiesand requirements are incorporated It is however crucial that thedevelopment of the standards comes to a timely consensus at eachevolutionary stage The literature reviewed has discussed the useof ldquointelligentrdquo data the inclusion of useful functionality accord-ing to the data type and of behavioral aspects It is anticipated thatthis functionality behavioral aspects and so forth will increas-

Fig 15 Ship design workflow using three-dimensional product model (Baum amp Ramakrishnan 1997)

ingly become part of the model to the extent that the model nolonger has any need for interfaces and translators to legacy soft-ware For example the piping model would automatically calcu-late interferences and the structures model would automaticallycalculate stress characteristics The simulation would essentiallybe part of the model and the model would contain additionalinformation and knowledge to effectively manage the simulationThis is not to say that the model would become a monolithicsystem despite such a system being potentially computationallyviable in 10 years Rather than being monolithic current andfuture distributed information technologies such as EnterpriseJava Beans may be utilized in order to distribute the model acrossa network while giving the impression to the user that the systemis monolithic Ship product data and functionality would be dis-tributed either within a single company or as partnerships withother companies

In a similar way that the ship product data has become stan-dardized benefits are to be gained from standardizing the inter-faces between applications to support the flow of standardizeddata and achieve a truly seamless integration The unfortunateshortcoming of application standardization is the necessity to re-develop the legacy systems to support this level of integration

The VRShips project addresses the management of ship productdata within a neutrally formatted common model The geometry

data contained within the common model are based on STEPAP203 are described using XML and are considered as beingcommon data if two or more applications access it Integration isprovided between the legacy applications and the common modelvia ldquogeneric wrappersrdquo that provide the general management re-quired in order to operate the applications The wrappers convertthe data to and from the native format using modular conversionalgorithms that can be plugged into the wrappers and provide thedomain-specific management for the applications Data are auto-matically downloaded from the common model and converted intothe native format when the application is started When the appli-cation is complete the designer has the option of undertaking thereverse process to convert the data back into the neutral format andupload into the common model Despite being a complex processconverters have been produced for a number of design applica-tions such as Tribon and AVPro and have been demonstrated tooperate without the need for manual interaction However theissues relating to the lack of integration between tools and con-tinuous product models remain to be addressed

The VRShips system also has an additional management layerconsisting of a process controller and an inference engine that arejointly responsible for maintaining data consistency and versionconstraint and process management Visualizing of product datavia the legacy applications is managed through the exporting of

Fig 16 Object diagram for generic shipyard computer model (Lamb et al 2000)

the displays via a virtual interaction environment These controlmechanisms ensure that designers may modify the data containedwithin the common model from any location either organization-ally or geographically distributed with network access using anapplication that they are familiar with and that any changes madeto the product model are correctly propagated such that the dataremain consistent

Every product modeling tool and technique discussed withinthis review is common from the perspective that the data containedwithin the model are a ldquosnapshotrdquo of the actual design activity Forinstance a designer may download data from the ship productmodel for use within a general design package which may take aweek to design During this design period the data within theproduct model do not change until the designer decides that thedesign process is complete and the data are uploaded into theproduct model The product model therefore does not contain acontinuous representation of either the design work that is cur-rently being undertaken or the form that the data are in This posesa number of significant project management issues with respect toversion control consistency management and conflict resolutionespecially in the situation where the design process is being un-dertaken in a distributed manner as is increasingly becomingcommon

A paradigm shift in the techniques used to enable the distributeddesign of ships while enabling a continuous product model andfacilitating the management of conflicts and consistency would bethe adoption of a technology that is more often seen within thecomputer games industry Graphics servers are commonly usedwithin the games industry to enable the user to immerse them-selves within an environment and interact both with the environ-ment and with other users High-level graphical objects are com-municated between the server side and the client side rather thanusing structured files This technique bypasses the need to trans-late the communicated data into the client side format alleviatingunnecessary computation It also results in a model containedwithin the server and represented within the clients that is a con-tinuous depiction of what everyone is undertaking The ship prod-uct data would remain within the ship STEP formats Howeverthe description method would be the graphical object representa-tion that would also exhibit behavioral properties Within the ship-building context individual graphics servers would represent do-mains similar to those identified by Crawford et al (1999) Clientsconnecting to the servers would immediately get an up-to-dateview of that particular domain which would be consistent with theviews of all of the other clients The client software would operatein a manner similar to conventional design applications There isalso clearly a requirement for integration between the differentdomain servers to enable conflicts to be resolved across domainsSimulation servers would integrate all of the scenarios that wouldenable an evaluation of the performance within any particular lifephase There would still remain the need to provide an effectivemanagement of different versions as well as a high-level coordi-nation structure to manage conflicts constraints design goals andcollaboration among designers However the underlying frame-work would provide the basis on which to construct this Despitebeing a significant step-change compared with current practicethis future technique proposes a viable solution to the effectivemanagement of a ship product model that may be manipulated andoperated upon in a distributed manner

This type of architecture does however raise a number of

issues relating to partnerships between the shipbuilding industryand the shipbuilding software industry because the system wouldrepresent an amalgamation of existing design and simulation ap-plications into a number of domain-specific servers The intellec-tual property rights as well as the ownership of both the technol-ogy and the data contained would clearly need to be resolved Inaddition the system calls upon the need to implement a standardfor the communication of the graphical objects that is both secureand robust whereas the standard for the data may be ldquoflavoredrdquoand managed effectively within the system via the ability to dy-namically load classes

Just as many of the precommissioning life phases are currentlybeing modeled it is anticipated that the rather poorly supportedpostcommissioning life phases will be catered for The most sig-nificant difference between pre- and postcommissioning is that itwill be the ship product model in its entirety that will be consid-ered For example there currently appears to be a significantopportunity for the specialization of the immersion of an entireship product model into an artificial environment to determine theoperational performance both at virtual sea (modeling existingshipping lanes to determine sea-keeping characteristics) within avirtual port (modeling existing ports to determine cargo-handlingcharacteristics) within a virtual shipyard for recommissioning(modeling existing shipyards to determine recommissioning capa-bility) and within a virtual breakers yard for disposal (to deter-mine scrap value) Increased opportunity would therefore be madefor designing the ship to meet a more rigorous set of customer-specified life-phase requirements and would represent a signifi-cant commercial advantage

It is also interesting at this point to note that a number of thecited papers have stated the need to avoid a reliance on computerprogrammers which in order to maintain even the simplest ofproduct data modeling systems seems unachievable

Conclusions

From the increasing amount of literature and the papers re-viewed within this paper related to the ship product model theprimary focus is on developing a standard representation for thedata contained within the model Despite not having yet finalizedthe standards for all aspects of the ship the STEP APs go a longway toward achieving this It is almost inconceivable to considerthat an alternative could compete against such a massive thrusttoward ship data standardization A number of instances havearisen however when the APs have been adhered to with theresult that ldquoflavorsrdquo or minor changes to the standard have beenrequired in order to utilize the structured well-defined and stan-dardized data within the legacy applications The question there-fore arises as to whether there is a requirement to standardize thelegacy applications such that they adhere to the data standard toenable a modular plug-in approach to ship design and simulation

Behavioral aspects have been considered within a number of thecited papers to be an important addition to the data in order toprovide the designer with additional feedback with respect to theoperation of the design This behavior may however be betterrepresented as high-level rules within a standard that are used todefine the operation of the ship rather than in existing standardsin order to minimize its impact on applications that have no needfor such data

A number of the tools and techniques discussed have described

the use of the ship STEP formats as being a mechanism for inte-grating existing legacy applications with a common model of shipproduct data Considerable benefit would be obtained from pro-viding similar integration between applications to progress fromthe limitations of discrete design and simulation toward having aholistic approach

The design tasks that are undertaken as part of the ship designprocess may well take a considerable amount of time and wouldconventionally result in ldquosnapshotsrdquo of the design artifact coin-ciding with the designer uploading data into the common modelA number of future directions have been discussed which wouldindividually require considerable development in order to imple-ment but which represent possible solutions to issues relating to

Continuous rather than ldquosnapshotrdquo ship product models Integration between the ship product model and the design

and simulation applications as well as across applications Removal of information translation problems through the

use of high-level graphical objects that are consistent betweenservers and applications

A collaborative framework on which to develop versionconflict and consistency management

Acknowledgments

The review was undertaken as part of an investigation intocommon model techniques within the VRShips-ROPAX2000project The authors gratefully acknowledge the support given bythe European Commission Community Research 5th Frameworkprogram under the area of Competitive and Sustainable Growthwhich provided the grant (G3RD-CT-2001-00506) that enabledthis work to be undertaken

References

BAUM S J AND RAMAKRISHNAN R 1997 Applying 3D product modelingtechnology in shipbuilding Marine Technology 34 1 56ndash65

CATLEY D 1999 Prototype STEP data exchanges in ship initial design andprovision of an application programmer interface to TRIBON Proceedings10th International Conference on Computer Applications in ShipbuildingJune Cambridge MA

CRAWFORD A K HARRINGTON G AMES R M AND VAN ESELTINE RT 1999 Neutral format data exchanges between ship product models andanalysis interfaces Proceedings 10th International Conference on Com-puter Applications in Shipbuilding June Cambridge MA

ERIKSTAD S O AND FATHI D E 1999 Applying the STEP shipbuildingprotocols as a basis for integrating existing in-house ship design applica-tions Proceedings 10th International Conference on Computer Applica-tions in Shipbuilding June Cambridge MA

GISCHNER B KASSEL B LAZO P WOOD R AND WYMAN J 2001 Evolution of STEP (ESTEP) exchange of shipbuilding productmodel data JOURNAL OF SHIP PRODUCTION 17 3 151ndash160

GRAU M AND KOCH T 1999 Applying STEP technology to shipbuildingProceedings 10th International Conference on Computer Applications inShipbuilding June Cambridge MA

HERZOG E AND TOumlRNE A 1999 A seed for a STEP application protocolfor systems engineering Proceedings 12th International Conference andWorkshop on the Engineering of Computer Based Systems Institute ofElectrical and Electronics Engineers Press Piscataway NJ 174ndash180

HIGNEY J T AND OUILETTE J J 1994 An engineering product modelbased on STEP protocols JOURNAL OF SHIP PRODUCTION 10 4 281ndash286

ISO 1996 Product Data Representation and Exchange Part 218 Ship Struc-

tures International Standards Organization Hamburg GermanyJOHANSSON K 1995 The product model as a central information source in

a shipbuilding environment Proceedings National Shipbuilding ResearchProgram 1995 Ship Production Symposium June Seattle WA

LAMB T CHUNG H AND SHIN J G 2000 A generic shipyard computermodel a tool for design for production Proceedings 7th IMDC NovemberKyung-Ju Korea

MARTIN D J 1980 The shipyard product information system as an aid toimplementing more productive strategies Proceedings Research and Engi-neering for Automation and Productivity in Shipbuilding IIT Research In-stitute October Chicago IL 81ndash101

POLINI M A AND MELAND K E 1997 The development and implemen-tation of a SMART product model for ship structure Proceedings 9thInternational Conference on Computer Applications in Shipbuilding Octo-ber Yokohama Japan

RANDO T C AND FERNHOLZ D 2000 MARITECHrsquos shipbuilding infor-mation infrastructure JOURNAL OF SHIP PRODUCTION 16 2 110ndash120

RANDO T C 2001 XML-based interoperability in the integrated shipbuild-ing environment (ISE) JOURNAL OF SHIP PRODUCTION 17 2 69ndash75

ROSS J M AND GARCIA L 1998 Making the jump to product modeltechnology JOURNAL OF SHIP PRODUCTION 14 1 15ndash26

ROSS J M AND ABAL D 2001 Practical use of 3D product modeling inthe small shipyard JOURNAL OF SHIP PRODUCTION 17 1 27ndash34

SCHMIDT W R VANDER J R AND SHIELDS V R 1990 Modelling andtransfer of product model digital data for the DDG 51 class destroyer pro-gram Proceedings National Shipbuilding Research Program 1990 ShipProduction Symposium August Milwaukee WI

SHIN Y AND HAN S H 1998 Data enhancement for sharing of shipdesign models Computer-Aided Design 30 12 931ndash941

VON HAARTMAN J KUUTTI I AND SCHAUMAN C 1994 Improving designproductivity with a product model for initial ship design Proceedings 8thInternational Conference on Computer Applications in Shipbuilding Sep-tember Bremen Germany

WELSH M LYNCH J AND BRUN B 1992 A data model for integration ofthe precommissioning life-cycle stages of the shipbuildingproduct JOURNAL

OF SHIP PRODUCTION 8 4 220ndash234WHITFIELD R I COATE S G DUFFY A H B AND HILLS

W 2000 Coordination approaches and systemsmdashpart I a strategic per-spective Research in Engineering Design 12 73ndash89

WYMAN J WOOLEY D GISCHNER B AND HOWELL J 1997 Development of STEP ship model database and translators fordata exchange between shipyards JOURNAL OF SHIP PRODUCTION 13 2111ndash124

Internet addresses

European Marine STEP Association httpemsagermanlloydorg

ISO STEP ship team http wwwnsnetcomNIDDESCt23html

Japan Marine Standards Association http wwwjecalsjipdecorjp

Korea STEP Centre httpksteporkr

3 Development of direct translators by a software developerspecializing in computer-aided design (CAD) direct transla-tors

4 Use of a neutral file that defines object data

Option 1 was rejected due to the associated shipyardsrsquo usingobject- rather than entity-oriented CAD software PDES was con-sidered to result with a delay of several years to implement aproduction translator hence option 2 was rejected Flexibility andexpansion were considered as restricting factors for option 3 Fi-nally option 4 was accepted due to the ability to develop a neutralmodel in the available time and the flexibility and future expan-sion of such a model

Schmidt et al also introduced the concept of the ldquodesign win-dowrdquo to transfer only the part of the model that was required ratherthan the entire model by specifying boundaries for the design zoneto be transferred One important aspect related to the transfer ofpartial data was the requirement for effective configuration man-agement such that changes made to the partial models were re-flected within the overall model Higney and Ouilette (1994) fol-lowed up the discussion of Schmidt with a description of a STEP-based product model for the AEGIS destroyer The product modelwas split into two parts a graphical model and a relational data-base containing nongraphical data NIAM diagrams were initiallyused to define the relationships within the relational database Themodel was developed based on the more fully developed STEPpiping AP However other APs were to be included when theybecame available

Welsh et al (1992) focussed on the precommissioning life-cyclestages of the shipbuilding product model while developing aframework to integrate disparate computer-based information sys-tems within the ESPRIT IIndashfunded NEUTRABAS project (Fig 8)The underlying mechanism to achieve this integration was a prod-uct model database to contain and manage neutral shipbuildingdata specifically spatial structural integration outfitting and en-gineering systems data It was identified that the structure of thedata was as important as the data themselves in order to effectively

manage the exchange of the data across various complex andheterogeneous ship development applications

Baum and Ramakrishnan (1997) suggested that associativitydata are extremely useful additions to the product model becausethey enable changes made to any one of the objects within thedatabase to be reflected in all associated objects Baum and Ra-makrishnan however did not suggest how this change propaga-tion is managed because without due coordination the impact ofthe change may result in chaotic behavior in complex systems(Whitfield et al 2000) Additionally there is no discussion regard-ing the requirement to simulate the reflected change using thesimulation software to determine the adequacy of the initialchange

The overall aims of the NEUTRABAS project were defined as

The standardization of the way in which information con-cerning marine-related products is represented

The development of standard methods for the exchangeand storage of product definition data in the marine industry

The specification and development of a suitable databasearchitecture that will facilitate the exchange and storage of suchproduct definition data

The implementation of a prototype data exchange andstorage system based on the previously defined database ar-chitecture which will demonstrate the feasibility of a trulyintegrated product life cycle

The authors identified a number of benefits associated with theabove aims such as the reduction of project time scales throughthe adoption of a single managed information store Managing theinformation within a single database is intended to avoid infor-mation mismatches and hence reduce the amount of rework which

Fig 7 Product information system layout (Martin 1980)

Fig 8 The NEUTRABAS system architecture (Welsh et al 1992)

has indeed been reported within a number of publications How-ever there has never been any consideration of the database con-trol mechanisms required to prevent the database from becomingan information bottleneck despite the assumption that a benefitwould be more effective information management or the in-creased duration associated with searching a single (extremely)large database for the required piece of data despite the assump-tion that a benefit would be rapid information disseminationThere is also the suggestion that using such a representation ofproduct data will avoid the need to transcribe the data betweendifferent application systems eliminating the introduction of errorthrough human interaction However a number of papers havesince reported on the requirement of application interfaces totranslate the product data into a format suitable for the intendedapplication Indeed Rando (2001) reported that in some cases adegree of human interaction has been required to ensure that thisprocess runs smoothly Conversely Catley (1999) suggested thatthe minimization of human interaction within the data exchangeprocess has resulted in more consistent design Finally the authorsidentified the benefit associated with improving the interface be-tween the supplier and the client through the introduction of elec-tronic product definition databases

The NEUTRABAS system was composed of an application-independent EXPRESS model defining the shipbuilding producta data dictionary to manage requests to the database a mappingbetween the model and the dictionary in the form of an EXPRESSimport tool the data management component to enable the cre-ation communication modification and querying of productmodel data a number of application interfaces to enable the in-dividual applications to interact with the database a number ofdatabase interfaces to enable communication between specific da-tabase management systems and the NEUTRABAS database anda database generator that enables the mapping of data within aspecific database to the data within the NEUTRABAS database

Von Haartman et al (1994) described the ship product modelwithin the NAPA project and realized the potential of the productmodel as a basis for concurrent engineering (CE) The use ofcomputers within the shipbuilding industry was previously re-stricted to the computationally intensive applications such as thecalculation of hydrostatics and stability These applications havehad a great deal of development to produce tools that represent andmodel a particular characteristic of the design quite accuratelyThey have generally received a great deal of investment of timeand money (Crawford et al 1999) Von Haartman et al suggest thatthe modern ship design process should ideally consist of a singlesystem that augments all of the disparate design tools but that oneshould recognize that such a system is far from reality The alter-native was to provide a framework to interlink these design toolsto give the impression of a single system The ship product modelwas the key to interlinking these tools

Von Haartman et al also stated ldquoAny model merely reflectsselected properties of the object it is intended to describe and theappropriate selection of properties is of central importance whendesigning the modelrdquo Within the NAPA ship product modelglobal properties of the ship were identified such as the maindimensions hull form and so forth and although not explicitlystated it is assumed that these global properties were chosenpartly for the reason that they are common among the design toolsbeing utilized These properties within the model may also be usedto evaluate the economic and technical requirements of the ship

Finally Von Haartman et al stated that the lack of detail of theglobal properties within the ship product model is not synonymouswith inaccuracy

Johansson (1995) described the challenge of modern shipbuild-ing as ldquoto manage and control the design and assembly process togain efficiency and short delivery timesrdquo By summarizing theshipbuilding process life-cycle stages as tendering design pro-duction planning materials finance and follow-up the require-ment for the effective management of the extremely large amountsof information was established in order to ensure the efficientorganization of the shipbuilding process Johansson suggested thatthis requirement could be satisfied only through the developmentof ldquoan information flow solution specifically designed for thisindustryrdquo and suggested that it was not sufficient just to automateexisting manual activities Rather the organization should beadapted to the use of new tools to streamline the information flowwherever possible The discussion appeared however to be re-stricted to information flows within a single shipbuilding organi-zation with the main focus on how the information may be utilizedto improve the production process

The product model concept was regarded by Johansson as beingone such tool whereby the organization may be streamlinedthroughout the precommissioning stages by providing a consis-tent model to enable well thought-out build strategies to be de-veloped early ordering of materials and material handling pre-fabrication preoutfitting and the use of numerically controlledmachines

Additional information was contained within the productmodel such as material codes weights surface treatments and soforth For this reason Johansson suggested that a more appropriateterm may be product information model because the modelshould contain all technical product definition data and may beused to provide for example graphical representations of geom-etry as well as lists and reports of material requirements Addi-tionally Johansson stated that the generation of a graphical rep-resentation should be produced only when it is required and to theextent that is suitable in order to avoid unnecessary computationThe graphical representation is regarded as secondary informationof the (primary) information stored in the product model Theinformation flow may be streamlined by the manipulation of theprimary information rather than the secondary information

Johansson also recognized that it was important that ldquoa productmodel based system must understand what the different parts ofthe system really represent and be able to interpret the rules andrestrictions connected to each type of objectrdquo

Erikstad and Fathi (1999) described how a STEP-based shipproduct model could be used within the ShipX project for theintegration of the data within a number of hydrodynamic analysisapplications for a ship The applications were previously devel-oped as stand-alone applications to specific aspects of the hydro-dynamic performance of the ship such as propulsion and seakeeping Previous integration among the applications wasachieved through the development of translators to allow for theexchange of information However the technique was difficult toimplement and maintain and was not considered to be seamlessThe communication of information among applications is clearlya central issue that has been discussed in a number of reports(Wyman et al 1997 Gischner et al 2001) Essentially the optionsare either to develop a direct interface between every pair ofcomponents or develop the interfaces based on a consistent inter-

face standard A common product model (Fig 9) was imple-mented within ShipX and from the application developmentviewpoint it enabled

Developers to concentrate more on the specific simulationproblem rather than the modeling of the data This benefit isrealized every time a particular application goes through rede-velopment or when new applications are developed

Guaranteed synchronization of data between the applica-tions and the product model Translators were previously usedto convert the product data to and from the required formats foreach application Changes could potentially be made to theproduct model after data translation to the application resultingin a discrepancy in the translated data The product modeltechnique ensures that each application has a common repre-sentation of the ship

Reuse of previous applications and graphical user inter-faces eliminating the need for the end user to relearn how touse the application

Despite integrating existing applications with the productmodel it is not clear within the ShipX project whether integrationexisted between applications For example two discrete applica-tions may be considered as damage stability assessment andevacuation simulation both integrated via the product model It ispossible to make assessments of the performance of the ship withrespect to both the damage stability and the evacuation in isola-tion via the integration with the product model However inte-gration is required between the damage stability and evacuationapplications in order to assess the evacuation time while compart-ments are flooding

The ShipX product model was developed using the relevantshipbuilding protocols developed within STEP which were imple-mented into a class library and stored using an object-orienteddatabase

Erikstad gave a number of useful guidelines for the develop-ment of the ShipX system

Simplicity The development of a comprehensive productmodel tool was considered to be prohibitive both from theaspects of timeliness and cost effectiveness Wherever pos-sible commercial off-the-shelf components were used Thedevelopment of the actual product model was undertaken usingthe STEP shipbuilding protocols rather than developing anin-house product model from scratch

Flexibility and extensibility The model was initially lim-ited to representing data that were specific to hydrodynamicperformance However consideration was given to the struc-ture of the model such that it could be extended to representother performance aspects Also the use of STEP to producethe common product model enables the scope of ShipX to beextended without restructuring the model The facade designpattern was also used to hide the complexity of the productmodel from the client applications define the correct usage ofthe product model by the client applications and enable theupdating of the product model without affecting the client ap-plications

Weak bindings to platform and programming language toenable the cross-platform and cross-language integration of theproduct model

Baum and Ramakrishnan (1997) regarded three-dimensionalproduct model technology as being fundamental for the imple-mentation of concurrent engineering (CE) within shipbuilding dueto the ability to develop capture represent integrate and coor-dinate data and permit simultaneous access to a number of usersBaum defined the product model as ldquothe integration of the 3Dgeometric model and non-geometric database informationrdquo whichmay be a logical integration of distributed information (Fig 10)

Simulation and interaction with the objects within the productmodel through the introduction of anthropomorphic models into avirtual environment to test functionality and operability were dis-cussed as being a useful technique to test the validity of the modelin a way similar to what would be achieved with the final productThe resulting model is essentially an electronic ldquomock-uprdquo Baumsuggested therefore that it is important to also represent the nor-mal behavior of the objects within the ship product model suchthat their behavior may also be analyzed enabling the product tobe designed manipulated analyzed constructed tested operatedsupported and disposed of in a virtual environment

Ross and Garcia (1998) and Ross and Abal (2001) discussed theutilization of product modeling technologies within two differentshipyard applications new build and conversion with the focus ofaiding shipyard managers with the decision to adopt such tech-nologies Ross suggests that the key characteristic of the productmodel for achieving a high level of integration is the adoption ofa single database allowing a number of designers to simulta-neously work on the same design through effective database man-agement and reducing or preventing altogether the inconsistency

Fig 9 From data translators to data integration within the ShipX project (Erikstad amp Fathi 1999)

of information A number of small shipyards that have incorpo-rated product-modeling technologies are used as case studies todiscuss the techniquersquos effectiveness with the conclusions thatthese shipyards have an improved production quality and signifi-cant savings in material cost labor cost construction cost andlabor hours Despite being a more complex representation thantraditional techniques Ross and Abal (2001) concluded that stafftraining was straightforward and that staff were considered com-petent after the design of the first vessel

Polini and Meland (1997) discussed the extension of a prototypeproduct modeling system through to the development of a pro-duction implementation that was capable of supporting concur-rent multiuser access Life-cycle data and behavior were modeledwithin the classes contained in the Smart Product Modelling(SPM) system The differentiation between a standard productmodel and an SPM system is shown in Fig 11 To appreciate theamount of effort involved in developing the SPM Polini andMeland state ldquoTo date nearly 45 man-years of software devel-opment have been invested in the SPM and its GUI approxi-mately 1000 classes with over 30000 methods have been devel-oped object oriented databases on the order of 25 gigabytes arecommonplace 24 concurrent users have modeled five shipclasses and tens of thousands of structural parts have been manu-facturedrdquo

This development was undertaken entirely within a shipyardwithout any commercial input Polini and Meland justified thisdevelopment by surveying the requirements of the shipyard andconcluding that there were no commercially available systemscapable of dealing with the degrees of specialization within theshipbuilding industry a point that has also been made by Jo-hansson (1995)

One of the questions asked by Shin and Han (1998) and others(Baum amp Ramakrishnan 1997) is whether it is possible to imple-ment paperless design because designers often spend a great dealof time trying to extract useful information from two-dimensionalpaper drawings The shipbuilding building blocks within the STEPshipbuilding APs were used as the basis to produce a ship product

model Shin used the STEP toolkit ST-Developer to produce C++classes using the EXPRESS data definition language for the mid-ship section of a bulk carrier

The classes were enhanced to enable all life-cycle product in-formation to be stored within a single data structure as well as fortranslating data formats by one-to-one mapping and includingexplicit information (Youngrsquos modulus Poissonrsquos ratio) from de-sign conventions available within the product model The systemarchitecture can be seen in Fig 12 This enhancement was re-quired because Shin suggested that it was not sufficient to simplytranslate data from a neutral format into the format required byeach application Rather it is a requirement of each applicationthat associated functions and information specific to each appli-cation is also incorporated into the model

This requirement for functional data was also discussed byCrawford et al (1999) Rather than relying on a flat neutral file tocontain geometry and topology information it was considereduseful that the topological data for example were provided withsome sort of intelligence to facilitate the translation between ap-plications The STEP standards were adhered to wherever pos-sible However achieving intelligent topology required extensionof the standards Crawford defined the Newport News Shipbuild-ing view of a product model as ldquoan all encompassing model of a

Fig 11 Product model definitions (Polini amp Meland 1997)

Fig 10 Representation of a ship three-dimensional product model (Baum amp Ramakrishnan 1997)

ship project taking advantage of the available computer toolsfor describing the geometry of a ship but it also includes allattributes necessary for the design production and operation ofthe shiprdquo

Again it was considered unlikely that the ship could be definedby a single computer system rather than by a number of moremanageable systems grouped according to some arbitrarily de-fined domains (Fig 13)

Crawford demonstrated the use of intelligent topological andgeometric STEP-based data through the use of the GOBS commonobject request brokerage architecture (CORBA) server that pro-vides a number of methods to enable legacy tools to extract therequired data Two analysis tools were used to model the ship

vulnerability and hydrostatics which obtained their data from theGOBS server The analysis concluded that within the majority ofthe cases the STEP standard for geometric data (Part 42) wassufficient to represent the geometry for the ship

Rando and Fernholz (2000) describes how the DARPA Mar-itech Shipbuilding Information Infrastructure Project (SHIIP) andShipbuilding Partners and Suppliers (SPARS) projects used acombination of component-based software internet protocols anda portable computing platform to satisfy the following shipbuild-ing information technical requirements

An information technology gap separates the large me-dium and small shipyards

Fig 12 System architecture of the STEP manager (Reprinted from Shin amp Han 1998 with permission from Elsevier)

The information technology staffs at most shipyards areexperts in shipbuilding process requirements but not in system-level computer technologies

Shipyard information systems must be reliable and main-tainable yet often need to be customized to suit an individualshipyard

As with many other projects (Rando 2001 Gischner et al 2001)integration within the shipbuilding industry was considered pos-sible only by the reuse of existing software components becausethe number of shipbuilding system requirements is so diverse thatit is unrealistic to assume that it is possible to produce a singleoverarching solution The integrated system was considered toconsist of a number of independent components to be assembledand reused by third parties in order to create a new complexsystem The initial task of the SHIIP project was to define areference architecture to support the composition of the indepen-dent components

The management of the product data was achieved using En-terprise Java Beans (EJB) that enable persistent storage secureaccess and load balancing for multiple users wishing to access thedata simultaneously At the start of the SHIIP project however

EJB was not available and the project relied instead on CORBAtechnology The project learned the following lessons from usingCORBA

Technology independence although useful in theoryshould not be pursued at the expense of developing workingimplementations

Technical interoperability is not a requirement for the de-velopment of an industrial information infrastructure Support-ing applications and software components for the informationinfrastructure are homogeneous enough to be implemented in asingle implementation technology

The Object Management Group (OMG) while advocatingseparation of components has produced in the arena of do-main standards wrappers for monolithic applications

OMG has been hampered by the inability to reach timelyconsensus

The Integrated Shipbuilding Environment (ISE) project withinthe Maritech Advanced Shipbuilding Enterprise (ASE) is usingXML as the basis for achieving interoperability between ship-building systems technologies specifically between application toapplication (Rando 2001) Rando differentiates this problem fromthat of other industries by stating that many of the applicationcomponents used within the shipbuilding industry have alreadybeen developed as well as the having little control over the de-velopment of these systems The shipbuilding product model mayalso contain millions of instances of a large number of differenttypes of information that need to be managed as they evolve overthe productrsquos life cycle It is also suggested that not only is therea need to rely on an enterprise system that augments the manyspecialist applications but due to the diversity of informationwithin the life cycle of the ship no single information system issufficient to deal with the entire ship product Indeed previousalliances between shipyards have been one-off solutions and thereis a definite requirement for a standardized effort for the shipproduct model

Rando identified a number of business drivers in order toachieve interoperability within the shipbuilding industry and pro-

Fig 13 Domain-based ship system (Crawford et al 1999)

Fig 14 ISE reference architecture three levels of interoperability (Rando 2001)

posed an architecture in order to respond to these drivers (Fig 14)The architecture represents three interoperability levels within theshipbuilding environment intercomponent refers to the interac-tions between the software components within a system intersys-tem refers to the interactions between the systems and is boundedby a business system domain and interenterprise interoperabilityrefers to interactions between business systems domains at differ-ent shipyards and organizations

The key elements for achieving this interoperability were acommon syntax using XML to facilitate communication a sharedstandard information model using STEP and an interoperabilityinfrastructure using web-based technologies XML is a neutralformat that may be viewed by humans (although this is not gen-erally a primary requirement) and that enables the sharing of in-formation between different technologies different operating sys-tems and different programming languages Five keyrequirements were identif ied to facilitate application-to-application integration

Should ldquoreuserdquo widely available standards-based tools Should be implementable with tools that allow for recon-

figuration by nonprogrammers Should support transformation to and from a canonical or

neutral format Should utilize a representation that is as simple and con-

cise as possible Should be able to marshalunmarshal every semantic con-

cept representable in the EXPRESS information modeling lan-guage (ISO 10303-11)

One of the most significant issues relating to the use and inte-gration of ship product models with existing applications appearsto be the need to ldquoflavorrdquo the model and specifications to suit theparticular requirements of the design and simulation applicationsWithout these embellishments the fully automated data integra-tion appears quite often difficult to achieve There are howeverconflicting opinions regarding the effectiveness of automating thisprocess generally arising due to the complexity of the problem andthe level of support The application of ldquoflavoredrdquo standards doeshowever entirely go against the point of creating a standard es-pecially when it is with respect to the transfer of product data Itcould therefore be concluded that the solution to the effectiveintegration of STEP lies not in the modification of a new tech-nology to satisfy the requirements of legacy applications but inthe updating of the legacy applications to satisfy the new technol-ogy

Life-cycle issues

The NEUTRABAS project (Welsh et al 1992) was limited tothe precommissioning stages that is marketing conceptual de-sign detailed design drafting materials ordering productionplanning and control scheduling and quality control However itwas recognized that significant benefits would be achievedthrough extending the life cycle through to disposal Welsh et alqualified the limitation to the precommissioning stages by statingthat ldquothe definition and implementation of a complete product datamodel covering all of these aspects of the life-cycle of an engi-neering product as complex as a ship is an onerous task and one

which would require the commitment of a vast amount of time andeffortrdquo

Limiting the project to the precommissioning stages would ap-pear to have been a wise judgment because in the 10 years fol-lowing this project the standards created to describe the shipproduct model have still not yet been finalized

Welsh et al suggest that the physical representation of the prod-uct within each life cycle stage would ldquonormally be unchanged inthe global sense although the information associated with theproduct and the techniques used to represent it will vary consid-erablyrdquo that is the information contained within the productmodel would mature as more detail becomes available as well asrequiring different viewpoints at each life-cycle stage The productmodel must therefore be developed not only with the associateddata and structure in mind but also with the life-cycle stages Toenable the support of the precommissioning life-cycle stagesWelsh et al identified four views that need to be supported by theship product model

Marketing-oriented view Management-oriented view Design-oriented view Production-oriented view

Von Haartman et al (1994) briefly discussed life phase issues ofthe ship product model and suggested that a number of systemsmodel the design with too much detail and hence are not appli-cable to the concept design stage A solution to this was thedevelopment of a concept design product model that could then betransferred to the detailed design stage It is not clear from thiswhether Von Haartman et al were proposing separate models forthe two stages or if the detail product model would simply consistof the concept product model plus the additional required detail

The mechanism of having multiple different views for the shar-ing of a product model among designers and production engineersfor example has been considered and implemented in a number ofcases (Polini amp Meland 1997 Johansson 1995) Johansson indi-cated that it is common for parts of the product to be in differentlife-cycle stages at the same time that is the ldquomanufacture of onepart of the product is going on at the same time as the detaileddesign of anotherrdquo This is one aspect of concurrent engineeringwith the result of reducing the lead times because the manufactureof the product has started before the design of the product has beencompleted However it is necessary to ensure both that manufac-turing starts only on parts that require no further design and thatother parts that are currently being designed do not propagatechanges to the manufactured parts The management and controlof the information flow were recognized as being the key elementsin increasing the overlapping of life cycles However no expla-nation was given by Johansson regarding the nature of the man-agement other than through the relationships between the objectscontained within the model These relationships were described asa mechanism to enable both interdisciplinary and cross-disciplinary communication among designers

The three-dimensional product model was described by Baumand Ramakrishnan (1997) as being a mechanism to enable a num-ber of different life-cycle stage simulations such as interferencechecking crew traffic flow studies yard-specific designs and fi-nite capacity scheduling through the use of a virtual environmentdesign review technology using data contained within the productmodel (Fig 15)

Coupled with simulation-based design (SBD) Baum describedthe combined technology as ldquothe new frontierrdquo that would enablethe virtual prototyping of the ship which previously could not beachieved due to the cost and complexity More importantly Baumrecognized that just as interference-checking software may beused to determine discrepancies between geometric parts duringthe design and production phases SBD may be used to reduce oreliminate design errors that would have previously have beendiscovered years later in the operational stage for example Es-sentially SBD and product modeling enable the validation of thedesign production and operation stages of the ship product

Baum also finally suggested that the product model provides asignificant benefit to the owneroperator by enabling the analysisand support of life-cycle maintenance

A generic shipyard computer modeling tool for evaluating de-sign for production (DFP) is discussed by Lamb et al (2000) Thetool enables shipyards to be modeled such that the impacts ofchanges to the ship design may be determined on the basis of theresulting material manpower and schedule The shipyard modelrepresents details of the buildingsmdashtheir arrangement and size aswell as equipment capacity and flow The tool also enables aninvestigation of the necessary changes required for a shipyard inorder to produce a new design The key foundations in order toevaluate these impacts are the interim product catalogue and thebuild strategy approach

Lamb et al identified a number of important concepts for DFP

All designs should be prepared to suit a shipyardrsquos facili-ties and preferred production methods

DFP takes into account production methods and tech-niques that reduce the product work content but still meet thespecified design requirements and quality

DFP must be incorporated into a design from the start Traditional engineering leaves it up to another department

such as production or manufacturing engineering to developthe technical documentation required for the production work-ers This is an unnecessary duplication of effort and is a nonndashvalue-added task that takes time

An objective of the CE approach is to accommodate DFPby bringing all the necessary people together right from dayone on a project

The time to influence the cost of a product is during theearly stages After the design has been developed in conceptmost of the opportunity to positively affect cost is gone

World-class ship designers know how their shipyardbuilds ships and design accordingly Many ship designers donot consider this and the designs may or may not be efficientlybuilt in their facilities More shipbuilders have taken steps toremedy this situation through the use of the build strategyapproach

Engineering should be prepared and transmitted to theusers in a way that best suits block construction advanced andzone outfitting

An object-oriented approach was adopted for the constructionof the model (Fig 16) The model represents shipyards worksta-tions products equipment processes manufacturing processesmaterial handling processes and interim products The tool wasapplied to the evaluation of two design alternatives for the bottomstructure of a ship The authors demonstrated that the tool enabledreliable evaluations of the man-hours for manufacturing and ma-terial handling such that the best design alternative could beadopted

Future directions

It is believed that the ship STEP APs will become the standardunit of shipbuilding data but that it will probably be an evolution-ary process as advances in technology and modeling capabilitiesand requirements are incorporated It is however crucial that thedevelopment of the standards comes to a timely consensus at eachevolutionary stage The literature reviewed has discussed the useof ldquointelligentrdquo data the inclusion of useful functionality accord-ing to the data type and of behavioral aspects It is anticipated thatthis functionality behavioral aspects and so forth will increas-

Fig 15 Ship design workflow using three-dimensional product model (Baum amp Ramakrishnan 1997)

ingly become part of the model to the extent that the model nolonger has any need for interfaces and translators to legacy soft-ware For example the piping model would automatically calcu-late interferences and the structures model would automaticallycalculate stress characteristics The simulation would essentiallybe part of the model and the model would contain additionalinformation and knowledge to effectively manage the simulationThis is not to say that the model would become a monolithicsystem despite such a system being potentially computationallyviable in 10 years Rather than being monolithic current andfuture distributed information technologies such as EnterpriseJava Beans may be utilized in order to distribute the model acrossa network while giving the impression to the user that the systemis monolithic Ship product data and functionality would be dis-tributed either within a single company or as partnerships withother companies

In a similar way that the ship product data has become stan-dardized benefits are to be gained from standardizing the inter-faces between applications to support the flow of standardizeddata and achieve a truly seamless integration The unfortunateshortcoming of application standardization is the necessity to re-develop the legacy systems to support this level of integration

The VRShips project addresses the management of ship productdata within a neutrally formatted common model The geometry

data contained within the common model are based on STEPAP203 are described using XML and are considered as beingcommon data if two or more applications access it Integration isprovided between the legacy applications and the common modelvia ldquogeneric wrappersrdquo that provide the general management re-quired in order to operate the applications The wrappers convertthe data to and from the native format using modular conversionalgorithms that can be plugged into the wrappers and provide thedomain-specific management for the applications Data are auto-matically downloaded from the common model and converted intothe native format when the application is started When the appli-cation is complete the designer has the option of undertaking thereverse process to convert the data back into the neutral format andupload into the common model Despite being a complex processconverters have been produced for a number of design applica-tions such as Tribon and AVPro and have been demonstrated tooperate without the need for manual interaction However theissues relating to the lack of integration between tools and con-tinuous product models remain to be addressed

The VRShips system also has an additional management layerconsisting of a process controller and an inference engine that arejointly responsible for maintaining data consistency and versionconstraint and process management Visualizing of product datavia the legacy applications is managed through the exporting of

Fig 16 Object diagram for generic shipyard computer model (Lamb et al 2000)

the displays via a virtual interaction environment These controlmechanisms ensure that designers may modify the data containedwithin the common model from any location either organization-ally or geographically distributed with network access using anapplication that they are familiar with and that any changes madeto the product model are correctly propagated such that the dataremain consistent

Every product modeling tool and technique discussed withinthis review is common from the perspective that the data containedwithin the model are a ldquosnapshotrdquo of the actual design activity Forinstance a designer may download data from the ship productmodel for use within a general design package which may take aweek to design During this design period the data within theproduct model do not change until the designer decides that thedesign process is complete and the data are uploaded into theproduct model The product model therefore does not contain acontinuous representation of either the design work that is cur-rently being undertaken or the form that the data are in This posesa number of significant project management issues with respect toversion control consistency management and conflict resolutionespecially in the situation where the design process is being un-dertaken in a distributed manner as is increasingly becomingcommon

A paradigm shift in the techniques used to enable the distributeddesign of ships while enabling a continuous product model andfacilitating the management of conflicts and consistency would bethe adoption of a technology that is more often seen within thecomputer games industry Graphics servers are commonly usedwithin the games industry to enable the user to immerse them-selves within an environment and interact both with the environ-ment and with other users High-level graphical objects are com-municated between the server side and the client side rather thanusing structured files This technique bypasses the need to trans-late the communicated data into the client side format alleviatingunnecessary computation It also results in a model containedwithin the server and represented within the clients that is a con-tinuous depiction of what everyone is undertaking The ship prod-uct data would remain within the ship STEP formats Howeverthe description method would be the graphical object representa-tion that would also exhibit behavioral properties Within the ship-building context individual graphics servers would represent do-mains similar to those identified by Crawford et al (1999) Clientsconnecting to the servers would immediately get an up-to-dateview of that particular domain which would be consistent with theviews of all of the other clients The client software would operatein a manner similar to conventional design applications There isalso clearly a requirement for integration between the differentdomain servers to enable conflicts to be resolved across domainsSimulation servers would integrate all of the scenarios that wouldenable an evaluation of the performance within any particular lifephase There would still remain the need to provide an effectivemanagement of different versions as well as a high-level coordi-nation structure to manage conflicts constraints design goals andcollaboration among designers However the underlying frame-work would provide the basis on which to construct this Despitebeing a significant step-change compared with current practicethis future technique proposes a viable solution to the effectivemanagement of a ship product model that may be manipulated andoperated upon in a distributed manner

This type of architecture does however raise a number of

issues relating to partnerships between the shipbuilding industryand the shipbuilding software industry because the system wouldrepresent an amalgamation of existing design and simulation ap-plications into a number of domain-specific servers The intellec-tual property rights as well as the ownership of both the technol-ogy and the data contained would clearly need to be resolved Inaddition the system calls upon the need to implement a standardfor the communication of the graphical objects that is both secureand robust whereas the standard for the data may be ldquoflavoredrdquoand managed effectively within the system via the ability to dy-namically load classes

Just as many of the precommissioning life phases are currentlybeing modeled it is anticipated that the rather poorly supportedpostcommissioning life phases will be catered for The most sig-nificant difference between pre- and postcommissioning is that itwill be the ship product model in its entirety that will be consid-ered For example there currently appears to be a significantopportunity for the specialization of the immersion of an entireship product model into an artificial environment to determine theoperational performance both at virtual sea (modeling existingshipping lanes to determine sea-keeping characteristics) within avirtual port (modeling existing ports to determine cargo-handlingcharacteristics) within a virtual shipyard for recommissioning(modeling existing shipyards to determine recommissioning capa-bility) and within a virtual breakers yard for disposal (to deter-mine scrap value) Increased opportunity would therefore be madefor designing the ship to meet a more rigorous set of customer-specified life-phase requirements and would represent a signifi-cant commercial advantage

It is also interesting at this point to note that a number of thecited papers have stated the need to avoid a reliance on computerprogrammers which in order to maintain even the simplest ofproduct data modeling systems seems unachievable

Conclusions

From the increasing amount of literature and the papers re-viewed within this paper related to the ship product model theprimary focus is on developing a standard representation for thedata contained within the model Despite not having yet finalizedthe standards for all aspects of the ship the STEP APs go a longway toward achieving this It is almost inconceivable to considerthat an alternative could compete against such a massive thrusttoward ship data standardization A number of instances havearisen however when the APs have been adhered to with theresult that ldquoflavorsrdquo or minor changes to the standard have beenrequired in order to utilize the structured well-defined and stan-dardized data within the legacy applications The question there-fore arises as to whether there is a requirement to standardize thelegacy applications such that they adhere to the data standard toenable a modular plug-in approach to ship design and simulation

Behavioral aspects have been considered within a number of thecited papers to be an important addition to the data in order toprovide the designer with additional feedback with respect to theoperation of the design This behavior may however be betterrepresented as high-level rules within a standard that are used todefine the operation of the ship rather than in existing standardsin order to minimize its impact on applications that have no needfor such data

A number of the tools and techniques discussed have described

the use of the ship STEP formats as being a mechanism for inte-grating existing legacy applications with a common model of shipproduct data Considerable benefit would be obtained from pro-viding similar integration between applications to progress fromthe limitations of discrete design and simulation toward having aholistic approach

The design tasks that are undertaken as part of the ship designprocess may well take a considerable amount of time and wouldconventionally result in ldquosnapshotsrdquo of the design artifact coin-ciding with the designer uploading data into the common modelA number of future directions have been discussed which wouldindividually require considerable development in order to imple-ment but which represent possible solutions to issues relating to

Continuous rather than ldquosnapshotrdquo ship product models Integration between the ship product model and the design

and simulation applications as well as across applications Removal of information translation problems through the

use of high-level graphical objects that are consistent betweenservers and applications

A collaborative framework on which to develop versionconflict and consistency management

Acknowledgments

The review was undertaken as part of an investigation intocommon model techniques within the VRShips-ROPAX2000project The authors gratefully acknowledge the support given bythe European Commission Community Research 5th Frameworkprogram under the area of Competitive and Sustainable Growthwhich provided the grant (G3RD-CT-2001-00506) that enabledthis work to be undertaken

References

BAUM S J AND RAMAKRISHNAN R 1997 Applying 3D product modelingtechnology in shipbuilding Marine Technology 34 1 56ndash65

CATLEY D 1999 Prototype STEP data exchanges in ship initial design andprovision of an application programmer interface to TRIBON Proceedings10th International Conference on Computer Applications in ShipbuildingJune Cambridge MA

CRAWFORD A K HARRINGTON G AMES R M AND VAN ESELTINE RT 1999 Neutral format data exchanges between ship product models andanalysis interfaces Proceedings 10th International Conference on Com-puter Applications in Shipbuilding June Cambridge MA

ERIKSTAD S O AND FATHI D E 1999 Applying the STEP shipbuildingprotocols as a basis for integrating existing in-house ship design applica-tions Proceedings 10th International Conference on Computer Applica-tions in Shipbuilding June Cambridge MA

GISCHNER B KASSEL B LAZO P WOOD R AND WYMAN J 2001 Evolution of STEP (ESTEP) exchange of shipbuilding productmodel data JOURNAL OF SHIP PRODUCTION 17 3 151ndash160

GRAU M AND KOCH T 1999 Applying STEP technology to shipbuildingProceedings 10th International Conference on Computer Applications inShipbuilding June Cambridge MA

HERZOG E AND TOumlRNE A 1999 A seed for a STEP application protocolfor systems engineering Proceedings 12th International Conference andWorkshop on the Engineering of Computer Based Systems Institute ofElectrical and Electronics Engineers Press Piscataway NJ 174ndash180

HIGNEY J T AND OUILETTE J J 1994 An engineering product modelbased on STEP protocols JOURNAL OF SHIP PRODUCTION 10 4 281ndash286

ISO 1996 Product Data Representation and Exchange Part 218 Ship Struc-

tures International Standards Organization Hamburg GermanyJOHANSSON K 1995 The product model as a central information source in

a shipbuilding environment Proceedings National Shipbuilding ResearchProgram 1995 Ship Production Symposium June Seattle WA

LAMB T CHUNG H AND SHIN J G 2000 A generic shipyard computermodel a tool for design for production Proceedings 7th IMDC NovemberKyung-Ju Korea

MARTIN D J 1980 The shipyard product information system as an aid toimplementing more productive strategies Proceedings Research and Engi-neering for Automation and Productivity in Shipbuilding IIT Research In-stitute October Chicago IL 81ndash101

POLINI M A AND MELAND K E 1997 The development and implemen-tation of a SMART product model for ship structure Proceedings 9thInternational Conference on Computer Applications in Shipbuilding Octo-ber Yokohama Japan

RANDO T C AND FERNHOLZ D 2000 MARITECHrsquos shipbuilding infor-mation infrastructure JOURNAL OF SHIP PRODUCTION 16 2 110ndash120

RANDO T C 2001 XML-based interoperability in the integrated shipbuild-ing environment (ISE) JOURNAL OF SHIP PRODUCTION 17 2 69ndash75

ROSS J M AND GARCIA L 1998 Making the jump to product modeltechnology JOURNAL OF SHIP PRODUCTION 14 1 15ndash26

ROSS J M AND ABAL D 2001 Practical use of 3D product modeling inthe small shipyard JOURNAL OF SHIP PRODUCTION 17 1 27ndash34

SCHMIDT W R VANDER J R AND SHIELDS V R 1990 Modelling andtransfer of product model digital data for the DDG 51 class destroyer pro-gram Proceedings National Shipbuilding Research Program 1990 ShipProduction Symposium August Milwaukee WI

SHIN Y AND HAN S H 1998 Data enhancement for sharing of shipdesign models Computer-Aided Design 30 12 931ndash941

VON HAARTMAN J KUUTTI I AND SCHAUMAN C 1994 Improving designproductivity with a product model for initial ship design Proceedings 8thInternational Conference on Computer Applications in Shipbuilding Sep-tember Bremen Germany

WELSH M LYNCH J AND BRUN B 1992 A data model for integration ofthe precommissioning life-cycle stages of the shipbuildingproduct JOURNAL

OF SHIP PRODUCTION 8 4 220ndash234WHITFIELD R I COATE S G DUFFY A H B AND HILLS

W 2000 Coordination approaches and systemsmdashpart I a strategic per-spective Research in Engineering Design 12 73ndash89

WYMAN J WOOLEY D GISCHNER B AND HOWELL J 1997 Development of STEP ship model database and translators fordata exchange between shipyards JOURNAL OF SHIP PRODUCTION 13 2111ndash124

Internet addresses

European Marine STEP Association httpemsagermanlloydorg

ISO STEP ship team http wwwnsnetcomNIDDESCt23html

Japan Marine Standards Association http wwwjecalsjipdecorjp

Korea STEP Centre httpksteporkr

has indeed been reported within a number of publications How-ever there has never been any consideration of the database con-trol mechanisms required to prevent the database from becomingan information bottleneck despite the assumption that a benefitwould be more effective information management or the in-creased duration associated with searching a single (extremely)large database for the required piece of data despite the assump-tion that a benefit would be rapid information disseminationThere is also the suggestion that using such a representation ofproduct data will avoid the need to transcribe the data betweendifferent application systems eliminating the introduction of errorthrough human interaction However a number of papers havesince reported on the requirement of application interfaces totranslate the product data into a format suitable for the intendedapplication Indeed Rando (2001) reported that in some cases adegree of human interaction has been required to ensure that thisprocess runs smoothly Conversely Catley (1999) suggested thatthe minimization of human interaction within the data exchangeprocess has resulted in more consistent design Finally the authorsidentified the benefit associated with improving the interface be-tween the supplier and the client through the introduction of elec-tronic product definition databases

The NEUTRABAS system was composed of an application-independent EXPRESS model defining the shipbuilding producta data dictionary to manage requests to the database a mappingbetween the model and the dictionary in the form of an EXPRESSimport tool the data management component to enable the cre-ation communication modification and querying of productmodel data a number of application interfaces to enable the in-dividual applications to interact with the database a number ofdatabase interfaces to enable communication between specific da-tabase management systems and the NEUTRABAS database anda database generator that enables the mapping of data within aspecific database to the data within the NEUTRABAS database

Von Haartman et al (1994) described the ship product modelwithin the NAPA project and realized the potential of the productmodel as a basis for concurrent engineering (CE) The use ofcomputers within the shipbuilding industry was previously re-stricted to the computationally intensive applications such as thecalculation of hydrostatics and stability These applications havehad a great deal of development to produce tools that represent andmodel a particular characteristic of the design quite accuratelyThey have generally received a great deal of investment of timeand money (Crawford et al 1999) Von Haartman et al suggest thatthe modern ship design process should ideally consist of a singlesystem that augments all of the disparate design tools but that oneshould recognize that such a system is far from reality The alter-native was to provide a framework to interlink these design toolsto give the impression of a single system The ship product modelwas the key to interlinking these tools

Von Haartman et al also stated ldquoAny model merely reflectsselected properties of the object it is intended to describe and theappropriate selection of properties is of central importance whendesigning the modelrdquo Within the NAPA ship product modelglobal properties of the ship were identified such as the maindimensions hull form and so forth and although not explicitlystated it is assumed that these global properties were chosenpartly for the reason that they are common among the design toolsbeing utilized These properties within the model may also be usedto evaluate the economic and technical requirements of the ship

Finally Von Haartman et al stated that the lack of detail of theglobal properties within the ship product model is not synonymouswith inaccuracy

Johansson (1995) described the challenge of modern shipbuild-ing as ldquoto manage and control the design and assembly process togain efficiency and short delivery timesrdquo By summarizing theshipbuilding process life-cycle stages as tendering design pro-duction planning materials finance and follow-up the require-ment for the effective management of the extremely large amountsof information was established in order to ensure the efficientorganization of the shipbuilding process Johansson suggested thatthis requirement could be satisfied only through the developmentof ldquoan information flow solution specifically designed for thisindustryrdquo and suggested that it was not sufficient just to automateexisting manual activities Rather the organization should beadapted to the use of new tools to streamline the information flowwherever possible The discussion appeared however to be re-stricted to information flows within a single shipbuilding organi-zation with the main focus on how the information may be utilizedto improve the production process

The product model concept was regarded by Johansson as beingone such tool whereby the organization may be streamlinedthroughout the precommissioning stages by providing a consis-tent model to enable well thought-out build strategies to be de-veloped early ordering of materials and material handling pre-fabrication preoutfitting and the use of numerically controlledmachines

Additional information was contained within the productmodel such as material codes weights surface treatments and soforth For this reason Johansson suggested that a more appropriateterm may be product information model because the modelshould contain all technical product definition data and may beused to provide for example graphical representations of geom-etry as well as lists and reports of material requirements Addi-tionally Johansson stated that the generation of a graphical rep-resentation should be produced only when it is required and to theextent that is suitable in order to avoid unnecessary computationThe graphical representation is regarded as secondary informationof the (primary) information stored in the product model Theinformation flow may be streamlined by the manipulation of theprimary information rather than the secondary information

Johansson also recognized that it was important that ldquoa productmodel based system must understand what the different parts ofthe system really represent and be able to interpret the rules andrestrictions connected to each type of objectrdquo

Erikstad and Fathi (1999) described how a STEP-based shipproduct model could be used within the ShipX project for theintegration of the data within a number of hydrodynamic analysisapplications for a ship The applications were previously devel-oped as stand-alone applications to specific aspects of the hydro-dynamic performance of the ship such as propulsion and seakeeping Previous integration among the applications wasachieved through the development of translators to allow for theexchange of information However the technique was difficult toimplement and maintain and was not considered to be seamlessThe communication of information among applications is clearlya central issue that has been discussed in a number of reports(Wyman et al 1997 Gischner et al 2001) Essentially the optionsare either to develop a direct interface between every pair ofcomponents or develop the interfaces based on a consistent inter-

face standard A common product model (Fig 9) was imple-mented within ShipX and from the application developmentviewpoint it enabled

Developers to concentrate more on the specific simulationproblem rather than the modeling of the data This benefit isrealized every time a particular application goes through rede-velopment or when new applications are developed

Guaranteed synchronization of data between the applica-tions and the product model Translators were previously usedto convert the product data to and from the required formats foreach application Changes could potentially be made to theproduct model after data translation to the application resultingin a discrepancy in the translated data The product modeltechnique ensures that each application has a common repre-sentation of the ship

Reuse of previous applications and graphical user inter-faces eliminating the need for the end user to relearn how touse the application

Despite integrating existing applications with the productmodel it is not clear within the ShipX project whether integrationexisted between applications For example two discrete applica-tions may be considered as damage stability assessment andevacuation simulation both integrated via the product model It ispossible to make assessments of the performance of the ship withrespect to both the damage stability and the evacuation in isola-tion via the integration with the product model However inte-gration is required between the damage stability and evacuationapplications in order to assess the evacuation time while compart-ments are flooding

The ShipX product model was developed using the relevantshipbuilding protocols developed within STEP which were imple-mented into a class library and stored using an object-orienteddatabase

Erikstad gave a number of useful guidelines for the develop-ment of the ShipX system

Simplicity The development of a comprehensive productmodel tool was considered to be prohibitive both from theaspects of timeliness and cost effectiveness Wherever pos-sible commercial off-the-shelf components were used Thedevelopment of the actual product model was undertaken usingthe STEP shipbuilding protocols rather than developing anin-house product model from scratch

Flexibility and extensibility The model was initially lim-ited to representing data that were specific to hydrodynamicperformance However consideration was given to the struc-ture of the model such that it could be extended to representother performance aspects Also the use of STEP to producethe common product model enables the scope of ShipX to beextended without restructuring the model The facade designpattern was also used to hide the complexity of the productmodel from the client applications define the correct usage ofthe product model by the client applications and enable theupdating of the product model without affecting the client ap-plications

Weak bindings to platform and programming language toenable the cross-platform and cross-language integration of theproduct model

Baum and Ramakrishnan (1997) regarded three-dimensionalproduct model technology as being fundamental for the imple-mentation of concurrent engineering (CE) within shipbuilding dueto the ability to develop capture represent integrate and coor-dinate data and permit simultaneous access to a number of usersBaum defined the product model as ldquothe integration of the 3Dgeometric model and non-geometric database informationrdquo whichmay be a logical integration of distributed information (Fig 10)

Simulation and interaction with the objects within the productmodel through the introduction of anthropomorphic models into avirtual environment to test functionality and operability were dis-cussed as being a useful technique to test the validity of the modelin a way similar to what would be achieved with the final productThe resulting model is essentially an electronic ldquomock-uprdquo Baumsuggested therefore that it is important to also represent the nor-mal behavior of the objects within the ship product model suchthat their behavior may also be analyzed enabling the product tobe designed manipulated analyzed constructed tested operatedsupported and disposed of in a virtual environment

Ross and Garcia (1998) and Ross and Abal (2001) discussed theutilization of product modeling technologies within two differentshipyard applications new build and conversion with the focus ofaiding shipyard managers with the decision to adopt such tech-nologies Ross suggests that the key characteristic of the productmodel for achieving a high level of integration is the adoption ofa single database allowing a number of designers to simulta-neously work on the same design through effective database man-agement and reducing or preventing altogether the inconsistency

Fig 9 From data translators to data integration within the ShipX project (Erikstad amp Fathi 1999)

of information A number of small shipyards that have incorpo-rated product-modeling technologies are used as case studies todiscuss the techniquersquos effectiveness with the conclusions thatthese shipyards have an improved production quality and signifi-cant savings in material cost labor cost construction cost andlabor hours Despite being a more complex representation thantraditional techniques Ross and Abal (2001) concluded that stafftraining was straightforward and that staff were considered com-petent after the design of the first vessel

Polini and Meland (1997) discussed the extension of a prototypeproduct modeling system through to the development of a pro-duction implementation that was capable of supporting concur-rent multiuser access Life-cycle data and behavior were modeledwithin the classes contained in the Smart Product Modelling(SPM) system The differentiation between a standard productmodel and an SPM system is shown in Fig 11 To appreciate theamount of effort involved in developing the SPM Polini andMeland state ldquoTo date nearly 45 man-years of software devel-opment have been invested in the SPM and its GUI approxi-mately 1000 classes with over 30000 methods have been devel-oped object oriented databases on the order of 25 gigabytes arecommonplace 24 concurrent users have modeled five shipclasses and tens of thousands of structural parts have been manu-facturedrdquo

This development was undertaken entirely within a shipyardwithout any commercial input Polini and Meland justified thisdevelopment by surveying the requirements of the shipyard andconcluding that there were no commercially available systemscapable of dealing with the degrees of specialization within theshipbuilding industry a point that has also been made by Jo-hansson (1995)

One of the questions asked by Shin and Han (1998) and others(Baum amp Ramakrishnan 1997) is whether it is possible to imple-ment paperless design because designers often spend a great dealof time trying to extract useful information from two-dimensionalpaper drawings The shipbuilding building blocks within the STEPshipbuilding APs were used as the basis to produce a ship product

model Shin used the STEP toolkit ST-Developer to produce C++classes using the EXPRESS data definition language for the mid-ship section of a bulk carrier

The classes were enhanced to enable all life-cycle product in-formation to be stored within a single data structure as well as fortranslating data formats by one-to-one mapping and includingexplicit information (Youngrsquos modulus Poissonrsquos ratio) from de-sign conventions available within the product model The systemarchitecture can be seen in Fig 12 This enhancement was re-quired because Shin suggested that it was not sufficient to simplytranslate data from a neutral format into the format required byeach application Rather it is a requirement of each applicationthat associated functions and information specific to each appli-cation is also incorporated into the model

This requirement for functional data was also discussed byCrawford et al (1999) Rather than relying on a flat neutral file tocontain geometry and topology information it was considereduseful that the topological data for example were provided withsome sort of intelligence to facilitate the translation between ap-plications The STEP standards were adhered to wherever pos-sible However achieving intelligent topology required extensionof the standards Crawford defined the Newport News Shipbuild-ing view of a product model as ldquoan all encompassing model of a

Fig 11 Product model definitions (Polini amp Meland 1997)

Fig 10 Representation of a ship three-dimensional product model (Baum amp Ramakrishnan 1997)

ship project taking advantage of the available computer toolsfor describing the geometry of a ship but it also includes allattributes necessary for the design production and operation ofthe shiprdquo

Again it was considered unlikely that the ship could be definedby a single computer system rather than by a number of moremanageable systems grouped according to some arbitrarily de-fined domains (Fig 13)

Crawford demonstrated the use of intelligent topological andgeometric STEP-based data through the use of the GOBS commonobject request brokerage architecture (CORBA) server that pro-vides a number of methods to enable legacy tools to extract therequired data Two analysis tools were used to model the ship

vulnerability and hydrostatics which obtained their data from theGOBS server The analysis concluded that within the majority ofthe cases the STEP standard for geometric data (Part 42) wassufficient to represent the geometry for the ship

Rando and Fernholz (2000) describes how the DARPA Mar-itech Shipbuilding Information Infrastructure Project (SHIIP) andShipbuilding Partners and Suppliers (SPARS) projects used acombination of component-based software internet protocols anda portable computing platform to satisfy the following shipbuild-ing information technical requirements

An information technology gap separates the large me-dium and small shipyards

Fig 12 System architecture of the STEP manager (Reprinted from Shin amp Han 1998 with permission from Elsevier)

The information technology staffs at most shipyards areexperts in shipbuilding process requirements but not in system-level computer technologies

Shipyard information systems must be reliable and main-tainable yet often need to be customized to suit an individualshipyard

As with many other projects (Rando 2001 Gischner et al 2001)integration within the shipbuilding industry was considered pos-sible only by the reuse of existing software components becausethe number of shipbuilding system requirements is so diverse thatit is unrealistic to assume that it is possible to produce a singleoverarching solution The integrated system was considered toconsist of a number of independent components to be assembledand reused by third parties in order to create a new complexsystem The initial task of the SHIIP project was to define areference architecture to support the composition of the indepen-dent components

The management of the product data was achieved using En-terprise Java Beans (EJB) that enable persistent storage secureaccess and load balancing for multiple users wishing to access thedata simultaneously At the start of the SHIIP project however

EJB was not available and the project relied instead on CORBAtechnology The project learned the following lessons from usingCORBA

Technology independence although useful in theoryshould not be pursued at the expense of developing workingimplementations

Technical interoperability is not a requirement for the de-velopment of an industrial information infrastructure Support-ing applications and software components for the informationinfrastructure are homogeneous enough to be implemented in asingle implementation technology

The Object Management Group (OMG) while advocatingseparation of components has produced in the arena of do-main standards wrappers for monolithic applications

OMG has been hampered by the inability to reach timelyconsensus

The Integrated Shipbuilding Environment (ISE) project withinthe Maritech Advanced Shipbuilding Enterprise (ASE) is usingXML as the basis for achieving interoperability between ship-building systems technologies specifically between application toapplication (Rando 2001) Rando differentiates this problem fromthat of other industries by stating that many of the applicationcomponents used within the shipbuilding industry have alreadybeen developed as well as the having little control over the de-velopment of these systems The shipbuilding product model mayalso contain millions of instances of a large number of differenttypes of information that need to be managed as they evolve overthe productrsquos life cycle It is also suggested that not only is therea need to rely on an enterprise system that augments the manyspecialist applications but due to the diversity of informationwithin the life cycle of the ship no single information system issufficient to deal with the entire ship product Indeed previousalliances between shipyards have been one-off solutions and thereis a definite requirement for a standardized effort for the shipproduct model

Rando identified a number of business drivers in order toachieve interoperability within the shipbuilding industry and pro-

Fig 13 Domain-based ship system (Crawford et al 1999)

Fig 14 ISE reference architecture three levels of interoperability (Rando 2001)

posed an architecture in order to respond to these drivers (Fig 14)The architecture represents three interoperability levels within theshipbuilding environment intercomponent refers to the interac-tions between the software components within a system intersys-tem refers to the interactions between the systems and is boundedby a business system domain and interenterprise interoperabilityrefers to interactions between business systems domains at differ-ent shipyards and organizations

The key elements for achieving this interoperability were acommon syntax using XML to facilitate communication a sharedstandard information model using STEP and an interoperabilityinfrastructure using web-based technologies XML is a neutralformat that may be viewed by humans (although this is not gen-erally a primary requirement) and that enables the sharing of in-formation between different technologies different operating sys-tems and different programming languages Five keyrequirements were identif ied to facilitate application-to-application integration

Should ldquoreuserdquo widely available standards-based tools Should be implementable with tools that allow for recon-

figuration by nonprogrammers Should support transformation to and from a canonical or

neutral format Should utilize a representation that is as simple and con-

cise as possible Should be able to marshalunmarshal every semantic con-

cept representable in the EXPRESS information modeling lan-guage (ISO 10303-11)

One of the most significant issues relating to the use and inte-gration of ship product models with existing applications appearsto be the need to ldquoflavorrdquo the model and specifications to suit theparticular requirements of the design and simulation applicationsWithout these embellishments the fully automated data integra-tion appears quite often difficult to achieve There are howeverconflicting opinions regarding the effectiveness of automating thisprocess generally arising due to the complexity of the problem andthe level of support The application of ldquoflavoredrdquo standards doeshowever entirely go against the point of creating a standard es-pecially when it is with respect to the transfer of product data Itcould therefore be concluded that the solution to the effectiveintegration of STEP lies not in the modification of a new tech-nology to satisfy the requirements of legacy applications but inthe updating of the legacy applications to satisfy the new technol-ogy

Life-cycle issues

The NEUTRABAS project (Welsh et al 1992) was limited tothe precommissioning stages that is marketing conceptual de-sign detailed design drafting materials ordering productionplanning and control scheduling and quality control However itwas recognized that significant benefits would be achievedthrough extending the life cycle through to disposal Welsh et alqualified the limitation to the precommissioning stages by statingthat ldquothe definition and implementation of a complete product datamodel covering all of these aspects of the life-cycle of an engi-neering product as complex as a ship is an onerous task and one

which would require the commitment of a vast amount of time andeffortrdquo

Limiting the project to the precommissioning stages would ap-pear to have been a wise judgment because in the 10 years fol-lowing this project the standards created to describe the shipproduct model have still not yet been finalized

Welsh et al suggest that the physical representation of the prod-uct within each life cycle stage would ldquonormally be unchanged inthe global sense although the information associated with theproduct and the techniques used to represent it will vary consid-erablyrdquo that is the information contained within the productmodel would mature as more detail becomes available as well asrequiring different viewpoints at each life-cycle stage The productmodel must therefore be developed not only with the associateddata and structure in mind but also with the life-cycle stages Toenable the support of the precommissioning life-cycle stagesWelsh et al identified four views that need to be supported by theship product model

Marketing-oriented view Management-oriented view Design-oriented view Production-oriented view

Von Haartman et al (1994) briefly discussed life phase issues ofthe ship product model and suggested that a number of systemsmodel the design with too much detail and hence are not appli-cable to the concept design stage A solution to this was thedevelopment of a concept design product model that could then betransferred to the detailed design stage It is not clear from thiswhether Von Haartman et al were proposing separate models forthe two stages or if the detail product model would simply consistof the concept product model plus the additional required detail

The mechanism of having multiple different views for the shar-ing of a product model among designers and production engineersfor example has been considered and implemented in a number ofcases (Polini amp Meland 1997 Johansson 1995) Johansson indi-cated that it is common for parts of the product to be in differentlife-cycle stages at the same time that is the ldquomanufacture of onepart of the product is going on at the same time as the detaileddesign of anotherrdquo This is one aspect of concurrent engineeringwith the result of reducing the lead times because the manufactureof the product has started before the design of the product has beencompleted However it is necessary to ensure both that manufac-turing starts only on parts that require no further design and thatother parts that are currently being designed do not propagatechanges to the manufactured parts The management and controlof the information flow were recognized as being the key elementsin increasing the overlapping of life cycles However no expla-nation was given by Johansson regarding the nature of the man-agement other than through the relationships between the objectscontained within the model These relationships were described asa mechanism to enable both interdisciplinary and cross-disciplinary communication among designers

The three-dimensional product model was described by Baumand Ramakrishnan (1997) as being a mechanism to enable a num-ber of different life-cycle stage simulations such as interferencechecking crew traffic flow studies yard-specific designs and fi-nite capacity scheduling through the use of a virtual environmentdesign review technology using data contained within the productmodel (Fig 15)

Coupled with simulation-based design (SBD) Baum describedthe combined technology as ldquothe new frontierrdquo that would enablethe virtual prototyping of the ship which previously could not beachieved due to the cost and complexity More importantly Baumrecognized that just as interference-checking software may beused to determine discrepancies between geometric parts duringthe design and production phases SBD may be used to reduce oreliminate design errors that would have previously have beendiscovered years later in the operational stage for example Es-sentially SBD and product modeling enable the validation of thedesign production and operation stages of the ship product

Baum also finally suggested that the product model provides asignificant benefit to the owneroperator by enabling the analysisand support of life-cycle maintenance

A generic shipyard computer modeling tool for evaluating de-sign for production (DFP) is discussed by Lamb et al (2000) Thetool enables shipyards to be modeled such that the impacts ofchanges to the ship design may be determined on the basis of theresulting material manpower and schedule The shipyard modelrepresents details of the buildingsmdashtheir arrangement and size aswell as equipment capacity and flow The tool also enables aninvestigation of the necessary changes required for a shipyard inorder to produce a new design The key foundations in order toevaluate these impacts are the interim product catalogue and thebuild strategy approach

Lamb et al identified a number of important concepts for DFP

All designs should be prepared to suit a shipyardrsquos facili-ties and preferred production methods

DFP takes into account production methods and tech-niques that reduce the product work content but still meet thespecified design requirements and quality

DFP must be incorporated into a design from the start Traditional engineering leaves it up to another department

such as production or manufacturing engineering to developthe technical documentation required for the production work-ers This is an unnecessary duplication of effort and is a nonndashvalue-added task that takes time

An objective of the CE approach is to accommodate DFPby bringing all the necessary people together right from dayone on a project

The time to influence the cost of a product is during theearly stages After the design has been developed in conceptmost of the opportunity to positively affect cost is gone

World-class ship designers know how their shipyardbuilds ships and design accordingly Many ship designers donot consider this and the designs may or may not be efficientlybuilt in their facilities More shipbuilders have taken steps toremedy this situation through the use of the build strategyapproach

Engineering should be prepared and transmitted to theusers in a way that best suits block construction advanced andzone outfitting

An object-oriented approach was adopted for the constructionof the model (Fig 16) The model represents shipyards worksta-tions products equipment processes manufacturing processesmaterial handling processes and interim products The tool wasapplied to the evaluation of two design alternatives for the bottomstructure of a ship The authors demonstrated that the tool enabledreliable evaluations of the man-hours for manufacturing and ma-terial handling such that the best design alternative could beadopted

Future directions

It is believed that the ship STEP APs will become the standardunit of shipbuilding data but that it will probably be an evolution-ary process as advances in technology and modeling capabilitiesand requirements are incorporated It is however crucial that thedevelopment of the standards comes to a timely consensus at eachevolutionary stage The literature reviewed has discussed the useof ldquointelligentrdquo data the inclusion of useful functionality accord-ing to the data type and of behavioral aspects It is anticipated thatthis functionality behavioral aspects and so forth will increas-

Fig 15 Ship design workflow using three-dimensional product model (Baum amp Ramakrishnan 1997)

ingly become part of the model to the extent that the model nolonger has any need for interfaces and translators to legacy soft-ware For example the piping model would automatically calcu-late interferences and the structures model would automaticallycalculate stress characteristics The simulation would essentiallybe part of the model and the model would contain additionalinformation and knowledge to effectively manage the simulationThis is not to say that the model would become a monolithicsystem despite such a system being potentially computationallyviable in 10 years Rather than being monolithic current andfuture distributed information technologies such as EnterpriseJava Beans may be utilized in order to distribute the model acrossa network while giving the impression to the user that the systemis monolithic Ship product data and functionality would be dis-tributed either within a single company or as partnerships withother companies

In a similar way that the ship product data has become stan-dardized benefits are to be gained from standardizing the inter-faces between applications to support the flow of standardizeddata and achieve a truly seamless integration The unfortunateshortcoming of application standardization is the necessity to re-develop the legacy systems to support this level of integration

The VRShips project addresses the management of ship productdata within a neutrally formatted common model The geometry

data contained within the common model are based on STEPAP203 are described using XML and are considered as beingcommon data if two or more applications access it Integration isprovided between the legacy applications and the common modelvia ldquogeneric wrappersrdquo that provide the general management re-quired in order to operate the applications The wrappers convertthe data to and from the native format using modular conversionalgorithms that can be plugged into the wrappers and provide thedomain-specific management for the applications Data are auto-matically downloaded from the common model and converted intothe native format when the application is started When the appli-cation is complete the designer has the option of undertaking thereverse process to convert the data back into the neutral format andupload into the common model Despite being a complex processconverters have been produced for a number of design applica-tions such as Tribon and AVPro and have been demonstrated tooperate without the need for manual interaction However theissues relating to the lack of integration between tools and con-tinuous product models remain to be addressed

The VRShips system also has an additional management layerconsisting of a process controller and an inference engine that arejointly responsible for maintaining data consistency and versionconstraint and process management Visualizing of product datavia the legacy applications is managed through the exporting of

Fig 16 Object diagram for generic shipyard computer model (Lamb et al 2000)

the displays via a virtual interaction environment These controlmechanisms ensure that designers may modify the data containedwithin the common model from any location either organization-ally or geographically distributed with network access using anapplication that they are familiar with and that any changes madeto the product model are correctly propagated such that the dataremain consistent

Every product modeling tool and technique discussed withinthis review is common from the perspective that the data containedwithin the model are a ldquosnapshotrdquo of the actual design activity Forinstance a designer may download data from the ship productmodel for use within a general design package which may take aweek to design During this design period the data within theproduct model do not change until the designer decides that thedesign process is complete and the data are uploaded into theproduct model The product model therefore does not contain acontinuous representation of either the design work that is cur-rently being undertaken or the form that the data are in This posesa number of significant project management issues with respect toversion control consistency management and conflict resolutionespecially in the situation where the design process is being un-dertaken in a distributed manner as is increasingly becomingcommon

A paradigm shift in the techniques used to enable the distributeddesign of ships while enabling a continuous product model andfacilitating the management of conflicts and consistency would bethe adoption of a technology that is more often seen within thecomputer games industry Graphics servers are commonly usedwithin the games industry to enable the user to immerse them-selves within an environment and interact both with the environ-ment and with other users High-level graphical objects are com-municated between the server side and the client side rather thanusing structured files This technique bypasses the need to trans-late the communicated data into the client side format alleviatingunnecessary computation It also results in a model containedwithin the server and represented within the clients that is a con-tinuous depiction of what everyone is undertaking The ship prod-uct data would remain within the ship STEP formats Howeverthe description method would be the graphical object representa-tion that would also exhibit behavioral properties Within the ship-building context individual graphics servers would represent do-mains similar to those identified by Crawford et al (1999) Clientsconnecting to the servers would immediately get an up-to-dateview of that particular domain which would be consistent with theviews of all of the other clients The client software would operatein a manner similar to conventional design applications There isalso clearly a requirement for integration between the differentdomain servers to enable conflicts to be resolved across domainsSimulation servers would integrate all of the scenarios that wouldenable an evaluation of the performance within any particular lifephase There would still remain the need to provide an effectivemanagement of different versions as well as a high-level coordi-nation structure to manage conflicts constraints design goals andcollaboration among designers However the underlying frame-work would provide the basis on which to construct this Despitebeing a significant step-change compared with current practicethis future technique proposes a viable solution to the effectivemanagement of a ship product model that may be manipulated andoperated upon in a distributed manner

This type of architecture does however raise a number of

issues relating to partnerships between the shipbuilding industryand the shipbuilding software industry because the system wouldrepresent an amalgamation of existing design and simulation ap-plications into a number of domain-specific servers The intellec-tual property rights as well as the ownership of both the technol-ogy and the data contained would clearly need to be resolved Inaddition the system calls upon the need to implement a standardfor the communication of the graphical objects that is both secureand robust whereas the standard for the data may be ldquoflavoredrdquoand managed effectively within the system via the ability to dy-namically load classes

Just as many of the precommissioning life phases are currentlybeing modeled it is anticipated that the rather poorly supportedpostcommissioning life phases will be catered for The most sig-nificant difference between pre- and postcommissioning is that itwill be the ship product model in its entirety that will be consid-ered For example there currently appears to be a significantopportunity for the specialization of the immersion of an entireship product model into an artificial environment to determine theoperational performance both at virtual sea (modeling existingshipping lanes to determine sea-keeping characteristics) within avirtual port (modeling existing ports to determine cargo-handlingcharacteristics) within a virtual shipyard for recommissioning(modeling existing shipyards to determine recommissioning capa-bility) and within a virtual breakers yard for disposal (to deter-mine scrap value) Increased opportunity would therefore be madefor designing the ship to meet a more rigorous set of customer-specified life-phase requirements and would represent a signifi-cant commercial advantage

It is also interesting at this point to note that a number of thecited papers have stated the need to avoid a reliance on computerprogrammers which in order to maintain even the simplest ofproduct data modeling systems seems unachievable

Conclusions

From the increasing amount of literature and the papers re-viewed within this paper related to the ship product model theprimary focus is on developing a standard representation for thedata contained within the model Despite not having yet finalizedthe standards for all aspects of the ship the STEP APs go a longway toward achieving this It is almost inconceivable to considerthat an alternative could compete against such a massive thrusttoward ship data standardization A number of instances havearisen however when the APs have been adhered to with theresult that ldquoflavorsrdquo or minor changes to the standard have beenrequired in order to utilize the structured well-defined and stan-dardized data within the legacy applications The question there-fore arises as to whether there is a requirement to standardize thelegacy applications such that they adhere to the data standard toenable a modular plug-in approach to ship design and simulation

Behavioral aspects have been considered within a number of thecited papers to be an important addition to the data in order toprovide the designer with additional feedback with respect to theoperation of the design This behavior may however be betterrepresented as high-level rules within a standard that are used todefine the operation of the ship rather than in existing standardsin order to minimize its impact on applications that have no needfor such data

A number of the tools and techniques discussed have described

the use of the ship STEP formats as being a mechanism for inte-grating existing legacy applications with a common model of shipproduct data Considerable benefit would be obtained from pro-viding similar integration between applications to progress fromthe limitations of discrete design and simulation toward having aholistic approach

The design tasks that are undertaken as part of the ship designprocess may well take a considerable amount of time and wouldconventionally result in ldquosnapshotsrdquo of the design artifact coin-ciding with the designer uploading data into the common modelA number of future directions have been discussed which wouldindividually require considerable development in order to imple-ment but which represent possible solutions to issues relating to

Continuous rather than ldquosnapshotrdquo ship product models Integration between the ship product model and the design

and simulation applications as well as across applications Removal of information translation problems through the

use of high-level graphical objects that are consistent betweenservers and applications

A collaborative framework on which to develop versionconflict and consistency management

Acknowledgments

The review was undertaken as part of an investigation intocommon model techniques within the VRShips-ROPAX2000project The authors gratefully acknowledge the support given bythe European Commission Community Research 5th Frameworkprogram under the area of Competitive and Sustainable Growthwhich provided the grant (G3RD-CT-2001-00506) that enabledthis work to be undertaken

References

BAUM S J AND RAMAKRISHNAN R 1997 Applying 3D product modelingtechnology in shipbuilding Marine Technology 34 1 56ndash65

CATLEY D 1999 Prototype STEP data exchanges in ship initial design andprovision of an application programmer interface to TRIBON Proceedings10th International Conference on Computer Applications in ShipbuildingJune Cambridge MA

CRAWFORD A K HARRINGTON G AMES R M AND VAN ESELTINE RT 1999 Neutral format data exchanges between ship product models andanalysis interfaces Proceedings 10th International Conference on Com-puter Applications in Shipbuilding June Cambridge MA

ERIKSTAD S O AND FATHI D E 1999 Applying the STEP shipbuildingprotocols as a basis for integrating existing in-house ship design applica-tions Proceedings 10th International Conference on Computer Applica-tions in Shipbuilding June Cambridge MA

GISCHNER B KASSEL B LAZO P WOOD R AND WYMAN J 2001 Evolution of STEP (ESTEP) exchange of shipbuilding productmodel data JOURNAL OF SHIP PRODUCTION 17 3 151ndash160

GRAU M AND KOCH T 1999 Applying STEP technology to shipbuildingProceedings 10th International Conference on Computer Applications inShipbuilding June Cambridge MA

HERZOG E AND TOumlRNE A 1999 A seed for a STEP application protocolfor systems engineering Proceedings 12th International Conference andWorkshop on the Engineering of Computer Based Systems Institute ofElectrical and Electronics Engineers Press Piscataway NJ 174ndash180

HIGNEY J T AND OUILETTE J J 1994 An engineering product modelbased on STEP protocols JOURNAL OF SHIP PRODUCTION 10 4 281ndash286

ISO 1996 Product Data Representation and Exchange Part 218 Ship Struc-

tures International Standards Organization Hamburg GermanyJOHANSSON K 1995 The product model as a central information source in

a shipbuilding environment Proceedings National Shipbuilding ResearchProgram 1995 Ship Production Symposium June Seattle WA

LAMB T CHUNG H AND SHIN J G 2000 A generic shipyard computermodel a tool for design for production Proceedings 7th IMDC NovemberKyung-Ju Korea

MARTIN D J 1980 The shipyard product information system as an aid toimplementing more productive strategies Proceedings Research and Engi-neering for Automation and Productivity in Shipbuilding IIT Research In-stitute October Chicago IL 81ndash101

POLINI M A AND MELAND K E 1997 The development and implemen-tation of a SMART product model for ship structure Proceedings 9thInternational Conference on Computer Applications in Shipbuilding Octo-ber Yokohama Japan

RANDO T C AND FERNHOLZ D 2000 MARITECHrsquos shipbuilding infor-mation infrastructure JOURNAL OF SHIP PRODUCTION 16 2 110ndash120

RANDO T C 2001 XML-based interoperability in the integrated shipbuild-ing environment (ISE) JOURNAL OF SHIP PRODUCTION 17 2 69ndash75

ROSS J M AND GARCIA L 1998 Making the jump to product modeltechnology JOURNAL OF SHIP PRODUCTION 14 1 15ndash26

ROSS J M AND ABAL D 2001 Practical use of 3D product modeling inthe small shipyard JOURNAL OF SHIP PRODUCTION 17 1 27ndash34

SCHMIDT W R VANDER J R AND SHIELDS V R 1990 Modelling andtransfer of product model digital data for the DDG 51 class destroyer pro-gram Proceedings National Shipbuilding Research Program 1990 ShipProduction Symposium August Milwaukee WI

SHIN Y AND HAN S H 1998 Data enhancement for sharing of shipdesign models Computer-Aided Design 30 12 931ndash941

VON HAARTMAN J KUUTTI I AND SCHAUMAN C 1994 Improving designproductivity with a product model for initial ship design Proceedings 8thInternational Conference on Computer Applications in Shipbuilding Sep-tember Bremen Germany

WELSH M LYNCH J AND BRUN B 1992 A data model for integration ofthe precommissioning life-cycle stages of the shipbuildingproduct JOURNAL

OF SHIP PRODUCTION 8 4 220ndash234WHITFIELD R I COATE S G DUFFY A H B AND HILLS

W 2000 Coordination approaches and systemsmdashpart I a strategic per-spective Research in Engineering Design 12 73ndash89

WYMAN J WOOLEY D GISCHNER B AND HOWELL J 1997 Development of STEP ship model database and translators fordata exchange between shipyards JOURNAL OF SHIP PRODUCTION 13 2111ndash124

Internet addresses

European Marine STEP Association httpemsagermanlloydorg

ISO STEP ship team http wwwnsnetcomNIDDESCt23html

Japan Marine Standards Association http wwwjecalsjipdecorjp

Korea STEP Centre httpksteporkr

face standard A common product model (Fig 9) was imple-mented within ShipX and from the application developmentviewpoint it enabled

Developers to concentrate more on the specific simulationproblem rather than the modeling of the data This benefit isrealized every time a particular application goes through rede-velopment or when new applications are developed

Guaranteed synchronization of data between the applica-tions and the product model Translators were previously usedto convert the product data to and from the required formats foreach application Changes could potentially be made to theproduct model after data translation to the application resultingin a discrepancy in the translated data The product modeltechnique ensures that each application has a common repre-sentation of the ship

Reuse of previous applications and graphical user inter-faces eliminating the need for the end user to relearn how touse the application

Despite integrating existing applications with the productmodel it is not clear within the ShipX project whether integrationexisted between applications For example two discrete applica-tions may be considered as damage stability assessment andevacuation simulation both integrated via the product model It ispossible to make assessments of the performance of the ship withrespect to both the damage stability and the evacuation in isola-tion via the integration with the product model However inte-gration is required between the damage stability and evacuationapplications in order to assess the evacuation time while compart-ments are flooding

The ShipX product model was developed using the relevantshipbuilding protocols developed within STEP which were imple-mented into a class library and stored using an object-orienteddatabase

Erikstad gave a number of useful guidelines for the develop-ment of the ShipX system

Simplicity The development of a comprehensive productmodel tool was considered to be prohibitive both from theaspects of timeliness and cost effectiveness Wherever pos-sible commercial off-the-shelf components were used Thedevelopment of the actual product model was undertaken usingthe STEP shipbuilding protocols rather than developing anin-house product model from scratch

Flexibility and extensibility The model was initially lim-ited to representing data that were specific to hydrodynamicperformance However consideration was given to the struc-ture of the model such that it could be extended to representother performance aspects Also the use of STEP to producethe common product model enables the scope of ShipX to beextended without restructuring the model The facade designpattern was also used to hide the complexity of the productmodel from the client applications define the correct usage ofthe product model by the client applications and enable theupdating of the product model without affecting the client ap-plications

Weak bindings to platform and programming language toenable the cross-platform and cross-language integration of theproduct model

Baum and Ramakrishnan (1997) regarded three-dimensionalproduct model technology as being fundamental for the imple-mentation of concurrent engineering (CE) within shipbuilding dueto the ability to develop capture represent integrate and coor-dinate data and permit simultaneous access to a number of usersBaum defined the product model as ldquothe integration of the 3Dgeometric model and non-geometric database informationrdquo whichmay be a logical integration of distributed information (Fig 10)

Simulation and interaction with the objects within the productmodel through the introduction of anthropomorphic models into avirtual environment to test functionality and operability were dis-cussed as being a useful technique to test the validity of the modelin a way similar to what would be achieved with the final productThe resulting model is essentially an electronic ldquomock-uprdquo Baumsuggested therefore that it is important to also represent the nor-mal behavior of the objects within the ship product model suchthat their behavior may also be analyzed enabling the product tobe designed manipulated analyzed constructed tested operatedsupported and disposed of in a virtual environment

Ross and Garcia (1998) and Ross and Abal (2001) discussed theutilization of product modeling technologies within two differentshipyard applications new build and conversion with the focus ofaiding shipyard managers with the decision to adopt such tech-nologies Ross suggests that the key characteristic of the productmodel for achieving a high level of integration is the adoption ofa single database allowing a number of designers to simulta-neously work on the same design through effective database man-agement and reducing or preventing altogether the inconsistency

Fig 9 From data translators to data integration within the ShipX project (Erikstad amp Fathi 1999)

of information A number of small shipyards that have incorpo-rated product-modeling technologies are used as case studies todiscuss the techniquersquos effectiveness with the conclusions thatthese shipyards have an improved production quality and signifi-cant savings in material cost labor cost construction cost andlabor hours Despite being a more complex representation thantraditional techniques Ross and Abal (2001) concluded that stafftraining was straightforward and that staff were considered com-petent after the design of the first vessel

Polini and Meland (1997) discussed the extension of a prototypeproduct modeling system through to the development of a pro-duction implementation that was capable of supporting concur-rent multiuser access Life-cycle data and behavior were modeledwithin the classes contained in the Smart Product Modelling(SPM) system The differentiation between a standard productmodel and an SPM system is shown in Fig 11 To appreciate theamount of effort involved in developing the SPM Polini andMeland state ldquoTo date nearly 45 man-years of software devel-opment have been invested in the SPM and its GUI approxi-mately 1000 classes with over 30000 methods have been devel-oped object oriented databases on the order of 25 gigabytes arecommonplace 24 concurrent users have modeled five shipclasses and tens of thousands of structural parts have been manu-facturedrdquo

This development was undertaken entirely within a shipyardwithout any commercial input Polini and Meland justified thisdevelopment by surveying the requirements of the shipyard andconcluding that there were no commercially available systemscapable of dealing with the degrees of specialization within theshipbuilding industry a point that has also been made by Jo-hansson (1995)

One of the questions asked by Shin and Han (1998) and others(Baum amp Ramakrishnan 1997) is whether it is possible to imple-ment paperless design because designers often spend a great dealof time trying to extract useful information from two-dimensionalpaper drawings The shipbuilding building blocks within the STEPshipbuilding APs were used as the basis to produce a ship product

model Shin used the STEP toolkit ST-Developer to produce C++classes using the EXPRESS data definition language for the mid-ship section of a bulk carrier

The classes were enhanced to enable all life-cycle product in-formation to be stored within a single data structure as well as fortranslating data formats by one-to-one mapping and includingexplicit information (Youngrsquos modulus Poissonrsquos ratio) from de-sign conventions available within the product model The systemarchitecture can be seen in Fig 12 This enhancement was re-quired because Shin suggested that it was not sufficient to simplytranslate data from a neutral format into the format required byeach application Rather it is a requirement of each applicationthat associated functions and information specific to each appli-cation is also incorporated into the model

This requirement for functional data was also discussed byCrawford et al (1999) Rather than relying on a flat neutral file tocontain geometry and topology information it was considereduseful that the topological data for example were provided withsome sort of intelligence to facilitate the translation between ap-plications The STEP standards were adhered to wherever pos-sible However achieving intelligent topology required extensionof the standards Crawford defined the Newport News Shipbuild-ing view of a product model as ldquoan all encompassing model of a

Fig 11 Product model definitions (Polini amp Meland 1997)

Fig 10 Representation of a ship three-dimensional product model (Baum amp Ramakrishnan 1997)

ship project taking advantage of the available computer toolsfor describing the geometry of a ship but it also includes allattributes necessary for the design production and operation ofthe shiprdquo

Again it was considered unlikely that the ship could be definedby a single computer system rather than by a number of moremanageable systems grouped according to some arbitrarily de-fined domains (Fig 13)

Crawford demonstrated the use of intelligent topological andgeometric STEP-based data through the use of the GOBS commonobject request brokerage architecture (CORBA) server that pro-vides a number of methods to enable legacy tools to extract therequired data Two analysis tools were used to model the ship

vulnerability and hydrostatics which obtained their data from theGOBS server The analysis concluded that within the majority ofthe cases the STEP standard for geometric data (Part 42) wassufficient to represent the geometry for the ship

Rando and Fernholz (2000) describes how the DARPA Mar-itech Shipbuilding Information Infrastructure Project (SHIIP) andShipbuilding Partners and Suppliers (SPARS) projects used acombination of component-based software internet protocols anda portable computing platform to satisfy the following shipbuild-ing information technical requirements

An information technology gap separates the large me-dium and small shipyards

Fig 12 System architecture of the STEP manager (Reprinted from Shin amp Han 1998 with permission from Elsevier)

The information technology staffs at most shipyards areexperts in shipbuilding process requirements but not in system-level computer technologies

Shipyard information systems must be reliable and main-tainable yet often need to be customized to suit an individualshipyard

As with many other projects (Rando 2001 Gischner et al 2001)integration within the shipbuilding industry was considered pos-sible only by the reuse of existing software components becausethe number of shipbuilding system requirements is so diverse thatit is unrealistic to assume that it is possible to produce a singleoverarching solution The integrated system was considered toconsist of a number of independent components to be assembledand reused by third parties in order to create a new complexsystem The initial task of the SHIIP project was to define areference architecture to support the composition of the indepen-dent components

The management of the product data was achieved using En-terprise Java Beans (EJB) that enable persistent storage secureaccess and load balancing for multiple users wishing to access thedata simultaneously At the start of the SHIIP project however

EJB was not available and the project relied instead on CORBAtechnology The project learned the following lessons from usingCORBA

Technology independence although useful in theoryshould not be pursued at the expense of developing workingimplementations

Technical interoperability is not a requirement for the de-velopment of an industrial information infrastructure Support-ing applications and software components for the informationinfrastructure are homogeneous enough to be implemented in asingle implementation technology

The Object Management Group (OMG) while advocatingseparation of components has produced in the arena of do-main standards wrappers for monolithic applications

OMG has been hampered by the inability to reach timelyconsensus

The Integrated Shipbuilding Environment (ISE) project withinthe Maritech Advanced Shipbuilding Enterprise (ASE) is usingXML as the basis for achieving interoperability between ship-building systems technologies specifically between application toapplication (Rando 2001) Rando differentiates this problem fromthat of other industries by stating that many of the applicationcomponents used within the shipbuilding industry have alreadybeen developed as well as the having little control over the de-velopment of these systems The shipbuilding product model mayalso contain millions of instances of a large number of differenttypes of information that need to be managed as they evolve overthe productrsquos life cycle It is also suggested that not only is therea need to rely on an enterprise system that augments the manyspecialist applications but due to the diversity of informationwithin the life cycle of the ship no single information system issufficient to deal with the entire ship product Indeed previousalliances between shipyards have been one-off solutions and thereis a definite requirement for a standardized effort for the shipproduct model

Rando identified a number of business drivers in order toachieve interoperability within the shipbuilding industry and pro-

Fig 13 Domain-based ship system (Crawford et al 1999)

Fig 14 ISE reference architecture three levels of interoperability (Rando 2001)

posed an architecture in order to respond to these drivers (Fig 14)The architecture represents three interoperability levels within theshipbuilding environment intercomponent refers to the interac-tions between the software components within a system intersys-tem refers to the interactions between the systems and is boundedby a business system domain and interenterprise interoperabilityrefers to interactions between business systems domains at differ-ent shipyards and organizations

The key elements for achieving this interoperability were acommon syntax using XML to facilitate communication a sharedstandard information model using STEP and an interoperabilityinfrastructure using web-based technologies XML is a neutralformat that may be viewed by humans (although this is not gen-erally a primary requirement) and that enables the sharing of in-formation between different technologies different operating sys-tems and different programming languages Five keyrequirements were identif ied to facilitate application-to-application integration

Should ldquoreuserdquo widely available standards-based tools Should be implementable with tools that allow for recon-

figuration by nonprogrammers Should support transformation to and from a canonical or

neutral format Should utilize a representation that is as simple and con-

cise as possible Should be able to marshalunmarshal every semantic con-

cept representable in the EXPRESS information modeling lan-guage (ISO 10303-11)

One of the most significant issues relating to the use and inte-gration of ship product models with existing applications appearsto be the need to ldquoflavorrdquo the model and specifications to suit theparticular requirements of the design and simulation applicationsWithout these embellishments the fully automated data integra-tion appears quite often difficult to achieve There are howeverconflicting opinions regarding the effectiveness of automating thisprocess generally arising due to the complexity of the problem andthe level of support The application of ldquoflavoredrdquo standards doeshowever entirely go against the point of creating a standard es-pecially when it is with respect to the transfer of product data Itcould therefore be concluded that the solution to the effectiveintegration of STEP lies not in the modification of a new tech-nology to satisfy the requirements of legacy applications but inthe updating of the legacy applications to satisfy the new technol-ogy

Life-cycle issues

The NEUTRABAS project (Welsh et al 1992) was limited tothe precommissioning stages that is marketing conceptual de-sign detailed design drafting materials ordering productionplanning and control scheduling and quality control However itwas recognized that significant benefits would be achievedthrough extending the life cycle through to disposal Welsh et alqualified the limitation to the precommissioning stages by statingthat ldquothe definition and implementation of a complete product datamodel covering all of these aspects of the life-cycle of an engi-neering product as complex as a ship is an onerous task and one

which would require the commitment of a vast amount of time andeffortrdquo

Limiting the project to the precommissioning stages would ap-pear to have been a wise judgment because in the 10 years fol-lowing this project the standards created to describe the shipproduct model have still not yet been finalized

Welsh et al suggest that the physical representation of the prod-uct within each life cycle stage would ldquonormally be unchanged inthe global sense although the information associated with theproduct and the techniques used to represent it will vary consid-erablyrdquo that is the information contained within the productmodel would mature as more detail becomes available as well asrequiring different viewpoints at each life-cycle stage The productmodel must therefore be developed not only with the associateddata and structure in mind but also with the life-cycle stages Toenable the support of the precommissioning life-cycle stagesWelsh et al identified four views that need to be supported by theship product model

Marketing-oriented view Management-oriented view Design-oriented view Production-oriented view

Von Haartman et al (1994) briefly discussed life phase issues ofthe ship product model and suggested that a number of systemsmodel the design with too much detail and hence are not appli-cable to the concept design stage A solution to this was thedevelopment of a concept design product model that could then betransferred to the detailed design stage It is not clear from thiswhether Von Haartman et al were proposing separate models forthe two stages or if the detail product model would simply consistof the concept product model plus the additional required detail

The mechanism of having multiple different views for the shar-ing of a product model among designers and production engineersfor example has been considered and implemented in a number ofcases (Polini amp Meland 1997 Johansson 1995) Johansson indi-cated that it is common for parts of the product to be in differentlife-cycle stages at the same time that is the ldquomanufacture of onepart of the product is going on at the same time as the detaileddesign of anotherrdquo This is one aspect of concurrent engineeringwith the result of reducing the lead times because the manufactureof the product has started before the design of the product has beencompleted However it is necessary to ensure both that manufac-turing starts only on parts that require no further design and thatother parts that are currently being designed do not propagatechanges to the manufactured parts The management and controlof the information flow were recognized as being the key elementsin increasing the overlapping of life cycles However no expla-nation was given by Johansson regarding the nature of the man-agement other than through the relationships between the objectscontained within the model These relationships were described asa mechanism to enable both interdisciplinary and cross-disciplinary communication among designers

The three-dimensional product model was described by Baumand Ramakrishnan (1997) as being a mechanism to enable a num-ber of different life-cycle stage simulations such as interferencechecking crew traffic flow studies yard-specific designs and fi-nite capacity scheduling through the use of a virtual environmentdesign review technology using data contained within the productmodel (Fig 15)

Coupled with simulation-based design (SBD) Baum describedthe combined technology as ldquothe new frontierrdquo that would enablethe virtual prototyping of the ship which previously could not beachieved due to the cost and complexity More importantly Baumrecognized that just as interference-checking software may beused to determine discrepancies between geometric parts duringthe design and production phases SBD may be used to reduce oreliminate design errors that would have previously have beendiscovered years later in the operational stage for example Es-sentially SBD and product modeling enable the validation of thedesign production and operation stages of the ship product

Baum also finally suggested that the product model provides asignificant benefit to the owneroperator by enabling the analysisand support of life-cycle maintenance

A generic shipyard computer modeling tool for evaluating de-sign for production (DFP) is discussed by Lamb et al (2000) Thetool enables shipyards to be modeled such that the impacts ofchanges to the ship design may be determined on the basis of theresulting material manpower and schedule The shipyard modelrepresents details of the buildingsmdashtheir arrangement and size aswell as equipment capacity and flow The tool also enables aninvestigation of the necessary changes required for a shipyard inorder to produce a new design The key foundations in order toevaluate these impacts are the interim product catalogue and thebuild strategy approach

Lamb et al identified a number of important concepts for DFP

All designs should be prepared to suit a shipyardrsquos facili-ties and preferred production methods

DFP takes into account production methods and tech-niques that reduce the product work content but still meet thespecified design requirements and quality

DFP must be incorporated into a design from the start Traditional engineering leaves it up to another department

such as production or manufacturing engineering to developthe technical documentation required for the production work-ers This is an unnecessary duplication of effort and is a nonndashvalue-added task that takes time

An objective of the CE approach is to accommodate DFPby bringing all the necessary people together right from dayone on a project

The time to influence the cost of a product is during theearly stages After the design has been developed in conceptmost of the opportunity to positively affect cost is gone

World-class ship designers know how their shipyardbuilds ships and design accordingly Many ship designers donot consider this and the designs may or may not be efficientlybuilt in their facilities More shipbuilders have taken steps toremedy this situation through the use of the build strategyapproach

Engineering should be prepared and transmitted to theusers in a way that best suits block construction advanced andzone outfitting

An object-oriented approach was adopted for the constructionof the model (Fig 16) The model represents shipyards worksta-tions products equipment processes manufacturing processesmaterial handling processes and interim products The tool wasapplied to the evaluation of two design alternatives for the bottomstructure of a ship The authors demonstrated that the tool enabledreliable evaluations of the man-hours for manufacturing and ma-terial handling such that the best design alternative could beadopted

Future directions

It is believed that the ship STEP APs will become the standardunit of shipbuilding data but that it will probably be an evolution-ary process as advances in technology and modeling capabilitiesand requirements are incorporated It is however crucial that thedevelopment of the standards comes to a timely consensus at eachevolutionary stage The literature reviewed has discussed the useof ldquointelligentrdquo data the inclusion of useful functionality accord-ing to the data type and of behavioral aspects It is anticipated thatthis functionality behavioral aspects and so forth will increas-

Fig 15 Ship design workflow using three-dimensional product model (Baum amp Ramakrishnan 1997)

ingly become part of the model to the extent that the model nolonger has any need for interfaces and translators to legacy soft-ware For example the piping model would automatically calcu-late interferences and the structures model would automaticallycalculate stress characteristics The simulation would essentiallybe part of the model and the model would contain additionalinformation and knowledge to effectively manage the simulationThis is not to say that the model would become a monolithicsystem despite such a system being potentially computationallyviable in 10 years Rather than being monolithic current andfuture distributed information technologies such as EnterpriseJava Beans may be utilized in order to distribute the model acrossa network while giving the impression to the user that the systemis monolithic Ship product data and functionality would be dis-tributed either within a single company or as partnerships withother companies

In a similar way that the ship product data has become stan-dardized benefits are to be gained from standardizing the inter-faces between applications to support the flow of standardizeddata and achieve a truly seamless integration The unfortunateshortcoming of application standardization is the necessity to re-develop the legacy systems to support this level of integration

The VRShips project addresses the management of ship productdata within a neutrally formatted common model The geometry

data contained within the common model are based on STEPAP203 are described using XML and are considered as beingcommon data if two or more applications access it Integration isprovided between the legacy applications and the common modelvia ldquogeneric wrappersrdquo that provide the general management re-quired in order to operate the applications The wrappers convertthe data to and from the native format using modular conversionalgorithms that can be plugged into the wrappers and provide thedomain-specific management for the applications Data are auto-matically downloaded from the common model and converted intothe native format when the application is started When the appli-cation is complete the designer has the option of undertaking thereverse process to convert the data back into the neutral format andupload into the common model Despite being a complex processconverters have been produced for a number of design applica-tions such as Tribon and AVPro and have been demonstrated tooperate without the need for manual interaction However theissues relating to the lack of integration between tools and con-tinuous product models remain to be addressed

The VRShips system also has an additional management layerconsisting of a process controller and an inference engine that arejointly responsible for maintaining data consistency and versionconstraint and process management Visualizing of product datavia the legacy applications is managed through the exporting of

Fig 16 Object diagram for generic shipyard computer model (Lamb et al 2000)

the displays via a virtual interaction environment These controlmechanisms ensure that designers may modify the data containedwithin the common model from any location either organization-ally or geographically distributed with network access using anapplication that they are familiar with and that any changes madeto the product model are correctly propagated such that the dataremain consistent

Every product modeling tool and technique discussed withinthis review is common from the perspective that the data containedwithin the model are a ldquosnapshotrdquo of the actual design activity Forinstance a designer may download data from the ship productmodel for use within a general design package which may take aweek to design During this design period the data within theproduct model do not change until the designer decides that thedesign process is complete and the data are uploaded into theproduct model The product model therefore does not contain acontinuous representation of either the design work that is cur-rently being undertaken or the form that the data are in This posesa number of significant project management issues with respect toversion control consistency management and conflict resolutionespecially in the situation where the design process is being un-dertaken in a distributed manner as is increasingly becomingcommon

A paradigm shift in the techniques used to enable the distributeddesign of ships while enabling a continuous product model andfacilitating the management of conflicts and consistency would bethe adoption of a technology that is more often seen within thecomputer games industry Graphics servers are commonly usedwithin the games industry to enable the user to immerse them-selves within an environment and interact both with the environ-ment and with other users High-level graphical objects are com-municated between the server side and the client side rather thanusing structured files This technique bypasses the need to trans-late the communicated data into the client side format alleviatingunnecessary computation It also results in a model containedwithin the server and represented within the clients that is a con-tinuous depiction of what everyone is undertaking The ship prod-uct data would remain within the ship STEP formats Howeverthe description method would be the graphical object representa-tion that would also exhibit behavioral properties Within the ship-building context individual graphics servers would represent do-mains similar to those identified by Crawford et al (1999) Clientsconnecting to the servers would immediately get an up-to-dateview of that particular domain which would be consistent with theviews of all of the other clients The client software would operatein a manner similar to conventional design applications There isalso clearly a requirement for integration between the differentdomain servers to enable conflicts to be resolved across domainsSimulation servers would integrate all of the scenarios that wouldenable an evaluation of the performance within any particular lifephase There would still remain the need to provide an effectivemanagement of different versions as well as a high-level coordi-nation structure to manage conflicts constraints design goals andcollaboration among designers However the underlying frame-work would provide the basis on which to construct this Despitebeing a significant step-change compared with current practicethis future technique proposes a viable solution to the effectivemanagement of a ship product model that may be manipulated andoperated upon in a distributed manner

This type of architecture does however raise a number of

issues relating to partnerships between the shipbuilding industryand the shipbuilding software industry because the system wouldrepresent an amalgamation of existing design and simulation ap-plications into a number of domain-specific servers The intellec-tual property rights as well as the ownership of both the technol-ogy and the data contained would clearly need to be resolved Inaddition the system calls upon the need to implement a standardfor the communication of the graphical objects that is both secureand robust whereas the standard for the data may be ldquoflavoredrdquoand managed effectively within the system via the ability to dy-namically load classes

Just as many of the precommissioning life phases are currentlybeing modeled it is anticipated that the rather poorly supportedpostcommissioning life phases will be catered for The most sig-nificant difference between pre- and postcommissioning is that itwill be the ship product model in its entirety that will be consid-ered For example there currently appears to be a significantopportunity for the specialization of the immersion of an entireship product model into an artificial environment to determine theoperational performance both at virtual sea (modeling existingshipping lanes to determine sea-keeping characteristics) within avirtual port (modeling existing ports to determine cargo-handlingcharacteristics) within a virtual shipyard for recommissioning(modeling existing shipyards to determine recommissioning capa-bility) and within a virtual breakers yard for disposal (to deter-mine scrap value) Increased opportunity would therefore be madefor designing the ship to meet a more rigorous set of customer-specified life-phase requirements and would represent a signifi-cant commercial advantage

It is also interesting at this point to note that a number of thecited papers have stated the need to avoid a reliance on computerprogrammers which in order to maintain even the simplest ofproduct data modeling systems seems unachievable

Conclusions

From the increasing amount of literature and the papers re-viewed within this paper related to the ship product model theprimary focus is on developing a standard representation for thedata contained within the model Despite not having yet finalizedthe standards for all aspects of the ship the STEP APs go a longway toward achieving this It is almost inconceivable to considerthat an alternative could compete against such a massive thrusttoward ship data standardization A number of instances havearisen however when the APs have been adhered to with theresult that ldquoflavorsrdquo or minor changes to the standard have beenrequired in order to utilize the structured well-defined and stan-dardized data within the legacy applications The question there-fore arises as to whether there is a requirement to standardize thelegacy applications such that they adhere to the data standard toenable a modular plug-in approach to ship design and simulation

Behavioral aspects have been considered within a number of thecited papers to be an important addition to the data in order toprovide the designer with additional feedback with respect to theoperation of the design This behavior may however be betterrepresented as high-level rules within a standard that are used todefine the operation of the ship rather than in existing standardsin order to minimize its impact on applications that have no needfor such data

A number of the tools and techniques discussed have described

the use of the ship STEP formats as being a mechanism for inte-grating existing legacy applications with a common model of shipproduct data Considerable benefit would be obtained from pro-viding similar integration between applications to progress fromthe limitations of discrete design and simulation toward having aholistic approach

The design tasks that are undertaken as part of the ship designprocess may well take a considerable amount of time and wouldconventionally result in ldquosnapshotsrdquo of the design artifact coin-ciding with the designer uploading data into the common modelA number of future directions have been discussed which wouldindividually require considerable development in order to imple-ment but which represent possible solutions to issues relating to

Continuous rather than ldquosnapshotrdquo ship product models Integration between the ship product model and the design

and simulation applications as well as across applications Removal of information translation problems through the

use of high-level graphical objects that are consistent betweenservers and applications

A collaborative framework on which to develop versionconflict and consistency management

Acknowledgments

The review was undertaken as part of an investigation intocommon model techniques within the VRShips-ROPAX2000project The authors gratefully acknowledge the support given bythe European Commission Community Research 5th Frameworkprogram under the area of Competitive and Sustainable Growthwhich provided the grant (G3RD-CT-2001-00506) that enabledthis work to be undertaken

References

BAUM S J AND RAMAKRISHNAN R 1997 Applying 3D product modelingtechnology in shipbuilding Marine Technology 34 1 56ndash65

CATLEY D 1999 Prototype STEP data exchanges in ship initial design andprovision of an application programmer interface to TRIBON Proceedings10th International Conference on Computer Applications in ShipbuildingJune Cambridge MA

CRAWFORD A K HARRINGTON G AMES R M AND VAN ESELTINE RT 1999 Neutral format data exchanges between ship product models andanalysis interfaces Proceedings 10th International Conference on Com-puter Applications in Shipbuilding June Cambridge MA

ERIKSTAD S O AND FATHI D E 1999 Applying the STEP shipbuildingprotocols as a basis for integrating existing in-house ship design applica-tions Proceedings 10th International Conference on Computer Applica-tions in Shipbuilding June Cambridge MA

GISCHNER B KASSEL B LAZO P WOOD R AND WYMAN J 2001 Evolution of STEP (ESTEP) exchange of shipbuilding productmodel data JOURNAL OF SHIP PRODUCTION 17 3 151ndash160

GRAU M AND KOCH T 1999 Applying STEP technology to shipbuildingProceedings 10th International Conference on Computer Applications inShipbuilding June Cambridge MA

HERZOG E AND TOumlRNE A 1999 A seed for a STEP application protocolfor systems engineering Proceedings 12th International Conference andWorkshop on the Engineering of Computer Based Systems Institute ofElectrical and Electronics Engineers Press Piscataway NJ 174ndash180

HIGNEY J T AND OUILETTE J J 1994 An engineering product modelbased on STEP protocols JOURNAL OF SHIP PRODUCTION 10 4 281ndash286

ISO 1996 Product Data Representation and Exchange Part 218 Ship Struc-

tures International Standards Organization Hamburg GermanyJOHANSSON K 1995 The product model as a central information source in

a shipbuilding environment Proceedings National Shipbuilding ResearchProgram 1995 Ship Production Symposium June Seattle WA

LAMB T CHUNG H AND SHIN J G 2000 A generic shipyard computermodel a tool for design for production Proceedings 7th IMDC NovemberKyung-Ju Korea

MARTIN D J 1980 The shipyard product information system as an aid toimplementing more productive strategies Proceedings Research and Engi-neering for Automation and Productivity in Shipbuilding IIT Research In-stitute October Chicago IL 81ndash101

POLINI M A AND MELAND K E 1997 The development and implemen-tation of a SMART product model for ship structure Proceedings 9thInternational Conference on Computer Applications in Shipbuilding Octo-ber Yokohama Japan

RANDO T C AND FERNHOLZ D 2000 MARITECHrsquos shipbuilding infor-mation infrastructure JOURNAL OF SHIP PRODUCTION 16 2 110ndash120

RANDO T C 2001 XML-based interoperability in the integrated shipbuild-ing environment (ISE) JOURNAL OF SHIP PRODUCTION 17 2 69ndash75

ROSS J M AND GARCIA L 1998 Making the jump to product modeltechnology JOURNAL OF SHIP PRODUCTION 14 1 15ndash26

ROSS J M AND ABAL D 2001 Practical use of 3D product modeling inthe small shipyard JOURNAL OF SHIP PRODUCTION 17 1 27ndash34

SCHMIDT W R VANDER J R AND SHIELDS V R 1990 Modelling andtransfer of product model digital data for the DDG 51 class destroyer pro-gram Proceedings National Shipbuilding Research Program 1990 ShipProduction Symposium August Milwaukee WI

SHIN Y AND HAN S H 1998 Data enhancement for sharing of shipdesign models Computer-Aided Design 30 12 931ndash941

VON HAARTMAN J KUUTTI I AND SCHAUMAN C 1994 Improving designproductivity with a product model for initial ship design Proceedings 8thInternational Conference on Computer Applications in Shipbuilding Sep-tember Bremen Germany

WELSH M LYNCH J AND BRUN B 1992 A data model for integration ofthe precommissioning life-cycle stages of the shipbuildingproduct JOURNAL

OF SHIP PRODUCTION 8 4 220ndash234WHITFIELD R I COATE S G DUFFY A H B AND HILLS

W 2000 Coordination approaches and systemsmdashpart I a strategic per-spective Research in Engineering Design 12 73ndash89

WYMAN J WOOLEY D GISCHNER B AND HOWELL J 1997 Development of STEP ship model database and translators fordata exchange between shipyards JOURNAL OF SHIP PRODUCTION 13 2111ndash124

Internet addresses

European Marine STEP Association httpemsagermanlloydorg

ISO STEP ship team http wwwnsnetcomNIDDESCt23html

Japan Marine Standards Association http wwwjecalsjipdecorjp

Korea STEP Centre httpksteporkr

of information A number of small shipyards that have incorpo-rated product-modeling technologies are used as case studies todiscuss the techniquersquos effectiveness with the conclusions thatthese shipyards have an improved production quality and signifi-cant savings in material cost labor cost construction cost andlabor hours Despite being a more complex representation thantraditional techniques Ross and Abal (2001) concluded that stafftraining was straightforward and that staff were considered com-petent after the design of the first vessel

Polini and Meland (1997) discussed the extension of a prototypeproduct modeling system through to the development of a pro-duction implementation that was capable of supporting concur-rent multiuser access Life-cycle data and behavior were modeledwithin the classes contained in the Smart Product Modelling(SPM) system The differentiation between a standard productmodel and an SPM system is shown in Fig 11 To appreciate theamount of effort involved in developing the SPM Polini andMeland state ldquoTo date nearly 45 man-years of software devel-opment have been invested in the SPM and its GUI approxi-mately 1000 classes with over 30000 methods have been devel-oped object oriented databases on the order of 25 gigabytes arecommonplace 24 concurrent users have modeled five shipclasses and tens of thousands of structural parts have been manu-facturedrdquo

This development was undertaken entirely within a shipyardwithout any commercial input Polini and Meland justified thisdevelopment by surveying the requirements of the shipyard andconcluding that there were no commercially available systemscapable of dealing with the degrees of specialization within theshipbuilding industry a point that has also been made by Jo-hansson (1995)

One of the questions asked by Shin and Han (1998) and others(Baum amp Ramakrishnan 1997) is whether it is possible to imple-ment paperless design because designers often spend a great dealof time trying to extract useful information from two-dimensionalpaper drawings The shipbuilding building blocks within the STEPshipbuilding APs were used as the basis to produce a ship product

model Shin used the STEP toolkit ST-Developer to produce C++classes using the EXPRESS data definition language for the mid-ship section of a bulk carrier

The classes were enhanced to enable all life-cycle product in-formation to be stored within a single data structure as well as fortranslating data formats by one-to-one mapping and includingexplicit information (Youngrsquos modulus Poissonrsquos ratio) from de-sign conventions available within the product model The systemarchitecture can be seen in Fig 12 This enhancement was re-quired because Shin suggested that it was not sufficient to simplytranslate data from a neutral format into the format required byeach application Rather it is a requirement of each applicationthat associated functions and information specific to each appli-cation is also incorporated into the model

This requirement for functional data was also discussed byCrawford et al (1999) Rather than relying on a flat neutral file tocontain geometry and topology information it was considereduseful that the topological data for example were provided withsome sort of intelligence to facilitate the translation between ap-plications The STEP standards were adhered to wherever pos-sible However achieving intelligent topology required extensionof the standards Crawford defined the Newport News Shipbuild-ing view of a product model as ldquoan all encompassing model of a

Fig 11 Product model definitions (Polini amp Meland 1997)

Fig 10 Representation of a ship three-dimensional product model (Baum amp Ramakrishnan 1997)

ship project taking advantage of the available computer toolsfor describing the geometry of a ship but it also includes allattributes necessary for the design production and operation ofthe shiprdquo

Again it was considered unlikely that the ship could be definedby a single computer system rather than by a number of moremanageable systems grouped according to some arbitrarily de-fined domains (Fig 13)

Crawford demonstrated the use of intelligent topological andgeometric STEP-based data through the use of the GOBS commonobject request brokerage architecture (CORBA) server that pro-vides a number of methods to enable legacy tools to extract therequired data Two analysis tools were used to model the ship

vulnerability and hydrostatics which obtained their data from theGOBS server The analysis concluded that within the majority ofthe cases the STEP standard for geometric data (Part 42) wassufficient to represent the geometry for the ship

Rando and Fernholz (2000) describes how the DARPA Mar-itech Shipbuilding Information Infrastructure Project (SHIIP) andShipbuilding Partners and Suppliers (SPARS) projects used acombination of component-based software internet protocols anda portable computing platform to satisfy the following shipbuild-ing information technical requirements

An information technology gap separates the large me-dium and small shipyards

Fig 12 System architecture of the STEP manager (Reprinted from Shin amp Han 1998 with permission from Elsevier)

The information technology staffs at most shipyards areexperts in shipbuilding process requirements but not in system-level computer technologies

Shipyard information systems must be reliable and main-tainable yet often need to be customized to suit an individualshipyard

As with many other projects (Rando 2001 Gischner et al 2001)integration within the shipbuilding industry was considered pos-sible only by the reuse of existing software components becausethe number of shipbuilding system requirements is so diverse thatit is unrealistic to assume that it is possible to produce a singleoverarching solution The integrated system was considered toconsist of a number of independent components to be assembledand reused by third parties in order to create a new complexsystem The initial task of the SHIIP project was to define areference architecture to support the composition of the indepen-dent components

The management of the product data was achieved using En-terprise Java Beans (EJB) that enable persistent storage secureaccess and load balancing for multiple users wishing to access thedata simultaneously At the start of the SHIIP project however

EJB was not available and the project relied instead on CORBAtechnology The project learned the following lessons from usingCORBA

Technology independence although useful in theoryshould not be pursued at the expense of developing workingimplementations

Technical interoperability is not a requirement for the de-velopment of an industrial information infrastructure Support-ing applications and software components for the informationinfrastructure are homogeneous enough to be implemented in asingle implementation technology

The Object Management Group (OMG) while advocatingseparation of components has produced in the arena of do-main standards wrappers for monolithic applications

OMG has been hampered by the inability to reach timelyconsensus

The Integrated Shipbuilding Environment (ISE) project withinthe Maritech Advanced Shipbuilding Enterprise (ASE) is usingXML as the basis for achieving interoperability between ship-building systems technologies specifically between application toapplication (Rando 2001) Rando differentiates this problem fromthat of other industries by stating that many of the applicationcomponents used within the shipbuilding industry have alreadybeen developed as well as the having little control over the de-velopment of these systems The shipbuilding product model mayalso contain millions of instances of a large number of differenttypes of information that need to be managed as they evolve overthe productrsquos life cycle It is also suggested that not only is therea need to rely on an enterprise system that augments the manyspecialist applications but due to the diversity of informationwithin the life cycle of the ship no single information system issufficient to deal with the entire ship product Indeed previousalliances between shipyards have been one-off solutions and thereis a definite requirement for a standardized effort for the shipproduct model

Rando identified a number of business drivers in order toachieve interoperability within the shipbuilding industry and pro-

Fig 13 Domain-based ship system (Crawford et al 1999)

Fig 14 ISE reference architecture three levels of interoperability (Rando 2001)

posed an architecture in order to respond to these drivers (Fig 14)The architecture represents three interoperability levels within theshipbuilding environment intercomponent refers to the interac-tions between the software components within a system intersys-tem refers to the interactions between the systems and is boundedby a business system domain and interenterprise interoperabilityrefers to interactions between business systems domains at differ-ent shipyards and organizations

The key elements for achieving this interoperability were acommon syntax using XML to facilitate communication a sharedstandard information model using STEP and an interoperabilityinfrastructure using web-based technologies XML is a neutralformat that may be viewed by humans (although this is not gen-erally a primary requirement) and that enables the sharing of in-formation between different technologies different operating sys-tems and different programming languages Five keyrequirements were identif ied to facilitate application-to-application integration

Should ldquoreuserdquo widely available standards-based tools Should be implementable with tools that allow for recon-

figuration by nonprogrammers Should support transformation to and from a canonical or

neutral format Should utilize a representation that is as simple and con-

cise as possible Should be able to marshalunmarshal every semantic con-

cept representable in the EXPRESS information modeling lan-guage (ISO 10303-11)

One of the most significant issues relating to the use and inte-gration of ship product models with existing applications appearsto be the need to ldquoflavorrdquo the model and specifications to suit theparticular requirements of the design and simulation applicationsWithout these embellishments the fully automated data integra-tion appears quite often difficult to achieve There are howeverconflicting opinions regarding the effectiveness of automating thisprocess generally arising due to the complexity of the problem andthe level of support The application of ldquoflavoredrdquo standards doeshowever entirely go against the point of creating a standard es-pecially when it is with respect to the transfer of product data Itcould therefore be concluded that the solution to the effectiveintegration of STEP lies not in the modification of a new tech-nology to satisfy the requirements of legacy applications but inthe updating of the legacy applications to satisfy the new technol-ogy

Life-cycle issues

The NEUTRABAS project (Welsh et al 1992) was limited tothe precommissioning stages that is marketing conceptual de-sign detailed design drafting materials ordering productionplanning and control scheduling and quality control However itwas recognized that significant benefits would be achievedthrough extending the life cycle through to disposal Welsh et alqualified the limitation to the precommissioning stages by statingthat ldquothe definition and implementation of a complete product datamodel covering all of these aspects of the life-cycle of an engi-neering product as complex as a ship is an onerous task and one

which would require the commitment of a vast amount of time andeffortrdquo

Limiting the project to the precommissioning stages would ap-pear to have been a wise judgment because in the 10 years fol-lowing this project the standards created to describe the shipproduct model have still not yet been finalized

Welsh et al suggest that the physical representation of the prod-uct within each life cycle stage would ldquonormally be unchanged inthe global sense although the information associated with theproduct and the techniques used to represent it will vary consid-erablyrdquo that is the information contained within the productmodel would mature as more detail becomes available as well asrequiring different viewpoints at each life-cycle stage The productmodel must therefore be developed not only with the associateddata and structure in mind but also with the life-cycle stages Toenable the support of the precommissioning life-cycle stagesWelsh et al identified four views that need to be supported by theship product model

Marketing-oriented view Management-oriented view Design-oriented view Production-oriented view

Von Haartman et al (1994) briefly discussed life phase issues ofthe ship product model and suggested that a number of systemsmodel the design with too much detail and hence are not appli-cable to the concept design stage A solution to this was thedevelopment of a concept design product model that could then betransferred to the detailed design stage It is not clear from thiswhether Von Haartman et al were proposing separate models forthe two stages or if the detail product model would simply consistof the concept product model plus the additional required detail

The mechanism of having multiple different views for the shar-ing of a product model among designers and production engineersfor example has been considered and implemented in a number ofcases (Polini amp Meland 1997 Johansson 1995) Johansson indi-cated that it is common for parts of the product to be in differentlife-cycle stages at the same time that is the ldquomanufacture of onepart of the product is going on at the same time as the detaileddesign of anotherrdquo This is one aspect of concurrent engineeringwith the result of reducing the lead times because the manufactureof the product has started before the design of the product has beencompleted However it is necessary to ensure both that manufac-turing starts only on parts that require no further design and thatother parts that are currently being designed do not propagatechanges to the manufactured parts The management and controlof the information flow were recognized as being the key elementsin increasing the overlapping of life cycles However no expla-nation was given by Johansson regarding the nature of the man-agement other than through the relationships between the objectscontained within the model These relationships were described asa mechanism to enable both interdisciplinary and cross-disciplinary communication among designers

The three-dimensional product model was described by Baumand Ramakrishnan (1997) as being a mechanism to enable a num-ber of different life-cycle stage simulations such as interferencechecking crew traffic flow studies yard-specific designs and fi-nite capacity scheduling through the use of a virtual environmentdesign review technology using data contained within the productmodel (Fig 15)

Coupled with simulation-based design (SBD) Baum describedthe combined technology as ldquothe new frontierrdquo that would enablethe virtual prototyping of the ship which previously could not beachieved due to the cost and complexity More importantly Baumrecognized that just as interference-checking software may beused to determine discrepancies between geometric parts duringthe design and production phases SBD may be used to reduce oreliminate design errors that would have previously have beendiscovered years later in the operational stage for example Es-sentially SBD and product modeling enable the validation of thedesign production and operation stages of the ship product

Baum also finally suggested that the product model provides asignificant benefit to the owneroperator by enabling the analysisand support of life-cycle maintenance

A generic shipyard computer modeling tool for evaluating de-sign for production (DFP) is discussed by Lamb et al (2000) Thetool enables shipyards to be modeled such that the impacts ofchanges to the ship design may be determined on the basis of theresulting material manpower and schedule The shipyard modelrepresents details of the buildingsmdashtheir arrangement and size aswell as equipment capacity and flow The tool also enables aninvestigation of the necessary changes required for a shipyard inorder to produce a new design The key foundations in order toevaluate these impacts are the interim product catalogue and thebuild strategy approach

Lamb et al identified a number of important concepts for DFP

All designs should be prepared to suit a shipyardrsquos facili-ties and preferred production methods

DFP takes into account production methods and tech-niques that reduce the product work content but still meet thespecified design requirements and quality

DFP must be incorporated into a design from the start Traditional engineering leaves it up to another department

such as production or manufacturing engineering to developthe technical documentation required for the production work-ers This is an unnecessary duplication of effort and is a nonndashvalue-added task that takes time

An objective of the CE approach is to accommodate DFPby bringing all the necessary people together right from dayone on a project

The time to influence the cost of a product is during theearly stages After the design has been developed in conceptmost of the opportunity to positively affect cost is gone

World-class ship designers know how their shipyardbuilds ships and design accordingly Many ship designers donot consider this and the designs may or may not be efficientlybuilt in their facilities More shipbuilders have taken steps toremedy this situation through the use of the build strategyapproach

Engineering should be prepared and transmitted to theusers in a way that best suits block construction advanced andzone outfitting

An object-oriented approach was adopted for the constructionof the model (Fig 16) The model represents shipyards worksta-tions products equipment processes manufacturing processesmaterial handling processes and interim products The tool wasapplied to the evaluation of two design alternatives for the bottomstructure of a ship The authors demonstrated that the tool enabledreliable evaluations of the man-hours for manufacturing and ma-terial handling such that the best design alternative could beadopted

Future directions

It is believed that the ship STEP APs will become the standardunit of shipbuilding data but that it will probably be an evolution-ary process as advances in technology and modeling capabilitiesand requirements are incorporated It is however crucial that thedevelopment of the standards comes to a timely consensus at eachevolutionary stage The literature reviewed has discussed the useof ldquointelligentrdquo data the inclusion of useful functionality accord-ing to the data type and of behavioral aspects It is anticipated thatthis functionality behavioral aspects and so forth will increas-

Fig 15 Ship design workflow using three-dimensional product model (Baum amp Ramakrishnan 1997)

ingly become part of the model to the extent that the model nolonger has any need for interfaces and translators to legacy soft-ware For example the piping model would automatically calcu-late interferences and the structures model would automaticallycalculate stress characteristics The simulation would essentiallybe part of the model and the model would contain additionalinformation and knowledge to effectively manage the simulationThis is not to say that the model would become a monolithicsystem despite such a system being potentially computationallyviable in 10 years Rather than being monolithic current andfuture distributed information technologies such as EnterpriseJava Beans may be utilized in order to distribute the model acrossa network while giving the impression to the user that the systemis monolithic Ship product data and functionality would be dis-tributed either within a single company or as partnerships withother companies

In a similar way that the ship product data has become stan-dardized benefits are to be gained from standardizing the inter-faces between applications to support the flow of standardizeddata and achieve a truly seamless integration The unfortunateshortcoming of application standardization is the necessity to re-develop the legacy systems to support this level of integration

The VRShips project addresses the management of ship productdata within a neutrally formatted common model The geometry

data contained within the common model are based on STEPAP203 are described using XML and are considered as beingcommon data if two or more applications access it Integration isprovided between the legacy applications and the common modelvia ldquogeneric wrappersrdquo that provide the general management re-quired in order to operate the applications The wrappers convertthe data to and from the native format using modular conversionalgorithms that can be plugged into the wrappers and provide thedomain-specific management for the applications Data are auto-matically downloaded from the common model and converted intothe native format when the application is started When the appli-cation is complete the designer has the option of undertaking thereverse process to convert the data back into the neutral format andupload into the common model Despite being a complex processconverters have been produced for a number of design applica-tions such as Tribon and AVPro and have been demonstrated tooperate without the need for manual interaction However theissues relating to the lack of integration between tools and con-tinuous product models remain to be addressed

The VRShips system also has an additional management layerconsisting of a process controller and an inference engine that arejointly responsible for maintaining data consistency and versionconstraint and process management Visualizing of product datavia the legacy applications is managed through the exporting of

Fig 16 Object diagram for generic shipyard computer model (Lamb et al 2000)

the displays via a virtual interaction environment These controlmechanisms ensure that designers may modify the data containedwithin the common model from any location either organization-ally or geographically distributed with network access using anapplication that they are familiar with and that any changes madeto the product model are correctly propagated such that the dataremain consistent

Every product modeling tool and technique discussed withinthis review is common from the perspective that the data containedwithin the model are a ldquosnapshotrdquo of the actual design activity Forinstance a designer may download data from the ship productmodel for use within a general design package which may take aweek to design During this design period the data within theproduct model do not change until the designer decides that thedesign process is complete and the data are uploaded into theproduct model The product model therefore does not contain acontinuous representation of either the design work that is cur-rently being undertaken or the form that the data are in This posesa number of significant project management issues with respect toversion control consistency management and conflict resolutionespecially in the situation where the design process is being un-dertaken in a distributed manner as is increasingly becomingcommon

A paradigm shift in the techniques used to enable the distributeddesign of ships while enabling a continuous product model andfacilitating the management of conflicts and consistency would bethe adoption of a technology that is more often seen within thecomputer games industry Graphics servers are commonly usedwithin the games industry to enable the user to immerse them-selves within an environment and interact both with the environ-ment and with other users High-level graphical objects are com-municated between the server side and the client side rather thanusing structured files This technique bypasses the need to trans-late the communicated data into the client side format alleviatingunnecessary computation It also results in a model containedwithin the server and represented within the clients that is a con-tinuous depiction of what everyone is undertaking The ship prod-uct data would remain within the ship STEP formats Howeverthe description method would be the graphical object representa-tion that would also exhibit behavioral properties Within the ship-building context individual graphics servers would represent do-mains similar to those identified by Crawford et al (1999) Clientsconnecting to the servers would immediately get an up-to-dateview of that particular domain which would be consistent with theviews of all of the other clients The client software would operatein a manner similar to conventional design applications There isalso clearly a requirement for integration between the differentdomain servers to enable conflicts to be resolved across domainsSimulation servers would integrate all of the scenarios that wouldenable an evaluation of the performance within any particular lifephase There would still remain the need to provide an effectivemanagement of different versions as well as a high-level coordi-nation structure to manage conflicts constraints design goals andcollaboration among designers However the underlying frame-work would provide the basis on which to construct this Despitebeing a significant step-change compared with current practicethis future technique proposes a viable solution to the effectivemanagement of a ship product model that may be manipulated andoperated upon in a distributed manner

This type of architecture does however raise a number of

issues relating to partnerships between the shipbuilding industryand the shipbuilding software industry because the system wouldrepresent an amalgamation of existing design and simulation ap-plications into a number of domain-specific servers The intellec-tual property rights as well as the ownership of both the technol-ogy and the data contained would clearly need to be resolved Inaddition the system calls upon the need to implement a standardfor the communication of the graphical objects that is both secureand robust whereas the standard for the data may be ldquoflavoredrdquoand managed effectively within the system via the ability to dy-namically load classes

Just as many of the precommissioning life phases are currentlybeing modeled it is anticipated that the rather poorly supportedpostcommissioning life phases will be catered for The most sig-nificant difference between pre- and postcommissioning is that itwill be the ship product model in its entirety that will be consid-ered For example there currently appears to be a significantopportunity for the specialization of the immersion of an entireship product model into an artificial environment to determine theoperational performance both at virtual sea (modeling existingshipping lanes to determine sea-keeping characteristics) within avirtual port (modeling existing ports to determine cargo-handlingcharacteristics) within a virtual shipyard for recommissioning(modeling existing shipyards to determine recommissioning capa-bility) and within a virtual breakers yard for disposal (to deter-mine scrap value) Increased opportunity would therefore be madefor designing the ship to meet a more rigorous set of customer-specified life-phase requirements and would represent a signifi-cant commercial advantage

It is also interesting at this point to note that a number of thecited papers have stated the need to avoid a reliance on computerprogrammers which in order to maintain even the simplest ofproduct data modeling systems seems unachievable

Conclusions

From the increasing amount of literature and the papers re-viewed within this paper related to the ship product model theprimary focus is on developing a standard representation for thedata contained within the model Despite not having yet finalizedthe standards for all aspects of the ship the STEP APs go a longway toward achieving this It is almost inconceivable to considerthat an alternative could compete against such a massive thrusttoward ship data standardization A number of instances havearisen however when the APs have been adhered to with theresult that ldquoflavorsrdquo or minor changes to the standard have beenrequired in order to utilize the structured well-defined and stan-dardized data within the legacy applications The question there-fore arises as to whether there is a requirement to standardize thelegacy applications such that they adhere to the data standard toenable a modular plug-in approach to ship design and simulation

Behavioral aspects have been considered within a number of thecited papers to be an important addition to the data in order toprovide the designer with additional feedback with respect to theoperation of the design This behavior may however be betterrepresented as high-level rules within a standard that are used todefine the operation of the ship rather than in existing standardsin order to minimize its impact on applications that have no needfor such data

A number of the tools and techniques discussed have described

the use of the ship STEP formats as being a mechanism for inte-grating existing legacy applications with a common model of shipproduct data Considerable benefit would be obtained from pro-viding similar integration between applications to progress fromthe limitations of discrete design and simulation toward having aholistic approach

The design tasks that are undertaken as part of the ship designprocess may well take a considerable amount of time and wouldconventionally result in ldquosnapshotsrdquo of the design artifact coin-ciding with the designer uploading data into the common modelA number of future directions have been discussed which wouldindividually require considerable development in order to imple-ment but which represent possible solutions to issues relating to

Continuous rather than ldquosnapshotrdquo ship product models Integration between the ship product model and the design

and simulation applications as well as across applications Removal of information translation problems through the

use of high-level graphical objects that are consistent betweenservers and applications

A collaborative framework on which to develop versionconflict and consistency management

Acknowledgments

The review was undertaken as part of an investigation intocommon model techniques within the VRShips-ROPAX2000project The authors gratefully acknowledge the support given bythe European Commission Community Research 5th Frameworkprogram under the area of Competitive and Sustainable Growthwhich provided the grant (G3RD-CT-2001-00506) that enabledthis work to be undertaken

References

BAUM S J AND RAMAKRISHNAN R 1997 Applying 3D product modelingtechnology in shipbuilding Marine Technology 34 1 56ndash65

CATLEY D 1999 Prototype STEP data exchanges in ship initial design andprovision of an application programmer interface to TRIBON Proceedings10th International Conference on Computer Applications in ShipbuildingJune Cambridge MA

CRAWFORD A K HARRINGTON G AMES R M AND VAN ESELTINE RT 1999 Neutral format data exchanges between ship product models andanalysis interfaces Proceedings 10th International Conference on Com-puter Applications in Shipbuilding June Cambridge MA

ERIKSTAD S O AND FATHI D E 1999 Applying the STEP shipbuildingprotocols as a basis for integrating existing in-house ship design applica-tions Proceedings 10th International Conference on Computer Applica-tions in Shipbuilding June Cambridge MA

GISCHNER B KASSEL B LAZO P WOOD R AND WYMAN J 2001 Evolution of STEP (ESTEP) exchange of shipbuilding productmodel data JOURNAL OF SHIP PRODUCTION 17 3 151ndash160

GRAU M AND KOCH T 1999 Applying STEP technology to shipbuildingProceedings 10th International Conference on Computer Applications inShipbuilding June Cambridge MA

HERZOG E AND TOumlRNE A 1999 A seed for a STEP application protocolfor systems engineering Proceedings 12th International Conference andWorkshop on the Engineering of Computer Based Systems Institute ofElectrical and Electronics Engineers Press Piscataway NJ 174ndash180

HIGNEY J T AND OUILETTE J J 1994 An engineering product modelbased on STEP protocols JOURNAL OF SHIP PRODUCTION 10 4 281ndash286

ISO 1996 Product Data Representation and Exchange Part 218 Ship Struc-

tures International Standards Organization Hamburg GermanyJOHANSSON K 1995 The product model as a central information source in

a shipbuilding environment Proceedings National Shipbuilding ResearchProgram 1995 Ship Production Symposium June Seattle WA

LAMB T CHUNG H AND SHIN J G 2000 A generic shipyard computermodel a tool for design for production Proceedings 7th IMDC NovemberKyung-Ju Korea

MARTIN D J 1980 The shipyard product information system as an aid toimplementing more productive strategies Proceedings Research and Engi-neering for Automation and Productivity in Shipbuilding IIT Research In-stitute October Chicago IL 81ndash101

POLINI M A AND MELAND K E 1997 The development and implemen-tation of a SMART product model for ship structure Proceedings 9thInternational Conference on Computer Applications in Shipbuilding Octo-ber Yokohama Japan

RANDO T C AND FERNHOLZ D 2000 MARITECHrsquos shipbuilding infor-mation infrastructure JOURNAL OF SHIP PRODUCTION 16 2 110ndash120

RANDO T C 2001 XML-based interoperability in the integrated shipbuild-ing environment (ISE) JOURNAL OF SHIP PRODUCTION 17 2 69ndash75

ROSS J M AND GARCIA L 1998 Making the jump to product modeltechnology JOURNAL OF SHIP PRODUCTION 14 1 15ndash26

ROSS J M AND ABAL D 2001 Practical use of 3D product modeling inthe small shipyard JOURNAL OF SHIP PRODUCTION 17 1 27ndash34

SCHMIDT W R VANDER J R AND SHIELDS V R 1990 Modelling andtransfer of product model digital data for the DDG 51 class destroyer pro-gram Proceedings National Shipbuilding Research Program 1990 ShipProduction Symposium August Milwaukee WI

SHIN Y AND HAN S H 1998 Data enhancement for sharing of shipdesign models Computer-Aided Design 30 12 931ndash941

VON HAARTMAN J KUUTTI I AND SCHAUMAN C 1994 Improving designproductivity with a product model for initial ship design Proceedings 8thInternational Conference on Computer Applications in Shipbuilding Sep-tember Bremen Germany

WELSH M LYNCH J AND BRUN B 1992 A data model for integration ofthe precommissioning life-cycle stages of the shipbuildingproduct JOURNAL

OF SHIP PRODUCTION 8 4 220ndash234WHITFIELD R I COATE S G DUFFY A H B AND HILLS

W 2000 Coordination approaches and systemsmdashpart I a strategic per-spective Research in Engineering Design 12 73ndash89

WYMAN J WOOLEY D GISCHNER B AND HOWELL J 1997 Development of STEP ship model database and translators fordata exchange between shipyards JOURNAL OF SHIP PRODUCTION 13 2111ndash124

Internet addresses

European Marine STEP Association httpemsagermanlloydorg

ISO STEP ship team http wwwnsnetcomNIDDESCt23html

Japan Marine Standards Association http wwwjecalsjipdecorjp

Korea STEP Centre httpksteporkr

ship project taking advantage of the available computer toolsfor describing the geometry of a ship but it also includes allattributes necessary for the design production and operation ofthe shiprdquo

Again it was considered unlikely that the ship could be definedby a single computer system rather than by a number of moremanageable systems grouped according to some arbitrarily de-fined domains (Fig 13)

Crawford demonstrated the use of intelligent topological andgeometric STEP-based data through the use of the GOBS commonobject request brokerage architecture (CORBA) server that pro-vides a number of methods to enable legacy tools to extract therequired data Two analysis tools were used to model the ship

vulnerability and hydrostatics which obtained their data from theGOBS server The analysis concluded that within the majority ofthe cases the STEP standard for geometric data (Part 42) wassufficient to represent the geometry for the ship

Rando and Fernholz (2000) describes how the DARPA Mar-itech Shipbuilding Information Infrastructure Project (SHIIP) andShipbuilding Partners and Suppliers (SPARS) projects used acombination of component-based software internet protocols anda portable computing platform to satisfy the following shipbuild-ing information technical requirements

An information technology gap separates the large me-dium and small shipyards

Fig 12 System architecture of the STEP manager (Reprinted from Shin amp Han 1998 with permission from Elsevier)

The information technology staffs at most shipyards areexperts in shipbuilding process requirements but not in system-level computer technologies

Shipyard information systems must be reliable and main-tainable yet often need to be customized to suit an individualshipyard

As with many other projects (Rando 2001 Gischner et al 2001)integration within the shipbuilding industry was considered pos-sible only by the reuse of existing software components becausethe number of shipbuilding system requirements is so diverse thatit is unrealistic to assume that it is possible to produce a singleoverarching solution The integrated system was considered toconsist of a number of independent components to be assembledand reused by third parties in order to create a new complexsystem The initial task of the SHIIP project was to define areference architecture to support the composition of the indepen-dent components

The management of the product data was achieved using En-terprise Java Beans (EJB) that enable persistent storage secureaccess and load balancing for multiple users wishing to access thedata simultaneously At the start of the SHIIP project however

EJB was not available and the project relied instead on CORBAtechnology The project learned the following lessons from usingCORBA

Technology independence although useful in theoryshould not be pursued at the expense of developing workingimplementations

Technical interoperability is not a requirement for the de-velopment of an industrial information infrastructure Support-ing applications and software components for the informationinfrastructure are homogeneous enough to be implemented in asingle implementation technology

The Object Management Group (OMG) while advocatingseparation of components has produced in the arena of do-main standards wrappers for monolithic applications

OMG has been hampered by the inability to reach timelyconsensus

The Integrated Shipbuilding Environment (ISE) project withinthe Maritech Advanced Shipbuilding Enterprise (ASE) is usingXML as the basis for achieving interoperability between ship-building systems technologies specifically between application toapplication (Rando 2001) Rando differentiates this problem fromthat of other industries by stating that many of the applicationcomponents used within the shipbuilding industry have alreadybeen developed as well as the having little control over the de-velopment of these systems The shipbuilding product model mayalso contain millions of instances of a large number of differenttypes of information that need to be managed as they evolve overthe productrsquos life cycle It is also suggested that not only is therea need to rely on an enterprise system that augments the manyspecialist applications but due to the diversity of informationwithin the life cycle of the ship no single information system issufficient to deal with the entire ship product Indeed previousalliances between shipyards have been one-off solutions and thereis a definite requirement for a standardized effort for the shipproduct model

Rando identified a number of business drivers in order toachieve interoperability within the shipbuilding industry and pro-

Fig 13 Domain-based ship system (Crawford et al 1999)

Fig 14 ISE reference architecture three levels of interoperability (Rando 2001)

posed an architecture in order to respond to these drivers (Fig 14)The architecture represents three interoperability levels within theshipbuilding environment intercomponent refers to the interac-tions between the software components within a system intersys-tem refers to the interactions between the systems and is boundedby a business system domain and interenterprise interoperabilityrefers to interactions between business systems domains at differ-ent shipyards and organizations

The key elements for achieving this interoperability were acommon syntax using XML to facilitate communication a sharedstandard information model using STEP and an interoperabilityinfrastructure using web-based technologies XML is a neutralformat that may be viewed by humans (although this is not gen-erally a primary requirement) and that enables the sharing of in-formation between different technologies different operating sys-tems and different programming languages Five keyrequirements were identif ied to facilitate application-to-application integration

Should ldquoreuserdquo widely available standards-based tools Should be implementable with tools that allow for recon-

figuration by nonprogrammers Should support transformation to and from a canonical or

neutral format Should utilize a representation that is as simple and con-

cise as possible Should be able to marshalunmarshal every semantic con-

cept representable in the EXPRESS information modeling lan-guage (ISO 10303-11)

One of the most significant issues relating to the use and inte-gration of ship product models with existing applications appearsto be the need to ldquoflavorrdquo the model and specifications to suit theparticular requirements of the design and simulation applicationsWithout these embellishments the fully automated data integra-tion appears quite often difficult to achieve There are howeverconflicting opinions regarding the effectiveness of automating thisprocess generally arising due to the complexity of the problem andthe level of support The application of ldquoflavoredrdquo standards doeshowever entirely go against the point of creating a standard es-pecially when it is with respect to the transfer of product data Itcould therefore be concluded that the solution to the effectiveintegration of STEP lies not in the modification of a new tech-nology to satisfy the requirements of legacy applications but inthe updating of the legacy applications to satisfy the new technol-ogy

Life-cycle issues

The NEUTRABAS project (Welsh et al 1992) was limited tothe precommissioning stages that is marketing conceptual de-sign detailed design drafting materials ordering productionplanning and control scheduling and quality control However itwas recognized that significant benefits would be achievedthrough extending the life cycle through to disposal Welsh et alqualified the limitation to the precommissioning stages by statingthat ldquothe definition and implementation of a complete product datamodel covering all of these aspects of the life-cycle of an engi-neering product as complex as a ship is an onerous task and one

which would require the commitment of a vast amount of time andeffortrdquo

Limiting the project to the precommissioning stages would ap-pear to have been a wise judgment because in the 10 years fol-lowing this project the standards created to describe the shipproduct model have still not yet been finalized

Welsh et al suggest that the physical representation of the prod-uct within each life cycle stage would ldquonormally be unchanged inthe global sense although the information associated with theproduct and the techniques used to represent it will vary consid-erablyrdquo that is the information contained within the productmodel would mature as more detail becomes available as well asrequiring different viewpoints at each life-cycle stage The productmodel must therefore be developed not only with the associateddata and structure in mind but also with the life-cycle stages Toenable the support of the precommissioning life-cycle stagesWelsh et al identified four views that need to be supported by theship product model

Marketing-oriented view Management-oriented view Design-oriented view Production-oriented view

Von Haartman et al (1994) briefly discussed life phase issues ofthe ship product model and suggested that a number of systemsmodel the design with too much detail and hence are not appli-cable to the concept design stage A solution to this was thedevelopment of a concept design product model that could then betransferred to the detailed design stage It is not clear from thiswhether Von Haartman et al were proposing separate models forthe two stages or if the detail product model would simply consistof the concept product model plus the additional required detail

The mechanism of having multiple different views for the shar-ing of a product model among designers and production engineersfor example has been considered and implemented in a number ofcases (Polini amp Meland 1997 Johansson 1995) Johansson indi-cated that it is common for parts of the product to be in differentlife-cycle stages at the same time that is the ldquomanufacture of onepart of the product is going on at the same time as the detaileddesign of anotherrdquo This is one aspect of concurrent engineeringwith the result of reducing the lead times because the manufactureof the product has started before the design of the product has beencompleted However it is necessary to ensure both that manufac-turing starts only on parts that require no further design and thatother parts that are currently being designed do not propagatechanges to the manufactured parts The management and controlof the information flow were recognized as being the key elementsin increasing the overlapping of life cycles However no expla-nation was given by Johansson regarding the nature of the man-agement other than through the relationships between the objectscontained within the model These relationships were described asa mechanism to enable both interdisciplinary and cross-disciplinary communication among designers

The three-dimensional product model was described by Baumand Ramakrishnan (1997) as being a mechanism to enable a num-ber of different life-cycle stage simulations such as interferencechecking crew traffic flow studies yard-specific designs and fi-nite capacity scheduling through the use of a virtual environmentdesign review technology using data contained within the productmodel (Fig 15)

Coupled with simulation-based design (SBD) Baum describedthe combined technology as ldquothe new frontierrdquo that would enablethe virtual prototyping of the ship which previously could not beachieved due to the cost and complexity More importantly Baumrecognized that just as interference-checking software may beused to determine discrepancies between geometric parts duringthe design and production phases SBD may be used to reduce oreliminate design errors that would have previously have beendiscovered years later in the operational stage for example Es-sentially SBD and product modeling enable the validation of thedesign production and operation stages of the ship product

Baum also finally suggested that the product model provides asignificant benefit to the owneroperator by enabling the analysisand support of life-cycle maintenance

A generic shipyard computer modeling tool for evaluating de-sign for production (DFP) is discussed by Lamb et al (2000) Thetool enables shipyards to be modeled such that the impacts ofchanges to the ship design may be determined on the basis of theresulting material manpower and schedule The shipyard modelrepresents details of the buildingsmdashtheir arrangement and size aswell as equipment capacity and flow The tool also enables aninvestigation of the necessary changes required for a shipyard inorder to produce a new design The key foundations in order toevaluate these impacts are the interim product catalogue and thebuild strategy approach

Lamb et al identified a number of important concepts for DFP

All designs should be prepared to suit a shipyardrsquos facili-ties and preferred production methods

DFP takes into account production methods and tech-niques that reduce the product work content but still meet thespecified design requirements and quality

DFP must be incorporated into a design from the start Traditional engineering leaves it up to another department

such as production or manufacturing engineering to developthe technical documentation required for the production work-ers This is an unnecessary duplication of effort and is a nonndashvalue-added task that takes time

An objective of the CE approach is to accommodate DFPby bringing all the necessary people together right from dayone on a project

The time to influence the cost of a product is during theearly stages After the design has been developed in conceptmost of the opportunity to positively affect cost is gone

World-class ship designers know how their shipyardbuilds ships and design accordingly Many ship designers donot consider this and the designs may or may not be efficientlybuilt in their facilities More shipbuilders have taken steps toremedy this situation through the use of the build strategyapproach

Engineering should be prepared and transmitted to theusers in a way that best suits block construction advanced andzone outfitting

An object-oriented approach was adopted for the constructionof the model (Fig 16) The model represents shipyards worksta-tions products equipment processes manufacturing processesmaterial handling processes and interim products The tool wasapplied to the evaluation of two design alternatives for the bottomstructure of a ship The authors demonstrated that the tool enabledreliable evaluations of the man-hours for manufacturing and ma-terial handling such that the best design alternative could beadopted

Future directions

It is believed that the ship STEP APs will become the standardunit of shipbuilding data but that it will probably be an evolution-ary process as advances in technology and modeling capabilitiesand requirements are incorporated It is however crucial that thedevelopment of the standards comes to a timely consensus at eachevolutionary stage The literature reviewed has discussed the useof ldquointelligentrdquo data the inclusion of useful functionality accord-ing to the data type and of behavioral aspects It is anticipated thatthis functionality behavioral aspects and so forth will increas-

Fig 15 Ship design workflow using three-dimensional product model (Baum amp Ramakrishnan 1997)

ingly become part of the model to the extent that the model nolonger has any need for interfaces and translators to legacy soft-ware For example the piping model would automatically calcu-late interferences and the structures model would automaticallycalculate stress characteristics The simulation would essentiallybe part of the model and the model would contain additionalinformation and knowledge to effectively manage the simulationThis is not to say that the model would become a monolithicsystem despite such a system being potentially computationallyviable in 10 years Rather than being monolithic current andfuture distributed information technologies such as EnterpriseJava Beans may be utilized in order to distribute the model acrossa network while giving the impression to the user that the systemis monolithic Ship product data and functionality would be dis-tributed either within a single company or as partnerships withother companies

In a similar way that the ship product data has become stan-dardized benefits are to be gained from standardizing the inter-faces between applications to support the flow of standardizeddata and achieve a truly seamless integration The unfortunateshortcoming of application standardization is the necessity to re-develop the legacy systems to support this level of integration

The VRShips project addresses the management of ship productdata within a neutrally formatted common model The geometry

data contained within the common model are based on STEPAP203 are described using XML and are considered as beingcommon data if two or more applications access it Integration isprovided between the legacy applications and the common modelvia ldquogeneric wrappersrdquo that provide the general management re-quired in order to operate the applications The wrappers convertthe data to and from the native format using modular conversionalgorithms that can be plugged into the wrappers and provide thedomain-specific management for the applications Data are auto-matically downloaded from the common model and converted intothe native format when the application is started When the appli-cation is complete the designer has the option of undertaking thereverse process to convert the data back into the neutral format andupload into the common model Despite being a complex processconverters have been produced for a number of design applica-tions such as Tribon and AVPro and have been demonstrated tooperate without the need for manual interaction However theissues relating to the lack of integration between tools and con-tinuous product models remain to be addressed

The VRShips system also has an additional management layerconsisting of a process controller and an inference engine that arejointly responsible for maintaining data consistency and versionconstraint and process management Visualizing of product datavia the legacy applications is managed through the exporting of

Fig 16 Object diagram for generic shipyard computer model (Lamb et al 2000)

the displays via a virtual interaction environment These controlmechanisms ensure that designers may modify the data containedwithin the common model from any location either organization-ally or geographically distributed with network access using anapplication that they are familiar with and that any changes madeto the product model are correctly propagated such that the dataremain consistent

Every product modeling tool and technique discussed withinthis review is common from the perspective that the data containedwithin the model are a ldquosnapshotrdquo of the actual design activity Forinstance a designer may download data from the ship productmodel for use within a general design package which may take aweek to design During this design period the data within theproduct model do not change until the designer decides that thedesign process is complete and the data are uploaded into theproduct model The product model therefore does not contain acontinuous representation of either the design work that is cur-rently being undertaken or the form that the data are in This posesa number of significant project management issues with respect toversion control consistency management and conflict resolutionespecially in the situation where the design process is being un-dertaken in a distributed manner as is increasingly becomingcommon

A paradigm shift in the techniques used to enable the distributeddesign of ships while enabling a continuous product model andfacilitating the management of conflicts and consistency would bethe adoption of a technology that is more often seen within thecomputer games industry Graphics servers are commonly usedwithin the games industry to enable the user to immerse them-selves within an environment and interact both with the environ-ment and with other users High-level graphical objects are com-municated between the server side and the client side rather thanusing structured files This technique bypasses the need to trans-late the communicated data into the client side format alleviatingunnecessary computation It also results in a model containedwithin the server and represented within the clients that is a con-tinuous depiction of what everyone is undertaking The ship prod-uct data would remain within the ship STEP formats Howeverthe description method would be the graphical object representa-tion that would also exhibit behavioral properties Within the ship-building context individual graphics servers would represent do-mains similar to those identified by Crawford et al (1999) Clientsconnecting to the servers would immediately get an up-to-dateview of that particular domain which would be consistent with theviews of all of the other clients The client software would operatein a manner similar to conventional design applications There isalso clearly a requirement for integration between the differentdomain servers to enable conflicts to be resolved across domainsSimulation servers would integrate all of the scenarios that wouldenable an evaluation of the performance within any particular lifephase There would still remain the need to provide an effectivemanagement of different versions as well as a high-level coordi-nation structure to manage conflicts constraints design goals andcollaboration among designers However the underlying frame-work would provide the basis on which to construct this Despitebeing a significant step-change compared with current practicethis future technique proposes a viable solution to the effectivemanagement of a ship product model that may be manipulated andoperated upon in a distributed manner

This type of architecture does however raise a number of

issues relating to partnerships between the shipbuilding industryand the shipbuilding software industry because the system wouldrepresent an amalgamation of existing design and simulation ap-plications into a number of domain-specific servers The intellec-tual property rights as well as the ownership of both the technol-ogy and the data contained would clearly need to be resolved Inaddition the system calls upon the need to implement a standardfor the communication of the graphical objects that is both secureand robust whereas the standard for the data may be ldquoflavoredrdquoand managed effectively within the system via the ability to dy-namically load classes

Just as many of the precommissioning life phases are currentlybeing modeled it is anticipated that the rather poorly supportedpostcommissioning life phases will be catered for The most sig-nificant difference between pre- and postcommissioning is that itwill be the ship product model in its entirety that will be consid-ered For example there currently appears to be a significantopportunity for the specialization of the immersion of an entireship product model into an artificial environment to determine theoperational performance both at virtual sea (modeling existingshipping lanes to determine sea-keeping characteristics) within avirtual port (modeling existing ports to determine cargo-handlingcharacteristics) within a virtual shipyard for recommissioning(modeling existing shipyards to determine recommissioning capa-bility) and within a virtual breakers yard for disposal (to deter-mine scrap value) Increased opportunity would therefore be madefor designing the ship to meet a more rigorous set of customer-specified life-phase requirements and would represent a signifi-cant commercial advantage

It is also interesting at this point to note that a number of thecited papers have stated the need to avoid a reliance on computerprogrammers which in order to maintain even the simplest ofproduct data modeling systems seems unachievable

Conclusions

From the increasing amount of literature and the papers re-viewed within this paper related to the ship product model theprimary focus is on developing a standard representation for thedata contained within the model Despite not having yet finalizedthe standards for all aspects of the ship the STEP APs go a longway toward achieving this It is almost inconceivable to considerthat an alternative could compete against such a massive thrusttoward ship data standardization A number of instances havearisen however when the APs have been adhered to with theresult that ldquoflavorsrdquo or minor changes to the standard have beenrequired in order to utilize the structured well-defined and stan-dardized data within the legacy applications The question there-fore arises as to whether there is a requirement to standardize thelegacy applications such that they adhere to the data standard toenable a modular plug-in approach to ship design and simulation

Behavioral aspects have been considered within a number of thecited papers to be an important addition to the data in order toprovide the designer with additional feedback with respect to theoperation of the design This behavior may however be betterrepresented as high-level rules within a standard that are used todefine the operation of the ship rather than in existing standardsin order to minimize its impact on applications that have no needfor such data

A number of the tools and techniques discussed have described

the use of the ship STEP formats as being a mechanism for inte-grating existing legacy applications with a common model of shipproduct data Considerable benefit would be obtained from pro-viding similar integration between applications to progress fromthe limitations of discrete design and simulation toward having aholistic approach

The design tasks that are undertaken as part of the ship designprocess may well take a considerable amount of time and wouldconventionally result in ldquosnapshotsrdquo of the design artifact coin-ciding with the designer uploading data into the common modelA number of future directions have been discussed which wouldindividually require considerable development in order to imple-ment but which represent possible solutions to issues relating to

Continuous rather than ldquosnapshotrdquo ship product models Integration between the ship product model and the design

and simulation applications as well as across applications Removal of information translation problems through the

use of high-level graphical objects that are consistent betweenservers and applications

A collaborative framework on which to develop versionconflict and consistency management

Acknowledgments

The review was undertaken as part of an investigation intocommon model techniques within the VRShips-ROPAX2000project The authors gratefully acknowledge the support given bythe European Commission Community Research 5th Frameworkprogram under the area of Competitive and Sustainable Growthwhich provided the grant (G3RD-CT-2001-00506) that enabledthis work to be undertaken

References

BAUM S J AND RAMAKRISHNAN R 1997 Applying 3D product modelingtechnology in shipbuilding Marine Technology 34 1 56ndash65

CATLEY D 1999 Prototype STEP data exchanges in ship initial design andprovision of an application programmer interface to TRIBON Proceedings10th International Conference on Computer Applications in ShipbuildingJune Cambridge MA

CRAWFORD A K HARRINGTON G AMES R M AND VAN ESELTINE RT 1999 Neutral format data exchanges between ship product models andanalysis interfaces Proceedings 10th International Conference on Com-puter Applications in Shipbuilding June Cambridge MA

ERIKSTAD S O AND FATHI D E 1999 Applying the STEP shipbuildingprotocols as a basis for integrating existing in-house ship design applica-tions Proceedings 10th International Conference on Computer Applica-tions in Shipbuilding June Cambridge MA

GISCHNER B KASSEL B LAZO P WOOD R AND WYMAN J 2001 Evolution of STEP (ESTEP) exchange of shipbuilding productmodel data JOURNAL OF SHIP PRODUCTION 17 3 151ndash160

GRAU M AND KOCH T 1999 Applying STEP technology to shipbuildingProceedings 10th International Conference on Computer Applications inShipbuilding June Cambridge MA

HERZOG E AND TOumlRNE A 1999 A seed for a STEP application protocolfor systems engineering Proceedings 12th International Conference andWorkshop on the Engineering of Computer Based Systems Institute ofElectrical and Electronics Engineers Press Piscataway NJ 174ndash180

HIGNEY J T AND OUILETTE J J 1994 An engineering product modelbased on STEP protocols JOURNAL OF SHIP PRODUCTION 10 4 281ndash286

ISO 1996 Product Data Representation and Exchange Part 218 Ship Struc-

tures International Standards Organization Hamburg GermanyJOHANSSON K 1995 The product model as a central information source in

a shipbuilding environment Proceedings National Shipbuilding ResearchProgram 1995 Ship Production Symposium June Seattle WA

LAMB T CHUNG H AND SHIN J G 2000 A generic shipyard computermodel a tool for design for production Proceedings 7th IMDC NovemberKyung-Ju Korea

MARTIN D J 1980 The shipyard product information system as an aid toimplementing more productive strategies Proceedings Research and Engi-neering for Automation and Productivity in Shipbuilding IIT Research In-stitute October Chicago IL 81ndash101

POLINI M A AND MELAND K E 1997 The development and implemen-tation of a SMART product model for ship structure Proceedings 9thInternational Conference on Computer Applications in Shipbuilding Octo-ber Yokohama Japan

RANDO T C AND FERNHOLZ D 2000 MARITECHrsquos shipbuilding infor-mation infrastructure JOURNAL OF SHIP PRODUCTION 16 2 110ndash120

RANDO T C 2001 XML-based interoperability in the integrated shipbuild-ing environment (ISE) JOURNAL OF SHIP PRODUCTION 17 2 69ndash75

ROSS J M AND GARCIA L 1998 Making the jump to product modeltechnology JOURNAL OF SHIP PRODUCTION 14 1 15ndash26

ROSS J M AND ABAL D 2001 Practical use of 3D product modeling inthe small shipyard JOURNAL OF SHIP PRODUCTION 17 1 27ndash34

SCHMIDT W R VANDER J R AND SHIELDS V R 1990 Modelling andtransfer of product model digital data for the DDG 51 class destroyer pro-gram Proceedings National Shipbuilding Research Program 1990 ShipProduction Symposium August Milwaukee WI

SHIN Y AND HAN S H 1998 Data enhancement for sharing of shipdesign models Computer-Aided Design 30 12 931ndash941

VON HAARTMAN J KUUTTI I AND SCHAUMAN C 1994 Improving designproductivity with a product model for initial ship design Proceedings 8thInternational Conference on Computer Applications in Shipbuilding Sep-tember Bremen Germany

WELSH M LYNCH J AND BRUN B 1992 A data model for integration ofthe precommissioning life-cycle stages of the shipbuildingproduct JOURNAL

OF SHIP PRODUCTION 8 4 220ndash234WHITFIELD R I COATE S G DUFFY A H B AND HILLS

W 2000 Coordination approaches and systemsmdashpart I a strategic per-spective Research in Engineering Design 12 73ndash89

WYMAN J WOOLEY D GISCHNER B AND HOWELL J 1997 Development of STEP ship model database and translators fordata exchange between shipyards JOURNAL OF SHIP PRODUCTION 13 2111ndash124

Internet addresses

European Marine STEP Association httpemsagermanlloydorg

ISO STEP ship team http wwwnsnetcomNIDDESCt23html

Japan Marine Standards Association http wwwjecalsjipdecorjp

Korea STEP Centre httpksteporkr

The information technology staffs at most shipyards areexperts in shipbuilding process requirements but not in system-level computer technologies

Shipyard information systems must be reliable and main-tainable yet often need to be customized to suit an individualshipyard

As with many other projects (Rando 2001 Gischner et al 2001)integration within the shipbuilding industry was considered pos-sible only by the reuse of existing software components becausethe number of shipbuilding system requirements is so diverse thatit is unrealistic to assume that it is possible to produce a singleoverarching solution The integrated system was considered toconsist of a number of independent components to be assembledand reused by third parties in order to create a new complexsystem The initial task of the SHIIP project was to define areference architecture to support the composition of the indepen-dent components

The management of the product data was achieved using En-terprise Java Beans (EJB) that enable persistent storage secureaccess and load balancing for multiple users wishing to access thedata simultaneously At the start of the SHIIP project however

EJB was not available and the project relied instead on CORBAtechnology The project learned the following lessons from usingCORBA

Technology independence although useful in theoryshould not be pursued at the expense of developing workingimplementations

Technical interoperability is not a requirement for the de-velopment of an industrial information infrastructure Support-ing applications and software components for the informationinfrastructure are homogeneous enough to be implemented in asingle implementation technology

The Object Management Group (OMG) while advocatingseparation of components has produced in the arena of do-main standards wrappers for monolithic applications

OMG has been hampered by the inability to reach timelyconsensus

The Integrated Shipbuilding Environment (ISE) project withinthe Maritech Advanced Shipbuilding Enterprise (ASE) is usingXML as the basis for achieving interoperability between ship-building systems technologies specifically between application toapplication (Rando 2001) Rando differentiates this problem fromthat of other industries by stating that many of the applicationcomponents used within the shipbuilding industry have alreadybeen developed as well as the having little control over the de-velopment of these systems The shipbuilding product model mayalso contain millions of instances of a large number of differenttypes of information that need to be managed as they evolve overthe productrsquos life cycle It is also suggested that not only is therea need to rely on an enterprise system that augments the manyspecialist applications but due to the diversity of informationwithin the life cycle of the ship no single information system issufficient to deal with the entire ship product Indeed previousalliances between shipyards have been one-off solutions and thereis a definite requirement for a standardized effort for the shipproduct model

Rando identified a number of business drivers in order toachieve interoperability within the shipbuilding industry and pro-

Fig 13 Domain-based ship system (Crawford et al 1999)

Fig 14 ISE reference architecture three levels of interoperability (Rando 2001)

posed an architecture in order to respond to these drivers (Fig 14)The architecture represents three interoperability levels within theshipbuilding environment intercomponent refers to the interac-tions between the software components within a system intersys-tem refers to the interactions between the systems and is boundedby a business system domain and interenterprise interoperabilityrefers to interactions between business systems domains at differ-ent shipyards and organizations

The key elements for achieving this interoperability were acommon syntax using XML to facilitate communication a sharedstandard information model using STEP and an interoperabilityinfrastructure using web-based technologies XML is a neutralformat that may be viewed by humans (although this is not gen-erally a primary requirement) and that enables the sharing of in-formation between different technologies different operating sys-tems and different programming languages Five keyrequirements were identif ied to facilitate application-to-application integration

Should ldquoreuserdquo widely available standards-based tools Should be implementable with tools that allow for recon-

figuration by nonprogrammers Should support transformation to and from a canonical or

neutral format Should utilize a representation that is as simple and con-

cise as possible Should be able to marshalunmarshal every semantic con-

cept representable in the EXPRESS information modeling lan-guage (ISO 10303-11)

One of the most significant issues relating to the use and inte-gration of ship product models with existing applications appearsto be the need to ldquoflavorrdquo the model and specifications to suit theparticular requirements of the design and simulation applicationsWithout these embellishments the fully automated data integra-tion appears quite often difficult to achieve There are howeverconflicting opinions regarding the effectiveness of automating thisprocess generally arising due to the complexity of the problem andthe level of support The application of ldquoflavoredrdquo standards doeshowever entirely go against the point of creating a standard es-pecially when it is with respect to the transfer of product data Itcould therefore be concluded that the solution to the effectiveintegration of STEP lies not in the modification of a new tech-nology to satisfy the requirements of legacy applications but inthe updating of the legacy applications to satisfy the new technol-ogy

Life-cycle issues

The NEUTRABAS project (Welsh et al 1992) was limited tothe precommissioning stages that is marketing conceptual de-sign detailed design drafting materials ordering productionplanning and control scheduling and quality control However itwas recognized that significant benefits would be achievedthrough extending the life cycle through to disposal Welsh et alqualified the limitation to the precommissioning stages by statingthat ldquothe definition and implementation of a complete product datamodel covering all of these aspects of the life-cycle of an engi-neering product as complex as a ship is an onerous task and one

which would require the commitment of a vast amount of time andeffortrdquo

Limiting the project to the precommissioning stages would ap-pear to have been a wise judgment because in the 10 years fol-lowing this project the standards created to describe the shipproduct model have still not yet been finalized

Welsh et al suggest that the physical representation of the prod-uct within each life cycle stage would ldquonormally be unchanged inthe global sense although the information associated with theproduct and the techniques used to represent it will vary consid-erablyrdquo that is the information contained within the productmodel would mature as more detail becomes available as well asrequiring different viewpoints at each life-cycle stage The productmodel must therefore be developed not only with the associateddata and structure in mind but also with the life-cycle stages Toenable the support of the precommissioning life-cycle stagesWelsh et al identified four views that need to be supported by theship product model

Marketing-oriented view Management-oriented view Design-oriented view Production-oriented view

Von Haartman et al (1994) briefly discussed life phase issues ofthe ship product model and suggested that a number of systemsmodel the design with too much detail and hence are not appli-cable to the concept design stage A solution to this was thedevelopment of a concept design product model that could then betransferred to the detailed design stage It is not clear from thiswhether Von Haartman et al were proposing separate models forthe two stages or if the detail product model would simply consistof the concept product model plus the additional required detail

The mechanism of having multiple different views for the shar-ing of a product model among designers and production engineersfor example has been considered and implemented in a number ofcases (Polini amp Meland 1997 Johansson 1995) Johansson indi-cated that it is common for parts of the product to be in differentlife-cycle stages at the same time that is the ldquomanufacture of onepart of the product is going on at the same time as the detaileddesign of anotherrdquo This is one aspect of concurrent engineeringwith the result of reducing the lead times because the manufactureof the product has started before the design of the product has beencompleted However it is necessary to ensure both that manufac-turing starts only on parts that require no further design and thatother parts that are currently being designed do not propagatechanges to the manufactured parts The management and controlof the information flow were recognized as being the key elementsin increasing the overlapping of life cycles However no expla-nation was given by Johansson regarding the nature of the man-agement other than through the relationships between the objectscontained within the model These relationships were described asa mechanism to enable both interdisciplinary and cross-disciplinary communication among designers

The three-dimensional product model was described by Baumand Ramakrishnan (1997) as being a mechanism to enable a num-ber of different life-cycle stage simulations such as interferencechecking crew traffic flow studies yard-specific designs and fi-nite capacity scheduling through the use of a virtual environmentdesign review technology using data contained within the productmodel (Fig 15)

Coupled with simulation-based design (SBD) Baum describedthe combined technology as ldquothe new frontierrdquo that would enablethe virtual prototyping of the ship which previously could not beachieved due to the cost and complexity More importantly Baumrecognized that just as interference-checking software may beused to determine discrepancies between geometric parts duringthe design and production phases SBD may be used to reduce oreliminate design errors that would have previously have beendiscovered years later in the operational stage for example Es-sentially SBD and product modeling enable the validation of thedesign production and operation stages of the ship product

Baum also finally suggested that the product model provides asignificant benefit to the owneroperator by enabling the analysisand support of life-cycle maintenance

A generic shipyard computer modeling tool for evaluating de-sign for production (DFP) is discussed by Lamb et al (2000) Thetool enables shipyards to be modeled such that the impacts ofchanges to the ship design may be determined on the basis of theresulting material manpower and schedule The shipyard modelrepresents details of the buildingsmdashtheir arrangement and size aswell as equipment capacity and flow The tool also enables aninvestigation of the necessary changes required for a shipyard inorder to produce a new design The key foundations in order toevaluate these impacts are the interim product catalogue and thebuild strategy approach

Lamb et al identified a number of important concepts for DFP

All designs should be prepared to suit a shipyardrsquos facili-ties and preferred production methods

DFP takes into account production methods and tech-niques that reduce the product work content but still meet thespecified design requirements and quality

DFP must be incorporated into a design from the start Traditional engineering leaves it up to another department

such as production or manufacturing engineering to developthe technical documentation required for the production work-ers This is an unnecessary duplication of effort and is a nonndashvalue-added task that takes time

An objective of the CE approach is to accommodate DFPby bringing all the necessary people together right from dayone on a project

The time to influence the cost of a product is during theearly stages After the design has been developed in conceptmost of the opportunity to positively affect cost is gone

World-class ship designers know how their shipyardbuilds ships and design accordingly Many ship designers donot consider this and the designs may or may not be efficientlybuilt in their facilities More shipbuilders have taken steps toremedy this situation through the use of the build strategyapproach

Engineering should be prepared and transmitted to theusers in a way that best suits block construction advanced andzone outfitting

An object-oriented approach was adopted for the constructionof the model (Fig 16) The model represents shipyards worksta-tions products equipment processes manufacturing processesmaterial handling processes and interim products The tool wasapplied to the evaluation of two design alternatives for the bottomstructure of a ship The authors demonstrated that the tool enabledreliable evaluations of the man-hours for manufacturing and ma-terial handling such that the best design alternative could beadopted

Future directions

It is believed that the ship STEP APs will become the standardunit of shipbuilding data but that it will probably be an evolution-ary process as advances in technology and modeling capabilitiesand requirements are incorporated It is however crucial that thedevelopment of the standards comes to a timely consensus at eachevolutionary stage The literature reviewed has discussed the useof ldquointelligentrdquo data the inclusion of useful functionality accord-ing to the data type and of behavioral aspects It is anticipated thatthis functionality behavioral aspects and so forth will increas-

Fig 15 Ship design workflow using three-dimensional product model (Baum amp Ramakrishnan 1997)

ingly become part of the model to the extent that the model nolonger has any need for interfaces and translators to legacy soft-ware For example the piping model would automatically calcu-late interferences and the structures model would automaticallycalculate stress characteristics The simulation would essentiallybe part of the model and the model would contain additionalinformation and knowledge to effectively manage the simulationThis is not to say that the model would become a monolithicsystem despite such a system being potentially computationallyviable in 10 years Rather than being monolithic current andfuture distributed information technologies such as EnterpriseJava Beans may be utilized in order to distribute the model acrossa network while giving the impression to the user that the systemis monolithic Ship product data and functionality would be dis-tributed either within a single company or as partnerships withother companies

In a similar way that the ship product data has become stan-dardized benefits are to be gained from standardizing the inter-faces between applications to support the flow of standardizeddata and achieve a truly seamless integration The unfortunateshortcoming of application standardization is the necessity to re-develop the legacy systems to support this level of integration

The VRShips project addresses the management of ship productdata within a neutrally formatted common model The geometry

data contained within the common model are based on STEPAP203 are described using XML and are considered as beingcommon data if two or more applications access it Integration isprovided between the legacy applications and the common modelvia ldquogeneric wrappersrdquo that provide the general management re-quired in order to operate the applications The wrappers convertthe data to and from the native format using modular conversionalgorithms that can be plugged into the wrappers and provide thedomain-specific management for the applications Data are auto-matically downloaded from the common model and converted intothe native format when the application is started When the appli-cation is complete the designer has the option of undertaking thereverse process to convert the data back into the neutral format andupload into the common model Despite being a complex processconverters have been produced for a number of design applica-tions such as Tribon and AVPro and have been demonstrated tooperate without the need for manual interaction However theissues relating to the lack of integration between tools and con-tinuous product models remain to be addressed

The VRShips system also has an additional management layerconsisting of a process controller and an inference engine that arejointly responsible for maintaining data consistency and versionconstraint and process management Visualizing of product datavia the legacy applications is managed through the exporting of

Fig 16 Object diagram for generic shipyard computer model (Lamb et al 2000)

the displays via a virtual interaction environment These controlmechanisms ensure that designers may modify the data containedwithin the common model from any location either organization-ally or geographically distributed with network access using anapplication that they are familiar with and that any changes madeto the product model are correctly propagated such that the dataremain consistent

Every product modeling tool and technique discussed withinthis review is common from the perspective that the data containedwithin the model are a ldquosnapshotrdquo of the actual design activity Forinstance a designer may download data from the ship productmodel for use within a general design package which may take aweek to design During this design period the data within theproduct model do not change until the designer decides that thedesign process is complete and the data are uploaded into theproduct model The product model therefore does not contain acontinuous representation of either the design work that is cur-rently being undertaken or the form that the data are in This posesa number of significant project management issues with respect toversion control consistency management and conflict resolutionespecially in the situation where the design process is being un-dertaken in a distributed manner as is increasingly becomingcommon

A paradigm shift in the techniques used to enable the distributeddesign of ships while enabling a continuous product model andfacilitating the management of conflicts and consistency would bethe adoption of a technology that is more often seen within thecomputer games industry Graphics servers are commonly usedwithin the games industry to enable the user to immerse them-selves within an environment and interact both with the environ-ment and with other users High-level graphical objects are com-municated between the server side and the client side rather thanusing structured files This technique bypasses the need to trans-late the communicated data into the client side format alleviatingunnecessary computation It also results in a model containedwithin the server and represented within the clients that is a con-tinuous depiction of what everyone is undertaking The ship prod-uct data would remain within the ship STEP formats Howeverthe description method would be the graphical object representa-tion that would also exhibit behavioral properties Within the ship-building context individual graphics servers would represent do-mains similar to those identified by Crawford et al (1999) Clientsconnecting to the servers would immediately get an up-to-dateview of that particular domain which would be consistent with theviews of all of the other clients The client software would operatein a manner similar to conventional design applications There isalso clearly a requirement for integration between the differentdomain servers to enable conflicts to be resolved across domainsSimulation servers would integrate all of the scenarios that wouldenable an evaluation of the performance within any particular lifephase There would still remain the need to provide an effectivemanagement of different versions as well as a high-level coordi-nation structure to manage conflicts constraints design goals andcollaboration among designers However the underlying frame-work would provide the basis on which to construct this Despitebeing a significant step-change compared with current practicethis future technique proposes a viable solution to the effectivemanagement of a ship product model that may be manipulated andoperated upon in a distributed manner

This type of architecture does however raise a number of

issues relating to partnerships between the shipbuilding industryand the shipbuilding software industry because the system wouldrepresent an amalgamation of existing design and simulation ap-plications into a number of domain-specific servers The intellec-tual property rights as well as the ownership of both the technol-ogy and the data contained would clearly need to be resolved Inaddition the system calls upon the need to implement a standardfor the communication of the graphical objects that is both secureand robust whereas the standard for the data may be ldquoflavoredrdquoand managed effectively within the system via the ability to dy-namically load classes

Just as many of the precommissioning life phases are currentlybeing modeled it is anticipated that the rather poorly supportedpostcommissioning life phases will be catered for The most sig-nificant difference between pre- and postcommissioning is that itwill be the ship product model in its entirety that will be consid-ered For example there currently appears to be a significantopportunity for the specialization of the immersion of an entireship product model into an artificial environment to determine theoperational performance both at virtual sea (modeling existingshipping lanes to determine sea-keeping characteristics) within avirtual port (modeling existing ports to determine cargo-handlingcharacteristics) within a virtual shipyard for recommissioning(modeling existing shipyards to determine recommissioning capa-bility) and within a virtual breakers yard for disposal (to deter-mine scrap value) Increased opportunity would therefore be madefor designing the ship to meet a more rigorous set of customer-specified life-phase requirements and would represent a signifi-cant commercial advantage

It is also interesting at this point to note that a number of thecited papers have stated the need to avoid a reliance on computerprogrammers which in order to maintain even the simplest ofproduct data modeling systems seems unachievable

Conclusions

From the increasing amount of literature and the papers re-viewed within this paper related to the ship product model theprimary focus is on developing a standard representation for thedata contained within the model Despite not having yet finalizedthe standards for all aspects of the ship the STEP APs go a longway toward achieving this It is almost inconceivable to considerthat an alternative could compete against such a massive thrusttoward ship data standardization A number of instances havearisen however when the APs have been adhered to with theresult that ldquoflavorsrdquo or minor changes to the standard have beenrequired in order to utilize the structured well-defined and stan-dardized data within the legacy applications The question there-fore arises as to whether there is a requirement to standardize thelegacy applications such that they adhere to the data standard toenable a modular plug-in approach to ship design and simulation

Behavioral aspects have been considered within a number of thecited papers to be an important addition to the data in order toprovide the designer with additional feedback with respect to theoperation of the design This behavior may however be betterrepresented as high-level rules within a standard that are used todefine the operation of the ship rather than in existing standardsin order to minimize its impact on applications that have no needfor such data

A number of the tools and techniques discussed have described

the use of the ship STEP formats as being a mechanism for inte-grating existing legacy applications with a common model of shipproduct data Considerable benefit would be obtained from pro-viding similar integration between applications to progress fromthe limitations of discrete design and simulation toward having aholistic approach

The design tasks that are undertaken as part of the ship designprocess may well take a considerable amount of time and wouldconventionally result in ldquosnapshotsrdquo of the design artifact coin-ciding with the designer uploading data into the common modelA number of future directions have been discussed which wouldindividually require considerable development in order to imple-ment but which represent possible solutions to issues relating to

Continuous rather than ldquosnapshotrdquo ship product models Integration between the ship product model and the design

and simulation applications as well as across applications Removal of information translation problems through the

use of high-level graphical objects that are consistent betweenservers and applications

A collaborative framework on which to develop versionconflict and consistency management

Acknowledgments

The review was undertaken as part of an investigation intocommon model techniques within the VRShips-ROPAX2000project The authors gratefully acknowledge the support given bythe European Commission Community Research 5th Frameworkprogram under the area of Competitive and Sustainable Growthwhich provided the grant (G3RD-CT-2001-00506) that enabledthis work to be undertaken

References

BAUM S J AND RAMAKRISHNAN R 1997 Applying 3D product modelingtechnology in shipbuilding Marine Technology 34 1 56ndash65

CATLEY D 1999 Prototype STEP data exchanges in ship initial design andprovision of an application programmer interface to TRIBON Proceedings10th International Conference on Computer Applications in ShipbuildingJune Cambridge MA

CRAWFORD A K HARRINGTON G AMES R M AND VAN ESELTINE RT 1999 Neutral format data exchanges between ship product models andanalysis interfaces Proceedings 10th International Conference on Com-puter Applications in Shipbuilding June Cambridge MA

ERIKSTAD S O AND FATHI D E 1999 Applying the STEP shipbuildingprotocols as a basis for integrating existing in-house ship design applica-tions Proceedings 10th International Conference on Computer Applica-tions in Shipbuilding June Cambridge MA

GISCHNER B KASSEL B LAZO P WOOD R AND WYMAN J 2001 Evolution of STEP (ESTEP) exchange of shipbuilding productmodel data JOURNAL OF SHIP PRODUCTION 17 3 151ndash160

GRAU M AND KOCH T 1999 Applying STEP technology to shipbuildingProceedings 10th International Conference on Computer Applications inShipbuilding June Cambridge MA

HERZOG E AND TOumlRNE A 1999 A seed for a STEP application protocolfor systems engineering Proceedings 12th International Conference andWorkshop on the Engineering of Computer Based Systems Institute ofElectrical and Electronics Engineers Press Piscataway NJ 174ndash180

HIGNEY J T AND OUILETTE J J 1994 An engineering product modelbased on STEP protocols JOURNAL OF SHIP PRODUCTION 10 4 281ndash286

ISO 1996 Product Data Representation and Exchange Part 218 Ship Struc-

tures International Standards Organization Hamburg GermanyJOHANSSON K 1995 The product model as a central information source in

a shipbuilding environment Proceedings National Shipbuilding ResearchProgram 1995 Ship Production Symposium June Seattle WA

LAMB T CHUNG H AND SHIN J G 2000 A generic shipyard computermodel a tool for design for production Proceedings 7th IMDC NovemberKyung-Ju Korea

MARTIN D J 1980 The shipyard product information system as an aid toimplementing more productive strategies Proceedings Research and Engi-neering for Automation and Productivity in Shipbuilding IIT Research In-stitute October Chicago IL 81ndash101

POLINI M A AND MELAND K E 1997 The development and implemen-tation of a SMART product model for ship structure Proceedings 9thInternational Conference on Computer Applications in Shipbuilding Octo-ber Yokohama Japan

RANDO T C AND FERNHOLZ D 2000 MARITECHrsquos shipbuilding infor-mation infrastructure JOURNAL OF SHIP PRODUCTION 16 2 110ndash120

RANDO T C 2001 XML-based interoperability in the integrated shipbuild-ing environment (ISE) JOURNAL OF SHIP PRODUCTION 17 2 69ndash75

ROSS J M AND GARCIA L 1998 Making the jump to product modeltechnology JOURNAL OF SHIP PRODUCTION 14 1 15ndash26

ROSS J M AND ABAL D 2001 Practical use of 3D product modeling inthe small shipyard JOURNAL OF SHIP PRODUCTION 17 1 27ndash34

SCHMIDT W R VANDER J R AND SHIELDS V R 1990 Modelling andtransfer of product model digital data for the DDG 51 class destroyer pro-gram Proceedings National Shipbuilding Research Program 1990 ShipProduction Symposium August Milwaukee WI

SHIN Y AND HAN S H 1998 Data enhancement for sharing of shipdesign models Computer-Aided Design 30 12 931ndash941

VON HAARTMAN J KUUTTI I AND SCHAUMAN C 1994 Improving designproductivity with a product model for initial ship design Proceedings 8thInternational Conference on Computer Applications in Shipbuilding Sep-tember Bremen Germany

WELSH M LYNCH J AND BRUN B 1992 A data model for integration ofthe precommissioning life-cycle stages of the shipbuildingproduct JOURNAL

OF SHIP PRODUCTION 8 4 220ndash234WHITFIELD R I COATE S G DUFFY A H B AND HILLS

W 2000 Coordination approaches and systemsmdashpart I a strategic per-spective Research in Engineering Design 12 73ndash89

WYMAN J WOOLEY D GISCHNER B AND HOWELL J 1997 Development of STEP ship model database and translators fordata exchange between shipyards JOURNAL OF SHIP PRODUCTION 13 2111ndash124

Internet addresses

European Marine STEP Association httpemsagermanlloydorg

ISO STEP ship team http wwwnsnetcomNIDDESCt23html

Japan Marine Standards Association http wwwjecalsjipdecorjp

Korea STEP Centre httpksteporkr

posed an architecture in order to respond to these drivers (Fig 14)The architecture represents three interoperability levels within theshipbuilding environment intercomponent refers to the interac-tions between the software components within a system intersys-tem refers to the interactions between the systems and is boundedby a business system domain and interenterprise interoperabilityrefers to interactions between business systems domains at differ-ent shipyards and organizations

The key elements for achieving this interoperability were acommon syntax using XML to facilitate communication a sharedstandard information model using STEP and an interoperabilityinfrastructure using web-based technologies XML is a neutralformat that may be viewed by humans (although this is not gen-erally a primary requirement) and that enables the sharing of in-formation between different technologies different operating sys-tems and different programming languages Five keyrequirements were identif ied to facilitate application-to-application integration

Should ldquoreuserdquo widely available standards-based tools Should be implementable with tools that allow for recon-

figuration by nonprogrammers Should support transformation to and from a canonical or

neutral format Should utilize a representation that is as simple and con-

cise as possible Should be able to marshalunmarshal every semantic con-

cept representable in the EXPRESS information modeling lan-guage (ISO 10303-11)

One of the most significant issues relating to the use and inte-gration of ship product models with existing applications appearsto be the need to ldquoflavorrdquo the model and specifications to suit theparticular requirements of the design and simulation applicationsWithout these embellishments the fully automated data integra-tion appears quite often difficult to achieve There are howeverconflicting opinions regarding the effectiveness of automating thisprocess generally arising due to the complexity of the problem andthe level of support The application of ldquoflavoredrdquo standards doeshowever entirely go against the point of creating a standard es-pecially when it is with respect to the transfer of product data Itcould therefore be concluded that the solution to the effectiveintegration of STEP lies not in the modification of a new tech-nology to satisfy the requirements of legacy applications but inthe updating of the legacy applications to satisfy the new technol-ogy

Life-cycle issues

The NEUTRABAS project (Welsh et al 1992) was limited tothe precommissioning stages that is marketing conceptual de-sign detailed design drafting materials ordering productionplanning and control scheduling and quality control However itwas recognized that significant benefits would be achievedthrough extending the life cycle through to disposal Welsh et alqualified the limitation to the precommissioning stages by statingthat ldquothe definition and implementation of a complete product datamodel covering all of these aspects of the life-cycle of an engi-neering product as complex as a ship is an onerous task and one

which would require the commitment of a vast amount of time andeffortrdquo

Limiting the project to the precommissioning stages would ap-pear to have been a wise judgment because in the 10 years fol-lowing this project the standards created to describe the shipproduct model have still not yet been finalized

Welsh et al suggest that the physical representation of the prod-uct within each life cycle stage would ldquonormally be unchanged inthe global sense although the information associated with theproduct and the techniques used to represent it will vary consid-erablyrdquo that is the information contained within the productmodel would mature as more detail becomes available as well asrequiring different viewpoints at each life-cycle stage The productmodel must therefore be developed not only with the associateddata and structure in mind but also with the life-cycle stages Toenable the support of the precommissioning life-cycle stagesWelsh et al identified four views that need to be supported by theship product model

Marketing-oriented view Management-oriented view Design-oriented view Production-oriented view

Von Haartman et al (1994) briefly discussed life phase issues ofthe ship product model and suggested that a number of systemsmodel the design with too much detail and hence are not appli-cable to the concept design stage A solution to this was thedevelopment of a concept design product model that could then betransferred to the detailed design stage It is not clear from thiswhether Von Haartman et al were proposing separate models forthe two stages or if the detail product model would simply consistof the concept product model plus the additional required detail

The mechanism of having multiple different views for the shar-ing of a product model among designers and production engineersfor example has been considered and implemented in a number ofcases (Polini amp Meland 1997 Johansson 1995) Johansson indi-cated that it is common for parts of the product to be in differentlife-cycle stages at the same time that is the ldquomanufacture of onepart of the product is going on at the same time as the detaileddesign of anotherrdquo This is one aspect of concurrent engineeringwith the result of reducing the lead times because the manufactureof the product has started before the design of the product has beencompleted However it is necessary to ensure both that manufac-turing starts only on parts that require no further design and thatother parts that are currently being designed do not propagatechanges to the manufactured parts The management and controlof the information flow were recognized as being the key elementsin increasing the overlapping of life cycles However no expla-nation was given by Johansson regarding the nature of the man-agement other than through the relationships between the objectscontained within the model These relationships were described asa mechanism to enable both interdisciplinary and cross-disciplinary communication among designers

The three-dimensional product model was described by Baumand Ramakrishnan (1997) as being a mechanism to enable a num-ber of different life-cycle stage simulations such as interferencechecking crew traffic flow studies yard-specific designs and fi-nite capacity scheduling through the use of a virtual environmentdesign review technology using data contained within the productmodel (Fig 15)

Coupled with simulation-based design (SBD) Baum describedthe combined technology as ldquothe new frontierrdquo that would enablethe virtual prototyping of the ship which previously could not beachieved due to the cost and complexity More importantly Baumrecognized that just as interference-checking software may beused to determine discrepancies between geometric parts duringthe design and production phases SBD may be used to reduce oreliminate design errors that would have previously have beendiscovered years later in the operational stage for example Es-sentially SBD and product modeling enable the validation of thedesign production and operation stages of the ship product

Baum also finally suggested that the product model provides asignificant benefit to the owneroperator by enabling the analysisand support of life-cycle maintenance

A generic shipyard computer modeling tool for evaluating de-sign for production (DFP) is discussed by Lamb et al (2000) Thetool enables shipyards to be modeled such that the impacts ofchanges to the ship design may be determined on the basis of theresulting material manpower and schedule The shipyard modelrepresents details of the buildingsmdashtheir arrangement and size aswell as equipment capacity and flow The tool also enables aninvestigation of the necessary changes required for a shipyard inorder to produce a new design The key foundations in order toevaluate these impacts are the interim product catalogue and thebuild strategy approach

Lamb et al identified a number of important concepts for DFP

All designs should be prepared to suit a shipyardrsquos facili-ties and preferred production methods

DFP takes into account production methods and tech-niques that reduce the product work content but still meet thespecified design requirements and quality

DFP must be incorporated into a design from the start Traditional engineering leaves it up to another department

such as production or manufacturing engineering to developthe technical documentation required for the production work-ers This is an unnecessary duplication of effort and is a nonndashvalue-added task that takes time

An objective of the CE approach is to accommodate DFPby bringing all the necessary people together right from dayone on a project

The time to influence the cost of a product is during theearly stages After the design has been developed in conceptmost of the opportunity to positively affect cost is gone

World-class ship designers know how their shipyardbuilds ships and design accordingly Many ship designers donot consider this and the designs may or may not be efficientlybuilt in their facilities More shipbuilders have taken steps toremedy this situation through the use of the build strategyapproach

Engineering should be prepared and transmitted to theusers in a way that best suits block construction advanced andzone outfitting

An object-oriented approach was adopted for the constructionof the model (Fig 16) The model represents shipyards worksta-tions products equipment processes manufacturing processesmaterial handling processes and interim products The tool wasapplied to the evaluation of two design alternatives for the bottomstructure of a ship The authors demonstrated that the tool enabledreliable evaluations of the man-hours for manufacturing and ma-terial handling such that the best design alternative could beadopted

Future directions

It is believed that the ship STEP APs will become the standardunit of shipbuilding data but that it will probably be an evolution-ary process as advances in technology and modeling capabilitiesand requirements are incorporated It is however crucial that thedevelopment of the standards comes to a timely consensus at eachevolutionary stage The literature reviewed has discussed the useof ldquointelligentrdquo data the inclusion of useful functionality accord-ing to the data type and of behavioral aspects It is anticipated thatthis functionality behavioral aspects and so forth will increas-

Fig 15 Ship design workflow using three-dimensional product model (Baum amp Ramakrishnan 1997)

ingly become part of the model to the extent that the model nolonger has any need for interfaces and translators to legacy soft-ware For example the piping model would automatically calcu-late interferences and the structures model would automaticallycalculate stress characteristics The simulation would essentiallybe part of the model and the model would contain additionalinformation and knowledge to effectively manage the simulationThis is not to say that the model would become a monolithicsystem despite such a system being potentially computationallyviable in 10 years Rather than being monolithic current andfuture distributed information technologies such as EnterpriseJava Beans may be utilized in order to distribute the model acrossa network while giving the impression to the user that the systemis monolithic Ship product data and functionality would be dis-tributed either within a single company or as partnerships withother companies

In a similar way that the ship product data has become stan-dardized benefits are to be gained from standardizing the inter-faces between applications to support the flow of standardizeddata and achieve a truly seamless integration The unfortunateshortcoming of application standardization is the necessity to re-develop the legacy systems to support this level of integration

The VRShips project addresses the management of ship productdata within a neutrally formatted common model The geometry

data contained within the common model are based on STEPAP203 are described using XML and are considered as beingcommon data if two or more applications access it Integration isprovided between the legacy applications and the common modelvia ldquogeneric wrappersrdquo that provide the general management re-quired in order to operate the applications The wrappers convertthe data to and from the native format using modular conversionalgorithms that can be plugged into the wrappers and provide thedomain-specific management for the applications Data are auto-matically downloaded from the common model and converted intothe native format when the application is started When the appli-cation is complete the designer has the option of undertaking thereverse process to convert the data back into the neutral format andupload into the common model Despite being a complex processconverters have been produced for a number of design applica-tions such as Tribon and AVPro and have been demonstrated tooperate without the need for manual interaction However theissues relating to the lack of integration between tools and con-tinuous product models remain to be addressed

The VRShips system also has an additional management layerconsisting of a process controller and an inference engine that arejointly responsible for maintaining data consistency and versionconstraint and process management Visualizing of product datavia the legacy applications is managed through the exporting of

Fig 16 Object diagram for generic shipyard computer model (Lamb et al 2000)

the displays via a virtual interaction environment These controlmechanisms ensure that designers may modify the data containedwithin the common model from any location either organization-ally or geographically distributed with network access using anapplication that they are familiar with and that any changes madeto the product model are correctly propagated such that the dataremain consistent

Every product modeling tool and technique discussed withinthis review is common from the perspective that the data containedwithin the model are a ldquosnapshotrdquo of the actual design activity Forinstance a designer may download data from the ship productmodel for use within a general design package which may take aweek to design During this design period the data within theproduct model do not change until the designer decides that thedesign process is complete and the data are uploaded into theproduct model The product model therefore does not contain acontinuous representation of either the design work that is cur-rently being undertaken or the form that the data are in This posesa number of significant project management issues with respect toversion control consistency management and conflict resolutionespecially in the situation where the design process is being un-dertaken in a distributed manner as is increasingly becomingcommon

A paradigm shift in the techniques used to enable the distributeddesign of ships while enabling a continuous product model andfacilitating the management of conflicts and consistency would bethe adoption of a technology that is more often seen within thecomputer games industry Graphics servers are commonly usedwithin the games industry to enable the user to immerse them-selves within an environment and interact both with the environ-ment and with other users High-level graphical objects are com-municated between the server side and the client side rather thanusing structured files This technique bypasses the need to trans-late the communicated data into the client side format alleviatingunnecessary computation It also results in a model containedwithin the server and represented within the clients that is a con-tinuous depiction of what everyone is undertaking The ship prod-uct data would remain within the ship STEP formats Howeverthe description method would be the graphical object representa-tion that would also exhibit behavioral properties Within the ship-building context individual graphics servers would represent do-mains similar to those identified by Crawford et al (1999) Clientsconnecting to the servers would immediately get an up-to-dateview of that particular domain which would be consistent with theviews of all of the other clients The client software would operatein a manner similar to conventional design applications There isalso clearly a requirement for integration between the differentdomain servers to enable conflicts to be resolved across domainsSimulation servers would integrate all of the scenarios that wouldenable an evaluation of the performance within any particular lifephase There would still remain the need to provide an effectivemanagement of different versions as well as a high-level coordi-nation structure to manage conflicts constraints design goals andcollaboration among designers However the underlying frame-work would provide the basis on which to construct this Despitebeing a significant step-change compared with current practicethis future technique proposes a viable solution to the effectivemanagement of a ship product model that may be manipulated andoperated upon in a distributed manner

This type of architecture does however raise a number of

issues relating to partnerships between the shipbuilding industryand the shipbuilding software industry because the system wouldrepresent an amalgamation of existing design and simulation ap-plications into a number of domain-specific servers The intellec-tual property rights as well as the ownership of both the technol-ogy and the data contained would clearly need to be resolved Inaddition the system calls upon the need to implement a standardfor the communication of the graphical objects that is both secureand robust whereas the standard for the data may be ldquoflavoredrdquoand managed effectively within the system via the ability to dy-namically load classes

Just as many of the precommissioning life phases are currentlybeing modeled it is anticipated that the rather poorly supportedpostcommissioning life phases will be catered for The most sig-nificant difference between pre- and postcommissioning is that itwill be the ship product model in its entirety that will be consid-ered For example there currently appears to be a significantopportunity for the specialization of the immersion of an entireship product model into an artificial environment to determine theoperational performance both at virtual sea (modeling existingshipping lanes to determine sea-keeping characteristics) within avirtual port (modeling existing ports to determine cargo-handlingcharacteristics) within a virtual shipyard for recommissioning(modeling existing shipyards to determine recommissioning capa-bility) and within a virtual breakers yard for disposal (to deter-mine scrap value) Increased opportunity would therefore be madefor designing the ship to meet a more rigorous set of customer-specified life-phase requirements and would represent a signifi-cant commercial advantage

It is also interesting at this point to note that a number of thecited papers have stated the need to avoid a reliance on computerprogrammers which in order to maintain even the simplest ofproduct data modeling systems seems unachievable

Conclusions

From the increasing amount of literature and the papers re-viewed within this paper related to the ship product model theprimary focus is on developing a standard representation for thedata contained within the model Despite not having yet finalizedthe standards for all aspects of the ship the STEP APs go a longway toward achieving this It is almost inconceivable to considerthat an alternative could compete against such a massive thrusttoward ship data standardization A number of instances havearisen however when the APs have been adhered to with theresult that ldquoflavorsrdquo or minor changes to the standard have beenrequired in order to utilize the structured well-defined and stan-dardized data within the legacy applications The question there-fore arises as to whether there is a requirement to standardize thelegacy applications such that they adhere to the data standard toenable a modular plug-in approach to ship design and simulation

Behavioral aspects have been considered within a number of thecited papers to be an important addition to the data in order toprovide the designer with additional feedback with respect to theoperation of the design This behavior may however be betterrepresented as high-level rules within a standard that are used todefine the operation of the ship rather than in existing standardsin order to minimize its impact on applications that have no needfor such data

A number of the tools and techniques discussed have described

the use of the ship STEP formats as being a mechanism for inte-grating existing legacy applications with a common model of shipproduct data Considerable benefit would be obtained from pro-viding similar integration between applications to progress fromthe limitations of discrete design and simulation toward having aholistic approach

The design tasks that are undertaken as part of the ship designprocess may well take a considerable amount of time and wouldconventionally result in ldquosnapshotsrdquo of the design artifact coin-ciding with the designer uploading data into the common modelA number of future directions have been discussed which wouldindividually require considerable development in order to imple-ment but which represent possible solutions to issues relating to

Continuous rather than ldquosnapshotrdquo ship product models Integration between the ship product model and the design

and simulation applications as well as across applications Removal of information translation problems through the

use of high-level graphical objects that are consistent betweenservers and applications

A collaborative framework on which to develop versionconflict and consistency management

Acknowledgments

The review was undertaken as part of an investigation intocommon model techniques within the VRShips-ROPAX2000project The authors gratefully acknowledge the support given bythe European Commission Community Research 5th Frameworkprogram under the area of Competitive and Sustainable Growthwhich provided the grant (G3RD-CT-2001-00506) that enabledthis work to be undertaken

References

BAUM S J AND RAMAKRISHNAN R 1997 Applying 3D product modelingtechnology in shipbuilding Marine Technology 34 1 56ndash65

CATLEY D 1999 Prototype STEP data exchanges in ship initial design andprovision of an application programmer interface to TRIBON Proceedings10th International Conference on Computer Applications in ShipbuildingJune Cambridge MA

CRAWFORD A K HARRINGTON G AMES R M AND VAN ESELTINE RT 1999 Neutral format data exchanges between ship product models andanalysis interfaces Proceedings 10th International Conference on Com-puter Applications in Shipbuilding June Cambridge MA

ERIKSTAD S O AND FATHI D E 1999 Applying the STEP shipbuildingprotocols as a basis for integrating existing in-house ship design applica-tions Proceedings 10th International Conference on Computer Applica-tions in Shipbuilding June Cambridge MA

GISCHNER B KASSEL B LAZO P WOOD R AND WYMAN J 2001 Evolution of STEP (ESTEP) exchange of shipbuilding productmodel data JOURNAL OF SHIP PRODUCTION 17 3 151ndash160

GRAU M AND KOCH T 1999 Applying STEP technology to shipbuildingProceedings 10th International Conference on Computer Applications inShipbuilding June Cambridge MA

HERZOG E AND TOumlRNE A 1999 A seed for a STEP application protocolfor systems engineering Proceedings 12th International Conference andWorkshop on the Engineering of Computer Based Systems Institute ofElectrical and Electronics Engineers Press Piscataway NJ 174ndash180

HIGNEY J T AND OUILETTE J J 1994 An engineering product modelbased on STEP protocols JOURNAL OF SHIP PRODUCTION 10 4 281ndash286

ISO 1996 Product Data Representation and Exchange Part 218 Ship Struc-

tures International Standards Organization Hamburg GermanyJOHANSSON K 1995 The product model as a central information source in

a shipbuilding environment Proceedings National Shipbuilding ResearchProgram 1995 Ship Production Symposium June Seattle WA

LAMB T CHUNG H AND SHIN J G 2000 A generic shipyard computermodel a tool for design for production Proceedings 7th IMDC NovemberKyung-Ju Korea

MARTIN D J 1980 The shipyard product information system as an aid toimplementing more productive strategies Proceedings Research and Engi-neering for Automation and Productivity in Shipbuilding IIT Research In-stitute October Chicago IL 81ndash101

POLINI M A AND MELAND K E 1997 The development and implemen-tation of a SMART product model for ship structure Proceedings 9thInternational Conference on Computer Applications in Shipbuilding Octo-ber Yokohama Japan

RANDO T C AND FERNHOLZ D 2000 MARITECHrsquos shipbuilding infor-mation infrastructure JOURNAL OF SHIP PRODUCTION 16 2 110ndash120

RANDO T C 2001 XML-based interoperability in the integrated shipbuild-ing environment (ISE) JOURNAL OF SHIP PRODUCTION 17 2 69ndash75

ROSS J M AND GARCIA L 1998 Making the jump to product modeltechnology JOURNAL OF SHIP PRODUCTION 14 1 15ndash26

ROSS J M AND ABAL D 2001 Practical use of 3D product modeling inthe small shipyard JOURNAL OF SHIP PRODUCTION 17 1 27ndash34

SCHMIDT W R VANDER J R AND SHIELDS V R 1990 Modelling andtransfer of product model digital data for the DDG 51 class destroyer pro-gram Proceedings National Shipbuilding Research Program 1990 ShipProduction Symposium August Milwaukee WI

SHIN Y AND HAN S H 1998 Data enhancement for sharing of shipdesign models Computer-Aided Design 30 12 931ndash941

VON HAARTMAN J KUUTTI I AND SCHAUMAN C 1994 Improving designproductivity with a product model for initial ship design Proceedings 8thInternational Conference on Computer Applications in Shipbuilding Sep-tember Bremen Germany

WELSH M LYNCH J AND BRUN B 1992 A data model for integration ofthe precommissioning life-cycle stages of the shipbuildingproduct JOURNAL

OF SHIP PRODUCTION 8 4 220ndash234WHITFIELD R I COATE S G DUFFY A H B AND HILLS

W 2000 Coordination approaches and systemsmdashpart I a strategic per-spective Research in Engineering Design 12 73ndash89

WYMAN J WOOLEY D GISCHNER B AND HOWELL J 1997 Development of STEP ship model database and translators fordata exchange between shipyards JOURNAL OF SHIP PRODUCTION 13 2111ndash124

Internet addresses

European Marine STEP Association httpemsagermanlloydorg

ISO STEP ship team http wwwnsnetcomNIDDESCt23html

Japan Marine Standards Association http wwwjecalsjipdecorjp

Korea STEP Centre httpksteporkr

Coupled with simulation-based design (SBD) Baum describedthe combined technology as ldquothe new frontierrdquo that would enablethe virtual prototyping of the ship which previously could not beachieved due to the cost and complexity More importantly Baumrecognized that just as interference-checking software may beused to determine discrepancies between geometric parts duringthe design and production phases SBD may be used to reduce oreliminate design errors that would have previously have beendiscovered years later in the operational stage for example Es-sentially SBD and product modeling enable the validation of thedesign production and operation stages of the ship product

Baum also finally suggested that the product model provides asignificant benefit to the owneroperator by enabling the analysisand support of life-cycle maintenance

A generic shipyard computer modeling tool for evaluating de-sign for production (DFP) is discussed by Lamb et al (2000) Thetool enables shipyards to be modeled such that the impacts ofchanges to the ship design may be determined on the basis of theresulting material manpower and schedule The shipyard modelrepresents details of the buildingsmdashtheir arrangement and size aswell as equipment capacity and flow The tool also enables aninvestigation of the necessary changes required for a shipyard inorder to produce a new design The key foundations in order toevaluate these impacts are the interim product catalogue and thebuild strategy approach

Lamb et al identified a number of important concepts for DFP

All designs should be prepared to suit a shipyardrsquos facili-ties and preferred production methods

DFP takes into account production methods and tech-niques that reduce the product work content but still meet thespecified design requirements and quality

DFP must be incorporated into a design from the start Traditional engineering leaves it up to another department

such as production or manufacturing engineering to developthe technical documentation required for the production work-ers This is an unnecessary duplication of effort and is a nonndashvalue-added task that takes time

An objective of the CE approach is to accommodate DFPby bringing all the necessary people together right from dayone on a project

The time to influence the cost of a product is during theearly stages After the design has been developed in conceptmost of the opportunity to positively affect cost is gone

World-class ship designers know how their shipyardbuilds ships and design accordingly Many ship designers donot consider this and the designs may or may not be efficientlybuilt in their facilities More shipbuilders have taken steps toremedy this situation through the use of the build strategyapproach

Engineering should be prepared and transmitted to theusers in a way that best suits block construction advanced andzone outfitting

An object-oriented approach was adopted for the constructionof the model (Fig 16) The model represents shipyards worksta-tions products equipment processes manufacturing processesmaterial handling processes and interim products The tool wasapplied to the evaluation of two design alternatives for the bottomstructure of a ship The authors demonstrated that the tool enabledreliable evaluations of the man-hours for manufacturing and ma-terial handling such that the best design alternative could beadopted

Future directions

It is believed that the ship STEP APs will become the standardunit of shipbuilding data but that it will probably be an evolution-ary process as advances in technology and modeling capabilitiesand requirements are incorporated It is however crucial that thedevelopment of the standards comes to a timely consensus at eachevolutionary stage The literature reviewed has discussed the useof ldquointelligentrdquo data the inclusion of useful functionality accord-ing to the data type and of behavioral aspects It is anticipated thatthis functionality behavioral aspects and so forth will increas-

Fig 15 Ship design workflow using three-dimensional product model (Baum amp Ramakrishnan 1997)

ingly become part of the model to the extent that the model nolonger has any need for interfaces and translators to legacy soft-ware For example the piping model would automatically calcu-late interferences and the structures model would automaticallycalculate stress characteristics The simulation would essentiallybe part of the model and the model would contain additionalinformation and knowledge to effectively manage the simulationThis is not to say that the model would become a monolithicsystem despite such a system being potentially computationallyviable in 10 years Rather than being monolithic current andfuture distributed information technologies such as EnterpriseJava Beans may be utilized in order to distribute the model acrossa network while giving the impression to the user that the systemis monolithic Ship product data and functionality would be dis-tributed either within a single company or as partnerships withother companies

In a similar way that the ship product data has become stan-dardized benefits are to be gained from standardizing the inter-faces between applications to support the flow of standardizeddata and achieve a truly seamless integration The unfortunateshortcoming of application standardization is the necessity to re-develop the legacy systems to support this level of integration

The VRShips project addresses the management of ship productdata within a neutrally formatted common model The geometry

data contained within the common model are based on STEPAP203 are described using XML and are considered as beingcommon data if two or more applications access it Integration isprovided between the legacy applications and the common modelvia ldquogeneric wrappersrdquo that provide the general management re-quired in order to operate the applications The wrappers convertthe data to and from the native format using modular conversionalgorithms that can be plugged into the wrappers and provide thedomain-specific management for the applications Data are auto-matically downloaded from the common model and converted intothe native format when the application is started When the appli-cation is complete the designer has the option of undertaking thereverse process to convert the data back into the neutral format andupload into the common model Despite being a complex processconverters have been produced for a number of design applica-tions such as Tribon and AVPro and have been demonstrated tooperate without the need for manual interaction However theissues relating to the lack of integration between tools and con-tinuous product models remain to be addressed

The VRShips system also has an additional management layerconsisting of a process controller and an inference engine that arejointly responsible for maintaining data consistency and versionconstraint and process management Visualizing of product datavia the legacy applications is managed through the exporting of

Fig 16 Object diagram for generic shipyard computer model (Lamb et al 2000)

the displays via a virtual interaction environment These controlmechanisms ensure that designers may modify the data containedwithin the common model from any location either organization-ally or geographically distributed with network access using anapplication that they are familiar with and that any changes madeto the product model are correctly propagated such that the dataremain consistent

Every product modeling tool and technique discussed withinthis review is common from the perspective that the data containedwithin the model are a ldquosnapshotrdquo of the actual design activity Forinstance a designer may download data from the ship productmodel for use within a general design package which may take aweek to design During this design period the data within theproduct model do not change until the designer decides that thedesign process is complete and the data are uploaded into theproduct model The product model therefore does not contain acontinuous representation of either the design work that is cur-rently being undertaken or the form that the data are in This posesa number of significant project management issues with respect toversion control consistency management and conflict resolutionespecially in the situation where the design process is being un-dertaken in a distributed manner as is increasingly becomingcommon

A paradigm shift in the techniques used to enable the distributeddesign of ships while enabling a continuous product model andfacilitating the management of conflicts and consistency would bethe adoption of a technology that is more often seen within thecomputer games industry Graphics servers are commonly usedwithin the games industry to enable the user to immerse them-selves within an environment and interact both with the environ-ment and with other users High-level graphical objects are com-municated between the server side and the client side rather thanusing structured files This technique bypasses the need to trans-late the communicated data into the client side format alleviatingunnecessary computation It also results in a model containedwithin the server and represented within the clients that is a con-tinuous depiction of what everyone is undertaking The ship prod-uct data would remain within the ship STEP formats Howeverthe description method would be the graphical object representa-tion that would also exhibit behavioral properties Within the ship-building context individual graphics servers would represent do-mains similar to those identified by Crawford et al (1999) Clientsconnecting to the servers would immediately get an up-to-dateview of that particular domain which would be consistent with theviews of all of the other clients The client software would operatein a manner similar to conventional design applications There isalso clearly a requirement for integration between the differentdomain servers to enable conflicts to be resolved across domainsSimulation servers would integrate all of the scenarios that wouldenable an evaluation of the performance within any particular lifephase There would still remain the need to provide an effectivemanagement of different versions as well as a high-level coordi-nation structure to manage conflicts constraints design goals andcollaboration among designers However the underlying frame-work would provide the basis on which to construct this Despitebeing a significant step-change compared with current practicethis future technique proposes a viable solution to the effectivemanagement of a ship product model that may be manipulated andoperated upon in a distributed manner

This type of architecture does however raise a number of

issues relating to partnerships between the shipbuilding industryand the shipbuilding software industry because the system wouldrepresent an amalgamation of existing design and simulation ap-plications into a number of domain-specific servers The intellec-tual property rights as well as the ownership of both the technol-ogy and the data contained would clearly need to be resolved Inaddition the system calls upon the need to implement a standardfor the communication of the graphical objects that is both secureand robust whereas the standard for the data may be ldquoflavoredrdquoand managed effectively within the system via the ability to dy-namically load classes

Just as many of the precommissioning life phases are currentlybeing modeled it is anticipated that the rather poorly supportedpostcommissioning life phases will be catered for The most sig-nificant difference between pre- and postcommissioning is that itwill be the ship product model in its entirety that will be consid-ered For example there currently appears to be a significantopportunity for the specialization of the immersion of an entireship product model into an artificial environment to determine theoperational performance both at virtual sea (modeling existingshipping lanes to determine sea-keeping characteristics) within avirtual port (modeling existing ports to determine cargo-handlingcharacteristics) within a virtual shipyard for recommissioning(modeling existing shipyards to determine recommissioning capa-bility) and within a virtual breakers yard for disposal (to deter-mine scrap value) Increased opportunity would therefore be madefor designing the ship to meet a more rigorous set of customer-specified life-phase requirements and would represent a signifi-cant commercial advantage

It is also interesting at this point to note that a number of thecited papers have stated the need to avoid a reliance on computerprogrammers which in order to maintain even the simplest ofproduct data modeling systems seems unachievable

Conclusions

From the increasing amount of literature and the papers re-viewed within this paper related to the ship product model theprimary focus is on developing a standard representation for thedata contained within the model Despite not having yet finalizedthe standards for all aspects of the ship the STEP APs go a longway toward achieving this It is almost inconceivable to considerthat an alternative could compete against such a massive thrusttoward ship data standardization A number of instances havearisen however when the APs have been adhered to with theresult that ldquoflavorsrdquo or minor changes to the standard have beenrequired in order to utilize the structured well-defined and stan-dardized data within the legacy applications The question there-fore arises as to whether there is a requirement to standardize thelegacy applications such that they adhere to the data standard toenable a modular plug-in approach to ship design and simulation

Behavioral aspects have been considered within a number of thecited papers to be an important addition to the data in order toprovide the designer with additional feedback with respect to theoperation of the design This behavior may however be betterrepresented as high-level rules within a standard that are used todefine the operation of the ship rather than in existing standardsin order to minimize its impact on applications that have no needfor such data

A number of the tools and techniques discussed have described

the use of the ship STEP formats as being a mechanism for inte-grating existing legacy applications with a common model of shipproduct data Considerable benefit would be obtained from pro-viding similar integration between applications to progress fromthe limitations of discrete design and simulation toward having aholistic approach

The design tasks that are undertaken as part of the ship designprocess may well take a considerable amount of time and wouldconventionally result in ldquosnapshotsrdquo of the design artifact coin-ciding with the designer uploading data into the common modelA number of future directions have been discussed which wouldindividually require considerable development in order to imple-ment but which represent possible solutions to issues relating to

Continuous rather than ldquosnapshotrdquo ship product models Integration between the ship product model and the design

and simulation applications as well as across applications Removal of information translation problems through the

use of high-level graphical objects that are consistent betweenservers and applications

A collaborative framework on which to develop versionconflict and consistency management

Acknowledgments

The review was undertaken as part of an investigation intocommon model techniques within the VRShips-ROPAX2000project The authors gratefully acknowledge the support given bythe European Commission Community Research 5th Frameworkprogram under the area of Competitive and Sustainable Growthwhich provided the grant (G3RD-CT-2001-00506) that enabledthis work to be undertaken

References

BAUM S J AND RAMAKRISHNAN R 1997 Applying 3D product modelingtechnology in shipbuilding Marine Technology 34 1 56ndash65

CATLEY D 1999 Prototype STEP data exchanges in ship initial design andprovision of an application programmer interface to TRIBON Proceedings10th International Conference on Computer Applications in ShipbuildingJune Cambridge MA

CRAWFORD A K HARRINGTON G AMES R M AND VAN ESELTINE RT 1999 Neutral format data exchanges between ship product models andanalysis interfaces Proceedings 10th International Conference on Com-puter Applications in Shipbuilding June Cambridge MA

ERIKSTAD S O AND FATHI D E 1999 Applying the STEP shipbuildingprotocols as a basis for integrating existing in-house ship design applica-tions Proceedings 10th International Conference on Computer Applica-tions in Shipbuilding June Cambridge MA

GISCHNER B KASSEL B LAZO P WOOD R AND WYMAN J 2001 Evolution of STEP (ESTEP) exchange of shipbuilding productmodel data JOURNAL OF SHIP PRODUCTION 17 3 151ndash160

GRAU M AND KOCH T 1999 Applying STEP technology to shipbuildingProceedings 10th International Conference on Computer Applications inShipbuilding June Cambridge MA

HERZOG E AND TOumlRNE A 1999 A seed for a STEP application protocolfor systems engineering Proceedings 12th International Conference andWorkshop on the Engineering of Computer Based Systems Institute ofElectrical and Electronics Engineers Press Piscataway NJ 174ndash180

HIGNEY J T AND OUILETTE J J 1994 An engineering product modelbased on STEP protocols JOURNAL OF SHIP PRODUCTION 10 4 281ndash286

ISO 1996 Product Data Representation and Exchange Part 218 Ship Struc-

tures International Standards Organization Hamburg GermanyJOHANSSON K 1995 The product model as a central information source in

a shipbuilding environment Proceedings National Shipbuilding ResearchProgram 1995 Ship Production Symposium June Seattle WA

LAMB T CHUNG H AND SHIN J G 2000 A generic shipyard computermodel a tool for design for production Proceedings 7th IMDC NovemberKyung-Ju Korea

MARTIN D J 1980 The shipyard product information system as an aid toimplementing more productive strategies Proceedings Research and Engi-neering for Automation and Productivity in Shipbuilding IIT Research In-stitute October Chicago IL 81ndash101

POLINI M A AND MELAND K E 1997 The development and implemen-tation of a SMART product model for ship structure Proceedings 9thInternational Conference on Computer Applications in Shipbuilding Octo-ber Yokohama Japan

RANDO T C AND FERNHOLZ D 2000 MARITECHrsquos shipbuilding infor-mation infrastructure JOURNAL OF SHIP PRODUCTION 16 2 110ndash120

RANDO T C 2001 XML-based interoperability in the integrated shipbuild-ing environment (ISE) JOURNAL OF SHIP PRODUCTION 17 2 69ndash75

ROSS J M AND GARCIA L 1998 Making the jump to product modeltechnology JOURNAL OF SHIP PRODUCTION 14 1 15ndash26

ROSS J M AND ABAL D 2001 Practical use of 3D product modeling inthe small shipyard JOURNAL OF SHIP PRODUCTION 17 1 27ndash34

SCHMIDT W R VANDER J R AND SHIELDS V R 1990 Modelling andtransfer of product model digital data for the DDG 51 class destroyer pro-gram Proceedings National Shipbuilding Research Program 1990 ShipProduction Symposium August Milwaukee WI

SHIN Y AND HAN S H 1998 Data enhancement for sharing of shipdesign models Computer-Aided Design 30 12 931ndash941

VON HAARTMAN J KUUTTI I AND SCHAUMAN C 1994 Improving designproductivity with a product model for initial ship design Proceedings 8thInternational Conference on Computer Applications in Shipbuilding Sep-tember Bremen Germany

WELSH M LYNCH J AND BRUN B 1992 A data model for integration ofthe precommissioning life-cycle stages of the shipbuildingproduct JOURNAL

OF SHIP PRODUCTION 8 4 220ndash234WHITFIELD R I COATE S G DUFFY A H B AND HILLS

W 2000 Coordination approaches and systemsmdashpart I a strategic per-spective Research in Engineering Design 12 73ndash89

WYMAN J WOOLEY D GISCHNER B AND HOWELL J 1997 Development of STEP ship model database and translators fordata exchange between shipyards JOURNAL OF SHIP PRODUCTION 13 2111ndash124

Internet addresses

European Marine STEP Association httpemsagermanlloydorg

ISO STEP ship team http wwwnsnetcomNIDDESCt23html

Japan Marine Standards Association http wwwjecalsjipdecorjp

Korea STEP Centre httpksteporkr

ingly become part of the model to the extent that the model nolonger has any need for interfaces and translators to legacy soft-ware For example the piping model would automatically calcu-late interferences and the structures model would automaticallycalculate stress characteristics The simulation would essentiallybe part of the model and the model would contain additionalinformation and knowledge to effectively manage the simulationThis is not to say that the model would become a monolithicsystem despite such a system being potentially computationallyviable in 10 years Rather than being monolithic current andfuture distributed information technologies such as EnterpriseJava Beans may be utilized in order to distribute the model acrossa network while giving the impression to the user that the systemis monolithic Ship product data and functionality would be dis-tributed either within a single company or as partnerships withother companies

In a similar way that the ship product data has become stan-dardized benefits are to be gained from standardizing the inter-faces between applications to support the flow of standardizeddata and achieve a truly seamless integration The unfortunateshortcoming of application standardization is the necessity to re-develop the legacy systems to support this level of integration

The VRShips project addresses the management of ship productdata within a neutrally formatted common model The geometry

data contained within the common model are based on STEPAP203 are described using XML and are considered as beingcommon data if two or more applications access it Integration isprovided between the legacy applications and the common modelvia ldquogeneric wrappersrdquo that provide the general management re-quired in order to operate the applications The wrappers convertthe data to and from the native format using modular conversionalgorithms that can be plugged into the wrappers and provide thedomain-specific management for the applications Data are auto-matically downloaded from the common model and converted intothe native format when the application is started When the appli-cation is complete the designer has the option of undertaking thereverse process to convert the data back into the neutral format andupload into the common model Despite being a complex processconverters have been produced for a number of design applica-tions such as Tribon and AVPro and have been demonstrated tooperate without the need for manual interaction However theissues relating to the lack of integration between tools and con-tinuous product models remain to be addressed

The VRShips system also has an additional management layerconsisting of a process controller and an inference engine that arejointly responsible for maintaining data consistency and versionconstraint and process management Visualizing of product datavia the legacy applications is managed through the exporting of

Fig 16 Object diagram for generic shipyard computer model (Lamb et al 2000)

the displays via a virtual interaction environment These controlmechanisms ensure that designers may modify the data containedwithin the common model from any location either organization-ally or geographically distributed with network access using anapplication that they are familiar with and that any changes madeto the product model are correctly propagated such that the dataremain consistent

Every product modeling tool and technique discussed withinthis review is common from the perspective that the data containedwithin the model are a ldquosnapshotrdquo of the actual design activity Forinstance a designer may download data from the ship productmodel for use within a general design package which may take aweek to design During this design period the data within theproduct model do not change until the designer decides that thedesign process is complete and the data are uploaded into theproduct model The product model therefore does not contain acontinuous representation of either the design work that is cur-rently being undertaken or the form that the data are in This posesa number of significant project management issues with respect toversion control consistency management and conflict resolutionespecially in the situation where the design process is being un-dertaken in a distributed manner as is increasingly becomingcommon

A paradigm shift in the techniques used to enable the distributeddesign of ships while enabling a continuous product model andfacilitating the management of conflicts and consistency would bethe adoption of a technology that is more often seen within thecomputer games industry Graphics servers are commonly usedwithin the games industry to enable the user to immerse them-selves within an environment and interact both with the environ-ment and with other users High-level graphical objects are com-municated between the server side and the client side rather thanusing structured files This technique bypasses the need to trans-late the communicated data into the client side format alleviatingunnecessary computation It also results in a model containedwithin the server and represented within the clients that is a con-tinuous depiction of what everyone is undertaking The ship prod-uct data would remain within the ship STEP formats Howeverthe description method would be the graphical object representa-tion that would also exhibit behavioral properties Within the ship-building context individual graphics servers would represent do-mains similar to those identified by Crawford et al (1999) Clientsconnecting to the servers would immediately get an up-to-dateview of that particular domain which would be consistent with theviews of all of the other clients The client software would operatein a manner similar to conventional design applications There isalso clearly a requirement for integration between the differentdomain servers to enable conflicts to be resolved across domainsSimulation servers would integrate all of the scenarios that wouldenable an evaluation of the performance within any particular lifephase There would still remain the need to provide an effectivemanagement of different versions as well as a high-level coordi-nation structure to manage conflicts constraints design goals andcollaboration among designers However the underlying frame-work would provide the basis on which to construct this Despitebeing a significant step-change compared with current practicethis future technique proposes a viable solution to the effectivemanagement of a ship product model that may be manipulated andoperated upon in a distributed manner

This type of architecture does however raise a number of

issues relating to partnerships between the shipbuilding industryand the shipbuilding software industry because the system wouldrepresent an amalgamation of existing design and simulation ap-plications into a number of domain-specific servers The intellec-tual property rights as well as the ownership of both the technol-ogy and the data contained would clearly need to be resolved Inaddition the system calls upon the need to implement a standardfor the communication of the graphical objects that is both secureand robust whereas the standard for the data may be ldquoflavoredrdquoand managed effectively within the system via the ability to dy-namically load classes

Just as many of the precommissioning life phases are currentlybeing modeled it is anticipated that the rather poorly supportedpostcommissioning life phases will be catered for The most sig-nificant difference between pre- and postcommissioning is that itwill be the ship product model in its entirety that will be consid-ered For example there currently appears to be a significantopportunity for the specialization of the immersion of an entireship product model into an artificial environment to determine theoperational performance both at virtual sea (modeling existingshipping lanes to determine sea-keeping characteristics) within avirtual port (modeling existing ports to determine cargo-handlingcharacteristics) within a virtual shipyard for recommissioning(modeling existing shipyards to determine recommissioning capa-bility) and within a virtual breakers yard for disposal (to deter-mine scrap value) Increased opportunity would therefore be madefor designing the ship to meet a more rigorous set of customer-specified life-phase requirements and would represent a signifi-cant commercial advantage

It is also interesting at this point to note that a number of thecited papers have stated the need to avoid a reliance on computerprogrammers which in order to maintain even the simplest ofproduct data modeling systems seems unachievable

Conclusions

From the increasing amount of literature and the papers re-viewed within this paper related to the ship product model theprimary focus is on developing a standard representation for thedata contained within the model Despite not having yet finalizedthe standards for all aspects of the ship the STEP APs go a longway toward achieving this It is almost inconceivable to considerthat an alternative could compete against such a massive thrusttoward ship data standardization A number of instances havearisen however when the APs have been adhered to with theresult that ldquoflavorsrdquo or minor changes to the standard have beenrequired in order to utilize the structured well-defined and stan-dardized data within the legacy applications The question there-fore arises as to whether there is a requirement to standardize thelegacy applications such that they adhere to the data standard toenable a modular plug-in approach to ship design and simulation

Behavioral aspects have been considered within a number of thecited papers to be an important addition to the data in order toprovide the designer with additional feedback with respect to theoperation of the design This behavior may however be betterrepresented as high-level rules within a standard that are used todefine the operation of the ship rather than in existing standardsin order to minimize its impact on applications that have no needfor such data

A number of the tools and techniques discussed have described

the use of the ship STEP formats as being a mechanism for inte-grating existing legacy applications with a common model of shipproduct data Considerable benefit would be obtained from pro-viding similar integration between applications to progress fromthe limitations of discrete design and simulation toward having aholistic approach

The design tasks that are undertaken as part of the ship designprocess may well take a considerable amount of time and wouldconventionally result in ldquosnapshotsrdquo of the design artifact coin-ciding with the designer uploading data into the common modelA number of future directions have been discussed which wouldindividually require considerable development in order to imple-ment but which represent possible solutions to issues relating to

Continuous rather than ldquosnapshotrdquo ship product models Integration between the ship product model and the design

and simulation applications as well as across applications Removal of information translation problems through the

use of high-level graphical objects that are consistent betweenservers and applications

A collaborative framework on which to develop versionconflict and consistency management

Acknowledgments

The review was undertaken as part of an investigation intocommon model techniques within the VRShips-ROPAX2000project The authors gratefully acknowledge the support given bythe European Commission Community Research 5th Frameworkprogram under the area of Competitive and Sustainable Growthwhich provided the grant (G3RD-CT-2001-00506) that enabledthis work to be undertaken

References

BAUM S J AND RAMAKRISHNAN R 1997 Applying 3D product modelingtechnology in shipbuilding Marine Technology 34 1 56ndash65

CATLEY D 1999 Prototype STEP data exchanges in ship initial design andprovision of an application programmer interface to TRIBON Proceedings10th International Conference on Computer Applications in ShipbuildingJune Cambridge MA

CRAWFORD A K HARRINGTON G AMES R M AND VAN ESELTINE RT 1999 Neutral format data exchanges between ship product models andanalysis interfaces Proceedings 10th International Conference on Com-puter Applications in Shipbuilding June Cambridge MA

ERIKSTAD S O AND FATHI D E 1999 Applying the STEP shipbuildingprotocols as a basis for integrating existing in-house ship design applica-tions Proceedings 10th International Conference on Computer Applica-tions in Shipbuilding June Cambridge MA

GISCHNER B KASSEL B LAZO P WOOD R AND WYMAN J 2001 Evolution of STEP (ESTEP) exchange of shipbuilding productmodel data JOURNAL OF SHIP PRODUCTION 17 3 151ndash160

GRAU M AND KOCH T 1999 Applying STEP technology to shipbuildingProceedings 10th International Conference on Computer Applications inShipbuilding June Cambridge MA

HERZOG E AND TOumlRNE A 1999 A seed for a STEP application protocolfor systems engineering Proceedings 12th International Conference andWorkshop on the Engineering of Computer Based Systems Institute ofElectrical and Electronics Engineers Press Piscataway NJ 174ndash180

HIGNEY J T AND OUILETTE J J 1994 An engineering product modelbased on STEP protocols JOURNAL OF SHIP PRODUCTION 10 4 281ndash286

ISO 1996 Product Data Representation and Exchange Part 218 Ship Struc-

tures International Standards Organization Hamburg GermanyJOHANSSON K 1995 The product model as a central information source in

a shipbuilding environment Proceedings National Shipbuilding ResearchProgram 1995 Ship Production Symposium June Seattle WA

LAMB T CHUNG H AND SHIN J G 2000 A generic shipyard computermodel a tool for design for production Proceedings 7th IMDC NovemberKyung-Ju Korea

MARTIN D J 1980 The shipyard product information system as an aid toimplementing more productive strategies Proceedings Research and Engi-neering for Automation and Productivity in Shipbuilding IIT Research In-stitute October Chicago IL 81ndash101

POLINI M A AND MELAND K E 1997 The development and implemen-tation of a SMART product model for ship structure Proceedings 9thInternational Conference on Computer Applications in Shipbuilding Octo-ber Yokohama Japan

RANDO T C AND FERNHOLZ D 2000 MARITECHrsquos shipbuilding infor-mation infrastructure JOURNAL OF SHIP PRODUCTION 16 2 110ndash120

RANDO T C 2001 XML-based interoperability in the integrated shipbuild-ing environment (ISE) JOURNAL OF SHIP PRODUCTION 17 2 69ndash75

ROSS J M AND GARCIA L 1998 Making the jump to product modeltechnology JOURNAL OF SHIP PRODUCTION 14 1 15ndash26

ROSS J M AND ABAL D 2001 Practical use of 3D product modeling inthe small shipyard JOURNAL OF SHIP PRODUCTION 17 1 27ndash34

SCHMIDT W R VANDER J R AND SHIELDS V R 1990 Modelling andtransfer of product model digital data for the DDG 51 class destroyer pro-gram Proceedings National Shipbuilding Research Program 1990 ShipProduction Symposium August Milwaukee WI

SHIN Y AND HAN S H 1998 Data enhancement for sharing of shipdesign models Computer-Aided Design 30 12 931ndash941

VON HAARTMAN J KUUTTI I AND SCHAUMAN C 1994 Improving designproductivity with a product model for initial ship design Proceedings 8thInternational Conference on Computer Applications in Shipbuilding Sep-tember Bremen Germany

WELSH M LYNCH J AND BRUN B 1992 A data model for integration ofthe precommissioning life-cycle stages of the shipbuildingproduct JOURNAL

OF SHIP PRODUCTION 8 4 220ndash234WHITFIELD R I COATE S G DUFFY A H B AND HILLS

W 2000 Coordination approaches and systemsmdashpart I a strategic per-spective Research in Engineering Design 12 73ndash89

WYMAN J WOOLEY D GISCHNER B AND HOWELL J 1997 Development of STEP ship model database and translators fordata exchange between shipyards JOURNAL OF SHIP PRODUCTION 13 2111ndash124

Internet addresses

European Marine STEP Association httpemsagermanlloydorg

ISO STEP ship team http wwwnsnetcomNIDDESCt23html

Japan Marine Standards Association http wwwjecalsjipdecorjp

Korea STEP Centre httpksteporkr

the displays via a virtual interaction environment These controlmechanisms ensure that designers may modify the data containedwithin the common model from any location either organization-ally or geographically distributed with network access using anapplication that they are familiar with and that any changes madeto the product model are correctly propagated such that the dataremain consistent

Every product modeling tool and technique discussed withinthis review is common from the perspective that the data containedwithin the model are a ldquosnapshotrdquo of the actual design activity Forinstance a designer may download data from the ship productmodel for use within a general design package which may take aweek to design During this design period the data within theproduct model do not change until the designer decides that thedesign process is complete and the data are uploaded into theproduct model The product model therefore does not contain acontinuous representation of either the design work that is cur-rently being undertaken or the form that the data are in This posesa number of significant project management issues with respect toversion control consistency management and conflict resolutionespecially in the situation where the design process is being un-dertaken in a distributed manner as is increasingly becomingcommon

A paradigm shift in the techniques used to enable the distributeddesign of ships while enabling a continuous product model andfacilitating the management of conflicts and consistency would bethe adoption of a technology that is more often seen within thecomputer games industry Graphics servers are commonly usedwithin the games industry to enable the user to immerse them-selves within an environment and interact both with the environ-ment and with other users High-level graphical objects are com-municated between the server side and the client side rather thanusing structured files This technique bypasses the need to trans-late the communicated data into the client side format alleviatingunnecessary computation It also results in a model containedwithin the server and represented within the clients that is a con-tinuous depiction of what everyone is undertaking The ship prod-uct data would remain within the ship STEP formats Howeverthe description method would be the graphical object representa-tion that would also exhibit behavioral properties Within the ship-building context individual graphics servers would represent do-mains similar to those identified by Crawford et al (1999) Clientsconnecting to the servers would immediately get an up-to-dateview of that particular domain which would be consistent with theviews of all of the other clients The client software would operatein a manner similar to conventional design applications There isalso clearly a requirement for integration between the differentdomain servers to enable conflicts to be resolved across domainsSimulation servers would integrate all of the scenarios that wouldenable an evaluation of the performance within any particular lifephase There would still remain the need to provide an effectivemanagement of different versions as well as a high-level coordi-nation structure to manage conflicts constraints design goals andcollaboration among designers However the underlying frame-work would provide the basis on which to construct this Despitebeing a significant step-change compared with current practicethis future technique proposes a viable solution to the effectivemanagement of a ship product model that may be manipulated andoperated upon in a distributed manner

This type of architecture does however raise a number of

issues relating to partnerships between the shipbuilding industryand the shipbuilding software industry because the system wouldrepresent an amalgamation of existing design and simulation ap-plications into a number of domain-specific servers The intellec-tual property rights as well as the ownership of both the technol-ogy and the data contained would clearly need to be resolved Inaddition the system calls upon the need to implement a standardfor the communication of the graphical objects that is both secureand robust whereas the standard for the data may be ldquoflavoredrdquoand managed effectively within the system via the ability to dy-namically load classes

Just as many of the precommissioning life phases are currentlybeing modeled it is anticipated that the rather poorly supportedpostcommissioning life phases will be catered for The most sig-nificant difference between pre- and postcommissioning is that itwill be the ship product model in its entirety that will be consid-ered For example there currently appears to be a significantopportunity for the specialization of the immersion of an entireship product model into an artificial environment to determine theoperational performance both at virtual sea (modeling existingshipping lanes to determine sea-keeping characteristics) within avirtual port (modeling existing ports to determine cargo-handlingcharacteristics) within a virtual shipyard for recommissioning(modeling existing shipyards to determine recommissioning capa-bility) and within a virtual breakers yard for disposal (to deter-mine scrap value) Increased opportunity would therefore be madefor designing the ship to meet a more rigorous set of customer-specified life-phase requirements and would represent a signifi-cant commercial advantage

It is also interesting at this point to note that a number of thecited papers have stated the need to avoid a reliance on computerprogrammers which in order to maintain even the simplest ofproduct data modeling systems seems unachievable

Conclusions

From the increasing amount of literature and the papers re-viewed within this paper related to the ship product model theprimary focus is on developing a standard representation for thedata contained within the model Despite not having yet finalizedthe standards for all aspects of the ship the STEP APs go a longway toward achieving this It is almost inconceivable to considerthat an alternative could compete against such a massive thrusttoward ship data standardization A number of instances havearisen however when the APs have been adhered to with theresult that ldquoflavorsrdquo or minor changes to the standard have beenrequired in order to utilize the structured well-defined and stan-dardized data within the legacy applications The question there-fore arises as to whether there is a requirement to standardize thelegacy applications such that they adhere to the data standard toenable a modular plug-in approach to ship design and simulation

Behavioral aspects have been considered within a number of thecited papers to be an important addition to the data in order toprovide the designer with additional feedback with respect to theoperation of the design This behavior may however be betterrepresented as high-level rules within a standard that are used todefine the operation of the ship rather than in existing standardsin order to minimize its impact on applications that have no needfor such data

A number of the tools and techniques discussed have described

the use of the ship STEP formats as being a mechanism for inte-grating existing legacy applications with a common model of shipproduct data Considerable benefit would be obtained from pro-viding similar integration between applications to progress fromthe limitations of discrete design and simulation toward having aholistic approach

The design tasks that are undertaken as part of the ship designprocess may well take a considerable amount of time and wouldconventionally result in ldquosnapshotsrdquo of the design artifact coin-ciding with the designer uploading data into the common modelA number of future directions have been discussed which wouldindividually require considerable development in order to imple-ment but which represent possible solutions to issues relating to

Continuous rather than ldquosnapshotrdquo ship product models Integration between the ship product model and the design

and simulation applications as well as across applications Removal of information translation problems through the

use of high-level graphical objects that are consistent betweenservers and applications

A collaborative framework on which to develop versionconflict and consistency management

Acknowledgments

The review was undertaken as part of an investigation intocommon model techniques within the VRShips-ROPAX2000project The authors gratefully acknowledge the support given bythe European Commission Community Research 5th Frameworkprogram under the area of Competitive and Sustainable Growthwhich provided the grant (G3RD-CT-2001-00506) that enabledthis work to be undertaken

References

BAUM S J AND RAMAKRISHNAN R 1997 Applying 3D product modelingtechnology in shipbuilding Marine Technology 34 1 56ndash65

CATLEY D 1999 Prototype STEP data exchanges in ship initial design andprovision of an application programmer interface to TRIBON Proceedings10th International Conference on Computer Applications in ShipbuildingJune Cambridge MA

CRAWFORD A K HARRINGTON G AMES R M AND VAN ESELTINE RT 1999 Neutral format data exchanges between ship product models andanalysis interfaces Proceedings 10th International Conference on Com-puter Applications in Shipbuilding June Cambridge MA

ERIKSTAD S O AND FATHI D E 1999 Applying the STEP shipbuildingprotocols as a basis for integrating existing in-house ship design applica-tions Proceedings 10th International Conference on Computer Applica-tions in Shipbuilding June Cambridge MA

GISCHNER B KASSEL B LAZO P WOOD R AND WYMAN J 2001 Evolution of STEP (ESTEP) exchange of shipbuilding productmodel data JOURNAL OF SHIP PRODUCTION 17 3 151ndash160

GRAU M AND KOCH T 1999 Applying STEP technology to shipbuildingProceedings 10th International Conference on Computer Applications inShipbuilding June Cambridge MA

HERZOG E AND TOumlRNE A 1999 A seed for a STEP application protocolfor systems engineering Proceedings 12th International Conference andWorkshop on the Engineering of Computer Based Systems Institute ofElectrical and Electronics Engineers Press Piscataway NJ 174ndash180

HIGNEY J T AND OUILETTE J J 1994 An engineering product modelbased on STEP protocols JOURNAL OF SHIP PRODUCTION 10 4 281ndash286

ISO 1996 Product Data Representation and Exchange Part 218 Ship Struc-

tures International Standards Organization Hamburg GermanyJOHANSSON K 1995 The product model as a central information source in

a shipbuilding environment Proceedings National Shipbuilding ResearchProgram 1995 Ship Production Symposium June Seattle WA

LAMB T CHUNG H AND SHIN J G 2000 A generic shipyard computermodel a tool for design for production Proceedings 7th IMDC NovemberKyung-Ju Korea

MARTIN D J 1980 The shipyard product information system as an aid toimplementing more productive strategies Proceedings Research and Engi-neering for Automation and Productivity in Shipbuilding IIT Research In-stitute October Chicago IL 81ndash101

POLINI M A AND MELAND K E 1997 The development and implemen-tation of a SMART product model for ship structure Proceedings 9thInternational Conference on Computer Applications in Shipbuilding Octo-ber Yokohama Japan

RANDO T C AND FERNHOLZ D 2000 MARITECHrsquos shipbuilding infor-mation infrastructure JOURNAL OF SHIP PRODUCTION 16 2 110ndash120

RANDO T C 2001 XML-based interoperability in the integrated shipbuild-ing environment (ISE) JOURNAL OF SHIP PRODUCTION 17 2 69ndash75

ROSS J M AND GARCIA L 1998 Making the jump to product modeltechnology JOURNAL OF SHIP PRODUCTION 14 1 15ndash26

ROSS J M AND ABAL D 2001 Practical use of 3D product modeling inthe small shipyard JOURNAL OF SHIP PRODUCTION 17 1 27ndash34

SCHMIDT W R VANDER J R AND SHIELDS V R 1990 Modelling andtransfer of product model digital data for the DDG 51 class destroyer pro-gram Proceedings National Shipbuilding Research Program 1990 ShipProduction Symposium August Milwaukee WI

SHIN Y AND HAN S H 1998 Data enhancement for sharing of shipdesign models Computer-Aided Design 30 12 931ndash941

VON HAARTMAN J KUUTTI I AND SCHAUMAN C 1994 Improving designproductivity with a product model for initial ship design Proceedings 8thInternational Conference on Computer Applications in Shipbuilding Sep-tember Bremen Germany

WELSH M LYNCH J AND BRUN B 1992 A data model for integration ofthe precommissioning life-cycle stages of the shipbuildingproduct JOURNAL

OF SHIP PRODUCTION 8 4 220ndash234WHITFIELD R I COATE S G DUFFY A H B AND HILLS

W 2000 Coordination approaches and systemsmdashpart I a strategic per-spective Research in Engineering Design 12 73ndash89

WYMAN J WOOLEY D GISCHNER B AND HOWELL J 1997 Development of STEP ship model database and translators fordata exchange between shipyards JOURNAL OF SHIP PRODUCTION 13 2111ndash124

Internet addresses

European Marine STEP Association httpemsagermanlloydorg

ISO STEP ship team http wwwnsnetcomNIDDESCt23html

Japan Marine Standards Association http wwwjecalsjipdecorjp

Korea STEP Centre httpksteporkr

the use of the ship STEP formats as being a mechanism for inte-grating existing legacy applications with a common model of shipproduct data Considerable benefit would be obtained from pro-viding similar integration between applications to progress fromthe limitations of discrete design and simulation toward having aholistic approach

The design tasks that are undertaken as part of the ship designprocess may well take a considerable amount of time and wouldconventionally result in ldquosnapshotsrdquo of the design artifact coin-ciding with the designer uploading data into the common modelA number of future directions have been discussed which wouldindividually require considerable development in order to imple-ment but which represent possible solutions to issues relating to

Continuous rather than ldquosnapshotrdquo ship product models Integration between the ship product model and the design

and simulation applications as well as across applications Removal of information translation problems through the

use of high-level graphical objects that are consistent betweenservers and applications

A collaborative framework on which to develop versionconflict and consistency management

Acknowledgments

The review was undertaken as part of an investigation intocommon model techniques within the VRShips-ROPAX2000project The authors gratefully acknowledge the support given bythe European Commission Community Research 5th Frameworkprogram under the area of Competitive and Sustainable Growthwhich provided the grant (G3RD-CT-2001-00506) that enabledthis work to be undertaken

References

BAUM S J AND RAMAKRISHNAN R 1997 Applying 3D product modelingtechnology in shipbuilding Marine Technology 34 1 56ndash65

CATLEY D 1999 Prototype STEP data exchanges in ship initial design andprovision of an application programmer interface to TRIBON Proceedings10th International Conference on Computer Applications in ShipbuildingJune Cambridge MA

CRAWFORD A K HARRINGTON G AMES R M AND VAN ESELTINE RT 1999 Neutral format data exchanges between ship product models andanalysis interfaces Proceedings 10th International Conference on Com-puter Applications in Shipbuilding June Cambridge MA

ERIKSTAD S O AND FATHI D E 1999 Applying the STEP shipbuildingprotocols as a basis for integrating existing in-house ship design applica-tions Proceedings 10th International Conference on Computer Applica-tions in Shipbuilding June Cambridge MA

GISCHNER B KASSEL B LAZO P WOOD R AND WYMAN J 2001 Evolution of STEP (ESTEP) exchange of shipbuilding productmodel data JOURNAL OF SHIP PRODUCTION 17 3 151ndash160

GRAU M AND KOCH T 1999 Applying STEP technology to shipbuildingProceedings 10th International Conference on Computer Applications inShipbuilding June Cambridge MA

HERZOG E AND TOumlRNE A 1999 A seed for a STEP application protocolfor systems engineering Proceedings 12th International Conference andWorkshop on the Engineering of Computer Based Systems Institute ofElectrical and Electronics Engineers Press Piscataway NJ 174ndash180

HIGNEY J T AND OUILETTE J J 1994 An engineering product modelbased on STEP protocols JOURNAL OF SHIP PRODUCTION 10 4 281ndash286

ISO 1996 Product Data Representation and Exchange Part 218 Ship Struc-

tures International Standards Organization Hamburg GermanyJOHANSSON K 1995 The product model as a central information source in

a shipbuilding environment Proceedings National Shipbuilding ResearchProgram 1995 Ship Production Symposium June Seattle WA

LAMB T CHUNG H AND SHIN J G 2000 A generic shipyard computermodel a tool for design for production Proceedings 7th IMDC NovemberKyung-Ju Korea

MARTIN D J 1980 The shipyard product information system as an aid toimplementing more productive strategies Proceedings Research and Engi-neering for Automation and Productivity in Shipbuilding IIT Research In-stitute October Chicago IL 81ndash101

POLINI M A AND MELAND K E 1997 The development and implemen-tation of a SMART product model for ship structure Proceedings 9thInternational Conference on Computer Applications in Shipbuilding Octo-ber Yokohama Japan

RANDO T C AND FERNHOLZ D 2000 MARITECHrsquos shipbuilding infor-mation infrastructure JOURNAL OF SHIP PRODUCTION 16 2 110ndash120

RANDO T C 2001 XML-based interoperability in the integrated shipbuild-ing environment (ISE) JOURNAL OF SHIP PRODUCTION 17 2 69ndash75

ROSS J M AND GARCIA L 1998 Making the jump to product modeltechnology JOURNAL OF SHIP PRODUCTION 14 1 15ndash26

ROSS J M AND ABAL D 2001 Practical use of 3D product modeling inthe small shipyard JOURNAL OF SHIP PRODUCTION 17 1 27ndash34

SCHMIDT W R VANDER J R AND SHIELDS V R 1990 Modelling andtransfer of product model digital data for the DDG 51 class destroyer pro-gram Proceedings National Shipbuilding Research Program 1990 ShipProduction Symposium August Milwaukee WI

SHIN Y AND HAN S H 1998 Data enhancement for sharing of shipdesign models Computer-Aided Design 30 12 931ndash941

VON HAARTMAN J KUUTTI I AND SCHAUMAN C 1994 Improving designproductivity with a product model for initial ship design Proceedings 8thInternational Conference on Computer Applications in Shipbuilding Sep-tember Bremen Germany

WELSH M LYNCH J AND BRUN B 1992 A data model for integration ofthe precommissioning life-cycle stages of the shipbuildingproduct JOURNAL

OF SHIP PRODUCTION 8 4 220ndash234WHITFIELD R I COATE S G DUFFY A H B AND HILLS

W 2000 Coordination approaches and systemsmdashpart I a strategic per-spective Research in Engineering Design 12 73ndash89

WYMAN J WOOLEY D GISCHNER B AND HOWELL J 1997 Development of STEP ship model database and translators fordata exchange between shipyards JOURNAL OF SHIP PRODUCTION 13 2111ndash124

Internet addresses

European Marine STEP Association httpemsagermanlloydorg

ISO STEP ship team http wwwnsnetcomNIDDESCt23html

Japan Marine Standards Association http wwwjecalsjipdecorjp

Korea STEP Centre httpksteporkr