Wen-Bin Zhao

Yang Ho Park

Hye Yun Lee

Chan Mo

Sang Do

Design and Implementation of a PLM System for Sustainable Manufacturing

Keywords: PLM(Product Lifecycle Management), Sustainable Manufacturing, Information Model, UML(Unified Modeling Language)

Since the beginning of the industrial revolution, manufacturing industries have primarily been responsible for adverse effects on the environment caused by pollutants such as carbon dioxide. Therefore, there has been tremendous pressure for these industries to be globally competitive within the range of environmental regulations and laws, which has been greatly increased and reinforced these days. In addition, manufacturing industries have been confronted with new challenges owing to the depletion of energy and natural resources, economic stagnation, and increasing human needs that become very diverse. Thus, low-carbon green growth, cleaner production, and eco-friendly products are main issues, and sustainable manufacturing is the driving direction in the future manufacturing industry. PLM (Product Lifecycle Management) is one of the innovative manufacturing paradigms that leverage e-business technologies in order to allow a company's product content to be developed and integrated with all company business processes through an extended enterprise. In this paper, we designed a new information model and a PLM system for sustainable manufacturing using UML methodology. We performed thoughtful analyses of existing PLM and sustainable indicator, basic schema and information model for supporting sustainable manufacturing engineering are developed. This paper also presents apractical case study showing information model and sustainable engineering by using commercial PDM software.

Introductions

A study released by the U.S. National Academy of Sciences (NAS) in 2010 said, "Climate change is occurring, is caused largely by human activities, and poses significant risks for -and in many cases is already affecting -a broad range of human and natural systems." [START_REF]Advancing the Science of Climate Change[END_REF].Since the beginning of the industrial revolution, manufacturing industries have primarily been responsible for adverse effects on the environment caused by pollutants such as carbon dioxide. Therefore, there has been tremendous pressure for these industries to be globally competitive within the range of environmental regulations and laws, which has been greatly increased and reinforced these days. In addition, manufacturing industries have been confronted with new challenges owing to the depletion of energy and natural resources, economic stagnation, and increasing human needs that become very diverse. Thus, low-carbon green growth, cleaner production, and eco-friendly products are main issues, and sustainable manufacturing is the driving direction in the future manufacturing industry.

Sustainable manufacturing is a new paradigm in which manufacturing industries produce their products in a sustainable manner to maintain global competitiveness while coping with recent challenges and problems. According to the report by the Brundtland Commission in 1987, sustainable development is defined as "development that meets the needs of the present without compromising the ability of future generations to meet their own need." This description has generally been quoted as the definition that best expresses the concept of sustainability [START_REF] Lee | MAS2: Modeling & Simulation-based Life Cycle Evaluation for Sustainable Manufacturing[END_REF].

Figure 1 Concepts of sustainable development

As shown in Figure 1, sustainable development is balanced development satisfying economic and social development as well as protecting environments [START_REF]Sustainability[END_REF][START_REF]Sustainable Manufacturing[END_REF]. The goal of sustainable development is to "meet the needs of the present without compromising the ability of future generations to meet their own needs." As key forces in society, organizations of all kinds have an important role to play in achieving this goal [START_REF]Sustainability Reporting Guidelines (ver. 3.1)[END_REF].Sustainable development as a manufacturing industry requires new and innovative choices and ways of thinking as well as the production of sustainable products such as energy efficiency and green growth [START_REF]Sustainable Manufacturing[END_REF][START_REF] Jayal | Sustainable manufacturing: Modeling and optimization challenges at the product, process and system levels[END_REF]. Knowledge and technological advancement lead to economic growth in addition to resolving factors threatening the relationship between our social relations and manufacturing industries as well as environmental and economic sustainability.Therefore the PLM philosophy that is utilized broadly in manufacturing industry also has to have contribution to the sustainable development in engineering activity.

In this research, we designed a new information model and a PLM system for sustainable manufacturing using UML methodology. We performed thoughtful analyses of existing PLM and sustainable indicator, basic schema and information model for supporting sustainable manufacturing engineering were developed. This paper also presents detailed case studyfor sustainable PLM using commercial PDM software.

Backgrounds

UML(Unified Modeling Language) Methodology

UML(Unified Modeling Language) is a standardized general-purpose modeling language in the field of object-oriented software engineering. The standard is managed, and was created, by the Object Management Group. It was first added to the list of OMG adopted technologies in 1997, and has since become the industry standard for modeling softwareintensive systems [7]. And, UML is used to specify, visualize, modify, construct and document the artifacts of an object-oriented software-intensive system under development.

UML combines techniques from data modeling (entity relationship diagrams), business modeling (work flows), object modeling, and component modeling. It can be used with all processes, throughout the software development life cycle, and across different implementation technologies [7]. UML has synthesized the notations of the Booch method, the Object-modeling technique (OMT) and Object-oriented software engineering (OOSE) by fusing them into a single, common and widely usable modeling language. UML aims to be a standard modeling language which can model concurrent and distributed systems. UML is a de facto industry standard, and is evolving under the auspices of the Object Management Group (OMG).The UML methodology is largely divided into the structural model, behavior model and architectural model. This research used the structural model of systems designing the information model primarily as Class Diagram and Case Diagram [START_REF] Chun | UML essence[END_REF][START_REF] Thimm | Towards unified modeling of product life-cycles[END_REF].

Existing PLM Information Model

For the past several years, a considerable number of PLM systems have been designed and established in order to perform engineering in manufacturing industries. Among them, there is the PLM system composed of the P3R information model dividing PLM information into P3R(Product, Process, Plant and Resource) to promote production improvement.

In this paper, a P3R information modelwhich was introduced in the book of"Digital Factory for Human-oriented Production System",is referenced as existing PLM information model [START_REF] Canetta | Digital Factory for Human-Oriented Production System[END_REF]. As shown in Figure2, it is managed primarily in the unit of process and substructures such as products produced in this process, resources used in the process and plant information belongs to this process.

Figure 2 An existing PLM information model [START_REF] Canetta | Digital Factory for Human-Oriented Production System[END_REF] 3 Sustainability Indicator

GRI(Global Reporting Initiative) Sustainability Indicator

In 1997, the United Nations Environment Programme(UNEP) together with the United States nongovernmental organization, Coalition for Environmentally Responsible Economics(CERES) launched the GRI with the goal of "enhancing the quality, rigour and utility of sustainability reporting" [START_REF]Sustainability Reporting Guidelines (ver. 3.1)[END_REF]. Reporting is therefore the strong focal point of the guidelines. The GRI uses a hierarchical framework in three focus areas, namely social, economic, and environmental. The hierarchy consists of categories, aspects, and indicators. The guideline contains more than 100 indicators. However, not all the indicators are easy to evaluate and no guidance is given on how to choose between the indicators [START_REF] Veleva | A proposal for measuring business sustainability: addressing shortcomings in existing frameworks[END_REF]. The guideline does, however, indicate what should be considered at a lower level, i.e. operational or project level within the company, especially if the company reports on sustainability using the GRI principles [START_REF] Labuschagne | Assessing the sustainability performances of industries[END_REF].

IChemE Sustainability Indicator

The Institution of Chemical Engineers (IChemE) published a set of sustainability indicators in 2002 to measure the sustainability of operations within the process industry. The IChemE provides standard reporting forms and conversion tables [START_REF]The sustainability metrics: sustainable development progress metrics recommended for use in the process industries[END_REF]. This framework is less complex and impact-oriented. However, the framework strongly favors environmental aspects, as well as quantifiable indicators that may not be practical in all operational practices, e.g. in the early phases of a project's life cycle [START_REF] Labuschagne | Sustainable project life cycle management: Criteria for the South African process industry[END_REF].

Sustainability Indicatorsfor Sustainable PLM

Elements associated with sustainable development were organized based on GRI reports as well as additional supplementary IChemE reports [START_REF] Zhao | A study on concept design of a PLM system for sustainable engineering[END_REF]. As shown in Figure 3

PLM Information Model for Sustainable Manufacturing

Defines Use Case Actors

This paper analyzed the requirements for Sustainable Engineering using the Use Case Diagram in order to classify elements of sustainable development by using the UML methodology. Actors performing acts in sustainable engineering systems were defined for the use of the Use Case Diagram. As in Figure 4, from the aspect of corporations, the actor is the company, from the social aspect, the actor is the customer and society, from a national aspect, the actor is the government, and from an environmental aspect the actor is Earth.

Sustainable PLM Information Model

