cap.

3
Disponibilidad, conabilidad y mantenibilidad de equipos

Proyecto de mejoras de conabilidad de las redes de control en planta de Codelco Chuquicamata

En los sectores de mina, concentradora y planta Moto, pertenecientes a la minera Codelco Chuquicamata, la infraestructura de control para la produccin es soportada por la plataforma Contrologix, y las redes de comunicaciones ControlNet y EtherNet/IP. Las redes de control e informacin mencionadas son exigidas cada vez ms por los constantes aumentos de la produccin, generando un aumento en los volmenes de informacin de control en los equipos de operacin y mantencin. Todas estas exigencias adems de los nuevos nodos que se agregan conducen a la existencia de fallas en las redes de comunicaciones. Debido los antecedentes mencionados anteriormente, se requiere analizar la necesidad de mejorar la disponibilidad, conabilidad y robustez de las redes existentes en las diferentes reas de la minera Codelco Chuquicamata. El propsito del proyecto es evaluar, diagnosticar y mejorar las condiciones de las redes de control ControlNet y EtherNet/IP que existen en las diferentes reas de la mina, con el n de robustecer la estructura de la redes antes mencionadas, optimizar la comunicaciones y aumentar la conabilidad de stas, impactando en la disminucin de los tiempos de prdida-produccin relacionados con fallas en las redes de control. El desarrollo del proyecto consider desde el levantamiento de informacin hasta la evaluacin de las acciones aplicadas, pasando por las necesarias etapas intermedias como por ejemplo denicin del plan de accin. El trabajo desarrollado ha permitido, disminuir de forma cuantitativa el ndice que reeja los tiempos muertos o detencin de la produccin asociados a fallas relacionadas a mantencin, por ejemplo reducir a cero fallas de comunicaciones en un semestre mejorando la conabilidad operacional, disponibilidad de procesos para la produccin, etc. En conclusin, es muy importante tener siempre presente que toda red de comunicacin asociada al control de procesos para la produccin, deben crecer de forma planicada y ordenada. A lo menos es necesario optimizar las comunicaciones existentes de modo que permita la integracin de nuevos nodos o un manejo ecaz de tramas de datos de control.

Fernando Saavedra y Luis Campusano. Rockwell Automation S.A ., Chile

100

Project for improving control network reliability at the Codelco Chuquicamata plant

In the mine, concentrator and Moto plant areas belonging to Codelco Chuquicamata mining, infrastructure for production control is supported by the Contrologix platform, and ControlNet and EtherNet/IP communications networks. The control and information networks mentioned above are constantly under demand by constant increases in production, generating in turn an increase in the volumes of control information for operation and maintenance equipment. All these requirements, as well as new nodes that are added, are leading to the existence of faults in communications networks. Given the background above, an analysis of the need to improve the availability, reliability and robustness of existing networks is required for dierent areas of Codelco Chuquicamata. The purpose of the project is to assess, diagnose and improve the ControlNet and EtherNet/IP control networks that exist in dierent areas of the mine. The project seeks to strengthen the structure of the aforementioned networks, optimize communications and increase reliability; reducing production time-loss related to failures in control networks. The project development took into account everything from information collection to evaluating the actions implemented, as well as going through the necessary intermediate steps such as dening the action plan. As a result of the work, a decrease in the index reecting downtime and production stoppage related to failures associated with maintenance was achieved. Communication failures in one semester were reduced to nil, thus improving operational reliability, availability of processes for the production, etc. In conclusion, it is important to keep in mind that any communication network associated with the production processes control should grow in a planned and orderly manner. At least it is necessary to optimize existing communications so as to allow the integration of new nodes or eective management control data frames.

Fernando Saavedra and Luis Campusano. Rockwell Automation S.A ., Chile

101

INTRODUCCIN
La contina demanda de aumentar la productividad y bajar los costos de produccin por parte de las empresas son las exigencias que tienen hoy por hoy las industrias mineras, que en conjunto con la innovacin, la optimizacin y la mejora continua de los procesos nos permitirn enfrentar los desafos que la industria de la minera nos ofrece. A lo anterior se agrega la necesidad que las tecnologas usadas en los procesos productivos permitan soportar la constante expansin de la produccin a travs de los aos. En relacin a las tecnologas que son utilizadas en las reas produccin de Mina, planta Mofito y Concentradora de Codelco Chuquicamata existen dos tipos de redes de control principales ControlNet y Ethernet/IP. La redes ControlNet que estn presentes en las reas de produccin antes mencionadas, tienen dentro de sus caractersticas ms destacables su robustez, el alcance en distancia que proporciona el medio fsico (Coaxial y Fibra Optica), tolerancia a fallas a travs de la redundancia del bus de datos y la cantidad nodos que soporta (99), lo cual brinda flexibilidad, confiabilidad y mayor de disponibilidad de la red, etc. Las redes EtherNet/IP que estn presente en las reas de produccin ante mencionadas, tienen dentro de sus caractersticas ms destacables, un mayor ancho de banda, no tiene casi limitaciones de la cantidad de nodos que la componen, la gran flexibilidad del medio fsico, ya que, puede usar cobre (UTP), Fibra ptica o el aire transmisin inalmbrica de datos, tolerancia a fallas a travs de la redundancia de medio o lgica, ofreciendo un confiabilidad, disponibilidad y flexibilidad en el diseo de redes de control. Por otro parte a medida que las metas de produccin crecen cada ao, aumenta de manera considerable la cantidad de datos de control y nodos de comunicacin necesarios, sobre las redes existentes ControlNet y EthernNet/IP, para cumplir con los objetivos de produccin , por lo cual es necesario contar con una buena planificacin del cmo se manejara el aumento de flujo de datos, para responder de manera ptima a la expansin de los nodos de comunicacin, ya sea, por la adquisicin de un nuevo molino o una expansin de alguna etapa del proceso que requiere de automatizacin de dicho equipo o proceso. En relacin a los diferentes proyectos de expansin ejecutados en las distintas reas de la minera Codelco Chuquicamata, y las problemticas que surgieron al aumentar los volmenes de datos de control y nodos de comunicacin para control de los procesos, en las redes existentes ControlNet y EtherNet/IP, sin considerar como impactara a nivel de las comunicaciones que existen entre los controladores (PLC) y entre cada controlador con sus nodos remotos de entradas y salidas de seales de proceso, generando fallas intermitencia en la comunicaciones y aleatorias en el tiempo que afectaron directamente los procesos de produccin. Basandose en los problemas indicados anteriormente fue que surgi la necesidad de diagnosticar, evaluar y mejorar el estado actual de las redes de comunicacin, ya que, la expansin en el tiempo de los procesos productivos, no fueron de la mano con una planificacin adecuada que permitira un crecimiento de las redes de comunicacin, sin sobre cargarlas y produciendo fallas de

102

intermitencia de datos y fallas de comunicaciones ms complejas, afectando directamente a la produccin.

METODOLOGA
La forma en la cual se enfrent este desafo, fue la formacin de un equipo de ingenieros de servicios especialistas en la validacin de redes de control, como DH+, DH RIO, ControlNet y EthertNet/IP, los cuales en conjunto con el cliente participaron activamente en el desarrollo del proyecto de validar y mejorar la redes de control existentes en las diferentes reas de minera Codelco Chuquicamata mencionadas anteriormente. Los primero pasos que se realizaron fue el levantamiento de la informacin existente de cada red de control, tal como planos, respaldo de las lgicas de control de los controladores involucrados; y visitas a terreno que permitiera dimensionar el alcance de los trabajos a realizar. Una vez ya fijados los alcances del proyecto de mejora de la confiabilidad de las redes de control en las tres reas de procesos antes mencionadas, y con el fin evaluar el estado actual de cada uno de ellas, como tambin el estado general de las redes de comunicacin, se procedi a revisar cada uno de los nodos que componan las distintas redes de control. A lo anterior se agrega la necesidad de planificar en conjunto con el cliente, la forma que se realizara la validacin de las redes sin afectar de manera significativa la produccin y que a su vez permitiera una avance eficaz en los trabajos a realizar.

Validacin Ethernet/IP
Se procede a la validacin del medios fsicos (Cable UTP y FO) a travs de la herramienta DTX-1800 marca Fluke, que entrega un certificado de validacin del medio sometido a prueba, informando la integridad y calidad de medio, etc. En el caso de los medios fsicos utilizados en la red EtherNet/IP del rea mofito y concentradora, todos pasaron la certificacin, evidenciando el buen estado del medio de comunicacin, brindando conectividad entre los nodos que componen la red EtherNet/IP. Como siguiente paso se procede con la revisin exhaustiva de los componentes mayores o concentradores de comunicacin (Switches y/o Routers, Transceiver), tanto en su configuracin como en su desempeo. Resultado de la revisin indica que los parmetros de configuracin del Switch Stratix que Rockwell certifica, no contaba la configuraciones bsica que permite el intercambio de mensajes CIP que utilizan los controladores y la HMI. Se realizaron mejoras significativas en la seguridad y en el manejos de cierto tipo de tramas multicast que utilizan los controladores ControlLogix, a travs de las tarjetas de comunicacin 1756ENBT y 1756-EN2T, para mejorar an ms la performance de los switches y entre los controladores, esto se logr a travs de la aplicacin de las macros de parmetros pre-configuradas disponibles en Switch. En la siguiente etapa de la validacin de red se procedi a revisar y probar la comunicacin de cada nodo que componen la red EtherNet/IP, a travs de una serie de comandos de consola, para comprobar la conectividad y adems de analizar la red a travs del analizador de red EtherScope

