Marja Lintala
email: marja.lintala@kit.edu

Pierre Bonnal

Uniting Lifecycle Informationfrom Items to Assets, from Concepts to Practice

Keywords: Item, Asset, Product Lifecycle Management, Change Management, CERN

Many products have become more and more complex and tailormade. Consequently, product data is an extremely important factor to ensure the success and the sustainability of a product. Large and complex products, systems or facilities were managed in the past without the enhanced information technology systems available nowadays. Among some successful products or systems, one can cite space programs such as the NASA Apollo program or the particle accelerators built as from the 1950s such as that of CERN, Geneva, Switzerland, which serves as a case study for this paper. Some of the products developed in these eras are still in operation. Projects and practitioner approaches were developed and are still under development to address the problem of migrating data, produced with different technologies, to today's technologies. For instance, the ISO 10303 standard-also known as the STEP standard (Standard for the Exchange of Product Data)-provides the means to transfer CAD data between systems. But only little attention has been drawn to providing reliable means for integrating the information from different lifecycle phases together. This paper aims to draw attention to the issues raised by the use of different terminologies and systems in different lifecycle phases, in particular the concept of item during conception and development phase, and the concept of asset during that of operations and maintenance and some problems that this may bring.

Introduction

In our constantly changing world, even consumer products have become more and more complex and tailor-made. So it is no wonder that industrial products and systems are increasingly engineered. On the other hand, regulations such as laws, directives and standards are being constantly updated and are becoming stricter and more constraining. For example, in the European Union (EU) and European Economic Area (EEA), Machinery Directive 2006/EC/42 [1] valid as from December 2009 and the related standards dedicate more and more room to safety features. In this quickly evolving environment, product information management throughout the entire lifecycle has become an extremely important factor to ensure the success of a product.

Just a few decades ago, large and complex products, systems and facilities were conceived, developed, operated and maintained simply with paper archived in filing cabinets. With the advent of microcomputers, files and folders took over. Documents were managed manually and data exchange, in the modern sense, was the manual transportation of documents or later documents in a digital format such as floppy disks [START_REF]Berliner Kreis -Wissenschaftliches Forum für Produktentwicklung[END_REF]. Nowadays, information systems that embed word-processed and CAD data are widely used, especially when the products are complex. Information systems, such as those used in PLM (Product Lifecycle Management), are no longer only technically focused, but take into account the entire product lifecycle and enable the collaboration of various business units from development to service [START_REF]Berliner Kreis -Wissenschaftliches Forum für Produktentwicklung[END_REF].

In products with a long life, and with a great amount of history, information may have been produced with different technologies for different product lifecycle purposes. For instance, the Proton Synchrotron (PS) particle accelerator in CERN (European Organization for Nuclear Research, Geneva, Switzerland) built in the 1950s is fifty years later still a key component of CERN's accelerator complex. Operations and maintenance of scientific facilities such as that of the PS rely on information originating from various sources: paper documents in filing cabinets, some files still on microcomputers, but also documents in shared access on CERN's several electronic data and document management systems. The in-formation also relates to different lifecycle phases: 2D drawings, engineering specifications, design reports, manufacturing and assembly procedures and records prepared or released in the conception and development phase; and operations and maintenance documentation such as operations and maintenance manuals, procedures and control reports released in the operation and maintaining phase.

Methods for solving the problem of integrating information from different tools, for instance different CAD software, have gained attention over time. Standards such as the ISO 10303-also known as the STEP standard (Standard for the Exchange of Product Data) [START_REF]ISO 10303, Industrial automation systems and integration -Product data representation and exchange (ISO 10303)[END_REF]-have been developed. Approaches for product architectures, such as modular or integral architecture [START_REF] Ulrich | The role of product architecture in the manufacturing firm[END_REF], and for creating a customer demand adaptable product [START_REF] Maurer | Individualized Product Design by Evolutionary Algorithms[END_REF], also emerged. However, these methods concentrate on the design phase of the whole product lifecycle, and hence, adding product information from different lifecycle phases needs more attention. The aim of this paper is to draw attention on the issues that arise out of the use of different terminologies and also information systems in different lifecycle and some problems that this may bring.

Lifecycle Management

The importance of coherency and the integrity of data are widely recognized, because it avoids a loss of time. This 'loss of time' consists of searching and waiting for data, data translations, working with wrong data and recreating the existing knowledge as described in [START_REF] Ameri | Product lifecycle management: Closing the knowledge loops[END_REF]. The Product Lifecycle Management (PLM) approach addresses streamlining the product and related processes, and in-formation flows throughout the product's lifecycle [START_REF] Ameri | Product lifecycle management: Closing the knowledge loops[END_REF]. The aim of PLM is to pro-vide a continuous and transparent flow of digital information within the lifecycle [START_REF]Berliner Kreis -Wissenschaftliches Forum für Produktentwicklung[END_REF]. However, as it is pointed out in [START_REF] Ameri | Product lifecycle management: Closing the knowledge loops[END_REF], the underlying concept in PLM is knowledge management.

Knowledge is according to [START_REF] Aamodt | Different roles and mutual dependencies of data, information, and knowledge -An AI perspective on their integration[END_REF] 'learned information'. Information on the other hand is 'interpreted data' and data 'syntactic entities' [START_REF] Aamodt | Different roles and mutual dependencies of data, information, and knowledge -An AI perspective on their integration[END_REF]. The relationship between these three key concepts have been discussed in previous research, for in-stance in [START_REF] Aamodt | Different roles and mutual dependencies of data, information, and knowledge -An AI perspective on their integration[END_REF], [START_REF] Tuomi | Data is more than knowledge: implications of the reversed knowledge hierarchy for knowledge management and organizational memory[END_REF]. An extensive amount of research about information and knowledge management in the context of PLM is also available, for instance [START_REF] Ameri | Product lifecycle management: Closing the knowledge loops[END_REF], [START_REF] Terzi | Product lifecycle managementfrom its history to its new role[END_REF][START_REF] Garetti | Organisational change and knowledge management in PLM implementation[END_REF][START_REF] Abramovici | Future Trends in Product Lifecycle Management (PLM)[END_REF].

Tacit knowledge usually is subjective, cognitive and a result of experimental learning (knowledge that is still in the mind of the person) [START_REF] Ameri | Product lifecycle management: Closing the knowledge loops[END_REF] [START_REF] Gupta | Knowledge management: practices and challenges[END_REF]. While tacit knowledge is formed into explicit, knowledge becomes more objective, rational and technical knowledge, (knowledge, that can be relatively easily saved, processed and shared, and that is well documented and accessible) [START_REF] Ameri | Product lifecycle management: Closing the knowledge loops[END_REF], [START_REF] Gupta | Knowledge management: practices and challenges[END_REF]. In this phase technological solutions have an active role [START_REF] Ameri | Product lifecycle management: Closing the knowledge loops[END_REF].

