A framework for effective management of condition based maintenance programs in the context of industrial development of E-Maintenance strategies

1 A Framework for Effective Management of Condition Based Maintenance Programs in the context of industrial development of E-Maintenance strategies. Antonio J. Guillén*, Adolfo Crespo, Juan Fco. Gómez, Maria Dolores Sanz University of Seville, Department of Industrial Management, School of Engineering, Sevilla, 41092, Spain ABSTRACT CBM (Condition Based Maintenance) solutions are increasingly present in industrial systems due to two main circumstances: rapid evolution, without precedents, in the capture and analysis of data and significant cost reduction of supporting technologies. CBM programs in industrial systems can become extremely complex, especially when considering the effective introduction of new capabilities provided by PHM (Prognostics and Health Management) and E-maintenance disciplines. In this scenario, any CBM solution involves the management of numerous technical aspects, that the maintenance manager needs to understand, in order to be implemented properly and effectively, according to the company’s strategy. This paper provides a comprehensive representation of the key components of a generic CBM solution, this is presented using a framework or supporting structure for an effective management of the CBM programs. The concept “symptom of failure”, its corresponding analysis techniques (introduced by ISO 13379-1 and linked with RCM/FMEA analysis), and other international standard for CBM opensoftware application development (for instance, ISO 13374 and OSA-CBM), are used in the paper for the development of the framework. An original template has been developed, adopting the formal structure of RCM analysis templates, to integrate the information of the PHM techniques used to capture the failure mode behaviour and to manage maintenance. Finally, a case study describes the framework using the referred template. KEYWORDS: CBM management, E-maintenance, Failure Mode Symptom Analysis (FMSA), Detection, Diagnosis, Prognosis. 1. Introduction Condition-Based Maintenance (CBM) is defined by EN 13306:2010 as “Preventive maintenance that includes a combination of condition monitoring and /or inspection 2 and/or testing, analysis and subsequent maintenance actions” (CEN, 2010). ISO 13372:2012 standard defines CBM as “Maintenance performed as governed by condition monitoring programmes” (ISO, 2012a). CBM monitors the condition of components and systems in order to determine a dynamic preventive schedule (Niu,Yang and Petch, 2010). In the literature, it is also possible to find CBM referenced as a system, a program or a solution. The standard ADS-79D-HDBK (United States Army, 2013) defines a “CBM system” as that it includes the analytical methods, sensors, data acquisition (DA) hardware, signal processing software, and data management standards necessary to support the use of CBM as a maintenance approach to sustain and maintain systems, subsystems, and components. A “CBM solution” can be understood as the application of a particular monitoring solution to a specific case (failure mode or element). A “CBM program” comprises the application of the different CBM solutions that have been adopted for a particular system (Parra and Crespo 2012), and it involves management and maintenance task planning. CBM is increasingly becoming common in industrial systems, improving the transition from maintenance approaches that combine run-to-fail and programmed preventive maintenance to more efficient maintenance approaches (Jardine, Lin and Banjevic 2006). In recent decades, the emergence of cheaper and more reliable ICT-Information and Communication Technologies (intelligent sensors, personal digital devices, wireless tools, etc.) has allowed an increase in the efficiency of CBM programs (Niu et al 2010). In automated manufacturing or process plants, CBM is preferred wherever it is technically feasible and financially viable (Campos, 2009). The classical industrial view of CBM is mainly focused on the use of Condition Monitoring (CM) techniques such as vibration analysis, thermography, acoustic emission or tribology (ISO, 2011). The recent development of the PHM discipline (Prognosis and Health Management) is promoting a new CBM, providing powerful capabilities for physical understanding of the useful life of a system through dynamic pattern recognition (Vachtsevanos, Lewis, Roemer, Hess and Wu, 2006; Lee, Ghaffari and Elmeligy, 2011). These capabilities allow us to treat, efficiently, new maintenance challenges in modern systems and applications (Zio, 2009; United States Army, 2013). This new CBM, CBM+ (Jaw & Merrill, 2008) or CBM/PHM (Vatchsevanos et al 2006), is the main pillar for the implementation of E-maintenance strategies, where CBM develops its full potential through a more proactive maintenance management. However, there is still a large gap for effective implementation of these new CBM programs extensively in industry, mainly due to complexity of these solutions and their life cycle. To this end, we propose two practical tools to represent and understand the key points of a CBM solution life cycle: 3 (i) A framework, a basic structure to facilitate the representation of any CBM solution; and (ii) A template, in table format, that will complement RCM results tables, integrating the information of the CBM solution for a particular existing failure mode). The paper is organized as follows: Section 2 presents and justifies the CBM management approach within the context of E-maintenance strategies, and complexity of its practical implementation. Section 3 develops the proposed framework and its structure, which is depicted with an UML schema. Section 4 introduces the proposed template for CBM solutions compilation in a practical example. Finally, Section 5 presents the paper conclusions. 2. CBM management within a E-maintenance context 2.1. On the role of CBM as pillar of E-maintenance Information and Communication Technologies (ICTs) are transforming the way systems are maintained, they provide the support to generate more systems behaviour knowledge and to introduce new tools and processes for a more proactive maintenance. This maintenance support, has been defined as E-Maintenance (Muller et al., 2008): “Maintenance support which includes the resources, services and management necessary to enable proactive decision process execution. This support includes e-technologies (i.e. ICT, Web-based, tether-free, wireless, infotronics technologies) but also, e-maintenance activities (operations or processes) such as e-monitoring, e-diagnosis, e-prognosis, etc.”. E-maintenance is a broader concept than CBM. Macchi and Garetti (2006) claims that Emaintenance provides a new working context extending the service maintenance to a knowledge-driven organization, where the information flows integrating diverse processes (especially those related with monitoring and CBM), knowledge providers (technicians of the service provider, machinery builder/engineers/technicians, and operators on field), and expert/decision support systems (intelligent systems). Monitoring, diagnosis and prognosis are the basic concepts of CBM (Zio, 2009), three terms appearing in the above definition of E-maintenance. Thus, it is possible to claim that CBM is a basic element of E-Maintenance. This CBM concept is here understood as an "extended" CBM, where the classical methods of condition monitoring are completed with the new outcomes of an innovative and emerging discipline: PHM. To underline this evolution from the classical CBM view, different terms have been proposed in the literature to name this new concept: CBM+ (DOD, 2008), CBM/PHM (CBM enable by PHM) (Vachtsevanos et al. 2006) or the use 4 of the concept PdM (Predictive Maintenance) with this meaning (Gupta, Trinquier, Lorton, Feuillard, 2012). Sometimes the borders and differences between terms like E-Maintenance, CBM+ , PHM and CBM are not clear enough. Simultaneous reference to so many terms can produce great confusion in future practitioners. Figure 1 tries to organize them according to the maintenance types evolution. It shows how CBM evolution is enabled by PHM capabilities; likewise, E-maintenance strategies facilitate a degree of proactivity, supporting greater control and capacity to act on the systems, including efficiency and effectiveness of maintenance plans monitoring (Muller et al., 2008). Fig.1. Positioning CBM with respect to E-Maintenance (Guillén et. al 2016) To simplify terminology, in this paper the term CBM should, from now on, be understood as the new global CBM and the E-maintenance strategies its application framework where CBM can provide more value and better results. Macchi et al (2014) underline this link between E-maintenance and CBM as an evidence of the fact that advanced ICT solutions are being adopted in manufacturing processes in order to progressively change the maintenance management policies. To this concern, automation over available CBM services is crucial to build manufacturing value-driven solutions. This perspective is well synthesized by the conceptual E-maintenance framework provided in Levrat, Iung and Crespo (2008), where the role of CBM is acknowledged from a business point of view by its potential to improve services, processes, organisation and infrastructure. Until this moment, the CBM research contributions have been focused on structuring technological issues (models, methods and algorithms) for their application to concrete systems (Lee et al 2011), without discussing the specific techniques and methods required Run to fail Schedule Maintenance Classical CBM CBM enable by PHM (CBM/PHM) CBM+ More Proactive Maintenance PHM skills & solutions E-maintenance Reliability Modelling Classical Techniques of Condition Monitoring 5 to fulfil the envisioned goals in future maintenance processes. It is necessary to understand how to apply CBM techniques and methods conveniently, controlling their implications in a sustainable and efficient way. The relevance of CBM within E-maintenance justifies the need to analyse the problem of the use, comprehension and applicability of CBM solutions. In fact, there is no CBM/PHM methodological framework covering the management of CBM besides the technical aspects of these solutions. This CBM management approach is the scope of this paper. The notion “framework”, as in standard conceptual computing models (Jayaratna 1994), used to transmit or address complex issues about some area of knowledge through a generic outline or approach. From a computational context, the reference frameworks serve as templates for the development of specific models and the implementations in a determined scope (ISO15704 2000). In our case, the abstract representation of entities and their relationships will be implemented by UML computer language. Unified Modelling Language (UML) is a well-known graphical language used for specifying, visualizing, constructing and documenting systems. The UML has proven to be successful in the modelling of many large and complex systems (Wu et al. 2006). 2.2. Complexity Causes and Implementation Challenges of CBM programs CBM programs have received several criticisms due to their complexity (Pintelon and Parodi-Herz 2008) (Kobbacy 2008) and to their challenges for practical implementation (see graphic description in Figure 2): • Depending on the type of company, the coverage of this program will be more or less complex and so will be the devices required to accomplish this process. It can be monitored the entire plant, critical equipment or only their critical functions. o The challenge of this cause is to apply the real coverage according to the cost benefit analysis of the program. • The system contains a large number of sub-systems and components. This case generates a wide variety of maintenance situations that can be handled using different models and methods. Most of the analysis is conducted at a single equipment level, and: o The challenge is to employ escalating to its surrounding assets of the plant. A generic and scalable prognostic methodology or toolbox doesn’t exist. • CBM contributes to asset failure reduction thanks to improve the root-cause detection in a short time, providing means for conveying spatial and functional information to operators. The existence of isolated transmission of information and knowledge into islands of specialties or departments normally hampers teamwork and improvements in intergroup activities. 6 o The challenge is how structure the information sustainably and interrelated properly and how present it in a form which they can assimilate, decreasing mismatches between perceived and real risk, improving rapid decision on critical incidents. That is, defined in a clear and unambiguous way, providing support for decision-making through visual and symbolic representations, simulations and analysis. • Instrumentation and tools precision, reliability and allocation are crucial frequently unevaluated previously. o The challenge is to define these in advance in order to obtain valid information, measurable on homogenous basis, but with the caution of defining for each specific application instead of in a general sense. • The measurements change according to location, not all measurements are valid in all assets. o The related challenge is to define the circumstances in which CBM can be applied, detecting changes that can invalid the measurements. Then, location changes have to be measured continuously. The changeable nature of large technical systems will present constant challenges and many developed CBM programs have been demonstrated in a laboratory environment, but are still without industry validation. All these difficulties highlight the need to develop special computerized systems that can cope with the management of complex engineering systems. • A CBM program is based on identifying physical changes on equipment conditions, their operation and operation environment. A crucial aspect of this process is to identify equipment patterns triggering warning or alarm messages. The objective is to detect or estimate equipment degradation from normal conditions; consequently to determine the degradation nature and behaviour could be difficult. o The challenge is to define the degradation model, whenever possible, in the simplest and most synthetic way easy to use and providing fast feedback. The models should be according to the problem severity, linking more factors only if the contributions of them are vital. • The CBM application is bad selected to the problem to solve. o The challenge is to have a better problem analysis and identification, providing documented specifications and useful information. These tools may help in reducing the time and resources devoted to decisions to solve repetitive problems instead of singular problems. • Normally, CBM measurements require specific skills or qualifications, but also the results interpretation. The pattern of degradation depends on the nature of the physical variable and there are diverse international recommendations for each type of variable used: temperatures, pressures, vibrations, amperage, voltage, displacements, humidity, amplitudes, thickness, cracks, presence of chemicals or particles, etc. There is no expertise regarding modelling and statistical techniques. 7 This expert knowledge can be absent in the company or contracted to an inadequate provider. o Then four challenges arise from this, first to verify the technical organizational attitude, second to collect and incorporate expert knowledge (tacit and explicit) to the problem, incorporated after consensus which increases satisfaction and motivation, third to have better analysis consistency with expert knowledge, improving quality and applicability of decisions, in a way that risks decrease, and fourth to train and update the organization in CBM. • The results should be directly related to the company objectives, they must also adopt financial measures. If this is not adopted at the beginning, managers can lose their faith in the program, and with periodic trends to forsake or reduce the program. o The related challenge is to analyse the return on investment previously, check the results, visualize the the progress and success, and share the achievements of the program. It should generate a return on investment that could be between the range from 10:1 and 12:1. • It is important to determine the items and ultimately the parameters which need to be monitored. This depends on the importance of the item criticality, on the criticality of its failure modes (Failure Mode Effect and Criticality Analysis - FMECA). This information can be obtained by eliciting knowledge from the maintenance staff; of course, this is not a trivial process. The information is often locked away in the heads of domain experts and many times the experts themselves may not be aware of the implicit conceptual models that they use. o The challenge is to elicit staff knowledge, drawing out and making explicit all the known knowns, unknown knowns, etc. Another challenge is to develop a more versatile and with a multipurpose staff. Flexible maintenance organizations should be enhanced to facilitate the exchange of knowledge and the teamwork in a confident and motivational environment, avoiding obsolescence and focusing on continuous improvement. • The patterns have to be reviewed periodically to be properly tuned using the same or different methods and including additional information or knowledge from recent experiences. o The related challenge is that CBM programs have to be designed for continuous improvement rather than only monitoring purposes, and also for internal and externally comparison. • CBM activities execution by hand weighs down the consistency of measurements and analysis. o Automation is the challenge. By automation we improve the responsiveness, we reduce complexity, costs and errors in the processes, and also the information is continuously updated, thereby the quality of decision making increases. Additional challenge is decide the provision of higher levels of intelligence and 8 modelling layers, allowing automatic and fast root cause and weak point analysis. Fig.2. CBM Complexity Graph. Entities, attributes and relations. The complexity of a CBM program is represented in the relationships diagram in Figure 2. Entities with solid line edges are entities correlated with all the rest of the entities, and they have been drawn separately. This Figure shows how, in a CBM program, the concepts have to be considered in a correlational and descriptive way, but not only from a technical point of view, but also from a financial point of view. To minimize the error in the development of a CBM program, to tackle this complexity, the analyst must work at three different levels (Russell and Norvig, 2004): i. In the first level, the objectives and scope of the analysis are defined, delimiting the available technologies and knowledge collection as basis of the next level. ii. The second level is related to the expert’s knowledge; this will include appropriate criteria for pattern recognition including possible data correlations. The pattern is documented and represented with the intention to make the knowledge explicit and to facilitate simulation and verification. In case of a negative verification, the flow is guided towards an adjustment program where the causes of this negative result are analyzed and documented for a first level refinement. If no pattern is recognized the flow ends. iii. The third level chases the generation of new knowledge in the organization based on the verified and explicit pattern, which will be standardized and studied. In the case of potential serious repercussions during the implementation, the flow is 9 redirected towards the first level allowing a modification; otherwise the implementation is carried out searching for the process automation. Automation is developed in proportion to the maximum level of intelligence, as a support system or expert system. Finally, in addition to the produced prediction and studies, implementation activities could be generated internally or externally as a demanded perfective proposal and depending on the scope of the changes. After the implementation this process has to be reviewed again over time updating information for a sustainable future. The CBM program requires up-to-date data, information and ultimately knowledge about the assets. The development, management and distribution of assets maintenance knowledge is considered as a foundation for the continuous improvement in CBM program. In consequence, the causes of the complexity of a CBM program can be determined along with the Knowledge Management discipline. Davenport and Prusak (1998) define knowledge as “a fluid mix of framed experience, values, contextual information, and expert insight that provides a framework for evaluating and incorporating new experiences and information”. We have experienced that there is a large amount of dispersed knowledge about assets, which is frequently unprofitable, unknown or inaccessible, and therefore cannot help to process improvement. 2.3. CBM Management approach In order to manage the proper adoption of CBM enabling capabilities, each phase of a CBM program life cycle has to be considered: design, implementation and operation; and a continuous review of objectives, on going and planned activities, and results will introduce changes and new requirement that will modify the CBM plan. 2.3.1. The CBM management issue. Principal references There are references in the literature that somehow try to approximate to the CBM management issue, as ISO 17359:2011 (ISO, 2010), ADS-79D-HDBK (Unites State Army, 2013) or the CBM+ DoD Guide Book (DOD, 2008). • The ISO 17359:2011 standard in order to establish a condition-monitoring program provides a process over the use of the introduced concept of symptom. This standard works with the traditional view of CBM industrial applications, comprising from the equipment analysis to the maintenance action determination point of view. • ADS-79D-HDBK standard (United States Army, 2013) is focused on aircraft CBM applications and provides a very practical approach too, detailing basic concepts and providing practical guides for the application of main measurement techniques for aircraft maintenance. Different processes to manage the implementation of CBM system for new development and legacy system are presented. • CBM+ DoD Guide Book (DOD, 2008) presents the CBM+ referred above in section 2.1. This is a concept halfway between CBM and E-maintenance. Not only it includes prognosis and diagnosis capabilities and the technological (hardware, 16 The blocks that we have identified include different abstraction levels. At first glance, it may seem difficult to combine them. But the fact is that all CBM solution involves all these issues and different abstraction levels have to be managed and this is the challenge. Besides we have to think in E-maintenance scenarios, where hundred or thousand CBM solutions will be applied within a complex engineering systems. Thus, formal approaches as it is proposed with this framework are needed. This approach introduces a formal and standard treatment that allows: • Overall treatment of the solution, assuring that all relevant aspects are considered, avoiding mistakes and low performances. • Suitable knowledge management regarding CBM applictions. • Scalability and replicability of CBM applications. Four of the blocks are corresponded with maintenance processes (blocks 1, 2, 4 and 5) and one additional block dealing all the information resources (block 3) according to the indicated previously Russell and Norvig (2004) ideas. The sequence of blocks can be interpreted as basic process to analyse any CBM solution. The first two blocks are not only specific to CBM solutions, but they are essentials of any maintenance management application. In the proposed structure, the explicit inclusion of physical and functional elements is mainly due to two reasons: firstly, it is necessary to connect the CBM with RCM view, as mentioned in previous section; secondly, the definition of the rest of the elements of the structure depends on the way that failure modes have been defined as a result of these previous blocks. Table 1 summarizes the blocks elements and the references to deal the concepts of everyone. Block Elements Objective References: methods & standards B1 - System - Equipment - Maintainable Item Physical Description from system to indenture level ISO 14224 B2 - Function - Functional Failure - Failure Mode Functional description and failure mode definition RCM/FMEA/ FMECA, ISO 17359, IEC 60812 B3 - Sensor - Measurement Technique - System Variable - Monitoring Variable Information source management and technical resources. ISO 13374, OSA-CBM, ISO 17359 B4 - Symptom - Descriptor - Interpretation Rule Symptom description. Descriptors definition FMSA, ISO 13379, ADS79D-HDBK 17 B5 - Detection - Diagnosis - Prognosis - Maintenance Decision Monitoring outputs and decisions about maintenance (CBM outputs) ISO 13374, OSA-CBM, ISO 13381, ISO 17359 Table 1. Summary of the blocks in the framework for CBM management From now on, the purposes of all the five blocks are introduced in relation to their functionality inside the framework. 3.3. Blocks and components of the framework From a computational point of view, the elements of the framework and their relationships are represented in a general UML schema (Fig. 6), where for a better understanding of the descriptions, we address the reader to the example in Section 4. 3.3.1. Block 1. Physical description Physical structure is the most intuitive way to observe the system reality. In the physical structure, the system belongs to a plant, an installation, an industry, etc., and has different subsystems and components that can be physically distinguished. In the structure proposed, this block has been defined hierarchically according with of the ISO 14224:2006 general standard taxonomy (ISO, 2006) by: - Element 1.1: System. - Element 1.2: Equipment unit. - Element 1.3: Subunit. - Element 1.4: Maintainable item. 3.3.2. Block 2. Functional description Failure has to be used to indicate functional disorders of elements, of the whole experience surrounding their performance. Information about functional disorders is part of the aim of FMEA/FMECA analysis (Parra and Crespo, 2012), and has to be obtained by eliciting knowledge from the maintenance staff, but this is not a trivial process. The information is often locked away in the heads of domain experts and many times the experts themselves may not be aware of the implicit conceptual models that they use. Eliciting knowledge consist in drawing out and making explicit all the known knowns, unknown knowns, etc. This block can be summarized in the hierarchical structure through the definition of the following elements: - Element 2.1: Function. The action and activity assigned to, required from or expected from a system (ISO, 2012a). In fact, what the system user wants it to do (Moubray, 1997). The accurate definition of the functions includes the functioning standards determination. 18 - Element 2.2: Functional failure: the way in which a system is unable to fulfill a function at the performance standard that is acceptable for the user (Moubray 1997). - Element 2.3: Failure mode: event that is reasonably likely to cause each functional failure. It is also defined as the effect by which a failure is observed (ISO, 2012a). Maintenance management is focus on failure mode in order to preserve system functions (Crespo, 2007). The failure mode is the key concept for maintenance management (Moubray 1997), and its definition is the goal of this block and as central item of CBM process. There can be different ways to define the failure modes: Moubray (1997), ISO (2006), OREDA (2009) or Parra and Crespo (2012). In conclusion, the main output of this block is the failure mode determination. And this step will have great impact on the rest of elements in the following block. Jointly with the symptom (Block 4) is the key component of this analysis structure. Accordingly with the ISO14224 standard and RCM methodology, the relation among blocks 1 and 2 are depicted linking the physical structure elements and functional logic elements: • Equipment unit is related to Function: functions are defined at Equipment unit level; an equipment unit will have one or more functions. • Maintainable Item is related to Failure Mode: failure mode is defined for a Maintainable Item; a Maintainable Item will have one or more failure modes. 3.3.3. Block 3. Information sources. One of the main aspects for the maintenance manager control is where the information comes from. Actually, this is the core of the Data-Information process, introduced in previous section 2.3.2. CBM program will have to manage the presence of a great number of different information sources in an industrial system: sensors, software systems (control, operation and maintenance), monitoring devices and techniques, data bases, data warehouses, etc. (Cheng et al., 2010). The integration of all these information sources is a very complex task, and it is critical for the CBM aims, ensuring the reliability of the information and controlling the performance of the monitoring system (Vatchsevanos et al., 2006). The proposed structure includes a revision and an interpretation of the different terms that can be used to treat the information. This block provides a model to organize and interconnect the different types of information available that will be used in symptoms treatment (Block 5) and considering the separate analysis of three crucial aspects: • The physical support (sensor determination and location). 19 • The knowledge for the interpretation of the information (measurement techniques application). • The relationship with the rest of the organization performance metrics (system variables). Dealing with ISO 13374 and ISO 17359 jointly with OSA-CBM, the structure defines hierarchically the following concepts in this block: - Element 3.1: Sensor. The “sensor” term is related to the physic measurement process and its communication. A sensor generates a signal and that signal has to be processed and transmitted. The sensors and signals management are related to physical design of the data collection and communication process (Vatchsevanos et al., 2006). In this element it is possible to define the physical characters of the sensor and its location within the system (Chen et. al., 2010). The location of the sensor can be interpreted as related to a maintainable item. The information gathered from a sensor can feed one or more measurement techniques. - Element 3.2: Measurement technique. It is referred to the technical knowledge and the necessary equipment to observe a particular phenomenon. Techniques as thermography, vibrations or ultrasound analysis have been broadly applied during last decades. Instead of using a simple sensor, these techniques give information that allows to analyse and to interpret the behaviour of an asset. It is possible to refer to them in general with the expression “measurement techniques” There are much more techniques that can be classified as measurement techniques (ISO, 2011). Traditionally, the measurement techniques are introduced through periodic inspections, although recently in line with the future factory or the Industry 4.0 models, these measurement techniques are programed in automatic application. The outputs of measurement techniques can be included in one or more system variables. - Element 3.3: System Variable. This element includes any variable presented in any database related to the system that can model behaviour of good or bad performance of the system. For example, additional information to the obtained variables by measurement techniques: operational variables (from the SCADA), maintenance variables (from the CMMS), economic variables (from ERP), etc. - Element 3.4: Monitoring Variable. The monitoring variable list will include the variables that actually are going to be used in the CBM solution. As a result of below elements definition this term includes: (i) variables result of the processing of signals (from sensors), (ii) outputs of measurement techniques analysis expressed as variables; (ii) the System Variables that are used by CBM solutions. 20 Processed signals from sensors and processed variables from measurement techniques can produce one or more monitoring variables. 3.3.4. Block 4.- Symptoms Analysis The symptoms, how they are managed and interpreted in relation to the failure mode, are the key point of the approach here presented, disaggregating the general concept of symptom into three elements: the symptom, the descriptor and the interpretation rule. Before to describe these elements in details, it is necessary a previous review of the symptom concept. According to the definition of the ISO 13372 standard, a symptom is the “perception, made by means of human observations and measurements (descriptors), which may indicate the presence of one or more faults with a certain probability” (ISO, 2012a). Thus, a symptom implies that something happen in the system (presence of fault) and that we have the capacity to observe, or measure, some evidence of it (perception). The ISO 13372 definitions use the term “fault”. According with the definitions included in Block 2, here the fault concept has been exchanged by the failure mode concept, aggregating author opinions that consider this a more accurate concept. For example, the symptoms can give information of states before the failure (when failure mode is evolving), that allows more detailed interpretations with great relevance in most of CBM applications, while a fault is the state after the failure (CEN, 2011). On the other hand, the concept of perception is related with terms like sensor, variable, measurement technique, information source, etc. In addition, this standard introduces the concept of “descriptor”, as “feature, data item derived from raw or processed parameters or external observation” (ISO, 2012a). Finally, the measure provided by a descriptor has to be interpreted in order to represent information about the failure mode. So the use of each descriptor implies the definition of interpretation rules. This block is composed by the following elements: - Element 4.1: Symptom. A qualitative description of specific effects or causes that can be measured giving information about the failure mode. One failure mode can have one or more symptoms. On the other hand, a symptom can be related to more than one failure mode. In the proposed structure if a symptom is related to, for example, two different failure modes, the symptom appears twice in the structure, once with a code that associate the symptom with the first failure mode and other time with a different code related to the second failure mode. It is crucial, that descriptors definition and interpretation rules will be detailed for every single coded symptom-failure mode. A symptom will have at least one descriptor. 21 - Element 4.2: Descriptor. It is the feature or the specific measurement parameter that actually provide the monitoring of the symptom. A descriptor is related with one coded symptom and one symptom can have one or more descriptors. From the symptom definition, descriptors are measures, so an accurate definition is needed including all the characters of a measure: magnitude, precision, measure frequency, etc. (Cheng et al., 2010). The difference between descriptor and variable or parameter, is that the descriptor is related with a specific failure mode and produce one or more interpretation rules. Descriptor, in this sense, is also referred in the literature as Condition Indicator (CI) (United States Army, 2013; Saxena et al 2010) or as a feature (Vactchsevanos 2006). Another term sometimes used is the Health Indicators (HI). It is different from CI. HIs are indicators of maintenance action based on the value of one or more CIs (United States Army, 2013). CI is closer to monitoring while HI to interpretation. Descriptors can be developed recurrently towards sustainable evolution and accuracy in the CBM solutions. - Element 4.3: Interpretation rule: It is the description of how the descriptor values have to be interpreted or treated in order to get the monitoring outputs (detection, diagnosis, prognosis) for a failure mode. A unique descriptor can have more than one interpretation rules, so it has to be considered the necessity of detailing these rules accurately. For example, when the system presents two different possible operational standards, the same values of the same descriptor can be interpreted as normal behaviour on one standard and as failure evidence in the other. For example, the pick power consumed during the engine start is not a failure event, while the same value during regime functioning could be a failure. This can be interpreted as one descriptor with two interpretation rules. Therefore, in the context of a CBM solution, it has no sense to understand a symptom without, at least, one descriptor and an interpretation rule. They compose a unique entity for the interpretation of the monitoring of a failure mode. However, treating them separately, great advantages can be introduced: • The use of the symptom for introducing maintenance expert knowledge, without giving necessarily details of measures and data process details. Details will be included after with the descriptor and interpretation rule. • The possibility to easily improve or adapt the monitoring solutions. Sometimes, improve the solution only require, for example, changes of interpretation rule. • Introduce new monitoring solutions: by the introduction of new descriptors or new interpretation rules it is possible to obtain new solutions. • A better understanding of monitoring solutions (detection, diagnosis and/or prognosis), concentring the elements of this block in each of them but relating the knowledge in a sustainable way from detection, to diagnosis and prognosis (see Figure 3. 22 The interpretation rule element treatment can be extended in a recurrent way, that is, an interpretation rule can be based in one or others interpretation rule. In order to not complicate the paper and to focus it on the element that connect failure mode with information generation, the interpretation rule has not been divided into different elements as in some references. These references include in it other elements in order to concrete the interpretation of the information obtained, such as Health Index, Uncertainty Measurement and evaluation parameter of the performance of the monitoring objectives (detection, diagnosis and prognosis). Interesting references to the use of HI and Performance Metrics can be found by the reader in United States Army (2013) and Saxena et al (2010). Accordingly with the FMSA methodology, ISO 13379 and ADS-79D-HDBK standards, the relation among blocks with this block 4 are depicted next: • The failure mode element is linked to symptoms as qualitative description of the latter. • The link to the third block, allows the understanding of the symptom traceability and its descriptors, connected to the maintainable item, or vice versa, the monitoring variables are connected with the symptom through the descriptor definition. Then, any variable that is be used by the descriptors have to be distinguished as a monitoring variable. 3.3.5. Block 5.- Maintenance decision-making This block supports the two different types of outputs of the CBM process that were defined in section 2 (see fig 3): monitoring outputs and CBM outputs. Considering that it is possible to count and register events of the three types of monitoring outputs respectively (detection, diagnosis and prognosis), it makes sense to treat them as elements. For example, once it is established the descriptor and interpretation rule to obtain a specific failure mode detection, it is possible to register every detection event and control the performance of this solution (Saxena et al 2010) with a performance rate “failure mode event/right detections”. Similar consideration can be made with failure mode diagnosis and failure mode prognosis. In addition, it is important to understand than detection, diagnosis and prognosis are linked to different maintenance decisions. The maintenance decision depends on the objectives of maintenance. Two illustrative examples can be presented to show the differences between the maintenance decision linked with prognosis or detection: • In a first example, the maintenance objective is to extend the replacement period of equipment. We will use a prognosis solution since prognosis can provide a measure of the remaining useful life of a critical failure mode of this equipment, 23 thus we would able to programme the replacement of the equipment, from now until the estimated end of useful life. • In a second example, consider a failure mode where prognosis is not possible (it can happen when the failure mechanism is very fast) and it is critical because it causes the stop of the production of an important part within an industrial plan. In this case the maintenance objective is the maximum reduction of the down time. A detection solution can produce good results within this context, since provides information of the exact moment of the failure, allowing the maintenance resources to be promptly mobilized. - Element 5.1: Detection element. It focuses on the state of the machine or system. It enables to distinguish anomalous behaviours, comparing gathered data against baseline parameters (ISO 13379), detecting and reporting abnormal events. This is defined as CM (Condition Monitoring) by ISO 13379-1:2012 (ISO, 2012b) and SD (State Detection) by ISO 13374-1:2003 (ISO, 2003). Alerts and alarms management also related with the detection issue (ISO, 2011). Then, as in the example of the previous paragraph, one principal detection objective is to achieve the best possible performance by minimizing false positives and false negatives cases (Vatchevanos et al 2006). - Element 5.2: Diagnosis element. The ISO 13372 defines diagnosis as the result of diagnosis process and as determination of the nature of failure (ISO, 2012a). In this sense, within a complex system, this definition can be completed considering two different stages in diagnosis process: isolation, determining which component or more accurately which failure mode is affected; and identification, determining or estimating the nature (or causes) and the extent (size and time) of the failures or faults. It is also relevant to note that diagnosis can be done before the failure (the failure mode is evolving but the failure has not happened yet) and after the failure (Guillen et al 2016). It is focused on the failure modes and its causes. - Element 5.3: Prognosis element. Prognosis is focused on failure mode evolution. The estimation of future behaviour of the defined failure mode allows failure risk assessment and control. There are different types of outputs from various prognosis algorithms. Some algorithms assess Health Index (HI) or Probability of Failure (PoF) at any given point and others as Remaining Useful Life (RUL) based on a predetermined Failure Threshold (FT) (Saxena et. al 2010). - Element 5.4: Maintenance decision. With this element the CBM outputs are described. The maintenance tasks and general actions that are triggered as consequences of the monitoring outputs can be registered, listed and catalogued to be used within a standard process. They can be connected with the respective monitoring objectives, controlling their implementation balancing cost and performance of them. 24 The knowledge about the decision that a maintainer can take has great value. Actually all the CBM process is founded over this knowledge. We introduce the 3.4. Basic Structure. UML Diagram For a more detailed representation of the proposed structure, a being coherent with the CBM-OSA indications (MIMOSA 2011, ISO 2003), a UML diagram is used (Fig.6), showing a comprehensive view of the structure, elements and blocks, and the different relationships that can be establish among them within CBM solutions (Lopez-Campos et al 2013). 25 Fig.6. Basic structure for the CBM solution presented in an UML diagram. Figure 6 has been developed base on UML Class Diagram Notation. In this figure, classes of entities are represented by rectangular forms where the name of the entity is indicated in the top. A class describes a set of objects that share the same features, constraints and semantics (meaning). The classes can be associated, searching to link certain classes in May have 0..* May have 0..* 1 0..* 0..* 1..* 0..* Aggregation as binary association Composite aggregation is a "strong" form of aggregation Association is a relationship between classes which is used to show navigability 0..* Multiplicity in Aggregation, Composition, or Association *- Any number, nexactly n, 1-one, 0-zero, 0..*-zero or any 1..* 1..* 1..* 1 0..* 1 0..* 32 D2 R (t, OV1, OV2, OV6, MV1) · MTBF I2 whenever the condition D2 ≤ 0.2·MTBF, it is a warning of critical residual life to the next failure Table 6. Descriptor and interpretation rule of the symptom This table template has not considered the two first levels of the block 3 (Information sources), making independent the knowledge management among symptoms and their representative variables of the technology (sensors and measurement techniques or software systems) that makes the variables available. 4.3. Block 5 As we have anticipated, this CBM activity triggers a maintenance task. In this case for both interpretation rules, the expert group decided to dispose a preventive maintenance for this failure mode (see descriptors and interpretation rules in Table 6) in order to avoid the failure mode occurrence. Therefore, maintenance decision-making is automated by a prognosis monitoring output, so the Prognosis cell is selected in Table 7. Cod Failure Mode Cod Symptom Detection Diagnosis Prognosis 1.4.1 Lack of outflow 1.4.1.1 Relation of the oil temperature and the current output in the transformer   R Table 7. Monitoring objective selection 4.4. Final Template for the Use Case Finally, a template can be arranged to summarize the process followed for the failure mode 1.4.1. “Lack of outflow”, and the CBM activity (part of the CBM program) can be properly characterized in a unique table. This type of template is coherent with RCM output tables and completes them with CBM information. As the first columns of the template are coincident with RCM template, Equipment Unit with is code, Maintainable Item and its code, they have been omitted in Table 8. In Table 8 two failure modes are included with the intention to show the versatility of the process and the format adopted by the tables. The failure mode “1.4.1” using only one descriptor D1 and one monitoring output: prognosis; and the failure mode 1.1.1 “Core-Short Circuit” that has two monitoring outputs: detection and diagnosis. As a result of the expert group work, a very basic algorithm/rule allows to distinguish this failure mode and when it has occurred. The representation using a single table of all possible CBM activities in the solution facilitates the management of the program by the maintenance staff the decision-making 33 and the sustainable evolution with more available and accuracy measurement techniques, return-on-investment increment on measurement techniques implementation or new available system variables. 34 Cod Failure Mode Cod Symptom Cod Monitoring Variable Informatio n source Cod Descriptor Detec. Diag. Prog. Interpretation Rules 1.4.1 Lack of outflow 1.4.1.1 Relation of the oil temperature and the current output in the power transformer OV1 Upper oil layer temperature (oC) SCADA D1 R(t, OV1, OV2, OV6, MV1) R If D1≤ 0.2 (20%) it is a warning of a high risk OV2 Lower oil layer temperature (oC) SCADA OV6 Load current (A) SCADA MV1 Number of maintenance interventions CMMS 1.1.1 Short Circuit 1.1.1.1 Over-current considerably higher than service current, confirmed also by the presence of hydrogen and CO as a result of the arc OV5 Hydrogen Level (%) SCADA D5 OV5 R R When D6 is above 50% standard service values, and D5≥0 and D7≥0. OV6 Load current (A) SCADA D6 OV6 OV8 CO level (%) SCADA D7 OV8 Table 8. Example of the Proposed Template, including the description of the CBM activities, solution adopted, for two failure modes 35 5. Conclusions This paper discusses about the necessity of CBM management approaches in complex context of E-Maintenance strategies. In order to address the CBM management challenge, this paper proposes a framework with a template to clarify the concepts and to structure and to document the knowledge generation for a given condition-based maintenance solution. This framework fulfils, for consistency and robustness purposes, precise standards and well-known methodologies requirements. The CBM framework stresses the importance of concepts (such as fault detection, diagnosis & prognosis), and describes the key building blocks for the characterization of any CBM solution. The five blocks are consistent with the standards that have been included in each block definition, and represent different knowledge matters whose information is correlated in our structure framework. These blocks are traditionally supported by isolated software systems to administrate their information, so the main contribution of our framework is to swing the knowledge using four hinges to join the blocks: failure mode element, symptom element, descriptor element and interpretation rule element. Thanks to structure the relationships among elements, the CBM knowledge can be improved and evolved with the potentiality of capturing new information as monitoring variables inside e-Maintenance strategies. Any future change, modification, improvement, management of the solution will be very much facilitated and understood using the provided template. The framework and template have been exemplified for an electrical power transformer CBM solution. An UML model has been developed theoretically and implemented integrating databases in a prototype + software, which has been validated in practice, thanks to proper interoperability of well-known proprietary information systems. 6. Acknowledgements This research work was performed within the context of SustainOwner (‘Sustainable Design and Management of Industrial Assets through Total Value and Cost of Ownership’), a project sponsored by the EU Framework Programme Horizon 2020, MSCA-RISE-2014: Marie Skłodowska-Curie Research and Innovation Staff Exchange (RISE) (grant agreement number 645733 — Sustain-Owner — H2020-MSCA RISE2014). The authors would like to acknowledge the support of the Scientific Chair of MM BinLadin for Operation and Maintenance Technology at Taibah University, Madina, Saudi Arabia. 7. References Campos, J., 2009, Development in the application of ICT in condition monitoring and maintenance, Computers in Industry, 69, 1-20 CEN, 2010. Maintenance Terminology. European Standard, EN 13306:2010, European Committee for Standardization, Brussels. 36 Cheng S., Azarian M., Pecht M., 2010. Sensor Systems for Prognostics and Health Management, Sensors, 10, 5774-5797; Crespo A, Gómez J., Moreu P., Sola A, 2012. Modelling on-line reliability and risk to schedule the preventive maintenance of repairable assets in network utilities.IMA Journal of Management Mathematics, 1-14 Crespo A., 2007. The maintenance management framework. United Kingdom: Springer London Ltd. Crespo Marquez A, Gupta J. Contemporary maintenance management: process, framework and supporting pillars. Omega 2006;34(3): 313–26. Davenport TH, Prusak L (1998) Working knowledge. Harvard Business School Press 2000, Boston. DOD, 2008. Condition Based Maintenance Plus, DoD Guidebook. Department of Defense (USA). Guillén A.J., Crespo A., Macchi M., Gómez J., 2016, On the role of Prognostics and Health Management in advanced maintenance systems, Production Planning and Control (In printed) Gupta, J., Trinquier, C., Lorton, A., Feuillard, V., 2012. Characterization of prognosis methods: an industrial approach, European Conference of the Prognostics and Health Management Society, 2012. ISO, 2003. ISO 13374-1:2003 - Condition monitoring and diagnosiss of machines − Data processing, communication and presentation − Part 1: General guidelines ISO, 2006, ISO 14224:2006 - Petroleum, petrochemical and natural gas industries -- Collection and exchange of reliability and maintenance data for equipment. ISO, 2011. ISO 17359:2011 - Condition monitoring and diagnosiss of machines − General guidelines ISO, 2012a. ISO 13372:2012 - Condition monitoring and diagnostics of machines - Vocabulary ISO, 2012b. ISO 13379-1:2012 - Condition monitoring and diagnosiss of machines − Data interpretation and diagnosiss techniques − Part 1: General guidelines Jardine A., Lin D, Banjevic D., 2006. A review on machinery diagnosiss and prognostics implementing condition based maintenance, MechSyst Signal Process; 20:1483–1510. Jaw L., Merrill W., 2008. CBM+ research environment – facilitating technology development, experimentation, and maturation, in: Proceedings of the Aerospace Conference 2008, IEEE. Kobbacy KAH (2008) Artificial intelligence in maintenance in complex system. In: Kobbacy KAH, Murthy DNP (eds) Maintenance handbook. Springer, New York. Lee J., Ni J., 2014. Infotronics-based intelligent maintenance system and its impacts to closed-loop product life cycle systems. Invited keynote paper for IMS’2004—International conference on intelligent maintenance systems, Arles, France. Lee J., Ni J., Djurdjanovic D., Qiu H., Liao H (2006), Intelligent prognostics tools and e-maintenance, Computers in Industry , 57, 476–489 Lee, J., Bagheri, B., Kao, H., 2015. A Cyber-Physical Systems architecture for Industry 4.0-based manufacturing systems. Manufacturing Letters, Volume 3, 18–23. 37 Lee, J., Ghaffari, M., Elmeligy, S., 2011. Self-maintenance and engineering immune systems: Towards smarter machines and manufacturing systems, Annual Reviews in Control, 35, 111–122 Levrat, E., Iung, B. and Crespo A., 2008. E-maintenance: review and conceptual framework, Production Planning and Control, Volume 19, Issue 4, 408-429. López-Campos M., Crespo A., Gómez J.F., 2013, Modelling using UML and BPMN the integration of open reliability, maintenance and condition monitoring management systems: An application in an electric transformer system. Computers in Industry, 64, 524–542. Ly C., Tom K, ByingtonC.S., Patrick R., Vatchsevanos G. J., 2009, Fault Diagnosis an Failure Prognosis on Engeneering System: a Global Perspective. 5th Annual IEEE Conference on Automation Science and Engineering, Bangalore, India. Macchi, M., & Garetti, M. (2006). Information requirements for e-maintenance strategic planning: A benchmark study in complex production systems. Computers in industry, 57(6), 581-594. Macchi, M., Crespo Márquez, A., Holgado, M., Fumagalli, L., & Barberá Martínez, L. (2014). Value-driven engineering of E-maintenance platforms. Journal of Manufacturing Technology Management, 25(4), 568-598. MIMOSA (Machinery Information Management Open Standards Alliance), 2011. Open Systems Architecture for Condition Based Maintenance (OSA-CBM), v3.2.19, Moubray J, 1991. RCM II: Reliability-centred Maintenance. New York: Industrial Press Inc. Muller A., Crespo A., Iung B. 2008, On the concept of e-maintenance: Review and current research,.Reliability Engineering and System Safety, 93, 1165–1187 Niu G., Yang B.S., Pecht M., 2010, Development of an optimized condition-based maintenance system by data fusion and reliability-centered maintenance, Reliability Engineering and System Safety 95 (7) (2010) 786–796. OREDA (2009). Offshore Reliability Data Handbook 5th Edition, OREDA 2009. Parra C,.Crespo A. 2012, Maintenance Engineering and Reliability for Assets Management. Ingeman. Pecht M., 2008.Prognostics and Health Management of Electronics. Hoboken, NJ: Wiley, 2008. Pintelon L, Parodi-Herz A (2008) Maintenance: an evolutionary perspective in complex system. In: Kobbacy KAH, Murthy DNP (eds) Maintenance handbook. Springer, New York. Saxena, A., Celaya, J., Saha, B., Saha, S., Goebel, K., 2010. Metrics for Offline Evaluation of Prognostic Performance International Journal of Prognostics and Health Management, 1. Scarf P., (2007), A Framework for Condition Monitoring and Condition Based Maintenance, Quality Technology & Quantitative ManagementVol. 4, No. 2, pp. 301-312, 2007 United States Army, 2013. ADS-79D-HDBK - Aeronautical Design Standard Handbook for Condition Based Maintenance Systems for United States Army Aircraft 38 Vachtsevanos G., Lewis F., Roemer M., Hess A., Wu B. 2006, Intelligent Fault Diagnosis and Prognosis for Engineering Systems.Hoboken, NJ, John Wiley and Sons. Wu E, Diao Y, Rizvi S (2006). High-performance complex event processing over streams. In: Proceedings of the ACM SIGMOD international conference on management of data, Chicago, IL, USA, pp 407– 420 Zio, E. (2009). Reliability engineering: Old problems and new challenges. Reliability Engineering & System Safety, 94(2), 125-141. Figures Fig.1. Positioning CBM with respect to E-Maintenance. Maintenance types evolution through incorporation of proactive capabilities to the maintenance function ................... 4 Fig.2. CBM Complexity Graph. Entities, attributes and relations. ............................. 8 Fig.3. Data-processing for CBM, monitoring objectives (detection, diagnosis and prognosis) and correlation of process phases with levels of ISO 13374 ......................... 11 Fig.4. Elements and phases of the CBM management. ............................................. 13 Fig.5. Blocks in the proposed framework ................. ¡Error! Marcador no definido. Fig.6. Basic structure for the CBM solution presented in an UML diagram. ........... 25 Fig.7. Evolution of the ideal and actual reliability, failure probability, temperature and load current intensity, for a moment in time (t). .................................. 31