information model of ship product structure supporting operation and maintenance after ship delivery...

PLM11 8th International Conference on Product Lifecycle Management 319

IFIP Working Group 5.1, 2011

Information model of ship product structure supporting operation and maintenance after ship delivery

Duhwan Mun School of Mechanical and Automotive Engineering, Kyungpook National University 386 Gajang-dong, Sangju, Gyeongsangbuk-do 742-711, South Korea Fax: +82-54-530-1278, Tel: +82-54-530-1271 [email protected]

Namchul Do Gyeongsang National University, Department of industrial and systems engineering, ERI 900 Gajwa-dong, Jinju, Gyeongsangnam-do 660-701, South Korea [email protected]

Wooyoung Choi Daewoo Shipbuilding & Marine Engineering Co., Ltd. 1, Aju-dong, Geoje-si, Gyeongsangnam-do, 656-714, South Korea [email protected]

Abstract: Recent trends in the engineering information management technology of the shipbuilding industry are characterized by the spread of the product lifecycle management (PLM) concept and an increased demand on better use of ship engineering data after ship delivery. Product structure data, explicit hierarchical assembly structures representing assemblies and the constituents of those assemblies, form the backbone of all engineering data managed by PLM systems. The product structure differs depending on the industrys requirements, design and manufacturing methods, or lifecycle phases covered. In this study, information model of ship product structure is developed particularly considering the use of ship product structure data at the phase of operation and maintenance after the delivery.

Keyword : Information model; ISO 10303 STEP PDM Schema; ISO 15926 Process Plants; Operation and maintenance; Ship product structure.

1 Introduction Product lifecycle management (PLM) is the process of managing the entire lifecycle of a product from its conception, through design and manufacture, to service and disposal, and is also a business strategy of a company [1]. Product structure data, explicit hierarchical assembly structures representing assemblies and the constituents of those

320 Duhwan Mun, Namchul Do, Wooyoung Choi

assemblies, form the backbone of all engineering data managed by PLM systems. The product structure differs depending on the industrys requirements, design and manufacturing methods, or lifecycle phases covered [2].

Recent trends in the engineering information management technology of the shipbuilding industry are characterized by the spread of the PLM concept and an increased demand on better use of ship engineering data after ship delivery. In order to meet this requirement, shipbuilding computer-aided design (CAD) vendors have developed PLM systems. Large shipbuilding companies in Korea are either customizing PLM systems developed for use in the mechanical industry or developing new PLM capabilities which are based on ship CAD systems in use. It is interesting that large shipbuilding companies in Korea adopted mechanical PLM systems in spite of interoperability issues with ship CAD systems.

The shipbuilding industry in Korea has attempted to apply the PLM concept, focusing on managing the product data at the early lifecycle stages including design and manufacturing; the main purpose of introducing PLM systems is to seamlessly integrate CAD and enterprise resource planning (ERP) systems through PLM systems. However, in the cases of floating production storage and offloading (FPSO) and drill ships, 90% of the total lifecycle cost is incurred at lifecycle phases after ship delivery. Furthermore, effective operation and maintenance (O&M) and recycling of ships are gradually becoming important due to increased regulations on eco-friendly ships as well as ship safety. For these reasons, PLM systems are needed to provide capabilities so that ship data generated at design and manufacturing phases are efficiently utilized at lifecycle phases after ship delivery. Since core information managed by PLM systems is product structure, information model of ship product structure that is able to support ship O&M works is required.

In this study, information model of ship product structure is developed particularly considering the use of ship product structure data at the O&M phase after the delivery. To this end, information requirements of ship product structure are analyzed and then information model of ship product structure is defined according to the requirement. Usability of the proposed information model is demonstrated by representing various types of product structure data with this model.

2 Related literature and studies

