Mill Model Concept for Paper Mill Life Cycle Management

Transcription

1 Mill Model Concept for Paper Mill Life Cycle Management Pekka Siltanen 1, Timo L. Syrjänen 2 1 VTT Information Technology, P.O.Box 1201, FIN VTT, Finland, pekka.siltanen@vtt.fi 2 Jaakko Pöyry Oy, P.O.Box 4, FIN Vantaa, Finland, timo.syrjanen@poyry.fi Abstract Interest in paper mill life cycle management has been increasing in recent years. One of the most important aspects in large-scale paper mill life cycle management is information sharing between the different stakeholders (engineering, procurement and construction contractors as well as mill owner-operators). The goal of the study was to create a common data model, allowing the technical data to flow smoothly from the product data management and engineering systems of the equipment suppliers and EPC companies to the maintenance management systems of the mill owner-operator. Requirements for the data model were such that it had to be consistent with the international standards, but also simple enough to be rapidly implemented to currently used applications. The developed solution is called mill model. This solution was tested by transferring data from existing product data applications to existing maintenance management systems that are used by the major stakeholders in the paper industry. Keywords Plant design, life cycle management, mill model, product model 1 Introduction In recent years interest in paper mill life cycle management has been increasing. Most of the efforts try to optimise one phase in the mill life cycle and discard the whole mill life cycle. A typical paper mill life cycle comprises the development, implementation, production and write-off phases (Figure 1). Business idea Approval of investment proposal Plant take-over Plant abolishment Development Implementation Production Write-off Figure 1: Mill life cycle phases There are many stakeholders acting in different roles in different life cycle phases. The owners and operators of the facilities consist of one company, which is responsible for creating and revamping of the facilities. They are also responsible for the operation and operation-related tasks such as maintenance. Engineering, procurement and construction contractors (EPC contractors) are involved during one or several mill life cycle phases. Equipment and system suppliers deliver their products and services with relevant information and documents. One of the most important aspects in the management of large-scale paper mill life cycle is information sharing between the different stakeholders. When the information sharing is

2 efficient, the quality of life cycle management will increase (cost effective, better design, shorter schedule, etc.). The information comprises all the information flows during different phases and within the involved organisations. It includes hard and soft, structured and unstructured, official and unofficial knowledge. Currently, most of the information carried through the entire mill life cycle exists only in documents, i.e. drawings, specifications, lists and textual descriptions. Documents are a practical and reliable tool in information sharing, but some problems arise when they are used [Port 1999, PaperIXI]: Several proprietary data formats Are the documents all consistent, up-to-date, and complete? The solutions mimic the traditional work processes The documents can be communicated and viewed, but updated/changed only with the original application The document file lacks a data structure it is difficult to process the information with a variety of computer applications Granularity is too large for good re-use of information Recording the relationships between the documents and the organisation s real business, such as its products or processes, is limited The documents themselves are not, however, important but the information in them is of importance. Therefore, we try to define how the information could be exchanged between the different stakeholders during the paper mill life cycle. Modelling of information instead of documents is nothing new [Talvio 1987], but it has normally been implemented by individual companies each of which has its own unintegrated - information management tools. Until recent years owner-operators were mostly interested in building, operating and maintaining their physical mill. The information collected during the different life cycle phases was not sufficiently integrated. The new information technology standards give new possibilities to build a virtual mill integrating all the information from the different stakeholders. The virtual mill can be viewed and maintained with various tools and it consists of all the data that defines the mill. This paper describes a simple data model for building such a virtual mill. The goal of the study was to create a common data model allowing the technical data to flow smoothly from the product data management and engineering systems of the equipment suppliers and EPC companies to the maintenance management systems of the mill owneroperator. Requirements for the data model were such that it had to be consistent with the international standards, but also simple enough to be rapidly implemented to currently used applications. The developed solution is called mill model and it is described in the section Mill model. The background of this paper is the project titled PaperIXI (Paper Industry Information Exchange [PaperIXI]), which was financed by the leading paper mill owner-operators, engineering consultants and equipment suppliers. The current design practices in the industry today were studied by interviewing employees of the companies participating in mill construction projects. Research and development within information exchange in the EPC industry were studied. Research and standardisation development primarily deal with data transfer from the design to the construction on one hand, and with the design theory in general on the other hand. These approaches are briefly described in the section Existing work. The developed solution was tested by transferring data from existing product data applications to existing maintenance management systems. The testing methodology was to

