A Data Management Approach Based on Product Morphology in Product Lifecycle Management

: In the product life cycle from conception to retirement, there are three forms: conceptual products, digital products and physical products. The carriers of conceptual products are requirements, functions and abstract structures, and data management focuses on the mapping of requirements, functions, and structures. The carrier of digital products is digital ﬁles such as drawings and models, and the focus of data management is the design evolution of product. Physical products are physical entities, and their attributes and states will change over time. Existing data model research often focuses on one or two forms, and it is even impossible to integrate three forms of data into one system. So, a new data management method based on product form is presented. According to the characteristics of the three product form data, a conceptual product data model, a digital product data model, and a physical product data model are established to manage the three forms of data, respectively, and use global object mapping to integrate them into a uniﬁed data model. The conceptual product data model has a single data model for a single business stage. The digital product data model uses the core data model as the single data source, and uses one stage rule ﬁlter to add constraints to the core data model for each business stage. The physical product data model uses the core data model to manage the public data of the physical phase, and the phase private data model focuses on the private data of each business phase. Finally, a case of Multi-Purpose Container Vessel is studied to verify the feasibility of the method. This paper proposes three product forms of product data management and a uniﬁed data management model covering the three product forms, which provides a new method for product life cycle data. a Digital Object and a Phase, which means that it is the Form and Digital BOM of this object at this stage. Digital BOM has multiple Digital Objects and multiple Digital BOMs, which, respectively, indicate which objects it contains and the relationship with the underlying structure.


Introduction
With the coming of global economic integration, a deep affinity exists for the manufacturing industry. Customers focus not only on high quality and low cost, but also on innovation, service, environmental protection and the personalization of products. Thus, manufacturers must pay attention to intellectual capital, from a product's initial conception to its retirement.
Product Lifecycle Management (PLM) is defined as "A strategic business approach that applies a consistent set of business solutions that support the collaborative creation, management, dissemination and use of product definition information" [1]. In this decade, PLM systems are recognized for managing the information of the full product lifecycle [2].
A critical aspect of PLM systems is their product information modelling architectures [2,3]. A reasonable and effective product data model can seamlessly integrate and make available all of the product data throughout all of the phases in a full lifecycle, to the right people, who are the manufacturer, suppliers, facilitators, customers and circulation economy enterprises, at the right time.
In the product life cycle, products have three morphologies: conceptual products, digital products, and physical products. The carrier of a conceptual product is an abstract product structure oriented to product requirements and functions. Conceptual product data management focuses on the realization relationship between requirements and functions, and functions and structures. The carrier of digital products is data based on the product design structure, including the attributes of the product and its parts, two-dimensional drawings, three-dimensional models, instructions, analysis reports and other data. The focus of digital product data management is product evolution management. Physical products are physical objects that really exist, and can be used and maintained. Physical product data management focuses on changes in product status and attributes over time. The data management characteristics of these product morphologies determine that there are huge differences in data management modes, and there is a gap.
In this paper, a new product data management method based on product morphology is proposed. The method uses three data models and integrates the three data models into a data management framework to manage product lifecycle data. The first one is a single data model for the conceptual data. The second one uses a core data model and several phase rule filters for the digital data. Additionally, the last one includes a core data model and several phase private data models for the physical data. This approach removes the gaps among the conceptual product, digital product and physical product, which are divided according to product morphology. Thus, all the product data seamlessly integrates into one system.
The structure of this paper is as follows. Section 2 studies the state-of-the-art of a data model in PLM. Section 3 discusses the methodology. Section 4 presents three product morphology types: the conceptual product, the digital product and the physical product. Section 5 achieves a Unified Data Model based on Product Morphology (UDMPM) using Unified Modelling Language (UML). Section 6 studies a case of shipbuilding to validate the data management approach.

