Vous êtes sur la page 1sur 13

ARTICLE IN PRESS

Ocean Engineering 34 (2007) 917929 www.elsevier.com/locate/oceaneng

Technical note

The collaboration modelling framework for ship structural design


Wei Tann, Heiu-Jou Shaw
Department of Systems and Naval Mechatronic Engineering, National Cheng Kung University, Taiwan, ROC Received 14 December 2005; accepted 3 May 2006 Available online 25 September 2006

Abstract Within a shipyard, many designers each have their own design objective cooperating in complex design circumstance that a variety of software tools run on different hardware platforms. Different CAD systems are used by different design stages and departments, and the design result is usually delivered on paper drawings. The proliferation of data and the rising number of disparate data systems do not communicate with each other and certainly do not collaborate. Advanced 3D modelling tools are installed in most of progressive shipyards for advantage to improve their productivities. However these 3D models are repetitiously constructed as per the specied design objectives of disparate software tools in various design stages. This paper describes the development of collaboration modelling framework, knowledge-based design support system, to make a web-based data-sharing collaborative environment potentially allowing to facilitate some applications, construct 3D lines rapidly, translate the product data, and further be capable of providing reasonable model congurations for XML type, and sharing the web services from the Internet to comply with shipyards specic strategy for each particular case to be designed. r 2006 Elsevier Ltd. All rights reserved.
Keywords: 3D product model; Design support system; Collaborative environment

1. Introduction Coordination procedure in the merchant ship design is a widely and predominantly analyzed eld. While design deadlines become shorter and shorter, the complexity of modern commercial vessels increases steadily, so that these design systems are more and more indispensable for integration in maritime industry. The ship design process typically involves a large number of disparate software tools evaluating a variety of characteristics and life phases (structural, operational performance, production scheduling, etc.) in order to enable the production of a ship design that satises the customers requirements. The software tools generally produce discrete solutions to a particular problem with respect to a set of requirements. That is, they have their own model and solution representations (Erikstad and Fathi, 1999) and are rarely inuenced by the interactions with other tools. As such, a large complex ship design project may have multiple representations of
Corresponding author. Tel.: +80101112466; fax: +886 7 8033135.

E-mail address: joseph.tann@msa.hinet.net (W. Tann). 0029-8018/$ - see front matter r 2006 Elsevier Ltd. All rights reserved. doi:10.1016/j.oceaneng.2006.05.012

different aspects of the same design model, distributed either organizationally or more commonly, globally. Managing the data within these models to maintain consistency is an important but complicated task (Staebler, 2002). Product modelling techniques of design tools undertake to address these issues by providing a central store of (neutrally formatted) data common. These modelling tools can then access these data, add their own embellishments if required, and perform design, analysis, while translating and then maintaining consistency with all of the other software tools (Bronsart et al., 2002). Because the data are shared among these tools, the store of data has often been called the common model. However, within some of modern heavy industries, such as shipbuilding industry, it is more commonly referred to as the ship product model. It is generally accepted that each individual life cycle within the development of the ship product is associated with the production and management of a large quantity of complicated and interrelated product data (Polini and Meland 1997; Catley, 1999). The data often relate to geometrical, topological, functional, material, production,

ARTICLE IN PRESS
918 W. Tann, H.-J. Shaw / Ocean Engineering 34 (2007) 917929

Nomenclature AutoKon shipping research services A/S, Oslo, Norway AVEVA provides shipbuilding IT practices DXML elements XML schema used to store in draft modeler and validate using design rules Do/DE design objects/design elements (objects designed using KESS) ERP enterprise resource planning FEM/FEA nite element method/analysis IE internet explorer KBE knowledge base editor KBS knowledge base server KESS knowledge-based design support system MLA material list for administration system PM project management

MLP PDMS POS RO/RE

material list of piping system plant design management system, AVEVA purchase order specication reference objects/reference elements (object referred by KESS) SCM supply chain management TID Tribon initial design Tribon maritime design system, AVEVA TXML elements XML schema used for import/export to Tribon UI user interface UML unied modelling language VANTAGE Marine a fusion of Tribon and PDMS systems by AVEVA X3D extensible 3D XML extensible markup language XSLT extensible style language