103

Series II Network Assistant, con el cual se procedi medir, por ejemplo, el porcentaje de mensajes broadcast enviado por cada nodo y el ancho de banda consumido por cada nodo. En conclusin la red EtherNet/IP del rea de Mofito y Concentradora, mostr resultados mixtos, pero a travs de las mejoras en la configuracin de cada equipo se volvieron ptimos tanto la instalacin y operatividad, obteniendo un red con alta disponibilidad, robustez y seguridad, siendo esto ndice de alta importancia en el desempeo de la operacin y produccin. En la Tabla N1 se describen las condiciones sub estndares encontradas, las cuales fueron mejoras en el transcurso de la validacin, queda registro de estas mejoras en Reporte tcnico desarrollado como informe final. Tabla 1 Condiciones Sub Estndares encontradas
1.En general los dispositivos y/ o nodos (Tarjetas 1756-ENBT/A y 1756-EN2T) fueron configurado de forma correcta, los medios de comunicacin UTP y Fibra ptica no presentan caractersticas que impidan el normal funcionamiento de las red de control. Se encuentra excesivo polvo en los Switch y Tarjetas de Comunicacin 1756-ENBT/A afectando su temperatura, por lo que se deben programar mantenciones al menos trimestrales. El Switch no tiene configuracin alguna, actuando como un Switch no administrable, y con parmetros de fbrica, por lo cual no es confiable para el manejo de las comunicaciones entre los controladores, ya que estos utilizan comunicacin del tipo CIP, y el switch no tiene activa la Vlan 1 CIP y no tienen configurado los protocolos IGMP Snopping y la calidad de servicio Q&S para manejar el trafico multicas generado por los nodos de control Ethernet/IP. Puertos de consola de los Switch no tiene activa seguridad para este puerto, para prevenir accesos no autorizados

2.3.-

4.-

Validacin ControlNet
Se procedi a la validacin de los medios fsicos que componen la red ControNet, que est compuesta por cable coaxial y fibra ptica, los cable coaxiales fueron probados a travs de las herramientas AB Media Checker y CNET NetChecker y la fibra ptica fue certificada por la herramienta DTX-1800 marca Fluke, que entrega un certificado de validacin, informando la integridad y calidad de medio. A lo anterior se agrega la revisin de cada uno de los elementos que componen el medio de fsico de la red, entre ellos los conectores, repetidores y canalizacin del cable coaxial, adems de chequear que lneas de fuerza de variadores de frecuencia y motores no estn prximas a la rutas por donde el medio fsico (Cable Coaxial RG6 Quad) fue canalizado para evitar que la induccin electromagntica puedan afectar la data que es enviada por el medio. Una vez validados los medios fsicos se procedi a la revisin de la formas de ondas que componen la red ControlNet, para cual se utiliz un Fluke Scope Meter para capturar las formas de onda que indican la calidad de la tramas de comunicacin que son enviadas o recibidas entres los nodos de comunicacin que componen la red. El procedimiento utilizado fue la medicin de las formas de ondas antes y despus de la validacin de la red, con fin de tener una referencia que nos permitira evaluar las mejoras realizadas.

104

Luego se procedi a revisar los parmetros de configuracin que cumplen con la funcin de administrar el comportamiento de la red de control, entre los parmetros uno de los ms importantes el NUT (Tiempo actualizacin de la Red) en la cual se actualizan lo datos de control (Mensajes, entradas/salidas a ejecutar) en los nueve nodos ControlNet, el valor de NUT era de 20 ms en la medicin inicial, como se muestra en la siguiente figura 1.

Figura 1 NUT inicial de red ControlNet de 9 nodos

Esto quiere decir, que cada 20 ms los datos de los nueve nodos se actualizan, como se muestran en la figura 1. Se aprecia claramente que el espacio entre cada NUT es bastante amplio y fue optimizado reduciendo el NUT de 20 ms a 10 ms de actualizacin de los datos de control, entre los nueve nodos la red, como lo muestra la figura 2.

Figura 2 NUT Final de red ControlNet de 9 nodos

105

RESULTADO Y DISCUSIN
Las validaciones de la redes del rea mina, se realizaron bajo los estndares que Rockwell ha diseado para las redes ControlNet y EthereNet/IP, permitiendo analizar de estas, su infraestructura, componentes, y estabilidad de la comunicaciones, al aplicar las matrices que evalan el diseo, instalacin y operacin de la redes antes mencionadas, se obtuvo una radiografa de la redes, en cada una de sus etapas evaluadas, entregando un listado de condiciones sub-estndares que fueron corregidas a travs de reemplazo de conectores, re-canalizacin de tramos donde el medio estaba expuesto a lneas elctricas de alto voltaje que generan campos magnticos que afectaban a la redes y optimizacin de los parmetros de configuracin determinan el comportamiento de las redes logrando resultado tales como lo que se pueden apreciar en la siguientes figuras 3 y 4.

Figura 3 ControlNet Mina, reflexin de seal en la lnea troncal

Figura 4 ControlNet Mina, seal normal despus de ejecutadas las acciones correctivas

106

Las acciones correctivas mencionadas anteriormente, permitieron disminuir el ndice de fallas provocadas por los errores de comunicacin en las redes de control del rea de mina, en el segundo semestre del ao 2012, que inciden directamente en el ndice de disponibilidad de las redes de comunicaciones para la produccin. Estos resultados son ilustrados en la figura 5 y Tabla 2 siguientes.

7 6 5 4 3 2 1 0

Antes de la validacion

Despues de la validacion

2011 2012

1 Trimestre

2 Trimestre

3 Trimestre

4 Trimestre

Figura 5 Eventos que afectaron la produccin aos 2011 y 2012

Tabla 2 Registro de falla atribuidas por el cliente a las redes de comunicacin

2011

2012

1 Trimestre

2 Trimestre

3 Trimestre

4 Trimestre

CONCLUSIN
Las validaciones de las distintas redes de control, son una herramienta poderosa que permite obtener un radiografa a fondo del estado general de la redes y de todos los elementos que la componen, generando un informacin valiosa para la deteccin de condiciones sub-estndares, en el diseo, instalacin y operatividad de un red de comunicaciones, lo cual permitir tomar las acciones correctivas necesarias, para disminuir el riesgo que ocurra una nueva falla.

107

Es importante considerar que la constante expansin y evolucin de los procesos, necesita de redes de informacin y control cada vez ms flexibles, confiables, disponibles y robustas. Hoy en da, las estrategias del mantenimiento estn encaminadas a garantizar la disponibilidad y eficacia requerida de las unidades, redes de comunicaciones, equipos e instalaciones, asegurando la duracin de su vida til y minimizando los costos de mantenimiento, dentro del marco de la seguridad y el medio ambiente, lo cual nos permite ver el mantenimiento como una fuente de rentabilidad. La gestin de activos se ha convertido en un hito gravitante a travs del cual consistentemente agregamos valor a la compaa mediante el uso y cuidado de los activos en todo el ciclo de vida, lo cual nos recuerda que las estrategias de mantenimiento predictivo, preventivo y correctivo son nuestro mejores aliados a la hora de cuidar nuestro activos.

REFERENCIAS
ControlNet Coax Taps Installation Instructions, 1786-IN007C-EN-P, October 2010. ControlNet Modular Repeater Adapter Installation Instructions, 1786-IN013F-EN-P, April 2011 ControlNet Fiber Media Planning and Installation Guide, CNET-IN001C-EN-P, October 2011 ControlNet Coax Media Planning and Installation Guide, CNET-IN002B-EN-P, July 2010 EtherNet/IP Embedded Switch Technology Application Guide, ENET-AP005D-EN-P, August 2011 Troubleshoot EtherNet/IP Networks ENET-AT003A-EN-P, June 2011 Industrial Security Best Practices, SECUR-AT001A-EN-E , May 2012 Stratix 8000 and 8300 Ethernet Managed Switches Installation Instructions, 1783-IN005D-EN-P, September 2009

108

Mejorando la conabilidad de equipos por medio de la implementacin de anlisis causa raz (RCA)

Anlisis de causa o simplemente RCA, el acrnimo comnmente conocido, se puede denir como un proceso estructurado que descubre las causas de fondo fsica, humana y de organizacin (o latente) de cualquier evento no deseado. Una investigacin RCA sigue el camino desde la causa y efecto de la falla hasta la raz de la causa; es muy similar a una investigacin de un detective para resolver un crimen. Este proceso ha demostrado ser esencial para cualquier organizacin y, muy importante para el mantenimiento industrial, que se esfuerza por eliminar la recurrencia de las fallas de equipos o sistemas y abandona el modo reactivo perjudicial de apagar incendios para pasar a ser ms proactivo. En este artculo, vamos a presentar un ejemplo prctico de aplicacin de la RCA y tambin un caso real que ocurri en la industria electrnica en un pas de Europa del Este, en donde el uso disciplinado de la RCA ayud a identicar las fallas de los equipos de produccin. Las fallas que se identicaron fueron utilizadas como un motivador importante para revisar los planes de mantenimiento, que se utilizaban en ese momento para evitar fallas en los equipos. Las actividades iniciadas permitieron una drstica reduccin de las fallas que estaban causando prdidas signicativas de produccin y, en consecuencia, la mejora de la productividad de la planta.

Jose Baptista. A BB Ltda., Brasil

110

Improving equipment reliability through the implementation of Root Cause Analysis (RCA)