2.1 Information modeling of product structure Bill of material (BOM) is a term similar to product structure. BOM is a hierarchical assembly structure of parts constituting a product. When multiple instances of a part are used in an assembly, only one relation between the part and the assembly is defined. The number of instances is associated with the relation as an attribute. The product structure is also a hierarchical assembly structure of parts constituting a product. However, when multiple instances of a part are used in an assembly, multiple relations, equal in number to the instances between the part and the assembly, are defined.

Van Veen and Wortmann proposed a generic BOM management system based on the variant concept [3]. Olsen studies an information model which represents product family with programming languages [4]. Do et al. suggested a method to represent engineering change information by using product structure data [5]. Trappey and Lin developed an

Information model of ship product structure supporting operation and maintenance after ship delivery 321

object-oriented BOM system for the management of product family [6]. Kim et al. studied the management of BOMs in ship outfitting design [7]. In this study, types of information that should be contained in BOM data and capabilities that shipbuilding PLM systems should provide are elaborated with several cases. Kim et al. suggested the system architecture as well as BOM data processing functionalities and the procedure of a collaborative BOM management system for small and medium enterprises [8].

Most of previous studies are on configuration management in which several products constituting a product family are constructed and managed with product structure. They mostly focused on the mechanical industry and did not consider the O&M phase. Kim et al. [7] studied the management technique of BOM data in the shipbuilding industry. However, they dealt with product structure not in information model level but in data (or instance) level focusing on the use of product structure in the design and manufacturing phases.

2.2 Related industrial data standards Typical industrial data standards for the representation of product structure are STEP product data management (PDM) schema [9], ISO 10303 STEP AP239 product life cycle support (PLCS) [10], and ISO 15926 Process Plants [11]. The shipbuilding industry occupies an intermediate position between the mechanical and plant industries. ISO 15926 Process Plants is an appropriate international standard for the plant industry, whereas ISO 10303 STEP is suitable for the mechanical industry. In this study, the authors referred to the STEP PDM schema and ISO 15926 Part 2 data model in order to develop information model of ship product structure.

The STEP PDM schema is a common PDM data schema developed by PDES, Inc. and ProSTEP, Inc. It is a real subset of PDM-relevant STEP APs (AP203, 212, 214, 232, 233, 239), fulfilling nearly all requirements for PDM data exchange. It provides main functionalities for parts and documents: part identification, product structure, document identification and linking the identified documents to the product structure, versioning, and product configuration.

ISO 10303 STEP AP239 PLCS, an extension of the STEP PDM schema, is an international standard designed to ensure that the support information is aligned with the evolving product definition over the entire lifecycle. It provides information resources for support engineering, resource management, configuration management, and maintenance and feedback.

ISO 15926 Process Plants is an international standard for data sharing and integration of process plant lifecycle data. From the view points of product structure, ISO 15926 Part 2 data model does not provide enough information resources for engineering change management and configuration management, but it has information resources useful in the O&M phase including clear definitions of classes and individuals, discrimination of functional and physical objects, and integration of space and time dimensions.


3 Information requirements of ship product structure

3.1 Lifecycle phases before ship delivery Contrary to mechanical CAD systems, shipbuilding CAD systems partially have PDM capabilities: access control, workflow management, and part catalogue management. Due to this reason, advantages of applying PLM systems in the shipbuilding industry come not from conventional PDM capabilities but from capabilities for seamlessly integrating whole lifecycles. Therefore, not only conventional application fields of product structure at the design and manufacturing phases, but also tight integration of product requirements created before the design phase and product structure [12], and use of product structure for the O&M works are required.

Views on the same product are different from each other depending on lifecycle phases or application purposes, which lead to different product structures for the same product. To describe the difference between product structure and product view, product structure contains explicit hierarchical assembly relations among constituents of a product whereas product view is product structure constructed relevant to the requirements of a particular lifecycle stage and application domain.

In the shipbuilding industry, different product views are required as ship design proceeds, as shown in Fig. 1. Ship product structure evolves from a rough one to a detailed one: from the main machinery list (MML) in the early design phase, through the system-oriented product view in the preliminary design phase and the block-oriented product view in the detail design phase, to the zone-oriented product view in the manufacturing design phase [7]. Therefore, information model of ship product structure should support product views.