operational, and other aspects of the product. Within the shipbuilding industry, the full life cycle of the product is expected to last more than 20 years (Wyman et al., 1997), and in some cases, such as the naval industry, it may be as long as 40 years, posing some important issues with respect to the organization and management of the product model. The representation, requirement, and usage of the ship product model will also vary depending on the current life phase. For example, three-dimensional geometrical data may be used more extensively within the design and production life phases, whereas the bill of materials would be more relevant to recycling during the disposal life phase. These issues have never before been considered within the advent of digital product modelling techniques, because these techniques have become prevalent only within the last 10 years or so, and have in general been developed and applied only to the pre-commissioning life cycle states. The structure and denitions for the data types within the precommissioning stages are becoming increasingly realized and standardized. However, little consideration has been given regarding the nature of the ship product model for the post-commissioning stages, such as operation, maintenance, ret, and disposal, and the pre-design stages of requirements analysis and feasibility studies. More importantly, due to the duration of the full life cycle of the ship product, it is essential that the data contained within the product model conform to agreed-upon standards such that support may be maintained through a number of generations of computer architectures, operating systems, and ship development environments. In a brief review of the state of the art of the product modelling technologies, Ross and Garcia (1998) identify a number of characteristics that advanced product models possess: a single, integrated database; graphical user interface with a consistent format; topological relationships among components of the ship design; macros and parametric tools; and open structure to allow for data retrieval to support manufacturing functions.

The paper rst discusses the ship design circumstance and problems between systems today and how these are addressed by the proposed collaboration modelling framework, KESS, and then outlines some of the requirements background and develpoment. This is followed by a description of KESSs outline perspective. 2. Description of design circumstance The processes of ship design and production can essentially be divided into several sub-phases in which different tasks are to be performed for the nal production information (Whiteld et al., 2003). The traditionally accepted design stages include feasibility studies or designs that are low level of denition, concept design with a slightly higher level of denition (system denition), preliminary design with additional system denition, contract design with a level of denition sufcient to produce a bid package (integration of design with production and specic material, equipment, and outt items specied), and detailed design with the highest level of denition (denition of joining, mountings, and foundations). Early stage parametric design tools can simplify and combine the feasibility and concept design process. These design tools utilize low denition design and metrics and perform the traditional function of dening a balanced design that meets early stage performance and cost criteria (Maritech ASE-Project 99-21, 2000). The basic systems required to support the mission are dened and general space allocations provided, accordingly leading to a generalized envelope or hull to contain the payload and the necessary support systems. The functional design approach is based on a spatial process with performance requirements and constraints, as well as productivity requirements and constraints, as the key elements of design. The ship type is designed from the project start as a combination of interim products, which

ARTICLE IN PRESS
W. Tann, H.-J. Shaw / Ocean Engineering 34 (2007) 917929 919