State-of-the-Art: A Data Model of PLM
In this section, several types of product data modelling methods are reviewed. The researchers studying the product data model focus on different aspects to deal with the problems facing them. Then, different methods of product data description and expression, integration of multi-phase data, single data source and so on are presented. The emphases of them are as follows: The description and expression of product data describe products in terms of content, attributes, and relationships, which are the basis of data management. There are many related studies, mainly focusing on the following four aspects. (1) Meta-data and metamodel are used for product data modeling and integration. Xia uses meta-models to describe data in the stages of product design, process manufacturing, sales operations, and maintenance [4]. Kreis uses meta-data to describe CAD data and integrates with PDM systems [5]. Tao uses meta-models to describe the basic structure and content of the data set, enables the retrieval and integration of heterogeneous data from different data sources [6]. Dinesh uses meta-models to support the integration of CAD, CAPP, NC tool path verification and MRP systems [7]. (2) Ontology is an explicit and formalised description of common concepts [8,9]. Ontology-based data models are used for product design, production, use, and service data management and integration [10][11][12], as well as product knowledge [13]. (3) As the most popular data exchange format and data model language, eXtensible Markup Language (XML), Standard for the Exchange of Product Model Data (STEP) and UML were widely adopted in data modelling. XML presented shared data to different information systems [14,15]. STEP was used as a bridge to integrate heterogeneous data [16][17][18]. UML model administrates product data [4,19]. (4) Product Profiles are multiple benefit models that benefit expected suppliers, customers, and users, and are used for the description and expression of early conceptual product data. Roughly Processes 2021, 9, 1235 3 of 22 outline the outline of the product, for example, with basic product attributes, customers can experience the functions of future products without completely predicting its shape [20].
The integration of multi-stage data is another research focus. Product plan-BOM (Bill Of Material), design-BOM, craft-BOM, stock-BOM, manufacture-BOM, finance-BOM, customer-BOM, and after service-BOM, is integrated to supply a single data source by developing a data flow [21,22]. Li uses data domains integrating a concept design domain, a structural design domain, a detailed design domain, a process planning domain, a manufacturing domain and a sales and service domain by mapping [3]. Xia puts forward a unified meta-model that supports the data meta models in the stages of product design, process manufacturing, sales and operation, and maintenance services [4]. Cai analyses the main mapping forms of BOM multi-views and designs the mapping rules of BOM multiview model [23]. A dynamic BOM describing the configuration of a spacecraft assembly indifferent phase of product development is established [24]. Modular instance structure data models of the generalized product are established, and the structure mapping views in different phases of the product life cycle are also presented [25].
A single data source is the next focus. Single data sources guarantee consistency, integrality and security of data to the largest extent. A single data source is obtained by integrating multi-BOM [26]. Sudarsan described a product information-modelling framework, based on the NIST Core Product Model (CPM) and its extensions: The Open Assembly Model (OAM), the Design-Analysis Integration model (DAIM) and the Product Family Evolution Model (PFEM), which can support the full range of PLM information needs [2]. A configurable BOM model abstracts key entities such as product, product attribute, material, material attribute, material brand, is a single data source of product parameter calculation [27].
All the researches above have contributed to information modelling of PLM. However, there are some problems that remain to be solved: Product data description and expression model one or several stages of product structure, attributes, characteristics and documents. However, it is not a deeper factor, that is, product form. It is the most critical factor for product existence and data evolution. Different product forms have different carriers and data evolution patterns, while the carriers and data evolution patterns at different stages in the same product form are the same. Therefore, a data model that does not take into account the similarities and differences of product form and product stage cannot well manage all product data and its evolution, and support data tracking throughout the life cycle.
Integration of multi-phase data uses complex mapping relations and brings redundant data among multi-BOM, multi-phase data models or multi-domains. The consistency and integrality of product data are usually out of control throughout the course of full lifecycle. Additionally, upward spread of versions is enlarged. Most studies only achieve the integration of conceptual products and digital products or digital products and physical products. BOM or domains of different stages are regarded as the same concepts as each other. The evolution process of "conceptual product", "digital product" and "physical product" has not been described.
Single data sources achieve a single meta-model, a single data model of the design phase or multi-phase data models and multi-BOM, which are not one whole data model. It either cannot express all of the information on a product from concept to retirement, or it is too difficult to implement.
To manage data from the full lifecycle, the paper studies product morphology, and a unified data model is presented. The morphology of a product has three types: a conceptual product, a digital product and a physical product. Every product morphology type has a meaning, a function, and data. According to the characteristics of the product morphology type, the unified data model reveals the three product morphology types and their relations.

Methodology
The product life cycle covers the entire process of a product from concept to death, including many business stages. Collecting and analyzing the data of each stage, it is found that the carrier of the product has three forms. Summarizeing the three product forms revealed the differences between them, and we have summarized the characteristics of data evolution.
Facing each product form, studying the characteristics of each phase of the product, it is found that the logical relationship of the data within the product form is similar, and there is an evolutionary relationship between the data in each phase.
Based on the different characteristics of the data evolution of each product form, the data model of each product form is established as a single data source, reducing the mapping relationship between BOMs, reducing data redundancy and the complexity of data management, and it is easy to maintain data consistency. Then, the mapping relationship of global objects is established to achieve the morphological evolution path of "conceptual product" to "digital product" to a "physical product".
UML supports object-oriented technology, can express various objects and their attributes concisely and clearly, can describe rich relationships in data modeling, and is used to establish a unified data model.