Root Cause Analysis or simply RCa, the commonly known acronym, can be dened as a structured process that uncovers the underlying physical, human, and organizational (or latent) causes of any undesirable event. A RCa investigation traces the trail of cause and eect from the failure back to the root cause; it is very similar to a detective investigating and solving a crime. This process proves to be essential for any organization and, especially important for industrial maintenance that strives to eliminate the recurrence of equipment or system failures and move away from the damaging reactive or re-ghting mode and become more proactive. In this paper, we will present a practical example of application of RCA and we will also report a real case that occurred in electronics industry in an Eastern Europe country, where the disciplined use of RCA helped to identify the failures of production equipment. The failures that were identied were used as an important trigger to review the maintenance plans, used at that time to avoid equipment failures. The initiated activities enabled a drastic reduction of the failures that were causing signicant production losses, and by consequence, improved the plant productivity.

Clauson Souza, Virginia Ciminelli and Daniel Majuste. Universidade Federal de Minas Gerais and the National Institute of Science and Technology on Mineral Resources, Water and Biodiversity (INCT Acqua), Brazil

111

INTRODUCTION
The root cause analysis or simply RCA, the acronym by which it is commonly known, is an indispensable methodology for the industrial maintenance to get out of the damaging reactive mode. To better understand what the reactive mode is; consider the situation where the maintenance crew is occupied full-time to repair equipment that randomly breaks. In this way, the maintenance team is always overloaded; working under the constant pressure of having to repair equipment to put the plant back in operation, another term commonly used to describe this situation is "only work to put out fires." In this work model the maintenance costs are high, fairly unpredictable. There is constant tension between operations and maintenance because the maintenance is always seen as the great villain that prevents the operation to meet its production program and, moreover, accounts for a significant portion of operating costs. What prevents the successful implementation of RCA, despite the fact that companies are becoming increasingly aware of benefits of RCA? ; We have to ask, Why doesnt RCA work? This paper points to the steps necessary to implement an RCA process that is successful and discusses the reason why it does not work in some cases. Before continuing, for better understanding, it is appropriate to review some important definitions that are used in RCA. Causal factors: All the factors that logically can affect results, including those that produce proven phenomenon. Causes: The causal factors that are proven to cause or implied, directly or indirectly, of the phenomenon under analysis. Root Cause: The cause that, if corrected, would prevent recurrence of this and similar occurrences. The root cause does not apply to this occurrence only, but has generic implications to a broad group of possible occurrences, and it is the most fundamental aspect of the cause that can logically be identified and corrected. There may be a series of causes that can be identified, one leading to another. This series should be pursued until the fundamental, correctable cause has been identified. (U.S. Department of Energy, 1992) It should be noted that there is no single consensus definition of RCA in industrial, technical societies, corporations and companies have their own definitions and it is rare to find two similar definitions. We opted for the definition below which reflects the concepts discussed in this paper. Root Cause Analysis is any evidence-driven process that, at a minimum, uncovers underlying truths about past adverse events, thereby exposing opportunities for making lasting improvements. (Latino & Latino, 2006) In the definition above of RCA we can find one of the reasons why it does not produce the expected results in several places; the whole process should be driven by evidence. It appears that many people do this routine bureaucratic process, organizing review meetings, preparing brainstorming sessions and applying the Five Whys technique without seeking any

112

evidence. In other words, not investigating the crime scene, not collecting samples, not interviewing witnesses and, at worst, not analyzing the real facts; they just cling to assumptions and hypoesthesia and then draw their conclusions. In RCA trainings in various countries, it has proved relevant to establish an analogy between the RCA and the research methods of the famous detective Sherlock Holmes, a fictional character from the books of British author and physician Sir Arthur Conan Doyle. The first book about Conan Doyle's Sherlock Holmes, "A study in scarlet" originally edited and published by the magazine Beeton's Christmas Annual in 1887 is considered to be the first description in fiction of a scientific method of analyzing and solving problems. The key points of the methodology used by the character to solve the most puzzling criminal cases, which are, in short, its hallmark and standard of conduct: Sherlock Holmes had a passion for definite and exact knowledge. (Doyle, 1887) - This implies that data should be collected to prove the hypothesis before determining a root cause. Believed that examining one thousand crimes would give information for solving the one thousand-first crime. (Doyle, 1887) - Examine data from similar events because they will help to improve the process of analysis. He believed that the world was full of obvious things which nobody by any chance observed Dont accept the most immediate explanation without looking at all of the information. Accordingly, some quotes from Sherlock Holmes which applies to RCA: It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts."- (Doyle, 1891) "Data! Data! Data!" he cried impatiently. "I can't make bricks without clay." - (Doyle, 1892) "I never guess. It is a shocking habit destructive to the logical faculty." (Doyle, 1890 ) Throughout the explanation of the RCA process, the similarities between it and the methods of Holmes become more evident.

METHODOLOGY
The RCA process adopted worldwide by ABB in the Full Service industrial customer sites consists of the following steps: Define the problem If necessary, perform the Failure Analysis Identify possible causes Check real cause(s) Propose solution to the problem Implement the solution Monitor the results

113

Step 1: Define the problem

Albert Einstein has said that if he had only one hour to save the world, he would spend fifty-five minutes to define the problem and five minutes to solve it. The quote illustrates how important it is to define the problem in finding its solution. First, it is important to understand that any problem or undesired event can be defined as the difference between the current situation and the goal (Eckert, 2005). A common practice in defining the problem, which ultimately hinder their subsequent analysis and solution, is that some people write a real novel describing the problem and, in most cases, end up defining not only a problem, but various problems in the same description. We need to understand that different people or groups will have different views on the same problem (Eckert, 2005). One way to circumvent this difficulty and arrive at a consensus definition is to make the following simple questions: What is the problem? When did this happen? Where did it happen? What goal has been impacted by the problem? These questions must be answered in short sentences; one object and one defect.

Step 2: Failure Analysis (if necessary)

The failure analysis is a detailed inspection of the damaged components to determine what was the mechanism or failure mode responsible for the failure. The information "how" the component failed is an important data for determining the root cause. Figure 1 illustrates an example of analysis. There are five mechanisms that lead to a component failure: Overload: The application of a single load (mechanical or electrical) leads the component to deform or fracture as the load is applied. Fatigue: Floating load over a relatively long period of time causes this type of failure and, in most cases, leaves clues. Corrosion-influenced failure: Corrosion substantially reduces the design strength of metals Corrosion: The failure results is the wearing away of metals due to a chemical reaction Wear: Several mechanisms result in the loss of material by mechanical removal.

114

Figure 1 Example of failure analysis showing a fatigue failure with a small fracture

Step 3: Identify the possible causes

One of the methods used to identify possible causes of the problem is the causal tree. The causal tree starts by determining the so-called main event, which is the problem or undesired event being analyzed. This block is extremely important because it determines the rest of the sequence analysis. In sequence, it is necessary to determine what factors may contribute to the occurrence of the main event and the possible interrelations between them. The relationship between the main event and its factors is the immediate cause-effect relationship. The second level is the possible immediate causes of it. Thereafter, for each possible cause it should immediately be related to its possible causes, each immediate cause becomes an effect. And the diagram will be expanded to as many levels as needed, as shown below. In a causal tree, the main event is the accident itself and it is placed at the top or at left hand side as in the below example. The next step is to provide the causes for the top event, followed by the causes for those secondary causes, and continuing on until the endpoints are reached. These endpoints are the possible root causes.

115

Figure 2 Example of Causal tree

In determining the roots, to facilitate understanding of the event, the roots can be divided into the following categories (Latino & Latino, 2006): physical, human and organisational (or latent) roots. The physical roots are the immediate consequences of the event; roots are tangible or damaged components, for example. The human roots are the human actions that caused the physical roots or damage to components / materials, and finally the latent or organizational roots are the motivation for the action has been taken. Physical roots are the physical reasons why the parts failed: Overload i.e. operation error, accident Fatigue i.e. thermally induced, mechanically induced, imbalance, misalignment, resonance, material Corrosion i.e. wrong material, process chemicals, environment, spills Wear i.e. lubrication, contamination, misalignment, excessive loading

116

 Human roots can be understood as human decision-making errors that will cause the roots of the physical event. They are errors of action or omission, which means, someone did something they should not have done or failed to do something they should do. Examples: Memory i.e. forgetting a task Selection i.e. ordering wrong component, making wrong choice Discrimination i.e. poor information Test or operation error i.e. knew the rest of the procedure Situational blindness i.e. acceptance of problems When the conclusion of an analysis is simply human error, there is a strong indication that the analysis was incomplete. Human error just says that something was not done correctly and that there were people involved. Human error is a general conclusion that does not allow any specific action to prevent recurrence of the problem. Once the specific cause of the problem was found, organizations choose disciplinary actions as the only alternative and keep thus a vicious circle. Organizations often blame employees for problems and seem to believe that this will set an example for all employees and discourage them to commit the same mistakes. In fact, the underlying message might be that: "If you identify a problem or are involved with a problem which is preventing us from achieving our goals, it is better not to reveal because you can be punished." Organizational or latent roots can be understood as organizational systems which people use to make decisions. When systems are flawed, the decisions made from them will result in errors. Some examples of organizational roots: Lack of employee engagement; Management complacency; Failure of communication; Task perceived as undesired; Lack of procedures, technical documentation and formal training; Missing or incomplete specifications; Incorrect incentive; Use of incorrect tools or worn; Priorities incorrect; Lack of access to information. The following illustration in figure 3 describes the hierarchical order of root levels and implications of corrective actions:

117

Figure 3 The three root levels