The final Sustainable PLM superordinate class was composed through an analysis of requirements and classification on elements of sustainable development for Sustainable PLM.As shown in Figure 6, the subordinate class is added for compliance as information composition for Product which is a Sustainable PLM information model superordinate class. As in Figure 7, the subordinate class is added for compliance, used materials, energy and emissions/pollution as information composition for Process which is a Sustainable PLM information model superordinate class. As shown in Figure 8, the subordinate class is added for compliance, materials used, biodiversity, energy and emissions/pollution as information composition for Plant which is a Sustainable PLM information model superordinate class. As shown in Figure 9, the Enterprise model is shown as the superordinate class of the newly added Sustainable PLM information model. Elements of sustainable cannot be contained in the P3R model leading to the need for data management with the Enterprise class from the corporate aspect. The superordinate class Enterprise which was added is composed of investment, economic performance, indirect economic effect, market presence, social influence, product responsibility, labor practices and human rights as the subordinate class. The existing PLM information model as the Process unit is composed of Product information and Plant information which is the affiliated plant, Resource information which is the used facility and Product information which is the produced product. However, all the information is information that is managed in order to improve productivity. Sustainable PLM information model has Enterprise information of the affiliated corporation which is the superordinate class and additionally managed information associated with sustainability in Plant information, Product information, and Process information.

Implementations and A Case Study

This paper, in order to verify Sustainable PLM information model collected related data based on the TOTAL basic application case which is the typical LCA Software. As shown in Figure 11, this case after passing through a total of 9 processes by using 12 kinds of materials, 9 resources and 5 kinds of energy emits 9kinds of product/part, 5 kinds of emissions and 5 kinds of pollutant.

  , this paper defined sustainable development elements for Sustainable PLM and classified as environmental indicators, economic indicators, and social indicators. Environmental indicators are composed of materials used, energy, emissions/pollution, biodiversity and compliance; economic indicators are composed of investment, economic performance, market presence and indirect economic effect. Finally, social indicators are composed of labor practices, human rights, social influence and product responsibility.

Figure 3

 3 Figure 3 Sustainability indicators for sustainable PLM

Figure 4

 4 Figure 4 Defines use case actors

Figure 5

 5 Figure 5 shows the analysis and classification of requirements for elements of sustainable development by using the Use Case Diagram and Class Diagram.

Figure 5

 5 Figure 5 Defines use case diagram and class diagram

Figure 6 Figure 7

 67 Figure 6 Sustainable PLM information model (Product)

Figure 8

 8 Figure 8 Sustainable PLM information model (Plant)

Figure 9

 9 Figure 9 Sustainable PLM information model (Enterprise)

Figure 10

 10 Figure 10 Sustainable PLM information model

Figure 11

 11 Figure 11 General information of a case study

Figure 12

 12 Figure 12 Implementations for a case study

Figure 13

 13 Figure 13 Results of implementations for a case study

Acknowledgment

This research was supported by a grant (Program No.: C6A2402) from BK21 Research & HRD Group for Management of Complex Systems. This support is gratefully acknowledged.

PLM information model as well as classification of sustainability elements through UML methodology.

The information model that is proposed in this paper has to be detailed and simplified for future utilization, and it is needed to construct an integrated system that is able to conduct analysis on both productivity and sustainability simultaneously.


Patrick Müller
email: patrick.mueller@ipk.fraunhofer.de

Michael Muschiol
email: michael.muschiol@siemens.com

Rainer Stark
email: rainer.stark@ipk.fraunhofer.de

PLM-Based Service Data Management in Steam Turbine Business

Keywords: Product Data and Lifecycle Management (PDM/PLM), Service Data Management, Service Business Process, Maintenance, Repair and Overhaul (MRO), Steam Turbines, Industrial Case

de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction and Motivation

This paper provides first-hand experiences form a particular PLM deployment project in industry. The target was the implementation of a new concept for a PLM-supported process in steam turbine service business. The next sections deliver information of the context of steam turbine business, related business requirements, and specialties in socalled MRO (Maintenance, Repair, and Overhaul) activities. After a detailed as-is process analysis, the new PLM concept and implementations will be described. Findings are presented in a discussion section.

1.1

Motivation for new PLM solution in Steam Turbines MRO Business

Steam turbines are complex systems with high investment costs, long life cycles, high technical requirements and a huge demand of technical services e.g. for system maintenance [START_REF]Maintenance Terminology[END_REF][START_REF]VDI 2246: Designing maintainable engineering products[END_REF]. Maintenance of steam turbines in general is not performed by the operators (e.g. plant owners) but by service providers who are capable to handle the comparably high system complexity and who are operating specialized plants and workshops needed for maintenance of large equipments (such as steam turbines). Typical services are inspections, spare part services, repair, or overhaul including technical upgrades. This kind of service is called MRO (Maintenance, Repair, and Overhaul). In the past years, solutions integrating products and services are applied beyond MRO-services. Business models and operating models deliver the base for such integrated solutions and shift responsibility from the customer to suppliers and MRO providers [START_REF] Müller | A generic PSS development process model based on theory and an empirical study[END_REF][START_REF] Tukker | Eight types of product-service system: eight ways to sustainability? Experiences from Suspronet[END_REF].

Slim processes and a suitable IT support are needed to perform effective and efficient customer contact and MRO activities. On the one hand, this support should enable the management of product-and service-relevant data. On the other hand, the state of design and manufacturing of the steam turbine at a particular time needs to be transparent or at least traceable [START_REF] Eigner | Produktdatenmanagement-Systeme[END_REF]. The tracking of the state of design and manufacturing is a special challenge of the lifecycle management for a steam turbine, because the lifecycle of a steam turbine can last several decades. Data being relevant for the steam turbine and MRO activities carried out typically can be stored in different data management systems (maybe even of different MRO providers) without any tracelink. Oftentimes, engineers have to "scout" in different data management systems and directly at the real turbine to trace the as-is configuration and documentation state.

A big proportion of the relevant design data and design documents (e.g. drawings) are stored in Product Data Management (PDM) systems and in Enterprise Resource Planning (ERP) systems. Throughout the long lifecycle of a steam turbine different engineering disciplines, departments, and finally company sites generate and change data of it and manage these in their own IT systems. This situation seriously complicates competitive, customer-oriented, high class MRO offerings and a transparent MRO process control, consistently tracking the design and configuration states of steam turbines.

A process analysis of the as-is situation of selects sites of SIEMENS Energy Service in Germany facilitates to get deeper insight into current challenges and to explain the boundary conditions for the new PLM process and related implementations.

Research Approach

The findings presented in this paper originate from collaborative work of SIEMENS Energy Service (site Nürnberg, Germany) and the Division Virtual Product Creation of the Fraunhofer Institute for Production Systems and Design Technology IPK (Berlin, Germany). The collaborative approach is based on applied research. The research institution was involved in a PLM deployment project of SIEMENS in order to give a neutral, external assessment of the deployment strategy and progression state. Find-ings from this collaborative work and further reflections on PLM deployment projects are summarized and published herewith. Furthermore, the Fraunhofer IPK carried out a study on MRO business needs and technologies [START_REF] Uhlmann | Markt-und Trendstudie[END_REF]. One focus area of this study was "MRO Planning and digital Assistance". Practitioners were asked to select one approach from a given list of improvement options to rank the best. 309 answers (feedback rate 25%) delivered following estimation of improvement potential in digitally supported MRO processes: High potential for improvement is in information and configuration management (26%). Assistant systems and simulation tools together were chosen also by 26%. Further 15% see the greatest demand of improvements in an adaptive process planning. Collaboration tools and reserve engineering solutions have been chosen by 8% each. 7% regarded tools for global asset management and production control as most important. The same rate found augmented reality application as most promising. Digital training systems were selected by 3% of the practitioners. One major fining of the examination finally is that a successful information and configuration management is an important issue and the main technology for a successful MRO processes. This study complements findings retrieved in the case study presented in this paper.

As-Is Situation of the MRO Service Process and PLM

The analysis of the as-is situation is providing insight into the overall lifecycle of a steam turbine, different types of MRO service orders and the generation and management of engineering data. The following subsections explain a typical MRO business case for energy systems.

Product Lifecycle of a Steam Turbine

In the investigated case, the product lifecycle of a steam turbine is addressed by three major competencies: firstly, Order Engineering (working on orders for new systems); secondly, Ramp-Up (installation, erection); thirdly, Service (mainly MRO services). A reorganization of business units carried out in the past, separated for instance Order Engineering from the Service. The introduction of independent PDM and ERP systems in each unit finally caused operational barriers. As a result, different data models, information standards, data access rights and additionally developed interfaces exist on either side. This situation led to additional monetary effort to operate and maintain the various PDM and ERP systems.

In Order Engineering, often standard components are used, which are managed in the PDM system of the Order Engineering department. The order-related product structure is generated and managed in this PDM system. The order-specific manufacturing execution is supported with a particular ERP system. During Ramp-Up, the information of the Order Engineering is used to install the system in the customer's plant. Data generated in this process step are stored in a particular data management system, which oftentimes bases on MS Office products. In case of a service-caused ramp-up, data from the PDM system of the Service department is used. The Service department operates its own PDM system to manage its engineering data, because many service orders require engineering changes in drawings and calculations. For instance, the preparation of drawings for the manufacturing of spare parts (e.g. turbine blades) in case of missing documentation or adaption design for upgrades.