Fig. 1. Evolution of ship product structure before ship delivery

An engineering change can be defined as all the changes made to the product structure, product configuration, or part properties with the aim of improving functionality, quality, or productivity of a product. From the viewpoint of the product


structure, an engineering change implies a change in the hierarchical relations in the product structure, which is caused by addition/deletion/modification of parts. In the design phase, engineering changes are frequently made due to technical problems. After a design is finalized and released to manufacturing departments, requests for engineering change are also made due to manufacturing or in-service issues. In order to manage the change history of parts constituting a product structure according to engineering changes, version and revision numbers are assigned to part and document objects, respectively. Shipbuilding industry needs tracking of engineering change history or reuse of design data, hence, information model of ship product structure should support version management.

Configuration management is a PLM capability where a part family is constructed in such a manner that interchangeable parts with standard interfaces and their combinations are defined in order to satisfy the requirements of various users. A part family constructed with product structure is called product configuration. A product structure is usually the representation of the physical composition of parts constituting a single real product. However, when the concept of configuration management is introduced, a product structure represents all the possible compositions of parts for individual products of a part family. Interchangeable parts are called options, while individual products of a part family are called variants.

In the shipbuilding industry, configuration management may be necessary for managing the product structures of series ships. However, conventional configuration management capability of mechanical PLM systems was developed under two assumptions [13]; all parts and product structures constituting a part family are clearly identified in advance and interfaces of mutually interchangeable options in product configuration are identical. However, when designing a series ship, it is practically unfeasible to consider the product structures of other series ships to be developed in the future and to make interfaces of options identical for series ships, since series ships have different points of design time and shipbuilding companies typically adopts engineered-to-order (ETO) manufacturing strategy.

A ship assembly consisting of millions of parts requires huge data storage to PLM systems. And to make things worse, even though more than 90% parts of series ships are the same, all the product structure data for every series ship are stored in a database. This is because presently, ship product structure data are modeled on the basis of the copy and modify approach where all product structure data are copied first and then some of the product structure are modified to meet new requirements of a new series ship. This leads to a problem of redundant use of data storage. Information model of ship product structure should provide information resources to solve this problem.

3.2 Lifecycle phases after ship delivery Before analyzing information requirements of ship product structure in the lifecycle phases after ship delivery, it is worth comparing abstraction level of product structure data used in the design/manufacturing phases with that of product structure data in the O&M phases. Objects represented in product structure in the design phase are classes, abstract objects which do not exist in the real world. They specify shape, physical characteristics, and functional characteristics that members (or individuals) of a class must have, such as centrifugal pump type A in Fig. 2. On the other hand, individuals which exist at specific time-space in the real world should be managed in product


structure in the O&M phase in addition to classes. For example, it is required to monitor and trace installation time, repairing history, and current status of a real pump with tag number 0000001 of Fig. 2.

Fig. 2. Distinction between class and individual

In the O&M phase, after O&M master plan is first established from design and manufacturing data of a product, O&M works are performed according to this master plan, of which history is also managed. The O&M master plan links to class-level product structure while the O&M history connects to individual-level product structure, as shown in Fig. 3. Therefore, information model of ship product structure should support both class- and individual- level product structures and couple them together.

Fig. 3. Use of ship product structure after ship delivery


4 Information model of ship product structure Information model of ship product structure is defined by referring to the information requirements mentioned in the previous section, and various types of product structure data are represented with this model in this section. Information model of ship product data is proposed in Section 4.1 and the authors represent various cases of ship product structure data shown in Fig 1 and Fig. 3 in Section 4.2 using this model.

4.1 Definition of information model of ship product structure The proposed information model of ship product structure is shown in Fig. 4. This figure is diagramed in EXPRESS-G [14]. Entities of this information model are mainly divided into abstract_object and individual. The authors referred to ISO 15926 Part 2 data model for the discrimination of classes and individuals. The abstract_object entity is used to specify class-level objects and relationships and the individual entity is used for representing individual-level objects. There are two types of relationships; the class_of_relationship entity specifying the relation between classes and the relationship entity representing the relation between individuals.