are addressed as individual work packages that have both labor and material content. Using a shipbuilding strategy based on appropriate (functional and production) design rules and metrics, a whole ship design that is sensitive to both functional and productive requirements can be developed (Rossii and Abal, 2001). Over the functional design stage, the design process in most shipyards utilizes 2D CAD systems, such as AutoCAD etc., to quickly create the functional designs. 2D drafts based on 3D CAD/CAM systems would mean frequent modications in multiple complicated steps to nalize a design version. 2D CAD software with simpler revising features (such as AutoLISP and drawings reference of AutoCADs functionalities) is mainly used to streamline drawing activities. 3D modelling is usually created according to 2D drawings, which are referred as 3D modelling information. However, 2D drawing sketches should be originally generated from 3D models slices. Today it is still tough to take over the data from the functional designs or even the earlier initial design stage. The other crucial problem for ship design programs is that 3D model repository can not offer consistent and collaborative information as soon as possible to facilitate information utilization. Almost all structure designs before and during the approval phase have been based on 2D drawings instead of 3D modelling even though there are many advantages of using 3D structure models. 2D structural design drawings are rapidly drafted by AutoCAD from the beginning on functional design stage, in order to be approved for structure strength from classication societies, then referred to Tribon 3D hull modelling as well as the outtting background to piping designs and arrangements on PDMS. 3D hull models are also re-built as 3D models for the pre-processor of vibration analysis etc. Fig. 1 illustrates completed 3D modelling process on the design and production stage. While 3D product information is going to gradually accumulate to the practical production needs, it is quite difcult to coordinate designs of complicated 3D structures with a set of 2D drawings, and thus cause design errors easily. 3D product models of structures can provide designers with all relevant information both from the strength and manufacturing points of view. Shipyards have a view primarily oriented towards constructability. The modelling software must be robust enough to handle many design aspects, not just
Initial Design TID Lines Hull Tribon Hull 3D Modelling AutoCAD2D Drawing Analysis Tools Specified 3D Modelling Piping & Outfitting PDMS 3D Modelling

structures. In addition, 3D models are needed to efciently support FEM/FEA tools. From 2D drawings, engineers must digest the information to build a 3D FE model for FEA; however with a 3D ship design model the FE model can be more readily generated. 3. Requirement and development to KESS 3.1. Background Many benchmarking studies have been conducted to compare the big-sized shipyard in Taiwan to overseas competitors. In general, these studies have shown that the maritime technology lags behind the worlds best shipbuilders in many areas. A major area of shortfall is in technology application, especially as related to white-collar functions. In the shipyard, Tribon and PDMS CAD/CAM systems have been used for hull production and outtting arrangement respectively since the past decade. All design consequences for structural, piping and outtting production components are dened into Tribon product information model (PIM) and the PDMS databases. In proportion to having higher costs, the shipyard spends considerably more time to complete a typical design and construction process. A signicant part of that is in the design phase, and design phase communications and decisions greatly affect the saving potential in manufacturing. 3.2. Collaboration approach A conventional serial sequence of one process step after the other for shipbuilding is history. One of the prominent progresses has been made in exchanging geometries with a detailed database of different design information from 3D modelling systems and 2D drafting by meta data denition, so as to promote the information and material ows against the entire performance of design and manufacture (Shin and Han, 1998). According to the architecture for the shipyard organization, specic discipline centers operating manifold systems are to be distinguished as design center, engineering center, and administration center, communication with each other through Internet and exchanges the XML-formatted information. A coordinated product model must reect details of the product being designed and stages of evolution in the process of creating the
Detailed Design Production

Functional Design

Fig. 1. Design and production process at present.

ARTICLE IN PRESS
920 W. Tann, H.-J. Shaw / Ocean Engineering 34 (2007) 917929
Design Center

Parameterized hull form design

Spec. Classification Modeling KM Database SQL Database

Initial design

XML

Functionality design Key plan (Structure) Functionality design Key plan (Outfitting) Outfitting Machinery Manufacturing design Yard plan (Structure) Hull XML

Vantage Marine Database XML

Manufacturing design Yard plan (Outfitting) POS/MLA/MLP SQL Database Production design Working plan (Structure) Engineering Center

Machines construction PM

ERP .com SCM XML

Oracle Database Manufacturing preparation Administration Center

Production NC /welding

BI Quality control Material control

Fig. 2. The data process and collaborative information environment for the going scheme.

product (Fig. 2). These stages involve the uses of many tools and technologies to perform specialized functions. In order to be truly integrated, the product information should enable to be transacted with all the disparate technologies over design and production process (Tann et al., 2005). Current CAD/CAM systems will not achieve this need, and the systems have limited capabilities to interface with other proprietary systems and technologies. 3.3. Develop the implement A dominant reasons to inuence the integration of upstream and downstream design stages is derived from a gap of the representation levels between the ship designers cognitive and modelling processes. The leading application ranges, however, appear to be limited in production design