Study of Product Morphology
A product is a thing that is produced to meet the demands of a customer. There are three product morphology types in a lifecycle: a conceptual product, a digital product and a physical product, which separately are the forms of a concept, digital data and an entity with matter.
A conceptual product is an abstract concept that describes the inherent characteristics of a type of product. It is the result of product conceptual design, and its carrier is the product requirement, function and abstract structure. Conceptual products are the source of product evolution, from which products of different models and specifications can be developed.
A digital product is developed based on conceptual products, which define the detailed functions, structural composition, structural features of parts and components, production processes and materials of the product. Its carrier is product structure information, two-dimensional drawings, three-dimensional models, calculation instructions, simulation analysis data, etc. The product structure is a framework for organizing and managing other data, which exhibits EBOM, PBOM and MBOM. Product data are gradually improved and accurate along with the development process. Versions are used to manage data evolution.
A physical product, also called an instance product, is a physical entity that can be manipulated. It has use value and can truly meet the needs of customers. It exists in a specific time domain and space domain, and its use and management are restricted by time and space. It has a single structure, but its properties and status change over time.
The PLM system manages the data extracted from the physical product, including product attributes, status and structure. The above data has time series properties and is unique at a certain moment.
In summary, the conceptual product, digital product and physical product are different morphology types of the same product, and separately involve conceptual, digital and physical things. There are many studies that concern data model of a digital product and a physical product, but, importantly, do not include a conceptual product.

Unified Data Model Based Product Morphology
There are large differences in the data of the three product morphology types. The data of a conceptual product is abstract and general, and includes concepts, functions and main structures of multi-series products. The data of a digital product is accurate and changeable, and includes structural data, attributes, requirements, and processes. The structural data of a physical product is usually changeless, and some attributes and states change continually.
According to the differences above, the Unified Data Model based Product Morphology (UDMPM) is made of three layers: Object Layer, Data Model Layer and Document Management Layer, as shown in Figure 1. The Object Layer includes an object pool, which creates and destroys Conceptual Object, Digital Object and Physical Object and manages the evolution among the three types of objects by mapping. The Data Model Layer holds three data models: the Conceptual Product Data Model (CPDM), the Digital Product Data Model (DPDM) and the Physical Product Data Model (PPDM). The three data models separately manage the data of three product forms and support corresponding business applications, acting as single data sources of every product morphology type. Document Management manages all of the unstructured data in the full lifecycle. UDMPM is based on UML. UML is an effective PLM modelling language and supports a Model-Driven Architecture (MDA). Thus, UML can achieve a platform-independent model. changeable, and includes structural data, attributes, requirements, and processes. The structural data of a physical product is usually changeless, and some attributes and states change continually.
According to the differences above, the Unified Data Model based Product Morphology (UDMPM) is made of three layers: Object Layer, Data Model Layer and Document Management Layer, as shown in Figure 1. The Object Layer includes an object pool, which creates and destroys Conceptual Object, Digital Object and Physical Object and manages the evolution among the three types of objects by mapping. The Data Model Layer holds three data models: the Conceptual Product Data Model (CPDM), the Digital Product Data Model (DPDM) and the Physical Product Data Model (PPDM). The three data models separately manage the data of three product forms and support corresponding business applications, acting as single data sources of every product morphology type. Document Management manages all of the unstructured data in the full lifecycle. UDMPM is based on UML. UML is an effective PLM modelling language and supports a Model-Driven Architecture (MDA). Thus, UML can achieve a platform-independent model.

Object Layer
The object layer uses an object pool to create and destroy all of the business objects and manages mapping relations among the conceptual object, digital object and physica object. The conceptual object, digital object and physical object are separately the abstrac of business objects of a conceptual product, digital product and physical product, including the products, components, parts, functions, requirements, resources and so on. A conceptual object is the source of several digital objects. Many physical objects are derived from the same digital object. Thus, there are mapping relations that describe the evolution of the three objects.
A UML static class structure of all product objects is presented and divided into four groups: Global Objects, Conceptual Product Objects, Digital Product Objects and Physica Product Objects, as shown in Figure 2.
Global Objects are the base of all objects. Item is the base class of all the business classes, and BOM is the base class of all the types of BOM objects. They are abstract classes and cannot be instantiated. The subclass of Document Business Object and Document Dataset are used in document management. The main attributes of Item, such as ID, name revision, vision, security classification, type, owner and time, are managed alone, and other phase-attributes are managed by Form. Phase is the abstract of the business phase Some subclasses of Item can exist in several Phases, for example that the same products