Fig. 4. Information model of ship product structure supporting operation and maintenance

The product entity is an assembly or a part of class-level product structure. Whether the instance of this entity is an assembly or a part is specified by the product_type_relation entity. The assembly hierarchy between parts is represented by the class_of_assembly_relation entity. When detail hierarchical relationships between parts constituting a high level assembly are not fixed but promissory usage relationships between parts and the assembly that is not the immediate parent in the hierarchy are known, the preliminary_assembly_relation entity is used to represent this assembly hierarchy.


In order to specify product version and view, the product_view and product_version entities are defined by referring to STEP PDM schema. The product, product_view, and product_version entities are linked by the view_relation and version_relation entities respectively.

Members of a certain class are declared with the classification entity. The assembly hierarchy between individual parts is represented by the assembly_relation entity. Since individuals exist uniquely in the time-space and do not change, they do not have different views and versions. Therefore it is not necessary to provide information resources for representing views or versions in individual-level product structure. However, role, usage, or classification of an individual at a particular period of time can be changed. It is called temporal part (or substate) of the individual. The temporal_whole_part entity represents this relationship between an individual and its temporal part.

4.2 Use of information model of ship product structure To show case studies of the proposed information model, a new diagram, where instance data adhering to the information model are added to the EXPRESS-G diagram for the information model, is used. In this diagram, instance data of an entity is written in underlined italic font. For example, PipeLine#1 and Fitting#1 in Fig. 5 are instances of the product entity.

The hierarchical (assembly) relationship between PipeLine#1 and Fitting#1 shown in Fig. 1 is represented as Fig. 5. PipeLine#01 and Fitting#01 are declared as assembly and part respectively and their hierarchical relationship is represented by the class_of_assembly_relation entity.

Fig. 5. Representation of hierarchical relationship between parts constituting a product

Different product views of Fitting#01 shown in Fig. 1 are represented as Fig. 6. After Fitting#01 is specified with the product entity, detail design and manufacturing design views are represented by product_view entity.

At the sales design phase, if a component is lined in MML, it means that this component is chosen but its exact position in product structure is not fixed. This kind of


hierarchical relationship is represented by the preliminary_assembly_relation entity, as shown in Fig. 7. In this figure, Type B engine is chosen for the design of LNGTypeA#1 ship.

Fig. 6. Representation of different product views

Fig. 7. Representation of a part of which exact position is not fixed in product structure

When some of product structure of a ship designed at point of time T is to be reused for the design of another ship designed at point of time T+, the instances of product_view for parts or assemblies, which will be reused, are referred to for the definition of both of product structures of two ships. For example, if PipePiece#01, which is a component of Block#01 assembly of LNGTypeA#1 ship, is to be reused for the design of Block#01 assembly of LNGTypeA#2 ship, additional assembly relationship between the detail design view of PipePiece#01 and the detail design view of Block#01 is specified, as shown in Fig. 8.

The classification entity is used for the connection of class- and individual-level product structures used in the O&M phase. For example, Fitting#01_AF1_0011 individual part installed in QueenMerry, LNGTypeA#01 type ship, is declared as member of Fitting#01 type using the classification entity, as shown in Fig. 9. If Fitting#01_AF1_0011 individual part is damaged and is replaced with Fitting#01_AF1_0012 individual part, Fitting#01_AF1_0012 becomes a member of Fitting#01 type.


Fig. 8. Multiple references of a part use of product structures of series ships

Fig. 9. Connection of class-level and individual-level product structures