The technological enablers for PLM are the different ICT tools used during the life of the product. Consequently, PLM can be described as multilayered and multisystem architecture [START_REF] Terzi | Product lifecycle managementfrom its history to its new role[END_REF]. From this ICT point-of-view, Garetti et al. [START_REF] Garetti | Organisational change and knowledge management in PLM implementation[END_REF] use 'connective tissue' to describe the role of PLM, for instance, the connection from design software to production and supply chain software in the extended enterprise [START_REF] Garetti | Organisational change and knowledge management in PLM implementation[END_REF]. The reason for this metaphor is that at the moment there is no comprehensive and well-accepted commercial PLM tool [START_REF] Terzi | Product lifecycle managementfrom its history to its new role[END_REF]. It is therefore appropriate to refer to PLM in ICT terms as a 'system of systems' [START_REF] Terzi | Product lifecycle managementfrom its history to its new role[END_REF]. Single systems are deficient without synthesis with other systems. In management sciences the system approach focuses on the whole, not on the separate parts, hence the relationships (interactions and compatibility) between the parts are important for the total sys-tem performance [START_REF] Ackoff | Towards a System of Systems Concepts[END_REF].

A philosophical view of PLM is to close the knowledge loops of the solutions enable creating, transforming and sharing the knowledge throughout the product lifecycle [START_REF] Ameri | Product lifecycle management: Closing the knowledge loops[END_REF]. In order to close the knowledge loops, the interactions and compatibility of the IT solutions, integrations are needed. Integration of different software solutions such as CAD (Computer Aided Design), PDM (Product Data Management), ERP (Enterprise Resource Planning), and CRM (Customer Relationship Management) started some years ago [START_REF] Garetti | Organisational change and knowledge management in PLM implementation[END_REF]. The integration of the different software solutions is important in ensuring the information flow without any gaps between. However, less attention has been paid to the integration of operation and maintenance tools, i.e. the so-called asset management system.

Change management is also an important function of any PLM frame-work. There are systems that provide means for managing changes, but in practice there are still problems with assessing the scope of the change [START_REF] Ahmad | Change impact on a product and its redesign process: a tool for knowledge capture and reuse[END_REF]. Changes, especially in complex engineering domains, can be 'initiated', such as front-end new requirements or new innovative solutions [START_REF] Eckert | Change and customisation in complex engineering domains[END_REF]. In addition, changes can be 'emergent', such as problems occurring in different lifecycle processes such as testing [START_REF] Eckert | Change and customisation in complex engineering domains[END_REF]. As observed by Eckert et al. [START_REF] Eckert | Change and customisation in complex engineering domains[END_REF], even if the changes can in both cases be handled the same way, their causes are different. It is important that changes, whatever their origin, are handled and managed systematically and effectively. Particular attention should be paid to change management while the product is in operations; during corrective or preventive maintenance interventions for instance. As highlighted by Ulrich [START_REF] Ulrich | The role of product architecture in the manufacturing firm[END_REF], products frequently undergo changes such as upgrades, add-ons, adaptations, wear, flexibility in use and even consumption.

Background -Use Case

The case study for this research is, as mentioned, a large-scale and complex scientific facility: that of CERN located across the French-Swiss border, in the vicinity of Geneva, Switzerland. CERN is an international research center dedicated to experimental particle physics [START_REF]Research at CERN: a gateway to the Universe[END_REF]. CERN equipment consists of accelerators, detectors and computing centers, which are substantially conceived in-house and partially manufactured, assembled and installed with the support of industrial firms.

As in many large-scale organizations, CERN has introduced and sometimes also developed different in-house means for keeping track of the equipment and their associated information. This need was enforced by the fact that several of CERN's facilities are subject to ionizing radiation and it is especially important to operate and maintain this equipment with a high degree of reliability and of traceability, and to accurately keep track of all pertinent information associated to equipment throughout its lifecycle.

The accelerator facility at CERN consists of many highly technological assets, but also of more common infrastructures such as industrial buildings and fully-equipped underground civil works. Technological assets include equipment from different decades. For instance, the PS mentioned above is from the 1950s, while that of the Large Hadron Collider (LHC), a 27-km circumference superconducting accelerator, was built in the late 1990s and early 2000s, and commissioned in 2008.

The LHC relies on superconducting magnets (see figure 1), altogether 1232 main dipoles in two variants 1104 dipoles in the arcs and 128 dipoles in the so-called dispersion suppressor (DS) regions of the tunnel [START_REF] Evans | LHC Machine[END_REF]. The LHC is not a perfect circle; it is made of eight arcs and of eight long straight sections (LSS) linked by16 DS sections [START_REF] Evans | LHC Machine[END_REF]. Even if they count fewer components, LSS and DS are more demanding from an engineering point of view [START_REF] Evans | LHC Machine[END_REF]. While the variants of the main cryodipole magnets share the same basic design, they may differ slightly in that they were manufactured by three different manufacturers [START_REF] Evans | LHC Machine[END_REF].

Items to Assets

When equipment such as the superconducting cryodipole magnets in the LHC are designed, the CERN's design offices use the term 'item' to qualify and to identify the object being conceived. Items are in general any independent objects that have an identity [START_REF] Peltonen | PDM: tuotetiedon hallinta[END_REF]. Moreover, through items, for example products, product modules and components are identified, encoded and named in a systematic and standardized way [START_REF] Sääksvuori | Product Lifecycle Management / by Antti Saaksvuori, Anselmi Immonen[END_REF].

At CERN, the LHC design information is managed through several systems: the still-in-use so-called CDD (CERN Drawing Directory, Oracle-base system developed for archiving 2D-CAD data), more recently CATIA® SmarTeam for handling 3D mock-ups and the CERN EDMS (Engineering & Equipment Data Management Service). The typical characteristic of this early phase of the product lifecycle is that the objects are not yet tangible; they do not have yet a physical existence.

When design is ready and approved, the physical instances required are manufactured and assembled based on items. One item can lead to the manufacture and assembly of a one of a kind product. This is, for instance, the case of the LHC detectors, or in many instances the case of the 1232 units in two variants of the LHC cryodipole magnets described in section 3.

After their manufacture and assembly, either done in-house in one of CERN's many machine shops and workshops, or outsourced to specialized industrial firms through procurement contracts or to partner institutes through partnership agreements, the assets are finally installed and commissioned to achieve the function they were aimed at, the facilities can move to operations and maintenance. In the case of LHC cryodipole magnets, their function is the bending of the beams to keep the particles on an orbital trajectory.