3 try to exchange technical data with existing applications to ensure that the new methodology is consistent with the current practices and internal data models of the applications. The results of these tests are described in the section Testing of the mill model concept. This study only focused on the management of technical data. Several issues, such as project management and the design process as a whole, were left to further research. Future research needs are described in the section Conclusions. 2 Existing work The need to exchange information in a large design project on the level of product data instead of documents is not new. Product information management and sharing have been standardised in ISO [ISO ], known as STEP, which aims at data exchange based on standardised information models. STEP-based standards have been developed in many industry sectors, including the process industry (STEP AP 221 [ISO ] and EPISTLE [EPISTLE]). STEP standards are not, however, widely used in the paper industry. The reasons are similar to those found in the construction industry [van Nederveen, Tolman, 2001]: The industry is fragmented and often on small scale There is no ICT support for the standards in the currently used applications There are also other more general reasons why STEP standards have not been successful in the paper industry. It seems that the ISO standardisation has not been able to meet the requirements for successful standardisation as stated by Tarandi [Tarandi 1998]: The standardisation process should be as short as possible The standard should be easy to understand The standard should be easy to implement The companies and software developers should be able to focus their implementations on a limited number of standards There should be legitimating bodies supporting the standards Industry Foundation Classes (IFC) is a standardisation effort in the construction industry by International Alliance for Interoperability [IAI]. The IFCs are essentially standardised CAD objects in which the technical data of the product is linked to its geometry. IFCs contain definitions for the properties of several product classes used in construction. The methodology of representing large and complex entities, such as paper machines, has traditionally implied a divide and rule method, i.e. the entities have been represented as hierarchical structures. For example the hierarchical part-of graph [Mäntylä 1990] and hierarchical tree structure [Lee, Gossard 1985] describe examples of using hierarchical structures in representing product assemblies. When complicated machinery or entire mills are designed, product assemblies are often used in parallel with the functional structure, which describes the product hierarchy from a functional point of view [Mäntylä 1990]. The functional view may be different depending on the viewer s discipline: the functional structure of the mill for an electrical designer is different from the one for a mechanical designer. The functional view is necessary not only in the design stage of the product life cycle, but also when the mill is in operation [Partridge 2002]. Partridge describes how the product manufacturer and mill maintenance see the product as a physical individual that has a serial number and maintenance history, while the designer and mill operator see the product as a logical product that has the same properties even if the individual product fulfilling its

4 function is replaced. A similar approach is described by West [West ], and there the logical product is called a replaceable part. So earlier research has shown that there is a need to manage not only product assemblies, but also the functional and logical structures of the mill, and seen from several viewpoints depending on the life cycle stage of the mill. Designing data models fulfilling all the requirements is a difficult task that is described by West and Fowler [West, Fowler, 1996]. Often the data models are divided into general concepts, containing the most generic and stable concepts, and into reference data, containing the more specific concepts [West ]. E.g. EPISTLE generic concepts (Core Model) [ISO ] consist of 201 concepts, while EPISTLE reference data (Reference Data Library) consists of several thousands of concepts. A similar approach has been taken by the electronics and telecommunication industries standardisation organisation RosettaNet that has defined a generic XML schema for the product data exchange and a technical dictionary [RosettaNet] for defining the specific concepts. Another approach to the information sharing problem is the one taken by the design scientists trying to define general ontologies for design. Gero [Gero 1990] defines a knowledge representation schema for design activity. A similar approach is presented by Pohjola [Pohjola 2001]. Gero argues that any object to be designed can be defined by the list of three 'classes of variables' - Function, Behaviour and Structure -, while Pohjola states a commitment that any object can be defined using four 'attributes' - Purpose, State, Structure and Performance. 3 Mill model Concepts similar to the mill model have been used earlier in the paper industry, but they have not been targeted to the whole mill life cycle so clearly. Especially in the engineering phase the use of such a model has become more of a rule than exception. Only in few cases the engineering model has been taken into use in other phases, or by the owner-operator. The purpose of the mill model is to keep the mill data management as simple as possible enabling an easy implementation and use by the different stakeholders. Consequently the model is static excluding any dynamic nature and other behavioural aspects. The model is best suited for data transfer and static operations. The model is defined on the basis of IEC standard [IEC ] and EPISTLE. IEC standard defines the functional, product structure and location-based views to handle mill objects. The definition of the mill model concept follows the typical plant project life cycle from the different stakeholders view point. The mill model concept includes object creation and the relations between the objects. The mill model is an object-oriented system in which the model is a collection of mill objects describing one mill or a part of the mill. The mill objects have relations to other mill objects or external objects. The model can be presented in different hierarchies. The mill objects are described in the following sections, and the corresponding concepts of the main object types in EPISTLE are described. 3.1 Mill object A mill object is a data instance that contains technical data of one piece of mill equipment or function. The data contents of the mill objects are defined in the object class definition, i.e. technical attributes needed for the object of class motor are different from the class pump. Various classifications are used in the paper industry, and the mill model concept should allow the use of the most relevant classification system. The mill model concept is built so that the classification can be implemented by using a reference library of the EPISTLE or