Individuals exist uniquely in the time-space and do not change. However, role, usage, or classification of an individual at a particular period of time can be changed. For example, when #1234 impeller is installed in #5678 pump from the point in time a to b, as shown in Fig. 10, the assembly relationship between the two individuals only exists for that time period. After that time period, #1234 impeller would be replaced with another part, repaired, or recycled. #1234 impeller for that time period has the additional characteristic (the assembly relationship), hence, #1234 impeller for that time period should be distinguished from #1234 impeller for the entire life time. To this end, #1234 impeller that exists from point in time a to b is identified as #9012 impeller and #9012


impeller is declared as temporal part of #1234 impeller using the temporal_whole_part entity, as shown in Fig. 10. The assembly relationship therefore exists between #9012 impeller and #5678 pump.

Fig. 10. Representation of usage history of an individual part

5 Conclusion To use PLM technology as a solution to urgent problems of sustainable manufacturing, response to environmental regulations, and total lifecycle cost reduction, PLM systems need to support both individual- and class-level product structures as well as coupling of them. For example, eco-friendliness of steel used for the manufacture of a product can be determined only after we know what kinds of manufacturing processes are applied for the production of this material, how this material is transported, or whether this material is recycled, as shown in Fig. 11. These activities involve the management of individual-level data in addition to class-level data, hence, information model of product structure should support two different levels of product structures.

Fig. 11. History tracking of steel


Acknowledgment This research was supported by Kyungpook National University Research Fund, 2010.

References 1 CIMdata, Product Lifecycle Management CIMdata Report, 2002. 2 Do N.C., Introduction to PLM and Its Application (in Korean), Life & Power Press, 2007. 3 Van Veen E.A., Wortmann J.C., New Development in Generative BOM-processing

Systems, Production Planning & Control, Vol. 3, No. 3, pp. 327-335, 1992. 4 Olsen K.A., A Procedure-oriented Generic Bill of Materials, Computers and Industrial

Engineering, Vol. 32, No. 1, pp. 29-45, 1997. 5 Do N.C., Choi I.J., Jang M.K., "A Structure-Oriented Product Data Representation of

Engineering Changes for Supporting Integrity Constraints", International Journal of Advanced Manufacturing Technology, Vol. 20, No. 8, pp.564-570, 2002.

6 Trappey A.J., Lin H.D., An Object-Oriented Bill of Materials System for Dynamic product Management, Journal of Intelligent Manufacturing, No. 7, pp. 365-371, 1996.

7 Kim S.H., Lee J.H., Suh H.W., Jeon J.I., Kim K.S., Implementation of Unique ID Considering the Evolutional BOMs in Ship Outfitting Design, Transactions of the Society of CAD/CAM Engineers, Vol. 15, No. 6, pp. 449-459, 2010.

8 Kim B.H., Jung S.Y., Baek J.Y., Lee S.J., Lee S.W., Choi H.Z., Design of Collaborative BOM Management System for Small and Medium Enterprises, Transactions of the Society of CAD/CAM Engineers, Vol. 14, No. 4, pp. 254-260, 2009.

9 STEP PDM schema, The STEP PDM Schema Home Page, http://www.pdmif.org/pdm_schema/, 2000.

10 ISO, Industrial Automation Systems and Integration-Product Data Representation and Exchange-Application Protocol: Product Life Cycle Support, ISO:2005 10303-239, 2005.

11 ISO, Industrial Automation Systems and Integration Integration of Lifecycle Data for Process Plants Including Oil and Gas Production Facilities Part 2: Data Model, ISO 15926-2, 2003.

12 Svensson D., Malmqvist J., Integration of Requirement Management and Product Data Management, In: Proceeding of ASME 2001 Design Engineering and Technical Conference, 2001.

13 Sabin D., Weigel R., Product Configuration Frameworks - A Survey, IEEE intelligent Systems, Vol. 13, No.4, pp. 42-49, 1998.

14 ISO 10303-11, Industrial automation systems and integration Product data representation and exchange Part 11: Description methods: The EXPRESS language reference manual.

information model of ship product structure supporting operation and maintenance after ship delivery...

Documents

product data

systems engineering

ship cad systems

mechanical plm systems

customizing plm systems

shipbuilding industry

automotive engineering

lifecycle phases