Database Systems for Hull Form Design

SNAMETransactions, Vol.98, 1990,pp. 537-564

Database Systems for Hull Form Design Bruce Johnson, Member, Nikolaos Glinos, Visitor, Nancy Anderson, Associate Member, U. S. Naval Academy, Annapolis, Maryland, Donald McCallum, Member, Naval Sea Systems Command, Arlington, VA, William Beaver, Member, David Taylor Research Center, Bethesda, Maryland, Patrick Fitzsimmons, Member, BMT CORTEC, Ltd. Wallsend, England

NAVSEA Naval Sea Systems Command NIDDESC Navy/Industrial Digital Data Exchange Standards Committee National Shipbuilding Research Program NSRP OODBMS Object Oriented Database Management System Product Definition Exchange Standards PDES RDBMS Relational Database Management System Structured Query Language SOL I'VI'C Standard Symbols and Terminology SS&T Standard for the Exchange of Product Model STEP Data

ABSTRACt

The conceptual design of optimal ship hull forms involves investigating the effects of hull geometry variations on hydrodynamic performance characteristics. An easily accessed hull form design database containing performance data on a wide range of previous designs can shorten the time required during early stage design to achieve the hydrodynamic performance goals of a given design. Such a database would also be extremely valuable in validating Hydro-Numeric design codes. A survey of existing and proposed hull form design systems worldwide suggests that the development of standardized neutral formats for digital data exchange would greatly improve the ship designer's access to a wide range of existing hull geometry/ship performance data. It is proposed that the International Towing Tank Conference (rITC) cooperate with other international standards organizations in developing standardized neutral formats for the efficient exchange of digital hull form performance data.

1. INTRODUCTION The advantages of an integrated hull form hydrodynamic design system which fully accesses and utilizes historic data are many. An excellent example of what can be accomplished (even without full integration) is the design of the SL7 class of high-speed containerships for SeaLand by MARIN (Marine Research Institute, Netherlands) [1]. Despite extensive model testing of different bulb and stern configurations, the design goal for speed was not being met. In a very constrained time frame MARIN developed a hull form based on its historic data which, when tested, proved significantlybetter than any previous design, and met the required design speed of 33 knots. Note that extensive model testing of new hull forms was used in a what if mode because bulb and stern configurations for 33 knot ships represented a case where little guidance was available from the various 'first level' computer codes based on regression analysis of historical data. Consider how much more efficient this process could be if CFD tools such as those discussed at this symposium were integrated into CAE/CAD/CFD/CAM/DBMS systems which would be used to solve such problems in the future. Clearly, hull geometry codes, CFD codes, model tank testing and other hull form design tools would be more useful to the ship design community if they were efficiently linked to each other and to standardized neutral format databases containing hull form and propeller geometry data from previous ship designs and the corresponding hydrodynamic performance characteristics from both model and full scale tests. Using computer-linked combinations of design tools, a

NOMENCLATURE Advisory Group for Aerospace Research and Development British Maritime Technologies BMT Computer-Aided Design CAD CADAS Computer-Aided Design Analysis Computer-Aided Engineering CAE Computer-Aided Logistics Support CAI_~ Computer-Aided Manufacturing CAM Computational Fluid Dynamics CFD Computer Graphics Metafile CGM Computer-Integrated Manufacturing CIM Data Base Management System DBMS David Taylor Research Center DTRC HYDDB Hydrodynamic Design Data Base International Conference on Computer ICCAS Application in the Automation of Shipyard Operations and Ship Design Initial Graphics Exchange Specification IGES Integrated Programs for Aerospace-Vehicle IPAD Design International Standards Organization ISO International Towing Tank Conference ITI'C MARIN Marine Research Institute Netherlands

AGARD

537

naval architect could accurately and expeditiously optimize hydrodynamic performance and compare his/her design with other ship hull forms with similar mission requirements. This type of "integrated" hull form design system could provide the following benefits: • Lower initial acquisition costs via substantial savings in time and money in the ship design process, including more effective use of engineering manpower • Cost effective ships for various mission profiles • More energy efficient hull forms with lower operating costs • Improved performance for onboard systems because of larger operational envelopes As discussed in this paper, there are large international programs attempting to standardize the electronic transfer of manufacturing (product definition) data from preliminary design through production [2], [3]. These phases of the production cycle consume approximately 95% of the total costs, so making data transfers more efficient can make for large cost savings, even when the design requires only a few changes before entering production. A recent Business Week article [4] estimated, however, that concept design, which is generally less than 5% of total costs, commits 40% to 60% of later spending and that the cost of design changes increases by an order of magnitude at each major stage of design and production. This paper reviews the historical and current developments in integrated vehicle design systems, especially the database enhancements essential to efficient hull form design which can make "Concurrent Engineering" cost effective for the ship design process. 2.

THE DEVELOPMENT OF VEHICLE DESIGN SYSTEMS

INTEGRATED

One of the first large scale attempts to reduce time and cost and consequently the number of '"oottlenecks" in the design process for complex systems was the IPAD (Integrated Programs for Aerospace-Vehicle Design) Project carried out from 1971-1984 as a $30M cooperative government/industry venture under the sponsorship of NASA, and later the U. S. Navy (see Fulton [5]). The principal contractor on the project was the Boeing Commercial Airplane Company from 1976-1984. According to Miller, [6] "I'he requirements were for a general purpose, interactive computer aided engineering (CAE) system capable of supporting engineering data associated with the design process, including manufacturing interfaces. The system would serve management and engineering staffs at all design levels as well as the downstream manufacturing processes." [6] The goal of the project was to improve aerospace productivity through better CAD/CAM information management including the development of a prototype for a future integrated CAD system as illustrated in Figure 1. 538

Fig. 1 Prototype integrated design system (adapted from Fulton [5])

The IPAD project envisioned a global database management system built around a common Relational Information Management (RIM) database manager (Blackburn [7]). The data in the database "..would include all official project information defining the characteristics of current baselines and alternative designs and their performance, as well as archivai 'handbook' information forming the technology base for company designs." [7] Various schemes for storing the necessary geometric data included the use of the Initial Graphics Exchange Specifications (IGES) derived from experience gained with the Boeing CAD/CAM Integrated Information Network (CIIN) and General Electric's Neutral Database (Wilson [8]) as well as other approaches (Dube [9]). Fulton [5] concluded that, "...a single product definition database containing an electronic description of the designed products that are being constructed or manufactured is a keystone to the successful utilization of CAD/CAM technology.... (however) a key data management requirement not yet commercially available is the ability to manage unified CAD/CAM information distributed across computers of different manufacture (Figure 2) ....(thus) the original intent of an integrated software system was abandoned as being too expensive, inappropriate for NASA, and not the best use of the limited R & D resources." [5] 2.1

Hull form design/manufacturing database developments

support

Today, there are numerous design/manufacturing support databases for many aspects of ship, aircraft, and land vehicle design. Most frequently they are used to store the details of the post-conceptual design process for use in the manufacturing process: drawing numbers, weight estimates, arrangements plans, parts lists, structural details and other information needed to produce a product or system. If one considers the stages of the so-called basic ship design spiral (see, for example, Figure 1 in Ship Design and Construction by Taggert [ 1 0 ] ) , existing integrated database

Database Systems for Hull Form Design

IBM

s~L

1

TRANSLATOR

j

VAX

CYBER DB STANDARD