Service Orders in particular

The MRO projects depend on the customer orders. Typical orders are spare parts orders, repair orders, overhaul orders, or so-called foot prints. A foot print is an overhaul including technological upgrades. A steam turbine is almost engineered and manufactured entirely new in such kind of an order. Changes of the basement foremost do not happen. Significant is the speed and delivery accuracy (time appointment toward a customer) of an MRO service process. Both are very depending on the current product documentation, which requests continuous maintenance and a central availability. Oftentimes, MRO service for steam turbines is characterized by insufficient digital representation of steam turbines in IT systems at the moment of commissioning. So-called "Old Fleets" (Ger. Altfotten) often cause trouble because the design documentation is very old and hence only available paper-based but not in 3D CAD models. Sometimes, engineering data were generated in another IT system generation. Some design and service data is missing completely if a turbine fleet has been taken over from another manufacturer. Especially data of purchase parts are missing.

Service and Engineering Data

Figure 2 shows on the one hand data responsibility and on the other hand growth of data volume. The Order Engineering has the responsibility of data for a relatively short time. Approximately for five years, including the period of warranty. However, the Service department is responsible for data for the next thirty years after FAC (final acceptance certificate) [START_REF] Ladeck | PLM im Kraftwerksbau[END_REF]. Over time, the data volume grows continuously. The reason for that is that all states of configuration, starting with original design data, manu- facturing data, ramp-up data (incl. redlining in technical documents such as drawings), design changes (adaptive design of spare parts or degraded components), and upgrade design of the engine, have all to be management continuously throughout all MRO projects of a particular turbine. The latter aspect especially is critical in order to meet the requirements of the product liability law. Thus, the Service department is responsible to trace the current configuration of each maintained steam turbine as well as related documentation (e.g. manual, reference books). Based on the analysis of the as-is situation, a concept for a new PLM-supported MRO service process was developed. The premise is the usage of just one common PDM system in combination with one dedicated ERP system along the entire PLM process.

The idea to work with just one PMD system is not new in general. Nevertheless, the way it is implemented and adapted to the application area, namely MRO business for long living systems, is new as the following sections will disclose. For instance, the way the PDM folder structure is going to be used as "machine folder" is new and will be described in detail in the later elaborations. As SIEMENS PLM Teamcenter [START_REF]SIEMENS PLM Software[END_REF] and an SAP ERP [START_REF]SAP ERP[END_REF] system have been chosen in advance, this paper is not indented to benchmark MRO functionality of currently offered PLM solutions. (Remark: Even if MRO functionality is moving into currently offered PLM solutions, reference applications are rare for some interesting functionality.) Figure 3 reveals a framework for the PLM process concept. Between both systems (PDM and ERP) the following concepts are aligned: the status net, the data model, the

Data responsibility at Service department:

Service has responsibility for the turbine but not necessarily the right to influence the data management solution according to service business requirements.

document types, as well as the meta data of the material master. These alignments ensure an effective hand-over between the single processes steps. Furthermore, the usage of one common PDM system avoids the development and permanent maintenance of IT interfaces over the process of Order Engineering and the Service. A more detailed discussion of the single steps of the PLM process delivers an overview of data which have to be managed in this process. The left side of Figure 4 shows in detailed form the steps in the PLM process of a turbine as introduced in Figure 3. The central database stores all the results of the single process steps such as drawings, product structures, maintenance documents etc. As most data is related to engineering tasks, a PDM system is and should be the central technological building block for the IT-supported PLM process.

The Order Engineering department is generating the necessary documents for manufacturing, assembling, and erection of new steam turbines. Examples for these are design calculations (e.g. thermo-dynamical), manuals, or product structures. The product structures serve to derive the bill of material (BOM). These documents have to be stored in the common PDM system by the Order Engineering.

During installation / ramp-up, the different documents are created, which reflect the current "as installed" configuration (current state of design and manufacturing) of the steam turbine. Actually this means that documents from Order Engineering will be changed in a controlled process. Affected documents are checked out, changed, and checked in as new revisions within the same PDM system. Finally, changes are documented and available for all departments promptly in an updated revision.

In case of service orders (spare parts, repair, overhaul, or foot print), the service engineers use these documents available in the central PDM system, which were generated and changed in the previous process steps. Accordingly, the efficiency of service is instantly depending of the current data of the respective steam turbine.

Figure 5 and 6 illustrate the implementation of the new concept in a PDM system: On the left side of both figures, a folder structure in the PDM system is shown, which allows an efficient management of documents and material master files as well as their meta data. The highest access point in a service order is the so-called machine folder (Ger. Maschinenakte), which is identified by the machine number and a key word. The machine number is a unique identifier and the key word is representing the owner of the engine (example Shell). The machine folder is a kind of collector for all technical and product-specifying data for a particular turbine. The figures 5 and 6 show an exemplary allocation of documents, which are generated in various lifecycle and PLM process steps, to the defined folder structure.

The folder structure is a compromise of two different views, which cannot be completely separated from each other. The integrated folder structure on the one hand represents an "image" of the company's organizational structure. On the other hand it represents an "image" of the several order types (example: repair order; foot print order) and engineering disciplines. In both views, the lifecycle of a steam turbine is partly visible. The documents now will be stored in the corresponding folders: For instance, a detail drawing of a repair part will be stored in the folder "Engineering". An erection report generated during the turbine assembling will be stored in the folder "Field Service". Both folders are part of a higher folder structure. The continuous storage of the current as-is configurations (design and manufacturing state) in each order enables a consistent tracking of configuration states along a sequence of differ-ent orders. The following example shows a possible service order sequence over a longer time period: spare part order → repair order → spare part order → revamp order → foot print order → spare part order.

Discussion of Experiences from Implementation/Application

Special challenges appear in the practical introduction of the new concept: First, the definition of the new PLM process is complicated because it tries to align the data management of stakeholders being active in different system lifecycle phases. Second, it is tough business to integrate approved service-specific work procedures, which are related to the core engineering design competence and vital on an operational level of the MRO service projects, into the new PDM system. The typical PDM use cases such as creating, changing, approving, and searching documents and material masters, viz. frequent events of the PDM system use, have to meet the mindset and successful work procedure of engineering in service business (for instance to enable quick change processes for spare parts reengineering). Without a meaningful compromise of technological possibilities and approved work practices neither the mentioned benefits of the system nor the user acceptance of the system can be reached.

Another critical point is a clear definition of the data responsibility between Order Engineering and Service. As mentioned in the as-is situation analysis (see section 2) data come from Order Engineering and will be enriched over the lifecycle of the turbine by the Service. The Order Engineering wants to keep its data responsibility in the matter of reuse of standard parts. In opposite, the Service department likes to have most possible influence on the product structure regarding its responsibility of tracking changes. This problem is found in the different working procedures and is naturally clear, because Order Engineering (performing new design) and Service (performing repairs and changes) are used to apply different types of by the product structures and bills of material (e.g. Engineering BOM vs. Service BOM). One dedicated example is design approvals: A design change in MRO engineering (e.g. for a blade of a steam turbine) can be approved by two engineering experts of the same hierarchical level. One makes an adaptive design and formally requests a second engineer to verify the change. So to say, a "4-eye principle" is applied and supported in the current IT system (PDM + ERP). A design change in an original design process of another organizational unit follows for instance an approval process, where engineers of different organizational roles are involved (e.g. engineering expert and technical development project leader). As such a process differs in digital rights allocation, the role model and process steps and expected/accepted duration, a consolidation can become wearing.

In the current case, the project management for the PLM implementation was organized after the principle of parity. This means that the lead was parted in two positions of equal rights, one staffed by a representative of the business division, the other staffed by an IT leader. This parity in project management has been experienced as hardly conductive. As both parties had equal rights, clear decisions needed much effort. Furthermore, the project was perceived as a pure IT project. Per contra, experiences show that PLM projects have been more successful, if the project responsibility was borne by the business unit, viz. the (end) users.

Another important aspect is the characteristic of the applied PLM deployment strategy. The strategy is marked by the fact that one PDM function (e.g. document management) is deployed at all sites at the same time. An advantage is that no site starts to develop own workarounds before this functionality is available. A drawback is that not all potential improvements of efficiency, which are conceivable based on PLM approaches and PDM functionality, are realized from the beginning. Anyhow, this strategy advocates end user acceptance because of quick success experiences. Furthermore, even the complexity of the PLM approach and the use of PDM system functionality is controlled by a stepwise extension of functions. This positively affects the "controllability" of the new system in early deployment phases.

In case of an alternative strategy, all PDM functions necessary for the entire PLM solution could be deployed in the first step at one site. After a consolidation / stabilization at this first site, the software is deployed to other sites. This strategy is characterized by a comparably high complexity of the software system, a fact that can conflict with quick success experiences and finally user acceptance.