Figure 2 describes the materialization of the intangible items used in the design of tangible assets used in operations and maintenance. This figure conveys the fact that conceptually our world is made of intangible objects, i.e. that do not have intrinsically a physical existence, and of tangible objects that have a physical existence. The model uses the well-know V-model (for example, [START_REF] Sage | Handbook of Systems Engineering and Management[END_REF], [START_REF] Hull | Requirements Engineering[END_REF]) as a basis and places items and assets on the different branches of the V. Items can be broken down into sub-items and described accordingly along the descending left branch of the V-model; assets are integrated along the right branch of the V-model. In between is the materialization process. The materialization process aims to transform items into assets; out of one item, one to several assets can be materialized (the link 1 item to 1...n assets). At CERN the LHC asset information is also managed through several systems mainly the CERN EDMS (Engineering & Equipment Data Management Service) or the CERN CMMS (Computerized Maintenance Management System). This asset information can be stored as electronic files such as maintenance control records stored in the EDMS, or stored as data in the CMMS [START_REF] Bonnal | [END_REF].

As a general principle, equipment is manufactured and assembled based on engineering information developed at item level. However, a vast amount of information is also produced while operating and maintaining the equipment. If this information is generic, i.e. applicable to all instances of an asset, then it shall be at item level. If this information is specific to a given instance of equipment, then the asset shall be the repository for this information. Figure 3, adapted from basic quality management practices shows the categorization of different types of information. It is also of interest to notice that the information is different according to the phases of life of a product [START_REF] Bonnal | [END_REF]. Information associated with an item shall typically be at 'descriptive level' i.e. level 3 in the quality assurance hierarchy of documents, while an asset's information shall be at 'records level' i.e. level 4 (see figures 2 and 3). As described above, during the life of equipment at CERN there is a transfer from one terminology to another, but also transfer from one system of information systems (SmarTeam, CDD and EDMS) to another (EDMS and CMMS). The terms and systems mentioned here do not cover all of those in use at CERN, but are a simplification for the use in this paper. For instance following (sometimes synonymous) terms are in use: item, equipment, part, system, asset, functional position, slot and location. It becomes evident that if there is no link between the terminology and the information systems, there will be problems when the need to proceed to some modifications to the original design will appear. It is then of prime importance to keep the information coherent throughout the whole lifecycle of the equipment.

From Concepts to Practice

When the items have been manufactured, installed and commissioned, the materialized equipment is handed over to the operation and maintenance phase. For the sake of operational efficiency, the CERN organizational structure is made of different sectors, departments groups and sections. For instance, the so-called Accelerator and Technology (A&T) sector groups three departments, namely the Beams, Engineering and Technology Departments. Further down, the Engineering Department take care of particular part of the equipment, systems and facilities by means of specialized groups: e.g. Cooling and Ventilation Group, Electrical Engineering Group, Handling Engineering Group, Beam Instrumentation Group or Cryogenics Group to cite just a few. Finally through their sections, the groups provide services such as the operational maintenance of the equipment for which they have responsibility. The problem with such an organizational approach is that transverse processes such as maintenance operations, whether they are corrective or preventive, are performed in different departments and groups and rather independently.

In the handover process, an item is transformed into one or several assets. Figure 4 shows that after materialization items and assets may have independent lifecycles, but necessarily interdependent ones: design activities belong to the item lifecycle. Materialization is an activity that 'bridges' both lifecycle, i.e. that initiates an asset instance of an item. After materialization, an item in design may be subject to changes. There are many challenges in the change implementation, regardless of cause or type [START_REF] Clarkson | Predicting change propagation in complex design[END_REF]. In the generic engineering change process introduced in Jarratt et al. [START_REF] Jarratt | Engineering change: an overview and perspective on the literature[END_REF], the first step is an engineering change request, which determines reason, priority and type of a change in addition to components and systems that are likely to be affected.

Changes to items, propagates to versioning or revising the item. Unfortunately, as pointed out in [START_REF] Schichtel | Produktdatenmodellierung in der Praxis[END_REF], the terminologies are not fixed. In any case, the meaning is that the item is changed in a matter that it will replace the original item [START_REF] Peltonen | PDM: tuotetiedon hallinta[END_REF], [START_REF] Schichtel | Produktdatenmodellierung in der Praxis[END_REF]. When changes are made as revisions, an important issue to keep in mind is the rules for revisions. The ISO 11442 standard dedicated to technical product documentation management [27] provides insights into revision rules for documents to reflect design changes. The revision rules also affect the identification of the components. The following passage of ISO 11442 [27] shall be kept in mind: "Technical changes with requirement for interchangeability between the old and the new version. The form, fit and function of the component is not affected, and consequently the identification number is retained." [27] This raises the question of interchangeability: while an item design evolves, how to guarantee that the results of its evolution are compatible with the requirements of its corresponding assets that are in use? Sometimes items are changed in such a manner that this rule does not apply and the original item is not replaced. This process produces variants. Variants are parallel options for items [START_REF] Peltonen | PDM: tuotetiedon hallinta[END_REF], [START_REF] Schichtel | Produktdatenmodellierung in der Praxis[END_REF]. Items may evolve, while their corresponding assets are kept physically unchanged (see figure 4). A problem may arise when the need to replace or modify an asset appears. Shall the replaced or repaired asset be based on version 1 of the item (that may have an obsolete status) or on version 2 (that is the latest released of the asset)? It is noteworthy that the figure 4 is meant to be a discussion opener for the topic. Another point of view on the information flow is backwards from assets to items. While modifying items the versioning and creation of variants are well defined procedures (e.g. [START_REF] Peltonen | PDM: tuotetiedon hallinta[END_REF], [START_REF] Schichtel | Produktdatenmodellierung in der Praxis[END_REF]), whereas describing what will happen in the item level when an asset is modified is to the best of our knowledge not well described. However, the modification of the description of an asset should be reflected at item level by creating a variant to receive this descriptive information.

Summary and Conclusions

In a complex and tailor-made environment, with the long life of equipment, it is extremely important to put emphasis on managing product information. The characteristics of the information such as that produced in different lifecycle phases and different period of time also bring their own flavour to the problems. In this paper we have raised and discussed a few issues: possible misunderstanding due to different terminologies used over the lifecycle; and additional misunderstanding due an insufficient distinction between the key concepts of item and asset.

Throughout its whole lifecycle, a product is prone to change [START_REF] Jarratt | Engineering change: an overview and perspective on the literature[END_REF]. Engineering changes is a largely noticed issue in industry, but also an active research area of academia [START_REF] Jarratt | Engineering change: an overview and perspective on the literature[END_REF]. The paper also draws attention integrating the information from different lifecycle phases, from items to assets and vice versa, together.

Discussed important challenges are highlighted in table 1.

Table 1. The challenges discussed.

Challenge Description Concepts vs. Practice In system design objects are still intangible, while in operation and maintenance the objects are tangible with a physical existence. In the materialization process one intangible object is transformed into one or several tangible objects and the link shall be maintained.

Terminology

Different terminology is used in different lifecycle phases. Problems may occur, when changing from term to term, and in the interfaces.

Different lifecycles

