SHIP PRODUCTION COMMITTEEFACILITIES AND ENVIRONMENTAL EFFECTSSURFACE PREPARATION AND COATINGSDESIGN/PRODUCTION INTEGRATIONHUMAN RESOURCE INNOVATIONMARINE INDUSTRY STANDARDSWELDINGINDUSTRIAL ENGINEERINGEDUCATION AND TRAINING

THE NATIONALSHIPBUILDINGRESEARCHPROGRAM

September 1991NSRP 0340

U.S. DEPARTMENT OF THE NAVYCARDEROCK DIVISION,NAVAL SURFACE WARFARE CENTER

1991 Ship Production SymposiumProceedings:Paper No. VB-1A Data Model for the Integration ofthe Pre-commissioning Life-cycleStages of the Shipbuilding Product

Report Documentation Page Form ApprovedOMB No. 0704-0188

Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering andmaintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information,including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, ArlingtonVA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if itdoes not display a currently valid OMB control number.

1. REPORT DATE SEP 1991

2. REPORT TYPE N/A

3. DATES COVERED -

4. TITLE AND SUBTITLE The National Shipbuilding Research Program, 1991 Ship ProductionSymposium Proceedings: Paper No. VB-1: A Data Model for theIntegration of the Pre-Commissioning Life-Cycle Stages of theShipbuilding Product

5a. CONTRACT NUMBER

5b. GRANT NUMBER

5c. PROGRAM ELEMENT NUMBER

6. AUTHOR(S) 5d. PROJECT NUMBER

5e. TASK NUMBER

5f. WORK UNIT NUMBER

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) Naval Surface Warfare Center CD Code 2230-Design Integration ToolsBldg 192, Room 128 9500 MacArthur Blvd, Bethesda, MD 20817-5700

8. PERFORMING ORGANIZATIONREPORT NUMBER

9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR’S ACRONYM(S)

11. SPONSOR/MONITOR’S REPORT NUMBER(S)

12. DISTRIBUTION/AVAILABILITY STATEMENT Approved for public release, distribution unlimited

13. SUPPLEMENTARY NOTES

14. ABSTRACT

15. SUBJECT TERMS

16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF ABSTRACT

SAR

18. NUMBEROF PAGES

23

19a. NAME OFRESPONSIBLE PERSON

a. REPORT unclassified

b. ABSTRACT unclassified

c. THIS PAGE unclassified

Standard Form 298 (Rev. 8-98) Prescribed by ANSI Std Z39-18

DISCLAIMER

These reports were prepared as an account of government-sponsored work. Neither theUnited States, nor the United States Navy, nor any person acting on behalf of the UnitedStates Navy (A) makes any warranty or representation, expressed or implied, with respectto the accuracy, completeness or usefulness of the information contained in this report/manual, or that the use of any information, apparatus, method, or process disclosed in thisreport may not infringe privately owned rights; or (B) assumes any liabilities with respect tothe use of or for damages resulting from the use of any information, apparatus, method, orprocess disclosed in the report. As used in the above, “Persons acting on behalf of theUnited States Navy” includes any employee, contractor, or subcontractor to the contractorof the United States Navy to the extent that such employee, contractor, or subcontractor tothe contractor prepares, handles, or distributes, or provides access to any informationpursuant to his employment or contract or subcontract to the contractor with the UnitedStates Navy. ANY POSSIBLE IMPLIED WARRANTIES OF MERCHANTABILITY AND/ORFITNESS FOR PURPOSE ARE SPECIFICALLY DISCLAIMED.

THE SOCIETY OF NAVAL ARCHITECTS AND MARINE ENGINEERS601 Pavonia Avenue, Jersey City, N.J. 07306

Paper presented at the 1991 Ship Production Symposium,The Pan Pacific Hotel, San Diego, California, September 3-6.1991.

A Data Model for the Integration of thePre-commissioning Life-cycle Stagesof the Shipbuilding ProductM. Welsh, Visitor, Engineering Design Center, University of Newcastle, UK,J. Lynch, Visitor, COTEC Computing Services, Sunderland, UK, and P. Brun, Visitor,lnstitut des Recherches de la Construction Navale, Paris, France

VB-1

ABSTRACT

This paper reports some aspects of the workbeing carried out on the NEUTRABAS projectunder the ESPRIT II European research program.The aim of this project is to specify and imple-ment a neutral product definition database forlarge marine-related artefacts, covering a largepart of the complete product life-cycle. Theresults of this research program will facilitate theeffective exchange of product-related databetween disparate computer-based informationsystems, and hence promote a movement towardsproduct life-cycle integration. The scope of theproduct model being developed as the basis forthis integration is described in terms of its spatialand steel structural components, together with theimplications for integration with other models ofoutfitting and engineering systems. The model isshown to encompass the wide range of product-related data which is associated with the variouspre-commissioning stages of the product life-cycle. A suitable database architecture designedto support product data exchange and full life-cycle integration based on this product model, isdescribed and discussed.

NOMENCLATURE

AEC

ASCII

CAD

CADEX

CAD*1

CALS

CEC

Architecture, Engineering and Con-struction.

American Standard Code for Infor-mation Interchange.

Computer Aided Design.

CAD Geometry Data Exchange.

CAD Interfaces.

Computer Aided Acquisition andLogistics Support.

Commission of the European Com-munities.

ED1

ESPRIT

IGES

IS0

Electronic Data Interchange.

European Strategic Program forResearch and Development in Infor-mation Technology.

Initial Graphical ExchangeSpecification.

International Standards Organisation.