5 RosettaNet type or by implementing classes directly as subclasses of the main mill model object types. Figure 2: The main mill model object types The main mill model object types are called function, product and individual (Figure 2). Each of them has the following parts: Identification comprises elements to identify the mill object, such as tags, names, IDs, etc. For example, in the function tag it is a position number, in the product it is the manufacturer s product code and in the individual it is a maintenance system equipment code. Properties are connected to each object. The object s class definition gives the properties, which belong to the object. The standardisation of properties is important, and in many cases the classification system already has property definitions. Relations connect objects together with a reference. For example a link from the function to the product implementing the function is a relation. Relations can be references to internal or external objects. Relations are needed because the mill model can be divided between different stakeholders. This division can be based on the function, product or individual, or on other aspects such as a mill department. Attachments can be a document, drawing, bill of material, operation manual or any other description associated with a mill object. The mill model is not targeted to be used as a document management system; so only the relevant metadata of the attachments are combined with the model. 3.2 Function When a new mill is designed the first phase is to create a functional structure of the mill. A function describes the purpose of an object in a mill model and it comprises functional and environmental requirements. For example a pump, defined by the designer on the process diagram, describes a media transfer function, which often is implemented with a pump individual. In projects EPC companies create most of the needed mill model functions.

6 EPISTLE s fuctional_physical_object closely resembles the function object type in the mill model. 3.3 Product After the functions have been assigned, the designer selects a product that meets the function requirements from the equipment supplier s product catalogue. A product is a generic description of a component or a piece of equipment. The product includes also its properties defined by the product supplier. The product suppliers are responsible for creating libraries of this object type. These can be used by the other equipment suppliers, EPC companies or the owner-operator. It seems that EPISTLE does not have any clear resemblance to this object type. 3.4 Individual When a product is ordered or manufactured, it becomes an individual with its own life cycle. An individual is a real physical mill object, which has an existence and a life cycle. In a mill environment the individuals are often described as equipment. For example a particular pump with a serial number is an individual. The owner-operators are mainly interested in individuals because the maintenance system mainly deals with individuals, which are often called equipments. EPISTLE s materialized_physical_object closely resembles an individual object type. 4 Testing of the mill model concept The concept was tested by creating an XML schema [XML] implementing the data model described above. The XML data elements for all the mill model concepts were defined and the RosettaNet technical dictionary format [RosettaNet] was selected for representing the classifications. The XML data format was used in the data exchange tests between several product data applications. A prototype mill model server was implemented. It was used to combine the mill functional model, produced by the engineering consultant and the mill maintenance personnel, with the technical data supplied by the equipment suppliers and system integrators (Figure 3). The technical data was exported from the data suppliers product data management systems: ematrix by MatrixOne and Vertex by Vertex Systems. The data was imported into the SAP system by SAP AG and PowerMaint DataExchange by TietoEnator Corporation. Paper mill maintenance management Mill modernisation: removing old individual structures Product structures from equipments suppliers Combining functional structure and product structures Functional structure Individual structures Figure 3: Information of the rebuilt equipments were removed from mill maintenance system and replaced with new data from equipment suppliers