Different objects (i.e. items and assets) may have different lifecycles. In the need of modification or replacement there is a need for 'bridging' the different lifecycles.

Fig. 1 .

 1 Fig. 1. Cross section of an LHC dipole in the tunnel. © 2011 CERN[START_REF] Brice | Cross section of an LHC dipole in the tunnel[END_REF]

Fig. 2 .

 2 Fig. 2. V-model of materializing items to assets.

Fig. 3 .

 3 Fig. 3. Document hierarchies in CERN adapted from [23].

Fig. 4 .

 4 Fig. 4. Item and Asset Lifecycles.

Acknowledgments. We would like to express our gratitude for European Commission Marie Curie Actions for providing funding for this research (FP7 grant agreement 264336). We would also like to thank PURESAFE-project consortium, especially CERN for their insight.


Dr Hondjack Dehainsala
email: hondjack.dehainsala@areava.com

Mr Philippe Perdriau

Repositories and Interoperability Standards

Keywords: PLM, Plants, ISO15926, Iring, Exchange Process, Interoperability, Semantic-Web, AIRE

Enterprise have needs for interoperability and exchange data interact with repositories; some standards exists and news are come in, particularly those related to the life cycle of facilities and plants. Technical and functional principles have been implemented in an interoperability platform built to meet these needs and to be open to the different standards (existing and news). PLM tools for repository management are inadequate for handling exchanges in that they consider only the development of point-to-point tools or data copying, and that current exchange standards are also about point-to-point tools and do not really meet the needs of engineering companies and facility operators. This deficiency has led the community to focus on new standards based on Semantic Web technologies (in particular ISO15926) [8] which make these repositories and other authoring tools interoperable with one another. Feedback is given on the inclusion of this standard, its implementation and deployment.

The Need to Interoperate and the Expected Functions

Functions integrated into the repositories

The term PLM is taken to mean all processes, activities and functions used to manage and configure data, documents, files and information during the cycle [7] of a product or facility. Presently only functions and data are considered. PLMs are widely deployed in manufacturing industries [7] and are starting to be in companies involved in the design, construction, operation, maintenance and decommissioning of facilities. However, in this latter context special features appear that are particularly linked to the eco-system engaged on projects and to the nature of the objects and design processes of continuous-process industries.

Purpose of this Document

The purpose of this paper is to analyze the features and tools for data exchange and between systems to make them interoperable, given, to use the definition outlined by Wikipedia, that interoperability is the ability of a product or system, whose interfaces are fully known, to work with other existing or future products or systems with unrestricted access or implementation; the creation of a specific tool to make A and B communicate does not make A and B interoperable. The main question is: do we need interoperability with PLM tools and why? After that, we consider the characteristic of exchange standards and why the news standards like ISO15926 are based on new technology as the semantic Web. We conclude with our feedback from a platform development and from first tests in interoperability.

Special Cases in the Design, Construction and Maintenance of Petrochemical, Chemical and Nuclear Power process Facilities

In these situations, the eco-system of the stakeholders involved is not known in advance from one project to another, which distinguishes this context from those commonly encountered in other sectors. It is assembled and dismantled for each operation: partners one day are competitors the next and suppliers' cultural differences are important, as the projects are mainly international with the contractual obligation to employ local businesses.

Operators ultimately recover the documentation (data, study, construction, inspection and commissioning documents) models, files and requirements, and classify and integrate them into their own operational systems or archiving.

Facilities comprise a large number of objects (of the order of one million compared, for example, with a car which has only a few thousand).

At this stage, the following observation can be made:

• The exchanges between systems are numerous, very diverse and need to be controlled and secured [2] o If we consider that out of the million objects referenced in a facility, 10% are subject to a collaborative process with the outside world and that this process requires 3-5 exchanges of partial or complete information, this makes about 1000 exchanges per day at the peak, with about a hundred stakeholders. • A single repository shared with several stakeholders is not a good idea, in addition to the fact that it is very complex to set up (especially if it is needed throughout the duration of a project, because it may be completed only after the end of the project). A functional architecture should therefore be chosen, suited to the needs of each entity and to its responsibilities, but open and interoperable with other systems.

Example: interoperability need for an operator An operator uses different business views of the various systems and equipment items

• For example, a technological view per equipment family The interoperability functions are then used to synchronize the systems, but it is also necessary to control the process of dissemination and integration between the source and the various targets.

Exchange Needs with others: how to achieve this

The previous sections show the diversity of exchange needs in both engineering projects and facility modification activities. There are structured into 4 categories:

1) Exchanges with suppliers While some exchanges consist of synchronizing information, it is standard practice they are supported by the publishing processes on the one hand and integration processes on the other. It is recommended to filter and check the data to be made accessible, control the quality of the data received and see the changes; the tools must be able to deal with the exchange safely, both for the value of data and for a data set or the whole of a facility, either in sync mode or via formalized transmissions.

The lack of interoperability between these stakeholders is a source of costs (4 % according to [1]) which may be important in absolute terms in major contracts and may be even more so in relative terms for modifications to facilities, even if they are less costly.

In conclusion, interoperability functions are complementary functions that are found in PLM tools. The development of tools, based on exchange standards, connected to PLMs, but also to other sources of information, helps to streamline information systems and optimizes project processes. Only adopting a standard shared by the ecosystem is able to solve the problem.

Exchange or Interoperability Standards and New Technologies

Exchange standards (ISO10303, ISO15926, for example) have similar characteristics:

1. An expression language of a data model 2. A data model representing a concept, 3. A dictionary describing types of reference objects and their characteristics, 4. Means to exchange and access information. The choice of the exchange standard is based on the characteristics of the data model and the contents of the dictionary. The usage of a standard by a company differs according to the disciplines (civil engineering, equipment, I & C, requirements), that these often refer the same information and that the consistency of information published or integrated becomes very difficult to maintain.

The ISO15926 standard (also called iRing) developed and maintained by the association PCA (POASC CAESAR ASSOCIATION) under the authority of the FIATECH (in relation with standardization bodies, in particular TC184/SC4) proposes a significant change in the approach in terms of both modelling and technology. In terms of modelling, the following notable points can be distinguished: 1. The model is based on the overall classification if each element satisfies the inclusion criteria in its category and on class specialization for a subclass to inherit the properties of the parent class; relationships between classes can be also categorized. 2. This fairly complex modelling is intended to be described in the language of the Semantic Web, i.e. OWL (Ontology Web Language). 3. Objects and object attributes are identified by URIs (Uniform Resource Identifier) and allow sharing by means of web navigation. 4. The ISO15926 standard, based on the notion of roles (defining attributes of a class) that can be instantiated on an object, enables representation to be simplified while remaining under the control of the principles set out in the general model. 5. Each company makes a mapping between the data model of its business application with the data model of ISO15926, its dictionary (private or public) and its roles (templates). In terms of technology, using the Semantic Web [3] provides the following benefits: 1. Based on a general purpose, non-specific communication standard for technical data: this makes it possible to use distributed technological layers.