NIDDESC Navy Industry Digital Data ExchangeStandards Committee.

SET Standard d’Exchange et de Transfert.

VDAFS Verband der Deutschen Automobilin-dustrie Plaechen Scnittstelle.

INTRODUCTION

The pre-commissioning stages in the life-cycle of large, complex engineering artefacts, ofwhich the shipbuilding product is an example, arenormally associated with the generation andmanagement of vast quantities of complex, inter-related product data. This data is concerned withall aspects of the product including its geometry,topology, functionality, the associated productionprocesses, production planning and control,materials, quality control and so on.

The scope and complexity of the product-related data being created and manipulatedthroughout the various pre-commissioning stagesof the complete product life-cycle, from require-ments analysis, through the various design stagesand finally into production, requires that equallycomprehensive and coherent data models bespecified and implemented to enable the effectivemanagement and exchange of such diverse pro-duct data between the associated applicationareas. The need for such data models is accen-tuated by the tendency to use increasingly com-plex heterogeneous computer-based informationsystems at the various pre-commissioning life-cycle stages. These life-cycle stages cover activi-ties such as marketing, conceptual design,

VB1-1

detailed design, drafting, materials ordering, pro-duction planning and control, scheduling, andquality control. The use of such diverse softwareand hardware systems presents considerable obs-tacles to the effective management and control ofthe massive amounts of data related to the pro-duct which these systems both generate and use.

In theory, a product data model could andshould be extended to cover the full life-cycle ofthe product, from the initial feasibilitystudies/requirements analysis, through the designand production stages, its operation, maintenance,possible upgrading and finally its de-commissioning and eventual demolition. Thiswould ensure that all information concerning theproduct would be available in a consistent andsystem-independent form throughout the full pro-duct life-cycle and even beyond. This period maytypically span more than 20 years; much longerthan several computer system hardware andsoftware architecture life-times. It is appreciated,however, that the definition and implementationof a complete product data model covering all ofthese aspects of the life-cycle of an engineeringproduct as complex as a ship is an onerous task,and one which would require the commitment ofa vast amount of time and effort.

This paper reports on work currently in pro-gress in Europe on the development of a datamodel which will facilitate the integration ofthose life-cycle stages of the shipbuilding productup to its commissioning and final hand-over.

STANDARDS FOR LIFE-CYCLE INTEGRA-TION AND PRODUCT DATA EXCHANGE

The many, non-trivial problems associatedwith the management and exchange of product-related data, have resulted in the inauguration ofa large number of separate, but largely comple-mentary initiatives, looking at the informationmanagement requirements of a wide range ofmanufacturing industries. These initiatives haveresulted in the specification of a number of stan-dards in the area of electronic data interchange(EDI). In some cases these specifications havebeen implemented to provide functioning dataexchange systems for a range of applicationareas.

Early attempts at the development of stan-dards for data exchange were largely concernedwith geometry-based information. One such stan-dard, IGES (Initial Graphical ExchangeSpecification) (l), allowed for the storage andtransfer of basic 2-dimensional geometry betweendifferent computer-aided design (CAD) systemsin a system-independent form. Although support-ing the integration of those activities which arebased upon geometrical data, IGES does not offerany facilities for the representation of information

VB1-2

regarding the topology, functionality, materialcharacteristics, production processes and manage-ment information associated with a product, andcannot therefore be used as a vehicle for theintegration of information flow throughout the thecomplete product life-cycle.

Standard for the Exchange of Product Data

One of the most significant attempts to cir-cumvent the limitations of standards such asIGES is currently being carried out by a commit-tee of the IS0 (International Standards Organisa-tion) and is commonly known as the Standard forthe Exchange of Product Data (STEP) (2). Theaim of this initiative is to provide a completerepresentation of all of the information which canbe associated with a product throughout its life-time in a completely system-independent form.That is, the basic goal is to enable a product tobe represented from the requirements definitionand conceptual design stages through to produc-tion, maintenance and eventual demolition. Thisrepresentation is intended to include all geometricand non-geometric data associated with that pro-duct. Information types to be represented includegeometry, topology, functionality, cost, materials,strength and safety. STEP is formulated in astructure consisting of an application layer uponan implementation layer, with the formercomprising the relevant, domain-specific datamodels, and the latter the actual implementationof these models. The EXPRESS data modellinglanguage (3) has been specifically developed foruse within the application layer.

A large number of individual data modelsreside within the STEP application layer, beingclassified as either application models or resourcemodels. Application models, such as the ship-building and the AEC (Architecture, Engineeringand Construction) models, address the require-ments of particular application areas. Resourcemodels, such as geometry or topology, are notgenerally associated with a specific applicationarea, but provide general facilities to applicationmodels. Resource models currently nearing com-pletion within the STEP standard includegeometry, topology, solids, features, material,presentation, AEC core and tolerances. Similarly,application models nearing completion includedrafting, ship structures, electrical applicationsand finite element analysis.

A STEP data model provides a description orspecification of a domain of interest and consistsof entities, attributes and relationships. Entitiesmay be either abstract, such as a powering calcu-lation, or concrete concepts such as a stiffenerpiece-part . Entities may be described by anumber of attributes and referred to other entitiesvia relationships. The data model containsdescriptions and other information including the

constraints upon the value of attributes, globalconstraints and textual descriptions with someexplanation of entities. All STEP data modelsare ultimately described in the EXPRESS datamodelling language.

The actual transfer of data between indivi-dual applications is achieved by means of a phy-sical file. The STEP standard allows for the useof ASCII characters only in the physical filedescription, and requires the format to be humanreadable. However, in the majority of cases it isnot necessary for the developer of a model to beaware of the actual appearance of the physicalfile.