Step 4: Check real cause(s)

In this step the possible causes are evaluated and the proof is sought through the data collected, as mentioned in the previous step. The real causes of the event can be achieved by discarding the hypotheses that cannot be proved. "When you eliminate the impossible, whatever remains, no matter how improbable, must be the truth." - (Doyle, 1902)

Step 5: Propose solution to the problem

At this phase, the process identifies possible solutions for each individual cause found in the analysis mentioned above. It is important to verify that each solution prevents recurrence of the problem and does not create new problems. The ease of solution implementation and the required investment (cost / benefit analysis) should also be assessed.

Steps 6 and 7: Implementation of the solution and follow up

The whole process developed up to this point will be totally useless if the implementation of the solution does not take place. It is suggested that: A complete plan must be prepared with all the planned actions This plan must set deadlines, resources and responsible persons for all actions Do not plan many actions simultaneously or assign a single responsible An action properly implemented is more valuable than ten actions in the plan Expand the cause and expand the fix

118

The process of root cause analysis aims at complete elimination of the problem preventing its recurrence. Recurrence at any time, demonstrates that the process was ineffective for one of the possible causes: Errors in determining the root cause Errors in the determination of actions to eliminate the root cause Errors in determining the parameters for monitoring the results Resistance to the implementation of Root Cause Analysis: To achieve success through the use of Root Cause Analysis, you must be prepared to overcome the possible obstacles. Here is a list of some of the arguments that people often use to justify their attitude (Latino, 2006): It is a bureaucratic process that takes a long time It is an expensive process It's just a "flavor of the month" It is a way to find and punish the guilty Only applies to really serious and important events It is a tool only for reliability engineers We've tried other times and it did not work We have enough quality programs These arguments, however, are easily refuted. For example, those who think that root cause analysis will take a lot of time, need to be reminded that if they do not have time for analysis, they will need to get more time and resources to handle the continual repetition of undesired events.

RESULTS AND DISCUSSIONS Example: RCA methodology application

Case Description: In a tire manufacturing plant there is an internal mixer equipped with two counterrotating rotors in a large housing that shear the rubber charge along with the additives. The rotors were driven by a 2000 HP electrical motor / gearbox. In this case, the internal mixer of the tire plant had its automation system (PLC and software) replaced (upgraded) during a plant planned shutdown (holidays), after five years of continuous operation. As scheduled, it returned to operation on a Monday morning and operated continuously during that whole week until Saturday night, when it was supposed to stop for the weekend (the mentioned plant always stopped from Saturday night to Sunday night). At the moment when the equipment was stopped by the operator, an explosive sound was heard and some smoke comes out from the 2000 HP gearbox.

Problem: The internal mixer 2000HP gearbox bearings were damaged.

Results from investigations that followed the event: It was the first time failure for the equipment

119

 The gearbox bearings were damaged due to lack of lubrication. The lubrication pump was stopped and the main motor continued operating. The operator used to stop the equipment by stopping the auxiliary equipment (hydraulic pump, fans, cooling water pump) instead of normal stop (main motor). He claimed that he operated the equipment this way for more than five years. The engineer who made the PLC software conversion forgot to include the equipment safety interlocks. The equipment safety interlock wasnt tested during the equipment commissioning.

Causal tree:

Figure 4 Causal tree: Gearbox bearings damaged

Root causes:
Physical roots: the damaged bearings Human roots: the operator didnt stop the equipment correctly and the design engineer didnt include the interlock avoiding the motor to continue running if the lubrication pump is not. Organizational roots: missing or inadequate qualification of operators, missing or inadequate commissioning of new / refurbished equipment, the area operations supervision was deficient.

Problem solution:
The problem was solved by the replacement of damaged bearings and the inclusion of an equipment safety interlock to avoid the main internal mixer motor to continue running if the lubrication pump is not.

120

 The internal mixer operations procedure was revised and all operators were trained.

Extend the cause and fix:

To keep a failure from reoccurring is good, but the true value of RCA is to leverage the overall plant results. So it was checked where else in the plant similar problem could take place due to unknowledgeable and therefore wrong operation.

Case example: How RCA positively affected overall plant effectiveness

Case description: At an electronics industry in an Eastern European country, the availability of production lines was being seriously affected by frequent equipment breakdowns. Maintenance staff was overwhelmed and totally involved only in corrective maintenance, in other words "just working to put out fires" and the plant operations team was increasingly dissatisfied because they were not able to meet production schedules. The vicious circle was established; equipment broke, the production schedule was not met, the plant manager complained, operations team blamed maintenance and the maintenance worked even more without obtaining a result of their actions. The following plan was established to overcome the situation: first the root cause of failures was to be discovered to prevent recurrence. Therefore, for every new failure the question should be: "Why did it failed?" And then there are two options: (1) the cause of failure can be identified and (2) the cause of failure cannot be identified: for this second option necessarily, it is needed to apply RCA. Addressing each equipment breakdown this way, we begin to understand what is actually contributing to the poor production technical availability. However, this is not enough to achieve our goals of reducing failures because we need to be proactive, in other words, the failures need to be prevented from occurring or the impact of occurrence must be minimized, and for this we have the preventive maintenance plans. The below figure 5 shows a process flow explaining the plan to minimize the equipment failures, moving maintenance from reactive to proactive.

121

Figure 5 Process flow to move maintenance from reactive to proactive

The plan was put into practice, after training of the involved teams (maintenance, operations, process engineers, etc.), and after thirty weeks of dedicated team work, occurred a drastic reduction in the frequency of failures, increasing the operational availability of the two main production lines as shown in the picture of figure 6 below.

122

Figure 6 Graph: Number of failures x week for the two main machine families

123

CONCLUSIONS
The RCA implementation is the first step towards a world-class reliability environment; it is extremely cost effective and greatly improves the reliability of the facilities, by improving standards of operation, maintenance and design, and helping to identify weaknesses in the organization. Some of the benefits of its implementation: A detailed understanding of what issues can be occurring on the plant Issues can be separated and clarified so the RCA is performed on the actual issues instead of perceived issues Identification of all root causes to the problem are exposed, giving a clear understanding of what is happening The root causes can be ranked in order of contribution and importance Recurring problems can be prevented; increasing availability, decreasing required maintenance costs and freeing up personnel to work on proactive improvements A failure database can be built up over a period of time Objective results are produced based on facts rather than personal opinion The analysis is documented for future review

AKNOWLEDGEMENT
I would like to gratefully acknowledge the contribution of Barry Kleine, ABB Full Service region reliability manager, whose RCA training material was a very important source of research.

REFERENCES
Doyle, A.C. (1887), A Study in Scarlet, Ward Lock & Co. Doyle, A.C. (1890), The Sign of Four, Spencer Blackett Doyle, A.C. (1902), The Hound of the Baskervilles, George Newnes Doyle, A.C. (1891), A Scandal in Bohemia, The Strand Magazine Doyle, A.C. (1892), The Adventure of the Copper Beeches, The Strand Magazine Eckert, C. (2005), Apollo Anlise de Causa de Raiz (RCA) - Um Sumrio, article published on March, 2005, Apollo South America Ltda., www.apollorca.com Latino, R. (2006), The top 10 reasons people don't http://www.plantservices.com/articles/2006/240.html trust root cause analysis, Plant Services

Latino, R. & Latino, K. (2006), Root Cause Analysis, 3rd. Edition, CRC Press, USA, 2006 US Department of Energy, (1992), Root Cause Analysis Guidance Document, DOE-NE-STD-1004-92

124

Generacin de KPIs de conabilidad a partir de la integracin de plataformas informticas

El proceso de generacin de KPIs de conabilidad est directamente relacionado con la data que se cuente, adems de la diagramacin lgico funcional del sistema. Esta data, en su gran mayora, proviene de los registros de detenciones, tanto operacionales como de mantenimiento y, por lo tanto, es fundamental que este registro sea dedigno para obtener indicadores de rendimiento representativos, por consecuencia, robustos. La data histrica de detenciones, por lo general, se encuentra almacenada en bases de datos generadas a partir de softwares especializados. Sin embargo, lo anterior no es suciente para asegurar la calidad de esta data, complicando la generacin de KPIs e incluso muchas veces presentndose como un obstculo signicativo, en la implementacin de proyectos que mejoren la gestin de activos. Este artculo presenta un modelo conceptual-genrico, fundamentado en el uso de plataformas informticas, que permite abordar la validacin de la calidad de la data, previa a la emisin de KPIs, y por ende, entregar rigurosidad y representatividad para los anlisis. Bsicamente, este modelo se fundamenta en la integracin de las plataformas, disminuyendo los tiempos de procesamiento de la data y eliminando sesgos por la manipulacin de la misma. Adicionalmente, permite homologar y estandarizar los rboles de equipos, modos de falla, entre otros aspectos. En denitiva, se concluye que el soporte que brindan las plataformas informticas para asegurar la calidad de la data es fundamental, sin perjuicio de la complementaria y necesaria gestin de los ingenieros de conabilidad en la validacin o imputacin nal de cada detencin. Por otro lado, el uso de la data proveniente de sistemas de control, sumada a la data contenida en los sistemas de gestin del mantenimiento, representan una fuente atractiva para obtener KPIs de conabilidad representativos. Cabe mencionar que la principal restriccin del modelo proviene del uso de los datos de detenciones gestionados por los EAM que son cargados manualmente, lo que genera variabilidad en el proceso y por ende en los resultados.

Jorge Sandoval, Adolfo Arata, Pablo Valencia y Esteban Heidke. CGS, Chile