[PIP TRANSLATDR

Fig. 2

FORMAT

RIM

FILE

TRANSLATOR

Database file transfer environment (adapted from Fulton [5])

development efforts have largely concentrated on interfacing the output of the preliminary design process with the contract and detail design and manufacturing process, i.e. the CAD/CAM/CIM (Computer-Aided Design/Computer-Aided Manufacturing/Computer Integrated Manufacturing) link. It is in this part of the ship production life cycle that cost savings have been considered most important. The conclusions contained in the study report "Toward More Productive Naval Shipbuilding" [Marine Board [11]] published in 1984 by the Committee on U. S. Shipbuilding Technology (appointed by the Marine Board of the Commission on Engineering and Technical Systems, National Research Council) stated that, "Four areas call for Navy leadership: • Common Engineering DataBase. A generic specification is needed for a ship product definition database, as a basis for computerization of ship design, shipbuilding, and ship life-cycle maintenance systems. • C A D / C A M DataBase Systems. A critical requirement not yet available in commercial data management is the ability to manage geometric information efficiently in concert with other engineering data, and at the same time provide for the production data requirement to produce on schedule the product of the required quality. • Interactive Data Transfer. The Navy and industry need to develop the capability of using electronic data as the standard for data transfer. (While Initial Graphics Exchange Specifications (IGES) address this need in part, much remains to be accomplished.)

•

Management Systems Development. A generic

specification is needed for computerized shipbuilding industry management systems. A joint Navy and industry developed specification, would result in reduced system implementation cost and improved ability to support ships and systems throughout their life cycle." [11] In response to this and similar recommendations, NIDDESC (Navy/Industry Digital Data Exchange Standards Committee) was initiated in 1986 as a joint project of NAVSEA and the National Shipbuilding Research Program (NSRP) and is supported by the CALS (Computer Aided Logistics Support) initiative within the Department of Defense. NIDDESC "...seeks to avoid costs associated with regeneration of data bases by enabling the exchange of digital data between successive agents during the ship life cycle." (Kloetzli [2]) As an example of the benefits of digital hull form data exchange, Kloetzli and Billingsly state that Bath Iron Works was able to avoid 96% of the labor usually associated with production lines fairing on the DDG51. The digital data exchange between organizations generally does not include engineering analysis (CADAS) results, since the legal issue of product liability could rest on proof of faulty analysis (Kloetzli [12]). Rather, the NIDDESC effort has concentrated on working with the IGES/PDES (Product Data Exchange Specification) and ISO/STEP (International Standards Organization/STandard for the Exchange of Product model data) groups discussed by Streiff [3], Owen [13], Mayer [14], Carson [15], Brandli [16], Schmitt [17], and Kuttner [18]).


539

2.2 Developments reported in the ICCAS Proceedings An excellent source of information on the use of design support databases for ship design and ship production is contained in the proceedings of the International Conferences on Computer Applications in the Automation of Shipyard Operations and Ship Design (ICCAS). These triannual conferences are sponsored by IFIP (International Federation for Information Processing), and IFAC (International Federation of Automatic Control) and the Proceedings published by Elsevier Science Publishers. Numerous papers (Arnold [19], Belda [20], Kanou [21], InDue [22], Okumoto [23], DiLuca [24], Johansson [25], Funaoka [26], Sakai [27], Baret [28], lkonen [29] plus those listed in the next sections) concerning the proprietary CAD systems are summarized in Table 1 and discussed below. This may not be a complete listing and the authors apologize for any existing systems which may have been overlooked. (Typical Personal Computer/workstation based hull fairing programs are reviewed in Ames [30].) In addition the Proceedings contain several important papers concerning the philosophy of database design for CAD/CAM systems. During ICCAS 76, Professor J. H. Krietemeijer [31], President of the International Standardization Organization Technical Committee #8, Shipbuilding, emphasized an urgent need for standardization of computer hardware and software elements in shipbuilding. During ICCAS 82, M. Liewald of Boeing Commercial Airplane Co. gave an invited paper (Liewald [32]) on "Futures in CAD/CAM Data Management'. The Boeing Company began development of a CAD/CAM Integrated Information Network (CIIN) in 1977. Their CIIN system and its successor, the Boeing Computer Support System (BCSS), pioneered the use of IGES data exchange standards to improve communication between CAD and CAM systems with the goal of developing a Computer Integrated Manufacturing (CIM) system built around a common database. Boeing realized that it had some control on the exchange formats for intra-company data but that standardized neutral data formats were required for inter-company exchanges with its industrial partners and sub-contractors. As was the case with Boeing's IPAD work, the project goals relative to "third party" use eventually exceeded the capabilities of the available software packages which lacked an "open architecture" transportability between different systems. The concept of using a structured methodology to design integrated shipbuilding information control systems was discussed by Malloni and Nusinow [33] during the 1985 ICCAS meeting. The "top down" functional analysis/planning activities discussed by Malloni and Nusinow and illustrated in Figure 3 are very similar to the CASE=Method used in developing the database formats discussed in this paper. Xia [34] discussed the reasons for selecting a relational database which uses the Structured Query Language (SQL) as its data definition and manipulation language. 540

TABLEt SUMMARY OF PUBUSHED PROPRIETARYHULL DESIGN SYSTEMS OWNER/DEVELOPER AVONDALE SHIPYARDS [19} BEC" [36]

COUNTRY

TYPE*

U.S.A.

CAD/CAM

FRANCE

HYDDB

U K.

CAD/CAM CADAS/CAD HYDDB

CEH (EL PARDO) [40]

SPAIN

HYDDB

CETENA "Modulo Story" [41]

ITALY

HYDDB

FORAN [20]

SPAIN

CAD

HITACHI ZOZEN" "HICADEC" [21] [22]

JAPAN

CAD/CAM

BMT (BSRA) "BRITSHIPS" [37} "BRrrDES° [38] [39] "STARTER"

IMD [42] ISHIKAWAJIMA - HARIMA HEAVY INDUSTRIES (IHI) [23] [43] [44] [58] ITALCANTIERI "SCAFO" [24] KOCKUMS *STEERBEAR HULL 3" [251

CANADA

HYDDB

JAPAN

HYDDB/CAM CAIVl/CIM/CADAS

ITALY

CAD/CAM

SWEDEN

CAD/CAM

MARIN "HOSDES" [45] [46] [47] [48] [49j "MARDES" [50]

NETHERLANDS

HYDDB/CAD HYDDB/CAD HYDDB/CAD

MITSUBISHI HEAVY INDUSTRIES [26] [53]

JAPAN

NKK "FUNDA" [27]

JAPAN

HYDDB

SAIC "IDEAS" [56]

U S.A.

CADAS/CAD/HYDDB

.SICEN" [28]

FRANCE

CAD

SSPNFLOWTECH "SHIPFLOW" [57]

SWEDEN

CADAS/HYDDB

TECHNION [55]

ISRAEL

HYDDS

WARTSILA [29]

FINLAND

CAD/CAM

c..w~

unaer ee.etWmen

H'ttX~: I~rdmdym~ics design database on I~es. CADAS.Compute~K~led Design A n a l ~ ; CAD:~ .~aoo g~metrlc aasign: Cm~:Comoutot, ~ a ~ C~: Como~eq ~egramd t ~ t ~ e m a n g

,

2.3 Proprietary hydrodynamic hull form design support database developments To support the research, analysis and development phases of the hull form design process, a number of organizations have built databases to store towing tank and wind tunnel data. These databases are used by individual organizations to make comparative performance studies of various vehicles whose characteristics lie within the bounds of their databases. Except for recent discussions within the International Towing Tank Conference community (Johnson [35]) however, proposals to develop standardized neutral data exchange formats for the comparative hydrodynamic analysis stages of conceptual design and for the ship performance estimation phase of preliminary design have not been pursued. This may be the result of not only the proprietary nature of a particular ship design but also the fact that the early stage comparative analysis studies represent a small fraction of the life cycle cost of a large ship and, with few exceptions, the hydrodynamic analysis comparisons are not passed along to the next stage of ship design/production. Regardless of the reasons, however, inter-database comparisons are presently limited to "hardcopy" data exchanges since nearly all proprietary hydrodynamic design systems presently lack the ability to exchange digital hydrodynamic data with each other. One of the motivating factors behind organizing this mini-symposium on Hydro-Numeric Design is that one cannot yet identify a ship which was designed using an integrated CAE/CAD/CFD/CAM/DBMS system which directly links validated computational fluid dynamics (CFD) tools to a database containing easily retrieved


I E'-C'''-'°" I °---''[''L°" I "E-~U~-'''--c'

DES [I.OP PROJt.CT PI.AN I CON|)(](-][ KK'K-O[;|" Mf.I

I I-I /,

RLv*I I'~& PROJ f.Cl I MAN~(II;Mf]N1 PI.A% DE~ ELO[' PROJECT ~JHt3)I?I.E

I ,--,E--o'-' I I,-,~E^0-,o--~

N I E ~ "'AN Ib'" IGANIZAIION ~ I g | i ' l l Itl'. CONDUCT MAN AGI':M I'~NT CON DLIC'T ORGANIZATION INTERVIEWS CONI)UCT IXX'CM I.~,TATION REVIEW~i 1'O%11| ('l ( AF..'( All. I'AM %~t*dt.M A'N~I $%1% I PI)ATI'. t.'~,] LRPR|N('.

k N ( ) g I.f3X,f. BA.M'~

I ";~',.','.":,,~.,w'"

I "";"::=';""~"";E'-"

I // I //

I/I

I /I

I I~,','.'~=;':~;,':~'~,,,.,,,,t // ]~"~/11 I~-','~,:::,'o'.~ I ~,".~.:'~°`"''''' ""'~'" I I / I / I

CONDU('T M I'~t.T1%(,;~ PRODUCE FUNCflONAL ANAI.VM~ RI':PORT

I ,',':,':",'~::,"' ['''''''''

IIETERMINEIIATA l ~ P~:~PRODUCT TOP DOWN FUNCTIONAL ANALYSIS/PLANNING ACTI ¥ ITI F.S

I L/

[ BOTTOM UP SYSTEM SPECIFICATION ACTIVITIES

Fig. 3 Structured methodology for database design (from Malloni [33]) information on the geometry and performance characteristics of previously tested vehicles with similar mission requirements. Integrated aerodynamic design database systems are apparently not yet operational in the aircraft industry either, in spite of the progress made during the IPAD project. One might expect that integrated aircraft design and manufacturing companies would have fewer proprietary data exchange problems than those nonintegrated industries which have separate design, testing and construction organizations as is the case in the U. S. ship design/production sequence. However, because designer/builders frequently have industrial partners and sub-contractors with dissimilar computer environments, performance data exchange problems are nearly universal during the conceptual design phase for all types of performance oriented vehicles. 2.4 Proprietary hydrodynamic design support systems As stated previously, Table 1 shows a summary of proprietary hull design and analysis systems developed around the world and reported in the technical literature. The "type" column in Table 1 indicates if the design system includes CAD, CAM, CIM and other CAE capabilities. The acronym HYDDB (Hydrodynamic Design Database) has been defined to indicate those computer based CAE systems which include hydrodynamic design databases or files. The acronym CADAS (Computer-Aided Design Analysis) is also used to indicate the presence of various design analysis codes. The purpose of the additional explanations given in this section is to comment on those proprietary computeraided ship design and analysis systems which include hydrodynamic design databases or files, i.e. HYDDB capabilities.

2.4.1 BEC (France) - Dern, Discerbo and Nedellec [36] outlines the requirements of a database system for tank test data and results. The paper deals with specific requirements of BEC to harness large amounts of data (which exist only in paper formats), to interface with specific CAD codes and to facilitate the smooth organization and progress of model testing and reporting during the preliminary ship design phase. This HYDDB system is presently being developed. 2.4.2 BMT (British Maritime Technologies) (U. K.) The various CAE/CAD/CAM software packages available from BSRA/BMT have been discussed in a number of papers (Parker [37], Odabasi [38], Archer [39]) concerning the BRITSHIPS/BRITDES systems. Figure 4 illustrates the general layout of the BRITDES CADAS/CAD system and indicates the interrelationships between the various software modules. The BRITSHIPS CAD/CAM system has a direct interface with the BRITDES system. The HYDDB STARTER database associated with the BRITDES system is the subject of a later section of this paper. 2.4.3 CEIl (EL PARDO) (Spain) Carlier and O'Docherty [40] outlined the structure of their multiple file, fixed record data bank and its use of customized Fortran code for comparing pairs of hull forms prior to scaling of the data for a new design configuration. This paper represents the first open publication to detail the type of data to be stored in associated files or groupings for use by hull design personnel. Extensive use is made of graphics and empirical relations for propulsion factors. 2.4.4 CETENA (Italy) - During ICCAS 88, Allieri and Sartori [41] described "Modulo Story", an integrated


541

l

CONCEPT DESIGN CONSTRAINED NON--LINEAR OPTIMIZATION

CONCEPT DESIGN

I I

I

D--LINES HULLFDRM DEStGN FITTING AND FAIRING

MIN, TOPOLOGICAL DEFINITION OF INTERNAL AND TOPSIDE STRUCTURES

///

Sea TfiGI

~

I

PRELIMINARY DESIGN GENERAL

ARRANGEMENT

.....

DESIGN

PREUMINARY

PRELIMINARY

2

DESIGN

ENGINEERING

STRUCTURAL

NAVAL

HYDRODYNAMIC

ARCHITECTURE DESIGN AND

................

SYSTEMS

DESIGN AND

ANALYSIS

ANALYSIS

I /HULLSURF HULLFORM DESIGN

I .......

il

......... FAIRING

II TOPSIDE . . . . . . . . . . . . STRUCTURE~ INTERNAL AND I

I

M~NT TOPOLOGICAL

i

I

I

ADVANCED DESIGN ENG ADVANCED ENGINEERING SYSTEMS DESIGN

STRUC ADVANCED STRUCTURAL DESIGN

1

NADAS HYDRO II NAVAL HYDRODYNAMIC ARCHITECTURE DESIGN AND DESIGN AND ANALYS S ANALYSPS

r-:--] $,~.~.d s,09, C~.-.~]

third

St*ge

I IBRITLOFT/BRITDEI-] Fig. 4 BRITDES CADAS/CAD system (from O d a b a s i [381)

Fig. 5 IHI CAD/CADAS/HYDDB s y s t e m for m a r i n e propeller design (from Fujino [44])

system being developed by CETENA for storage, retrieval and manipulation of ship design information including performance characteristics. "Modulo Story" is based on the SQL-based RDBMS ORACLE which is also used by the authors of this paper. AUieri and Sartori also give useful examples of the advantages of relational databases over hierarchical and network structures for ship design database systems.

diagram is similar to the one discussed in this paper and is centered around a data bank (Figure 5) which includes data on geometric forms, results of model tests, results of actual ship tests and the results of theoretical calculations. The details of the proprietary datafiling system used by IHI were not specified.

2.4.5 IMD (Canada) - IMD's database, like CEH's is more a data store comprised of a collection of files on a DEC 11/750 in which the file naming convention reflects the model identifier and the type of data stored. This appears to be similar to the convention adopted at the St. Albans tank, at which Molyneux [42] gained his primary experience of towing tank practice. The IMD HYDDB system, which is for resistance and propulsion only, relies on Fortran codes for creating indexes from the many data files, and as such has no inherent relational capabilities. 2.4.6 ISHIKAWAJIMA.HARIMAHEAVYINDUSTRIES (IHI) (Japan) - An integrated CAE systems discussed by Ogiwara [43] during the ICCAS 79 conference was the Ishikawajima-Harima Heavy Industries (IHI) Computer System for Ship Propulsive Performance. This file-based HYDDB system contained geometry data, model test data, sea trial data, and theoretical analysis data. The IHI system contains the same kinds of data as the database discussed in this paper, but in a different and non-standardized format. A CAD/CADAS/HYDDB system for marine propeller design was described by Fujino et al [44] as an extension of IHI's Integrated Computer System for Ship Propulsion Performance. The overall system 542

2.4.7 MARIN (Marine Research Institute, Netherlands). In 1983, MARIN began developing HOSDES, an integrated concept design system for high speed naval ships with support from the Dutch Navy. HOSDES is one of the most highly integrated ship design systems developed to date and has been expanded to include merchant ships (MARDES). HOSDES includes a CAD (graphics) system, CADAS (Computer-Aided Design Analysis) modules, and HYDDB (Hydrodynamic Design Database) capabilities. A number of papers (Koops [45], Ooman [46], van Oossanen [47], Koops [48], van Oortmerssen [ 4 9 ] , Glijnis [ 5 0 ] , Koops [51]) have described the HOSDES/MARDES system (Figure 6) which includes the following elements: 1) Support Systems including a System Management Subsystem, a User-Interface Management Subsystem (UMIS), a Swedish relational DBMS "MIMER", and a Designer Guidance Subsystem (the "Assist" Expert System). 2) Application Systems including various computational levels of software analysis programs for hull geometry, powering, mass distribution, hydrostatics, motions, strength, dynamics, endurance and engine configuration. 2.4.8 M I T S U B I S H I H E A V Y I N D U S T R I E S ( J a p a n ) T h e database for HDS (Hull Data System), a comprehensive CAD system developed by Mitsubishi


2.5 Integrated "Hydro-Numeric Design" systems

DESI N FILESG(OB)

PROGRAMS

APPLICATION

~ FILE -- ~ EXECUTION/~ I~(DNBM~, ~Ls)G ~.___..jEXECUTIVCE O 7 ~ -- ~SYSTEM/ /

\USERS/

INTERFACE

DESIGNFR Fig. 6 MARIN HOSDES system (from Koops [45]) Heavy Industies was described by Hasegawa [52] as being built around a Body Plan File and a Drawing File. 2.4.9 NICK (Japan) - The FUNDA ship design system developed by NKK (Yoshikai [53]) includes the data file service program VIEWCLERK which can access performance data from many towing tank tests and full scale trials stored in a hierarchical data structure system. 2.4.10 SSPA (Sweden) In 1973, Williams [54] discussed a system (more a datastore than a database) controlled by Fortran code rather than a relational database management system (RDBMS). Various common hydrostatic and hydrodynamic quantities were stored, together with measures of merit with respect to 'standard' model configurations. The data was held for only one speed per hull form, namely the design speed. Such a system allows quick interrogation of limited, fixed parameters but did not allow complex, related queries to be made on the base of data except through user modified Fortran code. 2.4.11 TECHNION (Israel) - Biran and Kantorowitz [55] demonstrate a similar approach to that adopted by BMT, and report the use of an unnamed relational database and management system which may be a product of Technion. The examples given of the command language indicate that the system is not based on SQL (Structured Query Language) methods but on customized query structures which in some cases involve complex operations such as selecting, computing, ordering, interpolating and plotting data. No details are given of the fundamental command set, hence no comparison can be made between the flexibility of the system to allow command syntax creation and corresponding standard SQL constructs. The schematic of the system is similar to that developed independently by BMT, perhaps reflecting a common, enforced way of marrying data with applications code and user interfaces as a result of using an RDBMS.

Although the BMT and MARIN systems incorporate some aspects of CFD integration into the design process, the systems discussed at this mini-symposium appear to be further along in the integration process. 2.5.1 SAIC (U.S.) IDEAS is currently under development in Annapolis, MD and will be discussed by Fritts [56] during the mini-symposium on "HydroNumeric Design" at the 1990 SNAME Annual Meeting. IDEAS will incorporate various flow codes for resistance, seakeeping and performance assessment tied to a user-friendly hull geometry design package "FASTSHIP" (in use by undergraduate naval architects at the U. S. Naval Academy). IDEAS will eventually be linked to the U. S. Navy/U. K. Navy Hull Form Design Database (HDDS) discussed later in this paper. 2.5.2 SSPA/FLOWTECH (Sweden) - Also during the 1990 Annual Meeting of SNAME, Lars Larsson [57] will discuss the SHIPFLOW design support system developed by SSPA/FLOWTECH International, A.B., which consists of an extensive set of CFD tools for calculating the potential flow with free surface, the boundary layer and the viscous flow in the stern region of a ship. The degree of integration with a CAD system for hull geometry was not mentioned in a draft of the paper available to the authors of this paper. 2.5.3 IHI (Japan) - Mori [58] describes the extension of IHI's integrated CAE/CAD/CADAS/HYDDB hull form design system (section 2.4.6) to include potential flow and boundary layer calculations. Simple calculations are used during the early stages of design, but increasing complexity of hydro-numeric calculations are used to refine the hull design. No details of the non-linear theories are given in the paper.

2.6 Bottlenecks in the integration of hydro-numeric design systems In preparing a paper on the integration of CFD and CAD in ship design, Johnson [59] interviewed CFD oriented vehicle designers to determine the most significant "oottlenecks" in the hull form design process. Two of the most significant problem areas involve the following.

2.6.1 Interfaces between CFD and CAD surface geometry codes - Common to nearly all CFD/CAD systems are time consuming delays associated with panelization and/or grid generation. These labor intensive activities are required 1) every time the designer changes the surface geometry and 2) for situations where dynamic flow conditions involve time domain solutions. This is an area where artificial intelligence/expert system developments can eventually provide more cost effective design solutions. It is also an area where industry-wide standards on formats for the description of surface geometry would make innovative code developments transportable from one CFD/CAD system to another. Difficult geometries, such as intersections with