Other Initiatives

In addition to STEP, a number of adjunctEDI projects are currently under development,some of which are providing a significant contri-bution to the STEP activities. Many of these ini-tiatives are collaborative ventures supported bythe Commission of the European Communities(CEC) under the ESPRIT program of researchand development.

ESPRIT (European Strategic Progmmme forResearch and Development in Information Tech-nology), founded in 1983 and currently at phaseII, has included a number of projects which havebeen significant to the development of STEP suchas CAD*I (CAD Interfaces) and CADEX (CADGeometry Data Exchange). Many other initia-tives, also related to STEP, have originated in theUnited States and Europe in support of a widerange of industrial interests. Examples of theseare the CALS (Computer-aided Acquisition andLogistics Support), NIDDESC (Navy IndustryDigital Data Exchange Standards Committee),SET (Standard d’Exchange et de Transfert) andVDAFS (Verband der Deutschen Automobilin-dustrie Flaechen Scnittstelle) initiatives. Furtherdetails of all of ‘these initiatives can be found in(4).

The one common aim that all of theaforementioned initiatives share, is that of provid-ing the means for the effective storage andexchange of product-related data betweendifferent applications in a completely system-independent form.

One other project which is making asignificant contribution to the STEP initiative isthe ESPRIT project NEUTRABAS (5), a projectwhich is specifically addressing the needs of theshipbuilding industry, and one which is the sub-ject of this particular paper.

NEUTRABAS - A NEUTRAL PRODUCTDEFINITION DATABASE FOR LARGEMULTI-FUNCTIONAL SYSTEMS

The shipbuilding industry in Europe has con-sistently been at the forefront of technologicaladvancement, with massive investment in compu-terized systems in all parts of the technical andproduction areas. This application of state-of-the-art technology, as illustrated by the introductionof computerized design and drafting systems,management information systems, and advancedautomated manufacturing technologies, hasrepeatedly highlighted the need for some meansfor consistently storing and transferring informa-tion in an electronic format, between the variousactivity areas.

This perceived need resulted in the develop-ment of a proposal for a collaborative projectunder the ESPRIT initiative, which would involvea team of industrialists, academics and computerscientists from four European countries. The threeyear NEUTRABAS project started in April 1989and involves fifteen partners from the UK,France, Germany and Spain. The overall aims ofthe project can be summarised in terms of fourmain points, as indicated below :

1.

2.

3.

4.

The standardization of the way in whichinformation concerning marine-related pro-ducts is represented;

The development of standard methods for theexchange and storage of product definitiondata in the marine industry;

The specification and development of a suit-able database architecture which will facili-tate the exchange and storage of such productdefinition data; and

The implementation of a prototype dataexchange and storage system, based on thepreviously defined database architecture,which will demonstrate the feasibility of atruly integrated product life-cycle.

The Anticipated Benefits of the NEUTRABASApproach

The most obvious of the anticipated benefitsto arise from the application of the NEUTRA-BAS philosophy is that of life-cycle stageintegration. This will be achieved through thecoherent and consistent storage and exchange ofproduct-related information between differentapplication systems. In addition to this, a numberof related benefits can be perceived, as indicatedbelow.

VB1-3

Reduced project time-scales - The adoptionof a single, carefully managed informationstore will enable overall project time-scalesto be reduced. This will be achieved throughthe rigorous control of information flow andthe subsequent avoidance of mis-matches ininformation requirement and availability ateach of the pre-commissioning life-cyclestages.

More effective information management - Asingle, shared information storage facilitywill enable the more effective managementof all product-related data including security,version control and data consistency issues.

Rapid information dissemination - The adop-tion of a common shared informationresource will result in more rapid informationdissemination among the various activitiesinvolved at each of the pre-commissioninglife-cycle stages.

Avoidance of data transcription - Theexchange of information between differentapplication systems in an electronic formatwill avoid the need for manual or mechanicaltranscription of the data, with the accom-panying risk of error introduction.

Improved supplier/client interface - In anindustry such as shipbuilding, which has ahigh level of bought-in items in its finishedproduct, considerable benefits will beobtained from the provision of componentand equipment catalogues and specificationsin an electronic format, which can be incor-porated into the product definition database.This will ensure that the most up-to-dateinformation is always available concerningitems of equipment obtained from outsidesources.

THE DEVELOPMENT OF A SHIPBUILD-ING PRODUCT INFORMATION MODEL

The main aim of the information modellingprocess is to develop a structured representationof the information associated with a real-worldphysical object, which extends over the requiredlife-cycle stages, and also supports the requiredviews or interpretations of the product at each ofthese specified stages.

According to STEP, the shipbuilding productis a specialisation of the general AEC (Architec-ture, Engineering and Construction) category ofreal-world physical products. The complete life-cycle of the shipbuilding product extends fromthe requirements definition/mission analysis stage,through the various design stages, into productionand then on to operation, maintenance and even-tual demolition. At each of these various life-

cycle stages, the actual physical object being con-sidered will normally be unchanged in the globalsense, although the information associated withthe product and the techniques used to representit will vary considerably. For example, at thevery earliest of the design stages, the conceptualdesign stage, the product will usually bedescribed in very general terms using high-level(global) information, such as intended speed,gross capacities, main dimensions etc. As thedesign stage progresses, additional informationconcerning the product will become available andso the early global product information will besupplemented by more detailed, lower-level infor-mation.