126

Creation of reliability KPIs based on integrated computing platforms

The process of generating reliability KPIs, apart from the logical functional layout of the system, is directly related to the available data. The vast majority of this data comes from operational and maintenance downtime records, and it is therefore essential that the record is reliable, to obtain representative and consequently robust performance indicators. The historical data of downtime is usually stored in databases which are generated using specialized software. However, that fact is not sucient enough to ensure the quality of this data, therefore complicating the generation of KPIs, and even appearing as a signicant obstacle in the implementation of asset management improvement projects. This paper presents a conceptual model-generic, based on the use of computing platforms. The model allows, prior to the issuance of KPIs, to address the data quality validation, thus providing rigor and representation for analysis. Essentially, this model is based on the integration of the platform, reducing data processing time and eliminating biases manipulation of the data. Additionally, it allows for approval and standardization of equipment trees and failure modes, among other aspects. Ultimately, it is concluded that the support oered by computing platforms to ensure the quality of the data is critical, regardless of the necessary and supplementary management participation of reliability engineers in the nal validation or rejection of each downtime. On the other hand, the use of data from control systems, added to existing data in the maintenance management systems, is an attractive source to obtain representative reliability KPIs. It is worth to mention, that the main constraint for the model comes from the use of downtime data managed by the EAM. These data are loaded manually, which causes variations in the process and therefore in the results.

Jorge Sandoval, Adolfo Arata, Pablo Valencia and Esteban Heidke. CGS, Chile

127

INTRODUCCIN
Actualmente, la administracin centra sus esfuerzos en intensificar su gestin, con el firme propsito de identificar las oportunidades de mejora e implementarlas, analizando indicadores de gestin (KPI) que le permiten hacer un uso ms eficiente de los recursos y enmendar desviaciones respecto a las planificaciones iniciales. Ahora bien, en el mundo de la gestin de activos, apoyado en las herramientas como las que brinda la ingeniera de confiabilidad, el fenmeno es el mismo. En este contexto, es clara la importancia del proceso que conduce a la emisin de reportes con indicadores de gestin, sin perder de vista que ste es un proceso intermedio de la cadena del valor de la ingeniera de confiabilidad. Esta cadena del valor consta, en trminos sencillos, de seis etapas principales: Registro de eventos y generacin de datos de detenciones. Almacenamiento y aseguramiento de calidad de los datos. Diagramacin lgico-funcional del sistema a analizar. Emisin de reportes con indicadores de gestin. Anlisis de indicadores de gestin y levantamiento de oportunidades de mejora. Evaluacin tcnica/econmica e implementacin de las oportunidades de mejora. Aunque se tiene conciencia de que todas las etapas previas a la implementacin de las oportunidades de mejora no agregan valor por si solas, sino que aportan una vez que se plasman en el roadmap de proyectos de mejoras, o en actividades concretas que van a modificar y dinamizar el plan de mantenimiento, esto no significa que sean menos importantes. Es ms, se identifican en ellas algunos componentes estratgicos que deben ser tratados con rigurosidad, ya que de ellos depende el resultado del proceso completo que conforma la cadena de valor de la ingeniera de confiabilidad. En este sentido, la etapa clave, es precisamente la primera, que tiene que ver con la generacin y registro o manejo de los datos de las detenciones del sistema productivo (datos histricos), que se requiere analizar. El principio bsico que rige para este tipo de procesos, donde se alimenta alguna herramienta informtica con datos que sern procesados para arrojar algn resultado, es que la calidad de los datos de entrada es directamente proporcional a la calidad de los resultados entregados por la herramienta. Esto es lo que determina la importancia de esta etapa. En consecuencia, y a modo de apoyar esta actividad, se propone un modelo que permite transformarla, en una etapa de aseguramiento de la calidad de la data, para lo cual se revisar el detalle de las actividades involucradas y las herramientas que intervienen (principalmente informticas), con el fin de proponer el estado ideal que asegure de calidad de la informacin.

128

METODOLOGA
Dado que se busca transformar la etapa de generacin y registro de datos de detenciones, en la etapa de aseguramiento de calidad de la data, es necesario comenzar con la definicin de los criterios que determinarn cundo un dato, o una base de datos, son considerados de calidad, y cundo no. Aclarado lo anterior, entonces se debe avanzar en la determinacin del proceso de generacin y captura de informacin, junto con incorporar los elementos necesarios (redefiniciones, validaciones, fuentes de informacin, etc.) para que este proceso sea asociado a la manipulacin de datos de calidad. Aqu, intervienen las herramientas informticas, usadas como repositorio de datos, y que adicionalmente pueden servir para su tratamiento.

Calidad de la data
Para determinar la calidad de la data, en primer lugar se definen los criterios que permiten discriminar entre datos buenos (buena calidad) y datos malos (mala calidad). En este sentido, se utiliza un criterio que contiene dos dimensiones diferentes: La calidad desde el punto de vista de la cantidad (en adelante la llamada Calidad Cantidad o CC) y la calidad que tiene que ver con la informacin que es registrada (en adelante la llamada Calidad Registro o CR).

Calidad - Cantidad
La CC se refiere bsicamente a que se registre la data de aquellos elementos que se requiere registrar, dentro de un sistema que ser sujeto de anlisis. Es decir, si un sistema est compuesto por diez elementos, y se registran datos nicamente de tres de ellos, por considerarlos elementos principales, despreocupndose de la data proveniente de los otros siete elementos, se obtiene data deficiente en cuanto a cantidad, o dicho de otra manera, no se estar registrando la data de todos los elementos que se requiere registrar dentro de un sistema. Cabe mencionar, que lo ideal es poder contar con data a nivel de elemento intercambiable, que es el nivel al cual se determinar la poltica de mantenimiento, sin embargo, para efectos de los clculos, cualquier nivel superior con el que se cuente la data (equipo, subsistema, etc.) permite hacer anlisis, con mayor o menor grado de precisin.

Calidad - Registro
La CR se refiere a que se registren los campos que se requieren registrar para un elemento o sistema en particular, es decir, que una lnea de datos contenga todos los campos que se definan como variables necesarias. Si en el ejemplo anterior, el sistema estaba compuesto por diez elementos, y se registran datos de los diez (data buena en cuanto a CC), pero los campos registrados son nicamente la fecha de detencin, omitiendo el resto de la informacin, se tiene data deficiente en cuanto a registro, o dicho de otra manera, no se estarn registrando los campos que se requieren en cada uno de los eventos que se detectan.

129

Para lograr el objetivo, y considerando la cadena del valor de la ingeniera de confiabilidad, los datos bsicos que se requiere registrar en una detencin, son los indicados en la Tabla 1, a saber: Tabla 1 Ejemplo tupla caracterstica de detencin para anlisis de confiabilidad
Fecha Inicio 01-05-2008 06-05-2008 Hora Inicio 3:45 11:25 Duracin [hrs.] 4,5 2,5 Tipo detencin MCM MP TAG CV-101 FE-100 Equipo detenido? S S

Respecto del tipo de detencin, se consideran, en trminos generales, las siguientes categoras: MCM: Mantencin correctiva mecnica. MCE: Mantencin correctiva elctrica. MCI: Mantencin correctiva instrumentacin. MP: Mantencin programada. DO: Detencin operacional. Cabe mencionar que es necesario identificar el tipo de detencin, al menos diferenciando entre detencin operacional y detencin de mantenimiento, ya que la detencin operacional afecta directamente el indicador Utilizacin, mientras que la detencin de mantenimiento afecta directamente el indicador Disponibilidad, ambos considerados KPI bsicos. En caso de que se cuente con data que tenga ms informacin que la mencionada con anterioridad, por ejemplo, informacin de costos directos de mantenimiento asociados a las detenciones, informacin de los modos de falla, etc. permitir hacer anlisis de mayor profundidad, en trminos de las conclusiones que se obtendrn. Por consiguiente, y en resumen, cuando se puede contar con data completa, desde la perspectiva de la CC y CR, se puede hablar de data de calidad.

Proceso de generacin y registro de eventos de detenciones

El fenmeno de generacin de eventos de detenciones es inherente a todo proceso productivo. Al registrar esta detencin, se est transformando el evento en dato, y si este dato es de calidad (CC y CR), entonces est en condiciones de ser usado para efectuar diversos tipos de anlisis. Si se recoge una mirada general de este proceso en diferentes industrias, se encuentran algunos elementos comunes, como son la generacin de un evento y el registro de este evento. Si bien es cierto, tambin se pueden encontrar realidades con un estado menor de evolucin en la gestin del mantenimiento, se considerar este escenario como situacin base, ya que un estado de evolucin menor requiere superar etapas previas antes de avanzar en la generacin de KPIs de confiabilidad, a travs de la integracin de plataformas informticas. Luego de la generacin de un evento (detencin), ste es registrado, para transformarlo en dato.

130

Las formas de registrarlo son mltiples, y dependen del estado de evolucin en la gestin del mantenimiento, y de la cultura asociada al dato, como se visualiza en la Figura 1.

Registros Manuales / Bitcoras Manuales

Registros en planillas

Registro en SW de gestin del mantenimiento

Registro automtico usando sistemas DCS o equivalentes

DATA DE CALIDAD

Evolucin en la gestin del mantenimiento y cultura del dato

Figura 1 Evolucin de las formas de registro de los eventos

Una vez registrada, la data debe ser tratada para usarla como entrada para las herramientas de confiabilidad.

Procesos de aseguramiento de calidad de la data