543

complex vehicle appendages, may require nearly as much time for grid generation as would be needed for a wind tunnel or ship model test. During a flow code validation study reported by Hoyle [60], for a short period the model test program had to wait on the CFD code grid generation process. 2.6.2 Data exchange bottlenecks - As discussed in section 2.3, nearly all exchanges of hydrodynamic data are accomplished with "hardcopy" data exchanges. To insure consistency in comparative validation studies, hull form geometry and hydrodynamic performance data should be exchanged in standardized formats (see section 5.1). Standard format data exchanges could significantly reduce the time and cost of CFD code validations.

Table A Field l 2 3 4 5

Table B Field I 2 3 4 5

3.

Umque Primary

Key

Type Wldth Char 15 Char 30 Char 20 Number

Unique Primary F o r e i g n Key

Key

Fieldname 1 Model_ID 2 Ship_Name

Type Char Char

Width 15 30

F o r e i g n Key F o r e i g n Key

Model

RELATIONAL DATABASE SYSTEMS Hierarchical

In the late 1960s, Dr. E. F. Codd (Codd [62]) developed the concept of relational data modeling as an alternative to the flat-file, hierarchical and network models in the development of database management systems for information control. The non-relational database models had primarily been ad-hoc developments with few theoretical and logically rigorous foundations, a typical "as the need arises" approach to extensions of the information contained in the database. Without the necessary theoretical structure, entry of new data and queries to the database often required complex programming to insure data integrity of the information stored in the database. As an example of the various database types, consider the development of a database for ship designs. If the required information in the database consisted only of the ship name, type, designer, builder, etc., a traditional "flat-file" as illustrated in Table A of Figure 7 would suffice. Each row of Table A pertains to a specific ship design, while the attributes of the design are stored as columns (fields) within the table. With the presence of a unique primary key, additional tables containing additional fields beyond the original fields could be created. However, if the database were to also contain information about models used to develop the ship designs, a one-to-many hierarchical structure would be necessary. This situation (illustrated in Table B) allows for several models to be associated with a single ship design, as might occur with different model scale ratios associated with powering, maneuvering and seakeeping tests. The hierarchical database has difficulty handling the situation where many-to-many relationships occur. For instance, if one hull form model were used to represent more than one ship design, i.e. the DD963 and the 544