7 The main goal of the test was to ensure that the data model and the data format defined in PaperIXI can be used for combining the suppliers data with the mill maintenance system. This goal was clearly achieved, even though the volume and complexity of the data were quite limited. The following summary of the challenges was identified during the test: The amount of data which was found in the suppliers systems and used in the test was quite small. It was estimated that only half of the data that the supplier in principle could provide was found in a structured format. The rest of the data is distributed in manuals, contracts, and minutes of meetings or is in other formats that cannot be easily exchanged automatically. There was no common reference data in the suppliers and mill s systems (e.g. classification, units of measurement, currency, country codes, etc.). Transformations were needed to convert these data values. Despite the identified challenges, all of the technical data that was needed by the mill maintenance was transferred by using the mill model methodology. Technical challenges naturally exist - most applications used in practice are old software versions that do not have modern data exchange interfaces - but it seems possible to achieve significant cost savings by utilising this mill model methodology. 5 Conclusions The mill model management methodology was discussed. The mill model is a generic data model that can be used for defining the functional mill structure together with product structures of the equipments implementing the mill s functionality. The technical properties, documents and relations between the mill objects can be expressed in the mill model. The main conclusions of the research were: the currently available international standards have not been successful in the paper industry due to missing applications support, as well as complexity and slowness of standardisation, the mill model methodology, based on only three basic object types, i.e. function, product and individual, is sufficient for handling practical needs in current data exchange, the mill model methodology is easily understood by the users and easily implemented with available applications. The paper industry seems to be ready to standardise product information exchange methodologies in the near future. The change from a document-centric world into a modelcentric world requires that easily implemented methods, such as the mill model methodology described here, are used. However, changes in project practices require also changes that encompass not only technical data exchange issues, but also legal and project management issues. The reason for this is that the current contacts and project management practices are based on document exchange. Project management seems to be the next logical step in future research. The generic design ontologies, such as PSSP ontology [Pohjola 2001] or POP ontology [Garcia, Kunz, Ekstrom, Kiviniemi 2003], might offer a solid background for integrating the project management and data management. These issues are studied in the project called NDC (New Design Culture [NDC]).

8 Acknowledgement This work has been funded by Tekes - National Technology Agency of Finland -, VTT Technical Research Center of Finland - and the companies participating in the PaperIXI project: ABB, Jaakko Pöyry, KCI Konecranes, Metso Paper, M-real, PMC Polarteknik, Siemens, SKF, Stora Enso, TietoEnator and UPM- Kymmene. The authors wish to acknowledge Tekes, VTT and the PaperIXI companies for the support. We also wish to acknowledge our gratitude and appreciation to all the PaperIXI and NDC project partners for their contribution during the development of various ideas and concepts presented in this paper. References EPISTLE: The European Process Industries STEP Technical Liaison Executive. WWW page Garcia Ana, Kunz John, Ekstrom Martin, Kiviniemi Arto: Building a Project Ontology with Extreme Collaboration and Virtual Design and Construction, Technical Report TR152, Center for Integrated facility Engineering, Gero John S.: Design prototypes: a knowledge representation for design, AI Magazine, Vol 11, No 4, 1990, p IAI: International Alliance for Interoperability. WEB page IEC : Industrial systems, installations and equipment and industrial products. Structuring principles and reference designations. Part 1: Basic rules ISO : Industrial automation systems and integration-product data representation and exchange-part 1: Description methods: Overview and fundamental principles, 1994 ISO : Functional data and schematic representation for process plants. Part 221: Application protocol: Process Plant Functional Data and its Schematic Representation, ISO/IEC, Geneva, Switzerland, 1995 ISO : Industrial automation systems and integration - Integration of life-cycle data for process plants including oil and gas production facilities - Part 2: Data model. Lee Kunwoo, Gossard David C.: A hierarchical data structure for representing assemblies: part 1. Computer- Aided Design, Vol 17, Issue 1, 1985, p Mäntylä Martti: A modeling system for top-down design of assembled products. IBM Journal of Research and Development. Vol 34, number 5, 1990, p NDC: New Design Culture project, WWW page van Nederveen Sander, Tolman Fritz: Neutral object tree support for inter-discipline communication in largescale construction. ITcon Vol. 6, pg , WWW page Port Stanley: Industry s Needs for Managing Plant Data versus Today s Solutions. PIM 99 Plant Information Management Conference. Hague, Netherlands 9-10 November PaperIXI: PaperIXI project, WWW page Partridge Chris: What is pump facility PF101? LADSEB-CNR - Technical report 04/02, Pohjola Veikko, POEM Guide Book. Introduction to SHE conscious process design. University of Oulu Press, Oulu, Finland, 2001 RosettaNet: RosettaNet Technical Dictionary, WWW page Talvio Paul: Today s design systems keep all parties involved on a daily basis, Pulp and Paper, September, USA Tarandi Väinö: Neutral Intelligent CAD Communication. PhD Thesis, KTH, Sweden West Matthew, Fowler Julian: Developing High Quality Data Models (Version 2.0) EPISTLE, WWW page West Matthew: Replaceable Parts: A Four Dimensional Analysis. COSIT'03 - Workshop on fundamental issues in spatial and geographic ontologies, West, Matthew: Common Reference Data - the foundation of e-business, PDT Europe XML: XML Schema. WEB page h