• So OWL modelling can be handled by existing tools inherent in this technology. 2. Using rules, this handling makes it possible to combine different concepts (domains) insofar as a relationship can be expressed to relate these concepts.

Figure 3 : example of adding different concepts

The dictionary of standard ISO15926 (RDL) today contains the characteristics of objects contained in the facility: equipment (heat exchangers, columns, etc.), components (pumps, valves, motors, etc.) which make it possible to describe a technical tree of physical objects. It is also possible to describe an abstract object tree as a functional tree. However exchanging this data is insufficient, particularly in the management of critical facilities and it is recommended that they should be accompanied by exchanges concerning the related requirements (e.g. requirements about the equipment). Semantic Web technologies allow this association and make it possible to implement it more efficiently than the simultaneous implementation of different protocols (AP221, AP227 and AP233) of ISO 10303..

3. Constraints (such as those formulated in STEP Express language) can then be added to the OWL model. These constraints, expressed as additional rules, can be enriched by each stakeholder without having to be uniquely defined in the standard. 4. The general use of URIs allows the construction of dictionaries at normative for the all concepts, sector or private level. 5. The exchange of information can be done in OWL files which include both data and the data model. We can then speak of knowledge transfer. 6. The notion of façade (RDF = Resource Description Framework) makes it possible to make data searchable via the Internet accessible using a suitable query system (SPARQL language). This language enables the concepts of the OWL data model in order to access the required information.

Another point to consider is that the exchanges are supported by the processes of each entity. In contractual terms, the exchanges must be traced and accompanied by a document possibly associated with an electronic signature of compliance.

The ISO15926 standard supports all its promises, the question being to find the most effective tools and see how they can be deployed in practice. This has been explained and experimented as set out in Part 3 of this document.

In conclusion, the new information technologies, especially the Semantic Web are able to provide innovation in achieving exchange standards: they allow exchanges that are internal and external to the Company and are more flexible to implement. They also allow different contexts to be aggregated. The emerging ISO15926 standards based on these technologies is potentially able to take up a key position (especially in process industries) and must therefore be investigated and equipped while maintaining a broad view of possible extensions and technical and contractual implementation constraints.

Experience Feedback from Industrial Implementation

The AIRE platform (AREVA Interoperabilty Rich Environment or AREVA IRING Environment following the redesignation of ISO15926 by the IRING brand) was developed to experiment and industrialize the above principles.

Technologically, this platform has been designed to:

• Be compliant with the Semantic Web technology,

• Implement all parts of ISO15926 1 ,

• Take into account the constraints related to data privacy and cyber security.

And in functional terms, it has been designed to:

• Be open to taking into consideration the exchange of data from multiple domains either by extension of the Part 2 model of ISO15926 and the RDL dictionary, Part 4, or by integrating other standards (e.g. -ISA, BIM/IFC, STEP). • Support the information publishing process, filtering information to be published 2 , creation and management of publication spaces according to data and recipients 3 . • Produce reports accompanying the publication of such information in order to meet contractual requirements. • Support the information integration process with evaluation of changes between two successive integrations and performance of integrity checks 4 . • Produce examination and integration reports to meet contractual requirements.

• Allow queries on data published by means of query generators.

• Exchange data sets by producing OWL files (on XML layer) making data and data model consistent with each other. • Produce private RDLs and check correspondence (mapping) between source data and the RDLs (those maintained by certification bodies PCA/JORD and private RDLs generated) within a collaborative dialogue between two third-party partners. This check focuses on the completeness of the mapping and on the practical checks on the basis of test data before running the exchanges. • Manage master data with alerting in case of modification of these data • Take into account the exchange of attribute data, schematic data and ultimately 3D data and their changes (version or time effectiveness).

To demonstrate its capability, several connectors are made with off-the-shelf packages so as to build some real feedback on tool integration. This has made it possible to validate the source integration methodology and to develop transactions and man-machine interfaces related to the above process: exchanges are prepared in AIRE but are directly carried out in the interfaces of these tools which therefore become interoperable.

1 It's mandatory to share data thru internet way, to extend the ISO15926 data model with new concepts and dictionary. 2 To avoid publication of internal data that the company have to protect if these data are also stored in the application with the data that the company must publish 3 To separate information regarding recipient need to have the data 4 To control data with company rules before integration in the target tool

Source Integration Methodology

The founding principle of the AIRE methodology (using the work described in [4]) is a) to transpose the data model of the application into an interface (source or target) and perform data transfer (import or export) in the formalism of the Semantic Web: b) construction of ontology of the application and c) execution of technical interface functions. This action gives a mirror of the data application in RDF format (in the form of subject-predicate-object triples) of both the data model and data directly manipulated by an OWL reasoner tool (into which the ontology of the standard has previously been loaded). This is done once and for all for each application. The import and export functions can then be realized by the same way. The second step is then to link the dictionary elements to the elements of the data model of the application. This is called "mapping" and is handled within a module of AIRE, the "configuration editor" which can question the public RDLs maintained by the PCA) or create private RDLs (at the level of the company, a group of companies or a business sector) 5 . This operation is performed once per application and per standard. However, it needs to have a validation process to ensure that the mapping made is understood by the other parties: and the "configuration editor" can do this in collaborative mode with a third party, independently of whether the latter has the AIRE platform or not.

Exchange Transformation Methodology in the Standard

The configuration editor then generates a certain number of rules that are added to the ontology of the standard (here Part 2 of the ISO15926 standard) making it possible to link the dictionary (Part 4) and the roles (Part 7).

These rules are then carried out to publish or integrate the application data in interaction with the formalisms of the standard. This formalism can be expressed in the language of the Semantic Web (through RDF facades or OWL exports as is the case for ISO 15926), but can be expressed in other formats (XML based for example such as PROTEUS/XMPLANT or as AEX).

Validation and certification

The AIRE solution has been validated with blind exchanges with a third party as part of a handover process. This experiment has improved functionality and means that the solution can be presented for certification by the PCA (POSC CAESAR ASSOCIATION).

Feedback

Firstly, the inclusion of a new standard in the company takes time that should not be underestimated. It seems important that the company should build case studies, depending on its activity and its own feedback, and clearly identify its levers, whether these be technical, technological, business or commercial. In the case of the developments and experiments made, the flexibility provided by the Semantic Web is confirmed without significant performance degradation due to this flexibility. One difficulty that should not be underestimated is related to communication of the standard and its implementation especially in the presentation of findings from the experiments: if it is too technical, it will seem very complicated and will alarm decision-makers; if this complexity is hidden, it becomes too easy or simplistic and states the obvious. It is therefore necessary to refer to difficulties encountered daily by the company which requires prior acceptance of these problems. Finally, the implementation of these interoperability tools introduces new tasks and new roles or may even require adaptation of the organization within the Company, particularly in the management of these interfaces with third parties.