At least, one aspect of major importance is a proper change management in order to communicate the advantages of a new PDM system and PLM solution for the end users. Especially those end users, who up to now, are accustomed to use a system tailored to their needs, need to be addressed with regard. Anyhow, such end users can help to give important details on business needs and bottlenecks, which hardly can be anticipated by IT experts such as programmers.

Outstanding Concept Elements

Beyond the borders of the order-and organizational-structure-oriented PLM process, a set of additional potentials is still visible: support by PDM is reasonable for MRO project management, MRO knowledge management and novel MRO service processes such as Reverse Engineering.

Project Management in MRO Projects

To indentify the current system configuration, documentation state, degradation after use, and damages steam turbines are disassembled step by step partly in the field (in the operating plant of the customer) and partly in the MRO plant of the provider. The disassembly, diagnose, and MRO planning happens in parallel as many MRO tasks first become clear after certain disassembly step. Each turbine finally is treated individually, because typically many "trouble shooters", service technicians, design engineers, and production experts work hand in hand to design and manufacture spare parts, to repair large components and to assemble and test the complex system for a next period of operation. Finally, maintenance orders typically are carried out in project form. Typically, there are no replacement turbines in stock and such MRO projects are carried out under time pressure. The MRO engineers have to clarify the turbine condition and to trace its configuration and documentation in different sources and IT systems. This process today is very document driven and thus it is reasonable to implement IT support for project management "near" by the leading PDM system. In general, the PDM systems offered nowadays provide project management functionality. Hereby, it still has to be assessed how far the functionality of the PDM system used in this particular case meets the requirements in turbine MRO service business.

Knowledge Management in MRO Service

Up to now, a just particularly solved challenge is IT supported learning from past repair projects (e.g. generalization and harmonization of repair experiences; identification of successful and less successful repair measures; recognizing of failure patterns depending on certain parts, configuration or operating conditions). The core competence relies on experiences regarding successful or less successful repair measures. Knowledge of successful maintenance projects is already stored in a special database (called technology database). This knowledge can be fetched in later projects. Potential of improvements exists considering the link between the technology database and the actual design-oriented product documentation (e.g. product structure, product model) in the PDM system.

Reverse Engineering

New 3D measuring technologies facilitate in sophisticated reverse engineering processes and data processing approaches to generate 3D models and drawings for mechanic and electronic system components. In case of missing or incomplete digital models, drawings etc. components are scanned 3D and new documentation is generated. For instance, digital models of turbine blades can be generated with reverse engineering in order to produce spare parts. In reverse engineering processes, 3D point clouds are generated with 3D measurement equipment first, and developed further in a stepwise process e.g. to generate parametric CAD models. Many product models, model revisions, and large data volumes are generated. Working with such model is close to typical engineering design activities and the models generated are analogue to common CAD models and oftentimes used in CAD systems. Therefore, management of such data and of reverse engineering workflows in the new PDM system is a target of at least one site. First attempts have been made and found useful. Further work is planned in order to design an efficient, use-case-driven process, to manage reverse engineering data as part of the new PLM approach. Opportunities for multi-site reverse engineering collaboration are currently being validated.

Summary and Conclusion

The Service has a long time period of data responsibility. Therefore, it should also receive respective data superiority and the possibility to design the logic of the data storage. Especially the demand to access, change, and manage the complete documen-tation of a steam turbine has to be highlighted. A common PDM system on the side of Order Engineering and Service secures data consistency of the current data stockin the project management as well as in the Service department. Therefore, the goal is to store all engineering-relevant product data in one common PDM system. For the PLM process of single part producer or a series producer it is indispensable to have a secure and a version controlled storage of all product-relevant data. That is the precondition for a transparency and tracking of data to secure and carry out a high-end servicing and maintenance.

The presented concept basically is framed by the application of just one PDM system. Based on current project experiences, one should try to get to the bottom of the question if it is really reasonable to include all sites / business units into one and the same system, even if they run almost similar business. In some cases it might be more effective to allow different installations for different needs. In the later case, less negotiations, trade-offs, and synchronization is needed to come to an end. The "least common denominator" is a common data model, common classification of documents and parts, agreed core functionality within the PDM system, and agreed folder structures to store generated data item. Finally, the interface to the ERP system is of major relevance. Here it is requested to have a clear workflow for the transfer of the data from the PDM to the ERP system so that changes of design data do not get lost. This is vital in order to maintain a clear tracking of "as-maintained" configurations and to plan and control MRO manufacturing processes.

According to an expert consultation [START_REF]SIEMENS PLM Software[END_REF], the proportion and functionality of PLM will rise until 2020 not only for management of virtual products but also for the management of real, installed systems over the lifecycle. The approach presented in this paper is in line with this expert vision.

Figure 1

 1 Figure 1 illustrates the product lifecycle of a steam turbine and shows the bandwidth of PDM usage.

Fig. 1 .

 1 Fig. 1. Simplified Product Lifecycle of a Steam Turbine

Fig. 2 .

 2 Fig. 2. Generation of Product and Service Data over the Steam Turbine Lifecycle

Fig. 3 .Fig. 4 .

 34 Fig. 3. Framework for the new PLM Process Concept

Fig. 5 .Fig. 6 .

 56 Fig. 5. New Concept to store Engineering Data and Documents in the PDM System (Part 1)


Thorsten Wuest

Karl Hribernik

Klaus-Dieter Thoben

Can a Product Have a Facebook? A New Perspective on Product Avatars in Product Lifecycle Management

Keywords: Social networks, Facebook, PLM, Product Avatar, production, Internet of Things, product state, data management

In today's business environment, customer expectation towards product lifecycle information accessibility and quality is rising. Concepts such as the Internet of Things (IoT) respond to these demands enabling products becoming "intelligent" and capable of interaction. Simultaneously, society is changing with people spending more and more time online. Social networks allow them to interact richly with both their personal and professional contacts. Users of social network share information about their lives with a wide network of people who can respond directly. Being the most widely used social network Facebook's functionality and usability have continuously evolved, culminating in the introduction of the timeline. The timeline is a representation of the users' entire life, de facto managing the user's "lifecycle" information. Considering the above developments, the question arises, whether it is feasible for a product to have a Facebook which acts as its product avatar, and whether that would contribute towards fulfilling the increasing customer demands towards product lifecycle information accessibility and quality?

Introduction

In today's global business environment, almost every company faces the challenges regarding increasing complexity and market turbulence [START_REF] Mason | The external environment's effect on management and strategy -A complexity theory approach[END_REF]. Today's customers expect physical products and related information of the highest quality. New developments, such as Web 2.0 or the Internet of Things (IoT), on the one hand offer good opportunities, but on the other add to the complexity, e.g. through new options, risks [START_REF] Shapiro | Strategic Planning: Now More Important Than Ever[END_REF] and turbulence, alongside rapid unexpected change [START_REF] Mason | The external environment's effect on management and strategy -A complexity theory approach[END_REF].

Products are becoming increasingly intelligent and are to some extent already able to interact with each other and users and even to take their own decisions [START_REF] Isenberg | The Role of the Internet of Things for Increased Autonomy and Agility in Collaborative Production Environments[END_REF]. At the same time, social networks such as Facebook, designed to support users in every aspect of their lives [START_REF] Null | How to Live Your Entire Life Through Facebook[END_REF] are becoming increasingly prominent on the Internet. These Web 2.0 services are furthermore characterised by their evolutionary, user-centric innovation and development of functionality and usability. These physical and virtual worlds are converging, with products are already using communication services like Twitter [START_REF] Hribernik | Co-creating the Internet of Things -First experience in the participatory design of Intelligent Products with Arduino[END_REF]. Complimenting these developments, concepts such as product avatars [START_REF] Hribernik | The product avatar as a productinstance-centric information management concept[END_REF] have already put forward the idea of digital counterparts for products enabling stakeholders to benefit from value-added services built on product lifecycle information generated by Intelligent Products.

In the light of these developments, questions arise regarding the feasibility and potential benefit of applying the evolving information infrastructures of social networks such as Facebook to meet challenges regarding product lifecycle information accessibility and quality. Can social networks functionalities such as Facebook timeline be applied to facilitate suitable product avatars towards owners and other stakeholders throughout the entire product lifecycle?

Intelligent products and their lifecycles

The following sections elaborate on the basic information management concepts which underpin the investigation Facebook functionality put forward in this paper: item-level PLM, IoT, and Product Avatars.

Internet of Things

The concept of the Internet of Things extrapolates the idea of the Internet -a global, interconnected network of computers -to describe a network of interconnected things such as everyday objects [START_REF] Mattern | From the Internet of Computers to the Internet of Things, 242 -259[END_REF], products, and objects in the surrounding environments [START_REF] Hribernik | Co-creating the Internet of Things -First experience in the participatory design of Intelligent Products with Arduino[END_REF]. It is a networked system of self-organizing objects which interact autonomously with each other and with related processes, leading to an expected convergence of physical things with the virtual world of the Internet. The IoT was first mentioned in 1999 [START_REF] Brand | Internet der Dinge -Perspektiven für die Logisitk[END_REF], but has been given new impetus with the availability of increasingly affordable sensors, actuators, embedded systems and computers. The economic sustainability is a key factor in the industrial take-up of IoT concepts by practitioners.