Object Layer
The object layer uses an object pool to create and destroy all of the business objects and manages mapping relations among the conceptual object, digital object and physical object. The conceptual object, digital object and physical object are separately the abstract of business objects of a conceptual product, digital product and physical product, including the products, components, parts, functions, requirements, resources and so on. A conceptual object is the source of several digital objects. Many physical objects are derived from the same digital object. Thus, there are mapping relations that describe the evolution of the three objects.
A UML static class structure of all product objects is presented and divided into four groups: Global Objects, Conceptual Product Objects, Digital Product Objects and Physical Product Objects, as shown in Figure 2. As shown in Figure 2, symbol 1 and symbol * represent the one and multi-object, respectively. The main subclasses of Item are Conceptual Object, Digital Object and Physical Object, which are basic abstract classes of three product morphology types and cannot be instantiated.
Conceptual Object and Conceptual BOM are major Conceptual Product Objects. Conceptual object is a super-class of all of the conceptual product business objects and has the attributes: state (Working, Modifying, Examining, Released and Invalid) and project. Its major subclasses are Conceptual Product, Conceptual Component, Conceptual Part and Functions, which are the abstracts of corresponding business objects and have attributes, as shown in Table 1. Conceptual BOM is an accessorial class creating the relations of two objects in the conceptual product structure tree. The data model of Conceptual Product is composed of the four subclasses, Conceptual BOM and other Conceptual Product objects, which are derived from Conceptual Object to fit specific needs.  Table 2. Digital BOM also is an accessorial class, and its subclasses are EBOM, PBOM, and MBOM. All of the subclasses above estab- Global Objects are the base of all objects. Item is the base class of all the business classes, and BOM is the base class of all the types of BOM objects. They are abstract classes and cannot be instantiated. The subclass of Document Business Object and Document Dataset are used in document management. The main attributes of Item, such as ID, name, revision, vision, security classification, type, owner and time, are managed alone, and other phase-attributes are managed by Form. Phase is the abstract of the business phase. Some subclasses of Item can exist in several Phases, for example that the same products, components and parts are in requirements management, structure design, process design and so on. However, Form and BOM only belong to a Phase. Then, Item can integrate the attributes and structural information of a multi-phase and can hold the access of every phase.
The main subclasses of Item are Conceptual Object, Digital Object and Physical Object, which are basic abstract classes of three product morphology types and cannot be instantiated.
Conceptual Object and Conceptual BOM are major Conceptual Product Objects. Conceptual object is a super-class of all of the conceptual product business objects and has the attributes: state (Working, Modifying, Examining, Released and Invalid) and project. Its major subclasses are Conceptual Product, Conceptual Component, Conceptual Part and Functions, which are the abstracts of corresponding business objects and have attributes, as shown in Table 1. Conceptual BOM is an accessorial class creating the relations of two objects in the conceptual product structure tree. The data model of Conceptual Product is composed of the four subclasses, Conceptual BOM and other Conceptual Product objects, which are derived from Conceptual Object to fit specific needs.  Table 2. Digital BOM also is an accessorial class, and its subclasses are EBOM, PBOM, and MBOM. All of the subclasses above establish digital product structure.  Table 3. Physical BOM is an accessorial class also, and its subclasses are Maintenance BOM, Position BOM and Disassembly BOM. All of the subclasses above construct a physical product structure.

Data Model Layer
According to the data characteristics of every product morphology type, Data Model Layer uses corresponding objects when building data models, including CPDM, DPDM and PPDM. The three data models are single data sources of every product morphology type. Mapping relations combine three data models into a whole model and remove the gaps among them. CPDM, DPDM and PPDM are separately composed of a core data model and phase data models. A core data model is the real single data source of product morphology types and assures the uniqueness and consistency of the data. A phase data model is a logic data model that exhibits the data of a core data model for business applications in a specific phase.

Conceptual Product Data Model
CPDM achieves Function-Structure management, and a Conceptual Core Data Model (CCDM) is the same as a Conceptual Phase Data Model (CPhDM), because there is only one phase. CPhDM is shown in Figure 3.

Digital Product Data Model
Digital product evolves through several business phases, including requ management, structure design, process design and so on. DPDM, including a Dig Data Model (DCDM), multiple rule filters and phase data model, is presented, a in Figure 4. DCDM is the only data source of a digital product, and flexibly ma of the design data. There is a rule filter that adds constraints to DCDM in every phase to prevent illogical and unauthorised operations, and then, the phase dat appear. Rule filters are in phase business managers; for example, Structure R (SRF) is in Product Structure Editor, which is a tool that manages design structur digital product, there is Requirement Rule