Conclusion and extensions

Developments and experiments carried out as part of the R&D project led to the construction of an accomplished solution, benefiting both from the advantages of a solid base, and also from business transactions deriving from a group with both engineering and operation/maintenance of complex systems services. It has also been shown that interoperability should be seen as a specific function with specialized stakeholders defining models and mappings, and organizing exchange flows. This solution is integrated into the PLM repositories, which thereby have an additional interoperability function, and prevents/reduces manual copying of

Figure 1 :

 1 Figure 1 : interoperability needs for an operator

Figure

  Figure 2 : exchanges between Plant actors

  Figure 4 : transformation principle

information or the implementation of specific point-to-point developments as well as the risk of errors and related cost overruns. The choice of technological solutions and their design is essential in order to accompany these changes without calling them into question. The Semantic Web technologies and their implementation flexibility allow us to meet these goals by drastically reducing the costs and risks: they live up to their promises.


Angelo Corallo

Mariangela Lazoi
email: mariangela.lazoi@unisalento.it

Antonio Margarito

Davide Pinna

Developing a PLM Framework: a case study application in an energy company

Keywords: PLM, framework, lifecycle phases, processes, configuration management, IT systems

Product lifecycle management has to be related to a business approach that requires IT solutions and also organizational changes in order to produce the desired effects. Different aspects (product data, people, processes, organization, IT technologies) needs to be integrated together for the achievement of a competitive advantage for the company. PLM needs of operational tools that can support the implementation of the theoretical principles. In particular, as extensively studied in the literature, company needs frameworks to refer for guiding the implementation of PLM initiatives and to support improvement actions. Based on an action research, the paper wants to describe the development and application of a PLM framework in Ansaldo Energia, an Italian leader energy company. The framework is product-centred and focused on processes and related IT systems. It allows to diffuse knowledge and culture on products lifecycle inside the company. Indications for the framework development in the ARIS Software AG are also provided.

Introduction

PLM means an integrated management of technological, methodological and strategic issues along the whole product lifecycle [START_REF] Garetti | Organisational change and knowledge management in PLM implementation[END_REF], [START_REF] Grieves | Product Lifecycle Management: Driving the Next Generation of Lean Thinking[END_REF]. A product data is not created and used only in a specific activity but it is linked to the whole set of data that are created and used during its lifecycle [START_REF] Ameri | Product Lifecycle Management: Closing the Knowledge Loops[END_REF]. Having this awareness, inefficiencies related to waste of time, energy and resources can be avoided. Many companies refer to the PLM considering only the IT side and ignoring the organizational impact [START_REF] Batenburg | PLM roadmap: stepwise PLM implementation based on the concepts of maturity and alignment[END_REF]. If it is underestimated, wrong investments and long time for IT deployment can arise. The understanding of these issues is not immediate. It needs a cultural change [START_REF] Rangan | Streamlining Product Lifecycle Processes: A Survey of Product Lifecycle Management Implementations, Directions, and Challenges[END_REF] based on a consciousness and knowledge of the impacts and relations among the whole product lifecycle elements.

Several scholars have developed models and frameworks on PLM (e.g. [START_REF] Schuh | Process oriented framework to support PLM implementation[END_REF], [START_REF] Budde | Holistic PLM Model -Deduction of a Holistic PLM-Model from the General Dimensions of an Integrated Management[END_REF], [START_REF] Silventoinen | Holistic PLM Model. 8th International Conference on Product Lifecycle Management[END_REF]) and have analyzed the industrial case studies (e.g. [START_REF] Alemanni | Key performance indicators for PLM benefits evaluation: The Alcatel Alenia Space case study[END_REF], [START_REF] Golovatchev | Integrated PLM-process-approach for the development and management of telecommunications products in a multi-lifecycle environment[END_REF]) to evaluate their validity. The available works don't explore the context of an energy company and don't propose a PLM framework and a corresponding methodology for process representation.

Therefore, based on an action research between University and Industry, the paper explore a case study on PLM features and relations in Ansaldo Energia, an Italian leading energy company. A PLM framework is proposed and validated in the paper. The aim is to generate a pragmatic view around PLM for company working for complex product development in high-technological sectors, such as energy one. structure processes, activities, data and IT tools related to a specific product lifecycle are highlighted and represented in an organic and integrated structure. The proposed framework has been used by the company to diffuse a PLM culture and knowledge.

Background

A wide set of PLM model is available in scientific papers as a result of both theoretical and industrial research. The most comprehensive models in literature present a holistic PLM vision describing the complexity of PLM and harmonizing all its aspects in a limited set of key dimensions.

Budde et al. [START_REF] Budde | Holistic PLM Model -Deduction of a Holistic PLM-Model from the General Dimensions of an Integrated Management[END_REF] include in their framework four elements important for the development and the implementation of PLM: strategy, process, product structure and IT-architecture. According to the author the challenge is not the selection of single solutions, but the integration of different tools and systems in the holistic implementation. Budde's model has been discussed by Silventoinen et al. [START_REF] Silventoinen | Holistic PLM Model. 8th International Conference on Product Lifecycle Management[END_REF], who add a fifth element, people and culture, in order to emphasize the importance of organizational culture and human factor in PLM implementation. Interrelation between key dimensions are defined both in Budde et al. [START_REF] Budde | Holistic PLM Model -Deduction of a Holistic PLM-Model from the General Dimensions of an Integrated Management[END_REF] and Silventoinen et al. [START_REF] Silventoinen | Holistic PLM Model. 8th International Conference on Product Lifecycle Management[END_REF].

Others authors have proposed models that identify PLM main components. In Schuh et al. [START_REF] Schuh | Process oriented framework to support PLM implementation[END_REF], the central point consists of a set of lifecycle oriented business process reference models which vary according to a group of company's characteristics. The centrality of business processes and product data are also the distinctive element of the PLM model defined by Abramovici [START_REF] Abramovici | Future trends in product lifecycle management[END_REF]. He proposes a model that includes methods, models and IT tools for managing product information, engineering processes and applications along the different phases of the product lifecycle [START_REF] Abramovici | Future trends in product lifecycle management[END_REF]. PLM is also analyzed by Rangan et al [START_REF] Rangan | Streamlining Product Lifecycle Processes: A Survey of Product Lifecycle Management Implementations, Directions, and Challenges[END_REF] that define just the broad scope of PLM specifying eight key dimensions: Business Drivers, Transformation Drivers, Domain Model, Generic Product Lifecycle, PLM tools, Implementation Drivers and Deployment Transition.