At the heart of the concept lies the idea that objects -things -are capable of information processing, communication with each other and with their environment, and autonomous decision taking and thus -become "intelligent" [3;6;8]. This ties in with the related concept of Intelligent Products, of which a well accepted definition is: "...a physical and information based representation of an item [...] which possesses a unique identification, is capable of communicating effectively with its environment, can retain or store data about itself, deploys a language to display its features, production requirements, etc., and is capable of participating in or making decisions relevant to its own destiny." [START_REF] Mcfarlane | Auto ID systems and intelligent manufacturing control[END_REF] An Intelligent Product is therefore not just the product itself but also its enabling information infrastructure. Up to now, Intelligent Products are not "socially intelligent" [START_REF] Erickson | Social systems: designing digital systems that support social intelligence[END_REF] in terms that they can create their own infrastructure to communicate, store information and interact with human users. But when an advanced information infrastructure designed by socially intelligent users is available, an Intelligent Product can make of it and therefore enhance information quality and accessibility for human users.

Product Lifecycle Management

Every product has a lifecycle. Manufacturers are increasingly becoming aware of the benefits inherent in managing those lifecycles [START_REF] Sendler | Das PLM-Kompendium. Referenzbuch des Produkt-Lebenszyklus-Managements[END_REF]. Today's products are becoming increasingly complicated. For example, the amount of component parts is increasing. Simultaneously, development, manufacturing and usage cycles are accelerating [START_REF] Sendler | Das PLM-Kompendium. Referenzbuch des Produkt-Lebenszyklus-Managements[END_REF] and production is being distributed geographically [START_REF] Seifert | Collaboration Formation in Virtual Organisations by applying prospective Performance Measurement[END_REF]. These trends highlight the need for innovative concepts for structuring and handling product related information efficiently throughout the entire lifecycle. On top that, customer demand for more customisation and variation stresses the need for a PLM at item and not merely type-level. PLM expands on the concept of Product Data Management (PDM) to include information generated and used beyond design and manufacturing [15;16]. Besides merely handling product and process related data, PLM also has to take into account the interdependencies of information and communication between all of the stakeholders involved in the product lifecycle.

Common graphical representations of the product lifecycle encompass three phases -begin of life, middle of life and end of life -arranged either in a circle or a straight line (see Fig. 1). The linear form represents the product lifecycle "from the cradle to the grave" whilst the circular form stresses PLM "from cradle to cradle" with a focus on recycling, refurbishing and reuse: the final phase feeds back into the first.

The social web offers a number of opportunities for item-level PLM. For example, Web 2.0-based product information acquisition could contribute to the improvement of the quality of future products [17;18]. One approach to representing the complex information flows connected to an individual product is the Product Avatar. This concept describes a digital counterpart of the physical Intelligent Product which exposes functionality and information to stakeholders of the product's lifecycle via a user interface [START_REF] Hribernik | The product avatar as a productinstance-centric information management concept[END_REF].

Over the last years, with the development of Web 2.0, social networks became a central and unavoidable medium for social interaction worldwide [START_REF] Gosling | Manifestations of Personality in Online Social Networks: Self-Reported Facebook-Related Behaviors and Observable Profile Information[END_REF]. In a recent study of German users and their time spent online social networks were far ahead with 23% in Dec. 2011 coming from 14% in Dec. 2010 [START_REF] Arns | Presseinformation -Internetnutzer verbringen die meiste Zeit in Sozialen Netzwerken[END_REF]. In other countries, like the United States of America the ratio is even more extreme [22;23]. Facebook, founded in 2004 as a social networking platform strictly limited to students from Harvard University, opened their user base step by step to all users globally. After passing myspace in 2008 in terms of active users, Facebook today has 845 million monthly active users and is recognized as the largest and most powerful social networking site worldwide [24;25].

Facebook's presentation and usability changed over time, introducing both evolutionary and revolutionary new services. The innovation impulses for many of these changes came directly from the user community. [START_REF] Ferebee | The Innovation Architectures of Facebook[END_REF] From being a mostly static way of presenting information of oneself it became a holistic platform where users can find almost everything from office tools over video conferencing [4;27] to news reading, with users claiming to find the presented sources more credible than automated reading suggestions and more relevant for the personal taste [24;28].

The newest development within Facebook is the timeline, introduced in Sept. 2011, becoming obligatory for all Facebook users in Feb. 2012. The timeline is a complete rewiring of the way Facebook works [START_REF] Townsend | This Is Your Life (According to Your New Timeline)[END_REF]. Facebook's vision of becoming the gateway to the Internet or passport for users' online identity [START_REF] Null | How to Live Your Entire Life Through Facebook[END_REF] made a big step forward. Facebook intends to gather all information of a person over the person's whole life even before Facebook existed. New functions like location based services help to generate accurate information/data [START_REF] Mulvihill | 10 Things to Know About Location-Based Services[END_REF] and help Facebook positioning itself as a personal archive. This archive is not just searchable, maintained and data-driven [START_REF] Townsend | This Is Your Life (According to Your New Timeline)[END_REF] but also always available on smartphones, computers and dynamically connected to other archives of users through "friendship" or "subscription" [START_REF] Ugander | The Anatomy of the Facebook Social Graph[END_REF].

With the introduction of Facebook's like button, and apps/cookies to be implemented in the design of websites outside of the social network environment, Facebook, in an extreme case, has the opportunity to gather data of the whole online experience of a user and connecting it with the information/data of the personal profile. This then automatic and passively collection of data completes the already actively provided content and allows Facebook to make it accessible on the user's online profile. Theoretically, the user's online profile could become richer and more complete than its offline one with information about everything, from favourite music to recently bought groceries on Amazon [START_REF] Townsend | This Is Your Life (According to Your New Timeline)[END_REF].

As Facebook develops very fast supported by a huge user community, maybe it is possible to take advantage of (social) functionalities to manage information and relationships and thus learn from processes formed by the social requirements of human users shaping Facebook services and functionalities for Intelligent Products.

In this section, first today's usage of Facebook for business purposes will be elaborated on followed by a presentation of how Facebook and its functionalities could be a promising approach to represent a product and its connected information/data as well as interdependencies as an intelligent product avatar over the whole product lifecycle.

Facebook and business

With Facebook's extremely fast growth, business is trying to benefit from the newly available opportunities. Besides on-line advertising, Facebook's main source of income, external businesses try to make use of the huge user and/or potential customer base. The huge, multi-cultural data base of Facebook users is deployed for market and increasingly academic research in different fields, ranging from business studies to psychology [20;23]. New approaches in innovation, like customer cocreation [START_REF] Rohrbeck | Sourcing innovation from your customer: how multinational enterprises use Web platforms for virtual customer integration[END_REF][START_REF] Cordrino | PLM in the age of Facebook[END_REF], or research in decision making [START_REF] Takac | The social embeddedness of decision making: opportunities and challenges[END_REF] also make use of the vast opportunities to interact with specific target groups incl. available embedded data.

The first applications of companies interacting with customers on Facebook were in the domain of involved user-centric marketing and customer relationship management. Facebook provided the possibility to set up a "fan page" of the company itself or their products. These "fan pages" could contain product information, pictures/videos, marketing events and easily and constantly accessible product support through the Facebook "wall". Users can indicate their interest in one of these "fan pages" through the "like" button functionality and thus subscribe to updates, special deals etc. and gain access to a fast an transparent communication channel with companies representatives. Taking a product "fan page", e.g. the iPhone, today it has mostly a representative and marketing functionality. The "fan page" does not represent a single iPhone, it is a product representation people interested can get general information, support or just show their network that they are fascinated by it.

The whole potential of Facebook in communication and interaction as well as information/data gathering, organization and accessibility are not yet used. But as in the age of IoT and PLM products become intelligent and customers demand individualized information of the product that might be not enough. In the following, the idea of an individual product having a Facebook profile not a fan page with all socially embedded functionality will be proposed and elaborated in more detail.

Facebook functions interpreted from a product avatar perspective

One question comes to mind is, why do "fan pages" (products) and "profiles" (users) have different functionalities and design? A profile of a person using Facebook contains a lot of more possibilities to provide information about the individual, options to indicate connections to other profiles and additionally communication services. Should a product also have these possibilities and could it make use of them? As was claimed before, products become more intelligent, the requirements towards an information infrastructure for a products digital representation are increasing. Treating a product like a person and to give it a "real" Facebook profile (see Fig. 2) instead of a simple "fan page" could provide just that: an advanced information infrastructure tested by millions of socially intelligent users.

Clustering of friends in groups: e.g. family:

identical part: sibling similar part: cousin

Possible functions of relationship status:

-In a relationship to: connected -Married: constantly connected -It's complicated: connection with problems ( e.g. predetermined breaking point)

Fig. 2. Example of Facebook page for an Intelligent Product

In Tab.1 an exemplary collection of selected functionalities, the possible usage within a product lifecycle perspective and the benefit for stakeholders are presented.

Table 1: interpretation of Facebook functionalities an possible benefit

Facebook function

Interpretation as PLM function

Possible application and benefit/impact check-in

Location based services Applications ranging from Supply Chain (SCM) and Stock Management to Tracking and Tracing (T&T) status Documentation of product state [START_REF] Wuest | State of steel product in industrial production processes[END_REF] Wide range of applications. For SCM and logistics, status updates can be mapped to T&T with LBS to present the status of a product in production, distribution and reverse logistics scenarios. Different views upon product state can be controlled via rights management. friends Map connections between the products and product lifecycle stakeholders.

For example, a service technician can be "friends" with a product so he will receive updates to its status.

Facebook function

Interpretation as PLM function

Possible application and benefit/impact groups Organisation and structuring of product and component part information.

Organisation of products, component parts and the related information into subsets. Friends can be organized into groups such as "assembly group", "accounts", "service technician".

For example, all parts of an engine could be "friends" in an "engine" group. timeline Representation of the product lifecycle over time with accentuation of important events [START_REF] Townsend | This Is Your Life (According to Your New Timeline)[END_REF] Can store all events related to the product throughout its entire lifecycle: from production, relocation, allocation to new assembly groups, repairs, ownership changes etc. Can be updated in real time and annotated with meta-data using the comment function.

Can provide a history of product status throughout the lifecycle. "like" button Documentation of acknowledgement/approval of lifecycle events by stakeholders Lifecycle stakeholder can quickly and easily document approval of a certain actions, useful e.g. for quality gate reviews, delivery receipt substitutions in combination with check-in. relationship status

Indication of degree of physical connection between products and component parts