This evolution and maturing of the informa-tion associated with the product, as it progressesthrough its various life-cycle stages, demands thatany model of this information must be specifiedand developed with these life-cycle stages inmind. In the context of the NEUTRABAS projectit was not considered feasible to attempt to definean information model which would support all ofthe product life-cycle stages mentioned previ-ously, as this would require resources and exper-tise not available within the existing NEUTRA-BAS program. Those product stages which areconsidered in the NEUTRABAS product informa-tion models are associated with the pre-commissioning part of the product’s life-cycle.

It has already been mentioned that the infor-mation associated with the physical productmatures as the life-cycle progresses. In additionto this maturing process, the same information issubject to different points of view or intetpreta-tions during a given life-cycle stage. For exam-ple, if a physical entity such as a deck is con-sidered at the detailed design stage, the way inwhich this object is described will be dependentupon which particular design activity is beingconsidered. The draftsman producing scantlingdrawings will be primarily concerned with load-ings, material properties, stiffening arrangements,precise geometry and so on. Whereas the navalarchitect investigating flooding, stability and othersafety-related characteristics of the product mayconsider the same entity as a simple planar ele-ment without any of the previously mentionedcharacteristics.

It can ‘therefore be seen that different viewsor interpretations of the same product requiredifferent aggregations of the information associ-ated with the product. The problems associatedwith developing a coherent model of the informa-tion are further compounded by the conflictingapproaches used at the design and productionstages of the product life-cycle. For example,design is basically a top-down modelling activitywith global concepts being repeatedly decom-posed into smaller information-bearing units at

VB1-4

subsequent stages in the design process, with theassociated increase in the level of detail of infor-mation. In contrast, production-oriented informa-tion modelling follows a bottom-up strategy, withindividual information units being aggregated toform larger units and eventually the completeproduct definition.

In view of the above points, it can be con-cluded that any information model of a complexphysical product must not only possess the scopeand structure to reflect the evolution of the asso-ciated information as the product life-cycleprogresses, but must also be able to facilitatedifferent views of the product information at eachof these life-cycle stages. It is with these require-ments in mind that the information models ofNEUTRABAS have been developed to provide acomplete and coherent representation of the ship-building product, throughout the relevant life-cycle stages, which accommodates both thedecomposition and aggregation scenarios associ-ated with the pre-commissioning stages of thecomplete product life-cycle.

Information Modelling Techniques

The NEUTRABAS product model is basi-cally comprised of a large number of physicaland abstract objects which are described bymeans of sets of attributes. The formalspecification of this model is therefore mainlyconcerned with the complete and unambiguousdescription of these objects (entities) and attri-butes, together with the means by which they areinterrelated to form the complete description ofthe product. To this end, the description of theentities and attributes and the declaration of therelationships between them is achieved in threeways. First of all, a natural language (English)description of the entities and attributes is givenwhich explains the context in which they are usedand the restrictions or rules with affect theirusage. Secondly, the entities and attributes arerepresented in a graphical form. The techniqueused for this graphical representation is theNijssen Information Analysis Method (NIAM)(6), as adopted by the ISO/STEP community. TheNIAM diagrams illustrate the relationshipsbetween the various entities which comprise themodel, and also specify the restrictions imposedon the relationships between the individual enti-ties and attributes. The final method used todescribe the components of the product model isthe EXPRESS information modelling language.This language provides a means of generating aformal, standardized textual description of thecomponents of the model, together with the rela-tionships between the various entities and attri-butes involved.

When combined, the three methods described

above provide a complete and coherent descrip-tion of the product information model of NEU-TRABAS which forms the basis for the imple-mentation and testing phases of the projectdescribed in subsequent sections of this paper.

THE NEUTRABAS PRODUCT MODEL

An analysis of the form and structure of theinformation associated with the shipbuilding pro-duct identifies four basic views of the informationwhich combine to give a complete description ofthe product throughout its pre-commissioninglife-cycle stages. These four views are listedbelow.

1. Marketing-oriented view;

2. Management-oriented view;

3. Design-oriented view; and

4. Production-oriented view.

Clearly, a shipbuilding product model mustsupport each of these high-level views of theproduct-related information in order that integra-tion of the associated activities and life-cyclestages can be supported.

When commencing the analysis of the infor-mation to be modelled, it is convenient tocategorize the information in terms of whether itis associated with the hull of the vessel or withthe machinery and outfitting systems. Thisenables the information analysis in these twocomplementary areas to be carried out in parallel,with agreed integration points providing themeans for the concatenation of the two sub-models. In the context of NEUTRABAS, thisapproach was adopted in the product modellingprocess with the result that two informationmodels were developed covering the informationconcerned with the hull of the vessel, and thatassociated with the machinery and outfitting sys-tems. This paper is primarily concerned with themodel which describes the information associatedwith the hull of the vessel and which covers boththe steel structure and the spatial arrangement ofthe product.

The High-Level Product Model

In very general terms, information relating tothe shipbuilding product can be placed into oneof three main categories :

1. Global information;

2. Information relating to the hull; and

3. Information relating to machinery andoutfitting systems.

VB1-5

Fig.1 NIAM diagram of the NEUTRABAS high-level model.

Therefore, at the highest level, a shipbuildingproduct information model can be considered ascomprising separate sub-models of global, hulland machinery/outfit information, as shown inNIAM form in Fig.1.

The Hull Model

As mentioned previously, a product modelcontains descriptions of a number of physical orabstract objects and their associated attributestogether with details of their relationships withother objects. In the context of the NEUTRABAShull model, the entities can be divided into twomain categories; those associated with therepresentation of the structure of the the vesseland those associated with its spatial organization.Although these two groupings can be consideredas distinct concepts, in reality they are mutuallydependent, a fact which is reflected in the NEU-TRABAS hull model.