Digital Product Data Model
Digital product evolves through several business phases, including requirements management, structure design, process design and so on. DPDM, including a Digital Core Data Model (DCDM), multiple rule filters and phase data model, is presented, as shown in Figure 4. DCDM is the only data source of a digital product, and flexibly manages all of the design data. There is a rule filter that adds constraints to DCDM in every business phase to prevent illogical and unauthorised operations, and then, the phase data models appear. Rule filters are in phase business managers; for example, Structure Rule Filter (SRF) is in Product Structure Editor, which is a tool that manages design structures. In appear. Rule filters are in phase business managers; for example (SRF) is in Product Structure Editor, which is a tool that manages d digital product, there is Requirement Rule Filter (RRF), SRF, Proces Requirement Phase Data Model (RPDM), Structure Phase Data M cess Phase Data Model (PrPDM). DCDM is very flexible for heterogeneous data and is shown object contains 0 or more Digital BOMs and 0 or more forms. Dig underlying structure of digital objects, and forms manage the attri at different stages. Digital objects are contained in multiple stage stages are valid. The stage contains multiple digital objects, multi DCDM is very flexible for heterogeneous data and is shown in Figure 5. The digital object contains 0 or more Digital BOMs and 0 or more forms. Digital BOM manages the underlying structure of digital objects, and forms manage the attributes of digital objects at different stages. Digital objects are contained in multiple stages, indicating in which stages are valid.  Rule filter uses a set of rules to restrict objects, relations and access. The attributes of the rules are shown in Table 4. ID is the identification number. The name is used to indicate the meaning of a rule. Phase decides the business phase. Priority means the order of Rule filter uses a set of rules to restrict objects, relations and access. The attributes of the rules are shown in Table 4. In Table 4, symbol 0 represents there is no object. ID is the identification number. The name is used to indicate the meaning of a rule. Phase decides the business phase. Priority means the order of importance. Relation is the relationships between Source Object and Destination Object. Multiplicity represents the quantitative relationship between Source Object and Destination Object in the rule. Access means who has the right to use this rule. Requirements management perfectly and accurately depicts the product capability that satisfies the demands of customers. The requirements come from a customer's advice and complaints, orders, and development processes. They are managed and tracked by an RPDM.
In the requirements management phase, there are many rules, as shown in Table 5. The Source Objects and Destination Objects have access to this phase, while other objects do not. All of the relations permitted and their multiplicities are shown in Table 5. A Product has a Requirements BOM for managing all of the requirements. The relations between Requirement and Requirement BOM build the requirements tree. Requirements are met by Design Objects, and the relations between them are used for requirements tracking management. Requirement has several subclasses, including Customer Requirement, Usage Requirement, Sale Requirement, Management Requirement, and Technology Requirement.
The rules of the structure design stage are shown in

Physical Product Data Model
In contrast to a conceptual product and digital product, a physical product has individualities. The data of physical products, which are from one digital product, are not the same as each other. The structures and most of the attributes of physical products, components and parts are changeless, but the state and other attributes change frequently. Physical components and parts are replaced often. The objects of inspection, MRO and recycling are the physical object, such as the physical product, physical components and physical parts.  As shown in Figure 7, PCDM comprises Neutral Structure Physical Structure. A digital product will produce thousands of p maintenance phase, the attributes and status of physical produc change over time. Each physical product requires a physical stru utes and status data separately. However, the design and proces  Table 7. The set of rules in the process phase (1, * represent the one and multi-object).  Figure 7, PCDM comprises Neutral Structure, Position Structure and Physical Structure. A digital product will produce thousands of physical products. In the maintenance phase, the attributes and status of physical products are different and will change over time. Each physical product requires a physical structure to manage attributes and status data separately. However, the design and process data of these physical products are the same, and the maintenance planning and solutions, failure modes and other data of the MRO stage are also the same. If the same data are managed with a physical structure, it will bring thousands of instances of data redundancy and easily lead to data inconsistency. Therefore, a neutral structure is used to manage the common data of physical products of the same design. Position Item inherits structural information, and Physical Object obtains other attributes from Design Object. Time Stamp stores the time relative to when Physical Object is installed on Position Item. As shown in Figure 7, PCDM comprises Neutral Structure, Position Structure and Physical Structure. A digital product will produce thousands of physical products. In th maintenance phase, the attributes and status of physical products are different and wil change over time. Each physical product requires a physical structure to manage attrib utes and status data separately. However, the design and process data of these physica products are the same, and the maintenance planning and solutions, failure modes and other data of the MRO stage are also the same. If the same data are managed with a phys ical structure, it will bring thousands of instances of data redundancy and easily lead t data inconsistency. Therefore, a neutral structure is used to manage the common data o physical products of the same design. Position Item inherits structural information, and Physical Object obtains other attributes from Design Object. Time Stamp stores the tim relative to when Physical Object is installed on Position Item. Neutral Structure bridges the gap between the design product and physical produc and manages common structures of physical products from one batch, and it is a simpli fied mirror of the design structure with respect to the granularity and assembly structure in the processes of use and repair. It manages instructions, operations process, mainte nance methodology and necessary design information. Design Product, other Design Ob ject and Neutral BOM construct the Neutral Structure, such as an SPDM. Neutral Structure bridges the gap between the design product and physical product and manages common structures of physical products from one batch, and it is a simplified mirror of the design structure with respect to the granularity and assembly structures in the processes of use and repair. It manages instructions, operations process, maintenance methodology and necessary design information. Design Product, other Design Object and Neutral BOM construct the Neutral Structure, such as an SPDM.