and production data on the phases of generation works, and therefore some available solutions have been proposed to ship designers to coordinate the early design stages. Ship designers on early stage handle some non-visual information such as functional requirements and abstract concepts synchronously, and visualize them gradually through incessant trial and error. From the standpoint of more competitive design, there is an increasingly strong demand from a few people for rapid design need proposed especially in recent years (Storch et al., 2002). The development of concurrent design should be from the early functional design stage. These tasks in either a prototype stage or production stage consume large amounts of highly specialized technical labor, but on certain degree can be substituted automatically through specically designed systems (Miyamoto et al., 2002).

ARTICLE IN PRESS
W. Tann, H.-J. Shaw / Ocean Engineering 34 (2007) 917929 921

Web-based KESS utilizes XML data format describing the object characteristic by XML schema of Tribon hull structure (AVEVA Tribon M3 Users Guides, 2005) and visualize these exchange data on the web from the very beginning, offering designers at different geographical locations consistent design model data for different utilizations to avoid repetitious modelling works. KESS enables to reduce the proportion of 2D drawings on the functional structure design phase, shorten the design processes and further compresses the entire manufacturing schedules. 4. System perspective 4.1. Overview A smart product model is developed following an object-oriented approach such that it addresses not only an objects attributes and relationships, but encapsulates behaviors with the object that control how the product data is accessed and used. Once the failed commissions occurring from the system operation or on the underdevelopment circumstance, the utilization of the objectoriented concept to construct these stand-alone programs and sub-systems enables the designers to use these still well coordination functionalities with their judgments and considerations to generate the product model. KESS is a web-based object-oriented system for designing and validating Tribon components. The validations are done as per the shipyard specic rules for the components. The validation rules to be used for component creation are stored in the knowledge database server, which can be created and developed by users. The web-based UIs provide the functionalities to modify the rule contents on the knowledge database server and create hull components via XML, scheme le or any input parameters. The system also creates XML les validated against Tribon hull XML schema. Fig. 3 presents the perspective of the system ow

chart. Currently KESS is designed to create components like longitudinal and seams which are a part of curved hull module. Tribon hull module gradually provides the mechanism which allows XML schema construct the component and access the database. By this gateway KESS can communicate with Tribon Hull module and meanwhile apply the modelling modules such as the knowledge database, inference engine, explanation facilities, and UI to rapidly generate reasonable structure as per the shipyard practice and design guidelines with very less input. 4.2. Data resources and integration The loosely coupled data for KESS is provided on data resources. Complied with the adoptability circumstance of Tribon system, the dealt design elements are categorized into two categories: the elements actually designed (DO), and the elements used as reference to validate or to generate the report data as a part of web services (RO). Components are created on KESS and Tribon system synchronously, and also, the model database backup is updated regularly with the latest data on Tribon. Thus there are two-way interactions between Tribon and KESS for exchange of data. The design elements are represented by draft modeler with the help of X3D visualization. The implementation of XMLX3D Parser which parses TXML to DXML is limited to design elements; this functionality visualizes the same components on Tribon. The integration architecture to incorporate adapters is accompanied by supplementary software products that facilitate connectivity and the overall communication process. Adapters are specialized piece of software used to connect heterogeneous applications and application components. For this legacy integration project, an adapter is required to bridge technology gaps that exit between incompatible platforms (Berry and Linoff, 2004). Fig. 4 presents the physical data transactions between applications and database.

Fig. 3. The system outline ow chart.

ARTICLE IN PRESS
922 W. Tann, H.-J. Shaw / Ocean Engineering 34 (2007) 917929

MS SQL DB

Adapter

AutoKon data Legacy application

sc001d.exe sx700.exe

XML access Tribon PIM DB Relation data RO: DO: Tribon Hull XML Schema Curved Hull XML Document

Draft Model DB

X3D Schema

X3D Document Application server

XSLT Style Sheet

Database server

Fig. 4. A physical architecture illustrates the data ow, exchange and integration between heterogeneous applications and databases.