Width 30 30 50 50

LINKAGE DBF

Field

Flat-File

Type Char Char Char Char

MODELSDBF

Fieldname Model_ID Ship Name Model M a t e r i a l Scale_ratio Etc.

Table C

2.6.3 Lack of adequate cost impact models - Cost models for the impact of seakeeping on ship operating economics (Sellars [61]) have been put forward, but not integrated into many hull form design systems. Simple fuel cost models based on operating profiles should be available from a menu driven system when making comparative hull form analysis studies.

SH1PS.DBF

Fieldname Ship_Name Type Designer Builder Ete,

D a t a Model ( P a r e n t - C h i l d )

N e t w o r k a n d R e l a t i o n a l Model

Fig. 7 Examples of hierarchical, network and relational databases

CG47 combatant classes, the Model ID would no longer be a unique identifier. This problem is addressed in the network model by the creation of linkage files. Linkage files contain the primary key fields of the various tables (entities), converting the situation to that of many-toone-to-many. This impacts the example by eliminating the Ship_Name field from Table B and by creating the linkage file shown in Table C. The resulting relation is also shown in Figure 7. Allieri and Sartori [41] point out several drawbacks of the hierarchical and network models including • the need for highly specialized personnel • the requirement that the access paths must be known by the user to query the information • the high cost of alterations to the database design. The relational model of database structures encompasses all the previously mentioned forms: flatfile, hierarchical, and network models. It provides an added degree of data independence and flexibility. In addition, by means of the normalization rules discussed in Appendix 1, it provides a systematic means by which the data structure can be checked to eliminate implementation problems resulting from data anomalies. The relational model has been extended to include the Structured Query Language (SQL) to define and manipulate data. The examples in Appendix 2 show the structure and flexibility of simple SQL queries. Efforts to standardize SQL should eventually result in the ability