Definidos los criterios que determinan la calidad de la data (CC y CR), es necesario mencionar que, pese a que hay ejemplos donde se ha logrado obtener data de calidad directamente desde el origen (cuando se registra el evento) de manera automtica, en general sta depende de las personas, y por ende, no siempre los datos son robustos. En este sentido, se identifican algunos vicios tpicos que impactan el registro, que afectan principalmente a la CR, ya que la CC generalmente obedece ms bien a un lineamiento de la jefatura. Es habitual que se encuentre data con registros incompletos, eventos no registrados, o registrados mucho tiempo despus de ocurridos, y por tanto, con informacin poco fidedigna. En los casos ms evolucionados, soportados en plataformas de gestin del mantenimiento (como el mdulo PM de SAP), tambin se visualizan estos problemas, ya que lo habitual es que no se reconozca esta actividad como importante, y por tanto, se realiza meramente por cumplir. El principio rector, en este sentido, es que el tiempo y esfuerzo que toma ingresar mal un evento, es el mismo que toma ingresarlo bien. Al respecto, es necesario hacer dos alcances: el primero, relacionado con la gestin de confiabilidad, indica que la experiencia en la implementacin de este tipo de metodologas de gestin provoca un efecto de tirar el dato, ya que la persona que lo registra comienza a ver un sentido a su labor, puesto que ste es usado para generar los KPI con los cuales se gestionarn mejoras al proceso, que a su vez, impactarn positivamente en su trabajo. El segundo, relacionado con los sistemas de validacin de la data, indica que, dado que se requiere que el proceso de registro sea robusto y

131

sostenible en el tiempo, los modelos de mejor funcionamiento son aquellos que incorporan etapas de validacin de la misma, a travs de un responsable que revise los registros, eventualmente los corrija, y finalmente los apruebe como data vlida.

Modelo de integracin de sistemas

Una vez que se cuenta con data de calidad, se debe avanzar hacia el uso eficiente de los recursos y centrarse en aquellas actividades que mayor valor agregan a la organizacin. Pese a que ya se mencion la importancia de la etapa de registro de la data, y la posterior generacin de KPIs a partir de sta, se sabe tambin que la etapa que mayor valor agrega es la etapa de anlisis de los KPIs levantados y transformacin de stos en oportunidades de mejora. Considerando lo anterior, la propuesta apunta al uso de las plataformas existentes, y su integracin, con el fin de agilizar la emisin de KPIs, y eliminar el sesgo humano presente en la manipulacin de la data, en beneficio de disponer ms tiempo para dedicar al anlisis de KPIs y levantamiento de oportunidades de mejora. Por lo tanto, el soporte y uso de las herramientas informticas, y su integracin, resulta fundamental. Es conveniente aclarar que cuando se habla de integracin de plataformas, no necesariamente implica que todos los procesos estn informatizados, y las respectivas plataformas integradas, sino ms bien que las plataformas que se identifican como fuentes de informacin y las que se usen para tratamiento de sta (como sistemas de registro, imputacin y validacin de datos) puedan funcionar de manera integrada, sin perjuicio del rol que cumple aquella persona encargada y responsable del aseguramiento de la calidad de la data, complementndola y tratndola de acuerdo a los lineamientos de cada operacin. En la Figura 2 se visualiza el diagrama que representa el modelo propuesto.

132

INICIO

Generacin de un evento de detencin Sistemas DCS, SCADA o similares Plataforma de Gestin del Mantenimiento

Registro de la detencin

Base de Datos de detenciones

Contamos con toda la informacin? SI

NO

Problemas de CC?

NO

Problemas de CR?

NO

SI Redefinir e incorporar nuevos elementos

SI Plataforma de Tratamiento de Detenciones

Base de Datos validada, de Calidad

Complemento y validacin de la data

Plataforma de Ingeniera de Confiabilidad

Emisin de KPIs de Confiabilidad

FIN

Figura 2 Diagrama del modelo de integracin de plataformas

El modelo entrega como resultado KPIs caractersticos de confiabilidad, como disponibilidad, utilizacin, tiempo medio entre fallas, tiempo medio para reparar, anlisis de Pareto, etc. El tipo y cantidad de KPIs depender de la plataforma de confiabilidad que se use. Adicionalmente, como externalidad positiva, el modelo genera bases de datos de calidad y validada, la homologacin y estandarizacin de rboles de equipos, modos de falla, tipos y clasificacin de las detenciones.

133

Caso aplicado
Para validar el modelo y verificar los beneficios que ste tiene, fue necesario primero encontrar una realidad donde se visualizaran las condiciones para ello, es decir, entendimiento de la problemtica, compromiso de gerencia, disponibilidad de sistemas, uso de los sistemas, disponibilidad de recursos para mejoras, propensin a los cambios y mejoras, y la voluntad para implementarlos. Esto se pudo encontrar en una empresa minera, donde despus de determinar los alcances y ver detalles de las actividades a desarrollar, se tom la decisin de avanzar en el proyecto de emisin de reportes de confiabilidad, buscando la integracin de las plataformas informticas disponibles. En este caso, el modelo recoge datos relacionados con tiempo (hora de la detencin) desde el sistema DCS (pese a que estn disponibles los datos de SAP, pero de menor precisin), que registra todas las alarmas del sistema que se requiere analizar. En este caso, la condicin es ideal, adems porque estn monitoreados todos los equipos que forman parte del sistema, por lo que la data es completa en trminos de CC. Sin embargo, dado que la data proveniente del DCS incluye nicamente informacin temporal de la detencin, ste se integr con un sistema de registro y tratamiento de la data, que recoge los datos desde el DCS, para luego ser tratados por el encargado de aseguramiento de calidad de la data, cuya responsabilidad es la de validar dicha data con informacin levantada en los sistemas complementarios (pero no menos importantes para efectos de la validacin), como bitcoras de operaciones y mantenimiento (en la mayora de los casos existen), entrevistas a operadores, mantenedores, y supervisores. Esta persona es, por lo tanto, el administrador del sistema de registro y tratamiento de la data. Una vez que tiene informacin completa de los eventos del periodo a analizar (en el caso aplicado corresponde a un turno) complementa la informacin que est en el sistema de registro y tratamiento de la data, y le asigna un tipo de detencin, y solo una vez que sta ha sido complementada y validada (cuenta con el visto del administrador del sistema), es considerada vlida para ser utilizada en anlisis posteriores (data de calidad). Finalmente, la data es exportada desde la plataforma de tratamiento de la data, en formato Excel, y manipulada nuevamente por el encargado del aseguramiento de calidad de la data, para que cumpla con el formato requerido para el clculo de los KPIs de confiabilidad, que a su vez son calculados tambin en Excel. El diagrama de la Figura 3 representa la situacin inicial previa al desarrollo del proyecto.

Otras fuentes de informacin (bitcoras, entrevistas, etc.)

INICIO

Generacin de detencin

Registro automtico de detencin en DCS

Carga automtica de datos a herramienta de tratamiento de detenciones

Tratamiento y validacin de detenciones

Exportacin de BD a excel

Tratamiento de BD en excel (formatos)

Generacin de KPI de confiabilidad en excel

Emisin de reportes de confiabilidad

Interpretacin de reportes y KPI

Levantamiento de oportunidades de mejora

FIN

ASEGURAMIENTO DE CALIDAD DE LA DATA

GENERACIN DE KPIs DE CONFIABILIDAD

LEVANTAMIENTO OPORTUNIDADES DE MEJORA

Figura 3 Diagrama de la situacin inicial del caso aplicado

Como se puede apreciar, y segn lo expuesto, en este caso la primera parte de la integracin (la que tiene que ver con el aseguramiento de calidad de la data) ya haba sido implementada, por lo que nicamente fue necesario incorporar la visin estratgica operativa y entregar los lineamientos necesarios para aprovechar de la mejor manera dicha integracin.

134

Los tiempos involucrados en las diferentes partes, considerando que en este caso la emisin de reportes de confiabilidad es diaria (base de clculo nueve horas disponibles), son: cuatro horas para el aseguramiento de calidad de la data, tres horas para la generacin de KPIs de confiabilidad, dejando disponibles nicamente dos horas para el anlisis y levantamiento de oportunidades de mejora. La hiptesis propuesta indica que se puede generar una integracin de las plataformas que se consideren fuentes de informacin vlidas, con las plataformas de ingeniera de confiabilidad, disminuyendo de manera significativa el tiempo de tratamiento de la informacin para obtener KPIs de confiabilidad, para poder destinarlo al anlisis de KPIs y levantamiento de oportunidades de mejora. Dado lo anterior, y para completar la integracin de plataformas, se avanz en la implementacin de una herramienta de ingeniera de confiabilidad (R-MES), que toma datos directamente de la plataforma de tratamiento de la data, como se visualiza en el diagrama de la Figura 4.

Otras fuentes de informacin (bitcoras, entrevistas, etc.)

INICIO

Generacin de detencin

Registro automtico de detencin en DCS

Carga automtica de datos a herramienta de tratamiento de detenciones

Tratamiento y validacin de detenciones

Tratamiento de BD en herramienta de IC

Generacin de KPI de confiabilidad en excel

Emisin de reportes de confiabilidad

Interpretacin de reportes y KPI

Levantamiento de oportunidades de mejora

FIN

ASEGURAMIENTO DE CALIDAD DE LA DATA

GENERACIN DE KPIs DE CONFIABILIDAD

LEVANTAMIENTO OPORTUNIDADES DE MEJORA

Figura 4 Diagrama de la situacin final del caso aplicado

