# PLM-Based Service Data Management in Steam Turbine Business

Patrick Müller, Michael Muschiol, Rainer Stark

► To cite this version:

Patrick Müller, Michael Muschiol, Rainer Stark. PLM-Based Service Data Management in Steam Turbine Business. 9th International Conference on Product Lifecycle Management (PLM), Jul 2012, Montreal, QC, Canada. pp.170-181, 10.1007/978-3-642-35758-9_15. hal-01526149

HAL Id: hal-01526149

https://inria.hal.science/hal-01526149

Submitted on 22 May 2017

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques 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.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
PLM-based Service Data Management
in Steam Turbine Business

Patrick Müller¹,*, Michael Muschiol², Rainer Stark¹

¹Fraunhofer IPK, Berlin, Germany
{patrick.mueller,rainer.stark}@ipk.fraunhofer.de

²Siemens Energy, Nürnberg, Germany
michael.muschiol@siemens.com

**Abstract.** This paper introduces a concept applied for a new PLM-supported process in steam turbine service business. The concept has been developed and instantiated in an industrial case: The paper starts with an analysis of engineering processes and the IT landscape in a globally acting company offering MRO (Maintenance, Repair and Overhaul) services for steam turbines. Illustrations show how digital product and service data is generated, edited, enriched, and managed throughout the lifecycle of a steam turbine. In order to enhance the already PLM-supported service process the concept for the new PLM process was defined within the company. The concept implements one single PDM system with interfaces to one dedicated ERP system. Illustrations of the new PLM process show how to manage product and service documentation generated throughout the steam turbine lifecycle. The paper provides first-hand experiences made in a PLM migration project, which implemented the new PLM process.

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

# 1 Introduction and Motivation

This paper provides first-hand experiences from 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 so-called 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 [1-2]. 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 [3-4].

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 [5]. 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 trace-link. 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.

## 1.2 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 [6]. 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.

## 2 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 man-
agement of engineering data. The following subsections explain a typical MRO busi-
ness case for energy systems.

### 2.1 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.

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

<figure><img src="image_2.png" /><figcaption>Fig. 1. Simplified Product Lifecycle of a Steam Turbine</figcaption></figure>

## 2.2 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. Often times, 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.

## 2.3 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) [7]. 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 managed 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).

<figure><img src="image_3.png" /><figcaption>Fig. 2. Generation of Product and Service Data over the Steam Turbine Lifecycle</figcaption></figure>

## 3 Concept of the new PLM Process

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 [8] and an SAP ERP [9] 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
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*.

<figure><img src="image_4.png" /><figcaption>Fig. 3. Framework for the new PLM Process Concept</figcaption></figure>

<figure><img src="image_5.png" /><figcaption>Fig. 4. Engineering Data generated throughout the Steam Turbine Lifecycle and PLM Process</figcaption></figure>
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.

<figure><img src="image_6.png" /><figcaption>Fig. 5. New Concept to store Engineering Data and Documents in the PDM System (Part 1)</figcaption></figure>

<figure><img src="image_7.png" /><figcaption>Fig. 6. New Concept to store Engineering Data and Documents in the PDM System (Part 2)</figcaption></figure>
# 4 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.

# 5 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.

## 5.1 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.

## 5.2 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.

## 5.3 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.

# 6 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 documenta-
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 stock – in 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 sys-
tem. 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 ne-
gotiations, 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 struc-
tures 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 [8], the proportion and functionality of PLM
will rise until 2020 not only for management of virtual products but also for the man-
agement of real, installed systems over the lifecycle. The approach presented in this
paper is in line with this expert vision.

References

1. DIN EN 13306: Maintenance Terminology, Trilingual version. 2001.

2. VDI 2246: Designing maintainable engineering products, basic princiles. 2001.

3. Müller, P.; Stark, R.: A generic PSS development process model based on theory and an empirical study. International DESIGN Conference, 2010.

4. Tukker, A.: Eight types of product-service system: eight ways to sustainability? Experiences from Suspronet. Business Strategy and the Environment; 2004.

5. Eigner, M.; Stelzer, R.: Produktdatenmanagement-Systeme. Springer-Verlag, Berlin, Heidelberg, 2009.

6. Uhlmann, E.; Röhner, M.; Behrendt, J.; van Duikeren, B.: Markt- und Trendstudie 2011, Maintenance, Repair and Overhaul, 2011.

7. Ladeck, Th.; Muschiol, M.: PLM im Kraftwerksbau. In: Tagungsunterlagen zum PLM-Kongress „Product life live“; November 2007.

8. SIEMENS PLM Software: http://www.plm.automation.siemens.com/en_gb/. (2012-05-20)

9. SAP ERP: http://www.sap.com/solutions/index.epx (2012-05-20)

10. Abramovici, M.; Bellalouna, R.; Neubach, M.: Delphi Studie PLM 2020, Experteneinschät-
zungen zur künftigen Entwicklung des Lifecycle Managements. ITM, Ruhr-Universität Bo-
chum.