4.3. Interoperability implement One of the most difcult tasks in co-design is to construct the interoperability commitments enabling to communicate and coordinate the distributed design support systems. Interoperability can be dened in the broadest sense as the ability of software and hardware on different machines from different vendors to share data (webopedia) and the ability of two or more systems or components to exchange information and to use the information that has been exchanged (IEEE, 1990). In general, these denitions refer to arbitrary systems, so that interoperability must be incorporated as a general architectural principle, not as a specic integration requirement with a known system. Interoperability is typically ensured by adherence to a set of common standards (Rando, 2001). This may be a direct connection, if both systems use the same data format and content. Alternatively, the systems may be connected through a mediator, which transforms the data format and content (Briggs et al., 2005). A standardization initiative for information exchange to achieve interoperability has been undertaken by KESS. XML stands for extensible mark-up language, often mentioned together with web technology and HTML, but it is important to remember that XML is basically a way to describe and structure data. It can be used in a great variety

of applications, not only in web applications. Tribon Solutions develops and supports CAD/CAM/CIM software solutions in the maritime industry. Nippon Kaiji Kyokai (Class NK) and Tribon Solutions have together made intense research investigations using XML. July 2003, Tribon Solutions promoted the standardization of the shipbuilding CAD/CAM data exchange using XML to become a de facto standard within the shipbuilding industry. XML-based schemas are developed for transfer of data inside the Tribon system and between Tribon and other systems. Historically there have for many years been difculties with the data exchange between various CAD/ CAM systems because they all have unique data formats. In Japan, shipyards have made large investments in their own in-house CAD/CAM systems; coexisting with these systems is a critical element for the future system enhancements. One of the benets of using XML as the information syntax is the amount of development of parsing, querying, transformation, validation, and presentation tools for the support of the language across all aspects of the information technology industry. Establishment of the XML standard schemas is expected to improve the data exchange to protect earlier made large investments in the in-house CAD/CAM systems. The objective of the standard was to provide a means of serializing (or persistently storing) the

ARTICLE IN PRESS
W. Tann, H.-J. Shaw / Ocean Engineering 34 (2007) 917929 923