Relation Source Object Destination Object Multiplicity
Position Structure, which is made up of Position Item and Position BOMs, mirrors the Neutral Structure and defines configuration data and position meta-data, which manage maintenance and repair documents that relate to the assembly position. Position Structure represents a virtual physical product that is independent of specific physical components and parts. Every Physical Product has a Position BOM to manage its sub-Item-Position In the inspection phase, according to quality standards, a strict working process and methods are used to supervise and control the quality of a physical product and to avoid providing defective physical products to the market. The aims of inspection are physical products, components and parts. The data of inspection are queues of inspections and bugs. IPrDM is built as shown in Figure 8. Physical Product, Physical Component and Physical Part inheriting from Physical Object exist in the whole PPDM. They can be inspected several times and use Inspection to store the data. The information of defects is described by Bug. Inspection and Bug are subclasses of Physical Object, too, and they are mainly the business object of the inspection phase. Physical Product, Physical Component, Physical Part and Bug have Inspection Form to address their attributes in the phase. and Physical Object are 1:0, 0:1 and 1:1 every moment. Physical Product a Objects have Forms to manage their attributes in different business p decides where the Form, Physical Product and other Physical Objects a In the inspection phase, according to quality standards, a strict wo methods are used to supervise and control the quality of a physical pro providing defective physical products to the market. The aims of inspe products, components and parts. The data of inspection are queues o bugs. IPrDM is built as shown in Figure 8. Physical Product, Physica Physical Part inheriting from Physical Object exist in the whole PPDM spected several times and use Inspection to store the data. The inform described by Bug. Inspection and Bug are subclasses of Physical Object mainly the business object of the inspection phase. Physical Product, Phy Physical Part and Bug have Inspection Form to address their attributes Service contains the use, maintenance, repair, and overhaul. The working condition, failure, maintenance, repair, overhaul, and com PCDM, SPrDM is built, as shown in Figure 9. The Physical Product is tomer, who has Gripe, and has many uase data, which involved Worki  Service contains the use, maintenance, repair, and overhaul. The data contain the working condition, failure, maintenance, repair, overhaul, and complaint. Based on PCDM, SPrDM is built, as shown in Figure 9. The Physical Product is owned by a Customer, who has Gripe, and has many uase data, which involved Working Condition and brings Recycling contains disassembly, cleanout, detection, reuse, remanu eration, burning, and Landfill. When out of service, physical products a lation economy enterprises. Physical products and components are disas physical parts are cleaned. After detection, some are reused directly i and others are remanufactured to recover the performance, regenerate then burned and landfilled. Based on PCDM, RPrDM is built, as shown i ical Product and Physical Component are dismantled, and we obtain nent, Physical Part, Material and Waste. Some can be reused. Blank, whi a new Physical Part, comes from Material. Waste receives Innocent T Physical Product is presented by Remanufacture and Reassembly of Phy and Physical Part. All Physical Objects in the recycling phase have a Re their recycling attributes. The content and management of the Process R as that for the Process Phase.  Recycling contains disassembly, cleanout, detection, reuse, remanufacturing, regeneration, burning, and Landfill. When out of service, physical products are taken to circulation economy enterprises. Physical products and components are disassembled, and the physical parts are cleaned. After detection, some are reused directly in other products, and others are remanufactured to recover the performance, regenerated for the material then burned and landfilled. Based on PCDM, RPrDM is built, as shown in Figure 10

Document Management
Document management is the basic function of PLM and is the first req customers. It manages unstructured data, including two-dimensional drawin mensional models, calculations, specifications, and simulation analysis da

Document Management
Document management is the basic function of PLM and is the first requirement of customers. It manages unstructured data, including two-dimensional drawings, threedimensional models, calculations, specifications, and simulation analysis data. Unstructured data are transferred and stored as a whole one, not considering the logic and stored structure.
Document management uses meta-data to manage all of the types of documents, as shown in Figure 11. DoDataset is meta-data to manage the file. Item is related to Document and DoDataset by citation, specification, and representation. Document, which is a superclass of Model and Draft, organises DoDataset of several files for the logic file, for example, a manual is composed of files in Chinese and in English, Model contains UG NX files and CATIA files, and Draft includes a metric drawing and an imperial drawing of the same content.
Processes 2021, 9, x FOR PEER REVIEW example, a manual is composed of files in Chinese and in English, Model contain files and CATIA files, and Draft includes a metric drawing and an imperial dr the same content.