The spatial organization model. Referenceto the spatial characteristics of the shipbuildingproduct will be found at all of the pre-commissioning life-cycle stages. In fact, the ear-liest of the design-related stages, the conceptualdesign stage, is almost entirely concerned withthe spatial aspects of the product, i.e. thedefinition of an acceptable general arrangementfor a design proposal. This will involve the mani-pulation of simple planar elements which com-

bine to form the boundaries of enclosed spaces orcompartments, and the gross sub-division of theproduct into various functional zones, i.e. cargospaces, machinery spaces, accommodation etc. Itshould be appreciated that the decisions made atthis stage in the design process concerning thespatial organization of the product can have asignificant effect on the overall quality of thefinished product in terms of both its productionand operational characteristics. Even at this earlystage, the spatial organization of the product willbe related to production, operational and otherconsiderations. For example, the disposition ofthe main transverse sub-division members willnormally be based on standard lengths of cargoholds, derived either from consideration of thesize of cargo units to be carried (containers, pal-lets etc.), or from the maximum plate size whichcan be accommodated by the production facilitiesbeing considered (reduced work content etc.).

At each of the stages in the complete productdesign cycle, information relating to the spatialorganization of the product will be required asthis forms the basis for many of the associateddesign activities. In fact, many design activitiesrely solely on the availability of spatial-orientedinformation relating to the product. The nature ofthis information will change as the design processprogresses from the concept stage to the detailedproduction-oriented design stage, reflecting theevolution and maturing of the product description.

VB1-6

Fig.2 NIAM diagram of the spatial organisation model.

The need for the spatial organization model toreflect this evolution of the product definitionthrough the various life-cycle stages and to sup-port different views of the information, is there-fore quite obvious.

In the context of NEUTRABAS, the spatialorganization model is comprised of a number ofbasic elements which combine to supportgeometrical, topological and functional descrip-tions of the space-related characteristics of thecomplete product. These components of theNEUTRABAS spatial organization model areshown in NIAM form in Fig.2. The aim of thisspatial model is to support the many applicationswhich require space-oriented product informationpertaining to the various pre-commissioning life-cycle stages.

It is to be appreciated that the spatial organi-zation model, like all of the other NEUTRABASinformation models, draws upon the informationcontained in the general resource models of STEPsuch as those concerned with geometry and topol-ogy. The integration of these general models withthe spatial organization model removes the needfor the explicit declaration of the associated enti-ties within the model being described here.

As can be seen in Fig.2, the NEUTRABASspatial organization model is basically a collec-tion of systems which combine to describe thegeometrical and topological characteristics of theinternal organization of a vessel. These includethe definition of the surfaces which combine toform the internal arrangement of the product, theinternal enclosed spaces or compartments, and thereference systems which facilitate the orientationand location of components of the product in

VB1-7

Fig.3 NIAM diagram of the global reference system concept.

three-dimensional space.

In order to illustrate the breadth and depth ofthe NEUTRABAs spatial organization model thefollowing paragraphs describe a number of thecomponents of the model in terms of the entitiesinvolved together with their associated attributesand their relationships with other entities.

The global reference system. Thereference system is perhaps one of the mostimportant components of the spatial organizationmodel as it provides the means for the orientationand location of all of the abstract and physicalobjects associated with the definition of the pro-duct. The NEUTRABAS global reference systemconcept is shown in NIAM form in Fig.3, andcan be seen to comprise a number of elements as

VB1-8

listed below :

• one or more transverse reference planes;

• one or more longitudmal reference planes;

l one or more horizontal reference planes; and

• a co-ordinate system.

Transverse, longitudinal and horizontal refer-ence planes can be associated with the locationand orientation of physical entities such asframes, bulkheads, decks and so on, or abstractentities such as the boundaries of functionalzones. The co-ordinate system component is itselfcomprised of two separate parts; a reference co-ordinate system and an axis set. This referenceco-ordinate system has associated with it a globalorigin and its own axis set. The global referencesystem concept is shown diagrammatically inFig.4.

Horizontal

Axis Set ReferenceLongitudinal

Plane Reference

YPlane

XReferenceCo-ordinate Z

System

Fig.4 Diagrammatic representation of theglobal reference system concept.

Internal compartmentation. The spatialorganization model, as its name suggests, is alsoconcerned with the representaion of the internalenclosed spaces on a vessel. This representationrequires the introduction of the concepts ofspaces, compartments and moulded surfaces.Moulded surfaces are non-structural boundarieswithin the overall envelope of the product, whichmay provide the topological and geometricalreferences for associated structural boundaries.Monlded surfaces may also form part of theboundaries of physical or hypothetical enclosed

spaces within the internal arrangement of the pro-duct. A variety of means can be used to definethese surfaces including a variety of mathematicaltechniques such as the Bezier and B-spline for-mulations. The NIAM representation of themoulded surface concept is shown in Fig.5,which also indicates the various attributes whichare associated with a particular occurrence of amoulded surface.

As mentioned above, moulded surfaces candefine the boundaries of the internal enclosedspaces on a vessel. These spaces can either behypothetical sub-divisions of the vessel, as in thecase of a functional sub-division, or physicalcompartments used for the carriage of revenue-earning material or material required for theeffective operation of the vessel such as fuel oiland water. The compartment concept is shown inNIAM form in Fig.6, and diagrammatically inFig.7. Fig.6 shows the various types of compart-ments which can be found on a vessel, with theattributes which can be possessed by any com-partment being shown in NIAM form in Fig.8,although it should be appreciated that particulartypes of compartments will have additional attri-butes which are peculiar to them.