La principal restriccin del modelo aplicado al caso, viene dada por el tratamiento manual que hace el responsable del aseguramiento de calidad de la data, ya que puede incorporar variabilidad a este proceso.

RESULTADO Y DISCUSIN
Los resultados obtenidos luego del desarrollo del proyecto del caso aplicado, son claros. Los tiempos involucrados en las diferentes partes se redujeron para dejar mayor tiempo disponible al anlisis y levantamiento de oportunidades de mejora. El aseguramiento de calidad de la data tom tres horas, la generacin de KPIs de confiabilidad una hora, dejando disponibles ahora cinco horas para el anlisis y levantamiento de oportunidades de mejora. De los antecedentes expuestos, se puede desprender que es posible, mediante el uso de los sistemas informticos disponibles, disminuir los tiempos de las actividades de menor valor agregado, dando mayor espacio a las actividades de anlisis e identificacin de oportunidades de mejora, lo que se evidencia claramente en el caso aplicado. Y no solo hay una ganancia en tiempo de anlisis, sino que adems, con la incorporacin de la plataforma especfica de ingeniera de confiabilidad se obtuvieron ms y mejores indicadores, tanto a nivel equipo como a nivel sistmico. Adicionalmente, la solucin de sistemas integrados es ms flexible, ya que permite modificar condiciones del sistema, como el sistema a analizar, de manera muy rpida (algunas horas), mientras que en la condicin inicial tomara probablemente varias semanas de trabajo.

135

El anlisis evidencia de manera emprica que los sistemas informticos, en trminos generales, son buenas herramientas de apoyo. La recomendacin es aprovecharlos en la dimensin que corresponde, si prejuicio del valor agregado irremplazable de los ingenieros de confiabilidad o encargados del aseguramiento de calidad de la data.

CONCLUSIN
Se puede concluir del anlisis realizado, que una correcta utilizacin de las herramientas de apoyo, especialmente sistemas informticos, ya sean ERPs, DCSs, EAMs, u otros, entrega beneficios significativos en trminos de ahorro en los tiempos de procesamiento de la informacin, y adicionalmente entregan mayores niveles de flexibilidad dado que son fcilmente reconfigurables, y su integracin genera sinergias, unificando fuentes de informacin y data, y eliminando al mximo el error humano inherente a la manipulacin de la misma.

AGRADECIMIENTOS
Nuestros agradecimientos al equipo de consultores CGS por su apoyo y ayuda en el desarrollo de este caso aplicado, como de tantos otros.

NOMENCLATURA
KPI CC CR Tupla SAP ERP DCS EAM Key Performance Indicators o Indicadores Clave de Desempeo Calidad - Cantidad Calidad - Registro Fila con secuencia ordenada de datos Marca comercial de ERP Enterprise Resource Planning; Softwares de planificacin de recursos empresariales Distributed Control System; Sistemas de control distribuido Enterprise Asset Management; Software de Gestin de Activos

REFERENCIAS
Arata, A. Furlanetto, L. (2005) Manual de Gestin de Activos y Mantenimiento, RIL, pp. 767-797.

136

Anlisis de causa raz de fallas, la herramienta clave del conjunto de herramientas de ingeniera de abilidad

Fallas sin previo aviso en el servicio e incidentes de seguridad de mquinas y estructuras se han experimentado en muchas industrias, con diferentes grados de daos indirectos en seguridad, salud y medio ambiente, negocios, reputacin, etc. La mayora de las empresas, en una decisin de gestin muy bien conocida, adoptan la ingeniera de conabilidad y mantenimiento predictivo como la principal estrategia de mantenimiento, que est diseada para evitar fallas catastrcas de los sistemas crticos en las plantas produccin. Por desgracia, estos eventos de falla ocurrirn independientemente de la ecacia del programa de conabilidad de la planta. Por esta razn, se implementa en el terreno un buen programa para comprender la causa raz de los problemas, evitando as la repeticin de stos y reduciendo el costo de falta de conabilidad. Entendiendo las fallas y sus causas, se incorporan las soluciones tcnicas en las distintas etapas y por lo tanto, se evita la repeticin de errores. El anlisis de causa raz de fallas es el proceso que estudia y analiza la falla de los componentes de una mquina y evita los problemas de recurrencia relacionados con los sistemas y mquinas de proceso. El xito de anlisis de fallas depende de la utilizacin de tcnicas analticas adecuadas en la secuencia correcta. El ejemplo que se proporciona en este documento se centra en la denicin y los requisitos para un anlisis de fallas realizado profesionalmente. El estudio de caso presentado en este trabajo, un incidente con una sistema de sujecin v-band del tubo de refrigeracin de una turbina de gas que mostraba claros signos de dao de fatiga por desgaste ( freeting) en la zona de la falla, debido principalmente a un diseo pobre y vibraciones procedentes de la mquina en operacin. Las acciones correctivas para evitar la recurrencia del problema fueron tomadas y las lecciones aprendidas de este incidente han sido compartidas con otros sitios. Este anlisis de fallas proporcion benecios de seguridad y mantenimiento incalculables.

Fernando Vicente. A BB Full Service, Argentina

138

Root Cause Failure Analysis, the key tool from reliability engineering toolbox

Service failures and safety incidents of machines and structures without warning have been experienced in many industries with varying degrees of consequential damages (health, safety and environmental, business, reputation, etc). In a very well known management decision most companies adopt reliability engineering and predictive maintenance as the main maintenance strategy, which is designed to prevent catastrophic failures of critical plant production systems. Unfortunately, these failure events will occur no matter how eective the plant reliability program is. For this reason, a good program shall be implemented at site to understand the root cause of the problems, avoiding recurrence issues and reducing the cost of unreliability. With an understanding of failures and their causes, technical remedies were incorporated at various stages and thus, the recurrence of failures is prevented. The Root Cause Failure Analysis is the process that study and analize the failure of machines components and avoid the recurrence issues related to the systems and process machines. The success of failure analysis depends on the use of proper analytical techniques in proper sequence. The example provided in this paper focus on the denition of and requirements for a professionally performed failure analysis. The case study presented in this paper, an incident with a v-band clamp system from a gass turbine cooling pipe showed clear signs of freeting fatigue damage at failure zone, mainly due to a poor design and vibration coming form machine operation. Corrective actions to avoid the recurrence of the problem has been taken and lessons learned from this incident have been shared with other sites. Safety and maintenance unquantiable benets have been achieved through this failure analysis.

Fernando Vicente. A BB Full Service, Argentina

139

INTRODUCTION
The prevention of potential damage to machinery is necessary for safe, reliable operation of process plants. Equipment downtime and component failure risk can be reduced only if potential problems are anticipated and avoided, however failures will occur even if your maintenance process is in excellent performance. Is for that reason that a formal process to find the root causes of the problem is required. What is failure analysis? There are several definitions, but a quite typical is the process of interpreting the features of a deteriorated system or component to determine why it no longer performs the intended function (Neville W. Sachs, 2007). The failure analysis process involves first using deductive logic to find the physical or mechanical and human root causes of the problem, and then using inductive logic to find the latent (most commonly known as organizatinal root) causes. Finally an engineering solution should also lead to the changes needed to prevent the recurrence of failure. Figure 1 shows the Root Cause Fault Analysis (RCFA) process.

Failure occur

Gathering information

Process and operation data Technical specifications Maintenance histoy

Define the problem

RCFA Process
The cause is obvious?

No

Initiate the basic RCA

Problem specification:What, When, Where, etc

Possible Root Causes Development

Yes
Real Cause verification Assess and design the solution
Visual Inspection of piece Metallographic investigation Fracture face assessment (SEM analysis) Engineering study

Most probably causes identification

Failure Analysis investigation if necessary

Check and approbe modification (MOC)

Validate modification

Maintenance plan revision if neccessary

Figure 1 RCFA process

It is essential to understand that failures can be induced during the whole life cycle of equipment, see figure 2. It is assumed that all failures without exception belong to one or more of the following Seven Causes: Faulty design Material defect

140

 Manufacturing and processing deficiencies Assembling or installation defects Off-design or unintended service conditions Maintenance deficiencies (neglect, procedures) Improper operation

Figure 2 Failure origin

The Root Cause Failure Analysis is a process that shall be present in a good reliability maintenance program; great benefits can be obtained from this process like avoiding recurrence problem, hidden failure mechanism identification, lesson learning from incidents and accidents. It would be nice and neat if there were only one cause per failure, because correcting the problem would then be easy. However, in reality, there are multiple causes to every equipment failure. Roots can be divided in physicals, humans, and latents. Most of the time failure analysis process stops at the identification of the physical causes. If the engineers team just find out the physical causes of the failure, all done is to determine why that one incident occurred, but going into greater depth and finding the human roots allow one to change human behaviour and eliminate a group of failures. But further reaching into and correcting the latent (organizational issues) weaknesses result in whole classes of failures being eliminated. The roots can be defined in the following way: Physical roots: This is the physical mechanism that caused the failure, i.e., corrosion, fatigue, etc. Human roots: This is how inappropriate human intervention resulted in the physical roots. Latent roots (system weaknesses): These are the corporate policies or actions that allow inappropriate human action.

141

Physical

Latent

Human

Figure 3 Levels or roots of failure causes

There are several and different tools for finding the various roots of failures. These include logic trees, Ishikawa (fishbone) diagrams, 5 whys and other systems that use an infinite number of combinations as well as a variety of copyrighted formats. These tools shall be used during the RCFA process to provide a final and simple solution or deriving into a deeper failure investigation, for the root causes's validation.