The role of processes in PLM is relevant as described in someone of the previous framework (e.g. [START_REF] Schuh | Process oriented framework to support PLM implementation[END_REF]; [START_REF] Budde | Holistic PLM Model -Deduction of a Holistic PLM-Model from the General Dimensions of an Integrated Management[END_REF]). Through processes, products evolve along the lifecycle and feedbacks (e.g. lesson learned and best practice) are diffused among the organizational practices. Different researchers have studied the relevance of processes in the product lifecycle. Messaadia et al [START_REF] Messaadia | Systems Engineering Processes Deployment for PLM[END_REF] have explored the System Engineering processes to model PLM and concluded that this approach is complimentary to PLM to address the systems technology. Etienne et al [START_REF] Etienne | Specifications and development of interoperability solution dedicated to multiple expertise collaboration in a design framework[END_REF] have proposed a interoperability platform based on product processes organizations. Schulte [START_REF] Schulte | Customer centric PLM: integrating customers' feedback into product data and lifecycle processes[END_REF] instead has proposed a methodology to better integrate the customers' requirements of actual or attended products in the PLM functions, processes and metadata. As highlighted by Rangan et al [START_REF] Rangan | Streamlining Product Lifecycle Processes: A Survey of Product Lifecycle Management Implementations, Directions, and Challenges[END_REF], PLM processes need further exploration and a "cultural change management" is required in order to optimize organizational processes rather than individual benefits.

In literature, several case studies analyze the company practices in the PLM field. In the study of Golovatchev et al. [START_REF] Golovatchev | Integrated PLM-process-approach for the development and management of telecommunications products in a multi-lifecycle environment[END_REF], a telecommunication industry is explored and a PLM-process management approach is proposed and validated. This approach is suitable for complex products composed by several elements each-one characterized by a proper lifecycle. Some case studies have a technological focus such as the work of An Chiang & Trappey [START_REF] Chiang | Development of value chain collaborative model for product lifecycle management and its LCD industry adoption[END_REF] in which a PLM system implementation in LCD industry is described through the proposal of a conceptual architecture of PLM. Focusing on companies working in complex sectors, there are specific case studies analyzing the aerospace and automotive sectors. For the aerospace sector, relevant studies are: 1) Alemanni et al. [START_REF] Alemanni | Key performance indicators for PLM benefits evaluation: The Alcatel Alenia Space case study[END_REF], which propose a KPI framework to test the adoption of a PLM tool, validated in an aerospace and defence company and 2) Lee et al. [START_REF] Lee | Product lifecycle management in aviation maintenance, repair and overhaul[END_REF], which discuss two case studies from the aviation MRO companies in Singapore that stress the high potentiality of PLM applications. In the automotive sector, the study of Tang & Qian [START_REF] Tang | Product lifecycle management for automotive development focusing on supplier integration[END_REF] needs a citation: it illustrates the PLM implementation among an OEM and its suppliers highlighting practices and characteristics.

Therefore, several researchers have argued both on the PLM representation in framework and models and on the relevance of PLM as a business approach integrating different companies' perspectives. In a high quantity of studies, the role of processes is clearly highlighted and included in the PLM treatments as a central element. Furthermore, to support the wide relevance of PLM for the companies practices several case studies are available that discuss and make relevant the strategic role of PLM both as a technology and as a business approach in different industrial sectors. None of the analyzed cases study in literature are focused on the energy sectors but best practices and lesson learned can be grasped and extended. This element is relevant to highlight the uniqueness of case study research focused on a specific object.

Additionally, in literature it doesn't exist an holistic PLM framework described with a methodology for process representation that support and allow a further extension and replication.

Finally, several are the enterprise architecture frameworks (i.e. Zachman Framework [START_REF]The Zachman framework[END_REF], CBM [START_REF]A component-based approach to strategic change[END_REF], DCOR [START_REF]Supply Chain Council Website[END_REF], APQC [START_REF] Apqc | APQC Process Classification Framework Website[END_REF], CMMI [START_REF]CMMI for Development[END_REF]) that treat the representation and integration of different organizational dimensions in a unique framework. This enterprise architecture framework however miss of a focus on the product and on its lifecycle. For example, configuration management aspects are not treated as a whole. Suggestions of linkages among elements and the use of standardized item name (e.g. such as for APQC) have been considered and integrated in the research results.

Research Design

Research Method

Based on the previous literature background, the paper wants to describe the development and application of a PLM framework, product-centred and focused on processes and involved IT systems, in an energy company. The main research question that the paper wants to address is: How to represent a PLM framework for complex products in order to diffuse a PLM culture and share features and insights of a product lifecycle?

This question has emerged as aim of an action research in which University of Salento was involved with its partner company Ansaldo Energia in the MindSh@re community of Finmeccanica. The paper presents an industrial case study based on the results of the carried out action research.

A case study is particularly appropriate to study contemporary events and noncontrollable units of analysis [START_REF] Yin | Case Study Research: Design and Methods[END_REF]. The case study is thus guided by the pragmatism knowledge claim: it is problem-centric and the attention is therefore placed on the problem and how to solve it in a real organizational setting [START_REF] Creswell | Research Design: Qualitative, Quantitative, and Mixed Methods Approaches[END_REF]. Multiple sources of evidences have been used to increase the case study's construct validity [START_REF] Yin | Case Study Research: Design and Methods[END_REF]: the direct researchers' observations and interviews with key users. Most of the information was collected through a set of interviews to key company referents. They are a convenience sample since are involved in the phases of product lifecycle as manager or responsible [START_REF] Bryman | Business Research Methods[END_REF]. For each phase, a key informant have been involved and information have been shared and collected with its collaboration. An open-ended questionnaire has been administered at each key informant to better stimulate perspectives, views and opinions sharing among the participants [START_REF] Creswell | Research Design: Qualitative, Quantitative, and Mixed Methods Approaches[END_REF]. The key informants have reviewed the case study report and validated the main findings and conclusions. Data and information of the PLM framework have been represented using the software ARIS Business Architect 7.1. This software is suitable to create, analyze, manage and administer an enterprise process architecture.

Research Context

Ansaldo Energia (AEN) is a Finmeccanica Group company and is the Italian largest supplier, installer and service provider for power generation plants and components. AEN is a manufacturing company working in the production of gas turbines, steam turbines and generators (hydro and air-cooled generators) dedicated to energy production. Depending on the contract type, AEN provides a variety of system configurations ranging from the simple supply of machines to the design, implementation and management of the entire plant.

AEN considers the PLM as essential and strategic to manage information, processes and resources that support the product along its lifecycle, from the conceptualization to the design, from the manufacturing to the sell, until the maintenance.

Results

The PLM Framework

Each time a company's product is designed, physically realized, delivered to a customer and, in some cases, also maintained and disposed, its lifecycle is put into effect requiring several resources and impacting on different organizational dimensions.

The structure of the proposed PLM Framework is composed by four blocks and related relational levels. The four blocks are: Block A -PLM Definition and Foundation; Block B -PLM Phases and Processes; Block C -PLM Configuration Management Views; Block D -PLM IT Architecture.