Case Study
An example using UDMPM to manage data on shipping in Huanghai Ship Co. Ltd. is studied. A sship is a complex product system, involving several majo are complex relations among phases, system, sections, components, parts and doc The ship's data management has obvious characteristics, and a unified data mo conceptual ship, digital ship and physical ship is built. Because the ship has t data, the case focuses on the marine engine system.
In a shipyard, a conceptual ship manages a ship type, such as a Multi-Purp tainer (MPC) Vessel, a Ro-Ro Passenger Vessel, or an Oil Tanker. MPC is a type o transfer containers, and its CCDM is shown in Figure 12. Conceptual MPC uses a tree and a conceptual structure to manage all the conceptual data. The function of engine system includes voyage power, cooling, air exchange and separate oil. Th Engine System has a Diesel Engine System, a Steam Turbine System, a Ventilation and an Oil Separator. Diesel Engine Systems and Steam Turbine Systems both voyage power and are redundant units. However, a conceptual MPC can select on types. Function-Structure mapping describes the relation between the function a ture units.
Digital MPC originates from conceptual MPC and manufactures one or seve ical MPCs. The DCDM of digital MPC is shown in Figure 13. Some digital ob cover several business phases for uniqueness, such as the digital MPC existing i quirements management phase, the structure design phase and the process desig Thus, digital MPC has Requirement Form, Structure Form and Process Form, wh arately contain the attributes of corresponding phases. Requirement Form own

Case Study
An example using UDMPM to manage data on shipping in Huanghai Shipbuilding Co. Ltd. is studied. A sship is a complex product system, involving several majors. There are complex relations among phases, system, sections, components, parts and documents. The ship's data management has obvious characteristics, and a unified data model for a conceptual ship, digital ship and physical ship is built. Because the ship has too much data, the case focuses on the marine engine system.
In a shipyard, a conceptual ship manages a ship type, such as a Multi-Purpose Container (MPC) Vessel, a Ro-Ro Passenger Vessel, or an Oil Tanker. MPC is a type of ship to transfer containers, and its CCDM is shown in Figure 12. Conceptual MPC uses a function tree and a conceptual structure to manage all the conceptual data. The function of a marine engine system includes voyage power, cooling, air exchange and separate oil. The Marine Engine System has a Diesel Engine System, a Steam Turbine System, a Ventilation System and an Oil Separator. Diesel Engine Systems and Steam Turbine Systems both achieve voyage power and are redundant units. However, a conceptual MPC can select one or two types. Function-Structure mapping describes the relation between the function and structure units.
Tube separately own Joining Process Route, Fixing Process Route and Machining Route. The Machining Process Route is shown in Figure 13, and others are omitte bending process step uses the Bending Machine in the Cold Working Shop.   Digital MPC originates from conceptual MPC and manufactures one or several physical MPCs. The DCDM of digital MPC is shown in Figure 13. Some digital objects can cover several business phases for uniqueness, such as the digital MPC existing in the requirements management phase, the structure design phase and the process design phase. Thus, digital MPC has Requirement Form, Structure Form and Process Form, which separately contain the attributes of corresponding phases. Requirement Form owns attributes, such as the seaworthy area, dead weight ton and seating capacity. Structure Form includes the length, width, height, and draught. The Process Form has a section number, max section weight, and welding requirements. Digital MPC uses Requirement BOM, Structure BOM and Process BOM to construct the backbone of the data. The black line, red line and green line separately express the Requirement Management Rule of RRF, the Structure Design Rule of SRF and the Process Design Rule of PRF, and RPDM, SPDM and PrPDM. In SPDM, sub-Items of the Marine Engine Room are the Diesel Engine System and the Ventilation System, which disappear in PrPDM because they are virtual parts, and they appear only for planning processes of structure design management. The long broken line is Requirement-Structure Mapping. The short dotted line is the Citation between design parts. The Exhaust Tube has a single structure, and Exhaust Tube A, B and C have different installation sites. They separately represent structure information and process information on the same part. Digital MPC, Marine Engine Room and Exhaust Tube separately own Joining Process Route, Fixing Process Route and Machining Process Route. The Machining Process Route is shown in Figure 13, and others are omitted. The bending process step uses the Bending Machine in the Cold Working Shop.    Every physical MPC has a unique ID, such as HCY-93, which has 8000 Dead Weight Ton (DWT), as shown in Figure 14. In PCDM, Neutral Structure is a mirror of PBOM, and the object comes from PBOM, also. The Position Structures of HCY-93 and HCY-94 are copies of Neutral Structure, using position objects. Timestamp manages the installation relation of position objects and physical objects. Before 6/19/11, the Air Blower uses CZ-80A, and after 6/19/11, it uses JCZ-50B. All of the physical objects are produced according to their corresponding design objects and obtain design attributes from them, such as the design performance and working condition, for example, the KYDH204SD-23 Oil Separator. The CLH100-125 Sea Water Pump has Inspection Form for inspection information, Service Form for use and MRO information and Recycling Form for disposal and recycling information. In the Inspection phase, HCY-93-08 Marine Engine Room experiences Air Tight Inspection and Water Tight Inspection, in which two bugs are found. In service, the KYDH204SD-23 Oil Separator is maintained, because of failures tracked by the system such as Oil Leak Accident and Shake Seriously. In recycling, 8DKM-28 Diesel Engine has Remanufacture Process Route to recover performance, and Stainless Steel is obtained from the HCY-93-08-02 Blast Pipe.
Tight Inspection and Water Tight Inspection, in which two bugs are found. In service, the KYDH204SD-23 Oil Separator is maintained, because of failures tracked by the system such as Oil Leak Accident and Shake Seriously. In recycling, 8DKM-28 Diesel Engine has Remanufacture Process Route to recover performance, and Stainless Steel is obtained from the HCY-93-08-02 Blast Pipe.