As mentioned previously, the spatial organi-zation model is closely related to that of thestructural organization as it provides referencesfor the location and orientation of the associatedstructural components. Additional details of theNEUTUBAS spatial organization model can befound in (7).

The structural organization model. TheNEWTRABAS structural organization model islargely based upon a top-down analysis of theinformation associated with the representation ofthe structural components of the shipbuilding pro-duct. The structure of the model is based uponthe repeated decomposition of the information- bearing units into their constituent parts until therequired level of granularity or detail is achieved.This approach can be compared to the overalldesign process where high-level representationsof the product are repeatedly refined until thecomplete product is defined in terms of individualpiece-parts and components. This top-down viewof the product may be representative of thedesign process, but is in direct opposition to thenormal production-related view which tends tofollows a bottom-up approach where individualpiece-parts and components are aggregated toform sub-assemblies, assemblies, units, blocksand eventually the complete product. Therefore,in order to support the information requirementsof the production-related life-cycle stages, theNEUTRABAS structural model has to supportboth the decomposition and aggregation views ofthe product.

VB1-9

Fig.5 NIAM diagram of the moulded surface concept.

The generalised NEUTRABAS structuralorganization model is shown in NIAM form inFig.9. The diagram shows that the structural sys-tem of the shipbuilding product is considered ascomprising a number of non-overlapping struc-tural elements, where each of these structural ele-ments corresponds to a functional zone of thevessel, i.e. a double-bottom region or a mainengine compartment. These individual structuralelements are composed of a number of pre-fabricated blocks which are themselves made upof pre-fabricated sub-blocks or units which con-tain assemblies of plate and stiffener piece-parts.This decomposition is illustrated in NIAM formin Fig.10, and shown diagrammatically in Fig.11.It can be appreciated that this type of representa-tion of the information associated with the struc-ture of the vessel is predominantly a production-related view of that product as these pre-

fabricated blocks and sub-blocks are the primaryoutputs of the various production processes.However, the general model also incorporates adifferent view of the structural representation ofthe product, one which is associated with thevarious design stages. This design-related viewconsiders the structural elements to be comprisedof a collection of primary sub-structures whichcorrespond to the major plate panels togetherwith their associated stiffening members. Theseplate panels represent the major structural entitiesof the vessel such as complete decks, bulkheadsand the outer shell. This type of representation iscomparable with the view often used at thedesign stages where the structural arrangement ofcomplete decks or bulkheads are consideredwithout regard for the eventual sub-division ofthe entities which is required for the productionprocesses, and is shown in NIAM form in Fig.12.

VB1-1O

Fig.6 NIAM diagram of the compartment concept.

Moulded Surface

Fig.7 Diagrammatic representation of the compartment concept.

VB1-11

Fig.8 NIAM diagram of the compartment concept and attributes.

VB1-12

Fig.9 NIAM diagram of the general structural model.

VB1-13

Fig.10 NIAM diagram of the sub-block concept.

The NEUTRABAS structural model has beendeveloped so as to support both of the major

Model Integration

views of the product which are associated with The previous sections have briefly describedthe pre-commissioning life-cycle stages, i.e. a few of the components of the NEUTRABASdesign and production. The complete model hull information model. The complete hull modeldefines all of the information which can be asso-ciated with the structural system of the product

provides a comprehensive definition of the typeand structure of the information which can be

including information such as the type and gradeof materials, the weights and centres of parts and

associated with the hull part of the shipbuilding

assemblies, details of welding procedures, andproduct. It should however be appreciated that

production management information, as well asthe hull model is only one part of the complete

information concerning the precise geometry anddescription of the complete product, and that thevarious systems which are installed in the hull

scantlings of individual parts and assemblies.Further details of the structural model can be

such as HVAC, electrical, pumping and the vari-

found in (8).ous machinery systems, are of equal importancein the specification of the complete shipbuilding

VB1-14

Fig.11 Diagrammatic representation of the sub-block concept.

product model. The machinery and outfitting sys-tems model is fully described in (9). In addition,the various resource models defined by STEPhave to be integrated so as to provide access todescriptions of entities dealing with topics suchas geometry and topology.

The integration of these separate sub-modelsinto a single product model is currently receivingconsiderable attention within the NEUTRABASproject, as it is this fully integrated model whichwill form the basis for the implementation of theproduct definition into a working data exchangeand storage facility.

THE NEUTRABAS SYSTEM ARCHITEC-TURE

As previously stated, the NEUTRABAS pro-ject is different from many of the related activi-ties in that it will be taken beyond the formalspecification stage and will achieve partial imple-mentation. In order to reach this implementationphase, a significant part of the effort associatedwith NEUTRABAS has been devoted to thespecification and implementation of a suitablesystem architecture, as described in (10), whichwill facilitate the effective management andtransfer of product data in the shipbuilding indus-try context. A brief description of the main

features of the NEUTRABAS system architectureis given in the following sections.

Requirements of the Proposed Architecture

When considering a suitable system architec-ture for the NEUTRABAS project, a number ofsignificant requirements were identified, as indi-cated below.

The system would have to be hardware andsoftware independent as the typical shipbuild-ing product life-cycle is in excess of 20years; a period far exceeding the current andanticipated life-spans of both computerhardware and software.