state of (ship data) objects contained within an objectoriented database into a neutral format that may be communicated from application to application. 4.4. UML representation System modelling is the designing of software applications before coding. A model plays the analogous role in software development that blueprints and other plans play in the building of a skyscraper. UML is used to specify, visualize, and document models of software systems, including their structure and design, in a way that meets all of these requirements (http://www.omg.org/uml/). KESS basically encompasses three physical sub-systems distributed in respective server machines, viz. draft model visualizer, knowledge management (Negnevitsky, 2002), Tribon application server and PIM. Depending on the nal deployment policy the knowledge server and draft server can be one physical system in a clients network (Fig. 5). One of the main actors of the system is administrator who has full access rights to read, modify and delete elements from the knowledge base DB, MS SQL (which is called in the system as design administrator). Modeler has access rights to model draft database and read only access rights to knowledge base DB. Since the modelers and, Administrator do have common properties, an abstract actor called viewer is added to the system that the viewer can have readonly access rights to the system. Actor relation diagram is referred for visual representation of relationship among

viewer, modeler, and administrator. The read-only access rights to the knowledge base DB assists viewer to know the rules and the default standard data set going to be applied while designing elements. It can assist the modeler to know the class rules and standard practices (Fig. 6). The draft modeler use case diagram presents the use cases related to the modelling activity and draft server events. Since this is a very high-level use case diagram, other abstract use cases which are not directly invoked by an external actor are ignored, only a few abstract use cases which are directly related to the use cases invoked by external actor are visualized in the diagram (Fig. 7). The sequence diagram illustrates the program manipulation processes while viewer creates a component (Fig. 8). Draft modeler DB is accessed and updated during operation. The created component data can be transmitted in XML type validated by TXML and stored into Tribon PIM after completion. 5. System functionality perspective The system utilizes ASP.NET to construct all UIs, with C# code behind driving .NET framework components and product model components. Besides, in order to get the DHTML behaviors in up-level browsers, IEWebControls is adopted to develop these web form UIs. IEWebControls encompasses TreeView, TabStrip, and MultiPage etc. components. When the control detects that an up-level browser made the last request, the controls emit dynamic HTML. DHTML uses the browsers inner object model

Knowledge Server Knowledge Web Server * * * Knowledge Base DB *

Knowledge Base Editor

Knowledge Base DB contains the tables of Class Rule, Standard Reference, Rule Base and Function Library Reference *

Inference Engine is a Windows DLL Tribon DB Server * Draft Server * * Draft Model Visualizer * * * * Inference Engine * * Function Library *

Draft Web Services * *

Draft *Model DB *

* CSSA Application

*CAD Application/DLL

Fig. 5. Deployment diagram.

ARTICLE IN PRESS
924 W. Tann, H.-J. Shaw / Ocean Engineering 34 (2007) 917929

Viewer is an abstract actor having access to Viewer <<uses>> the database Server. <<uses>>

Administrator Administrator has all rights manage database server and Draft Model DB to monitor the progress.

Modeler Modeller is the actor who does modelling job. This actor will have full access right to Draft Model DB.
Fig. 6. Actor relation use case.

Export To Tribon

ImportFormDB

<<extends>> Create Model <<extends>>

Web Services

<<uses>> <<extends>> Modeller/Admin Edit Mode l <<extends>> Validate Data

<<uses>> Delete Model

Viewer

View X 3D Model
Fig. 7. Draft modeler use case.

Update Draft DB

and client-side script to make the pages within a MultiPage respond to the TabStrip without making a round-trip back to the server. To provide a convenient mechanism to customize the appearance of IEWebControls, based on their state, CSS formatting properties is also used. 5.1. Functionalities on settings and scheduler backup The web-based UIs offer the actors to operate the components. These corresponding links are programmed

by TabStrip and MultiPage controls. Settings page is accessible only to the administrator of the system. Using this page, administrator will be able to manage domains, ship types and admin right of other users (Fig. 9). The system has intelligence to identify the users belonging to specied domains added by administrator in settings page, and automatically login the user bases on windows identity. However, in order to have the exibility to access the system from any machine in the given domain or from any specied domain, application will request for password

ARTICLE IN PRESS
W. Tann, H.-J. Shaw / Ocean Engineering 34 (2007) 917929 925

KESS User

KESS CreateFunctionality

Draft Modeler

XML passers

Inference engine

TRIBON system

Create component Access DraftModeler DB Search legacy info. Validated XML Invalid XML Apply design rules Design rule failure Validated XML Create component, import XML Invalid XML Update/Create data ShowX3D

Fig. 8. Sequence diagram for creating component functionality.

Fig. 9. Functionality of settings page for administrator.

from rst-time user. This project selection functionality is an entry point for any user to start working in the system. A list conformable to Tribon projects is presented to the user. The selected project is treated as an active project for all further operations done by the user. The data for longitudinal and seams displayed in rest of the pages are extracted from this project, unless user selects a project from this list he is not allowed to access RuleCheck and Modify pages. An appropriate error message is displayed to the user in case such attempt is made. User has a exibility to go to the home page and select another project to make it active for further operations.

Administrator login offers additional functionalities listed below. 1. Delete the components on KESSThis includes components created by KESS as well as components created into Trion Hull system. When a component is deleted in KESS, the corresponding component in Tribon is also deleted. In a reverse situation, when a component is deleted from Tribon, it will be reected in KESS system only after the project data is updated. Any inconsistent data will be alarmed. 2. Delete the rules in DSS system.

ARTICLE IN PRESS
926 W. Tann, H.-J. Shaw / Ocean Engineering 34 (2007) 917929

3. Schedule the batch job for updating KESS DB with latest Tribon PIM. 4. Take backup of KESS DB The functionalities such as RuleCheck and Modify are common for normal users and administrator. Using these functionalities one can manage the rules and components in KESS system. Backup and deletion to rules and components are available only for the administrator. Scheduler Backup page enables to schedule the batch job for updating the latest Tribon data into KESS (Fig. 10). The web page also displays the last date of data update, so after the data is updated this eld in the database can be

updated with the current date. When the backup button is clicked on, MS SQL database will be backed up with a SQL backup command. 5.2. Draft modeler The draft modeler offers the 3D representation to design structure elements of ship (add on application and the drafting CAD application combined called as draft modeler). Upon invoking any command to design a structure element (the basic geometry information is available in draft modeler database) the draft modeler also updates the draft modeler database, referring on the

Fig. 10. Batch scheduler and backup page for admin.

Fig. 11. Typical UI to edit or modify the design elements.

ARTICLE IN PRESS
W. Tann, H.-J. Shaw / Ocean Engineering 34 (2007) 917929 927

resultant of inference engine. The UI for this section can be nalized once the components and input parameters for those components are decided. A context sensitive menu at various levels is also made available to increase the usability of the draft modeler (Fig. 11). 5.3. Functionality on RuleCheck link RuleCheck, i.e. KBE, link offers functionality to add, delete or modify the rules of class rule, rule base and standard practice databanks, respectively, on KESS. The interface is also used to surf the functions available as a part of function library reference to dene the new rules. The rules have to be projected specically depending on the type of ship. Or in other words, different ships have different rules to apply on the components. This is done in the rule properties section where a combo box can be offered to the user to select the ship type. Also, there will be

provision to add new ship types and rule types through the administrator setting. Fig. 12 presents the inferred data via web services accessed from draft modeler database and knowledge base database. More the rules, such as on rule base originating from the design knowledge of users, increase gradually, more intelligent and stable the system can be. 5.4. Functionality on modify link This is a very essential part of KESS as it includes the classes and applications of C# and Vitesse to control the actual components validated by design rules on Tribon and itself. In KESS, when a new component is created or an existing component is modied, the XML le of that component is created and validated against Tribon XML schema. If the XML composition is properly validated, dened design rules will be applied, otherwise users will be indicated of any errors occurred. If the well-form composition is passed through the design validations, the nalized XML data is executed to create the component on Tribon. Ideally, the XML data should automatically import into Tribon to create/update the component; however it is conned at present because of technical limitations of the compatibility between Python language with .NET environment. An alternative of communication between web service functions and Tribon is to use batch Vitesse technique. X3D presents the consistent components on Tribon. A modify web page is shown in Fig. 13. 6. Conclusion

Fig. 12. Data access via RuleCheck on draft model and knowledge base database.

KESS is developed as an open, scalable, extensible framework which offers a central access point to the

Fig. 13. The synchronized components on modify.

ARTICLE IN PRESS
928 W. Tann, H.-J. Shaw / Ocean Engineering 34 (2007) 917929

Shipyard Operator Owner Survey data Classification Society Requirement feedback Shipyard

Shared Workspace XML/STEP/XML Web Service

Engineering sub-contractor

Supplier

Model basin

Fig. 14. Shared workspace approach.

clients for performing various operations. Internet-based technology with the ascendancy of information integration and coordination is much easier stretching the development potential to collaborative design. Tedious and repetitive data input and data inconsistency problems from earlier design stage can be reduced by data exchange between heterogeneous systems and quickly constructing 3D product model on data-centric architecture. With one point of access to all ship data, the system can easily and quickly interoperate with multiple ship data repositories or system tools. An underlying information model of a shared workspace environment has to address different information sets from an enterprise reference model (ERM) that describes all relevant shipbuilding business information objects (Bronsart and Gau, 2001). There are industry-specic systems as well as more general tools. Often a very important restriction is that they are mostly focusing on a company with a number of branch ofces geographically distributed or a group of afliated companies. The widely spread network of design tasks in combination with numerous different companies involved makes high demands on the communication processes within the network. The fundamental structure of a shared workspace conguration is shown in Fig. 14. The commonly accessed information and communication infrastructure is centered within the collaboration network (Tann and Shaw, 2005). A key topic in co-design from designers perspective is how to bridge the multitude of models required supporting a complex design circumstances at multidisciplinary system tools. STEP has been developed using rigorous data modelling disciplines and formal methodologies and each model receives a thorough international review, the tool also expanded and adopted in some shipbuilding design software. STEPml is based on robust, internationally standardized data models from ISO 10303 (STEP). STEPml takes the data models from STEP and publishes them as XML specications, which brings together the rich semantics of STEP and the widespread adoption of XML

technology. A system open to those involved is the setup, offering new ways to communicate and to collaborate. Utilizing the existing interoperability technologies and standards to augment the integration scalability, the implementation of the shared collaboration framework is just a matter of time.

References
AVEVA Tribon M3 Users Guides, 2005. Berry, M.J.A., Linoff, G.S., 2004. Data Mining Techniques. Wiley, New York. Briggs, T.L., Baum, S.J., Thomas, T.M., 2005. Interoperability framework. Journal of Ship Production 21 (2), 99107. Bronsart, R., Cantow, U., Petkov, V., 2002. Knowledge modelling and implementation methods in distributed CAE-environments. In: 11th International Conference on Computer Applications in Shipbuilding (ICCAS) 2002, pp. 731740, Malmo , Sweden. Bronsart, R., Gau, S., 2001. Collaborative design and production in shipbuilding networks. NSN2001, St. Petersburg, Russia. Catley, D., 1999. Prototype STEP data exchanges in ship initial design and provision of an application programmer interface to Tribon. In: Proceedings, 10th International Conference on Computer Applications in Shipbuilding, June, Cambridge, MA. Erikstad, S.O., Fathi, D.E., 1999. Applying the STEP shipbuilding protocols as a basis for integrating existing in-house ship design applications. In: ICCAS99, Cambridge, USA, pp. 415424. /http://www.omg.org/uml/S, April 2005. Maritech ASE - Project 99-21, 2000. Design and cost estimating metrics. Miyamoto, S., Nonoguchi, S., Matsuno, J., Matsumura, T., 2002. application of knowledge based modelling to detail structure design for shipbuilding. In: 11th International Conference on Computer Applications in Shipbuilding (ICCAS) 2002, pp. 717729, Malmo , Sweden. Negnevitsky, M., 2002. Articial intelligence: a guide to intelligence systems. Polini, M.A., Meland, K.E., 1997. The development and implementation of a SMART product model for ship structure. In: Proceedings, Ninth International Conference on Computer Applications in Shipbuilding, October, Yokohama, Japan. Rando, T.C., 2001. XML-based interoperability in the integrated shipbuilding environment (ISE). Journal of Ship Production 17 (2), 6975. Rossu , J.M., Abal, D., 2001. Practical use of 3D product modeling in the small shipyard. Journal of Ship Production 17 (1), 2734.

ARTICLE IN PRESS
W. Tann, H.-J. Shaw / Ocean Engineering 34 (2007) 917929 Shin, Y., Han, S.H., 1998. Data enhancement for sharing of ship design models. Computer-Aided Design 30 (12), 931941. Staebler, R.M., 2002. Efcient management of distributed ship design processes. In: 11th International Conference on Computer Applications in Shipbuilding (ICCAS) 2002, pp. 731740, Malmo , Sweden. Storch, R.L., Park, J.H., Evans, E., 2002. Development of a ship detail design expert system. Journal of Ship Production 18 (1), 812. 929 Tann, W., Shaw, H.-J., Bronsart, R., 2005. Integrating the collaborative environment in shipbuilding an implementation strategy. Journal of Ship Production 1 (25), 3745. Tann, W., Shaw, H.-J., 2005. The implementation method of data sharing based on ship product modeling, received by SNAME, Taiwan, ROC. Whiteld, R.I., Duffy, A.H.B., Meehan, J., Wu, Z., 2003. Ship product modelling. Journal of Ship Production 19 (4), 230245.

Vous aimerez peut-être aussi