Discussion
There are three forms in the product life cycle: conceptual products, digital products and physical products. The carrier and data evolution characteristics of these three product forms are different, so it is difficult to efficiently integrate product life cycle data.
In the product life cycle, there are several business stages such as conceptual design, structural design, process design, manufacturing, and service use. Many previous studies established a data model or BOM for each stage, and integrated them using mapping.
Other studies established a model for all stages as the only data source. The former abandons the common characteristics of data in multiple stages of a product form and weakens the evolutionary relationship between them. The latter cannot manage the data of each

Discussion
There are three forms in the product life cycle: conceptual products, digital products and physical products. The carrier and data evolution characteristics of these three product forms are different, so it is difficult to efficiently integrate product life cycle data.
In the product life cycle, there are several business stages such as conceptual design, structural design, process design, manufacturing, and service use. Many previous studies established a data model or BOM for each stage, and integrated them using mapping. Other studies established a model for all stages as the only data source. The former abandons the common characteristics of data in multiple stages of a product form and weakens the evolutionary relationship between them. The latter cannot manage the data of each product form according to its characteristics and distinguishes the evolution mode of each product form.
The paper summarizes the connotation of the three forms of products, and proposes a unified product data management model that covers the differences in data management among three product forms. Based on previous researches, the data model is constructed at two levels: product form and business stage. We have inherited the business-oriented modeling method and the idea of a single data source, and combined the two organically.

Conclusions
In this paper, we present a data management approach that is based on three product morphology types for concept data, digital data and physical data over the course of a full lifecycle. Three product morphology types and UDMPM are the core of the approach. Product morphology is classified into three types: conceptual product, digital product and physical product, by the carrier and the evolutionary characteristics of the product. According to the evolutionary characteristics of every product morphology type, UDMPM makes a corresponding management mode. A conceptual product has one business phase, and a single data model, and CCDM is the best approach. Because designing a product involves requirements management, structure design and process design, and because it evolves continually, a flexible DCDM allows for consistency and integrality. In addition, business applications are supported by phase data models, which are founded by adding phase rule filters on the DCDM. The structure and features of a physical product are not changeless, but properties and status change over time. Then, PCDM manages changeless data, and the phase private data model describes the changed data. In general, the approach integrates three data management modes into a whole system, which addresses all of the data in the full lifecycle, eliminating data redundancy and holding consistency and integrality.
Previous research focused on the integration of multi-stage BOM or data model with data mapping, or a single data source of multiple stages. Based on the above research, the paper summarizes the three forms of product connotation and proposes a unified product data management model, establishing a single data source for each product form, manage multiple stages of data and the data evolution between them, using global object mapping to integrate three data models, and providing a new method for integrated management of product life cycle data.
In the current research, big product data are of great significance to product operation and maintenance and design and manufacturing. Digital twin technology is also a current research hotspot. The data characteristics of big data are different from the data studied in this article. Digital twins are another carrier of products, and their evolutionary characteristics are also different from the data studied in this article. Due to limited conditions, the paper did not study the management model of big data and digital twins. This is an area for future research.