The system would have to be capable of stor-ing both information models and data modelsas the storage of data only in a neutral for-mat is of no real value. The semantics of therelationships between the data items will alsoneed to be defined and stored.

The system would need to be independent ofthe application area. As NEUTRABAS isintended to cover all of the pre-commissioning stages of the product life-cycle, it has therefore to be capable of stor-ing information together with the view or

VB1-15

INTEGRATION POINT :HULL SPATIAL ORGANISATION

Fig.12 NIAM diagram of the structural element concept.

interpretation of that information for any The Proposed Architectureapplication system at any stage in theproduct’s pre-commissioning life-cycle.

l The system would have to be dynamic asNEUTRABAS will be able to share informa-tion between large number of application sys-tems and users, and must therefore have thecapability to interrogate and update the data-base asynchronously. Equally, it must allowfor the evolution of the information modelitself.

The proposed main components of the com-plete NEUTRABAS implementation environmentare shown diagrammatically in Fig.13. The NEU-TRABAS system architecture is intended to pro-vide all of the means necessary for the creationof schemata, from previously defined productinformation models, for a variety of databasemanagement system architectures; the facilitiesneeded for the effective management of productdata contained in these databases; and the variousinterfaces which will permit various applicationsystems to communicate with this neutral

VB1-16

1 Application

DataDictionaryInterface

Data Management Interface

Data Management Kernel

Virtual Database Interface

Interface- - - - - - - - - - -

Object-ODatabase

DatabaseInterface- - - - - - - - - -

STEPW Form

Object-O STEPDatabase Working

System Form

DatabaseInterface

- - - - - - - - - - -

.... . .

Fig.13 The NEUTRABAS system architecture.

application-independent store of product informa-tion. The main features and functions of each ofthese components are outlined in the followingsections.

The EXPRESS model. This component ofthe system is the domain-specific informationmodel which completely defines the shipbuildingproduct in terms of the information used todescribe and represent it at each of its life-cyclestages. The model is independent of any applica-tion, and is written in the STEP informationmodelliig language EXPRESS. The model itselfwill not be static, and will continue to evolve

over time.

The data dictionary. The data dictionarycontains the dynamic form of the EXPRESSmodel described above. It comprises a formaldefinition of the structure of the data contained inthe database, together with information concem-ing how the individual items of data are relatedto each other. The data dictionary allowsrequests to the database to be validated or it canalternatively be used to return the completedefinition of the structure of an entity. This par-ticular component can also be used to controlsecurity issues such as update rights, view rights,

VB1-17

versionning etc. for all of the requesting applica-tion systems.

EXPRESS import. The EXPRESS importfacility is a software tool which maps from theEXPRESS-based product information model tothe data dictionary defined in the above section.

The data management component (DMC).The data management component is effectivelythe core of the NEUTRABAS system. Its maintasks are to facilitate communication between theother components of the system and to convertrequests in any one system-specific format to thatof any other system. In order to carry out thesetasks, the data management component consistsof four main sub-components, as describedbelow.

1.

2.

Data Management Interface - This is theexternal view of the NEUTRABAS systemwhich contains a procedural interface toallow individual application systems to com-municate with the neutral database.

Data Management Kernel - This componentallows the creation, modification and query-ing of items of information by the connectedapplication systems. To facilitate this, thedata management kernel uses the data struc-ture and relationship definitions contained inthe data dictionary component described pre-viously. Those requests received from thedata management interface are reduced tomore simple instructions by the data mange-ment kernel before being passed on to thevirtual database interface.

3.

4.

VB1-18

Data Dictionary Interface - This allows theother elements of the data management com-ponent to query the data dictionary fordetailed information on entities and theirassociated attribute structures.

Virtual Database Interface - This is a pro-cedural interface which allows different data-base management systems (DBMS) to beconnected to the NEUTRABAS system, inorder to provide storage and data manage-ment facilities.

The application interface. The applicationinterface is the specific interface which residesbetween a given application system and the neu-tral database. The interface itself may be one oftwo types. It may either be interactive or can sim-ply consist of a pair of pre and post-processors,depending upon the nature of the specific applica-tion system being considered. The interface maybe written in any high-level programminglanguage providing that a suitable language bind-ing is available.

The database interface. The database inter-face is the specific interface which permits com-munication between a particular database manage-ment system and the neutral database, and is amapping of the virtual database interface onto anactual database system. Unlike the applicationinterface, the database interface can utilizeaccepted database standards such as SQL (struc-tured query language) for complete classes ofdatabase management systems. The databaseinterface is a vital component of the NEUTRA-BAS system architecture, as it is intended that aNEUTRABAS product model will be capable ofbeing stored in any commercial database system.

The database generator. The database gen-erator is a tool which will map the definition ofthe product information model contained in thedata dictionary to a specific database implementa-tion. While performing this task it updates thedata dictionary so as to provide informationregarding the location of entities and their associ-ated attributes in the actual database system. It isquite obvious that a separate database generator isrequired for each specific database managementsystem being considered for connection to theneutral database. At present, consideration hasbeen limited to the relational and object orienteddatabase paradigms, together with the STEPworking form file although it is hoped that otherdatabase types will be considered in the future.

THE PROTOTYPE IMPLEMENTATIONSYSTEM