Defines the type of physical connection, e.g.: (see Fig. Provides a structured collection of individual manufacturing data (e.g. processes parameters) which can be used to track the entire manufacturing process. Useful in safety-critical industries (e.g. aerospace, pharmaceuticals) or in combating plagiarism. comment Annotation of any kind of interaction and information with meta-data.

Every event can be annotated with meta-information by commenting. E.g. in case a product is "in a relationship" with another product the provider of grease gets a notification (targeted audience) and suggests the corresponding lubricant for this suitable for this event. profile picture Graphical representation of the product, e.g. a photo or design.

Product picture can be updated after every modification. Can be used e.g. for monitoring the state of a product. photo album Additional graphical or textual information Can be used to provide e.g. a dynamic online user manual or certificates for the product. privacy settings Rights management.

Through privacy settings in combination with the group functions, addressees of information can be specifically targeted (e.g. service technician, owner etc.)

To give a more graphical example of possible interpretations of Facebook lingo, Fig. 3 highlights the idea of using Facebook family ties to express the connection a product has based on its manufacturer and/or product properties. sister: "product C is from the same manufacturer as product D but not identical"

Fig. 3. Possible interpretation of family ties (available Facebook options) for products

In this section the different functions have been presented with a short interpretation and possible benefits from a product lifecycle point of view, but without concrete examples. However, examples of real-life industrial application are crucial to understanding. Thus, in the following section a, still selective, example of an intelligent product (a boat) is presented and selected situations are chosen to be represented by means of Facebook functionalities as a product avatar over the whole product lifecycle.

Exemplary Facebook product avatar of a leisure boat life cycle

Leisure boat builders are increasingly realising the need to emphasize both the after-sales market and their customers' demands for products that are easy in upkeep, environmentally friendly and which offer them added-value services to enhance their boating experience. In order to fulfil these requirements, they need to take concepts such as item-level PLM, Intelligent Products and Product Avatars into consideration. In an initial, non-representative survey, five main areas of potential improvement were defined by industry representatives. As a boat is a very complex product with various parts put together from different manufacturers and ventures plus a high proportion of customization (e.g. interior design etc.), boats are very individual. So the possibility to manage the huge amount of variations and keep all information and records up-to-date would be a huge advantage for manufacturers and customers.

In Fig. 4 these areas of improvement are roughly positioned within the phases of the Product Lifecycle. They are then each mapped to a possible Facebook functionality in the bottom part of Fig. 4. an up-to-date status during manufacturing , usage and customer relevant end-of-life provides customers with all necessary information (adjustable in granularity through Facebook's internal prioritizing algorithms) 3. photo albums with photo of the boat and "tags" of individual parts (represented as friends), e.g. engine or tv, with specific information. Thus each part (even after exchange) has an up-to-date manual as a photo album 4. product avatar in Facebook, the boat is directly registered through name and customer has direct benefit of it 5. selected privacy settings and an algorithm information like e.g. location in summer 2012 can be tracked through Google maps

Conclusion and outlook

The possibility of a Product Avatar representation of product lifecycle information of an Intelligent Product have been described in more detail after elaborating on the development of the social network Facebook and the its various functionalities for private and business use. The theoretical concept illustrates selected practical examples of the life cycle of a boat interpreted with Facebook functionalities in the following section.

To conclude, the approach presented to apply the developments of Facebook and its user-driven, constantly evolving information infrastructure to the Product Avatar of an Intelligent Product currently seems feasible and promising.

Fig. 1 .

 1 Fig.1. Variations of the representation of product life cycles (based on[13;14]

  owner of the product with history of ownership for each part. education Documentation of the manufacturing history of individual products

  product A is identical to product B but from different manufacturer"

1 .

 1 Unique and continuous "boat number", service history, traceability (change history) of all components 1. (boat number) either name of Facebook groups (e.g. boat no. xxx) or an individual profile for the complete boat with no. xxx as part of the name. (service history) all needed data and information is collected in the timeline of the boat, and in more detail in the timeline of the specific part in focus. (traceability) also in through the timeline, e.g. change of component is shown as a change of friends with location, time and tagged service technician 2.

Fig. 4 .

 4 Fig. 4. Transformation of selected events during the product lifecycle into Facebook

Acknowledgement

This work has been partly funded by the European Commission through Project BOMA: Boat Management under FP7 "SME-2011-1 Research for SMEs". The authors acknowledge the support of the Commission and all BOMA project partners.


Nathan Hartman
email: nhartman@purdue.edu

Phil Rosche
email: prosche@icfi.com

Kevin Fischer
email: klfische@rockwellcollins.com

A Framework for Evaluating Collaborative Product Representations in Product Lifecycle Workflows

Keywords: product lifecycle management, model-based enterprise, model-based definition, neutral file formats, workflows, standards 1

Product definition technology has evolved in such a way as to encourage the proliferation of data formats used within the product lifecycle for various use cases. One such product development framework being proposed in industry today is the model-based enterprise (MBE), which is operationally driven by the model-based definition (MBD) of products. This paper describes current models of the product development process and the nature of collaborative data. This paper will also suggest a framework for evaluating various collaborative product representations. The nature of the data formats chosen for use in specific workflows have a substantial effect on the ability of users to consume data and the ability for an organization to capture and archive its critical information.

Introduction

The modern product realization environment, and the accompanying product lifecycle, has expanded in such a fashion that the global design, production, distribution, and support of a product is commonplace. Technologies and techniques, such as crowd sourcing, mobile devices, and social networks, have led to new ways that people communicate product design information. The notion of collaborative design and development activities have become commonplace due to the evolution of computing and communications technology and the globalization of productproducing companies [START_REF] Hartman | Examining neutral formats for visualization and data exchange[END_REF][START_REF] Sun | Workflow-driven collaborative session management in product lifecycle management via Internet[END_REF]. In an effort to effectively do business within this environment, companies have turned to using 3D Computer Aided Design (CAD)-based product representations as the basis for their communication [START_REF] Quintana | Re-engineering the Engineering Change Management process for a drawing-less environment[END_REF][START_REF] Hartman | Examining neutral formats for visualization and data exchange[END_REF]. In doing so, engineers are able to capture product definitions with a higher degree of fidelity and a reduced risk of error based on interpretation of design intent. However, it is not to say that the use of 3D models is not without risk. According to an Aberdeen study [START_REF] Boucher | Working with multi-CAD: Overcome the engineering collaboration bottleneck[END_REF], 269 companies were surveyed, and 84% of them reported using three or more CAD tools in their design process. Forty-two percent of the respondents reported using five or more CAD systems. Why all of the variety? The number one reason cited by respondents was that product development is not done in isolation -they needed to collaborate with other people in other organizations who ultimately used different tools and processes. As different digital product representation capabilities have developed within modern CAD authoring software, they can be classified as data models, data formats, and data wrappers (or packaging). This paper will provide a discussion of the nuances of using these different product representations in the product development processes, and a framework for evaluating these digital product representations in typical product lifecycle workflows.

With the proliferation of CAD software, and the ongoing incompatibilities between native CAD tools, the communication process between participants in the product lifecycle can be treacherous. Collaboration between people can take many forms and can use many different types of data and information formats. In the collaborative product design and PLM spaces, this data will typically take one of three forms relative to the aforementioned use of CAD-based product definitions to enable communication between members of a team: native files, neutral files, or lightweight files. Native files are those created and stored in the format of the CAD authoring tool (e.g., CAD, PDM, spreadsheet, word processing, presentation, logistics, etc.) Neutral formats are broadly interpretable file formats that can be used between different applications (e.g., STEP, IGES, DXF, etc.). Lightweight Collaboration formats are typically 3D formats derived from the native or neutral CAD model, which do not contain as much data as a native format or some neutral formats (e.g., JT, 3D PDF, 3Dxml, etc.).

According to Sun et. al. [START_REF] Sun | Workflow-driven collaborative session management in product lifecycle management via Internet[END_REF], the globalization of the modern manufacturing industry has lead to the need for tools that capture, represent, and exchange product development knowledge. The notion of the collaborative design process has emerged to support distributed and collaborative product development work teams, with suppliers and OEMs more tightly integrated. Current product development processes often include distributed workflows, complicated electronic interactions, and focused collaboration among the people involved. Historically, detail and assembly drawings were used to support these processes -they contained all of the necessary information to define, manufacture, and inspect the product [START_REF] Quintana | Re-engineering the Engineering Change Management process for a drawing-less environment[END_REF][START_REF] Quintana | Will model-based definition replace engineering drawings throughout the product lifecycle? A global perspective from aerospace industry[END_REF][START_REF] Versprille | Model-based Definition for the Masses[END_REF]. However, drawings are also cumbersome in that they allow for ambiguity and incorrect interpretation of design intent, which can undermine the effectiveness of digital product definitions and collaborative design teams. Drawings also do not have the ability to provide robust derivations based on the background and technical literacy of the person viewing them, whereas model-based product definitions can be dynamically re-purposed based on the consumer of the data.

Another factor influencing the collaborative product development process is the nature of the digital environments themselves. Managing product data across continents using web-based computing architectures that must include appropriate security protocols is not a trivial matter. The design author produces a CAD model, rich with information. Yet that model is only consumable by a small portion of the organization in that form. However, due to corporate culture, regulatory compliance, and a number of other factors, most others in the organization are prohibited in their ability to modify this model. Moreover, their lack of technical ability and proper training will likely impede their ability to use this form of the model.

As companies have difficulty in propagating the 'heavyweight' CAD model throughout the organization, the obvious need arises for a CAD-derivative format that is both dynamically manipulated and easily consumed. Hence the notion of making the model 'fit for purpose' by using alternate 3D formats to propagate data outside the native CAD software format. A fundamental requirement of a model-based product realization environment is that a fully-defined, fully-annotated 3D CAD model be the master source of product geometry definition. This allows for both human and machine consumption of model data within the larger collaboration framework. When people worked collaboratively in close physical proximity to each other, we trusted the data generated by them, because we trusted their personal judgment and expertise. In a global collaborative design and production environment, close physical proximity is not possible, thus requiring that we trust the process that generates the data as opposed to the person who generates the data.

Lightweight or collaboration formats were initially developed with visualization as the primary purpose. They could be used in a variety of scenarios such as design reviews, marketing, and product assembly on the shop floor. No special and expensive hardware or software was needed to view these formats. Over time these formats have evolved until they contain much more of the functionality found in native CAD system and have evolved for use by other scenarios such as manufacturing, coordinate measuring, and digital mock-up. As they have evolved, there has been extensive push from the user community for many of these formats to become recognized standards.

The Product Development Process and the Digital Enterprise

It is important to consider the system development process in concert with the collaborative product development environment. The concept of the V-model has emerged over the last three decades. It was introduced to simplify the complexity associated with system development. The V-model is applied across many industries to define a consistent approach to system design and product development. It begins with increasing degrees of product definition (concept to architecture to detail design) that leads to implementation (manufacture). From there the process traverses through component integration, test and verification and then system level integration, test and verification. Finally, culminating in the operation and fielding of a system that has been fully verified and validated against its defining requirements. But, how does model based collaboration and interoperability support and affect the V-model for complex system development shown in Figure 1 [7]? The Digital Enterprise represents the evolution of processes through the use of digital models and information. There is the business information view (resources, finance, program management, etc.) as well as the technical view (design, manufacture, sustainability, etc.) of the digital enterprise. In the technical view, the Model Based Enterprise (MBE) includes the concept that shared digital product data is available, in a form that is accurate and appropriate, when and where it is needed. The ability to create data once and use it throughout the lifecycle, without the need to re-master data, is a key to the MBE.

Product models are transformed as the definition progresses throughout the product lifecyclefrom concept to disposal. Within the model-based enterprise there are several important concepts. There is the Systems Engineering layer with information that spans the entire product life cycle. As the product model definition progresses through the stages of model based engineering, manufacturing, and sustainability, it is transformed from concept to retirement through these stages and is represented by product, process, and information models, as well as the collaborative visualization models. A robust MBE is inherently dependent upon the ease of data transformation, which is significantly improved through the collaborative capabilities of the modeling tools used to create the data and the standards used for data exchange. Appropriate application of the standards ensures that data flows seamlessly throughout the lifecycle and enables re-use of the data in formats that are most appropriate for collaboration and visualization throughout the lifecycle. Usually the original model format is not conducive to the collaborative use case and often a lightweight visualization is more beneficial. Obviously the richest data format among the three we are examining here are the native CAD files. They have evolved over the past 30 years and are quite robust in nature. However, the downside of using these files for collaboration is multifaceted:

• They are unreadable by other CAD systems (without direct translators)

• Depending on the system, they may not be readable from one major release to the next • If they are to be reused, they have to be "bumped up" or migrated on a regular basis from one release to the next • They are typically rather large from a file size standpoint Neutral files possess the greatest interoperability but obviously do not have the richness of the native CAD files. This is why the choice of which file format to use in a particular scenario is an important organizational decision. Lightweight collaboration formats have evolved as well and have become less "lightweight" as the functionality has increased. Another issue that has arisen as a result of this constant increase in functionality is that the collaboration formats need to be "bumped up" or migrated to later versions as the richness of the format is increased. In Figure 3 below, we compare the relative duration of time between when International Standards, Native CAD Formats, and Collaboration formats need to be migrated to later versions. International Standards change relatively slowly -for example there have been three versions of STEP Application Protocol (AP) 203 and AP 214 commercially implemented in the past 17 years. For native CAD systems, major releases occur on an almost annual basis. Collaboration formats change less often than native CAD formats, but more often than international standards or neutral formats. Over a product's lifecycle, the information used to represent it and control it goes through a number of transformations and is integrated with other data as well. Over the course of its lifecycle, a product could be represented as a hand sketch, a CAD model, a set of NC tool paths, a lightweight visualization model, a set of assembly instructions, or a technical data package for service and repair. By the time a product is retired, the number of representations of it and the associated documentation is immense.

The Nature of Collaborative Data

In order to support collaboration between dispersed members of product teams in various stages of the product lifecycle, the digital product definition must be deep and wide in terms of the "richness" of its data. In most instances this means there is a fully detailed CAD model to support the communications process; however, it also means much more than that. The digital product definition also includes non-geometric metadata that is carried by the CAD file. The digital product definition must be dynamic and able to be reconfigured as necessary based on the needs of the consumer of the data. The CAD-derivative formats must also retain a high level of fidelity to the original CAD file (both geometric and non-geometric data) in order to be used successfully. High degrees of fidelity are particularly important in industry sectors (e.g., aerospace and defense, automotive, or pharmaceuticals) where regulatory compliance is necessary -not only for collaboration, but for archival purposes as well. The structure of the collaborative data must also be compact and stable with an ability to move across corporate networks easily, reliably, and securely, In a model-based enterprise it is important that the digital product definition maintains stability, especially as the product definition evolves and transforms throughout the lifecycle. In order for the digital definition to fulfill the expectations of the system development (V-model) process, there must be a continuity of intent, whether the model is transformed for concept, physical/functional allocation, detailed design, collaborative visualization, analysis, manufacturing, service, support, or archival in the development lifecycle. No longer are concept, detail design, manufacture, test, service and support performed in a single location, nor are they typically done by a single corporation. The nature of today's supply chain is that of a supply network, and it is a driving component of the business environment and the world economy.

There is a need to be able to collaborate across the different roles within the corporate organization and across the supply chain with other involved actors, all with a level of product representation fidelity that is acceptable for the actor in their role in the organization. When collaborating, the information needs to be of the appropriate richness, size, and most often contain only the intellectual property necessary to complete the particular use case.

Today's product development environment is highly collaborative and global. Figure 4 shows the typical stages in a product lifecycle. It is absolutely essential that information be shared by many different actors, in many different locations, and often simultaneously. Frequently, the information needed for different use cases requires product representations with significantly different formats or varying degrees of richness. The more we are able to create model data once and transform it seamlessly for other uses, and the less we re-master for different purposes, the more stable our product definition remains. With stability, companies can maintain efficiency, consistency, quality, and usefulness of the original design intent. To support this paradigm of model data re-use, it is typically necessary to use derivative model representations as not everyone in the product lifecycle needs the full mathematical definition provided by the native CAD model. For the purpose of this paper, instead of discussing workflows that tend to be popular among the user communities such as Detailed Design, Design Collaboration, and Product Manufacturing, we focused efforts on workflows not normally considered such as Requirements Capture, Product Definition and Development, Field Support, and Data Archival. For the purposes of our workflows, we considered what inputs typically are required, what primary process they are driving, and what downstream process is being fed by the information. In light of this process, a framework for evaluating product representations was developed, with specific criteria to guide the review. The criteria in Table 2 need to be applied in the context of intended inputs and outcomes by the authors and consumers of the data in each respective workflow.

For Requirements Capture, inputs are typically Business Strategy, Customer Requirements, information that has been gleaned by Marketing, and new Technology that has been recently developed or is in the process of being developed. The inputs for Requirements Capture come in a variety of formats such as word processing documents, spread sheets, and CAD models. This information goes to the Systems Engineering organization and is used for defining system requirements, and validating initial requirements. The information generated by the Systems Engineering organization is fed to Conceptual Design.

For proposal development, input data is provided by the Design Engineering, Manufacturing Engineering, Finance, and Marketing organizations. The information they provide is in a variety of formats, including derivative data formats, word processing documents, and spread sheets. This data is provided to the Program Office. They in turn use the information for the development of proposals, pursuit and order capture, and early or initial requirements validation. The output of this is a proposal to the customer.

In the product definition workflow, input data is provided by program management, systems engineering, manufacturing, customers, as well as several other entities. The information they provide is typically contained in text-based documents, requirements document, systems modeling language, or geometric representations in the form of previous designs. Inside design engineering, activities include concept design, trade studies, detail design, and analysis. The focus on interoperability between authoring systems both within functions and between functions (MCAD-to-MCAD, MCAD-to-CAE, MCAD-to-ECAD, etc.) requires the use of a flexible product representation. The output of this process is a data set that can be consumed readily by In Supply Chain Integration input data from the Design Engineering, Quality, Manufacturing, and Program Management organizations is provided to Materials Management. This information typically takes the form of neutral files, native CAD files, derivative data formats, word processing documents, spread sheets, and "electronic" schedules. The Materials Management organization uses this information to perform make/buy decisions, decide on the level of collaboration with suppliers, and perform procurement. The outputs from the Materials Management organization take a number of forms, such as requests for information, requests for proposal, and contracts and purchase orders.

For Field Support, the Engineering and Manufacturing organizations and the customer provide the data to the Field Support organization. The information is provided in a number of formats such as derivative data formats, native CAD models, word processing documents, and spread sheets. The Field Support organization uses this information to create technical publications, provide logistics support, make decisions for provisioning, and analyzing field data for future decisions. Much of the output of the Field Support function goes to the Service Centers where the products are maintained and updated.

For Data Archival, Design Engineering, Manufacturing, and Information Management all provide input to the Data Control organization. This information is in a variety of formats including native CAD models, derivate data formats, NC tool path data, PLM/PDM information in both neutral and native formats, various document formats, spread sheets, and databases. The Data Control organization performs change management; they convert and validate the data, and finally archive the data. Nearly constant data migration is also performed depending on the information format.

Summary

One of the fundamental tenets of product lifecycle management and a model-based enterprise is the movement of information throughout the enterprise in a way than enables effective decision making through the use of a high-fidelity digital product representation. In order for the various stages of the product lifecycle shown in Figure 4 to be effective, they must have proper inputs and outputs that retain the integrity of the digital product definition. The nature of the digital product definition is more than just a CAD model, more than just geometry. It includes nongeometric attributes that drive downstream processes because they are made fit for machine consumption rather than human consumption. Machine-to-machine communication is necessary in many facets of the product lifecycle as a human in the loop can be too slow and (potentially) inaccurate. Yet, a fully-integrated product lifecycle only works if the geometric and nongeometric definitions of the product remain intact during translation and the dynamic repurposing of the model-based product definition. It is critical that the authors and consumers in the lifecycle conduct due diligence to evaluate specific product representations within each workflow. Using the criteria mentioned in Table 2 will aid organizations in selecting an appropriate product representation.

The product lifecycle and its accompanying processes and workflows have become increasingly complex as the use of digital data has continued to supplant paper-based processes. The authoring tools used to create such data (e.g., CAD systems, spreadsheet tools, analysis tools, visualization platforms, etc.) write their output in proprietary formats which vary across the product lifecycle based on the specific workflow and the consumer characteristics involved. Too often companies find themselves in the predicament of choosing between various product representations -native (proprietary) and derivative -when the decision is not really a choice, but a selection of complementary technologies. The use of particular product representations does not (and should not) need to be mutually exclusive.

The product representations used across the lifecycle will vary with respect to the desired functionality at each stage. The exclusive use of one class of representation over another can limit flexibility. Use of native CAD formats in the design or analysis stage of the lifecycle is likely; however, the use of those same types of files in the purchasing or technical publications stages of the lifecycle simply do not make sense. A native file would be too large in size, have too much detail, and would likely not be able to be opened by the tools that people in those positions would use. Derivative data formats can promote high fidelity communications between design and manufacturing or design and supply chain, but tend to be too large in size for publications and are usually not editable enough to be dynamically culled for levels of detail if the neutral file was not saved with an appropriate level of detail for a specific stage in the lifecycle. A lightweight collaborative file could be used for mobile applications, obtaining supplier quotes, or publications, but likely not for machining in a CNC application. Combining native, neutral and collaborative formats provide a richer solution across organizations and the lifecycle. The key to this selection process is the application of the selection criteria for each product representation based on the inputs and outputs of the respective workflows.

Figure 1 :

 1 Figure 1: V-model for Complex System Development

Figure 2 :

 2 Figure 2: Elements of a Model-based Enterprise Table 1 establishes the link between the Digital Enterprise pyramid and the Product Development V-diagram. Depending on where you are in an organization, and the type of organization you are in, there are other items involved in addition to the typical product lifecycle stages. Each actor has different collaborative, visualization and information needs in the development lifecycle. Business Portfolio Management is often maintained at a corporate or executive level within the organization. The Management Authorization Process is typically the responsibility of the program office (lower-level VP and directors). While the Product Data Lifecycle Stages (for reference from our outline) are usually directed by engineering managers, department managers, etc. Throughout all, as the product matures across the lifecycle, there exists the need to transform models and collaboratively share information for specific use cases.

Figure 3 :

 3 Figure 3: The Progression of Product Data Formats

Figure 4 :

 4 Figure 4: Typical Stages of Product Lifecycle 4 Evaluation Framework for Collaborative Product RepresentationsTo address the variety of authors and consumers of data within the collaborative product lifecycle, four different types of product representations have evolved: native representations, derivative data models, derivative data formats, and derivative data packaging. In contemporary terms, this means technologies like STEP (data model), JT or 3DXML (format), or 3D PDF (package) that have been used as solutions for the challenges presented by various lifecycle workflows and the different data needs of consumers within the lifecycle. It is important to note that any specific strengths or weaknesses presented by a specific product representation are more often the result of the selection of that technology for a particular workflow than it is a specific technical deficiency. It has become common practice to use certain product representations in a manner inconsistent with its original development objectives. To address this issue, it is important to have a framework for evaluating the use and application of specific product representations.

Table 1 : The Link between the Digital Enterprise and Product Development

 1

	Business Portfolio Management	Program Management Authorization Process	Product Data Lifecycle Stages	Use cases
	Strategic/financial	Validate options/trade-offs	Product specification	Concept/requirements
	plan			capture
	Pursuit/Order capture Develop proposal & plan	Marketing	Proposal development
	Design &	Full-scale development	Design; Analysis	Design for X
	Development
	Manufacturing	Manufacturing/Production	Manufacturing/Supply	Quality; Supply chain;
				Mfg.
	Support & Service	Field Support; Stop	Product support; Tech	Tech pubs; field
		production	pubs; TDPs	support
		Stop field support	Long-term Archival &	Data archival; disposal
			Retention

Table 2 : Evaluation Framework for Product Representation Selection

 2

	Native format	Derivative data	Derivative data	Derivative data
		model	format	package
	(Authoring
	system)	(STEP)	(JT or 3DXML)	(3D PDF)

Needs Requirements Functional Allocation HW/SW Design Model Analysis Models Manufacturing Models Service/MRO Physical Allocation LOTAR