When should a failure analysis be conducted and how deeply should it go?
It depends of the possible consequence of an undesired event. If a chronic problem appears, with a simple 5 Whys or Ishikawa diagram, a simple solution could be developed and implemented. But, if a serious incident or accident occurs, which there is the possibility of a serious injury or serious environmental event, a root cause analysis (RCA) is always warranted. In some circumstances a more detailed investigation needs to be developed. Generally, a metallurgical failure analysis will be required to validate the physical root hypothesis (ASM Metals Handbook Volume 11, 1992) This paper shows two case studies related to the failure analysis investigation, where root cause has been found to avoid the problems recurrence.

METHODOLOGY
If the failure is one of those with the probability of suffer a serious incident, it was an accident with catastrophic consequence or the event requires a deeper failure analysis investigation, the typical steps in the failure analysis investigation shall be: 1. Diagnosing the failure. Make a preliminary examination of the failed pieces (visual inspections, photos with high magnifications). What type of failure was it? What basic forces were involved?

142

2. Collect background data. Look at the installation and the surroundings. What was the normal environment, power usage, operating conditions, etc.? Find out if there have been changes in the last month, year, or other significant intervals. 3. Under low-power magnification, look at the pieces, fracture faces, and other surfaces; develop a logic tree that lists every symptom of the failure; and determine the possible causes of the symptoms and the failure scenarios. Most of the time in this stage, the Ishikawa diagram, 5 Whys or Fault tree diagram performed, shall be updated in this stage. 4. Deeper failure analysis on the critical pieces. This may involve metallography, nondestructive testing, chemical analysis, residual stress analysis, or a variety of other inspection tools used to determine the state of the pieces. 5. Determine the physical failure mechanisms and how the failure happened. 6. Determine the other root causes. Go further and find the human and latent roots to determine how to prevent future occurrences.

Case Study 1: Gas turbines cooling piping failure analysis

An incident with possibility of suffer serious injury has occurred with the high pressure gas turbines cooling pipe in the v-band clamp system. The cooling pipe of the high pressure turbine has the function of directing part of the air from the axial compressor, which is at a pressure of approximately 14 bars and 400 C to be sent to the turbine with the purpose of reducing the temperature of operation in the area of the impellers. During the normal operation of gas turbine a sudden failure happened on the cooling pipe v-band clamp system (see figure 4). Due to the possibility of serious injury over maintenance personnel, a RCFA process was initiated to find out the root causes of the problem and avoid the problem recurrence with high potential safety consequences. Figure 5 shows the V clamp system.

Figure 4 Gas turbines cooling pipe failure.

143

V-band Clamp system

= 65 mm; thickness = 0,97mm

Figure 5 V-band clamp system

Diagnosing the failure

Visual inspection with low and high resolution at failure zone was performed. Chevrons marks can be easily appreciated in figure 7, means that brittle fracture has occurred. A valuable feature on the fracture face of a brittle fracture is that the chevron marks point to where the failure started. They show where to take the metallurgical samples needed to check as to whether the metallurgy or condition of the material played a part in the failure. In a brittle fracture, the fracture plane is perpendicular to the direction of the forces that caused the failure. There is a clear wear pattern in the contact zone between pipe and clamp. The crack seems to start in this zone, SEM (Scanning Electron Microscope) analysis shall be performed at crack initation zone identified by Chevrons marks. There are times when it is difficult to see the chevron marks, and a careful inspection with a narrow-beamed light source, as shown in Figure 6, is extremely helpful. The failed part, including all its fragments, should be subjected to a thorough visual examination before any cleaning is undertaken

Figure 6 Light to accentuate the surface features

144

Chevrons. Crack origin direction

Figure 7 Chevron Marks indication of crack initiation

Collecting background data

The failure investigation should include gaining an acquaintance with all pertinent details relating to the failure, collecting the available information regarding the design, manufacture, processing, and service histories of the failed component or structure. In collecting service histories, special attention should be given to environmental details, such as normal and abnormal loading, accidental overloads, cyclic loads, variation in temperature, temperature gradients, and operation in a corrosive environment. A complete photographic register of the failed piece is strong recommended for a good preliminary analysis. Operating conditions of the gas turbine at the moment of failure were normal, no sign of any upset process conditions. Operating pressure, temperature, and speed machine were normal at time of the event. There were no signs of poor operation of the machine.

Under low-power magnification

Particular attention should be given to the surfaces of fractures and to the paths of cracks (ASM Handbook Volume 12: Fractography, 1998). The amount of information that can be obtained from examination of a fracture surface at low-power magnification is extensive. The orientation of the fracture surfaces must be consistent with the proposed mode of failure and the known loads on the failed part. Macroscopic examination can sometimes reveal the direction of crack growth and hence the origin of failure. Figure 8 shows the possible fatigue crack initiation.

145

Possible fatigue crack origin

Figure 8 Possible fatigue crack initiation. Macroscopic examination

The photographic register shows in figure 9 a wear contact pattern between pipe and v-band clamp has been occurred. Preliminary conclusions indicate that a contact fatigue process known as fretting fatigue could have been involved during the failure process development. SEM analysis was performed to validate this hypothesis.

Crack initiation Contact pattern

Figure 9 Wear pattern contacts between clamp and pipe

Deeper failure analysis on the critical pieces and physical root identification
In failure analysis investigation to corroborate the type of damage mechanism that is present metallurgical and SEM analysis shall be performed. A SEM analysis has the advantage over light microscopy because of the large depth of field and very high magnifications attainable, typically 5000 to 10,000X. Metallographic examination provides the investigator with a good indication of the class of material involved and its structure. If abnormalities are present, these may be associated with undesirable characteristics that predispose to early failure. In this case study the SEM analysis revealed that fretting fatigue damage was the physical root of the problem. Fretting fatigue damage was intensified by the natural vibration of the system during machine operation. Chemical and

146

metallurgical analysis showed that material it was AISI 321 an austenitic stainless steel for high temperature operation, no material degradation was detected. Figure 10 shows metallurgical analysis and figure 11 shows the SEM analysis where fatigue process can be appreciated.

Figure 10 Metallurgical image of failed zone

Figure 11 SEM analysis of fractured piece

147

Fretting can occur when a pair of structural elements is in contact under a normal load while cyclic stress and relative displacement are forced along the contact surface. The strength is reduced because of concentrations of contact stresses, such as contact pressure and tangential stress at the contact edge, where fretting fatigue cracks initiate and propagate. Cracking due to fretting fatigue starts at very early in fretting fatigue life. During this early period, fretting fatigue cracks tend to close and propagate very slowly especially in a low stress amplitude range due to the high contact pressure acting near this contact edge (ASM Handbook Volume 19: Fatigue and Fracture,1996).

Stress Analysis
An accurate stress analysis of the magnitude and type (axial, torsion, bending) of stress is required to substantiate the role of stress during the failure process. Sometimes simple analytical closed-form calculations are used by engineers. When pieces or components are designed with very complex shapes and high thermal gradients, a finite-element analysis (FEA) may be required to estimate the level of stress that most likely existed in the failed component. For this case a computational stress analysis was performed to validate the hypothesis of fretting fatigue that was generated by the contact between the v-band clamp and piping. Figure 12 shows clearly a high stress contact zone with the same pattern that the failed piece.

Figure 12 Stress analysis

Human and latent root identification

The human roots are those human errors that result in the mechanisms that caused the physical failures. This is the most difficult task within the failure analysis process because of there are no physical evidence and most of the time causes are based on assumptions. Figure 13 shows typical human errors classification.

148

Operator Error Handling Error

Design Error

Human Errors Maintenance Error Installation Error

Assembling Error

Inspection Error

Figure 13 Human Errors

For this case study, after physical root determination a brainstorm process was initiated to detect those probable human errors that generated the physical damage. Two main human issues were select as the most probable cause; a deficient mounting process (at machine factory site) of the vband system could have led the fatigue process in combination with a poor design of the clamp system. The latent root (organizational weakness) could have been the lack of procedures to guarantee the good performance of v-band clamp system on this type of gas turbines and the lack of a service bulleting mention this kind of OEMs problems.

IMPROVEMENT ACTIONS
Maintenance inspection plan has been modified to perform inspection to detect this type of damage. For this particular case, fretting fatigue cracks are not visible due to they are hidden under the v-band meaning that, in-service inspection (during machine operation) is not feasible. During the gas turbine major overhaul the v-band system shall be dismounted and inspected (visual and liquid penetrator testing).

CONCLUSION
The RCFA process is very important tool from the reliability maintenance program. Several benefits can be obtained from failure analysis investigation. One of the main benefits is the avoidance of

149

recurrence problems. Quantifiable and unquantifiable savings can be getting from this type of analysis, in terms of impact over safety and environment, business, reputation, production, etc. From the case study, the gas turbine coolings pipe failed due to damage mechanism known as "fretting fatigue" or "rolling contact fatigue". This was caused due to the lack of a good tight force on the v-band clamp system and it was intensified by machines vibration environment.

REFERENCES
Neville W. Sachs (2007) Practical Plant Failure Analysis, New York. ASM Metals Handbook Volumen 11 Failure Analysis and Prevention( 1992), Printed in United State of America. ASM Handbook Volume 12: Fractography ASM International Handbook Committee (1998) Electronic Format ASM Handbook Volume 19: Fatigue and Fracture ASM International Handbook Committee (1996) Stephens, R.I., Fatemi, A., Stephens, R.R., Fuchs, H.O. (2001) Metal Fatigue in Engineering John Wiley & Sons,New York.

150