The previous sections of this paper havedescribed various aspects of the informationmodel of the shipbuilding product which has beendeveloped to form the basis of the NEUTRABASdata exchange and storage system, together with asuitable architecture for the actual implementationof the system in the shipbuilding environment. Inorder to validate both the information model andthe proposed system architecture it is necessary toperform some form of implementation to demon-strate the controlled exchange of product-relatedinformation between two or more disparate com-puter systems, and also to demonstrate the con-sistent time-independent storage capabilities ofthe NEUTRABAS system. Unfortunately, due tolimitations on time and other resources, it is notconsidered feasible to implement a full version ofthe NEUTRABAS product model or attempt toproduce all of the software tools specified in thesystem architecture. However, a significant sub-set of the complete product model specificationwill be implemented, as will the key softwaretools, in order to provide a realistic test environ-ment for the NEUTRABAS approach.

Although the aim of NEUTRABAS is tofacilitate the complete integration of all informa-tion systems in use at all of the product life-cycle

stages, for the purpose of validating the basicphilosophy it has been decided to connect two,possibly three, different application systems to theNEUTRABAS system. The two definite candi-dates for this prototype testing system areCADIS, a steel structure design system, andCRESTA which is a production planning sytstem.The third possible candidate is a preliminary shipdesign system named SPAN, which will beincluded in the validation exercise if resourcespermit. Even with only two application systems itwill be possible to demonstrate how systems indifferent application areas, each having a differentview of the product, can be made to communicatein an effective manner and share common infor-mation in a coherent and consistent way. Thusdemonstrating that the true goal of a fullyintegrated product life-cycle is indeed one whichcould be achieved.

As previously stated, the testing system willinvolve the implementation of only a sub-set ofcomplete shipbuilding product model. This sub-set will in fact comprise part of the steel structureof the cargo region of a container carrying mer-chant vessel, consisting of a number of pre-fabricated production units. It is considered thatthe selected sub-set contains sufficient entitiesfrom the complete model to provide quite arigorous test of the NEUTRABAS philosophy inthe area of preliminary and production-orienteddesign, and in the complementary area of produc-tion planning and control.

The ORACLE relational database manage-ment system has been selected to provide themeans for the storage and retrieval of the physi-cal data created and used by the application sys-tems, although in theory any relational or object-oriented database system could have been chosen.At the time of writing this paper, work iscurrently being carried out on the implementationof the prototype system with its completion beingscheduled for March 1992.

CONCLUSIONS

This paper has described some of the workbeing carried out on the NEUTRABAS project inthe area of neutral data exchange and storage inthe shipbuilding industry. The progress outlinedin this paper has demonstrated the feasibility ofachieving a truly integrated shipbuilding environ-ment through the coherent and consistent storageand exchange of information relating to the pro-duct at all of the pre-commissioning stages in itslife-cycle. An information model of the shipbuild-ing product which will accommodate the variousviews and information requirements of the manycomputer-based systems used in the Europeanshipbuilding industry has been described. A neu-tral system architecture which will facilitate theimplementation of this information model and

subsequently provide database management func-tions for the manipulation of the variousproduct-related data created and used by the vari-ous application systems in use in the shipbuildingenvironment, has also been described. In addition,the proposed prototype implementation systemwhich will demonstrate the application of theNEUITRABAS concepts in a working environ-ment has been outlined.

NEUTRABAS is only one of many initia-tives being carried out in the area of product dataexchange throughout the world. It is, however,considered to be one of the leaders in this fieldand as such is actively contributing to the emerg-ing international standard for the exchange ofproduct data, STEP.

ACKNOWLEDGEMENTS

The authors would like to express their sin-cere thanks to all of their NEUTRABAS col-leagues, past and present, for their contributionsto the work reported in this paper. Gratitude isalso expressed to the Commission of the Euro-pean Communities (CEC) for their support of theNEUTRABAS project (No.2010) under theESPRIT II initiative.

REFERENCES

1.

2.

3.

4.

5.

6.

7.

B.M. Smith, IGES : a Key to CAD/CAM SYS-terns Integration, IEEE Computer GraphicsApplications, Volume 3, No.8 November1983.

IS0 TC184/SC4/WGl, IS0 STEP BaselineRequirements Document (IPIM), Tokyo,October 1988.

IS0 TC/184/SC4/wGl, EXPRESS LanguageReference Manual, working document, May

B.J. King, An Introduction to STEP, reportEDCN/DDEX/DISC/2/1, Engineering DesignCentre, University of Newcastle, May 1990.

ESPRIT 2010 - NEUTRABAS, TechnicalAnnex., February 1990.

G. Verheijen and J. VanBekkum, NIAM : AnInformation Analysis Method, in InformationSystem Design Methodology, edited by T.Olle, H. Sol and A. Verrijn-Stuart, North-Holland 1982.

M. Welsh et al., Formal Specification of theHull Spatial Organisation Model, NEUTRA-BAS, Workpackage 3, Deliverable 3.2.1,January 1991.

VB1-19

8.

9.

J.G. Julienne et al., Specification Relating tothe Structural System, NEUTRABAS, Work-package 3, Deliverable 3.2.2, October 1990.

M.G. Lehne et al., Analysis of Outfitting Sys-tem Structure - NEUTRABAS Draft Modelfor Outfitting Systems, NEUTRABAS, Work-package 4, Deliverable 4.1.6, January 1991.

10. S. Mullenbach et al., System Architecture,NEUTRABAS, Workpackage 1, Deliverable1.1.3, December 1989.

VB1-20

Additional copies of this report can be obtained from theNational Shipbuilding Research and Documentation Center:

http://www.nsnet.com/docctr/

Documentation CenterThe University of MichiganTransportation Research InstituteMarine Systems Division2901 Baxter RoadAnn Arbor, MI 48109-2150

Phone: 734-763-2465Fax: 734-936-1081E-mail: Doc.Center@umich.edu