to query and exchange data between ANSI standard SQL-based relational databases supplied by various vendors and operating on all types of hardware. For these reasons, as well as those previously discussed in the review of IPAD database developments (Blackburn [79, the relational model is widely accepted in integrated computer-aided-design systems. As discussed by Dube and Smith [9] however, "Excellent database management systems are available commercially, but most of them address financial and business requirements ...... Engineering data needs include vectors, matrices, and geometry which are not typically handled by business-oriented data managers." [9] This liability makes itself apparent in the current inability of relational databases to store data as a single entity such as the results of resistance and powering tests or a specific hull geometry, its section area curve and other geometric attributes.

[

4. THE BMT STARTERfl'IDDS (HULL DESIGN

DATABASE SYSTEM)

I

I

STARTERMENUSTRUCTURE

I

I

MASTERMENU

I

I

,.

I

I

~[0N ,MS

I HULL OFFSETS

EXTERNAL DATA FILES

UTILITIES

DATA FILES

PROP-GEOM

DATABASE

APPENDAGES I GEOMETRY

Fig. 8 STARTER/HDDS menu format Fig. 9 Structure of HDDS database 4.1

BMT STARTER Hull form database development

In collaboration with the St. Albans tank, BSRA (British Ship Research Association, now BMT) developed a comprehensive database for model test data and numerical predictions. The application was given the acronym STARTER (STorage And Retrieval of Tank Experimental Results). STARTER was initially developed in 1985 using the database management system "REVELATION". REVELATION was chosen because, although not truly 'relational', it allowed file structures to be defined to mirror the way in which data were traditionally presented in report formats. That is, it allowed unit length and multiple length vectors to be held in the same record, i.e. hull form factors and arrays of speed and total resistance could be held in the same record or 'line'. This initial implementation produced a flexible, userfriendly (menu driven) and self-documenting system for storing, querying and extracting volumes of data from towing tank test sources. The data extraction interfaces built by BMT allowed links to be established with generally accepted analysis codes such as the rvI'C 78 prediction code, BMT's concept design code CODES, preliminary numerical towing tank code SEHAM, and

lines fairing and distortion code B-LINES (Figure 4). The one major drawback of the chosen DBMS was its restriction to MS-DOS (PC's) and OS/2 platforms, where speed of data retrieval from large data sets was judged to be a limiting feature for further development. The BMT STARTER system was converted to the emerging shipbuilding industry standard RDBMS "ORACLE" in late 1987. ORACLE operates on all hardware from PC's to mainframes. In 1988, David Taylor Research Center (DTRC) acquired the licence to use STARTER from BMT, and modified it to accomodate DTRC procedures and practices. DTRC is currently inputting ship and model test data and is participating in the data conversion and exchange problem addressed later in the paper. Data is stored within the database in TABLES (see Appendix 1 on relational database design principles) which comprehensively cover data obtained from physical tests and studies involving computational analysis. Data is indexed within these tables according to a convention which has been selected by accounting for specific model testing procedures. Physical Test Data fall into the following categories: • Hull form geometry (several common formats) • Appendage geometry


545

IANALYSIS FUNCTIONSI

1. GENERATION OF FULL-SCALE PREDICTIONS OF RESISTANCE AND PROPULSION USING SELECTED METHODS 2. DATA WINDOWING AND PREDICTION GENERATORS 3. COMPARISONS AGAINST STORED CRITERIA FOR R & P , SEAKEEPING AND MANEUVERING 4. HULL DISTORTION CAPABILITY 5. DATA INTERFACING 6. REGRESSION OF SELECTED DATA 7. GRAPHICAL COMPARISON OF DATA FROM SELECTED HULLFORMS

I STORED INFORMATION I

J GEOMETRY: HULL, PROPULSION APPENDAGE RESISTANCE: MODEL TEST DATA & GENERATED DATA WAKE: MODEL TEST DATA & SOFTWARE DATA PROPULSION: MODEL TEST & FULL-SCALE TRIALS DATA & SOFTWARE DATA

7. PROPELLERDESIGN PROGRAM'. (SEHAM)

MANEUVERING: MODEL TEST DATA & SOFTWARE DATA

8. APPENDAGE PREDICTION PROGRAM(S) 9. CAVITATION, WAKE ASSESMENT PROGRAMS (SEHAM) 10. HYDRONUMERIC PROGRAMS FOR RESISTANCE PREDICTION (XYZFS, SWIFT)

PROPELLER DATA: MODEL SCALE AS TESTED AND FINAL DESIGN REGRESSION EQUATION FOR OPTIMIZATION CRITERIA/MEASURES OF MERIT

Functionality, contents and links of HDDS system

• • • • • • • •

Propeller geometry Hydrostatics and running drafts Resistance (raw and faired; naked and appended) Open water characteristics Self propulsion data Full scale predictions Full scale trials data Wave survey and harmonic analysis data Data from computational methods are accounted for in tables related to • Seakeeping analysis • Propeller design and analysis using lifting surface methods • Powering predictions from semi-empirical methods (BMT SEHAM system) • Hull flow analysis from boundary element methods with free surfaces The system is also designed to allow Imperial or SI units to be presented to the user of the system, while the database stores the fundamental data, an appropriate mix of non-dimensional coefficients and SI units. The program-control environment (or shell) is menu driven (see Figure 8). Each menu item, when selected, enables the user to run a selected code which may interrogate the database directly, or may read from intermediate data files produced by operating on the database through interpreted SQL queries and report codes. 4.2

Hull Design Database System (HDDS)

When the Naval Sea System Command (NAVSEA), USA began discussions with the Admiralty Research Establishment (ARE), Haslar, UK early in 1989 to 546

FASTSHIP, BLINES, HULLSURF

SEAKEEPING: MODELTEST DATA & SOFTWARE DATA

/

Fig. 10

1. SEAKEEPING PROGRAM(S) 2. MANEUVERINGPROGRAM(S) 3. RESISTANCEAND PROPULSION PREDICTION PROGRAMS 4. GRAPHICS PROGRAMS FOR PRODUCING FINAL REPORTS 5. WORD PROCESSING ON-LINE PROGRAM(S) (WORDPERFECT) 6. HULL FAIRING PROGRAMS,

establish a joint exchange program, the groundwork had already been set and the STARTER database was agreed upon as being the best basis for an international design system. The exchange of data between the US and UK navies is being carded out under the auspices of an international agreement. 4.2.1 Objectives - The objectives of the HDDS are fourfold: 1. To provide each navy with the capability to design hull forms quickly and optimally, in order to meet or exceed requirements for speed, endurance, energy conservation, seakeeping, and maneuverability 2. To create a ship design configuration management system 3. To capture design experience and hydrodynamic performance data in order to adapt to the changes imposed by technological advancements 4. To provide integration with other design functions. Figure 9 shows the basic STARTER database structure upon which HDDS is being constructed. 4.2.2 Current design probems - Problems with the present NAVSEA hull form design process can be summarized as follows. • Relatively little hull design data is available; what is available is not readily accessible, and it is scattered between NAVSEA and DTRC. • Design work is limited by time constraints. • A lack of trained personnel exists in the hull design field (i.e. naval architects with a good depth of design experience).


OTHER CALCULATIONS OF HDDS

HULL PARAMETER QUERY SELECT HULLFORM (~

VCF RrlZ~ R r l A (TAYLOR) ISESIRED SPEED RANGE I

Im

#E

I

~J~IEE~]NG

BASELINE HULLFORN

ASSEgSWENT.

DISTORT HULLFORM I ,

Ii

LI

0/SFI3OT L2

DEGREE

RATIO

V vqS MANEU~JNG A~SESSMENT

MODIFYFREEBDARDI RUDDER? SKEG~ PRI]~ELLERI

PREDICT

PROPELLER WAKI~ ASSESSMENT

Rf.A,~

Ht,Lt.fI]~

~ Po P~

Fig. 12 HDDS hullform comparison methodology

Figure 10 illustrates the content, links, and functionality of the HDDS. The stored data, including hull and propulsor geometry, wake definition, and hull and propulsor performance, are used as the basis for generating optimal hull forms, performing analyses between hull forms, and selecting and predicting performance of the baseline hull form.

/ HP g

b SPEED

Fig. 11 NAVSEA hullform design process

4.2.3 HDDS system description - When completed in 1991 the system will include the following attributes and characteristics. • Data will be available and selectively retrievable on-line for 1000 to 3000 different ships. • HDDS will contain hull and propulsor geometry, resistance, powering, seakeeping, and maneuvering data. • Data will be available in tabular and/or graphical format. • The program will incorporate menu-driven access to other navy programs for hull fairing, hydrostatics, seakeeping prediction, etc. • The program will allow for multi-users, and for removal of classified discs for safe storage.

4.2.4 HDDS and the NAVSEA design process - An insight into the planned NAVSEA hull form design process is shown in Figure 11. This illustrates how the HDDS will be instrumental in selection of the "baseline" hull form. This hull form is then verified against performance requirements (either real or implied) for powering, endurance, seakeeping, arrangements, stability, and machinery. Following this initial verification, more sophisticated codes are used to design appendages andpredict maneuvering characteristics, as well as to perform seakeeping, hydrodynamic load, and "numerical towing tank" evaluations. Next, a "near final" hull form is drawn, which is used for initial model testing. This hull form may include some options, such as bulbous bows, appendage suites, or stern configurations. Following model test validation of the hull form, and some advanced design analyses, the hull and appendages drawings and computer codes are given NAVSEA-wide distribution, as the Contract Design Phase begins.


547

I

PERFORMANCETARGETS & DESIGN ENVELOPE FROM DESIGN SYNTHESIS

........................................................................ SurfaceShipDatabase: Geometry, R&P, Seakeeping & Maneuverin Database.

~ '----'t

J

~ ..............................................................................

BASELINEHULL FORM SELECTION

Verification of R&P, Seakeepingand Maneuvering Performance by Empirical/ Database Methods.

/

BASELINE HULL

[ L

J

1

1 I

1

I

.MODIFICATIONS . . .

l

I l

k. .................................................................................................................... , l PREMMINARY DESIGN BEGINS

"'

MODEL TESTING

4

J

CONTRACT DESIGN BEGINS ,

ItI

[

J

r M°°I~'°%"°NS

NEAR-FINALHULL FORM

(PreliminaryNAVSEAOilUibution)

I

j ..................................

|

l ..o:::::. ]

1

I I

1

SEAKEEPING

l

MANEUVERIN! ~ J

l

l Hull Design Datafor Use by Other Codes (NAVSEADistribution) Fig. 13 HDDS design synthesis module

4.3 Unique features of HDDS 4.3.1 Extensive use of graphics - Graphics capabilities have ceased to be the icing on the cake; rather they are essential ingredients of the cake itself. The increased general use of spread-sheets and interactive CAD graphics software is largely responsible for generating this interest. HDDS will include more complex graphics than the spread-sheet type of graphics which normally accompany commercial databases. 4.3.2 Regression analysis functions - The ability to perform regression analyses on selected portions of the database. For example, if the designer is about to design a minesweeper, he or she could perform a regression on only the mines~veepers, and optimize such parameters as B/T, LCB, or half angle of entrance. 4.3.3 Hull form comparisons - The ability to make comparisons between hull forms based on predictive equations, curves, or techniques. This is illustrated on Figure 12 as part of the hull form design process. In the illustration shown, (R a / n ) / ( R R / n Taylor), the "worm curve factor", is used to compare the residual resistance of selected hull forms.

548

4.3.4 Hull distortion capability - The ability to distort a selected hull form in order to achieve the required displacement, draft, length, LCB location, or other desired attribute. The distorted hull form will retain the fairness associated with its parent hull. 4.3.5 EHP and SHP predictions - The ability to predict accurately the resistance and powering performance of the distorted hull form by using flow code algorithms, predictive equations, or regression analyses as appropriate. 4.3.6 Design synthesis modules - In essence such modules allow the designer to specify targets of performance, to select elements from diverse test data held within the database which satisfy these targets, and finally to assemble them into a new design. This is illustrated in Figure 13, where assessments are made for seakeeping, maneuvering, and propeller wake. 4.3.7 Window management systems Since the introduction of faster graphics screens pull-down or popup windows have become standard tools in many PC and Unix codes. These tools now permit users to operate in more natural environments, where they are accustomed

DatabaseSystemsfor Hull FormDesign

to viewing and relating to several images and text displays at one time. In many cases the scientific user will wish to analyze data presented in graphics formats, e.g. to fair data using interactive spline methods, or to access a range of data on a scatter graph by means of an interactive cursor window, or to perform a regression analysis. 4.3.8 Body plan output - The ability to output in a standard format an acceptable, scaled body plan for distribution within NAVSEA. 4.3.9 Desktop publishing - The ability to prepare and publish final reports using data generated by HDDS. 5. FUTURE DIRECTIONS 5.1

ITrc standard formats for neutral data exchange

The amount of information to be stored in hydrodynamic hull form design database tables will be very large, especially if CFD analysis code validation data and comparative model test data are to be shared between various hull form design support organizations. The number of possible attributes (columns) and individual tests (rows) in these tables numbers in the thousands. This is a situation where the development of neutral standard formats could make data exchanges between multiple organizations more economically feasible. Responding to the need for data exchange standards expressed by various organizations associated with the International Towing Tank Conference, the ITI'C Symbols and Terminology Group has proposed toundertake the following tasks during the 1990 to 1993 period: 1. To develop a standard neutral format for the efficient exchange of hydrodynamicperformance data defined in the ITI'C Standard Symbols and Terminology List. [63] 2. To utilize the format specifications being developed by ISO/STEP (STandard for the Exchange of Product model data) as the basis for an interim standard neutral format for the efficient exchange of data concerned with the definition of hull form, propeller and appendage geometry. The development of ITI'C standard formats for the exchange of hull form design and attribute data will require interactions with organizations normally outside the ship design community. This is especially true for the development of standard formats for the efficient exchange of data concerned with the CFD code validation and the definition of hull form, propeller and appendage geometries. In this respect, interaction with the parallel development of IGES/PDES/ISO STEP standards including those for the Computer Graphics Metafile (CGM) concept (Mumford [64], Owen [13], Brandli [16]) and new database technologies (Yamamoto [65], Ohsuga [66]) may prove fruitful to all parties concerned. Object-oriented DBMS, which would appear

to be a possible solution for the exchange of surface definition information, as yet have no equivalent to the relational database oriented ANSI standard SQL (Structured Query Language) which is quite adequate for storing and retrieving single valued quantities. There is also the challenge of developing standards for the exchange of records and analysis procedures for time series data which include seakeeping, maneuvering and other dynamic data. Data exchanges which depend on neutral standards developed by an international organization such as the ITTC community have a higher probability of acceptance and universal use by the maritime industry than data exchanges that depend on proprietary licensing agreements with individual software developers or on the development of individually tailored direct translation programs for data exchanges between non-neutral database systems (Kuttner [18]). Implementation of the proposed standard formats by the towing tank community and its clients will require one of the following. • Those organizations which have not yet developed adequate hydrodynamic performance databases could use the ITI'C standard formats as a guide in developing the database structure and data dictionaries needed for storing and retrieving hull geometry, hydrostatic characteristics, and hydrodynamic performance data. • Those organizations which already have hull form design databases can either convert their data structures to the new formats or develop a single set of input and output translation processors for converting data to the ITI'C neutral standard format for data exchange purposes. Figure 14 illustrates the number of translation processors required for data exchange between dissimilar databases. For example, for 9 member organizations or their clients to exchange data between 9 separate database systems, a total of 72 direct translators would have to be written as opposed to a total of only 18 (one time) translation processors if the neutral exchange format were involved. Those organizations which have database structures based on the neutral formats should not have to write any additional translation processors to exchange hydrodynamic performance data. The 1987 Draft Standard Symbols and Terminology List (including computer compatible symbols) has been updated for the 1990 conference. Although the list is not yet complete, the computer compatible symbols contained in the 1990 draft can be used as the basis for defining standard attribute names for a neutral control file format. A possible set of standard table names is discussed in Section 4 of Appendix 1 along with comments on necessary changes to the present I T r c computer compatible symbols list. 5.2

Integrated HYDDB enhancements

The integration of a neutral format database into complete ship design, analysis and evaluation systems (Odabasi [38], Fritts [56]) is in the early stages of development. Successful integration for the IDEAS


549

System A

System D

System A

System B

System D

11

System B

l r System C

Systemic

Translation Processors = N(N-1)

Translation Proces, ors = 2N

Fig. 14 Translation processors for data exchange system will require considerable additional development because the interfaces to the various modules illustrated in Figure 15 must be designed and some type of System Application Manager (SAM) developed. Several of the analysis modules already exist but the data links are lacking in all but a few cases. Having the modules input and output data from a neutral format central database, as proposed in this paper, should eliminate many of these problems. Expert system shells for the integrated system are still in the conceptual phase. It is in the System Application Manager where object oriented approaches, artificial intelligence and expert systems might make the greatest contribution. 5.3

Object oriented DBMS capabilities

As discussed previously, the conventional relational database management system is a fiat-record oriented model, composed largely of single valued quantities (numerical or textual). All data manipulations are done at this single value level. Queries extract attribute values and updates change them. A recent database development is that of the object oriented database management systems (OODBMS) (IEEE [67], Maler [68], Maler [69]). In an object oriented environment, users manipulate whole objects [Cox [70], Mumford [64], Yamamoto [65], Ohsuga [66]) rather than single valued attributes. Examples in addition to the obvious hull, propeller, and appendage geometry storage problem include time series data and video/bitmapped image data.

550

OODBMS are a key factor in attempts to bring the Artificial Intelligence and database communities closer together (Brodie [71]). First generation object oriented database management systems (OODBMS) are under development but commercially supported OODBMS have not yet been integrated into CAD systems. However, it clear that object oriented databases could have a major impact and be extremely useful for certain applications and in particular for ship and vehicle design support databases. An object oriented database system, containing ship data (a knowledge base) needed by the designer, is a valuable foundation upon which an Integrated Ship Design, Evaluation and Analysis System (IDEAS) (Fritts [56] can be built. 5.4 Intelligent ship design systems A fascinating view of future CAD systems is contained in the paper 'Towards Intelligent CAD Systems" by Dr. Setsuo Ohsuga of the Research Center for Advanced Science and Technology at the University of Tokyo (Ohsuga [66]). Dr. Ohsuga points out that, "...current applications of AI (artificial intelligence) are limited to rather small-scale problems, and are not proving a powerful means useful for innovative design." What is needed is a new generation of information processing systems for "knowledge-processing" technology. An intelligent CAD system, he continues, "...must be able to represent explicitly an object

Database Systemsfor Hull Form Design

0 0 0

refine

evaluate

(co=::.,) 0

.=o:o,

"=,:°' design

Manufoeturlng

Manuf*eture Test

Fig. 15 IDEAS system diagram and be able to manipulate it. The representation of an object is called an 'object model', and the system, a 'model based problem-solving system'" In addition to representing the 'object model', the intelligent CAD system must also contain a model of the Design Process (Figure 16) which can analyse and evaluate the object model from multiple viewpoints in relation to the given requirements. Although numerical codes for many aspects of the ship design process are well developed, the design process itself is not yet algorithmic, and may never be if Penrose [72] is correct. (In this sense, Figure 16 is preferred to the classic "design spiral" which could be interpreted as implying that the design process is algorithmic.) It is still up to the individual designer to come up with the best design to satisfy the goals and constraints of the problem. Thus Ohsuga states that the goals of the intelligent CAD system are: "I'o computerize as many individual operations (shown in Figure 16) involved in a design process as possible and To integrate these different operations into a process. As a matter of course, a human designer must be able to intervene in the process at any time." [66] Engineering design requires not only quantitative computations but also qualitative ones; innovation, creativity, exploration of new non-standard designs, and reasoning about goals, requirements and constraints. Penrose [72] and others outside the "strong Ar' community regard many of these qualitive activities as non-deterministic and certainly not algorithmic in a useful way. Artificial intelligence, although it can not offer a complete solution to the problem, can provide valuable assistance and methods for representation of designs, domain knowledge acquisition, and reasoning about goals and constraints. Expert systems have successfully

eslg

Fig. 16 Design process (adapted from Ohsuga [66]) captured the knowledge and problem solving techniques used for CFD (Andrews [73]) and during the design process (Tong [74]). The ship design process has been outlined by naval architects (see for example, Schaffer [75]), and expert systems have been used to support portions of the ship design process (MacCallum [76], Duffy [77], van Oortmerssen [49], Koops [51]). Artificial Intelligence methods will eventually be used to provide assistance to the designer in the generation of possible design solutions and to control the algorithmic aspects of the design process. Based on the opinions of Penrose [72] and Ohsuga [66], AI is unlikely to replace the creative (conscious) input of human designers. 6. CONCLUSIONS The foregoing paper has touched upon many aspects of database systems used for hull form design and the developments needed to integrate these tools into a cost effective ship design system. The appendices provide specific guidance for the design of a relational database from which to begin the development of International Towing Tank Conference (ITrC) standard neutral formats for data exchange of ship and marine vehicle performance data. The conclusions can be summarized as follows: 1. Previous attempts, such as the IPAD effort, to develop fully integrated vehicle design systems built around the efficient use of a central database exceeded the capabilities of the hardware and software commercially available at that time. The Workstation/Mainframe/RDBMS/UNIX environment is now sufficiently developed to


551

accomplish this task at a reasonable cost. . The work on international CAD/CAM/CIM data exchange standards by projects such as the ISO/STEP, NIDDESC, and CALS should be extended to include other CAE/CFD and model test data frequently used during the concept design phase. The 1TrC community should join this effort to encourage international cooperation in ship design and to provide even more cost savings during ship and marine vehicle design. . An AGARD-like ship design organiTation, possibly an international consortium, is needed to bridge the gap between basic CFD research efforts and the present design process. There is a great need to make those who are in a position to fund integration work aware of the long term cost benefits which could result by reducing the bottlenecks in the concept design process discussed in section 2. Cost sharing between the parties involved in "open system" code and code interface development is a viable alternative to the development of proprietary CAE/CAD systems which may or may not find a niche in the ship design market. 4. The STARTER/HDDS system, based on a prototype

of the ITI'C standard neutral format for data exchange, should provide a worldwide milestone when completed in 1991. This system will incorporate many desirable features including various CAE tools, a hull, propulsion and performance database (HYDDB), and links to CAD/CAM systems. 7. ACKNOWLEDGEMENTS A portion of the work described in this paper was carried out by U. S. Naval Academy personnel under the sponsorship of the Defense Advanced Research Projects Agency, Machine Intelligence Branch. 8. REFERENCES

1. Boylston, J. W., deKoff, D. J., and Muntjwerf, J. J., "SL-7 Containerships: Design, Construction, and Operational Experience', TRANS., SNAME, 1974. 2. Kloetzli, J., and Billingsley, D., "NIDDESC: Meeting the Data Exchange Challenge Through a Cooperative Effort', SNAME NSRP 1989 Ship Production Symposium, Arlington, VA, Sept. 1989. 3. Streiff, M. A., and Cada, D. G., "Applications of Digital Transfer of Computer-Aided Design Data for Production Usage', ./our. of Ship Production, Vol. 5, No. 1, Feb. 1989, pp 16-21. 4. Port, O., Schiller, Z., and King, R. W., "A Smarter Way to Manufacture", Business Week, No. 3157, April 30, 1990, pp 110-117. 5. Fulton, R. E., and Salley, G. C., "IPAD: A Unique Approach to Government/Industry Cooperation for Technology Development and Transfer", NASATM-86422, June 1985. 552

6. Miller, R. E., "IPAD-Integrated Programs for Aerospace Vehicle Design", NASA Contractor Report 3890, May 1985. 7. Blackburn, C. L., Storaasli, O. O., and Fulton, R. E., "The Role and Application of Data Base Management in Integrated Computer-Aided Design", Your. Aircraft, Vol. 20, No. 8, Aug. 1983, pp 717-725. 8. Wilson, P. R., "A Short History of CAD Data Transfer Standards", IEEE Computer Graphics and Applications, Vol. 7, June 1987, pp 64-67. 9. Dube, R. P., and Smith, M. R., "Managing Geometric Information with a Database Management System", Special Edition of IEEE Computer Graphics and Applications, Oct. 1983, pp 57-62. 10. Taggert, R., ed., Ship Design and Construction, SNAME, New York, 1980. 11. Marine Board, NRC, 'Toward More Productive Naval Shipbuilding" DTIC AD-A152 054, National Academy Press, 1984, p 5. 12. Kloetzli, J. W., private communication. 13. Owen, J., and Bloor, M. S., "Neutral Formats for Product Data Exchange: the Current Situation', Computer-Aided Design, Vol. 19, No. 8, Oct. 1987. 14. Mayer, R., 'if'he Case for IGES" Machine Design, Vol. 59, June 1987, pp 96-99. 15. Carson, G. S., "The Future of ISO Graphics Standards', IEEE Computer Graphics and Applications, Vol. 8, July 1988, pp 82-83. 16. Brandli, N., and Mittelstaedt, M., "Exchange of Solid Models: Current State and Future Trends", Computer-Aided Design, Vol. 21, No. 2, Mar. 1989. 17. Schmitt, R. A. M., "State of the Art of Interfaces for the Exchange of Product Model Data in Industrial Applications" Report N 96.4, Institut fur Rechneranwendung in Planung und Konstruktion, Karlsruhe, Dec. 1989. 18. Kuttner, B. C., and Lachance, M. A., 'The Dilemma of CAD Data Exchange', Personal Workstation, April 1990, pp 32-36. 19. Arnold, H., Brunner, R., and Blackshaw, J., "Integrated Computer-Aided Design and Ship Production Systems', 3rd Int. Conf. on Computer Applications in the Automation of Shipyard Operation and Ship Design (ICCAS), Glasgow, 1979. 20. Belda, J. A., "I'he FORAN System", 3rd Int. Conf. on Computer Applications in the Automation of Shipyard Operation and Ship Design (ICCAS), Glasgow, 1979. 21. Kanou, M., Shirakami, H., Inoue, T., and Moriya, Y., "HICADEC: Integrated CAD/CAM System with 3 D Interactive Data Processing Architectures for CIMS in Shipbuilding", Jour. SNAJ, Vol. 160, Dec. 1986 (in Japanese). 22. Inoue, T. et al, "HICADEC: Integrated CAD/CAM System with 3D Interactive Data Processing Architectures for CIMS in Shipbuilding", 6th Int. Conf. on Computer Applications in the Automation of Shipyard Operation and Ship Design (ICCAS), Shanghai, 1988.


23. Okumoto, Y., Takeda, Y., and Hiyoku, K., "Modern Hull Structure Design System 'COSMOS'", 5th Int. Conf. on Computer Applications in the Automation of Shipyard operation and Ship Design (ICCAS), Trieste, Sept. 1985. 24. Di Luca, R., and Bais, E., "SCAFO, a CAD and CAM Integrated System From Basic Design to Assembly", 3rd Int. Conf. on Computer Applications in the Automation of Shipyard Operation and Ship Design (ICCAS), Glasgow, 1979. 25. Johansson, K., "STEERBEAR HULL 3- Interactive Graphical System for Hull Applications", 4th Int. Conf. on Computer Applications in the Automation of Shipyard Operation and Ship Design (ICCAS), Annapolis, MD, 1982. 26. Funaoka, K. et al, "New Integrated Ship Design System Mates", 6th Int. Conf. on Computer Applications in the Automation of Shipyard Operation and Ship Design (ICCAS), Shanghai, 1988. Sakai, M., "Integrated CAD System for Ship 27. Accommodation", 6th Int. Conf. on Computer Applications in the Automation of Shipyard Operation and Ship Design (ICCAS), Shanghai, 1988. 28. Baret, B., "SICEN, A Computer-Aided Design for Preliminary Draft and Detailed Steel Structure Studies of a Ship (System Architecture, Operational Conditions and Economical Data) 2nd Int. Conf. on Computer Applications in the Automation of Shipyard Operation and Ship Design (ICCAS), Gothenburg, 1976. 29. Ikonen, J., "l'he Integration of CAD/CAM Systems at Wartsila Shipyards", 5th Int. Conf. on Computer Applications in the Automation of Shipyard Operation and Ship Design (ICCAS), Trieste, 1985. 30. Ames, R. M., and Lynaugh, K. M., "A Review of Hullform Design Systems for the Marine Industry", Proceedings of CADMO 88, the 2nd Int. Conf. on Computer-Aided Design, Manufacture and Operations in the Marine and Offshore Industries, Southhampton, 1988. 31. Krietemeijer, J. H. "Standardization in Computer Applications in the Field of Shipbuilding", 2nd Int. Conf. on Computer Applications in the Automation of Shipyard Operation and Ship Design (ICCAS), Gothenburg, 1976. 32. Liewald, M. H., "Futures in CAD/CAM Data Management", 4th Int. Conf. on Computer Applications in the Automation of Shipyard Operation and Ship Design (ICCAS), Annapolis, MD, 1982. 33. Malloni, J. S., and Nusinow, S. E. I., "An Engineering/Manufacturing Enterprise Integrated Information Control System", 5th Int. Conf. on Computer Applications in the Automation of Shipyard Operation and Ship Design (ICCAS), Trieste, 1985. 34. Xia, D., "An Approach of Integrated DBMS for CAD/CAM and MIS", 5th Int. Conf. on Computer

35.

36.

37.

38.

39.

40.

41.

42.

43.

44.

45.

Applications in the Automation of Shipyard Operation and Ship Design (ICCAS), Trieste, 1985. Johnson, B., Glinos, N., and Anderson, N., "A Progress Report on a Proposed ITFC 'Open Architecture' Standard Format for Hullform Databases", Proceedings of the 22nd American Towing Tank Conference, St. Johns, Newfoundland, Aug. 1989. Dern, J.-C., Diserbo, D., and Nedellec, A., "The Establishment of a Data Base of Experimental Results for the Bassin D'Essais des Carenes", Proceedings of CADMO 88, the 2nd Intl. Conf. on Computer-Aided Design, Manufacture and Operations in the Marine and Offshore Industries, Southhampton, 1988. Parker, M.N., Odabasi, A. Y., Fitzsimmons, P. A., and Goggin, C.J., "Advanced Technology in Ship Design Analysis and Production", Naval Engineers Journal, May 1984. Odabasi, A. Y., Patterson, D. R., Williams, E. A., and Davison, G. H., "Britships-Application of Advanced Technology to Shipbuilding CADCAM", 6th WEMT Symposium, Lubeck-Travemunde, 1987. Archer, D. J., and Marshall, G., "Preliminary Ship Design: A Rational Approach Using Microcomputers", Proceedings of CADMO 88, the 2nd Int. Conf. on Computer-Aided Design, Manufacture and Operations in the Marine and Offshore Industries, Southhampton, 1988. Carlier, M., and O'Docherty, M., "l'he Use of a Data Base in the optimization Process of a New Design", Proceedings, Int. Symp. on Ship Hydrodynamics and Energy Saving, El Pardo, 1983. Allieri E., and Sartori, G. A., "An Integrated System for Storage, Retrieval and Manipulation of Ship Design Information", 6th Int. Conf. on Computer Applications in the Automation of Shipyard Operation and Ship Design (ICCAS), Shanghai, 1988. Molyneux, W. D., "A Ship Model Database for Computer Applications", 39th Annual Technical Conf., Canadian Shipbuilding and Ship Repairing Assoc., Feb. 1987. Ogiwara, S., Namimatsu, M., Ochi, M., and Mori, M., "Computer System for Ship Propulsive Performance", 3rd Int. Conf. on Computer Applications in the Automation of Shipyard operation and Ship Design (ICCAS), Glasgow, 1979. Fujino, R., Katagiri, T., Ishida, S., and Sate, R., "Computer-Aided Design System for Marine Propellers", 4th Int. Conf.on Computer Applications in the Automation of Shipyard operation and Ship Design (ICCAS), Annapolis, MD, 1982. Keeps, A., "Hull Form Definition and ComputerAided Design", Proceedings, 5th Int. Conf. on Computer Applications in the Automation of Shipyard Operation and Ship Design (ICCAS), Trieste, 1985.


553

46. Oomen, A.C.WJ., and van Oossanen, P., "Development of a New Computer-Aided System for the Conceptual Design of Ships", 6th WEMT Symposium, Lubeck-Travemunde, 1987. 47. van Oossanen, P., "Preliminary Ship Design Using the HOSDES CAD System", 7th WEMT Symposium, 1988. 48. Koops, A., et al, "HOSDES: A New ComputerAided System for the Conceptual Design of Ships", Bicentennial Symposium, Sydney, Australia, 1988. 49. van Oortmerssen, G., and van Oossanen, P., "A New CAD System for the Design of Ships", Proceedings of CADMO 88, the 2nd Int. Conf. on Computer-Aided Design, Manufacture and Operations in the Marine and Offshore Industries, Southhampton, 1988. 50. Glijnis, B., "HOSDES/MARDES: A New Concept for CAD Systems", Schip en Werf, Vol. 56, June 1989, pp 196-202. 51. Koops, A., Oomen, A.C.WJ., and Bras, B.A., "Computer Based Design Assistance and Decision Support", Proceedings,6th Int. Conf. on Computer Applications in the Automation of Shipyard Operation and Ship Design (ICCAS), Shanghai, 1988. 52. Hasegawa, K., et al, "HDS - Hull Data System in Mitsubishi Heavy Industries, Ltd." 2nd Int. Conf. on Computer Applications in the Automation of Shipyard Operation and Ship Design (ICCAS), Gothenburg, 1976. 53. Yoshikal, T., amd Yamatsuta, M., "Fundamental Ship Design Using a Data Base", 4th Int. Conf. on Computer Applications in the Automation of Shipyard Operation and Ship Design (ICCAS), Annapolis, MD, 1982. 54. Williams, A., "Analysis and Storing of Ship Propulsion Data", SSPA Pub. No. 73, presented at the 1st Int. Conf. on Computer Applications in the Automation of Shipyard Operation and Ship Design (ICCAS), Tokyo, 1973. 55. Biran, A., and Kantorowitz, E., "Ship Design System Integrated Around a Relational Data Base", Proceedings, Int. Conf. on Computer Aided Design, Manufacture and Operation in Marine and Offshore Industries, Washington, DC, 1986. 56. Fritts, M., Comstock, E., [,in, W.C., and Salvesen, N., "Hydro-Numeric Design: Performance Prediction and Impact on Hull Design", TRANS., SNAME, 1990. 57. Larsson, L., Broberg, L., Kim, K., and Zhang, D., "A Method For Resistance and Flow Prediction in Ship Design", TRANS., SNAME, 1990. 58. Mori, M., "Design Conception and CAE/CAD of Hull Form", Proceedings, 13th Ship Tech. and Research (STAR) Symp., SNAME, 1988. 59. Johnson, B., "On the Integration of CFD and CAD in Ship Design", Proceedings of the Int. Symp. on CFD and CAD in Ship Design, Wageningen, 1990. 60. Hoyle, J. W. et al, "A Bow Bulb Design 554

61.

62. 63. 64. 65.

66. 67. 68. 69.

70. 71.

72. 73.

74.

75. 76.

77.

Methodology for High Speed Ships", TRANS., SNAME, Vol. 94, 1986. Sellars, F., and Setterstrom, C., "Impacts of Seakeeping on Ship Operating Economics", paper No. 22, Int. Symp. on Ship Operations, Management and Economics, Kings Point, 1987. Codd, E. F., "A Relational Model of Data for Large Shared Data Banks, Communications of the ACM, Vol. 13, No. 6, June 1970, pp 377-387. International Towing Tank Conference, Standard Symbols and TerminologyList, Draft, 1990. Mumford, A. M., "Why care about the Computer Graphics Metafile?", Computer-AidedDesign, Vol. 19, No. 8, Oct. 1987. Yamamoto, Y., and Murahashi, Y., "Common Language for Multilateral CommunicationBetween Different CADCAM Drawing Databases", Computer-AidedDesign, Vol. 21, No. 10, Dec. 1989. Ohsuga, S., 'Towards Intelligent CAD Systems", Computer-Aided Design, Vol. 21, No. 5, June 1989. Papers in Proceedings, International Workshop on Object Oriented Database Systems, IEEE, 1986. Maier, D., The Theory of Relational Databases, Computer Science Press, 1983. Maier, D., and 7_,donik, S., "Object Oriented Database Systems", Tutorial, Second Int. Conf. on Data and Knowledge Systems for Manufacturing and Engineering, NIST Gaithersburg, MD, Oct. 1989. (also OOPSLA 1989). Cox, B., Object Oriented Programming, Addison Wesley, 1986. Brodie, M., and Mylopoulos, J., "Integrating AI and Database Technologies", Tutorial, l lth Joint Conference on Artificial Intelligence, Detroit, MI, 1989. Penrose, R., The Emperor's New Mind, Oxford University Press, New York, 1989. Andrews, A. E., "Progress and Challenges in the Application of Artificial Intelligence to Computational Fluid Dynamics", AIAA Journal Vol. 26, No. 1, Jan. 1988. Tong, S. S., "Coupling Symbolic Manipulation and Numerical Simulation for Complex Engineering Designs", Proceedings, Conference on Expert Systems for Numerical Computing, Int. Assoc. of Mathematics and Computers in Simulation, Purdue University, Dec. 1988. Schaffer, R., Byers, D., and Slager, J., 'Towards an Improved Hull Form Design Methodology", Naval Engineers Journal, May, 1983. MacCallum, K. J., "Creative Ship Design by Computer", 4th International Conference on Computer Applications in the Automation of Shipyard Operation and Ship Design (ICCAS), Annapolis, MD, 1982. Duffy, A. H. B., and MacCallum, K. J., "Computer Representation of Numerical Expertise for Preliminary Ship Design", Marine Technology, Vol. 26, No. 4, Oct. 1989.


1.0 Collect and store data from model tests and

78.

79. 80.

81.

82. 83.

Codd, E. F., "Relational Data Base: A Practical Foundation for Productivity", Communications of the ACM, Vol. 25, No. 2 Feb. 1982, pp 109-117. Barker, R., CASE*Method Entity Relationships Modeling, Addison Wesley, Reading, MA. 1989. Zachman, J. A., "A Framework for Information Systems Architecture", IBM Systems Journal, Vol. 26, No. 3 1987. Chen, P. P., "I'he Entity-Relationship Model Toward a Unified View of Data" ACM Transactions; Database Systems, Vol. 1, 1976, pp 9-36. UUman, J. D., Principles of Database Systems, Computer Science Press, 1982. Ozkarahan, E., Database Machines and Database Management, Prentice Hall, 1986.

APPENDIX 1

RELATIONAL DATABASE DESIGN PRINCIPLES 1. A PROTOTYPE RELATIONAL DATABASE FOR HULL FORMS The mechanics involved in the development of relational databases have been well studied and documented (Codd [61], Codd [78], Maier [67]). To insure database compatibility with NAVSEA and DTRC, the ORACLE relational database management system (RDBMS) was chosen for prototype development. ORACLE is supported by a variety of database design tools including CASE*Designer and CASE*Dictionary (Barker [79]). These tools were used to design a prototype relational database to be used as the basis for a proposed neutral standard format for exchanging ship hull form data within the I'Iq'C member organizations. The design of the prototype database was guided by the desire to have a standard database exchange format for the many types of ship hull forms, propellers, and appendages which are tested by the International Towing Tank community. 2.

DATABASE STRATEGY ANALYSIS: FUNCTIONAL HIERARCHY

An important step in designing a database using the CASE*Method is establishing the functional and information needs of the organizations which will use the capabilities of the database, i.e.,'q'he Strategy" (Malloni [33], Zachman [80]). The strategy model for the prototype database was developed using interview questions posed to several experienced "experts" in the ship hull form design field. Based on answers received in response to the interview questions, a Functional Hierarchy for the database was developed which is summarized as follows: 0.0 Create and maintain a prototype database for hull form design studies and for hydrodynamic code validation studies.

analytical studies. Use this data for comparative hull form evaluation and analysis.

1.1 Collect data from towing tank tests and analytical studies for entry into the hull form database. 1.1.1 Select and categorize the types of hull forms to be entered initially into the database. 1.1.2 Enter geometry and performance data. 1.2 Perform analytical studies. 1.2.1 Perform resistance and powering study. 1.2.2 Perform seakeeping study. 1.2.3 Perform various other studies. 1.3 Support model basin tests. 1.3.1 Obtain data and comments for previous model tests to aid in preparation for new/current model tests. 1.3.2 Compare analytical study or previous model test output to current model test output for a quick comparison of validity of current data. 1.3.3 Prepare report of relevant model test information for client. 1.4 Archive selected geometry and performance data. 1.5 Conduct Performance evaluations. 1.6 Produce Reports on specific hull forms. 2.0 Perform validation studies for new hydrodynamic codes.

2.1 Demonstrate that a new code works on a new machine by obtaining the same results as those obtained on the original machine. 2.2 Demonstrate that a particular new code equals or improves upon the performance predictions of other codes and experimental methods which are not so convenient to use. 2.3 Establish the sensitivity of the new code to small changes in hull geometry. 2.4 Establish practical limits on the use of a new code as a function of key hull form characteristics and the domain of operation, i.e., speed range, sea states, etc. 3.0 Apply M/Decision Support modules to the hull form design process.

3.1 Use knowledge bases for various ship classes, based on imitating human behavior in the design process. 3.2 Generate problem statement. 3.2.1 Formulate decision statement. 3.2.2 Establish and classify objectives and requirements. 3.2.3 Establish design constraints. 3.2.4 Establish mission effectiveness criteria. 3.3 Create candidate hull-form alternatives for further analysis. 3.4 Evaluate alternatives. 3.5 Select most promising hull form. 3. ENTITY.RELATIONSHIP MODEL The next step in the CASE*Method was the development of an entity-relationship diagram (Zachman [80], Chen [81], Ullman [82]). An entity is an object or "thing of significance", whether real or


555

symbolic, about which information needs to be known or stored. The entity-relationship diagram graphically illustrates the entities and the relationships which join two entities through a common link. The development of an entity-relationship diagram is essential in the "top down" method of designing a database system. It depicts all the significant categories for which the database users need to keep information and it illustrates all the primary relationships among them. Each entity can be described by a set of attributes, which include any detail that quantifies, qualifies, identifies, classifies or expresses the state of an entity. An entity set is a collection of entities of the same type. An entity set in a relational database is implemented as a table of rows and columns. The table rows correspond to entity members and the table columns correspond to their attributes. An entity may contain sub-entities. Subentities inherit attributes and relationships of their super-entities but they may also have attributes and/or relationships of their own. It is necessary to uniquely identify each row, or record, of a table. A unique identifier, called a key, serves this necessity by combining a set of attributes to uniquely identify each row. There may be more than one key for each table. One of the keys is designated as the primary key. A set of table attributes is called a foreign key if it is the key of another table. A foreign key actually implements a one-to-many relationship between two tables. A relationship is any significant way in which two entity sets (tables) are associated. Relationships may be one of three types, depending on the number of entity members on the two sides of the relationship, i.e. oneto-one, one-to-many (many-to-one), and many-to-many relationships. The most commonly used is the one-tomany relationship. Many-to-many relationships should be avoided whenever possible by creating intermediate entities. In addition to structural information about the database being designed, the entity-relationship diagram contains semantic information that must be considered so that the database implemented is free of anomalies and undesired properties such as redundancy, inconsistency (update anomalies), insertion and deletion anomalies. The semantic information is conveyed with a set of known functional dependencies among the attributes of the relations. A functional dependency X -> Y specifies that the set of attributes Y depends on the attributes X. That is if two tuples (rows) in the relation (table) have the same values for the attributes in X, then they must have the same values for the attributes in Y. Normalization is a formal, systematic procedure for testing the relations against well defined rules, stemming from the mathematical theory underlying the relational model. These rules define various normal forms in which the types of allowable functional dependencies are restricted so as to avoid the above problems when the database is developed. There are several normal forms. The most important are the first (1NF), second (2NF), third (3NF) and Boyce-Codd (BCNF) normal forms, a full description of which can be found in the literature (Ullman [82], Ozkarahan [83]). 556

Several entity-relationship diagrams were constructed before converging to the one illustrated in Figure 17. Boxes represent entities and lines represent relationships among the entities as follows: Solid lines are translated into "must be" and dashed ones into "may be". Fanning into more than one line at the end means "one or more". For example the relationship between the HULL and PROPEI.I F R entities reads: A HULL may be propelled by one or more PROPELLERS and A PROPEl J.ER must be designed for one H U l L Propellers and appendages are usually associated with a particular hull form. However they can be designed independently of a hull, in which case they will be associated with a ubiquitous STOCK hull. CASE*Designer uses the entity-relationships model to create tables and determine keys and foreign keys of tables so that the relations described by those tables are in normalized form. The process of converting an entity-relationship diagram into a set of tables is fairly straightforward. Using default naming conventions, an initial database can be generated. SQL statements are created so that, when executed, create the tables and the columns which are included in the Data Dictionary. This database can always be modified to suit individual needs. One of the principal benefits of the current generation of relational database systems is the automatic maintenance of the data dictionaries by the system; hence tables, records and attributes, can be added or removed from the system without necessitating a complete reorganization of the file store. This allows the database design to be altered as new developments and applications become available, without incurring enormous overheads in re-organizing data. 4. ENTITLES AND TABLES FOR THE PROPOSED

ITrC STANDARD DATA EXCHANGE FORMAT Each entity, or table in the hull form database, has a set of attributes, arranged in columns. The majority of the attribute names are associated with either geometry or performance characteristics and are extracted from the ITI'C Standard Computer Compatible Symbols and Terminology List (SS&T List), Draft 1990 (rITC [63]). The remainder of the attributes are the key components used to uniquely identify and define each record and its relationships to other tables. From the entity-relationship diagram in Figure 17, an initial database design was developed, consisting of tables whose names were systematically assigned. These names will eventually constitute a proposed 1TI'C standard list of table and attribute names, modifiers and qualifiers to be added to the ITTC Standard Symbols List. The suggested names for the upper level tables are printed in Italics. Boldface names are corresponding entities. Note that table names consist of four letter abbreviated names followed by four letter qualifiers to indicate the type of table.


designedFord APPENDAGE ] ~ APPN:INDX J deF;nedbyi

I HULL_INDX~ HULL ~appendedby designedf ~ PROPELLER] ' propetted by ~PROP_INDX deF;nedby , de?,ned by ', /~ deF,n,t,onoF HULL FORN

GEOMETRY

i b

/~de£,n,t;on oF PROPELLER 1 GEOMETRY

1

]HARACTERISTICS HGEO_CHAR ~used For sourceo£

/~deF,n,t,onOF

APPENDAGE I GEOMETRY SHARACTERISTICS

CHARACTERISTICS PGEO_CHAR ',used For

ou,,,

AGEO_CHAR

--~usedFor

....

MODEL REALIZATION MODL_INDX

FTANK/TUNNEL ANALYTICAL MODEL MODEL LMODL_EXPR

FULNL0:EC?LE

MODL_ANAL L MOBL FSCL

I componento£ 9ro~

~

MODEL SET]

INDEX ~

resutt o£ HYDROS TA TICS l,nduded, n

HHST_CHAR J

loosedo ~

L

requ,red bay

TEST ~ ~ TEST INDX ./--

Database Systems for Hull Form Design

Database Systems for Hull Form Design

Suggest Documents

motor yacht hull form design for the displacement to semi

Database Design Patterns for Healthcare Information Systems

key challenges and opportunities in hull form design ... - Core

DATABASE SYSTEMS DATABASE SYSTEMS

WP 4 Ship hull coating systems compared-Design

Relational database management systems, database design, and gis

Relational database management systems, database design, and gis

Charles W. Hull - 3D Systems

Database Systems: Design, Implementation, and ... - WikiStudent

Database Systems: Design, Implementation, and ... - Google Sites

Read [PDF] Database Systems: Design ... - Google Sites

eBook Download Database Systems: Design ... - Google Sites

Read Online Database Systems: Design ... - Google Sites

PDF Database Systems: Design, Implementation ... - Google Sites

[Full] Database Systems: Design Book - Google Sites

[PDF] Download Database Systems: Design ... - Google Sites

[PDF] Database Systems: Design eBook - Google Sites

Read Online Database Systems: Design ... - Google Sites

[PDF] Database Systems: Design, Implementation ... - Google Sites

Download Database Systems: Design, Implementation, & Management

Download Database Systems: Design, Implementation ... - Google Sites

[PDF BOOK] Database Systems: Design ... - Google Sites

Download Database Systems: Design, Implementation, Management ...

Download [PDF] Database Systems: Design ... - Google Sites