The PLM Framework can be developed for each product typology in the company. Each product has its own phases of lifecycle led by the processes execution. During the activities done in the processes, the product data evolve and are represented in the configuration management (CM) views. IT tools are used in the processes and make available the CM Data.

Each block is designed to be detailed for including further relevant information. A specification of detail levels with the corresponding ARIS models is available:  Block A: 1) Company's products (as Product-Tree), 2) Structure of Products (as About the first two levels of the lask block, IT systems are specified as isolated entities that are used for different aims and in different moments of the life-cycle. In the third level "Details", instead, the integration among the different IT systems are specified, if it is present. Generally, in the practice of the companies is almost impossible to observe that all the software tools used along the lifecycle of a product are directly integrated without the need of re-working or uploading among different systems. This evidence justify the chosen block structure.

The Application in AEN

The gas turbine has been chosen as test-case for the application of the PLM Framework. It is a core product for AEN and is considered as a "single equipment" that can be expanded including also the whole plant or the maintenance services.

According to analyzed AEN practices, the following lifecycle phases have been defined:  Plan: a product life cycle starts with the definition of the company strategic plan that include research and business initiatives.  Concept Development: incremental or radical innovation activities on existing products are carry out to satisfy the needs of a specific customer or to increase and improve the company products portfolio.  Product Design: when a job order is received, product changes and installation details are designed.  Manufacturing: it is comprehensive of all the industrialization activities, including two fundamental moments the productive process design and the effective production.  Sell & Distribution: the realized product is delivered and installed at the customer site.  Service: when the product is operative in its site, a set of maintenance activities are executed based on the agreement conditions.  Disposal: an AEN product lifecycle is very long but if established by agreement, at the end of its lifecycle, it can be retired and its recyclable and un-recyclable components adequately managed.

The Lifecycle Phases are characterized by Technical Processes [START_REF]Systems and software engineering -System life cycle processes[END_REF] based on technical activities executed in the lifecycle for realizing the customers desired products. The Lifecycle Phases with their Technical Processes are supported by Project Processes [START_REF]Systems and software engineering -System life cycle processes[END_REF] that allow to manage resources and assets allocated to a project. Among them, in the specific case of AEN, the Tollgate Process and the Product Configuration Management Process are highlighted.

For each lifecycle phase, the Technical processes have been identified (e.g. Figure 1) and for each process, the activities, IT systems and data have been modeled using the EPC (Event Process Chain) standard. A Function Allocation Diagram (FAD) have been created for the activities with more than one input, output or IT system. Such activities have been extracted from the process and the related features have been assigned. The configuration management views recognized and managed in AEN are As Designed, As Planned and As Delivered. A CM View is a visualization of data in a specific moment of the lifecycle allocated for specific tasks. Such data are available on information systems and represents the product features. Therefore, for the aim of the Framework, the CM views have been broken up in their meta-data (e.g. Figure 2). IT systems in which are available, and activities in which are created, have been also specified. In AEN, several IT systems are used to manage and execute processes and to store configuration management data. A type classification is: Product Lifecycle Management (PLM) System, Product Data Management (PDM) System, Computer Aided Design (CAD) System, Computer Aided Engineering (CAE) System, Computer Aided Manufacturing (CAM) System, Project Management System, Enterprise Resources Planning (ERP) System, Legacy Software, Optimization Software and the Materials Database (DB). AEN has both a PLM and PDM System, this last one is mainly used as Document Management System in some processes. For each IT system, a map has been realized with available modules, supported activities and integration with others tools.

The analysis done for product data, processes, configuration management views and IT systems along the gas turbine lifecycle, is summarized in the following figure that represents the high level of the PLM framework for AEN.

Fig. 3. PLM Framework for Gas Turbine in AEN

The Framework is easy to navigate by simply clicking on the selected item both in the ARIS software and in a web format (html) that can be integrated in companies' portals. The use of the software ARIS Business Architect 7.1 have allowed to satisfied the need of a better traceability, integration and representation of the Framework elements thanks to the availability of several models suitable for each block's element. Furthermore, the Framework elements are structured in folders guaranteeing an easier consultation and exploration.

Discussion and Conclusion

In the study, the context of the company Ansaldo Energia has been explored and structured around a PLM framework suitable to represent in an integrated scenario product data, processes, configuration views and IT systems. The study results provide an evidence from a real company practices in the PLM field and suggest the adoption of a PLM framework detailed using the software ARIS Business Architect. In the paper, indications on the selected ARIS models for the representation of the Framework are also provided that can be used to replicate the framework in others contexts.

In the PLM Framework, the lifecycle is represented as an integrated framework in which data, processes and IT systems co-exist and are linked. The main field of application of the PLM Framework is to create a reference for the PLM issues inside the company. It can be used for documentation purposes inside the company in order to diffuse a PLM culture and knowledge among the employees. In this manner, the employees are stimulated to think to their job as a small part of a wider set of activities that impact on the whole product lifecycle performance.

The PLM Framework can also be useful in performance measurement of processes and IT inside a company or among different companies, as it provides a reference to assess performances on a wider scope, covering the whole product lifecycle, instead of providing measurements of individual elements separated from the whole context. Furthermore, representing IT and processes for different products, it allows to compare the different company scenarios and can support the design of improvements and rationalise initiatives.

Such a tool, as correlates all the different parts, allows a more accurate assessment of the effort and of the impacts that a change in the company (e.g. a change to a process, an update of an IT system, etc. ) can have in terms of cost and/or performance over the entire lifecycle. It can be used to better manage the change management process.

Future research will be dedicated to better formalize the PLM framework methodology and apply it to other organizational contexts within Ansaldo Energia and in other companies as well.

Product-Tree) and 3 )

 3 Structure of Products Component(as Product-Tree).  Block B: 1) Synthesis of company's products lifecycle (as Value-added Chain Diagram), 2) Product Lifecycle Phases (as Value-added Chain Diagram), 3) Processes for a specific Product Lifecycle Phase (as Value-added Chain Diagram), 4) Process Activities for a specific Product Lifecycle Phase (as EPC column display) and 5) Detail of IT systems, inputs, outputs and organizational units for an activity (as Functional Allocation Diagram)  Block C: 1) Sets of Configuration Management Views for company's products (as Value-added Chain Diagram), 2) Product Configuration Management Views (as Value-added Chain Diagram) and 3) Metadata, software and activities for the Configuration Management View of a given Product (as UML Class Diagram).  Block D: 1) Sets of IT systems for company's products (as EPC), 2) Product IT Systems (as Entry Diagram) and 3) Details (available modules, integrations and supported activities) of the IT system for a given Product (as Entry Diagram).

Fig. 1 .

 1 Fig. 1. Processes of Gas Turbine Concept Development phase

Fig. 2 .

 2 Fig. 2. Detail of As-Designed View (for privacy issues, meta-data are reported as example)