diagnóstico automático de turbinas de vapor en línea

Diagnóstico Automático de Turbinasde Vapor en Línea-Edición Única

Title Diagnóstico Automático de Turbinas de Vapor en Línea-EdiciónÚnica

Issue Date 2008-05-01

Publisher Instituto Tecnológico y de Estudios Superiores de Monterrey

Item Type Tesis de maestría

Downloaded 01/05/2018 08:11:23

Link to Item http://hdl.handle.net/11285/569077

INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY

Diagnóstico Automático de Turbinas de Vapor en Línea

Autor:

Enlai Pensado Vassallo

Sometido al Programa de Graduados en Informática y Computación en cumplimiento parcial con los

requerimientos para obtener el grado de:

Maestro en Ciencias de la Computación

Asesores: Dr. Juan Frausto Solís

Dr. Eduardo Preciado Delgado

Cuernavaca, Morelos. Mayo del 2008

Presentada por:

Enlai Pensado Vassallo

Aprobada por:

Dedicatoria

A mi amada Verónica, quien supo brindarme su cariño, soportar mi estrés y

finalmente entender que se requiere de sacrificios para obtener prosperidad.

A mis hijos, Fabian y Camila, por ser el combustible e inspiración para aguantar aún en los momentos más desesperados.

A mis padres, por el don de la vida, su amor y mi formación.

A mis suegros, por su apoyo total e incondicional.

A mis asesores quienes no me abandonaron pese a mis ánimos y desánimos.

Al Instituto de Investigaciones Eléctricas, por brindarme la oportunidad y las condiciones adecuadas para mi desarrollo.

A mis profesores, por todos sus consejos y su amistad.

A Dios, por la creación de todo.

Reconocimientos Gracias al apoyo y los conocimientos compartidos por mis asesores tanto en el IIE por

parte del Dr. Eduardo Preciado Delgado, como en el ITESM a través del Dr. Juan Frausto Solís.

Gracias a todos aquellos que sirvieron como fuentes de conocimiento de primera mano, quienes compartieron su extenso conocimiento sobre turbinas con la paciencia que mi inexperiencia requirió: Ing. José Antonio Ramírez Solís, M. C. Carlos Alberto Mariño López, Ing. Víctor Manuel Cristalinas Navarro, M. C. Juan José Rivera Grijalva, y todos los compañeros investigadores de la Gerencia de Turbomaquinaria, que de una forma u otra apoyaron este trabajo.

Gracias muy especiales al Dr. Jorge Aguirre por su apoyo tanto como responsable del proyecto número 13091, “Desarrollos en diagnóstico de turbomaquinaria”, así como supervisor del software desarrollado en esta investigación.

Gracias también a otros miembros del IIE, quienes tuvieron la atención y apoyaron con su experiencia en áreas afines a la diagnosis de turbinas, entre los cuales destacan investigadores de la talla del Dr. José Miguel González Santaló, quien es ampliamente reconocido por su conocimiento en el área y siempre me ha impulsado a exigirme lo mejor de mi, o el Dr. Pablo Héctor Ibargüengoitia González, quien tanto en vivo o a través de sus investigaciones puso claridad sobre muchos puntos duros de este trabajo.

Gracias a quienes ayudaron en todas las revisiones de este trabajo.

Gracias igualmente a quienes fundamentaron la ciencia y la tecnología aplicadas en esta investigación.

Prefacio Nuestra actualidad refleja una serie de problemas estrechamente relacionados, pues

la creciente demanda por servicios como agua potable, energía eléctrica o transporte, así como la necesidad de transformar y fabricar todo tipo de artículos han desencadenado la complicada situación del calentamiento global. Uno de los principales factores al respecto, es el uso de combustibles fósiles como fuente principal para la generación de energía eléctrica en todo el orbe. Toda vez que, pese a la existencia de alternativas de generación (plantas eólicas, geotérmicas, hidroeléctricas, mareomotrices, de biomasa, solares), tales opciones fallan en cuanto a: capacidad insuficiente para responder a la demanda, problemas de factibilidad técnica o económica, así como disponibilidad o confiabilidad. De esta manera, siendo la energía nuclear la única alternativa viable para sustituir la quema de combustibles fósiles en plantas termoeléctricas, con antecedentes como el accidente de Three Mile Island en 1979 [WALKER 2004] o el desastre de Chernobil en 1986 [HAWKES 1986], han llevado a no despreciar los riesgos relacionados, lo cual complica su manejo y en consecuencia ha limitado la proliferación de más centrales nucleares.

Bajo esta realidad, la problemática se concentra en dos tareas: aumentar el rendimiento de las plantas termoeléctricas y reducir la emisión de contaminantes, tanto gases como líquidos. Por todo esto, y en cumplimiento con los valores expresados en la misión y visión del Instituto de Investigaciones Eléctricas (IIE), se ha seleccionado desarrollar una herramienta de apoyo para el estudio de estado de equipos rotativos remotos. Para ello, tomando como base la experiencia del IIE en el diagnóstico de turbinas de vapor, se ha desarrollado una plataforma capaz de determinar la presencia de fallas a través del modelado de la turbina y sus elementos, se representa el comportamiento esperado y, mediante la transformación de las señales recolectadas del sistema, se calcula el comportamiento real del equipo. Con ambos resultados se procede a aplicar una técnica de diagnóstico que permita detectar las desviaciones e inferir los desperfectos existentes. Buscando mejorar la certeza y calidad de los resultados del análisis, como complemento, se ejecuta una revisión de las reglas de diagnóstico, con base en el registro histórico de diagnosis realizadas y empleando un algoritmo genético para la inclusión de reglas nuevas, las cuales se evalúan como candidatas para la mejora del producto.

Este documento representa los esfuerzos de más de un año en el área de diagnóstico, en busca de la adecuada arquitectura para una infraestructura de diagnóstico remoto que permita la detección de fallas en centrales con turbina de vapor. El principal reto de crear esta infraestructura es la conjugación del conocimiento de ingeniería mecánica para un producto de ciencias computacionales. De hecho, el material del respaldo teórico involucrado en esta investigación, se distribuye en tres partes; inicialmente se abordan los enfoques y estrategias abordadas por proyectos computacionales de diagnóstico; luego se exponen las alternativas para detectar defectos en turbocomponentes, conforme a la ingeniería mecánica; posteriormente se describen algunos casos destacables sobre la aplicación conjugada de ambas ciencias.

Índice CCaappííttuulloo 11 IInnttrroodduucccciióónn ..........................................................................................................................................................................................11

1.1 Antecedentes .........................................................................................2 1.2 Motivación .............................................................................................5 1.3 Problemática ..........................................................................................6 1.4 Objetivos ................................................................................................7 1.5 Alcances y limitaciones ...........................................................................8 1.6 Hipótesis ................................................................................................8 1.7 Contribuciones .......................................................................................9 1.8 Organización de la tesis ..........................................................................9

CCaappííttuulloo 22 FFuunnddaammeennttooss ddee ddiiaaggnnóóssttiiccoo ..................................................................................................................................1100 2.1 El problema de diagnóstico ..................................................................11 2.2 Profundidad del diagnóstico .................................................................12 2.3 Enfoques del diagnóstico......................................................................14 2.3.1 Diagnóstico basado en sistemas expertos..........................................15 2.3.2 Diagnosis probabilística .....................................................................17 2.3.3 Diagnóstico por redes neuronales .....................................................18 2.3.4 Diagnóstico por clasificación .............................................................21 2.3.5 Diagnóstico basado en modelos ........................................................24 2.3.6 Diagnóstico basado en casos .............................................................27 2.3.7 Diagnóstico orientado a objetos y ontologías ....................................29 2.3.8 Diagnosis por simulaciones................................................................30 2.3.9 Diagnóstico con algoritmos genéticos ...............................................31 2.3.10 Diagnóstico con enfoque SAT ............................................................32 2.4 Diagnosticabilidad ................................................................................33 2.5 Diagnóstico como un elemento de mejora ...........................................34 2.6 Herramientas de diagnóstico ................................................................36 2.7 Afinidad entre diagnóstico y pronóstico ...............................................39 2.8 Evaluación de sistemas de diagnóstico .................................................40 2.9 Conclusiones del capítulo .....................................................................41

CCaappííttuulloo 33 DDiiaaggnnoossiiss ddee ssiisstteemmaass mmeeccáánniiccooss ......................................................................................................................4422 3.1 Turbomaquinaria..................................................................................43 3.2 Generalidades sobre turbinas ...............................................................43 3.3 Ciclos termodinámicos .........................................................................47 3.3.1 Ciclo Rankine .....................................................................................47 3.3.2 Ciclo Brayton .....................................................................................49 3.4 Generación de energía con turbinas .....................................................51 3.4.1 Ciclo combinado ................................................................................53 3.4.2 Cogeneración ....................................................................................55 3.4.3 Generación de energía en México .....................................................56 3.5 Monitoreo del desempeño de turbinas ................................................57 3.5.1 Condiciones de operación .................................................................57

3.5.2 Adquisición de datos en equipos rotativos ........................................59 3.6 Enfoques del diagnóstico de turbinas ...................................................62 3.6.1 Análisis termodinámico .....................................................................62 3.6.2 Análisis de vibraciones ......................................................................65 3.6.3 Análisis estructural ............................................................................66 3.6.4 Inspección con boroscopía ................................................................67 3.6.5 Estudio por imágenes ........................................................................69 3.6.6 Estudio de lubricantes .......................................................................70 3.7 Métodos académicos de diagnóstico de turbinas .................................71 3.8 Método de diagnóstico de turbinas de vapor en línea del IIE ................74 3.9 Conclusiones del capítulo .....................................................................76

CCaappííttuulloo 44 EEssttaaddoo ddeell aarrttee ddeell ddiiaaggnnóóssttiiccoo ddee ttuurrbbiinnaass ddee vvaappoorr..........................................................7777 4.1 Naturaleza multidisciplinaría del diagnóstico........................................78 4.2 Representación de sistemas de diagnóstico de turbinas .......................79 4.3 Monitoreo de turbinas de vapor...........................................................80 4.4 Problemas de instrumentación .............................................................81 4.5 Corrección de referencias del fabricante ..............................................81 4.6 Diagnosis automática de turbinas de vapor ..........................................82 4.7 Combinación de enfoques ....................................................................83 4.8 Conclusiones del capítulo .....................................................................84

CCaappííttuulloo 55 DDiisseeññoo ddeell ssiisstteemmaa....................................................................................................................................................................8855 5.1 Elementos de una infraestructura de diagnóstico .................................86 5.2 Análisis de la problemática técnica .......................................................87 5.3 Diseño de la infraestructura de diagnóstico remoto .............................89 5.4 Meta‐modelos ......................................................................................92 5.5 Diseño de los elementos de definición del sistema ...............................93 5.6 Diseño de los elementos para el comportamiento esperado ................93 5.7 Diseño de los elementos para la preparación del diagnóstico ...............94 5.8 Diseño de los elementos para efectuar el diagnóstico ..........................95 5.9 Diseño de los elementos para evaluar el diagnóstico............................96 5.10 Proceso de diagnosis ............................................................................97 5.11 Conclusiones del capítulo .....................................................................98

CCaappííttuulloo 66 PPrruueebbaass aall ssiisstteemmaa ....................................................................................................................................................................9999 6.1 Incorporación de datos ...................................................................... 100 6.2 Pruebas al sistema.............................................................................. 101

CCaappííttuulloo 77 CCoonncclluussiioonneess yy ttrraabbaajjoo ffuuttuurroo ............................................................................................................................ 110066 7.1 Naturaleza de los resultados .............................................................. 107 7.2 Comparación de métodos .................................................................. 107 7.3 Diagnosticabilidad .............................................................................. 107 7.4 Trabajos futuros ................................................................................. 108

Lista de figuras Figura 1‐1 Esquema conceptual de un sistema de diagnóstico automático remoto. ........... 5 Figura 2‐1 Neurona artificial de dos entradas ................................................................... 18 Figura 2‐2 Red neuronal artificial simple ........................................................................... 19 Figura 2‐3 Patrones de combinación de señales en distintas compuertas lógicas ............. 20 Figura 2‐4 Clasificación por hiperplanos, empleada en SVM ............................................. 21 Figura 2‐5 Clasificación con múltiples clases ..................................................................... 22 Figura 2‐6 Diagnosis por imágenes ................................................................................... 23 Figura 2‐7 Funcionamiento general del diagnóstico basado en modelos .......................... 24 Figura 2‐8 Sistema de compuertas lógicas ........................................................................ 24 Figura 2‐9 Síntoma en un sistema de compuertas ............................................................ 26 Figura 2‐10 Visión general del ciclo del razonamiento basado en casos ............................ 27 Figura 2‐11 Metodología de implementación de CBR ....................................................... 28 Figura 2‐12 Algoritmo genético ........................................................................................ 31 Figura 2‐13 Un podómetro como ejemplo de diagnóstico en línea ................................... 34 Figura 2‐14 Prueba de máxima absorción de oxígeno ....................................................... 35 Figura 2‐15 Abstracción de un sistema de control ............................................................ 36 Figura 2‐16 Ejemplo de sistema para modelar con LYDIA.................................................. 37 Figura 2‐17 Evaluación de la confiabilidad con base en experimentos .............................. 40 Figura 3‐1 Ejemplo de turbina de vapor ............................................................................ 44 Figura 3‐2 Comparación entre turbinas de impulso y reacción.......................................... 45 Figura 3‐3 Ciclo Rankine característico de las turbinas de vapor. ...................................... 47 Figura 3‐4 Gráfica T‐S del ciclo Rankine convencional ....................................................... 48 Figura 3‐5 Ciclo Brayton abierto. ...................................................................................... 49 Figura 3‐6 Ciclo Brayton cerrado....................................................................................... 49 Figura 3‐7 Gráfica T‐S del ciclo Brayton ideal. ................................................................... 50 Figura 3‐8 Barco de vapor británico .................................................................................. 52 Figura 3‐9 Ciclo combinado de gas y vapor. ...................................................................... 53 Figura 3‐10 Ciclo combinado con energía solar integrada. ................................................ 54 Figura 3‐11 Cogeneración de energías eléctrica y térmica. ............................................... 55 Figura 3‐12 Capacidad efectiva instalada de generación de CFE ....................................... 56 Figura 3‐13 Carga en ciclo de paro y arranque típico de una turbina................................. 58 Figura 3‐14 Temperaturas en ciclo de paro y arranque típico de una turbina. .................. 59 Figura 3‐15 Ejemplo de adquisición de velocidades durante un arranque. ........................ 60 Figura 3‐16 Esquema del sistema PI .................................................................................. 61 Figura 3‐17 Esquema del sistema SICAD ........................................................................... 62 Figura 3‐18 Ejemplo de turbina con dos extracciones. ...................................................... 63 Figura 3‐19 Ejemplo de diagrama de Mollier. ................................................................... 64 Figura 3‐20 Pantalla de una aplicación de CAD y elemento finito. ..................................... 66 Figura 3‐21 Boroscopía de una turbina industrial.............................................................. 67 Figura 3‐22 Boroscopía manual de tuberías. ..................................................................... 67 Figura 3‐23 Robot para boroscopía en tuberías. ............................................................... 68

Figura 3‐24 Termografía para el diagnóstico de chumaceras. ........................................... 69 Figura 3‐25 Análisis de fractura en turbinas de gas. .......................................................... 70 Figura 3‐26 Pantalla de eSTPE. .......................................................................................... 73 Figura 3‐27 Metodología propia del IIE ............................................................................. 75 Figura 4‐1 Desempeño de las técnicas de diagnóstico ...................................................... 83 Figura 4‐2 Detección de fallas en generadores. ................................................................ 84 Figura 5‐1 Modelo en cascada con correcciones ............................................................... 86 Figura 5‐2 Estado 'A' contra Estado 'B' .............................................................................. 87 Figura 5‐3 Selección de opciones. ..................................................................................... 89 Figura 5‐4 Diagrama conceptual de la arquitectura de la solución. ................................... 90 Figura 5‐5 Diagrama modular de la solución ..................................................................... 91 Figura 5‐6 Alcance del sistema de diagnóstico .................................................................. 91 Figura 5‐7 Base de datos meta‐modelada ......................................................................... 92 Figura 5‐8 Proceso de diagnóstico .................................................................................... 97 Figura 6‐1 Pantalla de acceso a la herramienta de descripción de sistemas .................... 101 Figura 6‐2 Pantalla principal ........................................................................................... 102 Figura 6‐3 Acceso a la página de solicitud de diagnóstico. .............................................. 103 Figura 6‐4 Resultado del diagnóstico .............................................................................. 104

Lista de tablas Tabla 2‐1 Profundidad de diagnóstico .............................................................................. 13 Tabla 2‐2 Comportamiento esperado para un sistema de compuertas ............................. 25 Tabla 2‐3 Un síntoma de falla en un sistema de compuertas ............................................ 25 Tabla 2‐4 Código en LYDIA del ejemplo de compuertas lógicas ......................................... 38 Tabla 3‐1 Unidades de turbina de vapor en el mundo, con eficiencia. .............................. 51 Tabla 3‐2 Capacidad efectiva instalada y generación de unidades termoeléctricas. .......... 56 Tabla 3‐3 Efecto de los cambios en condiciones, conforme a Cotton. ............................... 72 Tabla 5‐1 Conjunto de instrucciones de LDX ..................................................................... 94 Tabla 6‐1 Conjuntos de datos de prueba ........................................................................ 100 Tabla 6‐2 Pruebas de stress a la herramienta de descripción .......................................... 101 Tabla 6‐3 Resultados sobre sencillez ............................................................................... 103

Diagnóstico Automático de Turbinas de Vapor en Línea Capítulo 1 Introducción

1 Capítulo 1

Capítulo 1 Introducción

Una parte integral del mantenimiento tanto preventivo como predictivo, involucra las tareas de análisis o diagnóstico para disminuir los riesgos y contar con la información para planificar el suministro de refacciones y las suspensiones en los servicios necesarias. Bajo la expectativa de reducir los costos (producidos por interrupciones en la producción, los accidentes, el retraso en la entrega de refacciones y los decrementos en la eficiencia), el diagnóstico debiese ser una de las actividades más empleadas en las plantas industriales. Entonces el estudio del diagnóstico resulta atractivo por el fuerte impacto económico que representa en diversas aplicaciones como las plantas generadoras de energía.

Por otra parte, la implementación de métodos de diagnóstico es interesante en términos técnicos de diversos campos, derivando trabajos como el actual, donde se enfrentan los retos del diagnóstico de turbinas de vapor, en una visión combinada de ingeniería mecánica y ciencias computacionales.

El presente capítulo introduce los aspectos que dan pie a esta investigación, desde sus antecedentes, descripciones tanto de la problemática abordada, como la solución planteada, detallando objetivos, alcances y limitaciones. Igualmente se exponen de una manera general, tanto los aportes técnicos como científicos del trabajo, concluyendo con una breve estructuración del documento.

1.1 Antecedentes La raza humana destaca por su búsqueda de conocimiento que mejore sus

condiciones de vida, sus oportunidades de éxito. Así, la exploración de mecanismos que conduzcan a mejorar la salud ha ocupado enormes esfuerzos en el transcurso de la historia. La evidencia al respecto nos remonta a tiempos tan remotos como el año 500 AC., donde los más antiguos médicos chinos conocidos como Bian Que (también llamado Tai Yueren), ganaron una enorme reputación por su habilidad de reconocer las enfermedades, en especial por sus habilidades al tomar el pulso, así como sus terapias por acupuntura. Continuando la historia, en los tiempos de los antiguos griegos, Hipócrates, “el padre de la medicina”, estableció la relación entre la herencia de un paciente y sus padecimientos y Pitágoras notó la asociación entre el metabolismo y algunas alergias heredadas. En el medievo, destacan las técnicas árabes cuyos médicos icónicos son Rhazes y Avicena, ambos con inclinaciones opuestas en cuanto al tratamiento de enfermedades. Mientras Rhazes resalta la importancia del caso individual, incorporando el historial clínico, Avicena buscaba soluciones generales a las epidemias, como lo manifiestan las cincuenta partes de su “Canon de medicina”. Durante los inicios del siglo XX, William Osler redefinió la práctica médica al fundamentar los actuales principios del diagnóstico y tratamiento de enfermedades, basándose en la identificación de los males a partir de sus manifestaciones. Estos conceptos dan pie a la medicina de nuestros días, donde es posible detectar enfermedades a partir de la información recabada mediante una multitud de análisis clínicos que incluyen: ultrasonidos, rayos X, genéticos, sanguíneos, cardiacos, etc.

Pero dado que la necesidad de conocimiento no se limita a la supervivencia elemental, y las aplicaciones en medicina no excluyen otros estudios que empleen el concepto de diagnóstico, es posible ofrecer un enfoque más general, bajo el cual se define al diagnóstico como una actividad que permite identificar el estado de un sistema estudiado, determinando los síntomas de falla o deterioro y con ello, reconocer las fallas presentes o futuras en dicho sistema. Dicho concepto se complementa al definir el término sistema como “un conjunto de elementos con un fin común”. Bajo este contexto de definiciones, un sistema equivale al paciente en ámbitos médicos y de manera similar, se pueden aplicar muchas analogías con otros términos como síntoma, tratamiento o enfermedad.

Cada método, técnica o herramienta de diagnóstico suele concebirse con un propósito dedicado y, pasado cierto tiempo, bien sea para ampliar sus capacidades, implementar otra instancia similar, o simplemente para copiar la solución dentro de un contexto distinto, ha generado un proceso que ha llevado de la especialización a la generalización del diagnóstico. En los campos computacionales existe la evidencia de tal proceso, dentro de la evolución de los sistemas expertos, implementaciones que pretenden copiar la habilidad de un experto humano en la realización de una tarea, las cuales iniciaron con amplia afinidad hacia aplicaciones médicas y poco a poco han ido extendiéndose a otras áreas, partiendo de las soluciones ya creadas.

Cada caso de estudio permite enfocar y mejorar los diversos elementos de un sistema de diagnóstico: modelos, métodos, técnicas, herramientas, etc., por esto suelen tener

resultados más plausibles y se pueden comparar contra muestras del producto de las formas tradicionales de diagnóstico para el sistema estudiado. La presente investigación se contextualiza empleando como caso práctico el diagnóstico de turbinas de vapor.

En los sistemas mecánicos, mediante el análisis o diagnóstico, se busca mantener cercanos a los niveles de diseño los valores de eficiencia, potencia y consumo térmico unitario como prioridad para la operación de las plantas. En el caso específico de elementos como turbinas de vapor, existen diversas bases para la operación, el mantenimiento y el análisis del estado de la máquina. Los textos para ingenieros de operación y mantenimiento de plantas, suelen indicar que el diagnóstico de turbinas de vapor consiste básicamente en la evaluación térmica de la turbina en operación, para cuantificar las pérdidas de eficiencia y potencia internas producidas por el desgaste de los componentes del canal de flujo y estimar en cuáles de estos componentes existen daños; estas evaluaciones constituyen la parte fundamental de un programa de mantenimiento [COTTON 1998, KUBIAK 1996, RAMIREZ 2004].

En el caso de turbinas de vapor, los resultados del diagnóstico basan sus cálculos de parámetros de desempeño en estándares, entre los que se incluyen: DIN 1943 (Pruebas de aceptación de turbinas de vapor), ANSI PTC 6S (Procedimientos para pruebas de desempeño rutinario de turbinas de vapor), y ANSI/ASME PTC6 (Turbinas de vapor). Estos estándares son empleados por las comunidades de ingeniería relacionadas, y funcionan partiendo de datos que normalmente acompañan al equipo y sirven de referencia. Sin embargo, en la práctica, las turbinas de vapor no son tan consistentes y varían significativamente en cuanto a la respuesta dinámica; estas variaciones en el comportamiento de las turbinas pueden tener varios orígenes, desde fallas en los modelos, alteraciones físicas del equipo mecánico o cambios en el ambiente del sistema. Por otro lado, el análisis necesario para diagnosticar las turbinas depende desafortunadamente de las señales que son obtenidas de la máquina estudiada, tales como: vibración, posición y temperatura, las cuales, además de que pueden verse alteradas por fallas en los instrumentos, no describen la condición, sino que requieren diversos grados de interpretación [MITCHELL 1981].

Por lo complejo del planteamiento, lo valioso de la información e incluso como práctica de mercado, los detalles necesarios para realizar el diagnóstico de turbinas quedan, en la mayoría de los casos, como propiedad de los mismos fabricantes, quienes desarrollan y comercializan sus herramientas de análisis. Las compañías externas que ofrecen servicios similares han tenido que invertir esfuerzos similares al de este proyecto para desarrollar las infraestructuras correspondientes. De esta manera, las publicaciones técnicas sobre los métodos de diagnóstico en turbinas suelen aparecer, bien sea cuando los grupos de desarrollo de las compañías fabricantes ofrecen información luego de que el mercado ha aceptado los servicios de análisis o cuando los investigadores externos a las compañías han implementado soluciones que superan los servicios del fabricante. [SCHEIDEL 2004]

Dado que la información temprana que suelen publicar los fabricantes es más bien de mercadotecnia, enfocada a resaltar las características positivas, tiene un valor muy escaso para otros fines fuera de la evaluación de mercado y por ende complica las implementaciones de sistemas de diagnóstico. Pese a ello, la documentación que acompaña al equipo suele contemplar las curvas de funcionamiento ideal, así como el modelo de referencia. Ambos datos son necesarios para una evaluación efectiva de los componentes [COTTON 1998], pero pierden certeza con el tiempo y se requiere de ajustes, que por su complejidad, han derivado en diversas investigaciones en áreas de ingeniería mecánica [PRECIADO 2000] y afines.

Para el diagnóstico de elementos mecánicos, existen dos enfoques principales, diferenciados por la forma en la que se realizan con respecto a la operación del equipo, por una parte, el diagnóstico fuera de línea permite la inspección del equipo cuando no se encuentra operando, mientras que el diagnóstico en línea debe entenderse como un proceso de monitoreo que va analizando la información del sistema mientras está en operación. El diagnóstico en línea, con base en las condiciones de operación, determina la presencia de fallas que afectan la producción.

Bajo este enfoque los trabajos de ingeniería derivados tanto de las evaluaciones como los ajustes para recalcular los modelos de referencia, han sido explorados por varias instituciones. En México, se puede mencionar que existen proyectos en universidades e institutos como: la Universidad Nacional Autónoma de México (UNAM), la Universidad de Guanajuato, el Instituto Tecnológico y de Estudios Superiores de Monterrey (ITESM) y el Instituto de Investigaciones Eléctricas (IIE). En el área de Turbomaquinaria del IIE, se han desarrollado múltiples proyectos relacionados con mantenimiento predictivo y diagnóstico de equipos rotativos.

Varias compañías fabricantes de turbinas y firmas especializadas ofrecen algún tipo de servicio de evaluación remota, que permite la identificación de problemas, disminuyendo la necesidad de diagnósticos fuera de línea. Sin embargo la mayoría de ejemplos tienen un limitado conjunto de funciones y sufren de un efecto de “caja negra”, es decir, por el hermetismo del sistema, tiende a dejar al operador con una vaga información de detalle del diagnóstico e incapacitado para profundizar el análisis.

Como casi todo en nuestros días, el análisis remoto que se ofrece, tiende a aprovechar las tecnologías Web, como medio para transportar la información extraída del equipo. Esta práctica es cada vez más común y necesaria, lo que ha propiciado el crecimiento de las tecnologías relacionadas a la instrumentación adecuada para estos fines.

Los modelos de conectividad, detección de problemas, protocolos de identificación, transporte y almacenamiento de señales, así como algunos esquemas de control de flujo de datos infieren en la implementación de los servicios industriales de diagnóstico. Se puede ir desde lo muy general y estandarizado, hasta casos muy particulares que requieran trabajar en la especificación.

1.2 Motivación Como parte de las medidas de mejora para la Gerencia de Turbomaquinaria del IIE, se

identificaron y evaluaron distintas oportunidades, priorizando sobre los potenciales beneficios esperados y la factibilidad técnica de cada opción. Así se determinó como prioritaria la creación de un conjunto de servicios que permitiese el análisis remoto de elementos rotativos, tomando como caso de estudio las turbinas de vapor.

Como parte de la experiencia del IIE al respecto se encuentran más de 2,000 reportes de diagnóstico de turbo‐componentes que ha emitido la Gerencia de Turbomaquinaria. Cabe resaltar que si bien existen diversos grupos que analizan turbinas de vapor, en México, sólo el IIE ofrece análisis de estado sobre las etapas de menor presión, lo cual es posible por las metodologías desarrolladas. En complemento, es elevado el grado de certeza que han ofrecido los reportes del IIE, ya que históricamente no ha habido grandes desviaciones entre los resultados del reporte y las inspecciones realizadas al abrir la máquina diagnosticada.

Fundamentalmente se pretende obtener una infraestructura para implementar proyectos de análisis remoto, ofreciendo con ello la posibilidad de experimentar con diversas técnicas de diagnóstico en la parte mecánica de la gerencia. Sin embargo no debe hacerse de lado aquellas técnicas de análisis en campo, locales, es decir no necesariamente remotos.

Al enfocar los esfuerzos en esta rama, el fundamento sobre diagnóstico es crítico y se requiere la exploración de opciones para seleccionar una solución adecuada, toda vez que se busca sustentar futuros proyectos, donde se desarrollen análisis de sistemas que conceptualmente sean similares al que se ilustra en la figura 1‐1.

Figura 1‐1 Esquema conceptual de un sistema de diagnóstico automático remoto.

Con un enfoque general con respecto a las aplicaciones futuras, se busca consolidar una infraestructura cuyas características permitan abordar una multitud de casos de diversos sistemas y subsistemas, con el doble propósito de implementar nuevos productos de análisis y afinar las técnicas de diagnóstico, funcionando como una opción rentable, con tecnología propia para el sector eléctrico nacional.

Complementariamente, dado que este desarrollo representa un desafío informático por las características de variabilidad tanto en el objeto de estudio como en los métodos de análisis, se decidió abordarlo en esta tesis.

1.3 Problemática La infraestructura de un centro de investigación posibilita aprovechar más y mejores

oportunidades. En lo referente al análisis de turbinas de vapor, el Instituto de Investigaciones Eléctricas posee un capital intelectual capaz de afrontar los retos del análisis de equipos, incluyendo evaluar las condiciones, recalcular los modelos de referencia y estimar los errores por fallas en los sensores.

Sin embargo, al carecer de una infraestructura que soporte el diagnóstico remoto, se arriesga la competitividad, tanto en el área de Turbomaquinaria, como en otras relacionadas, dadas las herramientas de diagnóstico remoto que ofrecen algunas firmas especializadas, normalmente asociadas a los fabricantes.

Por tanto, se toma como una oportunidad para explorar, analizar e implementar un conjunto de herramientas y servicios que permitan conformar un modelo de análisis y con ello integrar una plataforma incremental con el potencial para incorporar mejoras paulatinas al proceso de diagnóstico.

El alcance inmediato estará limitado al diagnóstico en línea de turbinas de vapor, aprovechando las técnicas existentes, en particular las desarrolladas por los especialistas del área de Turbomaquinaria del IIE.

Una característica indeseable de muchas aplicaciones de ingeniería, es que suelen ser complicadas de actualizar o ampliar. Una solución de diagnóstico, por ejemplo se limita a un conjunto de fallas, y ampliarlo o cambiarlo puede resultar en una tarea más difícil que abordar nuevamente el problema desde la nada. Por ello, se intenta implementar un modelo dinámico de diagnóstico, donde se dispondrán de versiones para cada representación del conocimiento (Know‐How), de manera que pueda implementarse una mejora en el proceso.

Debido a la necesidad de procesar señales de diversas fuentes, y multiplicar las opciones de fuentes de información, debe disponer de un mecanismo de integración de datos flexible, que pueda procesar señales de instrumentación, como las versiones del sistema SICAD del IIE, o instrumentos de monitoreo y diagnóstico portátiles más comerciales como pudiesen ser: ADRE de Bently Nevada o VIBSCANNER de Prüftechnik AG, entre otros. La naturaleza de estas múltiples fuentes y el hecho de no cerrar los modelos o configuraciones de la maquinaria a diagnosticar, hacen necesario considerar: a) la definición o modelado del sistema en estudio, b) la representación del proceso de preparación de los datos que el algoritmo de diagnóstico pueda requerir y c) el método de diagnóstico en sí. Cada una de estas consideraciones involucra un reto.

El modelado de los sistemas no es trivial y por la delimitación de tiempo, debe de considerarse la consolidación rápida de un modelo, con una relevancia menor en cuanto al nivel de eficiencia del mismo; por ende pueden existir mejoras futuras.

El proceso de preparación de los datos involucrará un lenguaje o alguna metodología de modelado para las actividades de manipulación de esas señales, así como una normalización de las interfases.

Como una suposición inicial, se considera que se cuenta con un enlace Web entre el servidor de diagnóstico y la instrumentación. Igualmente se supone que la instrumentación soporta los protocolos adecuados para el transporte Web de sus señales.

Hay delimitaciones del sistema que pueden definir la flexibilidad y capacidades de la solución, por lo que sólo se implementará un modelo base de diagnóstico y se comprobará su adaptabilidad con una mejora propuesta por el IIE. Las herramientas computacionales serán limitadas con base en las necesidades para implementar el modelo base, es decir el método de diagnóstico del IIE.

Las fuentes de datos a emplear para las pruebas se determinaron en una etapa temprana por especialistas del IIE, con base en la disponibilidad de los datos, lo representativo de los casos reales y la fiabilidad de los instrumentos de adquisición empleados. Como se mencionó, en el caso de adquisiciones remotas de datos, la fuente debe soportar Web tanto en Hardware como en Software. Así mismo, el nivel de error no debe ser mayor que el del proceso manual, sin embargo se considera como error aceptable hasta 25%, tomando en cuenta que el producto se trata de un prototipo dentro de un modelo incremental.

Por último, para consolidar este sistema, se debe implementar la infraestructura Web correspondiente para el acceso remoto, cumpliendo con algunos estándares y especificaciones abiertos para comunicación y control como TCP/IP, Modbus, DDE, OPC, entre otros.

1.4 Objetivos La presente investigación dentro del área de diagnóstico, está enfocada a cubrir el

desarrollo de una infraestructura para el diagnóstico remoto en línea de turbinas de vapor. Los atributos principales buscan representar de una manera flexible al sistema y los elementos del proceso de diagnóstico, desde el sistema en sí, sus fuentes de datos, los métodos de análisis y las reglas para el diagnóstico. Este proceso debe ser lo suficientemente amplio y flexible para expresar el conocimiento (Know‐How) de los expertos del IIE en diagnóstico de turbinas, inestimable y en continua evolución, por lo cual debe ser adaptable.

Para evaluar tales atributos de flexibilidad y adaptabilidad, se comparará la implementación en el sistema de diagnóstico de una metodología desarrollada en el IIE para el diagnóstico en línea de turbinas de vapor contra un modelo académico similar

basado en el libro de “Evaluación y mejora del rendimiento de turbinas de vapor” (En inglés Evaluating and improving steam turbine performance) por K.C. Cotton.

Como objetivos particulares, esta investigación busca:

a) Con base en la experiencia acumulada en el IIE, definir el proceso de diagnosis remota para turbinas de vapor en línea.

b) Formular la infraestructura necesaria para la diagnosis remota para turbinas de vapor.

c) Definir las piezas de software necesarias para implementar la diagnosis remota para turbinas de vapor.

d) Evaluar la validez de la automatización del proceso de diagnosis y las cualidades del software en cuanto a poder representar distintos sistemas, fuentes de datos, métodos y reglas de diagnóstico.

e) Documentar la implementación y pruebas del sistema.

1.5 Alcances y limitaciones El proyecto busca desarrollar una infraestructura Web, capaz de apoyar el análisis de

diversos equipos en planta, mas dadas las condiciones de tiempo restringido, se ha tomado como base el método de diagnóstico de turbinas de vapor en línea, desarrollado en la Gerencia de Turbomaquinaria.

Por otra parte, no se incluyeron como parte del alcance las pruebas en campo, por la incertidumbre en cuanto a la disponibilidad en las centrales tanto para experimentar empleando sus instrumentos ni sobre las condiciones para implementar la diagnosis correspondiente.

1.6 Hipótesis Mediante los trabajos de esta tesis se busca establecer la validez de la hipótesis: “Por

una combinación de datos meta‐modelados del sistema y un lenguaje de diagnosis, puede generarse una infraestructura de diagnóstico adaptable a diversos sistemas de turbinas de vapor”.

Este argumento se expresa asumiendo que los datos obtenidos de las turbinas en línea deben de colectarse y generar un modelo del comportamiento real del sistema, a partir de instrucciones codificadas en un lenguaje adecuado para un procesamiento de señales, anterior a la aplicación de un diagnóstico. Además, resulta necesario implementar un modelo que permita hacer la representación meta‐modelada del comportamiento esperado para la turbina de vapor.

Para aceptar o refutar la hipótesis planteada, se harán pruebas con conjunto de datos representativos de la presencia o ausencia de fallas características, demostrando la validez o inconsistencia de los resultados de la diagnosis basada en la comparación de los comportamientos esperado y real.

1.7 Contribuciones Este proyecto se ha concentrado en desarrollar una infraestructura capaz de describir

el conocimiento sobre diagnóstico de turbinas y mediante la documentación y análisis del proceso, se establece como un punto de partida para la mejora de tales métodos de diagnóstico.

La contribución mayor de este trabajo consiste en incorporar un lenguaje de diagnóstico para el procesamiento de las señales provenientes de sistemas mecánicos en línea, para el cálculo del comportamiento real de tales sistemas.

1.8 Organización de la tesis El documento se divide en siete capítulos, iniciando por el presente, el cual sirve como

preámbulo general al proyecto. En el Capítulo 1, Introducción, se definen los aspectos generales como los orígenes, los objetivos y la problemática.

El Capítulo 2, Fundamentos de diagnóstico, expone la visión sobre el diagnóstico, partiendo desde un enfoque general, exponiendo los enfoques y terminología del área desde una visión de ciencias computacionales.

Dentro del Capítulo 3, Diagnosis de sistemas mecánicos, se establece el contexto de ingeniería mecánica, manifestando los términos acordes al ambiente de sistemas mecánicos. En esta sección se ilustran los principios de la evaluación de turbinas de vapor.

En el Capítulo 4, Estado del arte de turbinas de vapor, complementando las definiciones anteriores, aborda la base teórica sobre la que se basa el estudio del diagnóstico de turbinas de vapor actual. Además, al revisar los resultados de investigaciones recientes en el tema, se manifiestan los parámetros fundamentales para la construcción de la infraestructura a desarrollar.

Dentro del Capítulo 5, Diseño del sistema, se exponen los detalles necesarios para la construcción del software. Se inicia con la normativa de diseño y se desarrollan los diversos aspectos de la aplicación, desde la arquitectura hasta los modelos de datos y las interfaces hombre‐máquina (HMI).

En el Capítulo 6, Pruebas al sistema, se describen las piezas del software y las pruebas básicas a la infraestructura desarrollada. Estas pruebas no van dirigidas a estudiar las herramientas de diagnóstico, sino a garantizar que la infraestructura trabaja según el diseño. Además se registran las pruebas dirigidas a estudiar la adaptabilidad de la infraestructura, la utilidad del modelo y el nivel de complejidad que representa.

El Capítulo 7, Resultados y trabajos futuros, cierra este documento presentando y concluyendo sobre los resultados de esta investigación y manifestando algunos posibles trabajos futuros.

Diagnóstico Automático de Turbinas de Vapor en Línea Capítulo 2 Fundamentos de diagnóstico

2 Capítulo 2

Capítulo 2 Fundamentos de diagnóstico

La naturaleza del diagnóstico, pese a ser tan básico como el instinto natural de supervivencia, resulta complejo en el sentido de estar compuesto de varios elementos además de los numerosos puntos de vista desde los que ha sido analizado. Con la finalidad de lograr una adecuada implementación, resulta necesario analizar en lo posible los componentes y enfoques del problema de diagnóstico, definiendo sus conceptos, para unificar criterios.

Este capítulo busca exponer los conceptos relativos al problema de diagnóstico y algunas áreas asociadas, partiendo desde los principios del análisis médico, y desarrollando una visión general que integre los conceptos en otros campos. Luego, bajo una visión de ciencias computacionales, se incluye una discusión acerca de los enfoques más comunes al abordar soluciones para el problema de diagnóstico, haciendo mención de varias de las herramientas computacionales más empleadas en la implementación de sistemas.

Complementariamente, se hace una breve revisión de los temas que definen la evaluación de sistemas de diagnóstico. Finalmente se concluye con un breve resumen del capítulo.

2.1 El problema de diagnóstico La necesidad de conocer las causas de los fenómenos, es el instrumento que, en la

historia de la humanidad, más ha orillado a generar ciencia. Algo en nuestra naturaleza, quizá el instinto de conservación, nos hace buscar las causas de los males, para evitarlos o corregirlos. De esta manera, como seres humanos resulta natural la curiosidad por analizar las enfermedades, los fallos, los accidentes e interpretarlos con argumento en las observaciones realizadas, formulando relaciones entre los elementos que originaron la situación y los efectos observables, generando así recetas o reglas para atender un padecimiento, eliminar un riesgo o corregir una falla.

Por otra parte, el diagnóstico médico establece a partir de síntomas, signos y los hallazgos de exploraciones complementarias, qué enfermedad padece una persona. Generalmente una enfermedad no está relacionada de una forma biunívoca con un síntoma, es decir, un síntoma no es exclusivo de una enfermedad.

Todo esto da lugar a la búsqueda de la representación del conocimiento para formar un proceso que posibilite buenos resultados, los métodos que lleven a la automatización de este proceso, a la evaluación y mejora de las soluciones, a formulaciones generales que apliquen a muchos casos de análisis, y a explorar técnicas que permitan ocupar menos información, o calcular datos que no siempre es posible tener para estas evaluaciones.

Los conceptos principales involucrados en el problema de diagnóstico clínico son:

• Diagnosis es la determinación de la naturaleza de una enfermedad.

• Paciente (o sistema estudiado) que es la parte central de cualquier representación o modelo para el diagnóstico, es el individuo analizado.

• Síntoma que representa la desviación del comportamiento típico. En el diagnóstico clínico la temperatura elevada es un síntoma clásico.

• Padecimiento, es decir la consecuencia de los síntomas, engloba las características y dependiendo del padecimiento, puede ser posible ubicar las posibles soluciones o las repercusiones futuras en el paciente.

• Tratamiento, es el conjunto de acciones que conducirán a corregir o disminuir los efectos del padecimiento o falla.

• Prognosis, el conocimiento anticipado de algún suceso, es la descripción del estado o los sucesos futuros que presentará el paciente. Típicamente se anticipa el desarrollo del padecimiento y los efectos del tratamiento médico.

Al generalizar los conceptos del diagnóstico, simplemente debe contemplarse que un paciente humano posee elementos regenerativos que en muchos casos pueden disminuir o contrarrestar los efectos de algunos padecimientos.

Sin embargo, de una manera global, los conceptos aplican con mínimas adecuaciones, por ejemplo, en el caso de sistemas financieros, la prognosis aborda los efectos monetarios sobre inversiones o decisiones tomadas.

En ambientes donde el paciente es una máquina, los padecimientos se traducen como fallas y el tratamiento se efectúa como ajustes o reparaciones a realizar. El término “síntoma” en sistemas mecánicos, comprende las manifestaciones fuera de lo esperado en la instrumentación, es decir combinaciones de vibraciones, presiones, temperaturas, flujo, etc.

Estas “manifestaciones anormales” o síntomas, no resultan obvias para quien sea ajeno al trabajo de mantenimiento de la máquina, lo cual implica que se requiere de expertos en el análisis del sistema, capaces de aportar el conocimiento para poder determinar la existencia de tales situaciones.

El tratamiento en turbinas se lleva a cabo durante el mantenimiento y un buen análisis permite anticipar los daños que presenta o presentará la máquina cuando este mantenimiento llegue. Esto es muy valioso pues se pueden solicitar las piezas con anticipación, limitar o incluso frenar la producción del equipo para evitar riesgos o disminuir los daños ocasionados por la falla.

2.2 Profundidad del diagnóstico Las soluciones al problema de diagnóstico ofrecen diferentes niveles de detalle sobre

las fallas, los elementos involucrados, la gravedad, el tratamiento propuesto o los cuidados para prevenir desencadenar otras fallas a partir del estado actual del sistema. [FENSEL 1996]

A manera de analogía, cuando un médico atiende a un paciente, su diagnóstico dependerá en gran parte de la información que se aporte bien sea por los síntomas que manifieste el propio paciente, la valoración física que el médico realice y los análisis de laboratorio adecuados.

Los escenarios alrededor de una enfermedad de vías respiratorias pueden servir para ilustrar la situación.

Si el médico debe dar una consulta telefónica, su análisis únicamente contará con la descripción del malestar según lo explique el propio paciente. Por la limitada información, será difícil ubicar un padecimiento específico, resultando en el diagnóstico, por ejemplo, de un resfriado o gripe común. Dado que esto no es sino la descripción genérica para un conjunto de padecimientos, puede originar que el tratamiento resulte poco efectivo, pues se emplearían medicamentos igualmente genéricos.

Por otra parte, si el paciente asiste a consulta, el médico podrá hacer una valoración física, mediante la cual se pueden identificar más síntomas. De esta forma, basándose en ciertos sonidos del pecho, pigmentación de ojos, presencia de inflamación en nariz y garganta. Con ello es posible ubicar de mejor manera el padecimiento, como pudiese ser,

ejemplificando rinofaringitis, que si bien aún involucra un conjunto de enfermedades, implica un conjunto más específico de medicamentos y cuidados en el tratamiento.

Una diagnosis complementada por los datos de ciertos análisis de laboratorio, permiten que el médico defina el caso como una enfermedad muy específica, como pudiese ser influenza, enfermedad de tratamiento plenamente identificado, y cuyos medicamentos son altamente dedicados y con tiempos de recuperación poco inciertos.

Tabla 2‐1 Profundidad de diagnóstico

A manera de resumen se ilustra la tabla 2‐1, con los niveles de profundidad del ejemplo, yendo desde lo genérico o poco profundo, hasta lo específico o de mucha profundidad.

La diferencia entre emplear tratamientos generales y específicos, puede evitar riesgos de emplear un medicamento poco efectivo que alargue la recuperación, o en el caso de emplear concentraciones demasiado agresivas, puede causar daños colaterales en el paciente como problemas hepáticos, cardiacos o incluso coágulos cerebrales.

Con este ejemplo se desprende que algunas soluciones, por lo general o ambiguo de sus resultados, pueden resultar ineficientes, principalmente si los alcances involucran ciertos tipos de decisiones que se tomarían con los datos del diagnóstico. Con ello se deriva uno de los retos del problema de diagnóstico: lo difícil que puede resultar especificar la profundidad requerida en una solución para hacer diagnóstico.

Con la analogía expuesta, la especificación sobre el nivel de detalle que debe proporcionar un diagnóstico, puede definirse en función del conjunto de padecimientos o enfermedades, con sus correspondientes tratamientos y las explicaciones relacionadas. Como desventaja, dado que el diagnóstico a nivel genérico pudiese contemplar un mayor

número de padecimientos, el volver específico a un sistema de diagnóstico puede limitarlo en cuanto a los casos que aplica.

La mayoría de las soluciones dan profundidades mixtas, esto es, ofrecen un nivel general para ciertas fallas y otro específico para otras. En términos comerciales o de bench‐marking, las soluciones omiten mencionar la profundidad, principalmente en aquellas fallas que pueden analizarse a distintos niveles de profundidad.

2.3 Enfoques del diagnóstico Dentro de las soluciones computacionales al problema de diagnóstico es posible

ubicar diferentes enfoques u orientaciones. Es importante destacar que no existe ningún método de diagnóstico sin asunciones, es decir todos parten de algún principio para abordar el problema, simplificándolo mediante la limitación de caso, la eliminación de restricciones o simplemente llegando a soluciones parciales.

Algunos de estos sistemas llegan a suponer falsamente la utilidad de los resultados pese a no aportar ningún elemento de apoyo a la prognosis o toma de decisiones, bien sea por la profundidad del diagnóstico, la ambigüedad de las fallas o lo incierto del análisis.

Por otra parte los sistemas computacionales para diagnóstico igualmente suelen no reflejar correctamente el comportamiento de los sistemas físicos debido a errores en las representaciones de los componentes, condiciones y variables no consideradas o comportamientos irregulares del sistema real. Esto sin considerar los problemas de instrumentación, los cuales se analizarán posteriormente.

Bajo estos principios, es posible encontrar una larga lista de enfoques, cada uno de ellos con ventajas y desventajas asociadas con las suposiciones con las que se abordan los problemas.

Primero que nada dentro de las comunidades científicas que abordan el problema de diagnóstico ha sido muy marcada la concentración en dos grupos mayores: FDI y DX. FDI son las siglas en inglés de Detección y Aislamiento de Fallas, mientras DX es un acrónimo de diagnóstico. La comunidad FDI basa los fundamentos de sus soluciones en disciplinas de ingeniería tales como la teoría de control y toma de decisiones estadística. Por su parte, la comunidad DX basa los fundamentos de sus enfoques de solución en los campos de ciencias computacionales e inteligencia artificial.

Las dos comunidades poseen éxitos y retos, que han hecho deseable la mezcla de sus enfoques y por ende resulta un tema recurrente de algunos proyectos, así como en los congresos y talleres de ambas comunidades, tales como el Taller Internacional sobre Principios de Diagnóstico (en inglés International Workshop on Principles of Diagnosis) que viene desarrollándose anualmente desde 1989.

Así pues, dentro de los enfoques que es posible encontrar cabe mencionar algunos miembros de la taxonomía que han sido importantes para el diagnóstico en general o aplicados a campos cercanos a las turbinas de vapor.

2.3.1 Diagnóstico basado en sistemas expertos Desde la concepción de la computación, uno de los grandes atractivos ha sido la

generación de programas de computadora que representen y razonen con base en el conocimiento de un especialista, para solucionar problemas u ofrecer consejo para la toma de decisiones. Este tipo de programas son denominados sistemas expertos y han sido, desde finales de la Segunda Guerra Mundial, una de las áreas más importantes de la inteligencia artificial (AI).

Tales sistemas normalmente involucran la experiencia de un humano como fundamento para definir tareas, reglas y explicaciones sobre los sucesos de un proceso o el análisis de la información.

Por principio, se asume que existe alguien, una persona denominada “experto”, quien no requiere ser capaz de construir por sí mismo los sistemas basados en computadora, pero si debe de ser capaz de ejecutar la tarea, saber como se ejecuta la tarea, ser igualmente capaz de explicar como se ejecuta la tarea, tener el tiempo para explicar como se ejecuta la tarea y estar motivado para colaborar en la construcción del sistema.

El desarrollo de sistemas expertos implica una diferencia sobre otros tipos de programas para solución de problemas, que tradicionalmente involucran para reflejar las características de un sistema tanto piezas de código como alguna fuente de datos. En los sistemas expertos toda la representación del sistema estudiado queda en datos, no en código.

Otra diferencia es que no se emplean soluciones algorítmicas, sino una solución de problemas por heurística o métodos aproximados. Una heurística es esencialmente una regla que envuelve el conocimiento sobre como resolver problemas en un dominio. Son métodos aproximados en el sentido de que no requieren datos perfectos para trabajar y las soluciones derivadas pueden proponerse con diversos grados de certidumbre. [JACKSON 1990]

El proceso de construcción de sistemas expertos es también denominado ingeniería del conocimiento y es considerada “Inteligencia artificial aplicada”. Bajo este punto de vista, el responsable de transferir el conocimiento del experto al sistema experto es un “ingeniero del conocimiento” y su rol exige muchas herramientas para asegurar la correcta interpretación de la información del experto.

Al ser el experto la pieza clave para la definición del sistema experto, siempre existirán dudas sobre ¿Cuán experto es el experto? y ¿Se representó correctamente la experiencia del experto?

Los mecanismos de implementación de sistemas expertos han evolucionado desde lograr la más elemental representación del conocimiento del mundo desde una perspectiva de un dominio muy específico, hasta la construcción de reglas, emulando aprendizaje y raciocinio.

La implementación de tales sistemas ha igualmente variado con los años, uno de las opciones más comunes es la implementación de programas en lenguajes lógicos como LISP o PROLOG, donde a través de establecer reglas y hechos se logra representar la naturaleza del sistema y es posible solicitar resultados sobre el paciente.

Otras implementaciones, a partir de 1980, emplean como base sistemas expertos “vacíos”, normalmente denominados “shell” (en inglés cáscara), es decir sin una base de conocimiento. Tales herramientas usan diversas estrategias de reglas y hechos para generar la base de conocimientos. De esta manera puede mencionarse que un sistema experto da lugar a otros, formando una evolución. DENDRAL (sistema experto en LISP para la interpretación de estructuras moleculares) dio lugar a MYCIN (sistema experto en LISP para la detección de enfermedades en la sangre) que a su vez ha derivado en muchos otros sistemas expertos e incluso versiones shell compactas como EMYCIN (Essential MYCIN)

Algunos shells importantes de la actualidad son: CLIPS (C Language Integrated Production System), FuzzyCLIPS, JESS (Java Expert System Shell), TMYCIN (Tiny MYCIN) o PESS (Prolog Expert System Shell) [GIARRATANO 1994, KAZAROV 1998].

La crítica general de este tipo de herramientas es que suelen ser utópicas e inadecuadas para la mayoría de las situaciones reales, por lo inflexible del manejo de sus reglas y la ambigüedad inherente a la presencia de los hechos. Esto ha hecho que pese a las diversas evoluciones de este tipo de herramientas, muchos desarrolladores opten por modelar con otras alternativas.

2.3.2 Diagnosis probabilística Cuando, como suele suceder en la mayoría de los casos reales de diagnóstico, los

fenómenos no son deterministas, se echa mano de herramientas que permitan introducir características de incertidumbre o aleatoriedad en el modelo. La teoría de probabilidad es una teoría matemática que permite el manejo de fenómenos aleatorios, permitiendo que un experimento ofrezca resultados diferentes con las mismas entradas.

Para el modelado de sistemas reales, se establecen estadísticas que permitan la generación de distribuciones de probabilidad que reflejen las características del sistema. Las herramientas probabilísticas tienen fuertes fundamentos en la teoría de conjuntos.

Con los fundamentos de probabilidad tales como la probabilidad discreta, la continua y la condicional, se puede manifestar de diversas formas la incertidumbre del sistema.

El teorema de Bayes establece el uso de probabilidades en dos momentos: una probabilidad a priori, normalmente basada en estimaciones de estadísticas históricas, sin ninguna experimentación y una probabilidad a posteriori, es decir mejorada tras de un proceso de experimentación.

Con esta mejora las herramientas pueden realizar mejores aproximaciones de los sucesos futuros, tal como sería una diagnosis de un sistema en función de un modelo probabilístico. De esta forma, un sistema experto que se guía por reglas del tipo SI…ENTONCES, puede ahora incluir un análisis condicionado a las probabilidades para cada evento dadas una serie de sucesos o síntomas previamente identificados.

Las redes bayesianas emplean un modelo de variables aleatorias mediante grafos dirigidos, su implementación permite ir actualizando las probabilidades ante nuevas evidencias, generando mejores soluciones conforme más ejemplos le sean suministrados.

Como defecto de la diagnosis basada en herramientas probabilísticas, debido a la naturaleza de la ley de los grandes números, su fineza depende de que se cuenten con suficientes ejemplos como para imitar las condiciones reales del sistema, incluyendo en la muestra tanto las situaciones menos probables, como el reflejo de cuan frecuentes son los casos más probables.

2.3.3 Diagnóstico por redes neuronales Las redes neuronales artificiales (ANN), constituyen un enfoque totalmente

matemático de los problemas que básicamente busca copiar un modelo biológico, el sistema nervioso. Así, se emula el comportamiento de la neurona y la interconexión entre neuronas por impulsos. Para lo cual, se modela considerando tres funciones principales:

• Una función de propagación o excitación, por lo general consistente en la sumatoria de las entradas, multiplicada por el peso de su interconexión (valor neto). Si el peso es positivo, se dice que la conexión es excitatoria; si es negativo, se denomina inhibitoria.

• Una función de activación, que modifica a la anterior. Puede no existir, siendo en este caso la salida la misma función de propagación.

• Una función de transferencia, que se aplica al valor devuelto por la función de activación. Se utiliza para acotar la salida de la neurona y generalmente viene dada por la interpretación que se requiera en las salidas. Comúnmente se emplean las funciones sigmoide (valores en el intervalo [0,1]) y la hiperbólica‐tangente (valores en el intervalo [‐1,1]).

Dentro de los principios de ANN, el término “perceptrón” se refiere a una neurona artificial y también como unidad básica de inferencia en forma de discriminador lineal, que suele formar parte de una red neuronal artificial. Un perceptrón puede clasificar datos que sean linealmente separables. En el caso de un perceptrón con dos entradas deberá poder trazarse una única línea que separe las dos clases que permite identificar el perceptrón.

Figura 2‐1 Neurona artificial de dos entradas

La figura 2‐1 ilustra una neurona artificial con dos entradas (X1, X2), una salida (Y) y las funciones matemáticas que emplea, donde, se ocupa como función de excitación la sumatoria (Σ) de las entradas modificadas mediante las funciones de peso (w1, w2), y se ocupa un sigmoide con base en un conjunto de referencia (Ѳ).

Al eslabonar capas de estas neuronas en una red, se manifiesta una salida para un conjunto de entradas conformando una función matemática más compleja.

A continuación, en la figura 2‐2, se ilustra el efecto de una red neuronal artificial simple, con múltiples entradas, que incluye capas de entrada y salida, así como una capa oculta o funciones intermedias. Cada capa está integrada por un conjunto de neuronas, las cuales se enlazan, formando la red y combinando sus resultados hasta formar la salida.

Figura 2‐2 Red neuronal artificial simple

Un problema típico de las ANN, es que no es trivial interpretar la forma en que infirió un resultado, por lo que se pierde un nivel de detalle en la explicación del diagnóstico. Otro detalle es que las redes neuronales requieren de entrenamiento, que puede ser supervisado o automático. La combinación de funciones matemáticas de las neuronas de una red neuronal hace posible las más atractivas características de las ANN, como son: el aprendizaje, la tolerancia a fallos y la flexibilidad.

Ilustremos el funcionamiento de las ANN, mediante el uso de funciones booleanas, por su simpleza de cálculo. Simplemente debe asociarse la idea de que, a partir de un nivel dado de intensidad de señal (en TTL es 2.4v), se obtiene un valor de “1” lógico, y a intensidades inferiores, se considera un “0” lógico. Dado esto, es posible relacionar la combinación de dos señales por medio de un patrón. En la figura 2‐3 se exponen algunas funciones, todas son linealmente independientes y con ello, un perceptrón es capaz de aprenderlas.

Sin embargo, este aprendizaje no surge de la nada, y es necesario realizar un entrenamiento, que puede realizarse de manera supervisada alimentando un conjunto de datos a través de los cuales se habilita la memoria de la red, estableciendo los criterios para la identificación de patrones mediante las funciones internas.

Figura 2‐3 Patrones de combinación de señales en distintas compuertas lógicas

Las ANN pueden emplear la retropropagación (backtracking), como técnica para el entrenamiento supervisado, que está basado en retransmitir el error causado a las capas anteriores y vuelve muy certero al sistema de diagnóstico. La retropropagación es el

algoritmo utilizado para el entrenamiento de una red multicapa. Se inicializa la red con una series de pesos aleatorios y tras hacerlos pasar por la red se compara la salida con el patrón que deseamos que aprenda el perceptrón. La diferencia entre entradas‐salidas, estimación del error o valores delta se utilizan para derivar los errores de los pesos de las sucesivas capas de la red haciendo pasar estos valores retrógradamente a la dirección de activación de la red.

Existe una función matemática para realizar esta modificación de pesos. El objeto de la ecuación es buscar un mínimo del espacio de la función n‐dimensional de los pesos. En el perceptrón esta técnica de descenso de gradiente da lugar a una solución única. En las redes multicapa está el problema de la presencia de mínimos locales de modo que no existe un Teorema de Convergencia del Perceptrón. Se recurre a determinados parámetros de ajuste empírico denominados "tasa de aprendizaje" y "velocidad de aprendizaje". Por tanto, para implementarse, esta técnica exige que las funciones de transferencia entre nodos sean diferenciales.

2.3.4 Diagnóstico por clasificación Para algunos casos, el alcance de las soluciones de diagnóstico basta con separar lo

bueno de lo malo, es decir poder diferenciar entre diversas clases de elementos. Así pues los métodos de clasificación se integran como técnicas de diagnóstico en ciertos casos.

El principio de esto nos lleva a la implementación de métodos como: las máquinas de soporte vectorial (SVM), que emplean aprendizaje, algoritmos de clasificación basados en entropía de la información, mediante la cual se construyen árboles de decisiones. Cabe mencionar que los algoritmos de clasificación más publicados son C4.5 e ID3 de Ross Quinlan.

Figura 2‐4 Clasificación por hiperplanos, empleada en SVM

En la figura 2‐4, se ilustra un ejemplo de la clasificación de elementos que realiza el algoritmo de SVM empleando hiperplanos, es decir funciones lineales que establecen

límites y separan los elementos entre clases. En la figura, se aprecian aplicadas de manera redundante tres funciones de tal tipo, separando los elementos en dos clases.

Al clasificar, este tipo de técnicas permite diferenciar entre “buenos” y “malos”, pero igualmente puede simplemente marcar elementos con alguna característica, que posteriormente se asocie a un síntoma.

La clasificación puede extenderse a establecer más de un límite a través de múltiples hiperplanos, generando rangos. En la figura 2‐5 se muestra un ejemplo de clasificación en niveles o rangos múltiples.

Los clasificadores generan subconjuntos y con ello pueden representar eficientes soluciones, pero normalmente sólo sirven como un paso en el proceso de diagnosis. Por ejemplo, mediante un clasificador inteligente pueden separarse por tipos las señales extraídas de un sistema y con ello aplicarse distintos algoritmos de diagnosis según el tipo de señales presente.

Figura 2‐5 Clasificación con múltiples clases

Otro uso típico de los clasificadores en el área de diagnóstico es el procesamiento de imágenes. En este caso se emplean algoritmos donde, a partir de diferencias de colores, identificación de líneas, patrones de formas, luz y sombra, entre otras, se determinan ciertas cualidades como: movimiento, temperatura, color o forma.

Tras eso, se genera información clave para la evaluación de estado del sistema, de manera que el uso de clasificadores es indispensable para muchos procesos de diagnóstico. En la figura 2‐6 se presenta un ejemplo de diagnosis por clasificación, en la cual se procesa una fotografía térmica, separando los distintos tonos y colores. Como ejemplo, un método permite analizar el desgaste de una pieza tomando en cuenta el número de áreas obscuras que presenta una imagen previamente tratada para resaltar los impactos de la temperatura aplicada.

Figura 2‐6 Diagnosis por imágenes

Por último, dentro de las técnicas de clasificación se incluye también el manejo de redes neuronales artificiales como motor de clasificación inteligente para conjuntos linealmente independientes, en los cuales se aprovecha la capacidad de aprendizaje para mejorar la identificación de algunos patrones de clasificación.

Todas las técnicas de clasificación requieren en mayor o menor grado de un proceso de sintonización de parámetros. Este proceso puede ser automatizado, siempre que exista una base de datos con la información de entrenamiento o un patrón de referencia confiable. Otra opción es que se entrene manualmente. Mediante la sintonización se mejoran los resultados de la clasificación, los cuales dependen de la naturaleza del conjunto de datos del sistema.

2.3.5 Diagnóstico basado en modelos El razonamiento que ha llevado hasta el diagnóstico basado en modelos puede

simplificarse como localizar las anormalidades entre el comportamiento que se espera del sistema y el comportamiento que presenta. [HAMSCHER 1992]

Figura 2‐7 Funcionamiento general del diagnóstico basado en modelos

La definición de diagnóstico que emplean los grupos de la comunidad DX, establece que es un estado explicito de un sistema físico compatible con la información disponible sobre el comportamiento real de un sistema y con el modelo de comportamiento de referencia [FENSEL 1996, TOUAF 2005].

Este fundamento tiene su origen en el análisis de compuertas lógicas, donde se mezclan funciones lógicas y que, en caso de presentar una falla, los resultados del conjunto denotarían una modificación con respecto a la tabla de verdad del sistema, es decir el comportamiento real no correspondería al comportamiento esperado. [REITER 1987]

Supongamos un ejemplo con cuatro compuertas, como el representado en el diagrama de la figura 2‐8.

Figura 2‐8 Sistema de compuertas lógicas

Para este sistema se tienen tres entradas (X0, X1, X2) y dos salidas (Y0, Y1), con un par de salidas o funciones intermedias (YA, YB).

Entonces, se tiene que: YA= X0 + X1

YB= X1 · X2

Y0= YA Å YB = (X0 + X1) Å (X1 · X2)

Y1= YA · YB= (X0 + X1) · (X1 · X2) Con estas funciones lógicas, se genera una tabla de verdad que asocia el conjunto de

valores esperados por cada conjunto de entradas. La tabla 2‐2 muestra la tabla de verdad del comportamiento esperado para el sistema de compuertas lógicas del ejemplo.

Tabla 2‐2 Comportamiento esperado para un sistema de compuertas

X0 X1 X2 YA YB Y0 Y1

0 0 0 0 0 1 1

0 0 1 1 0 0 1

0 1 0 1 0 0 1

0 1 1 1 1 1 0

1 0 0 1 0 0 1

1 0 1 1 0 0 1

1 1 0 1 0 0 1

1 1 1 1 1 1 0

Los síntomas serían anormalidades registradas entre las salidas que presente el sistema real y lo manifiesto en la tabla de verdad.

Por ejemplo para el caso de una entrada con todas las entradas en cero, las salidas esperadas son Y0 = 1, Y1=1, de tal forma que, si al inspeccionar las salidas se encuentra una combinación de Y0 = 0, Y1=1, se tiene una anormalidad, en otras palabras, un síntoma, como se refleja en la tabla 2‐3.

Tabla 2‐3 Un síntoma de falla en un sistema de compuertas

Entradas Valor esperado Valor real X0 X1 X2 YA YB Y0 Y1 YA YB Y0 Y1 0 0 0 0 0 1 1 ¿? ¿? 0 1

Con ese síntoma, con base en el diagrama que se ilustra a continuación, resulta identificable que la falla pudiese estar en G2, una compuerta NXOR.

Sin embargo a la vez es engañoso, pues falta determinar YA y YB para afirmar esta hipótesis, ya que si en lugar de haberse dañado G2, estuviese un daño en un par de las otras compuertas, los efectos serian similares. Estas serían entonces dos fallas a considerar para el mismo síntoma.

Figura 2‐9 Síntoma en un sistema de compuertas

Normalmente se toman varios síntomas para determinar una falla. Bajo este fundamento, la diagnosis ha sido descrita como el conjunto de descripción del sistema (SD, por sus iniciales en inglés), observaciones del sistema estudiado (OBS), a partir del cual se generan hipótesis sobre anormalidades en el sistema, normalmente descritas como funciones o expresiones de lógica de predicados.

Matemáticamente, un diagnóstico para (SD, COMPONENTES, OBS), es un conjunto mínimo ∆ ⊆ COMPONENTES tal que: SD ∪ OBS ∪ {¬AB(c) | c ∈ COMPONENTES ‐ ∆}, es consistente, donde AB es el predicado de anormalidad, tal que AB(c) significa que el componente c es anormal o falla.

La idea es mantener el conjunto de componentes anormales tan pequeño como sea posible, incluyendo un componente sólo si su presencia es requerida por un síntoma en OBS.

A partir de las observaciones y con el conocimiento de las funciones internas del sistema, puede igualmente calcularse el conjunto interno de salidas parciales (INT), el cual sirve para ubicar fallas cuando las anormalidades a partir del conjunto de observaciones OBS señalan un conjunto de posibles fallas. Mediante inspecciones al sistema puede identificarse el valor real que presenta en cierto punto interno y cotejarse contra el conjunto INT.

Otras técnicas infieren los valores reales a partir del mismo conjunto de funciones y adoptan la comparación entre lo esperado y lo calculado con base en valores reales.

En todo caso, las anormalidades o síntomas se detectan como resultado de funciones de comparación, que comúnmente son desigualdades escalares, sin embargo puede haber casos donde se adopten otros modelos comparativos: mezclas de incrementos y decrementos, manejo de rangos, aplicación de funciones estadísticas o calificadores cualitativos.

Se considera que la diagnosis basada en modelos por sí sola es utópica, dada la fragilidad del principio de que un único modelo pueda describir el comportamiento que se espera de un sistema real.

2.3.6 Diagnóstico basado en casos Dentro de las estrategias de la inteligencia artificial, existen técnicas para determinar

soluciones con base en problemas similares del pasado (denominados “casos”) para encontrar solución al problema actual (caso de referencia)1 [AAMODT 1994]. Una técnica muy recurrente en diagnosis automática, consiste en determinar los patrones que definen a un elemento sano, con daños de diversos tipos, totalmente dañados, etc.

En la práctica esto suele desempeñarse mediante diversos métodos, uno de los más populares es el razonamiento basado en casos (CBR), uno de los paradigmas de solución de problemas que más ha avanzado en los últimos tiempos.

Su enfoque de inferencia reside en calcular la cercanía entre elementos, para formar subconjuntos o clases, para posteriormente establecer individuos que describan al resto de los miembros de dicha clase. Estos miembros que representan al resto se denominan prototipos y se asocian a la memoria de casos (CM).

Para resolver un problema, se compara un caso nuevo con los prototipos, estableciendo a que caso se asocia y con ello se determina si los casos establecidos describen correctamente al nuevo, si falta una clase nueva y se propone una solución que puede involucrar recalificar los prototipos.

Figura 2‐10 Visión general del ciclo del razonamiento basado en casos

En la figura 2‐10 se ilustra el ciclo de la metodología de razonamiento basado en casos, donde el problema de diagnóstico se plantea como la búsqueda de un patrón de falla conocido o incluso uno nuevo que no obedezca a los comportamientos esperados.

1 No confundir el término “caso de referencia”, empleado en el diagnóstico basado en casos, con el término de “modelo de referencia” del diagnóstico basado en modelos.

La implementación de estas soluciones difiere de las técnicas para almacenar y proponer soluciones. A continuación, en la figura 2‐11, se ilustra un ejemplo de la metodología implementada para un sistema de diagnóstico basado en casos.

Figura 2‐11 Metodología de implementación de CBR

Esta implementación inicia por la Recuperación de casos, que consiste en seleccionar "buenos" casos; es decir, aquellos que tengan el potencial de hacer predicciones relevantes acerca del nuevo caso. Un buen caso en nuestro problema sería, por ejemplo, aquel que mostrara el mismo tipo de mediciones en toda la serie de pruebas, o en la mayoría, que las que se están presentando en las pruebas actuales. Luego de recuperar un conjunto de casos a partir de cierto criterio es necesario seleccionar el o los casos más prometedores.

Una vez que se tiene una solución aproximada inicia el proceso de Adaptación, y esto ocurre porque en muy pocas ocasiones la nueva situación coincide exactamente con las antiguas, de manera que la solución antigua debe arreglarse para que se acomode a la nueva.

Se llega a la Crítica y justificación, cuando la solución aproximada ya ha sido adaptada a la nueva. Puede considerarse la etapa de validación de la solución. Sin embargo, existen muchas incógnitas para tener la capacidad real de validar una situación, por lo tanto, se hace una justificación en la que se compara y contrasta la solución propuesta con otras soluciones similares.

Una solución se critica proponiendo situaciones hipotéticas para probar su solidez o ejecutando una simulación para verificar los resultados. En algunas ocasiones es necesario recuperar casos adicionales y esto implica realizar otras adaptaciones llamadas reparaciones.

La solución se ejecuta y se analizan los eventos que ocurren durante o como resultado de la ejecución. Si los resultados son los esperados, no es necesario mayor análisis, pero si fueron diferentes a los esperados, es necesario explicarlos. Esta explicación requiere averiguar qué causó la anomalía y qué pudo haberse hecho para evitarla.

Así la evaluación se realiza en el contexto de casos previos y se basa en la retroalimentación o en la simulación. Este paso incluye explicar diferencias entre resultados reales, justificar diferencias y proyectar consecuencias, además de comparar y clasificar posibilidades alternas. La evaluación puede descubrir la necesidad de hacer reparaciones a las soluciones propuestas.

Se almacena el nuevo caso en la librería de casos para su futuro uso. El proceso más importante es la elección de la forma de indexación del nuevo caso. Los índices deben elegirse de tal forma que el nuevo caso pueda ser recuperado en el momento que sea más útil durante posteriores razonamientos. Además, el razonador debe ser capaz de anticipar la importancia del caso para posteriores razonamientos.

Las soluciones que emplean esta metodología son conocidas por implicar mucho detalle en la descripción del sistema.

2.3.7 Diagnóstico orientado a objetos y ontologías Tomando en cuenta que el diagnóstico tiene en general, mucho que ver con la

interpretación de hechos y sucesos en un contexto definido, se establece que el conocimiento de un sistema estudiado puede servir para inferir su estado, siempre y cuando pueda irse reuniendo una descripción adecuada de los elementos del sistema.

Con el paradigma computacional de construcción de soluciones por un modelo orientado a objetos, se diseña el sistema conceptualizando todas las entidades que intervienen, tanto físicas como virtuales, sus atributos y acciones de interacción.

Las herramientas de ontologías, tienen su fundamento en principios de lingüística, al formular razonamientos basados en construcciones donde se exponen quiénes son los individuos, las clases que definen qué son estos individuos, qué cualidades tienen los individuos, las relaciones entre los mismos, así como las situaciones que generan interacción entre los individuos.

Con base en esto pueden generar reglas de diagnóstico orientadas a la extracción de propiedades o datos reales del sistema en vivo y plantear inferencias sobre el estado del sistema en función del contexto previamente establecido.

Este tipo de enfoques se aplica mucho en ambientes Web y de extracción masiva de datos que de manera implícita o explícita, manifiestan suficiente información para clasificar, los métodos de clasificación suelen asociarse como técnicas de diagnóstico.

Estas técnicas se emplean igualmente para la detección de problemas en códigos de programas de cómputo, fallas en la configuración de redes y ambientes colaborativos de aplicaciones robóticas y de Web.

2.3.8 Diagnosis por simulaciones Ante diversos escenarios, un sistema puede reaccionar de diversas formas, incluyendo

opciones que conduzcan a fallas. La experimentación suele ser la única forma de explorar estas situaciones, sin embargo, no en todos los casos es posible hacer experimentos en directo con el sistema, en especial por los riesgos a la integridad de operadores y usuarios, además de las infactibilidades técnicas y económicas.

Pero dado que todo sistema puede abstraerse y representarse, es posible estudiarlo bajo reproducciones del comportamiento del sistema. Bajo este principio, es posible generar modelos que pueden depender exclusivamente de las entradas del sistema (modelo determinista, que siempre obtiene la misma salida para cierto conjunto de valores de entrada), o presentar variaciones estocásticas con base en representaciones del ambiente del sistema estudiado. [JACKSON 1990]

La simulación es una de las herramientas más comunes en los ambientes de ingeniería, bien sea como herramienta de cálculo o como parte de un laboratorio de pruebas controladas. Los modelos deterministas ofrecen la capacidad de calcular o aproximar los resultados de situaciones donde la incertidumbre es mínima, o su impacto es despreciable como: astronomía, o ciertos modelos de química y física. Mientras tanto, dada la naturaleza de diversos sistemas muy difíciles de llevar a modelos deterministas o donde no se tiene certeza de las interacciones, existe el modelado estocástico que introduce variaciones tanto aleatorias como probabilistas para representar las variaciones no deterministas del sistema. Con todo esto es posible estudiar el sistema bajo pruebas que pueden considerarse “destructivas”, pues llevan al modelo del sistema a experimentar valores no seguros de operación. De la misma forma se pueden repetir experimentos que no implican los costos y riegos de aplicarlos sobre los sistemas reales, o incluso en muchos casos son imposibles de realizar por infactibilidades económicas, técnicas, éticas o legales.

Mediante una simulación pueden estimarse las condiciones y el comportamiento del sistema ante diversos escenarios donde se modifiquen diversas variables de estudio, normalmente asociadas a la configuración del sistema como: el tiempo, la velocidad, la temperatura, etc. Sin embargo, las simulaciones tienen como desventaja que en muchos casos no representan con fidelidad al sistema, o entre todas las ejecuciones o corridas no se llega a analizar los casos que pueden ser críticos para la toma de decisiones.

El uso del diagnóstico por simulación es intensivo en análisis en aeronáutica, industria automotriz, plantas nucleares, bioquímica y genética.

2.3.9 Diagnóstico con algoritmos genéticos Una de las herramientas más populares dentro de las ciencias computacionales son

los algoritmos genéticos. Estos algoritmos son una clase especial de algoritmos evolutivos, que han sido diseñados para encontrar soluciones aproximadas para problemas de optimización y de búsquedas. Se conocen como búsquedas globales heurísticas las cuales, imitando la evolución biológica, buscan mezclar individuos y poblaciones hasta localizar ciertas características en la población o en los individuos.

Al reproducir la evolución biológica y su fundamento genético‐molecular, los algoritmos genéticos (GA) emplean técnicas de: herencia, mutación, selección y recombinación (también denominada cruzamiento), además de emplear términos como: fenotipo, genotipo, cromosomas, generación y descendencia.

La implementación de GA usa simulaciones computacionales en las cuales se emplean funciones estocásticas para generar poblaciones, emular mutaciones y dependiendo de los criterios de diseño, hasta la selección de individuos que generaran nuevos elementos o soluciones.

Figura 2‐12 Algoritmo genético

Como se ilustra en al figura 2‐12, por medio de la repetición de las operaciones de selección, cruzamiento y mutación, se van generando generaciones que se evalúan contra una función objetivo. Se emplea el término “parecido” (fitness en inglés) para señalar el cumplimiento de un patrón de referencia, manejo de un tamaño de error, o una extensa gamma de opciones dependientes de las características definidas como propósito de la búsqueda.

2.3.10 Diagnóstico con enfoque SAT Si bien hasta este punto se ha expuesto la existencia de diversas formas de atacar el

problema de diagnóstico, aún existen muchas técnicas alternas, las cuales involucran aspectos como la evaluación cualitativa, la exploración de herramientas basadas en satisfactibilidad booleana (SAT), la creación de lenguajes que aplican descripciones ontológicas o fórmulas complejas, así como la gamma de mezclas entre las técnicas.

El enfoque SAT puede darse por lo cercano del sistema estudiado con una representación en álgebra de Boole (en análisis de circuitos lógicos por ejemplo), o logrando una interpretación cercana al planteamiento del problema SAT. Para tales casos se plantean soluciones basadas en algoritmos de solución parcial o general del problema SAT como Greedy SAT (GSAT), LSAT, SASAT, GASAT, entre otras. Esto representa la mezcla de distintas herramientas de punta en el área de sistemas como algoritmos genéticos o recocido simulado.

La gran limitante del enfoque es que esta diagnosis permite detectar casos con fallas, es decir separa los “buenos” de los “malos”, pero no permite la evaluación de nivel que otras técnicas aprovechan.

Mezclando el enfoque SAT a un diagnóstico basado en modelos, es posible abstraer las comparaciones de grandes conjuntos de variables en una evaluación de satisfactibilidad y generar un modelo de diagnosis por múltiples etapas.

Además, los problemas de diagnóstico que pueden traducirse a uno de satisfactibilidad, poseen una linealidad analítica y por ello se pueden ocupar instrumentos de optimización para la búsqueda de soluciones.

2.4 Diagnosticabilidad En la jerga de sistemas computacionales resulta común definir las características o

parámetros de calidad en función de las capacidades o habilidades que un elemento puede desarrollar, y se tiene como práctica común usar términos como: operabilidad (habilidad para operarse), durabilidad (habilidad para soportar cambios), e inclusive algunos inexistentes en el castellano como testabilidad, del inglés testability (habilidad de resistir pruebas).

Tal es el caso de la propiedad de un sistema de poder ser diagnosticado, o diagnosticabilidad (del inglés diagnosticability). Esta habilidad es tratada como un punto de comparación entre sistemas estudiados, es decir, ilustra si un objeto puede modelarse de forma que su representación permita conocer el estado de salud del objeto o si la incertidumbre es tal que no es posible confiar en ningún modelo.

Según el caso, se suele definir alguna escala para interpretar la diagnosticabilidad, normalmente asociado a la probabilidad de que un diagnóstico sea acertado. La diagnosticabilidad representa la incertidumbre de los resultados del diagnóstico. Así, un sistema se dice que es diagnosticable si, para cualquier comportamiento del sistema, es posible determinar sin ambigüedad un diagnóstico único.

El problema de la diagnosticabilidad es importante cuando se diseña un sistema debido a que, por una parte se busca reducir el número de sensores para reducir costos, al tiempo que, por otra parte, se busca aumentar el número de sensores para aumentar la probabilidad de detectar comportamientos de falla.

Los algoritmos para determinar la diagnosticabilidad emplean los datos del modelo que describe al sistema (metamodelo), por ende solo puede calcularse para diagnosis basada en modelos.

2.5 Diagnóstico como un elemento de mejora En el mundo real, los sistemas pueden analizarse mientras operan o cuando están sin

carga de trabajo. El diagnóstico en línea o durante operación, permite observar el comportamiento del paciente en condiciones típicas, permitiendo apreciar las condiciones dañinas o de peligro, los vicios, los esfuerzos, además de que dependiendo de la naturaleza del sistema, puede ser la única manera de obtener cierta información.

En el caso de análisis clínico, existen dispositivos portátiles como los monitores de ritmo cardiaco, podómetros, monitores de glucosa, los cuales permiten recaudar información y en muchos casos sirven como herramientas para determinar la condición del paciente, lo que es un claro ejemplo de diagnóstico en línea. Bajo este esquema, por ejemplo, un podómetro puede registrar la cantidad de actividad que ha manifestado el paciente durante su rutina diaria, lo cual permite establecer si sus hábitos son sanos, sin embargo el nivel de esfuerzo real o la condición física integral son aspectos imposibles de determinar mediante este proceso.

Figura 2‐13 Un podómetro como ejemplo de diagnóstico en línea

Cabe mencionar que algunas veces el diagnóstico en línea requiere que las condiciones de operación se encuentren dentro de un margen controlado, alguna secuencia de acciones o ante ciertos estímulos, pero todo esto de acuerdo a parámetros de diseño o promedio de la operación del sistema. Por ejemplo, en el caso del paciente humano, es posible incluir como instrumento de control, realizar un ejercicio sencillo como subir escalones durante unos minutos al iniciar cada jornada.

Por su parte, el diagnóstico fuera de línea requiere de mayor información. Muchas veces la recolección de datos requiere una exploración invasiva, lo cual requiere de condiciones ajenas al desempeño habitual del objeto de estudio. Tales condiciones pueden incluir aspectos como: transporte del individuo a instalaciones que posean la instrumentación adecuada, aislamiento de factores ambientales, control estricto de variables, entre otros. La transportación en ocasiones puede deber al hecho de contar con el equipo y personal capacitado para la recolección e interpretación de la información.

Continuando con la analogía del diagnóstico clínico, para obtener la información sobre la capacidad atlética de un paciente, un examen de esfuerzo, es la mejor manera de determinar la capacidad de absorción de oxígeno de un individuo, que refleja la condición real del paciente en cuanto a la operación del sistema respiratorio y su corazón. Para dichas pruebas se requiere de especialistas en cardiología o medicina del deporte, equipos para someter a un esfuerzo controlable (caminadora, bicicleta fija) e instrumentos para censar: ritmo cardiaco (normalmente mediante electrocardiogramas), velocidad y flujo de aire. Todo ello va más allá del accionar normal, sin embargo ofrece datos que permiten afondar sobre la condición física del paciente. [SLEAMAKER 1989, WAGGENSPACK 2006]

La siguiente figura ilustra la aplicación de una prueba de máxima absorción de oxígeno. Aquí se observa cuan distinto del accionar normal del individuo es una prueba fuera de línea.

Figura 2‐14 Prueba de máxima absorción de oxígeno

Comparando ambos métodos, al emplear diagnóstico en línea, pueden reducirse las molestias al paciente, obtener resultados más ágiles, sin interrumpir el accionar del paciente. Por su lado, la diagnosis fuera de línea ofrece técnicas que pueden ser más precisas, menos inciertas y por ende más aceptables.

En los procesos de control, el diagnóstico entra como el análisis y de ahí su constante estudio por parte de los grupos asociados al control en sus diversas aplicaciones. En la figura 2‐15 se ejemplifica un proceso de control, en el cual se cuenta con cuatro fases: adquisición, análisis, control y acción. El análisis determina la presencia de discrepancias de los valores adquiridos con respecto a algún tipo de referencia, mientras el control determina las correcciones a realizar para las discrepancias presentes.

Bajo un enfoque de diagnóstico en línea, el análisis procesa las señales cuando el sistema está activo, y permite desarrollar soluciones cuyo control sea reactivo. En un atleta en entrenamiento, pudiese determinar que se está desgastando inadecuadamente, con lo cual pudiese corregir, bien sea acelerando o disminuyendo el ritmo de carrera.

Por otra parte, con base a un punto de vista fuera de línea, se puede analizar la mejor técnica de respiración o la capacidad óptima de carrera de un competidor, con base en sus niveles de oxigenación.

Figura 2‐15 Abstracción de un sistema de control

En esquemas de control automatizado, se consideran modelos más matemáticos encaminados al procesamiento rápido de señales y la representación del modelo es compleja en términos del enfoque FDI, en el cual los modelos empleados son matemáticas inherentes al sistema físico.

2.6 Herramientas de diagnóstico El diagnóstico en sus diversos enfoques, ha empleado múltiples técnicas para su

implementación en sistemas de cómputo. Dentro de las técnicas que más tiempo se han asociado al diagnóstico automatizado, pueden destacarse las diversas evoluciones del desarrollo de sistemas expertos, la construcción de redes neuronales artificiales y los desarrollos de inteligencia artificial con fundamentos probabilísticos.

Además, otras herramientas explotan el procesamiento de imágenes, para determinar características por medio de segmentación de colores, igualmente se tiende a la mezcla de técnicas y métodos, formando sistemas basados en modelos con enfoques probabilísticos, por ejemplo.

El lenguaje de diagnóstico con más referencias es LYDIA, desarrollado en la Universidad Tecnológica de Delft en Holanda, para la representación cualitativa y cuantitativa, principalmente matemática, de sistemas de diagnóstico basado en modelos. Los modelos así construidos, reflejados en trabajos de maestría de dicha universidad, implican poseer claridad sobre el sistema. Sus investigaciones, pese a incluir una gamma variada de aplicaciones, han usado modelos relativamente simples.

La mayor ventaja que ofrece este esquema de construcción de sistemas de diagnóstico es la capacidad incremental y de mantenimiento que se ofrece al tener una infraestructura de diagnosis que se modifica en un breve espacio, contrario a lo complejo

de otras opciones. Por otra parte las herramientas de soporte han ido ampliándose y tienden a integrar mayores capacidades de salida y presentación de datos.

Tomando nuevamente como ejemplo a los sistemas de compuertas, es posible ilustrar la diagnosis basada en modelos mediante LYDIA, donde pude describirse el sistema en un enfoque muy similar al orientado a objetos, para luego con base a las propiedades de las compuertas, procesarse bajo un análisis matemático de las propiedades como entradas, salidas y los elementos (compuertas para el caso) que constituyen al sistema.

En la figura 2‐16 se expone un ejemplo de sistema de compuertas.

Figura 2‐16 Ejemplo de sistema para modelar con LYDIA

Su implementación logra describir las múltiples compuertas en un sistema (Polycell), permitiendo su diagnosis con base en características de probabilidad de salud para cada componente.

El código en LYDIA incluido en la tabla 2‐4 sirve para el diagnóstico del sistema ejemplo. [PIETERSMA 2007]

Tabla 2‐4 Código en LYDIA del ejemplo de compuertas lógicas

system Anégate ( bool x1, x2, // inputs bool h, // health bool y ) // output { // explicit fault mode: stuck‐at‐zero y = (h ? (x1 and x2) : false); } system OrGate ( bool x1, x2, // inputs bool h, // Elath bool y ) // output { // explicit fault mode: stuck‐at‐zero y = (h ? (x1 or x2) : false); } system Polycell ( bool x1, x2, x3, x4, x5, // inputs bool h1, h2, h3, h4, h5, // healths bool y1, y2 ) // outputs { // declare intermediate outputs bool z1, z2, z3; // declare components system Anégate m1, m2, m3; system OrGate a1, a2; // connect components m1 ( x1, x2, h1, z1 ); m2 ( x3, x4, h2, z2 ); m3 ( x2, x5, h3, z3 ); a1 ( z1, z2, h4, y1 ); a2 ( z2, z3, h5, y2 ); // define health probabilities probability (h1 = true) = 0.99; probability (h2 = true) = 0.99; probability (h3 = true) = 0.99; probability (h4 = true) = 0.99; probability (h5 = true) = 0.99; }

2.7 Afinidad entre diagnóstico y pronóstico Existen en los humanos la necesidad de buscar indicios que nos permitan anticipar las

situaciones, en especial los problemas, en virtud de buscar disminuir los efectos mediante la preparación ante contingencias. Así se han realizado estudios sobre los sistemas a fin de predecir las condiciones que se presentarán en un futuro.

Las técnicas de predicción suelen requerir modelos temporales, con fundamento de una u otra manera en los modelos de Markov. Por ejemplo, las redes neuronales permiten desarrollar modelos temporales basados en la estacionalidad, mediante la retropropagación, creando modelos autorregresivos (AR), los cuales pueden implementarse con los populares métodos de Box y Jenkins que implementan modelos AR con medias móviles (ARMA), cuyo enfoque es que los datos son estacionales y constantes tanto en ubicación como escala. El método original contempla tres etapas: Identificación, Estimación y Verificación; en la primera se diferencia la información por estacionalidad y se verifica la función de auto correlación, mientras que la estimación consiste en comparar los modelos tentativos con base en criterios como la estacionalidad, invertibilidad, parsimonia y la afinidad. [BOX 1970]. A partir de estos modelos se derivan los modelos autorregresivos con medias móviles integradas (ARIMA).

De esta manera es posible identificar tanto la situación actual como futura de ciertos sistemas, siendo de gran aplicación en estudios meteorológicos, hidrológicos, astronómicos y en la prevención y estimación de tratamientos de enfermedades progresivas.

No solo los modelos de Markov emplean matrices de transición; otros enfoques de modelos temporales pueden modelar reglas y probabilidades para estimar los estados subsecuentes en el tiempo. Tales enfoques conllevan a la diagnosis de fallas secuenciales, causadas por deterioro o factores que pueden predisponer la falla.

Así, muchos ejemplos de sistemas de diagnóstico pueden presentar características de predicción (cuando tienen información con algún tipo de estacionalidad) o de pronóstico (por simulaciones o modelos estadísticos).

2.8 Evaluación de sistemas de diagnóstico El término “mejor” es muy ambiguo dentro de los sistemas de diagnosis automática,

pues puede existir un sistema de resultados muy precisos, pero con un tiempo de diagnosis inadecuado, mientras otro procesamiento es rápido pero con una posibilidad muy alta de errar las estimaciones.

Así, los sistemas de diagnóstico como cualquier otro sistema, deben evaluarse para determinar la calidad de los resultados.

Ninguna comparación sería útil sin unificar los criterios de evaluación. Por ello, dependiendo de los parámetros de calidad que se requieren del sistema, su procesamiento y sus resultados, es necesario considerar y especificar la diagnosticabilidad del sistema, la usabilidad, el tipo de entradas, los tiempos de ejecución y enmarcar la evaluación previamente.

Por tener una dependencia de las mediciones, es recomendable en lo posible evaluar la confiabilidad del método de diagnóstico por separado de la integración con el sistema real.

Esta confiabilidad normalmente se describe de forma probabilística, con base en un conjunto de diagnósticos experimentales de la herramienta, bajo condiciones controladas de entrada. Normalmente se estima la eficacia por cuadrantes, como se ilustra en la figura 2‐17, pero pueden tomarse dependiendo de la naturaleza y profundidad del diagnóstico implementado, como una probabilidad dependiente de las condiciones de los experimentos.

Figura 2‐17 Evaluación de la confiabilidad con base en experimentos

La especificación de los parámetros de calidad, permite la comparación de los aspectos que califican a un sistema de diagnóstico como más adecuado para un caso de estudio dado, pero debe tenerse en cuenta que no es absoluta y por ello pueden darse condiciones bajo las cuales se revierta la comparativa.

2.9 Conclusiones del capítulo En la implantación de sistemas de diagnóstico hay una diversidad de enfoques, por lo

que es necesario considerar adecuadamente las herramientas y las abstracciones del sistema al estudiarlo.

Para cada enfoque de diagnóstico, se asumen distintos principios, que si bien posibilitan la implantación de las técnicas y herramientas, implican el riesgo de admitir modelos falsos del problema, generando resultados poco confiables. Las representaciones o modelos para abordar el problema de diagnóstico varían dependiendo de las herramientas y técnicas que las implementen.

Mientras las redes neuronales artificiales emplean modelos matemáticos para establecer una imitación del sistema nervioso, los enfoques bayesianos sustentan técnicas con modelos probabilísticos, al tiempo que el uso de clasificadores puede distinguir propiedades que identifiquen tipos de elementos, mientras que el diagnóstico basado en modelos se logra al desarrollar una comparación cualitativa o cuantitativa entre un modelo del comportamiento esperado del sistema y el comportamiento obtenido a partir de lecturas en el sistema real.

Dependiendo de las herramientas cambia la interpretación del diagnóstico, por ejemplo, en el caso del diagnóstico basado en modelos, es el resultado de aplicar una comparación entre los comportamientos, ubicando las anormalidades e interpretando en lo posible su origen y tratamiento, mientras que usando clasificadores inteligentes puede significar distinguir entre “buenos” y “malos”.

Especificar y evaluar los sistemas de diagnóstico requiere establecer ciertos criterios como la profundidad de diagnóstico, el nivel de error aceptable y otros parámetros de calidad del software.

Diagnóstico Automático de Turbinas de Vapor en Línea Capítulo 3 Diagnosis de sistemas mecánicos

3 Capítulo 3

Capítulo 3 Diagnosis de sistemas mecánicos

La generación de la energía eléctrica que hace posible la comodidad de la vida moderna, depende en gran medida del funcionamiento de diversos elementos mecánicos rotativos, por ende, todo aquello que permita mantener operando con la eficiencia adecuada a dichos sistemas, envuelve cierta relevancia. Dado que el mantenimiento preventivo de componentes rotativos pretende disminuir las interrupciones en la producción de energía, la relevancia económica resulta obvia, además, los retos técnicos que implica ofrecen el atractivo y la relevancia técnica para las áreas de ingeniería mecánica.

Si bien para entender completamente el análisis de turbinas se requiere un perfil similar al de un ingeniero mecánico, para poder abordar la situación del tema se hace una reseña sobre los diversos enfoques que han abordado el diagnóstico desde el punto de vista mecánico, mencionando algunos fundamentos, exponiendo las diferencias y discutiendo sobre los trabajos recientes y la tecnología más avanzada que infiere en la materia.

A continuación se aborda esta recapitulación sobre el diagnóstico de turbinas de vapor, situando los conceptos básicos para entrar en materia, los principios y enfoques del diagnóstico de turbinas y los beneficios y desventajas de cada opción. Luego de esto, se discute la metodología propia del IIE para el diagnóstico de turbinas de vapor, puntualizando acerca de los detalles importantes que sirven como parámetros de diseño y se cierra con una reseña del capítulo.

3.1 Turbomaquinaria En los campos de ingeniería mecánica se emplea el término ‘turbomaquinaria’ para

describir a aquellas máquinas que transfieren energía entre un rotor y un fluido, incluyendo tanto turbinas como compresores. Mientras una turbina transfiere energía del fluido al rotor, un compresor transfiere energía del rotor al fluido. Los dos tipos de máquinas están gobernadas por las mismas relaciones básicas, incluyendo la segunda ley del movimiento de Newton1 y la ecuación de energía de Euler para flujos compresibles2. Las bombas centrífugas también son turbomáquinas que transfieren energía de un rotor a un fluido, usualmente un líquido, mientras que turbinas y compresores usualmente trabajan con un gas.

El estudio de turbomaquinaria requiere fuertes nociones de física, abordando tópicos como: movimiento, termodinámica, transferencia de masa y energía, presión, temperatura, entalpía, entropía entre otros. A manera de breviario, es necesario presentar algunas generalidades sobre turbinas, sin la ambición de abordar todo el conocimiento sobre turbomaquinaria, sino concentrar los aspectos más significativos para el diagnóstico en línea de turbinas de vapor.

3.2 Generalidades sobre turbinas Para lograr la generación de movimiento que hace posible la generación de energía

eléctrica, se emplean turbomáquinas denominadas turbinas, en las cuales se hace pasar un fluido en forma continua, tal fluido le entrega su energía a través de un rodete con paletas o álabes. Las turbinas constan de un conjunto móvil de elementos denominado rotor, el cual, impulsado por el fluido, arrastra el eje en el que se obtiene el movimiento de rotación. La parte fija de la turbina se conoce como estator y debe ser lo suficientemente resistente y pesada como para soportar las fuerzas que envuelve tal transformación de la energía

El término turbina suele aplicarse a la mayoría de las turbomáquinas motoras, pero también, por ser el componente principal, se suele emplear este término en el conjunto de turbina conectada a un generador para la obtención de energía eléctrica.

Los géneros más importantes de turbinas son: hidráulicas y térmicas. Las turbinas hidráulicas son aquellas cuyo fluido de trabajo no sufre un cambio de densidad considerable a través de su paso por el rodete, éstas son generalmente las turbinas de agua que son las más comunes. Por su parte las turbinas térmicas son aquellas cuyo fluido de trabajo sufre un cambio de densidad considerable a través de su paso por el rodete. Estas se pueden clasificar en turbinas de vapor y turbinas de gas.

1 La variación del momento lineal de un cuerpo es proporcional a la resultante total de las fuerzas actuando sobre dicho cuerpo y se produce en la dirección en que actúan las fuerzas.

2 En dinámica de fluidos, las ecuaciones de Euler son las que describen el movimiento de un fluido compresible no viscoso. Su expresión corresponde a las ecuaciones de Navier‐Stokes cuando las componentes que disipan son despreciables frente a las que convergen.

Las turbinas de vapor son empleadas para la generación de electricidad en plantas de poder térmico, tales como las nucleares, o de combustibles fósiles como carbón o aceite combustible. Antiguamente se conectaba la turbina directamente a dispositivos mecánicos como la hélice de un barco (un ejemplo clásico es el Turbinia, uno de los primeros barcos de vapor), pero la mayoría de las aplicaciones actuales emplean engranes de reducción o algún paso eléctrico intermedio, el cual alimenta a un motor eléctrico conectado a la carga mecánica.

Para entender correctamente el funcionamiento de la mayoría de las turbinas de vapor, es indispensable definir el término “álabe”, que es cada una de las paletas curvas de una rueda hidráulica o de una turbina. Existen dos tipos de álabes: fijos y móviles, los fijos están afianzados al estator, mientras los móviles al rotor. La combinación de ambos genera un canal, a través del cual se realiza la transferencia de energía aprovechando la expansión del vapor.

Industrialmente, las turbinas de vapor se clasifican dependiendo de las condiciones de presión para las que se diseñó. La forma en la que se interconectan para aprovechar al máximo la potencia del vapor hace que se combinen, conectando la fuente de vapor directamente a una turbina de alta presión y se hace circular hacia otras turbinas de menor presión. Como se muestra en el ejemplo de la figura siguiente, dentro de las turbinas de vapor existen turbinas de alta, media y baja presión, que típicamente no se encuentran como elementos separados, sino armadas en un sistema mayor que continúa denominándose turbina.

Figura 3‐1 Ejemplo de turbina de vapor

Por otra parte, como se resume en la siguiente figura, las turbinas pueden clasificarse en función a la forma en la que la energía se extrae, esto es si son de impulso o de reacción. En la turbina de impulso o acción, el flujo se inyecta mediante el estator, que

consiste en un conjunto de toberas en las cuales la alta presión y baja velocidad del flujo a la entrada se transforma en baja presión y alta velocidad a la salida. Estas toberas están puestas en una posición tal que proporcionan el fluido a los álabes móviles con un ángulo definido, produciendo un cambio en la dirección del flujo, haciendo girar el rotor.

La turbina de reacción está constituida por un juego de álabes fijos o toberas y un juego de álabes móviles. Sin embargo, ocurre una caída de presión en los álabes móviles que están dispuestos en forma de toberas. El flujo de gases o vapor que entra en los álabes fijos de una etapa de reacción lo hace a través de toda su circunferencia, por lo que se dice que es de admisión total. En los álabes fijos, el fluido es acelerado mientras que su presión y entalpía disminuyen debido a la disposición de tobera de los canales formados por cada par de álabes. El flujo que sale de estos, entra al conjunto de álabes móviles cuyos canales tienen también forma de tobera, haciendo que el fluido incremente su velocidad relativa con respecto a los álabes mientras que la presión y entalpía disminuyen. La energía producida por el cambio en el momento de los gases, es absorbida por los álabes móviles y transmitida al eje en forma de trabajo útil.

Típicamente las turbinas en las secciones de alta presión son de impulso y las etapas de baja presión son de reacción. La siguiente figura compara ambos tipos de turbinas.

Figura 3‐2 Comparación entre turbinas de impulso y reacción.

Para determinar la eficiencia y el desempeño, es necesario dividir la turbina con el fin de localizar los problemas y situar las correcciones pertinentes, por eso para su análisis

hay varias políticas para tal división. La manera más clásica es por medio de etapas, donde una etapa se considera al par conformado por un conjunto de toberas o álabes fijos y un conjunto de álabes móviles. En una etapa se produce una caída de presión por lo cual es necesario vigilar los valores de presión y temperatura a la entrada y salida de tal etapa. Otro término empleado para dividir la complejidad de la turbina es el de sección o cilindro, que se refiere a cada una de las turbinas que integran el sistema, así se tienen por ejemplo, secciones de alta presión, intermedia presión y baja presión.

La turbina de gas es una turbina de reacción cuyo fluido de trabajo consiste en un gas. Comúnmente se marcan diferencias entre las turbinas a gas y el resto de las turbinas, debido a los aspectos físicos del fluido con el que operan. Si bien otras turbinas funcionan con sustancias en estado gaseoso, sus características de diseño son diferentes, y, mientras que en la turbina de gas no se espera un posible cambio de fase, cuando se habla de vapores es indispensable considerar tales cambios.

En la turbina de gas, la mayor parte de sus estudios se reducen al análisis de temperaturas, donde existen dos principios de operación: primero, que mayor temperatura implica mayor poder y segundo, a mayor temperatura se economiza combustible. Por su parte, el análisis de turbinas de vapor requiere considerar presiones y temperaturas, lo que en general puede considerarse como un reto mayor.

En el diseño de plantas, la potencia marca casi todas las diferencias con respecto a los sistemas de turbinas, estableciendo en la mayoría de los casos, las opciones de combustible, los accesorios necesarios, e incluso la ubicación y las dimensiones de la planta de generación.

Una planta nuclear por ejemplo, se justifica cuando la potencia requerida es de varios GW, pero arrastra una planeación mucho más delicada y envuelve muchos requisitos difíciles de reunir como una fuente de agua permanente, suficientemente amplia como para refrigerar el reactor nuclear (esto crece conforme a las características del reactor, pero típicamente se requiere de un lago profundo), una zona asísmica de suelo firme y acceso a un combustible nuclear suficientemente potente.

Las turbinas de vapor por combustibles fósiles ofrecen menor capacidad de potencia, pero se justifican en virtud de que al comparar los costos y dificultades durante su instalación, mantenimiento y operación, así como los riesgos asociados, pues son muy inferiores a sus contrapartes empleadas en plantas nucleares.

Ilustrando esto, en México, de acuerdo a datos de la Comisión Federal de Electricidad (CFE), la única central nucleoeléctrica es Laguna Verde, en el estado de Veracruz y cuenta con dos unidades generadoras de 682.5 MW eléctricos cada una (está planeado extender en el corto a mediano plazo a una más), que representa 2.74% de la capacidad instalada por la CFE, y contribuye con sólo 4.61% de la generación nacional, contra los más de 2/3 de la generación por combustibles fósiles (Este dato varia pues las unidades termoeléctricas constituyen además el mecanismo de respaldo cuando se requiere disminuir la producción en alguna planta).

3.3 Ciclos termodinámicos Uno de los principios más fundamentales para el análisis de turbomaquinaria, reside

en identificar las características ideales del comportamiento físico para el objeto de estudio, dado que para la operación de la mayoría de las turbinas existe un cambio de temperaturas, esta identificación consiste es distinguir los procesos termodinámicos que regresan al sistema a sus estado inicial, llevándolo por ejemplo desde un punto máximo al mínimo de temperatura y de regreso, ubicando con ello el ciclo termodinámico que rige la física del aparato. Los ciclos termodinámicos se representan mediante gráficas relacionando un par de variables, bien sea temperatura contra entropía (gráfica T‐S), o presión contra volumen (gráfica P‐V), dependiendo de cual de las variables refleja mejor la presencia de los procesos.

3.3.1 Ciclo Rankine Una turbina de vapor se caracteriza por el Ciclo Rankine (ilustrado en las figuras

siguientes), el cual consta de cuatro procesos mayores:

• Proceso 1‐2: Se presenta una expansión (idealmente isoentrópica, es decir con entropía constante) del fluido en la turbina, desde la presión de la caldera hasta la presión del condensador.

• Proceso 2‐3: Hay transmisión de calor desde el fluido de trabajo al refrigerante, a presión constante en el condensador, hasta el estado de líquido saturado. Se dice que el líquido está saturado si al agregar energía (calor), una fracción de él pasa a la fase vapor.

• Proceso 3‐4: En el proceso de compresión (también idealmente isoentrópica) en la bomba, se aumenta la presión del fluido mediante un compresor o bomba, al que se le aporta un determinado trabajo.

• Proceso 4‐1: Existe una transmisión de calor hacia el fluido de trabajo a presión constante en la caldera.

Figura 3‐3 Ciclo Rankine característico de las turbinas de vapor.

Figura 3‐4 Gráfica T‐S del ciclo Rankine convencional

Existen variaciones al ciclo Rankine que buscan mejorar el rendimiento, entre ellas se encuentra el ciclo Rankine con recalentamiento, mediante el cual es posible conseguir un aumento del rendimiento total. Esto es debido a que se puede tener una presión de caldera más alta sin que suponga una reducción de la fase del vapor a la salida de la turbina. Ahí el vapor no se expande directamente hasta la presión del condensador, sino que lo hace en dos etapas. En la primera el vapor se expande hasta una presión intermedia entre la de la caldera y la del condensador. Posteriormente, se vuelve a introducir en la caldera, recalentándose. Después del recalentamiento se vuelve a expandir en la segunda etapa de la turbina hasta la presión del condensador. Dentro del ciclo Rankine con recalentamiento, se le denomina turbina de alta presión a la primera etapa de la turbina y a la segunda etapa turbina de baja presión.

Otra variación es el denominado ciclo Rankine regenerativo. En esta variación se introduce un nuevo elemento al ciclo, un calentador abierto. Este elemento consiste en un intercambiador de calor por contacto directo en el cual se mezclan dos corrientes de agua para dar una corriente de temperatura intermedia. De las dos corrientes que entran al calentador una proviene de una extracción de vapor de la turbina y la otra del condensador (sufre la expansión total). Como las presiones en el calentador han de ser iguales, se añade una bomba después del condensador para igualar la presión de la parte del vapor que ha sufrido la expansión completa a la de la extracción.

En un ciclo Rankine real, la compresión de la bomba y la expansión en la turbina no son isoentrópicas, esto es, estos procesos son no‐reversibles y la entropía es incrementada durante ambos procesos. Esto hace que la potencia requerida por la bomba se incremente y disminuye la potencia generada por la turbina. Además, hace más difíciles e interdependientes los cálculos.

3.3.2 Ciclo Brayton El modelo para las turbinas de gas se describe por el ciclo termodinámico de Brayton,

integrado por tres elementos: compresor de gas, quemador o cámara de combustión y turbina de expansión, como se ilustra en la figura siguiente.

Figura 3‐5 Ciclo Brayton abierto.

El aire ambiental es inyectado en el compresor, donde es presurizado, esta compresión del aire permite generar un canal de aire comprimido en un proceso idealmente isoentrópico. Empleando un gas como combustible, se calienta el aire comprimido, a presión constante, transfiriendo energía al aire comprimido, produciendo aire calentado y presurizado, el cual sufre una expansión (teóricamente isoentrópica) a través de una o una serie de turbinas de expansión, que impulsan un generador y una parte del trabajo se emplea para dirigir el compresor.

Figura 3‐6 Ciclo Brayton cerrado.

Al contrario del ciclo Rankine, que recupera el flujo condensado para emplearlo en la generación de vapor que inicia el ciclo, en el ciclo Brayton, el aire empleado se libera

como gases calientes exhaustos, haciéndolo un ciclo incompleto o abierto, sin embargo, a través de un intercambiador de calor, es posible formar un ciclo cerrado, como se ilustra en la siguiente anterior.

En condiciones ideales, como se muestra en la gráfica T‐S de la figura siguiente, está compuesto por cuatro procesos:

• Proceso 1‐2. Compresión isentrópica en un compresor.

• Proceso 2‐3. Adición de calor al fluido de trabajo a presión constante en un intercambiador de calor o una cámara de combustión.

• Proceso 3‐4. Expansión isentrópica en una turbina.

• Proceso 4‐1. Remoción de calor del fluido de trabajo a presión constante en un intercambiador de calor o en la atmósfera.

Figura 3‐7 Gráfica T‐S del ciclo Brayton ideal.

Al igual que en el ciclo Rankine, existen variantes del ciclo Brayton, tales como el ciclo Brayton con regenerador, el ciclo Brayton de múltiples etapas, tanto de compresión como de expansión, o la combinación de un ciclo Brayton con un ciclo Rankine para dar lugar al denominado ciclo combinado. Todas estas variantes buscan optimizar uno o varios factores físicos como presión o temperatura, fundamentalmente para mejorar el uso del combustible.

3.4 Generación de energía con turbinas El uso más extensivo de las turbinas de vapor es la generación de energía eléctrica,

donde puede encontrarse operando sola o en combinación con turbinas de gas. La operación independiente es común en plantas de generación de combustibles fósiles, las cuales, pese a su indeseable contaminación, son las más comunes en el mundo, produciendo más de la mitad de la energía eléctrica mundial. En países como China, esto llega a niveles tan altos como 80% de su generación eléctrica mediante el uso de combustibles fósiles, principalmente carbón.

Para generar energía, la turbina requiere un suministro de vapor adecuado para su operación. La fuente de vapor en las plantas de combustibles fósiles es llamada generador de vapor o caldera. Para no ver interrumpido su funcionamiento, la práctica más común es instalar la planta cerca de algún yacimiento abundante de combustible. Otro requerimiento de tales plantas suele ser una fuente de agua tanto para la generación del vapor, como para el enfriamiento del sistema.

Además de lo versátil que es en cuanto a las diversas fuentes de vapor que existen, el principal atractivo de las turbinas de vapor es la potencia que pueden generar, en especial con las ventajas que ofrecen los avances tecnológicos en la materia desarrollados en los últimos años, enfocados por una parte a mejorar la eficiencia y por otro lado a disminuir las emisiones de contaminantes.

En el mundo, los rangos de potencia y eficiencia de las turbinas de vapor continúan en aumento, sin embargo para ofrecer una idea de las capacidades se ofrece en la tabla siguiente una breve recopilación de las turbinas japonesas y alemanas más eficientes. [LEYZEROVICH 2007]

Tabla 3‐1 Unidades de turbina de vapor en el mundo, con eficiencia.

Unidad de poder, País

Salida nominal

Fabricante de la turbina de

Condiciones de vapor, MPa -ºC (psi-ºF)

Eficiencia de la turbina,

Año de puesta en operación

Heckinan Unidad 3, Japón 700 MHI 24.0-538/593

(3,480-1,000/1,100) 47.4 1993

Heßler, Alemania 720 ABB 27.5-578/600

(3,990-1072/1112) 47.6 1997

Kawagoe Unidades 1 y 2, Japón 700 Toshiba 31.0-566/566/566

(4,495-1050/1050/1050) 48.4 1989

Boxberg Unidad Q, Alemania 907 Siemens 26.6-545/581

(3,860-1,013/1,078) 49.0 2000

Tachibana-wan Unidad 2, Japón 1,050 MHI 25.0-600/610

(3,625-1,112/1,130) 49.2 2000

Estos ejemplos ilustran algunos de los más potentes equipos de vapor, descontando aquellos empleados en centrales nucleares. Si se toma en cuenta que pese a los esfuerzos por conseguir fuentes alternas de generación de energía (tales como geotérmica, eólica o solar), la salida nominal de tales plantas es de unos pocos MW, razón por la cual se complica satisfacer la demanda con fuentes alternas y aumenta la relevancia del mejoramiento de los procesos de generación mediante quema de combustibles fósiles.

Por otra parte, además de distinguir a las turbinas de vapor por el método de generación de vapor, también se diferencian dependiendo de los arreglos que complementan su función. Así existen: turbinas de condensado, turbinas de recalentamiento, y turbinas de extracción. Las turbinas de condensado emplean vapor parcialmente condensado, son las más comunes en las etapas iniciales, especialmente en generación nuclear. Por su parte, en una turbina de recalentamiento, el flujo de vapor sale de una sección a alta presión de la turbina y es regresado a la caldera donde se le vuelve a sobrecalentar. El vapor entonces regresa a una sección de presión intermedia de la turbina y continúa su expansión. Finalmente, la turbina de extracción, que tiene aplicaciones más diversas fuera de la generación de energía, opera mientras el vapor es liberado en diversas etapas y aprovechado en distintos procesos industriales. Este vapor también puede ser enviado a calentadores de agua para mejorar la eficiencia del ciclo. [LICHTY 1967]

Esta taxonomía general pone en evidencia las múltiples opciones existentes en cuanto a generación de energía, sin embargo cabe mencionar las aplicaciones menos populares de las turbinas de vapor como: mecanismo de propulsión de barcos de vapor y submarinos nucleares, producción de papel, alimentos y acero. El análisis de este tipo de aplicación queda fuera del alcance de esta investigación, sin embargo es valido referir una vertiente para futuros proyectos.

Figura 3‐8 Barco de vapor británico

Por otra parte, las centrales termoeléctricas no tienden a emplear la generación por turbinas de vapor solitarias, uno de los arreglos más comunes es el ciclo combinado, que se explica a continuación.

3.4.1 Ciclo combinado En la generación de energía se denomina ciclo combinado a la co‐existencia de dos

ciclos termodinámicos en un mismo sistema, uno cuyo fluido de trabajo es el vapor de agua y otro cuyo fluido de trabajo es un gas producto de una combustión.

En una central eléctrica el ciclo de gas genera energía eléctrica empleando al menos una turbina de gas, mientras el ciclo de vapor de agua lo hace mediante una o varias turbinas de vapor. El principio sobre el cual se basa es utilizar los gases de escape a alta temperatura de la turbina de gas para aportar calor a la caldera o generador de vapor de recuperación, la que alimenta a su vez de vapor a la turbina de vapor. La principal ventaja de utilizar el ciclo combinado es su alta eficiencia, ya que se obtienen rendimientos superiores al rendimiento de una central de ciclo único y mucho mayores que los de una de turbina de gas. En la siguiente figura se ilustra el concepto de ciclo combinado.

Figura 3‐9 Ciclo combinado de gas y vapor.

Las centrales de ciclo combinado resultan contaminantes para el medio ambiente y para los seres vivos, incluidas las personas, por los gases tóxicos que expulsan al ambiente. No obstante es la que menos contamina de todas las industrias de producción de

electricidad por quema de combustibles fósiles. Básicamente las emisiones son de CO2, dado que las emisiones de NOX y SO2 son insignificantes, por tanto no contribuyen a la formación de lluvia ácida, tales efluentes gaseosos dependen del tipo de combustible que se queme en la turbina de gas. [LEYZEROVICH 2007]

Durante los últimos años, en las plantas de generación termoeléctrica modernas se ha experimentado un incremento gradual en la eficiencia, debido a varios factores, como la introducción de ciclos eficientes y la experimentación con nuevos materiales en álabes y carcasas. Ambas modificaciones permiten trabajar con mayores temperaturas, bajo las cuales, es posible recuperar mayor calor para generar más y mejor vapor que se emplea más efectivamente en las turbinas de vapor modernas.

Otro ejemplo de desarrollo prometedor, se presenta en recientes esfuerzos por consolidar plantas de generación con sistemas de ciclo combinado integrados con energía solar, produciendo vapor de una forma dual, tanto por el reciclaje de las emisiones de una turbina de gas, como por un generador solar de vapor, integrando un enorme generador de vapor compuesto, del cual se obtiene vapor de diferentes capacidades, que se inyecta en varias etapas de una turbina de vapor. Este concepto de ciclo combinado integrado con energía solar se ilustra en la siguiente figura.

Figura 3‐10 Ciclo combinado con energía solar integrada.

3.4.2 Cogeneración Durante la generación de energía eléctrica, es posible producir simultáneamente otras

formas de energía aprovechable, donde la combinación más común es la obtención para fines útiles de energías eléctrica y térmica, partiendo de un único combustible, tales sistemas se denominan de cogeneración. En la figura siguiente se plasma un esquema conceptual sobre la cogeneración.

Figura 3‐11 Cogeneración de energías eléctrica y térmica.

Las aplicaciones de la cogeneración aprovechan el vapor, para usos industriales o por ejemplo en la calefacción y obtención de agua caliente sanitaria para sitios universitarios, hospitales, etc. Con estos sistemas se mejora la eficiencia energética, consiguiendo con el mismo combustible más energía, repercutiendo en una serie de ahorros y entre ellos la disminución de las emisiones de contaminantes, especialmente CO2.

El conflicto más grande de la cogeneración, está en los costos relacionados con la salida de operación, puesto que, si en plantas sin cogeneración, tales costos representan los egresos por concepto de las opciones que cubran la demanda en lo que se regresa a operar, en cogeneración implica todo lo asociado a cubrir la demanda para cada servicio, es decir en el caso de una cogeneración de energía eléctrica y térmica, se tiene que considerar el manejo de alternativas para cubrir las necesidades de electricidad y de calor.

Por último, otras modalidades sobre la cogeneración, son: la trigeneración, y tetrageneración. La trigeneración es una opción en la que se utiliza el calor residual para producir frío mediante un método de absorción, además de las energías eléctrica y térmica. Si bien es poco común, en la tetrageneración, además de las energías de la trigeneración, se obtiene algún tipo energía mecánica residual aprovechable, por ejemplo en la obtención de aire comprimido.

3.4.3 Generación de energía en México México es un país rico en recursos naturales y por ende la generación de energía

eléctrica permite diversificar los tipos y ubicaciones de las centrales eléctricas, sin embargo, al igual que en la mayoría de países, las alternativas a la generación por combustibles fósiles apenas representan una opción de apoyo ante la creciente demanda. Este hecho se refleja en el gráfico de pastel de la siguiente figura, en el cual se representan cada uno de los tipos de generación existentes en México hasta septiembre de 2007.

Figura 3‐12 Capacidad efectiva instalada de generación de CFE

Complementando el dato, en la siguiente tabla se ha condensado la información reportada al cierre de septiembre de 2007, por la Comisión Federal de Electricidad (CFE) sobre la capacidad efectiva instalada y la generación por cada tipo de generación termoeléctrica. Cabe resaltar lo mucho que se aplica la generación con turbinas de vapor, dado que la CFE reporta con base en una clasificación en la cual se incluyen diversas opciones que emplean turbinas de vapor solas o en combinación con turbinas de gas.

Tabla 3‐2 Capacidad efectiva instalada y generación de unidades termoeléctricas.

Tipo Capacidad (MW) Generación (GW/h)Vapor 12,716.10 38,845Dual 2,100.00 10,709Carboeléctrica 2,600.00 13,863Ciclo Combinado (CFE) 5,205.34 21,673Ciclo Combinado (productores independientes de energía) 11,456.90 52.103Geotermoeléctrica 959.50 5,502Turbogás 2,103.33 1,049Combustión interna 224.19 841Nucleoeléctrica 1,364.88 7,981Total 38,730.24 152,566

3.5 Monitoreo del desempeño de turbinas Desde un punto de vista técnico, es posible medir la calidad de operación de una

planta mediante ciertos indicadores representativos, nombrados disponibilidad y desempeño. La disponibilidad envuelve todo lo que logra mantener a los equipos en producción. Dado que un equipo tiene algún nivel de importancia para la red de generación en la que se encuentra integrado, los costos por falta de disponibilidad se miden en función de los costos asociados a remplazar la producción del equipo, por ejemplo si cierta turbina está encarga de proveer una cantidad de MW y no está disponible, la red requiere suministrar una generación similar, lo que se traduce en emplear equipos menos eficientes, más costosos de mantener, más contaminantes, o simplemente reducirse a adquirir energía de otras compañías a costos que pueden llegar a quebrantar cualquier presupuesto.

Si bien la práctica común hace algunos años se concentraba casi exclusivamente en la disponibilidad para evitar sus costos, hoy día las presiones por el problema del calentamiento global han impulsado la búsqueda de mejorar el rendimiento del combustible, al tiempo que, la necesidad de aprovechar turbinas pequeñas como sistemas de respaldo para la red de generación eléctrica, hacen que la optimización del desempeño de las turbinas sea importante.

El desempeño se asocia a la eficiencia calculada entre otras formas, por la relación entre las cantidades de potencia generada y de combustible necesario para tal generación, mientras otra opción simplemente manifiesta la potencia y la cantidad de combustible para obtenerla.

Diversos proyectos se han desarrollado a partir del análisis de desempeño de equipos rotatorios, partiendo en cierta medida de la naturaleza del sistema, sin embargo tal y como se destacó al hablar de los métodos generales de diagnóstico, todo modelo de análisis recurre a ciertos aspectos que se asumen para desarrollar tal método. Para turbomáquinas, tales asunciones se concentran en asuntos físicos, por ejemplo considerar despreciable cierta pérdida de presión en algún momento. Estas suposiciones simplifican y vuelven factible el análisis de condición del equipo.

3.5.1 Condiciones de operación Se debe diferenciar entre las posibles situaciones que enfrenta una máquina en su

operación, por ello el estudio de turbomaquinaria implica analizar diversas condiciones de operación del equipo para determinar el estado de la máquina. La mayor parte de las metodologías para el diagnóstico de equipos rotativos requieren la existencia de un conjunto de condiciones específicas para el diagnóstico, tales como operar a cierto rango de velocidades, a uno o varios niveles determinados de carga, igualmente puede requerirse que el vapor presente ciertas propiedades como temperatura, grado de condensación, o un flujo específico.

Básicamente pueden distinguirse dos clases de condiciones de operación: aquellos momentos en que los procesos termodinámicos operan a un nivel de producción y

aquellos transitorios para llegar a un nivel de producción. Normalmente los transitorios suelen ofrecer información de relevancia en cuanto a las fallas por fatiga, pues tienden coincidir con la mayoría de los puntos críticos de los materiales. Tal es su importancia que es posible marcar por separado los eventos termodinámicos que suceden durante los transitorios para estimar el tiempo adecuado para el siguiente mantenimiento o incluso la vida remanente de algunas piezas del equipo. En la siguiente figura se muestra un gráfico de carga en el tiempo, donde existe un cambio de cargas, por ende hay dos ciclos transitorios, uno de arranque y uno de paro.

Figura 3‐13 Carga en ciclo de paro y arranque típico de una turbina

El monitoreo de los ciclos de arranque y paro resulta exhaustivo y forma parte de la operación típica de las plantas de generación de energía, en el caso de turbinas de gas suele realizarse con base en el tiempo que establece el fabricante como espacio entre mantenimientos mayores, mientras que en turbinas de vapor, participa en las tareas de monitoreo de las condiciones estructurales del equipo. Sin embargo para establecer el estado actual de un equipo rotativo, la información más importante se concentra en los puntos estables, los cuales proveen información sobre el comportamiento real del equipo a ciertas condiciones de operación calculables.

Un problema asociado a los estados transitorios, es la presencia de retrasos en los efectos físicos en diversas piezas de la turbina. Poniendo como ejemplo los efectos del ciclo de arranque y paro, para incrementar la carga, se deben de presentar aumento en la velocidad, lo cual requiere un incremento en el flujo, que tanto por la temperatura en el vapor como por la fricción, implica un aumento de temperatura y dada la combinación de momentos, ejerce un efecto de presión y fuerzas, es decir, prácticamente todas las variables registran incrementos. Pero obviamente no todo se incrementa al parejo en el sistema, primero se presentan los incrementos en los instrumentos de la entrada de

vapor, posteriormente afectará la superficie del rotor, transfiriendo los efectos a la carcasa y por ende la parte que más tardará en registrar los efectos será la parte externa del sistema. Todo esto se refleja en la siguiente figura, ilustrando una gráfica de temperaturas con los efectos en cuatro áreas de una turbina.

Figura 3‐14 Temperaturas en ciclo de paro y arranque típico de una turbina.

Así, dado que los incrementos en las variables marcan condiciones críticas de esfuerzo, exponen las debilidades del equipo, permitiendo pronosticar situaciones como los tiempos para mantenimiento o las fallas más próximas, pero introducen demasiado ruido para determinar adecuadamente el estado del equipo, por lo que deben seleccionarse ciertas condiciones de operación para explorar el desempeño del equipo y con ello estimar las fallas. Típicamente los fabricantes recomiendan el registro a diversos niveles de carga, bajo las mismas condiciones de vapor.

3.5.2 Adquisición de datos en equipos rotativos Para poder lograr reunir la información necesaria para evaluar la turbina, se necesita

una infraestructura tanto de hardware como de software que reúnan ciertas características que garanticen la calidad de la información recolectada, misma que se identifica mediante parámetros como la fidelidad, confiabilidad, disponibilidad, precisión y exactitud de los datos. La adquisición de datos ha experimentado evoluciones, dirigidas a la estandarización, la mejora de la calidad de la adquisición, la compatibilidad, la detección de problemas, la conectividad y las capacidades para adaptarse sin requerir grandes cambios.

Así han nacido estándares tanto de facto como oficiales o de iure, para los diversos aspectos técnicos envueltos en la adquisición de datos, como: transferencia de la información en redes informáticas, tratamiento de señales analógicas, conectores físicos, formatos de información, encriptación de datos, entre otros.

Para seleccionar un método de adquisición de datos existen propiedades que diferencian los productos, pues aspectos como la velocidad de adquisición se convierte en un problema cuando se busca registrar señales de frecuencia muy alta o muy baja. Mientras la capacidad de responder ante cambios instantáneos de las señales, igualmente puede ser deseable que indeseable; por ejemplo, si bien un arranque idealmente debe ser una rampa, las señales reales muestran otro comportamiento, ilustrado en la figura siguiente, que para algunas aplicaciones será necesario registrar y en otros casos puede inducir problemas.

Figura 3‐15 Ejemplo de adquisición de velocidades durante un arranque.

Los sistemas en tiempo real tienen características muy especiales con relación al resto de los sistemas, pues esta clase de sistema requiere ejecutar cada acción con una frecuencia requerida, y que ciertas tareas se ejecuten antes que otras. Dentro de las opciones de recolección de datos, existen las aplicaciones de Control de Supervisión y Adquisición de Datos (SCADA), los cuales permiten la adquisición de datos desde múltiples puntos, concentrándolas en un destino estratégico, para control o supervisión. Las opciones para implementar aplicaciones SCADA van desde los desarrollos independientes, tanto en hardware como en software, hasta la compra de módulos de un sistema comercial que incluso se integre a los sistemas informáticos financieros de la empresa.

Entre varios factores, los sistemas SCADA han impulsado la evolución de los sistemas de adquisición de datos, los cuales recolectan información, digitalizándola y son típicamente reconocidos por su acrónimo de DAQ, (Data Acquisition en inglés), dentro de los cuales existen diversos proveedores.

La compañía National Instruments (NI) es uno de los proveedores populares en los desarrollos industriales de sistemas que no adquieren un sistema completo de SCADA, pues ofrecen opciones modulares tanto de hardware como de software. Su concepto es generar instrumentaciones virtuales con base en sus productos, principalmente LabView, una herramienta de programación visual con base en un paradigma de desarrollo por componentes, es decir, se ocupan piezas previamente desarrolladas, que implementan

funciones, principalmente para el tratamiento de señales. NI además produce tarjetas de adquisición de datos, hardware para la integración y tratamiento de señales incluyendo audio y video, recolección de señales de vibración además de integración con dispositivos transductores de temperatura, presión, velocidad, etc.

Otro ejemplo de proveedor es OSISOFT, compañía cuyo software de instrumentación de plantas (PI), permite la integración de datos de las plantas y sus soluciones son tanto modulares como integrales y pueden cubrir tanto la parte hardware como el software. A continuación se ilustra un ejemplo de instrumentación con el sistema PI.

Figura 3‐16 Esquema del sistema PI

El sistema PI permite la integración para emplear datos externos o brindar los datos recolectados hacia otras aplicaciones, como algunas versiones del VSCORT desarrollado por el IIE para el control y optimización del régimen térmico con termoeconomía, con la finalidad de racionalizar el uso de energía. Su desarrollo es totalmente ad hoc o a la medida, para cada unidad en la que se implanta, lo cual requiere un análisis exhaustivo del comportamiento termodinámico de los equipos.

Por otra parte, el IIE ha desarrollado su propia plataforma de recolección de datos, bajo el nombre de SICAD (Sistema Computarizado para Análisis Dinámico), cuya arquitectura está basada en la tecnología de National Instruments para la adquisición de datos e implementa una integración de datos e interfases visuales para el análisis de vibraciones.

El SICAD se utiliza en la realización del balanceo de maquinaria rotatoria, permite la adquisición de los vectores de vibración y de las formas de onda durante los arranques, los paros y las condiciones estables de las máquinas y puede desplegar en pantalla diversos tipos de formatos gráficos de vibración en línea, entre ellos, los diagramas de espectros y

los diagramas polares de respuesta; con estos últimos el analista determina la posición física en el rotor en que deben ser colocados los pesos para balancear el equipo.

Este desarrollo ha permitido integrar diversas metodologías, algunas propias del IIE, tales como el desarrollo de herramientas avanzadas para balanceo de rotores, que emplea técnicas de balanceo por influencias (BALIN), mediante las cuales es posible plantear las correcciones mecánicas incrustando o removiendo pesos en el rotor.

Figura 3‐17 Esquema del sistema SICAD

Dentro de las características que han evolucionados con las versiones del SICAD, como en el resto de productos similares, han sido la reducción del tamaño y la mejora de la fidelidad y velocidad de adquisición de datos.

3.6 Enfoques del diagnóstico de turbinas Si bien es posible afirmar que el análisis termodinámico es el principal elemento para

la diagnosis de turbinas, existen varios principios para el estudio de condiciones. Los enfoques, usos y complementos pueden variar, el único elemento común es el monitoreo continuo y la extracción de datos del sistema.

3.6.1 Análisis termodinámico Bajo la perspectiva de calcular el comportamiento con base en la física del ciclo

termodinámico de la turbina, es posible comparar ese cálculo contra el desempeño de la turbina bajo ciertas condiciones de operación controladas. Para obtener el comportamiento calculado, deben considerarse las especificaciones del fabricante y el arreglo de accesorios que infiera en la termodinámica del equipo. Con esto en mente, es posible anticipar un conjunto aproximado de valores para las variables físicas del equipo (temperatura, presión, eficiencia, etc.). Tal conjunto de datos sirve como uno de los elementos de referencia ante los valores obtenidos del monitoreo del equipo en funcionamiento. Con base en esta referencia, es posible establecer cuan acorde a las

características esperadas se encuentra el equipo en estudio, y con ello se ubican las raíces de los problemas, tanto existentes como potenciales.

El análisis termodinámico es la base del mantenimiento de las plantas de generación eléctrica, sin embargo si bien los principios coinciden, existen diferencias en aspectos que van desde el nivel de profundidad, los modelos, las simplificaciones del problema hasta aspectos de la información disponible para el análisis. Dentro de las simplificaciones más comunes está el dividir el equipo, dependiendo del método de análisis por ejemplo, en secciones y etapas. En una turbina de impulso, una etapa es cada conjunto de álabes móviles previos a una extracción, mientras que, para turbinas de reacción, una etapa es cada fila de álabes. En la figura siguiente se ilustra un ejemplo de turbina con un par de extracciones, por lo que presenta dos etapas.

Figura 3‐18 Ejemplo de turbina con dos extracciones.

El diagnóstico de fallas en turbinas por medio del análisis termodinámico implica la comparación de la referencia creada a partir del estudio del ciclo termodinámico de la turbina, ajustando el cálculo con base tanto en los datos del fabricante con respecto a las condiciones operación del análisis, así como de algunos factores previamente estimados que puedan representar aspectos como el desgaste, ineficiencia mecánica, disminución del canal de flujo, y deficiencias en la generación de vapor. Esta referencia se cruza con un conjunto de datos obtenidos a partir de los valores en los instrumentos de diversas posiciones del equipo, sobre las variables físicas del flujo, principalmente de presión y temperatura.

La referencia se forma recalculando el flujo de vapor en expansión, desde la alta presión en calderas hasta su forma saturada en condensadores, para lo cual se analizan las distintas entalpías (los cambios térmicos que se llevan a cabo a presión constante) existentes en el ciclo, por medio del diagrama de Mollier, que es una representación de las propiedades del agua y vapor de agua, en el cual se emplea un sistema principal de coordenadas H‐S (Entalpía‐Entropía), como el que se ilustra en la figura siguiente (consultado del sitio http://www.engineeringtoolbox.com). En este gráfico es posible trazar las rectas para el proceso de expansión, permitiendo estimar gráficamente, si el comportamiento real tiene similitud con el estimado.

Todo este análisis puede evaluarse conforme a funciones lineales, pero resulta complejo por el número de variables y cálculos que pueden requerir, sin embargo si se llega a un nivel relativamente simplificado, que no consuma tiempos muy elevados (mayores a cinco minutos, que generen ineficiencias, por ejemplo), tales modelos pueden aprovecharse en la evaluación remota de elementos, tal y como lo ofrecen algunos servicios por parte de los fabricantes de turbomaquinaria.

Figura 3‐19 Ejemplo de diagrama de Mollier.

Otra forma de hacer cálculos es mediante las tablas de vapor, que describen las características del vapor, mediante lo cual es posible cruzar los valores para el flujo, dependiendo del estado del mismo, saturado o sobrecalentado. Las tablas de vapor existen para presión y temperatura.

3.6.2 Análisis de vibraciones Otras técnicas que permiten determinar el estado de los equipos rotativos, involucra

el estudio de señales de vibración. Tales diagnósticos pueden dividirse en genéricos y analíticos.

Los métodos genéricos se emplean para evaluar rápidamente la condición general de las máquinas con una cantidad limitada de mediciones globales o generales. Es comparable con la práctica médica de tomar temperatura, presión sanguínea y otros síntomas perceptibles desde el exterior del organismo.

A través de los métodos analíticos se evalúa la condición de componentes individuales de una máquina para identificar daños en el proceso que se presentan de manera incipiente, inclusive es posible determinar sus causas y adoptar medidas correctivas. La profundidad de diagnóstico crece, por tanto es equiparable a la aplicación médica de tomografías, ensayos radiográficos, ultrasonidos, etc.

En el caso de turbomaquinaria, se busca detectar la presencia de vibraciones mecánicas, que son las oscilaciones perceptibles y medibles en la superficie de las máquinas, elementos constructivos, sus funciones, etc. Así las vibraciones se detectan mediante la medición de señales, las cuales se procesan y se estudian en cuanto a frecuencia, forma de onda, velocidad, intensidad, periodicidad entre otros. Tal análisis determina el número y las características de las señales presentes en la señal compuesta.

Cada rotación implica muchas combinaciones de movimientos que es posible analizar mediante el estudio de vibraciones, sus velocidades y por ende sus frecuencias, así que un comportamiento errático produce señales y resonancias que pueden estudiarse, bien sea por análisis numérico puro o al graficarse. Igualmente, cada movimiento rotatorio describe algún modo de oscilación o rotación, los cuales pueden describir un comportamiento que se encuentre dentro de lo esperado o, caso opuesto, representar un estado de anormalidad, ya que cuando una estructura vibra, existen patrones de oscilación de acuerdo con alguna forma modal.

Sin embargo, dado que un sistema suele tener un número casi infinito de modos, la evaluación de formas modales es un trabajo complejo dentro del estudio de elementos rotativos, pues deben desarrollarse modelos matemáticos que representen las torsiones existentes en el rotor bajo un conjunto de condiciones, normalmente expresado por la velocidad de revoluciones. Dichas torsiones involucran los esfuerzos y la fatiga sobre los componentes, y dado que esta información permite calcular la vida útil remante, se presenta como parte de los servicios más avanzados en cuanto al análisis y diagnóstico de turbinas.

3.6.3 Análisis estructural Otra área de ingeniería mecánica que suele apoyar la detección de problemas en

turbomaquinaria es la mecánica estructural, en la cual, por medio de complicados modelos se identifican los puntos de fatiga y se elaboran modelos de fractura, mediante los cuales se realizan cálculos y simulaciones que pronostican las fallas del equipo originados por desgaste.

Las técnicas basadas en herramientas de cómputo que soportan este tipo de estudios, van encaminadas al desarrollo de modelos para el cálculo de elemento finito, en los cuales se aplican técnicas de diseño asistido por computadora (CAD), para modelar la pieza en estudio y se introducen las características de cada material. Tales modelos exigen mucho tiempo de modelado, consumen muchos recursos informáticos y suelen procesarse en tiempos relativamente largos, por lo que no suelen aplicarse para el diagnóstico automatizado. Como ejemplo, en la figura siguiente, se ilustra una pantalla de una aplicación de elemento finito para el análisis de un álabe.

Figura 3‐20 Pantalla de una aplicación de CAD y elemento finito.

Las mejoras en el hardware de computadoras han permitido la evolución del análisis estructural, en especial al combinar los modelos de elemento finito con el procesamiento de señales colectadas durante ciclos transitorios de arranques y paros. Este tipo de análisis permite diagnosticar y evitar fallas, al hacer una detección oportuna de los elementos que presentan niveles inadecuados de fatiga.

Al combinarse las técnicas de elemento finito con el análisis de vibraciones es posible realizar simulaciones para determinar los daños futuros, pieza por pieza o en toda la turbina.

3.6.4 Inspección con boroscopía De la misma forma que los estudios de laparoscopía, donde una cámara se introduce

en el cuerpo para determinar problemas en los órganos internos de un humano, así existen instrumentos similares en el área mecánica llamados boroscopios. Este tipo de equipo consiste en una cámara instalada en una estructura delgada a manera de cable, por medio del cual se ofrecen perspectivas del interior de turbocomponentes, permitiendo un análisis óptico sin necesidad de abrir el equipo.

La técnica, denominada boroscopía, se aplica introduciendo un boroscopio de cable flexible por un barreno o por un hueco de verificación cercano a la zona a analizar, permitiendo la visualización al otro lado del componente óptico del boroscopio. Dentro de los aspectos más importantes de la boroscopía es garantizar el tránsito adecuado de la cámara para obtener imágenes de todos los espacios que pudiesen presentar daño.

El boroscopio permite reconocer puntos conflictivos y puntos problemáticos de un modo muy sencillo y rápido y así poder tomar las medidas preventivas oportunas, sin necesidad de tener que realizar costosos desmontajes. Las siguientes figuras son fotos de la inspección por boroscopía de tuberías de agua y de una turbina industrial.

Figura 3‐21 Boroscopía de una turbina industrial.

Figura 3‐22 Boroscopía manual de tuberías.

En el caso de tuberías, dado que por los ángulos, las tonalidades de los materiales y la poca iluminación, se complica el poder distinguir con certeza algunos daños menores por corrosión, fracturas u otros desperfectos mayores. En estos casos, para garantizar el adecuado muestreo, se usa una técnica que emplea el rastreo de problemas por medio de un robot, el cual recorre la tubería, tomando muestreos del interior. En la figura se muestra un robot que recoge imágenes a través de la tubería.

Figura 3‐23 Robot para boroscopía en tuberías.

Mediante este tipo de equipo, es posible recopilar la información de cada segmento del tubo, proporcionando las bases para generar un modelo tridimensional de la tubería, con el cual se puede estudiar la presencia de fallas de diversos tipos, principalmente fracturas, corrosión y problemas de sellado. Los problemas así detectados suelen requerir de mantenimiento correctivo en cuanto a soldadura, sustitución de segmentos de tubo o la aplicación de sellos y adhesivos.

Este proceso de detección es muy lento por la naturaleza del robot, sin embargo elimina la incertidumbre sobre la ubicación de cada problema.

3.6.5 Estudio por imágenes Una técnica adecuada para la detección de algunos problemas en turbomaquinaria,

principalmente en aquellas de mayores temperaturas tales como las turbinas de gas o algunas turbinas de vapor modernas, consiste en emplear cámaras especiales para plasmar mediante coloridas imágenes la presencia o ausencia de energía calórica (termografías). A continuación se ilustra un ejemplo de aplicación de termografías para el diagnóstico de fallas en chumaceras.

Figura 3‐24 Termografía para el diagnóstico de chumaceras.

La identificación de puntos que excedan los márgenes esperados de temperatura, sirve de diagnóstico al ubicar las zonas de más daño en la turbina, pues las fallas de máquinas y en plantas eléctricas pueden ser detectadas tempranamente por el aumento de las temperaturas. Por los atributos del fluido en la turbina de gas, los fabricantes incluyen el dato del tiempo entre mantenimientos mayores (por ejemplo 280 días), bajo condiciones medias de carga, acompañando de una tabla de referencia para traducir el desgaste con otras condiciones de operación, así que el análisis con termografías e imágenes generadas a partir de a información recolectada, permiten un ajuste más cercano del desgaste efectuado durante la operación.

Dentro de las herramientas más innovadoras, existen otras variantes del estudio por imágenes, que usan técnicas tales como: rayos X y variantes del ultrasonido, para obtener representaciones en dos y tres dimensiones (ecografías) para apoyar el análisis estructural y la detección de fracturas en álabes y carcasa en turbinas, todo esto mayormente como parte de los estudios fuera de línea. Como ejemplo, en la siguiente figura se ilustra una imagen empleada en el análisis de fractura en turbinas de gas.

Figura 3‐25 Análisis de fractura en turbinas de gas.

3.6.6 Estudio de lubricantes Para que la rotación sea adecuada, en cada soporte o chumacera debe existir un

lubricante (típicamente aceite) que evite el rozamiento y los problemas de fricción. Existen pruebas específicas para determinar el estado del lubricante, las cuales se enfocan en dos objetivos: por una parte buscan determinar la presencia de sedimentos, en particular metálicos en el aceite, lo que sería indicio de problemas de rozamiento y por otro lado determinar si el lubricante es adecuado para las condiciones de operación.

Las pruebas de lubricantes permiten detectar tempranamente problemas que suelen pasar por alto en el rotor, lo cual evita problemas más severos y muchos de los mantenimientos mayores anticipados. Mecánicamente se vigila la degradación del aceite, cuidando en los instrumentos que las temperaturas presentes en el lubricante permanezcan dentro del rango adecuado para operación, de la misma manera, mediante filtros se analiza la presencia de sedimentos que alteren al lubricante, y por último a través de muestreos regulares se realizan pruebas a fondo sobre propiedades físicas específicas como la viscosidad.

3.7 Métodos académicos de diagnóstico de turbinas El diagnóstico de turbinas con base en modelos termodinámicos consiste en ubicar las

fallas a cargas parciales, con base en el análisis termodinámico, principalmente en las etapas donde se inyecta directamente el vapor desde la caldera, es decir en las secciones de alta presión, como vapor sobresaturado y en la secciones de intermedia presión como vapor recalentado caliente.

El análisis termodinámico busca estudiar e identificar desviaciones en las condiciones de operación, que conlleven a establecer reglas, bajo las cuales se pueda manifestar la presencia de fallas. Tales reglas se fundamentan en las diferencias entre las estimaciones calculadas por medio del modelo termodinámico a partir de los valores nominales de operación, contra los cálculos a partir de los valores efectivos en la instrumentación del sistema.

La teoría termodinámica permite llegar a construir modelos para cualquier máquina, donde la experimentación permite ajustar tales modelos. Después de mucha experimentación en los laboratorios de diversos fabricantes, Kenneth C. Cotton condensó su experiencia de 55 años en el análisis de turbinas, creando el libro “Evaluating and Improving Steam Turbine Performance”, que hoy día sirve para como una de las referencias más sólidas para la operación de plantas con turbinas de vapor. En México, por ejemplo, sirve de fundamento para los métodos de análisis de turbinas de vapor de LAPEM.

Su importancia radica en los objetivos que logra, pues busca determinar los efectos de la operación de plantas generadoras sobre la eficiencia de la turbina, tasas de calor y potencia de salida. Además plantea técnicas de diagnóstico con base en el análisis termodinámico de la expansión del vapor para ubicar puntos de operación y tipos de daño, estudiando el deterioro y proponiendo la interpretación del diagnóstico con base en datos históricos.

A partir de todo lo anterior es posible resumirlo en una metodología que registra los problemas, documentándolos como datos estadísticos, los cuales se utilizan en futuros análisis. Tales análisis caracterizan la máquina para compararlos contra los datos que, si bien normalmente forman parte de los documentos que el fabricante otorga, pueden calcularse, ajustando las curvas de expansión del vapor con base en los valores recolectados durante la operación a diferentes cargas parciales, es decir para distintos niveles de carga de la turbina.

Los datos obtenidos de la caracterización de la turbina, permiten manifestar los efectos de los cambios en las condiciones de la turbina, refiriendo los resultados de prueba como diferencias con respecto del conjunto de referencias calculadas. Esto puede resumirse como un conjunto de reglas ante combinaciones de las diferencias de las variables, similar a lo que se presenta en la tabla siguiente. En esta tabla se representan los cambios en las variables de velocidad de flujo, presión en cuatro extracciones: 1) entrada (PT) y 2) salida de la primera etapa (P1ra), 3) entrada de vapor recalentado caliente

en la etapa de intermedia presión (PHRH) y 4) salida de baja presión (PLP), así como la eficiencia para las etapas de alta (HP) e intermedia presión (IP). Las condiciones detectan la presencia de fallas en la turbina, tales como: Erosión por partículas sólidas (SPE) en las secciones de alta e intermedia presión, depósitos de sales y desprendimiento de recubrimientos en álabes en las turbinas de alta e intermedia presión, depósitos de sales en álabes y ductos de vapor en alta presión, deformaciones en alta presión y depósitos y daños probables en baja presión. También aísla los casos de incremento de temperaturas de vapor de entrada y vapor recalentado caliente, ambos problemas típicos de calderas, sin embargo no localiza el problema, ya que depende del tipo y la configuración de la fuente de vapor.

Tabla 3‐3 Efecto de los cambios en condiciones, conforme a Cotton.

Condición Velocidad de flujo

PT P1ra PHRH PLP Eficiencia

HP Eficiencia

Incrementa TT ‐ ‐

Incrementa THRH ‐ ‐ ‐ ‐

Incrementa A1ra (SPE) HP TB

Incrementa AHRH(SPE) IP TB

‐ ‐ ‐ ‐

Disminuye A1ra (Depósitos y desprendimientos)

HP TB ‐

Disminuye AHRH (Depósitos y desprendimientos)

HP TB ‐ ‐ ‐ ‐

Disminuye A2da (Depósitos) HP TB

Incrementa A2da (Deformaciones)

HP TB ‐

Disminuye ALP (Depósitos y daños)

‐ ‐ ‐ ‐ ‐

Las diferencias con las referencias se manifiestan como operaciones de comparación, donde puede aumentar ( ), disminuir ( ), no cambiar ( ), o no importar (‐), para una condición.

Por otra parte, el método de Cotton se basa en datos históricos, fundamentalmente en calificar cada falla, catalogando cada caso. Con esta información, es posible realizar los

cálculos para estimar la eficiencia en cada sección, para posteriormente formular la ubicación de las condiciones de acuerdo a la tabla.

Los seminarios para entender el material de Cotton han llevado al desarrollo de diversas herramientas de software para obtener los parámetros, las opciones van desde programas para plataformas que resuelven modelos matemáticos como Excel, Matlab, Maple o EES, hasta aplicaciones independientes para el cálculo y visualización, tales como el software de evaluación de turbinas de vapor, eSTPE (Steam Turbine Performance Evaluation) de encotech, que realiza los cálculos para determinar la eficiencia de la máquina en función de las condiciones de operación, permite calcular entre otros datos, la fatiga y la eficiencia por etapas. La figura siguiente ilustra una de las pantallas de eSTPE.

Figura 3‐26 Pantalla de eSTPE.

Uno de los atributos principales del método de Cotton es la conciliación de parámetros o el ajuste de datos en función tanto de datos históricos como del régimen térmico de la máquina.

3.8 Método de diagnóstico de turbinas de vapor en línea del IIE Los clientes del IIE como la Comisión Federal de Electricidad (CFE) o Petróleos

Mexicanos (PEMEX), tienen grupos dedicados al mantenimiento de plantas. Como ejemplo, la CFE cuenta con el Laboratorio de Pruebas de Equipos y Materiales (LAPEM), el cual especifica muchos de los aspectos de mantenimiento para las plantas hidroeléctricas y termoeléctricas, además de verificar la calidad de los suministros fabricados en el extranjero y certificar la calibración de equipos de medición. Por esto, los servicios de diagnóstico solicitados suelen requerir de niveles elevados de exactitud, que mejoren la eficiencia de las técnicas empleadas por los grupos de mantenimiento de los clientes.

Dentro de las técnicas de análisis termodinámico, la evaluación del régimen térmico en la etapa de baja presión es lo más complejo, debido a los cálculos del vapor, que llega en un estado de vapor húmedo. La física de este tipo de vapor difiere, además de que la turbina de baja presión al ser de reacción, requiere consideraciones distintas, que permitan valorar el cambio de estado y las distintas transformaciones de energía. Por otra parte, para poder hacer mejores estimaciones, es preciso realizar una conciliación de parámetros, es decir recalcular los parámetros de referencia de acuerdo con registros de condiciones controladas para el equipo.

Por otra parte, dado que CFE ha requerido transparentar y simplificar sus procesos de adquisiciones, creó en 1995 la especificación técnica W1200‐01, para turbogeneradores de 160 y 350 MW. En dicho documento se detallan aspectos de estructura, conectividad, potencia, suministros de combustible, instrumentación y cimentación de los componentes de un turbogenerador de vapor, incluida obviamente la turbina. También se detallan los parámetros aceptados de operación para cada nivel de carga. Por lo minucioso de dicha especificación, es posible considerar tales datos para la construcción de modelos muy precisos del comportamiento esperado de la turbina. [CFE 1995]

De acuerdo a la experiencia del grupo de diagnóstico del IIE, y de manera similar a las técnicas de Cotton, para elevar la exactitud de los resultados, en lugar de emplear el cuerpo completo o la etapa completa, la turbina se subdivide en grupos de trabajo, que normalmente asocian un par de puntos de inspección.

Esta metodología se fundamenta en un esquema basado en modelos, en la cual se preparan dos conjuntos de datos, una línea de referencia (comportamiento esperado) y una línea de prueba actual (comportamiento real). Los parámetros para la obtención del balance térmico de referencia necesitan del ajuste o conciliación de parámetros e igualmente se concilian los datos del equipo. Para tales ajustes, así como la estimación de desviaciones se emplea un modelo matemático en el software EES (Engineering Equation Solver). Dicha herramienta fue desarrollada por universitarios para emplearse en los cursos de termodinámica y su principal característica es resolver problemas complejos que envuelvan regresiones lineales y no lineales, ecuaciones simultáneas no lineales, estudios de parámetros de diseño, optimización y graficación de propiedades termodinámicas.

El método del IIE sin embargo no es dependiente de ninguna herramienta, ya que sus modelos han sido desarrollados sobre distintas herramientas matemáticas de software, por ejemplo EES y Matlab.

A manera de algoritmo, el método puede ilustrarse de una forma resumida mediante la figura siguiente.

Figura 3‐27 Metodología propia del IIE

Resulta notable que la principal ventaja de este método es la detección de fallas en las secciones más complejas de analizar: intermedia y baja presión. Las complicaciones de la sección de intermedia presión se asocian al manejo de flujos de vapor recalentado y la descripción detallada de las extracciones intermedias del equipo. En la sección de baja presión se complica severamente la estimación al incluir las variantes de estado asociados a la física del fluido por efecto de la condensación. En tales casos la observación de algunas variaciones abre la sospecha de ciertas fallas que deben confirmarse repitiendo el proceso de comparación, con un conjunto distinto de variables a considerar. Así el proceso se vuelve iterativo en cuanto a hacer comparaciones con base en una comparación anterior.

3.9 Conclusiones del capítulo Las turbinas de vapor apoyan en la mayor parte de la generación eléctrica mundial, y

por la contaminación que implican, han requerido mejorar las técnicas que monitoreen su estado y detecten fallas. Existen diversas formas de analizar las fallas, entre ellas el análisis termodinámico, muy afín al diagnóstico basado en modelos.

El IIE posee una metodología de diagnóstico propia, que parte de las técnicas académicas, pero agrega la conciliación de parámetros, además de proponer con base en una experiencia comprobable, reglas para determinar la presencia de ciertas fallas en la turbina, aún en las secciones de intermedia y baja presión.

Diagnóstico Automático de Turbinas de Vapor en Línea Capítulo 4 Estado del arte del diagnóstico de turbinas de vapor

4 Capítulo 4

Capítulo 4 Estado del arte del diagnóstico de turbinas de vapor

Entendiendo, al estado del arte como el grado más alto de desarrollo de una arte o técnica en un momento en particular, definir el conjunto de fundamentos que resuman la actualidad del diagnóstico de turbinas de vapor es un punto arriesgado, pues por lo atractivo del tema y la extensa cantidad de foros relativos al tema es difícil mantenerse al día, sin embargo en un intento por poner un contexto, se abordan algunas investigaciones influyentes en los desarrollos actuales de diagnóstico automático de turbo‐componentes.

Agrupados por tendencias, se sintetizan las diversas investigaciones afines a este proyecto. Entre las investigaciones publicadas, se puede lograr un sin número de clasificaciones, pero para sintetizar el material, se ha optado por abordar los temas de: representación de sistemas, monitoreo de equipos, problemas de instrumentación, corrección de referencias y la automatización del proceso de diagnóstico. Además se aborda la combinación de enfoques, finalizando con las conclusiones del capítulo.

4.1 Naturaleza multidisciplinaría del diagnóstico Básicamente el problema de diagnóstico, como muchos de la inteligencia artificial,

involucra tanto el análisis de las soluciones del área de aplicación (medicina, electrónica, mecánica, etc.), como emplear las técnicas más adecuadas dentro de las ramas que permiten la automatización (ciencias computacionales, electrónica, etc.), por lo que los resultados del área de diagnóstico de turbinas están más bien dispersos entre diversas publicaciones y congresos.

Para documentarse en el tema de diagnóstico de turbinas de vapor más allá de la bibliografía especializada en termodinámica, si bien no es extraño encontrar publicaciones de interés general, o de áreas afines a las ciencias computacionales (IEEE EXPERT, por ejemplo), que tomen como caso de estudio algún tipo de turbina, lo más común y por lo general de contenido más detallado en cuanto al diagnóstico de turbinas, se encontrará en artículos de congresos y revistas de las asociaciones de ingenieros mecánicos más destacadas, tales como los congresos especializados de: IEEE, POWER‐GEN y ASME POWER; así como las publicaciones: Journal of Turbomachinery de ASME, IEEE Transactions y Turbomachinery International.

Igualmente, pese a que las turbinas de vapor tienen fundamentos maduros, sobre los cuales es poco común definir algo totalmente nuevo, es prudente observar los casos de éxito y fracaso al llevar a cabo diferentes estilos de diagnóstico. El número de experiencias descritas es muy elevado, pero es posible destacar algunas de ellas, en el entendido que se busca poner contexto con respecto al diagnóstico automático de turbinas de vapor.

El problema con el aspecto multidisciplinario del diagnóstico de turbinas, es que al igual que todo foro de investigación, las publicaciones al respecto se realizan desde puntos de vista que se enfocan en técnicas, herramientas y especialidades, generando información que puede pasar por alto detalles importantes desde otra óptica. Pese a ello, es posible discutir los aspectos más recurrentes en cuanto al diagnóstico de fallas en turbinas de vapor.

4.2 Representación de sistemas de diagnóstico de turbinas Si bien el almacenamiento de datos ha evolucionado en cuanto a los dispositivos

físicos, las técnicas enfocadas a la representación de objetos han tenido un efecto singular en los sistemas de diagnóstico, pues han hecho factible la implementación de algoritmos fundamentados en la semántica o contexto de las descripciones expresadas al representar los datos. Los avances al respecto incluyen múltiples artículos sobre representación semántica de elementos, lo cual se aplica en instrumentaciones que incluyen información de la unidad de generación, características del equipo, estampa de tiempo, etc.

En los modelos de diagnóstico basado en modelos, una de las tendencias, es seguir el principio de descripción de sistemas de Reiter, que emplean representaciones basados en lógica de predicados. La evaluación se convierte en tales casos en conformaciones de reglas que, para casos muy concretos, algunos autores han orientado a resolver como un problema de satisfactibilidad booleana. La principal asunción en este enfoque es limitar la descripción del sistema a la presencia o ausencia de propiedades y que la evaluación de las condiciones sean reglas sobre la existencia de alguna anormalidad. Otra variante del enfoque de Reiter es indicar la presencia de condiciones normales, detectando un índice de salud o afinidad a las condiciones normales.

Por otro lado, muchas publicaciones de ingeniería mecánica se concentran en enfoques estáticos en cuanto al sistema, abordando casos específicos, sobre los que se describen mejoras en el análisis. Por ejemplo, al proponer mejoras a los procesos de monitoreo de condiciones en turbinas, la implementación del sistema Tiger, de Intelligent Applications Ltd., para el diagnóstico de turbinas de gas empleando diagnóstico basado en modelos cualitativos, en los cuales, si bien se emplean técnicas innovadoras en cuanto a los métodos basado en reglas, la representación es estática, dificultando la implementación por ejemplo de turbinas de vapor.

La gran ventaja de los enfoques estáticos es que se restringe la incertidumbre y con ello se forman descripciones muy exactas y explícitas de los detalles de la falla, además de que se logra una mayor compenetración con el sistema que se analiza. En este aspecto es similar a los desarrollos de herramientas VSCORT por parte del IIE y la Universidad de Guanajuato, han llevado a la evaluación de unidades de generación, donde cada implementación requiere un amplio trabajo de caracterización y conciliación de parámetros, además de tiempo para ajustar las interfases de usuario de acuerdo con el sistema real.

Estratégicamente, algunos enfoques dinámicos de descripción de equipos, han destacado sobre los modelos rígidos, al lograr resultados similares en cuanto a la certeza del diagnóstico, compensando la generalidad de los detalles del diagnóstico, con la habilidad del sistema de sencillez para adaptar el análisis de equipos diferentes. Tal es el caso de los desarrollos con base en el lenguaje de diagnóstico LYDIA, en los cuales, aprovechando la flexibilidad de la descripción de los modelos matemáticos mediante un lenguaje, han explorado soluciones en circuitos digitales, sistemas financieros y optimización de componentes de software.

Idealmente la representación de un sistema debe aproximarse a las necesidades de la aplicación, sin embargo en algunos casos se observa que las soluciones pueden artificialmente adaptar un problema a la representación que requieran las herramientas de diagnóstico, principalmente el software. Por tanto, existen diversas publicaciones con respecto a la representación, tanto en el aspecto del modelado físico‐matemático del equipo, como del almacenamiento de datos, condiciones, reglas, así como las estructuras de procesamiento necesarias para la automatización del proceso.

4.3 Monitoreo de turbinas de vapor Como se menciono antes, las turbinas de vapor son empleadas en la generación de

energía tanto solas como en ciclos combinados, teniendo como punto común que su funcionamiento debe monitorearse por razones principalmente económicas para mejorar el aprovechamiento de los combustibles de la caldera.

En el caso del sistema Tiger, los registros nocturnos de monitoreo en la turbina de gas, de la planta Exxon Fife Ethylene ofrecen un valor extra a su utilidad desde 1992. Este sistema de monitoreo consta de tres partes: un shell de reglas de diagnóstico, un manejador de rutinas de chequeo y un módulo de verificación. Por su parte, en Corea del Sur, las plantas de generación emplean sistemas monitores que integran las señales en un esquema basado en redes bayesianas para el estudio de probables incidencias, mediante la aplicación de una proyección de eventos con base en los datos históricos de mantenimiento.

Tras de una marcada tendencia a principios de los 90’s por abandonar las investigaciones en la generación eléctrica basada en la combustión de combustibles fósiles, principalmente por no ofrecer mejoras en la eficiencia de las nuevas turbinas de vapor. Con los cambios mundiales sobre los requerimientos de las plantas con respecto a la emisión de contaminantes, han promovido la necesidad de la verificación exhaustiva de las condiciones y los problemas de operación en planta.

En este sentido, en tiempos recientes, la industria ha optado por integrar el monitoreo de estado a soluciones mayores, por ejemplo dentro de sistemas PI o incluso, dependiendo del nivel crítico de la información a monitorear, en módulos de diversos ERP.

Otra parte del mercado ha optado por la movilidad de los dispositivos de extracción de datos, generando aplicaciones para dispositivos similares a un organizador personal, pero con características industriales. Mediante estos dispositivos se puede calcular el estado del equipo en sitio, ilustrar al operador sobre las condiciones de riesgo o incluso sugerir acciones de control.

4.4 Problemas de instrumentación Algunas investigaciones se han centrado en la corrección de problemas por parte de la

instrumentación, donde la falla de los sensores, los problemas de conexión física de los instrumentos, el ruido ambiental, la pérdida de información durante el muestreo de señales, y los problemas derivado de la calibración. Estos problemas requieren tanto la incorporación de mecanismos de validación, tanto en hardware como software. En el hardware, multiplicando los sensores para validar las señales para aumentar así la disponibilidad y confiabilidad; otra opción es incorporar hardware que analice minimice los errores por picos o cambios muy rápidos. En el software, aplicando análisis de Fourier principalmente, para el manejo de señales, es posible detectar la presencia de patrones discordes con respecto de un patrón esperado para ciertas condiciones de operación, por ejemplo un arranque controlado. Mediante el estudio de estos patrones, existen soluciones de software que tratan las señales, corrigiendo algunos problemas de instrumentación, en especial: presencia de eco, ruido estático, retrazo en la señal y mezcla de señales.

Otro truco común que es posible encontrar en múltiples aplicaciones industriales es la presencia de artificios para rellenar datos faltantes en la señal, tales soluciones aplanan, interpolan, o introducen un valor por defecto, en caso de detectar la ausencia de señal en pequeños lapsos, de esta manera se evitan errores en otros módulos de control.

Si bien la eliminación de problemas es utópica, la redundancia de sensores y puntos de control puede tornarse crítica en términos de costo‐beneficio, por lo cual las estrategias de estimación y detección de condiciones irregulares en las mediciones es un tema constantemente abordado.

4.5 Corrección de referencias del fabricante Los fabricantes proveen información que puede resultar básica para la mayoría de las

técnicas de diagnóstico, en especial aquellas basadas en el análisis termodinámico, a parir de los cuales se derivan una multitud de herramientas de diagnóstico basado en modelos.

Dependiendo de los modelos matemáticos formulados, se obtiene la profundidad de diagnóstico. Normalmente a mayor profundidad de diagnóstico, mayor complejidad del sistema, por lo cual, las necesidades en cuanto a profundidad tienden a implicar una mayor complejidad en el sistema de diagnóstico. Con esto en mente, los modelos que incluyen la corrección de modelos del fabricante, permiten evitar diversos errores presentes en la construcción de sistemas, aproximando soluciones de diagnóstico basadas en modelos, con auto‐corrección de las bases para la diagnosis.

Los mecanismos de corrección típicamente emplean herramientas de aprendizaje automático para implementar la consolidación de nuevos datos que se convierten en una versión corregida de las referencias del fabricante.

La publicación de los resultados sobre el ajuste de referencias normalmente va asociada a casos específicos de equipo, condiciones extremas de operación o discrepancias con la especificación de control y seguridad.

4.6 Diagnosis automática de turbinas de vapor La reducción de costos, la simplificación de tareas y la eliminación de errores humanos

ha motivado la automatización de los procesos desde la revolución industrial hasta nuestros días. Si bien todas las justificaciones anteriores son válidas, el diagnóstico clínico ofrece muchos ejemplos sobre los riesgos implícitos al confiar en una diagnosis automatizada. Por ejemplo, en algunos centros de donación de sangre en Estados Unidos, existe la renuencia de aplicar exámenes automáticos de sangre, mismos que podrían pasar por alto la presencia de algunas formas de VIH, exponiendo la salud de quienes reciben esta sangre, ventaja natural del método manual; Sin embargo mientras que un humano puede ofrecer una cantidad de pruebas de sangre de acuerdo a sus habilidades y experiencia, el proceso automático tiene capacidades 10 o 20 veces mayores.

La automatización del proceso de diagnóstico ha demostrado sus ventajas en las implementaciones de diversos sistemas en el mundo, en ellos, el sistema Tiger, el cual monitorea daños sin necesidad de supervisión, tiene varias características deseables en cualquier mecanismo de monitoreo, como son: velocidad, verificación y fidelidad.

Igualmente los desarrollos creados por el IIE en cuanto a la detección de fallas en plantas termoeléctricas mexicanas, han tenido distintos caminos, entre ellos el uso de un enfoque con un conjunto de modelos probabilísticos casuales, con base en redes Bayesianas, implementado en las plantas de Dos Bocas y Gómez Palacio. Bajo este enfoque, se va conformando una red de probables fallas. Con este esquema se determina la presencia de fallas, involucrando el aislamiento de causas y estimando los efectos.

Otras técnicas que han disfrutado de éxito en el diagnóstico de turbocomponentes, en especial desde un enfoque más eléctrico que mecánico, son las redes de Petri, el cual, frente a otros métodos, el esquema ofrece mayor facilidad para su implementación, rapidez de adaptación ante cambios de zona de operación y buena robustez.

Para implementar el sistema de diagnóstico se sigue un método que consiste en obtener un modelo de causalidad del elemento a diagnosticar, utilizando una red de Petri denominada red hacia adelante. Una vez obtenido este modelo, se invierte el sentido de los arcos de conexión, obteniéndose una red de Petri hacia atrás. Con base en la experiencia de los operadores se determinan los umbrales de detección y aplicando reglas de disparo de las transiciones de la red, se producen señales que cambian el estado de la red de Petri y que se interpretan como firmas de las fallas consideradas. [LO 1997], [SUAREZ 2007]

En este y otros trabajos de investigación previos, realizados en el IIE, se han explorado con éxito las técnicas de redes neuronales y la lógica difusa para el diagnóstico de fallas [RUZ 2005], [AQUINO, H., 2005]. Cada una de estas aplicaciones ha permitido obtener resultados muy dispersos en cuanto a la robustez, ya que si bien cada caso ha visto éxito,

las técnicas ofrecen mejor desempeño en ciertas condiciones, así mientras los resultados de un método son satisfactorios un conjunto de información, mientras que en otro conjunto no son concluyentes; pero los resultados de otra técnica son buenos en este segundo conjunto, pero no tan buenos en el primero.

Así como se ilustra a continuación, mientras que puede haber condiciones que favorecen a una técnica, no es absoluta la ventaja que puede presentar contra otras técnicas.

Figura 4‐1 Desempeño de las técnicas de diagnóstico

4.7 Combinación de enfoques Las técnicas de monitoreo de señales, integradas a la corrección de problemas de

instrumentación atrae muchos artículos de áreas de control e instrumentación que suelen ofrecer mejoras para casos muy específicos de aplicación.

Por su parte las investigaciones que combinan la representación de los elementos con la corrección de datos del fabricante han manifestado éxito en el aislamiento de fallas en sistemas industriales como evaporadores. Un caso especial de ello ha llevado a la detección de problemas en el control de los procesos industriales para obtener concentrado de cítricos, implementando técnicas de reingeniería de procesos.

Por último, los fabricantes de turbinas en el mundo continúan ampliando sus servicios en línea para el monitoreo y detección de fallas en componentes. Aquí existen una gama de técnicas manuales de detección de fallas que van en proceso de mejora y su posible automatización. Algunas técnicas dependen completamente de la habilidad humana conjugada del uso de visión, cálculo, memoria, experiencia y conocimientos. Los sistemas expertos que pretendan emular tal combinación deben ser o altamente especializados o de una complejidad inmensa, pues no consiste solo en diferenciar formas en tres dimensiones, sino tener la capacidad de interpretar objetos en movimiento.

Por otra parte los patrones existentes entre fallas son tan similares y tan distintos que pudiesen pasar desapercibidos si se emplea visión, pero ser muy detectables mediante ecografías.

Figura 4‐2 Detección de fallas en generadores.

En la figura anterior se señala que la detección manual de fallas en generadores requiere de la inspección visual de los componentes, más un sin fin de pruebas para garantizar el buen funcionamiento. De entre las pruebas, algunas son complicadas de transferir a un proceso automatizado, por ende la complejidad crece y requiere de más técnicas para su éxito.

4.8 Conclusiones del capítulo Los sistemas mecánicos requieren del manejo de señales para el control y la

estimación de su estado, al tiempo que existen proyectos para corregir la información de referencia de los fabricantes de turbinas, lograr una mejor representación de sistemas.

Al tiempo que se observa una tendencia a integrar enfoques que han tenido cierto éxito, donde se tiene que en algunos casos específicos es mejor una técnica que otra, de donde se infiere que un resultado más robusto puede ser alcanzado, mediante la implementación de un esquema de diagnóstico basado en diferentes métodos complementarios, lo cual justifica la necesidad de explorar las propiedades de nuevas técnicas en el campo de diagnóstico de fallas.

Diagnóstico Automático de Turbinas de Vapor en Línea Capítulo 5 Diseño del sistema

5 Capítulo 5

Capítulo 5 Diseño del sistema

Dentro de cualquiera de las metodologías de desarrollo de software, el diseño es la actividad que le da forma y sentido a la solución. En esta tarea se aplican distintas técnicas y principios, para definir las características del producto final y de cada uno de los elementos que lo componen.

La elaboración de un sistema que pueda cubrir los parámetros de la solución planteada, inducen al diseño, pues “es el primer paso en la fase de desarrollo de cualquier producto o sistema de ingeniería” [PRESSMAN98], y consiste en “aplicar distintas técnicas y principios con el propósito de definir un dispositivo, un proceso o un sistema con suficiente detalle como para permitir su realización física” [TAYLOR59].

Así pues se detalla la infraestructura necesaria para realizar un diagnóstico remoto flexible, cumpliendo los puntos definidos en el alcance del proyecto. Se finaliza recapitulando los parámetros principales y describiendo el resto del proceso.

5.1 Elementos de una infraestructura de diagnóstico La automatización de la diagnosis depende de adoptar diversas suposiciones y por ello

genera una incertidumbre difícil de manejar. Para manejar esta incertidumbre y disminuir los patrones de dispersión, es necesario enfocar los esfuerzos del diseño en concebir un conjunto argumentado de suposiciones.

Por otra parte siempre existen parámetros más deseables para la solución, tales como son: la robustez, es decir la capacidad de funcionar ante diversos escenarios adversos, relativamente alejados del diseño; la flexibilidad, que consiste en operar en diversas situaciones y la adaptabilidad, que implica la propiedad de que con pocos cambios afronte nuevas funciones.

Para lograr tales parámetros, el software debe producirse siguiendo algún modelo de desarrollo: clásico o modelo en cascada, 4GL, por prototipos, en espiral, incremental, etc. Cada uno de ellos tiene sus ventajas, por ejemplo en el caso del modelo clásico, la simplicidad y claridad que ofrece lo hacen uno de los modelos más populares. Al desarrollar por prototipos si bien puede representar más trabajo, otorga la posibilidad de obtener correctamente los requerimientos del cliente o usuario. El modelo en espiral parte del concepto de versión, siempre pasando por una comunicación con el cliente, un estudio de factibilidad, un proceso de ingeniería: análisis, diseño, construcción rápida y pruebas. Todos los modelos pueden combinarse o hacerse ciertas adaptaciones dependiendo del tamaño del equipo de desarrollo, la claridad de la especificación y las herramientas de desarrollo disponibles. Así, como se muestra a continuación, mientras que el proceso clásico es idóneamente de una sola dirección, existen variantes que incluyen opción de regreso a corregir actividades previas. Tal modelo es muy perfeccionista y corre el riesgo de alargar las

Figura 5‐1 Modelo en cascada con correcciones

Otro aspecto son los resultados esperados. Un producto definido de manera ambiciosa generará un sentimiento de frustración, mientras que un producto acotado en demasía, tiende a reducir el impacto y el sentido de la investigación.

5.2 Análisis de la problemática técnica Dado que los problemas de la automatización del diagnóstico pueden volverse

insalvables sin la acotación adecuada, para obtener una solución, se busco concentrar esfuerzos sobre un conjunto de enfoques prioritarios para situar la solución.

La figura siguiente ilustra conceptualmente un análisis del estado original y el estado deseado bajo el cual se enfoca el desarrollo de la solución planteada. El estado original o Estado ‘A’, sintetiza las situaciones existentes, siendo dos las principales: repetición de tareas durante la implementación de sistemas de monitoreo de equipos y la potencial reducción del número de visitas a sitio para realizar diagnóstico de turbinas, creando la capacidad en el tiempo para mejorar los procesos de diagnóstico.

Figura 5‐2 Estado 'A' contra Estado 'B'

De acuerdo con este gráfico, la conexión de datos es un requisito para lograr la simplificación del proceso de diagnóstico, convirtiéndolo en una evaluación remota. Para enmarcar el diseño de los elementos de la solución que permita la implementación de diagnóstico remoto de turbomaquinaria, se ha partido del siguiente conjunto de objetivos particulares:

a) Estudiar y analizar los métodos de descripción de sistemas bajo el enfoque de diagnóstico.

b) Seleccionar un método flexible para descripción de sistemas a diagnosticar, adecuado en cuanto a las características tanto de la adaptabilidad del método de descripción del sistema, como de la reusabilidad de los componentes de software, para

consolidar elementos mecánicos, tomando como el caso base las turbinas de vapor, e incluso otros dominios de diagnóstico.

c) Realizar la descripción del sistema del caso base de estudio (turbina de vapor) y un caso alterno de soporte.

d) Explorar los mecanismos de representación del comportamiento esperado de un sistema, a partir de la descripción del sistema y un conjunto de parámetros, tales como las condiciones de operación y algunas variables ambientales, que intervengan durante el proceso de diagnóstico.

e) Seleccionar el mecanismo de representación del comportamiento esperado, con base en el método de descripción seleccionado.

f) Seleccionar un modelo dinámico adecuado para la definición operativa de los parámetros descriptivos (de las condiciones de operación y algunas variables ambientales) del comportamiento esperado de un sistema a diagnosticar, con base en el mecanismo de representación del comportamiento esperado.

g) Describir el comportamiento esperado para un conjunto de datos de prueba, tanto para el caso base (turbina de vapor), como para un caso alterno de soporte.

h) Evaluar las técnicas de preparación de datos para el diagnóstico, enfocado a obtener un mecanismo de procesamiento de señales, que transforme los datos recolectados del sistema en línea, en una representación del comportamiento actual del sistema estudiado.

i) Definir el mecanismo de preparación de datos para distintas fuentes de recolección de datos, adecuado para la generación del modelo de comportamiento actual de un sistema, enfocado principalmente a sistemas mecánicos.

j) Describir el comportamiento actual de diversas señales monitoreadas por varias fuentes desde sistemas en línea, verificando la validez del modelo de comportamiento actual.

k) Explorar las diversas técnicas para formular el diagnóstico con base en los modelos de comportamiento esperado y actual.

l) Seleccionar la técnica más adecuada para la diagnosis automática, tomando en cuenta los modelos de comportamiento antes seleccionados.

m) Implementar y evaluar la automatización del proceso de diagnóstico seleccionado.

n) Evaluar las técnicas de validación, evaluación y retroalimentación inteligente de procesos automatizados semejantes al mecanismo de diagnóstico seleccionado.

o) Definir un modelo de registro y validación de la diagnosis, enfocado a un mecanismo de mejora inteligente que incorpore la validación de los resultados del diagnóstico.

p) Explorar las arquitecturas, herramientas y modelos para implementar las interfases de usuario adecuadas al sistema de diagnóstico definido, cuidando los atributos de calidad, tanto de la adaptabilidad del método de descripción del sistema, como de la reusabilidad de los componentes de software.

q) Evaluar las características globales de la solución implementada.

Cada uno de estos incisos coincide con las actividades del trabajo de tesis, representando retos técnicos muy relevantes en especial el manejo de piezas flexibles que incluso permiten la representación de otros sistemas, incluso ajenos al área de turbinas.

5.3 Diseño de la infraestructura de diagnóstico remoto La selección y acomodo de los elementos de una solución y su integración, conforman

la arquitectura del sistema, toda vez que representa la conformación de la solución es crítica para analizar aspectos como complejidad, factibilidad y la solidez de la solución.

Para tal selección se probaron distintas opciones, como el uso de tomar como base un sistema experto vacío (Shell), sin embargo, pese su modelado flexible, este tipo de sistemas limitan la implementación de interfaces de usuario y muy en especial en el caso de turbinas de vapor, se requiere incorporar información gráfica de la turbina y resulta preferible un modelo más matemático que lógico.

Se hicieron igualmente intentos por adoptar la plataforma del lenguaje de diagnóstico LYDIA, el cual ofrece la implementación de modelos lógico‐matemáticos. Este software permite generar librerías y aplicaciones que si bien no son del todo adecuadas para soluciones Web, es posible llamarlas mediante un servidor de aplicaciones. La gran desventaja es que pese a que los responsables de su desarrollo ya tienen contemplado generar versiones con modelos dinámicos, hasta febrero, su modelado es estático.

Figura 5‐3 Selección de opciones.

Finalmente, se ha escogido emplear el desarrollo de meta‐modelos desarrollados a la medida de este desarrollo, cuya principal ventaja es la flexibilidad en cuanto a la representación de sistemas y corre el riesgo de emplear más tiempo de desarrollo.

Así, la solución a implementar cuenta con tres grandes piezas: una herramienta para la descripción de sistemas, un servicio Web para la ejecución de procesos de diagnóstico y una base de datos (BD) con los metamodelos adecuados para la aplicación.

Como se ilustra a continuación, se seleccionó como lenguaje de desarrollo C# (C‐ Sharp), y MySQL como base de datos. Ambas opciones se tomaron pensando en la potencial migración entre sistemas operativos, principalmente ambientes Microsoft Windows y Linux.

Figura 5‐4 Diagrama conceptual de la arquitectura de la solución.

De la misma forma, es posible hacer un enfoque por módulos, bajo el cual la herramienta de descripción de sistemas cuenta con cinco módulos, conformados por: tres editores (sistema, programa LDX y conjuntos de reglas), una interfaz para manejar los parámetros para las fuentes de datos, además de un módulo para la configuración general. Por parte de los servicios Web, existen dos módulos: presentación de datos y ejecución de procesos de diagnóstico.

Figura 5‐5 Diagrama modular de la solución

El proceso de diagnóstico consiste en 8 etapas, señalizadas en el siguiente diagrama.

Figura 5‐6 Alcance del sistema de diagnóstico

5.4 Meta‐modelos Las bases de datos relacionales constituyen el almacenamiento de datos más usado en

nuestros días, para su correcto funcionamiento, los sistemas manejadores de base de datos (DBMS) requieren organizar la información en entidades o tablas, los cuales se describen a través del uso de campos o atributos. Cada campo tiene definido un conjunto de propiedades que aportan información adicional, bien sea para validar, presentar, etc. Tal información extra, se considera como el modelo del modelo de datos, o simplificado, meta‐modelo, y permite agregar funcionalidades para el manejo de la información.

Sin embargo aunque este fue el enfoque inicial y el más empleado de los meta‐modelos, existen otros usos del meta‐modelado; es posible almacenar la información de las piezas de la solución, generando un diseño basado en meta‐modelos, tal y como lo aprovechan las soluciones empresariales modernas, en las cuales se tienen interfases de usuario meta‐modeladas, para las cuales se almacena la configuración de detalles como estilos, formatos, roles, permisos, vistas y procesos.

Figura 5‐7 Base de datos meta‐modelada

De esta manera, es posible mencionar como principio que un metamodelo permite la representación de información adicional sobre los elementos de una solución, desde asuntos relacionados con el manejo de la interfaz de usuario, seguridad, validación de datos, o control de procesamiento.

Así los metamodelos empleados permiten describir el almacenamiento, la seguridad tanto en Web como en las herramientas de descripción y los detalles tanto de definición como ejecución de los procesos de diagnóstico.

5.5 Diseño de los elementos de definición del sistema Los sistemas mecánicos a explorar deben poder diferenciarse por un conjunto

relativamente pequeño de datos, básicamente nombre, descripción, ubicación, imagen a emplear como fondo, a la vez que almacenan los datos de los componentes, que es donde los sistemas realmente varían. Cada componente debe contener tanto datos del formato que tiene como de la representación que aplica, es decir su posición en el gráfico y detalles como sus unidades de medición, identificador y valor por omisión. Todos estos datos se deben introducir en etapas:

a) Primero se capturan los datos generales del sistema.

b) Se introducen los componentes, mencionando su posición.

c) Tras de eso, al almacenar, se ejecuta un procedimiento almacenado en la base de datos para conformar las tablas y vistas de trabajo que contendrán la información durante el proceso de diagnóstico.

Mediante estos pasos, se tiene definida la información del sistema en meta‐modelos.

5.6 Diseño de los elementos para el comportamiento esperado Tanto el conjunto de datos que integran el comportamiento esperado como la

información del comportamiento real requieren de un procesamiento de la información del equipo. Normalmente esto es la parte estática de las implementaciones de sistemas de diagnóstico.

En el caso del sistema, se debe introducir los datos de referencia, con base en las tablas de trabajo ya generadas durante la definición del sistema. Con base en estos datos es posible la generación del comportamiento esperado, que requiere de un proceso matemático de cálculo, para el cual había varias opciones. Se puede emplear un paquete especializado en cálculo, tal como MatLab o Maple, una herramienta más visual de diseño de algoritmos, estilo LabView o aprovechar las capacidades del sistema manejador de base de datos para procesar instrucciones en SQL.

En el IIE ya se trabaja en transformar los cálculos hacia herramientas como MatLab con algunas dificultades para la integración y la eficiencia del procesamiento cuando se integra a soluciones con interfaces de usuario complejas. Aprovechando el procesamiento veloz de los servidores de base de datos, se busca hacer un procesamiento remoto de tales trabajos.

En cualquier caso, los elementos pueden asociarse a fórmulas, datos recolectados o a salidas tanto del comportamiento esperado como del calculado. Este paso podemos mencionarlo como simbolización, y es mediante el cual se definen los componentes del modelo del sistema. Para su captura se deben incorporar formularios denominados editores, en los cuales se maneje la información de sistemas, programas LDX (lenguaje de diagnóstico) y conjuntos de reglas. Los diseños se detallan en formato UML en el anexo B.

5.7 Diseño de los elementos para la preparación del diagnóstico Para poder manipular los datos de la máquina, es necesario transformarlos mediante

un proceso que involucra el cálculo mecánico de los elementos físicos hasta reducirse a un conjunto comparable contra el comportamiento esperado. En esencia es lo mismo que el cálculo para el comportamiento esperado, salvo que además incluye la eliminación de huecos y otros problemas.

Tales programas como se comentaba parten de las funciones que incluye el manejador de MySQL y se extienden mediante librerías en C.

Por tanto no es necesariamente una gramática lo que aplica, con un parser, sino la ejecución de una verificación de SQL válido.

Tal lenguaje es denominado LDX y posee funciones de picos, promedios, sumatorias, eliminación de nulos, eliminación de picos, comparación contra tablas, declaración de constantes y tablas temporales, y sustitución de valores.

Tabla 5‐1 Conjunto de instrucciones de LDX

Instrucción Parámetrosprom valores peak valores, corte, sustituirmax valoresmin valorescount valorescount_a valores, acount_b valores, a, bcount_c valores, a, b, ctable_v valorestable_h valoresconstant valorsum valorestable_xy valoresfilter valoresnulls valor, nuloFor contador, inicio, finIf condiciónwhile condiciónstopjump línea

LDX es uno de los aportes mayores en esta investigación, al incorporar flexibilidad en el manejo de señales y el resto de la preparación de datos previo a la ejecución del diagnóstico.

La interfaz de usuario para la captura de programas de LDX requiere de un editor, con realce de sintaxis. La depuración de programas consiste en definir los datos de prueba e ir ejecutando las instrucciones hasta localizar un error. Los errores detectan la ubicación y una descripción.

5.8 Diseño de los elementos para efectuar el diagnóstico El proceso para emitir un diagnóstico del estado que presenta una turbina, requiere

identificar patrones por reglas, sin embargo dado que en las reglas puede afectar o no el valor de una variable, las opciones son la evaluación variable por variable, regla por regla o la conformación de grupos o clusters.

Intentando clarificar, se recurre a un ejemplo en el cual existe un sistema descrito por conjunto de cinco variables, (A, B, C, D, E). En tal caso, una regla es la combinación de los valores (Ai, Bi, Ci, Di, Ei), correspondientes a las operaciones de comparación: incremento ( ), decremento ( ) y equivalencia ( ). Adicionalmente se agrega el valor ( ) que indica que esa variable no infiere en la regla.

Así, los siguientes son ejemplos de reglas válidas:

a) { , , , , )

Esta reglas, no incluye más casos que { , , , , ).

b) { , , , , }

El operador , incluido al final de la segunda regla hace válidos:

{ , , , , }, { , , , , }, y { , , , , }.

c) { , , , , }

Donde son válidos:

{ , , , , }, { , , , , }, { , , , , }, { , , , , }, { , , , , }, { , , , , }, { , , , , }, { , , , , } y { , , , , }

Así se transforma el problema, reduciendolo a un algoritmo de búsqueda por grupos, se conforman los siguientes clusters: {11111‐11111}, {11231‐11233}, {11211‐11233}, asociando cada uno a una regla. Igualmente pueden generarse más de un cluster por regla.

5.9 Diseño de los elementos para evaluar el diagnóstico Como todo proceso automatizado, se requiere validar que su operación sea correcta

para identificar los casos correctos e incorrectos, a fin de ubicar el grado de efectividad del diagnóstico emitido. Tal validación está implementada como una evaluación asistida, es decir requiere apoyo por parte del usuario. Para tal parte se puede evaluar de dos maneras: tras la ejecución se incluye una casilla de verificación en el diagnóstico, lo que permite proceder con el proceso de validación del modelo de diagnóstico.

Así, para cada corrida, se ingresa el valor de verdadero o falso. Con base en las fallas emitidas en el reporte, se asocia un acierto o fallo a las reglas que dan pie a tal valor. Tras de esto se evalúa el registro de cada combinación evaluada, originando una calificación o probabilidad de acierto para cada conjunto de reglas.

Opcionalmente se debe agregar la generación automática de reglas de diagnóstico candidatas, es decir, generar con base en el siguiente algoritmo genético, un conjunto de reglas que pudiese mejorar el proceso.

1) Con base en evaluaciones anteriores, cada conjunto de reglas pre‐existente, asignar una ponderación del número de aciertos de cada conjunto y las ocasiones en que ha procedido.

2) Seleccionar como candidatos aquellos conjuntos con baja puntuación.

3) Procesar una mutación de tales candidatos, modificando los operadores en dichas reglas candidatas.

4) Con base en la efectividad histórica del actual conjunto de reglas, generar un subconjunto adicional de reglas. Esto es, si el conjunto ha sido completamente efectivo, no se requieren nuevos elementos, si ha sido completamente inefectivo, se requieren tantos elementos nuevos como elementos tenga el conjunto actual de reglas.

5) Consolidar un nuevo conjunto de reglas, a partir de las reglas vigentes, las mutaciones y en su caso el conjunto de reglas nuevas, sustituyendo las reglas que fueron marcadas como candidatas por sus mutaciones y anexando el subconjunto adicional de reglas nuevas.

6) Integrado el nuevo conjunto, se evalúa la eficiencia, efectuando el último proceso de análisis con

Los diseños se detallan en formato UML en el anexo B.

5.10 Proceso de diagnosis Mediante el diagrama de flujo de datos (DFD) ilustrado den la siguiente figura, se

representa el proceso completo de diagnóstico.

Figura 5‐8 Proceso de diagnóstico

El paso inicial es el modelado del sistema, con base en la información provista por el usuario, para generar la descripción del sistema, los datos de referencia y las reglas.

Posteriormente se debe realizar una configuración, que aporta los datos de la conexión de datos. Tras de ello es posible proceder a la recolección de datos, que procesan las señales directas del sistema, hasta dejarlas listas para la preparación de los datos reales. La preparación transforma los datos en un conjunto de datos tratados para su uso en las tareas de cálculo.

Hasta aquí, el proceso ha preparado los datos, mayoritariamente capturando la información en metamodelos, y ejecutando rutinas de LDX para su ajuste. Pero a continuación se procesan dos acciones de cálculo, de las cuales se desprenden los comportamientos esperado y real.

El siguiente paso es el análisis, con base en una evaluación por clusters, se termina si existe un grupo de síntomas que caracterice la presencia de fallas.

Posterior a este análisis, se evalúa la validez de las reglas a través de un algoritmo genético que formule la integración de nuevas reglas, produciendo un diagnóstico validado y un conjunto modificado de reglas.

5.11 Conclusiones del capítulo La infraestructura se divide en tres piezas: herramienta de descripción de sistemas,

base de datos con metamodelos y servicios Web para diagnóstico. La herramienta de descripción de sistemas debe editar la información y almacenarla en los metamodelos de la BD, mientras los servicios Web procesan la solicitud de ejecuciones de diagnóstico con base en los datos almacenados en la BD.

Para brindar flexibilidad, la solución usa un lenguaje de diagnóstico LDX, que permite el procesamiento de datos normalmente un archivo con datos recolectados desde la turbina. Existe un conjunto de reglas el cual debe editarse, para definir la estrategia de diagnóstico.

Diagnóstico Automático de Turbinas de Vapor en Línea Capítulo 6 Pruebas al sistema

6 Capítulo 6

Capítulo 6 Pruebas al sistema

La elaboración de un sistema involucra diversas evaluaciones o pruebas para validar que tal solución cubra el conjunto de parámetros de calidad. Por ello, se exploran las características de la solución implementada.

En este capítulo se presentan los resultados, exponiendo algunas tablas comparativas entre los efectos obtenidos para los modelo del IIE y Cotton. Así se busca encontrar argumentos para validar la hipótesis de esta investigación, al comparar tanto la operación presentada en el sistema como la opinión de especialistas en modelado y desarrollo de software de diagnóstico de turbocomponentes.

6.1 Incorporación de datos Para la prueba de cualquier software, es necesario seleccionar e incorporar la

información para garantizar que el producto opera correctamente. En algunos casos es necesario exponerlo ante una sobrecarga de solicitudes, o de inserción de datos, para evaluar los límites de operación ante stress.

Para la infraestructura desarrollada, se diseñaron las pruebas en dos etapas: pruebas de funcionalidad general y pruebas de flexibilidad. Para ambos casos se emplearon doce conjuntos de datos, conformados por información real de corridas y simulaciones, conformando una muestra con casos que incluyen varias fallas a detectar y un par de casos sin falla a manera de control.

Tabla 6‐1 Conjuntos de datos de prueba

Caso Condición Ubicación Causa posible

1 Funcionamiento normal

2 Incremento en temperatura de vapor principal

Caldera Caldera desbocada

3 Disminución de área Primera etapa, sección de Alta presión

Depósitos y desprendimientos

4 Incremento en área Primera etapa, sección de Alta presión

Posible presencia de SPE

5 Incremento en área Sección de Intermedia presión Posible presencia de SPE

6 Disminución de área Segunda etapa, sección de Alta presión

Depósitos

7 Disminución de área Sección de Alta presión Depósitos y desprendimientos

8 Incremento en área Primera etapa, sección de Alta presión

Posible presencia de SPE

9 Incremento en temperatura de vapor recalentado caliente

Caldera

10 Funcionamiento normal

11 Incremento de área Segunda etapa, Sección de Alta presión

Deformaciones

12 Disminución de área Sección de Baja presión Depósitos y daños

En cuanto a las pruebas de flexibilidad, se modelaron el método del IIE como base y se implementó la evaluación de acuerdo a K.C. Cotton. Ambos casos se contrastaron con base en el conjunto de datos antes mencionado, y evaluando la complejidad del cambio de modelo con base en el tiempo para implementarlo y el número de cambios efectuados.

6.2 Pruebas al sistema El sistema requiere de un nivel de seguridad, por lo cual se aplicó tanto en la

herramienta de descripción como en la aplicación Web, una interfaz para solicitar la información de acceso, tal y como se ilustra en la siguiente figura, tal acceso funcionó invariablemente sin mayores problemas.

Figura 6‐1 Pantalla de acceso a la herramienta de descripción de sistemas

Tras de acceder, se presenta un formulario de múltiples documentos, en el cual se invocan los editores de sistemas, conjuntos de reglas y programas LDX. Todos ellos operan bajo el principio de MDI (interfaz de múltiples documentos), por ende pueden existir diversas instancias simultaneas de ventanas bien sea de conjuntos de reglas, programas LDX o descripción de sistemas.

Para probar bajo stress esta condición, se probó bajo condiciones de suficiente memoria, baja memoria y mínima memoria (2 GB, 500 MB y 250 MB), con 40, 25 y 10 ventanas simultaneas. Se obtuvo la siguiente respuesta ante tal condición:

Tabla 6‐2 Pruebas de stress a la herramienta de descripción

Ventanas simultaneas

40 25 10

2 GB Sin problemas Sin problemas Sin problemas

500 MB Edita correctamente programas LDX, pero tarda en editar sistemas y conjuntos de reglas

Sin problemas Sin problemas

250 MB Sufre retrasos de hasta 40 segundos por operación

Edita correctamente tanto programas LDX como sistemas, pero tarda en reaccionar al editar conjuntos de reglas

Sin problemas

Tales pruebas consistieron en crear el sistema, editar una descripción genérica “Descripción del sistema número “, junto con un consecutivo de la prueba, además de asociar una docena de componentes, denominados “componente” y una letra de la “A” a

la “L”. Posteriormente se almacenaba con el nombre “sistema” y el consecutivo, se cerraba y se abría nuevamente, repitiendo hasta obtener el número de sistemas considerados en la prueba.

Posteriormente se cerraba el sistema, se reiniciaba el equipo y se procedía a ir generando los conjuntos de reglas asociados, introduciendo 12 reglas, de incremento en cada una de los componentes.

Para los programas se selecciono un código ejemplo que se copio en todos los programas y se editaron diez cambios mínimo en el mismo por prueba.

Figura 6‐2 Pantalla principal

Este sistema conllevó integrar en la interfaz gráfica el manejo de los metamodelos de seguridad, para controlar el acceso y los permisos de edición y ejecución. El protocolo de prueba solo contempló la restricción y acceso según los permisos de cinco usuarios, cada uno con distintos permisos, sin encontrar incidencia de fallas al respecto, evitando la edición de elementos y la restricción de acceso en el resto.

Para evaluar la sencillez de manejo, se consultó con un grupo de especialistas en análisis y modelado de turbinas, su opinión tras de emplearlo es que el modelado resulta sencillo en la definición, más el detalle de las reglas de diagnóstico resultó poco claro al principio y su opinión con respecto al manejo de los programas en LDX refleja que es poco intuitivo y por ende complicado.

Tabla 6‐3 Resultados sobre sencillez

Aspecto Sencillo Medianamente complicado ComplicadoModelo general 4 1 Reglas de diagnóstico 1 2 2 Programas LDX 1 4

La ejecución del diagnóstico ya preparado, se realiza desde un explorador de Internet o browser, permitiendo el proceso remoto de tal proceso. Por manejo de permisos, se valida la entrada del usuario, previo a la introducción de parámetros necesaria para poder procesar la información del diagnóstico.

Figura 6‐3 Acceso a la página de solicitud de diagnóstico.

De las 24 corridas finales, los tiempos de ejecución variaron significativamente, con un promedio de 1 minuto, y un máximo de 3 minutos en ejecutarse.

La salida que ofrece el sistema, describe las características del sistema, enlistando las fallas presentes. Un ejemplo de tal salida se ilustra en la siguiente figura.

Figura 6‐4 Resultado del diagnóstico

Finalmente, tras de la ejecución de 10 rondas con las 24 instancias de prueba para cada método, se ejecutó el algoritmo genético para el mejoramiento de reglas para ambos conjuntos de reglas. La siguiente tabla muestra los resultados de la ejecución del proceso, donde se encuentra una gran generación de reglas nuevas para el modelo del IIE principalmente.

Tabla 6‐4 Resultados sobre mejoramiento de reglas

Método Reglas originales Reglas generadas Modelo IIE 9 5Cotton 12 3

Estas reglas nuevas expresan que existe una amplia posibilidad de cambios, pero dado que son producto de un grupo relativamente pequeño de pruebas, no son muy confiables, por otra parte, hay interpretaciones de los especialistas que descartan algunas de las nuevas reglas, en especial en cuanto a las primes etapas de la turbina, pero consideran interesante algunas opciones sobre etapas más adelante, en especial las de la sección de baja presión.

Por otra parte, la aparición de menos reglas en cuanto al modelo de Cotton se explica pues las reglas nuevas surgen de la falta de profundidad en cuanto a la sección de baja presión, ante lo cual se anexan solo las reglas la cubren.

Diagnóstico Automático de Turbinas de Vapor en Línea Capítulo 7 Conclusiones y trabajo futuro

7 Capítulo 7

Capítulo 7 Conclusiones y trabajo futuro

A continuación se exponen los resultados, se exponen algunas observaciones que explican algunos aspectos de los resultados y se plantean los trabajos que complementan a futuro este desarrollo.

7.1 Naturaleza de los resultados Como parte de los objetivos, esta investigación busca determinar cuan adecuada es

este tipo de herramientas meta‐modeladas como infraestructura para futuros programas de diagnóstico. Sin embargo, durante la investigación se obtuvieron referencias que indican que las distintas técnicas requieren información y métodos muy variados, así mismo se destaca que cada técnica tiene condiciones de trabajo favorece algunos resultados.

Ante tal situación, más allá de cualquier tamaño de muestra, los resultados no expresan contundentemente que el diagnóstico fuese adecuado o no, sino que para el modelo seleccionado, es factible emplear este mecanismo.

Además de ello, los aspectos como flexibilidad y robustez tendrán que estimarse simplemente como existentes, pues es intangible la magnitud. Sin embargo, dado que para cada familia y configuración se debe verificar y acomodar tanto el modelo como los programas de LDX, resulta imposible considerar como sencillo su manejo.

7.2 Comparación de métodos Si bien los métodos se pudieron modelar, ejecutaron correctamente y no presentaron

discrepancias con respecto a las pruebas de escritorio, los dos métodos son distintos en complejidad, es decir el número de operaciones y reglas. Tal situación hace suponer que las ejecuciones del modelo de Cotton debieron ser mejores que los del IIE en tiempo, y fallar en precisión.

Sin embargo dado que las pruebas muestran tiempos similares, sin discrepancia en los resultados, salvo el hecho de que las reglas del modelo de Cotton parecen incidir en una clara ampliación para abordar los casos de fallas en la sección de baja presión de la turbina.

7.3 Diagnosticabilidad La implementación ha demostrado que bajo este enfoque ha sido posible la repetición

de los resultados, exponiendo un adecuado nivel de efectividad en el diagnóstico. Sin embargo esta diagnosticabilidad es relativa solo al caso de estudio empleado, cada nuevo sistema debe cuestionarse sobre la confiabilidad y validez en cuanto a la descripción del sistema y las reglas de diagnóstico aplicadas, principalmente buscando la automatización de procesos de monitoreo en planta.

La evaluación requiere aún del análisis de expertos en el tema y son conocimiento del estado real de los equipos.

7.4 Trabajos futuros Esta investigación puede considerarse como el primero de muchos pasos que deben

darse para mejorar la infraestructura de diagnóstico del IIE. Uno de los más significativos es lograr la simplificación en el manejo del lenguaje LDX. El cual debe ampliarse y combinarse con otras herramientas y librerías para poder implementar más técnicas como por ejemplo: redes neuronales, funciones avanzadas de física y química.

Así es deseable lograr la sencillez de manejo en la aplicación, debe realizarse un esfuerzo por desarrollar herramientas de generación automática de código y aplicar técnicas de programación visual modular, similares a LabView.

Obviamente que el caso de estudio sobre turbinas de vapor debe ser el primero de diversas implementaciones al respecto, continuando con otros elementos como: calderas, condensadores, turbinas de gas y generadores.

Anexo A: Diagrama de Mollier

Anexo B: Diagramas de UML

Anexo C: Diagrama E‐R de los metamodelos

Glosario .NET Framework Ciencias Computacionales. Es una plataforma de desarrollo de software con

énfasis en transparencia de redes, con independencia de plataforma y que permita un rápido desarrollo de aplicaciones. Basado en esta plataforma, Microsoft intenta desarrollar una estrategia horizontal que integre todos sus productos, desde el Sistema Operativo hasta las herramientas de mercado.

.NET podría considerarse una respuesta de Microsoft al creciente mercado de los negocios en entornos Web, como competencia a la plataforma Java de Sun Microsystems.

Álabe Ingeniería Mecánica. Es un elemento que permite la transferencia de impulso a un rotor. Así puede ser cada una de las paletas curvas de la turbina que reciben el impulso del fluido. También se llama álabe a cada uno de los dientes de la rueda, que sucesivamente levantan y luego abandonan a su propio peso los mazos de un batán u otro mecanismo análogo.

Algoritmo Ciencias Computacionales. Es un conjunto de pasos destinados a la solución de un problema.

Almacén de datos Ciencias Computacionales. (Del inglés data warehouse) Es una colección de datos orientadas a un dominio, integrado, no volátil y variable en el tiempo que ayuda a la toma de decisiones de la empresa u organización. Se trata, sobre todo, de un expediente de una empresa más allá de la información transaccional y operacional, almacenado en una base de datos diseñada para favorecer análisis y la divulgación eficientes de datos (especialmente OLAP, procesamiento analítico en línea).

ANN Ciencias Computacionales. Siglas de Red Neuronal Artificial (Del inglés Artificial Neural Network) Es un modelo. También denominado Redes Neuronales Simuladas.

ANSI Siglas del Instituto de Estándares Nacional Estadounidense (del inglés American National Standards Institute) Es el organismo responsable de la fijación y difusión de los estándares en Estados Unidos. Depende del ISO, el organismo internacional y ha sido generador de importantes normas tales como las bases para la presentación de información en pantalla y la forma en que se interactúa con el teclado.

Árbol de fallas Técnica de diagnóstico basada en la descripción de síntomas que inciden en las fallas de un sistema. Se representa como una arborescencia donde se encadenan síntomas hasta llegar a una falla. Puede incluir los pesos o probabilidades condicionales por evento.

Arquitectura de software Ciencias Computacionales. Es un conjunto de información sobre un sistema de software, enfocado a mejorar la calidad de los atributos del software, tales como la eficiencia, usabilidad, flexibilidad, durabilidad, etc. Tal conjunto debe describir las responsabilidades de las partes (componentes) internas del sistema, para administrar y controlar las dependencias dentro de un sistema de software.

ASME Siglas de la Sociedad Americana de Ingenieros Mecánicos (Del inglés American Society of Mechanical Engineers) Es un cuerpo profesional, específicamente una sociedad de ingeniería, enfocada a aspectos técnicos, educacionales y de investigación de ingeniería.

Genera códigos y estándares internacionalmente reconocidos para dispositivos mecánicos.

Autómata Ciencias Computacionales. Es un modelo matemático de un sistema que

recibe una cadena constituida por símbolos de un alfabeto y determina si esa cadena pertenece al lenguaje que el autómata reconoce.

Back propagation Ciencias Computacionales. Termino en inglés que se refiere a la propagación hacia atrás de errores, y es un algoritmo de aprendizaje supervisado que se usa para entrenar redes neuronales artificiales. El algoritmo consiste en minimizar un error (comúnmente cuadrático) por medio de gradiente descendiente, por lo que la parte esencial del algoritmo es cálculo de las derivadas parciales de dicho error con respecto a los parámetros de la red neuronal.

Balanceo Ingeniería mecánica. Es el ajuste de la distribución de la masa de una parte rotativa de manera que las fuerzas en los rodamientos (debido a efectos centrífugos) se reducen a valores pequeños. El rotor está balanceado si el centro de distribución de masa coincide con el centro de rotación. El balanceo reduce el consumo de energía en las máquinas, reduce los niveles de vibración e incrementa la vida de los rodamientos a veces de manera importante.

Base de datos Ciencias Computacionales. Es un conjunto de datos que pertenecen al mismo contexto almacenados sistemáticamente para su posterior uso. En este sentido, una biblioteca puede considerarse una base de datos compuesta en su mayoría por documentos y textos impresos en papel e indexados para su consulta.

En la actualidad, y debido al desarrollo tecnológico de campos como la informática y la electrónica, la mayoría de las bases de datos tienen formato electrónico, que ofrece un amplio rango de soluciones al problema de almacenar datos.

C# Ciencias Computacionales. Es un lenguaje de programación orientado a objetos, evolución del lenguaje C++, desarrollado por Microsoft. El fundamento de C# es operar con base en la plataforma .NET Framework.

Caja de texto Ciencias Computacionales. Es un elemento de la interfaz de usuario empleado para la introducción de texto.

Cálculo de predicados Ciencias Computacionales. Forma del cálculo lógico basado en el análisis de proposiciones.

Caldera Ingeniería Mecánica. Recipiente a presión, dotado de una fuente de calor, para la producción de vapor a partir de líquidos, típicamente agua.

Canal de flujo Ingeniería Mecánica. Conducto a través del cual transita un fluido. En el caso de turbinas de vapor, el canal de flujo se forma por el espacio, principalmente entre los álabes, por el cual se hace transitar el vapor.

Carcasa Ingeniería Mecánica. Armazón que contiene los componentes eléctricos y electrónicos de un aparato.

Chumacera Ingeniería Mecánica. Pieza de metal o madera con una muesca en que descansa y gira cualquier eje de maquinaria.

Ciclo termodinámico Ingeniería Mecánica. Es el proceso que tiene lugar en dispositivos destinados a la obtención de trabajo a partir de dos fuentes de calor a distinta temperatura o, de manera inversa, a producir el paso de calor de la fuente de menor temperatura a la fuente de mayor temperatura mediante la aportación de trabajo.

Clasificador Ciencias Computacionales. Pieza de código que permite la separación y el etiquetado de elementos dentro de una colección. Puede fundamentarse en agrupaciones por afinidad de propiedades con base en entropías, funciones numéricas para corte de planos o métodos mixtos.

CORBA Ciencias Computacionales. Siglas de Arquitectura de Agente de Petición de Objetos Común (Del inglés Common Object Request Broker Architecture) Es un estándar que establece una plataforma de desarrollo de sistemas distribuidos facilitando la invocación de métodos remotos bajo un paradigma orientado a objetos.

DB Ciencias Computacionales. Siglas de Base de Datos (Del inglés Database)

DBMS Ciencias Computacionales. Siglas de Sistema Manejador de Base de Datos (Del inglés Database Management System) Es un conjunto de herramientas para controlar la organización, almacenamiento, administración y recuperación de datos de la base de datos. Un DBMS incluye: un lenguaje de modelado de datos (DDL), estructuras de datos, lenguaje de manipulación de datos (DML), conectores para programación, servicios de control transaccional y algunas herramientas visuales de interfaz de usuario. Algunos ejemplos importantes son: Oracle, DB2, Microsoft SQL Server, MySQL, entre otros

Depósitos Ingeniería Mecánica. Desechos que contaminan un lubricante, un fluido o degradan un equipo. En el mantenimiento de turbinas, se denomina “depósitos” a las concentraciones de diversas sales que se adhieren a la carcasa y los álabes, reduciendo el canal de flujo, cambiando la física del equipo, exponiéndolo a condiciones riesgosas de operación.

Diagnosis Es el proceso para lograr un diagnóstico.

Diagnosis basada en modelos Ciencias Computacionales. Técnica de diagnóstico a partir de la comparación de los comportamientos calculado y real de un sistema. Su principio es la detección de desviaciones con base en la representación de variables del sistema.

Ingeniería Mecánica. Cálculo para establecer el nivel de desviación entre los resultados de procesar el modelo físico de un equipo, tanto con los datos de diseño como con la información presente en la instrumentación.

Diagnosticabilidad Ciencias Computacionales. Es la capacidad de un sistema de poder ser diagnosticado con un nivel de confiabilidad adecuado para cierta tarea.

Diagnóstico Ciencias Computacionales. Rama de la Inteligencia Artificial, encargada del estudio de la detección de fallas.

Ingeniería Mecánica. Detección de las desviaciones en el balance térmico, comportamiento de las vibraciones típicas o alteraciones en aspectos físicos del aparato.

DIN Siglas de Institución de normalización alemana (Del alemán Deutsche Industrie Norm) Una entidad alemana que se encarga de establecer la normativa técnica que han de cumplir los equipos electrónicos. Es reconocida por ciertas normativas técnicas de reconocimiento internacional como los formatos que debe tener el papel.

DX Ciencias Computacionales. Acrónimo de “Diagnóstico”, empleado por diversas comunidades de inteligencia artificial enfocadas al análisis del estado y las fallas en sistemas.

Entalpía Ingeniería Mecánica. Es nombre dado a una función de estado de la termodinámica donde la variación permite expresar la cantidad de calor puesto en juego durante una transformación isobárica (a presión constante) en un sistema termodinámico, transformación en el curso de la cual se puede recibir o aportar energía. Con este contexto, la entalpía es numéricamente igual al calor intercambiado con el ambiente exterior al sistema en cuestión.

Entropía Ciencias Computacionales. Término empleado como medida de la incertidumbre existente ante un conjunto de mensajes, de los cuales se va a recibir uno solo.

Ingeniería Mecánica. Es la magnitud física que mide la parte de la energía que no puede utilizarse para producir trabajo. En un sentido más amplio se interpreta como la medida de la uniformidad de la energía de un sistema.

Estator Ingeniería Mecánica. Es una parte fija de una máquina rotativa, la cual alberga una parte móvil (rotor). Las partes principales son: Carcasa, escudos, rodamientos (balineras, cojinetes), eje, bornera, entre otros.

Falla Es un evento que no cumple con el propósito para el que debiese servir. Dentro del diagnóstico de sistemas se ubica como la presencia de una anormalidad en el comportamiento del sistema.

FDI Siglas de Aislamiento y detección de fallas (Del inglés Fault Detection and Isolation) Es un enfoque del diagnóstico muy próximo al empleado por los grupos de control, consistente en localizar las partes defectuosas de un sistema con base en un modelo cercano a la naturaleza del sistema en sí.

GUI Ciencias Computacionales. Siglas de Interfaz gráfica de usuario (Del inglés Graphic User Interface) Es un método para facilitar la interacción del usuario con el ordenador a través de la utilización de un conjunto de imágenes y objetos pictóricos (iconos, ventanas, etc.) además de texto.

HMI Ciencias Computacionales. Siglas de Interfaz Hombre‐Máquina (Del inglés Human Machine Interface) Es el paquete de software que utiliza una interfase gráfica para permitir a un operador controlar una máquina u operación. También denominada MMI (Man Machine Interface)

HMM Siglas de Modelo Oculto de Markov (Del inglés Hidden Markov Model) Es un modelo estadístico donde el sistema modelado se asume como un proceso de Markov con parámetros desconocidos, y el reto es determinar los parámetros ocultos a partir de parámetros observables, basados en esta suposición. Los parámetros extraídos pueden entonces ser usados para ejecutar análisis posteriores, por ejemplo aplicaciones de reconocimiento de patrones.

IEEE Siglas de Instituto de Ingenieros Eléctricos y Electrónicos (Del inglés Institute of Electrical and Electronics Engineers) Es una asociación estadounidense dedicada a la estandarización. Sin fines de lucro, está formada por profesionales de las nuevas tecnologías, como ingenieros de telecomunicaciones, electrónicos, en informática, etc.

Incertidumbre Es la duda o falta de seguridad que existe en los procesos no determinísticos.

Ingeniería de software Es el conjunto de técnicas destinadas a la producción de un programa de computadora, más allá de la sola actividad de programación.

ISO Siglas de Organización Internacional para la Estandarización (Del inglés International Standard Organization), es una organización internacional no gubernamental, compuesta por representantes de los organismos de normalización nacionales, que produce normas internacionales industriales y comerciales. Dichas normas se conocen como normas ISO y su finalidad es la coordinación de las normas nacionales, para facilitar el comercio, permitir el intercambio de información y contribuir con unos estándares comunes para el desarrollo y transferencia de tecnologías.

J2EE Ciencias Computacionales. Siglas de Java 2 Edición Empresarial, es la edición empresarial del paquete Java creada y distribuida por Sun Microsystems. Comprenden un conjunto de especificaciones y funcionalidades orientadas al desarrollo de aplicaciones empresariales. Debido a que J2EE no deja de ser un estándar, existen otros productos desarrollados a partir de ella aunque no

exclusivamente.

Java Ciencias Computacionales. Es un lenguaje de programación orientado a objetos, diseñado por Sun Microsystems para el desarrollo de aplicaciones multiplataforma y para la WWW. Se puede describir como una versión simplificada de C++. Además, Java implementa muchas características de seguridad en tiempo de compilación y de ejecución, para asegurar la aplicación que se ejecuta. Pero la novedad de este lenguaje es que es independiente de la plataforma cliente, y las applets se ejecutan en el sistema cliente.

Javascript Ciencias Computacionales. Es un lenguaje interpretado (no requiere compilación) de programación desarrollado por Netscape para el enriquecimiento de funciones en páginas Web. Aunque es parecido a Java se diferencia de él en que los programas están incorporados en el archivo HTML. Al contrario que Java, JavaScript no es un lenguaje orientado a objetos propiamente dicho, ya que no dispone de Herencia, es más bien un lenguaje basado en prototipos, ya que las nuevas clases se generan clonando las clases base (prototipos) y extendiendo su funcionalidad.

JVM Ciencias Computacionales. Siglas de Máquina Virtual de Java (Del inglés Java Virtual Machine) es el elemento encargado de ejecutar el código (bytecode) generado por la compilación de código fuente escrito usando el lenguaje de programación Java. Se sitúa en un nivel superior al Hardware sobre el que se pretende ejecutar la aplicación, actuando como un puente entre el bytecode y el sistema sobre el que se ejecuta.

Lenguaje Ciencias Computacionales. Es sistema de programación que permite la creación de programas por medio de los cuales se comunica al usuario con la máquina a fin de que ésta cumpla una tarea determinada. Existen distintos niveles de lenguajes que se pueden clasificar según su grado de abstracción y dificultad.

Lógica difusa Ciencias Computacionales. Es un tipo de lógica que cualifica la incertidumbre de la lógica multivaluada al representar conceptos o conjuntos imprecisos, alejándose del concepto de dos valores que supone todo en términos de blanco y negro (cierto y falso) empleado en la lógica clásica, mediante el uso de matices de grises.

Lógica proposicional Ciencias Computacionales. Es una rama de la lógica clásica que estudia las proposiciones o sentencias lógicas, sus posibles evaluaciones de verdad y en el caso ideal, su nivel absoluto de verdad.

Maple Ciencias Computacionales. Acrónimo de Placer Matemático (Del inglésMAthematical PLEasure) Es un programa matemático de propósito general capaz de realizar cálculos simbólicos, algebraicos y de álgebra computacional. Fue desarrollado originalmente en 1981 por el Grupo de Cálculo Simbólico en la Universidad de Waterloo en Waterloo, Ontario, Canadá. Actualmente lo mantiene y comercializa la compañía Maplesoft.

MATLAB Ciencias Computacionales. Abreviatura de laboratorio de matrices (Del inglés Matrix Laboratory) Es un programa de cálculo numérico, creado por The MathWorks en 1984, orientado a matrices y vectores.

Metadatos Ciencias Computacionales. Representa la información sobre la información. Un elemento del metadatos puede describir un dato individual o elemento de contenido, o una colección de datos incluyendo múltiples elementos de contenido. Los metadatos se emplean para facilitar el entendimiento, uso y administración de los datos. Los metadatos requeridos para la administración efectiva de datos varían con el tipo de datos y el contexto de uso.

Middleware Ciencias Computacionales. Es un software de conectividad que ofrece un conjunto de servicios que hacen posible el funcionamiento de aplicaciones distribuidas sobre plataformas heterogéneas. Funciona como una capa de abstracción de software distribuida, que se sitúa entre las capas de aplicaciones y las capas inferiores (sistema operativo y red). A través del middleware se abstrae de la complejidad y heterogeneidad de las redes de comunicaciones subyacentes, así como de los sistemas operativos y lenguajes de programación, proporcionando una API para la fácil programación y manejo de aplicaciones distribuidas. Dependiendo del problema a resolver y de las funciones necesarias, serán útiles diferentes tipo de servicios de middleware.

Modelo Idealización de la realidad utilizada para plantear un problema, normalmente de manera simplificada en términos relativos y planteados desde un punto de vista matemático, aunque también puede tratarse de un modelo físico. Es una representación conceptual o física a escala de un proceso o sistema (fenómeno), con el fin de analizar su naturaleza, desarrollar o comprobar hipótesis o supuestos y permitir una mejor comprensión del fenómeno real al cual el modelo representa.

Modelo de datos Es aquella representación que describe de una forma abstracta cómo se representan los datos, sea en una empresa, en un sistema de información o en un sistema de gestión de base de datos. Básicamente consiste en una descripción de algo conocido como contenedor de datos (algo en donde se guarda la información), así como de los métodos para almacenar y recuperar información de esos contenedores.

Un modelo de datos consiste en: Objetos (entidades que existen y que se manipulan), Atributos (características básicas de estos objetos) y Relaciones (forma en que enlazan los distintos objetos entre si)

MSDN Ciencias Computacionales. Red de Desarrolladores de Microsoft (Del inglésMicrosoft Developer Network) Es el grupo para colaboración que Microsoft ha creado para soporte, actualización de productos, soporte entre clientes, referencia y solución de problemas.

OMG Ciencias Computacionales. Siglas de Grupo de Administración de Objetos (Del inglés Object Management Group) Es un consorcio de la industria computacional internacional, de membresía abierta sin fines de lucro. OMG desarrolla estándares empresariales de integración para una amplia variedad de industrias. Los estándares de modelado de OMG permiten poderosos diseños visuales, ejecución y mantenimiento de software y otros procesos. Los estándares y perfiles de OMG para middleware están basados en CORBA y soportan a una amplia variedad de industrias.

OOP Ciencias Computacionales. Siglas de Programación Orientada a Objetos (Del inglés Object Oriented Programming) Es una técnica de diseño y programación de software que parte del fundamento de abstraer los elementos del problema en función de las entidades físicas o virtuales que intervienen en el problema, sus atributos y acciones de interacción.

Parámetro Dato o factor que se toma como necesario para analizar o valorar una situación.

Portal Ciencias Computacionales. Es un sitio Web cuyo objetivo es ofrecer al usuario, de forma fácil e integrada, el acceso a una serie de recursos y de servicios, entre los que suelen encontrarse buscadores, foros, documentos, aplicaciones, compra electrónica, etc. Principalmente están dirigidos a resolver necesidades específicas de un grupo de personas o de acceso a la información y servicios de a una institución pública o privada.

CXVIII

Presión Ingeniería Mecánica. Fuerza ejercida por un líquido, o por un gas, sobre cada cm², o cada m², de la superficie de un sólido con el que está en contacto.

Prolog Ciencias Computacionales. (Del francés Programmation et Logique) Es un lenguaje de programación, concebido para escribir programas de Inteligencia Artificial. Creado en 1972, las tareas se expresan describiendo los objetos que se necesitan y las relaciones lógicas entre ellos.

Red bayesiana Ciencias Computacionales. Es un modelo probabilístico multivariado que relaciona un conjunto de incertidumbres. Una red de este tipo representa las variables del modelo como vértices, o nodos, en una estructura interconectada acíclicamente por flechas, o arcos, que indican influencia causal. Gracias a su motor de actualización de probabilidades, el Teorema de Bayes, las redes bayesianas son una herramienta extremadamente útil en la estimación de probabilidades ante nuevas evidencias.

Red de Petri Ciencias Computacionales. En el campo de la inteligencia artificial se refiere habitualmente de forma más sencilla como redes de neuronas o redes neuronales, las redes de neuronas artificiales (denominadas habitualmente como RNA o en inglés como: "ANN") son un paradigma de aprendizaje y procesamiento automático inspirado en la forma en que funciona el sistema nervioso de los animales. Se trata de un sistema de interconexión de neuronas en una red que colabora para producir un estímulo de salida.

Red neuronal artificial Ciencias Computacionales. En el campo de la inteligencia artificial se refiere habitualmente de forma más sencilla como redes de neuronas o redes neuronales, las redes de neuronas artificiales (denominadas habitualmente como RNA o en inglés como: "ANN") son un paradigma de aprendizaje y procesamiento automático inspirado en la forma en que funciona el sistema nervioso de los animales. Se trata de un sistema de interconexión de neuronas en una red que colabora para producir un estímulo de salida.

Regla de diagnóstico Conjunto de elementos que establecen una anormalidad en un sistema.

Reusabilidad Ciencias Computacionales. (Del inglés reusability) Concepto referente al diseño, construcción y documentación de los elementos para emplearse como piezas de diversas partes de una solución o en soluciones distintas.

Rotor Ingeniería Mecánica. Parte giratoria de una máquina.

SCADA Ciencias Computacionales. Acrónimo de Control de Supervisión y Adquisición de Datos (Del inglés Supervisory Control and Data Acquisition) Es software para el control de procesos, recolecta datos en tiempo real desde una posición remota, para supervisar y controlar equipos y ajustar condiciones.

SAT Ciencias Computacionales. Término empleado para designar al problema de satisfactibilidad, Consiste en decidir si acaso una forma proposicional dada es satisfactible, es decir si existe alguna combinación de valores cuya evaluación resulte en verdadero.

Simulación Ciencias Computacionales. Proceso de diseñar un modelo de un sistema real y llevar a término experiencias con él, con la finalidad de comprender el comportamiento del sistema o evaluar nuevas estrategias ‐dentro de los limites impuestos por un cierto criterio o un conjunto de ellos ‐ para el funcionamiento del sistema

Síntoma Es la manifestación o reacción observable de un sistema ante una anormalidad.

Sistema experto Ciencias Computacionales. Aplicación informática que procura capturar conocimiento y luego utilizarlo para emular el mecanismo de raciocinio de un experto humano, para la resolución de problemas concretos. Esto se logra automatizando su procedimiento de toma de decisiones. Un sistema experto

consta fundamentalmente de una base de conocimiento, un motor de inferencia y una interfaz de diálogo con el usuario.

SNN Ciencias Computacionales. Siglas de Red Neuronal Simulada (Del inglés Simulated Neural Network) Es otro nombre que se les da a las Redes Neuronales Artificiales o ANN.

Software Ciencias Computacionales. Es el conjunto de programas, documentos, procesamientos y rutinas asociadas con la operación de un sistema de computadoras, es decir, la parte intangible o lógica de una computadora.

SQL Ciencias Computacionales. Lenguaje Estructurado de Consulta (Del inglés Structured Query Language) Lenguaje creado por IBM para el acceso a la información en una base de datos y poder así gestionar entradas, borrarlas, ponerlas al día, etc. Una de sus características es el manejo álgebra y cálculo relacional permitiendo lanzar consultas con el fin de recuperar información de interés, de una forma sencilla.

Teorema de Bayes En la teoría de la probabilidad, es el resultado que da la distribución de probabilidad condicional de una variable aleatoria A dada B en términos de la distribución de probabilidad condicional de la variable B dada A y la distribución de probabilidad marginal de sólo A. Fue enunciado por Thomas Bayes.

Torque Ingeniería Mecánica. Es una magnitud física que nos sirve para darnos idea de cómo evoluciona la fuerza de un motor. En otras palabras, representa la capacidad del motor para producir trabajo o arrastre.

Turbina Ingeniería Mecánica. Es una máquina destinada a transformar en electricidad el movimiento giratorio de una rueda de paletas por medio de la presión de un fluido.

Turbina de gas Ingeniería Mecánica. Es una turbomáquina motora de reacción, cuyo fluido de trabajo es un gas.

Turbina de vapor Ingeniería Mecánica. Es el equipo impulsado por vapor, usador para convertir la energía del vapor en energía rotacional.

Turbomáquina Ingeniería Mecánica. Es una máquina cuyo elemento principal es un rodete (rotor) a través del cual pasa un fluido de forma continua, cambiando éste su cantidad de movimiento por acción de la máquina, significando este hecho una transferencia de energía entre la máquina y el fluido, la cual puede ser en sentido máquina‐fluido o fluido‐máquina.

Turbomaquinaria Ingeniería Mecánica. Es aquella máquina que transfiere energía entre un rotor y un fluido, incluyendo elementos como turbinas y compresores.

UML Ciencias Computacionales. Siglas de Lenguaje de Modelado Unificado (Del inglés Unified Modeling Language) Es el lenguaje de modelado de sistemas de software más conocido en la actualidad; es un estándar industrial de OMG para la especificación, visualización, construcción y documentación de artefactos de sistemas de software.

Usabilidad Ciencias Computacionales. (Del inglés Usability) Concepto referente a las características de efectividad, eficiencia y satisfacción con la que un producto permite alcanzar objetivos específicos a usuarios específicos en un contexto de uso específico.

Vapor Es un gas que se obtiene por evaporación o ebullición del agua líquida o por sublimación del hielo. Es inodoro e incoloro y, a pesar de lo que pueda parecer, las nubes o el vaho blanco de una cacerola o un congelador, vulgarmente llamado "vapor", no son vapor de agua sino el resultado de minúsculas gotas de agua líquida o cristales de hielo. Muy enrarecido, el

vapor de agua es responsable de la humedad ambiental. En ciertas condiciones, a alta concentración, parte del agua que forma el vapor condensa y se forma niebla o, en concentraciones mayores, nubes.

VBScript Ciencias Computacionales. (Abreviatura de Visual Basic Script Edition) Es un lenguaje interpretado surgido como variación del lenguaje Visual Basic. Sirve como herramienta de automatización en los sistemas operativos Windows, permitiendo más margen de actuación y flexibilidad que el lenguaje Batch. Es parte fundamental de la ejecución de aplicaciones de servidor programadas en ASP (Active Server Pages), sin embargo, VBScript sólo está disponible para el navegador de Microsoft Internet Explorer, y no en otros como Firefox u Opera.

Visual Basic Ciencias Computacionales. Es un lenguaje de programación desarrollado por Alan Cooper para Microsoft. El lenguaje de programación es un dialecto de BASIC, con importantes añadidos. Su primera versión fue presentada en 1991 con la intención de simplificar la programación utilizando un ambiente de desarrollo completamente gráfico que facilitara la creación de interfaces gráficas y en cierta medida también la programación misma. Visual Basic fue discontinuado por Microsoft hace ya varios años, a favor de su versión Visual Basic .NET.

Visual Basic .NET Ciencias Computacionales. Es un lenguaje de programación orientado a objetos que se puede considerar una evolución de Visual Basic implementada sobre el.NET Framework. Su introducción resultó muy controvertida, ya que debido a cambios significativos en el lenguaje VB.NET no es compatible hacia atrás con Visual Basic, cosa que causó gran división en la comunidad de desarrolladores de Visual Basic.

Referencias bibliográficas [AAMODT 1994] AAMODT, Agnar y Enric Plaza, “Case‐Based Reasoning: Foundational

issues, methodological variations, and System approaches”, AI Communications, Vol. 7, Num. 1, 1994, PP. 39‐59

[ALONSO 2002] ALONSO, Fernando, Juan P. Caraca‐Valente, Angel L. González & César Montes, “Combining Expert Knowledge and Data Mining in a Medical Diagnosis Domain”, Expert Systems with Applications, Num. 23, 2002, PP. 367 – 375.

[AQUINO 2005] AQUINO, H., “Investigación de estrategias para la detección y diagnóstico de fallas en Centrales Termoeléctricas”, Reporte técnico de estancia de Adiestramiento en Investigación Tecnológica, Instituto de Investigaciones Eléctricas, México, 2005.

[BENJAMINS 1994] BENJAMINS, Richard & Wouter Jansweijer, “Toward a Competence Theory of Diagnosis”, IEEE Expert, October, 1994, PP. 43 ‐ 52.

[BOX 1970] BOX, G. E. P. y G.M. Jenkins, “Time Series Analysis, Forecasting, and Control”, Holden Day, San Francisco, 1970

[CFE 1995] “Especificación CFE W1200‐01”, Especificación técnica oficial para proveedores de turbogeneradores de 160 y 350 MW, México, D.F. 1995

[COTTON 1998] COTTON, K. C., “Evaluating and Improving Steam Turbine Performance”, 2nd Edition, Cotton Fact Inc., New York, USA, 1998.

[DORF 2006] DORF, Richard C., “Systems, Controls, Embedded Systems, Energy, and Machines, The Electrical Engineering Handbook”, 3a. edición, CRC Press, Inc., Boca Raton, Fl. USA, 2006.

[ELAZAHARY 2002] EL‐AZHARY, E. S., A. Edrees &, A. Rafea, “Diagnostic Expert System Using Non‐Monotonic Reasoning”, Expert Systems with Applications, Num. 23, 2002, PP. 137–144.

[FELFERNIG 2004] FELFERNIG, Alexander, Gerhard Friedrich, Dietmar Jannach & Markus Stumptner, “Consistency‐based Diagnosis of Configuration Knowledge Bases”, Artificial Intelligence, Num 152, 2004, PP. 213‐234.

[FENSEL 1996] FENSEL, Dieter y Richard Benjamins, “Assumptions in Model‐based Diagnosis”, Proceedings of the 10th Banff Knowledge Acquisition for Knowledge‐Based System Workshop (KAW´96), Banff, Canada, 1996.

[GALINDO 1996] GALINDO, Francisco, “Esquemas de Control Predictivo para Regular la Presión de Vapor Sobrecalentado en una Central Termoeléctrica de Ciclo Combinado”, Tesis de maestría, ITESM, Morelos, México, Noviembre, 1996

[GIARRATANO 1994] GIARRATANO, Joseph C. y Gary Riley, “Expert Systems: Principles and Programming”, PWS Publishing Company, Boston, 1994, pp 644.

[GONZALEZ 1995] GONZALEZ, Avelino J., M. Stanley Baldwin, J. Stein y N. E. Nilsson, “Monitoring and diagnosis of turbine‐driven generators”, EPRI M&D Center Series, Prentrice Hall, USA, 1995

[HAWKES 1986] HAWKES, Nigel Et Al, “The Worst Accident in the World: Chernobyl: The End of the Nuclear Dream”, 1986, p178.

[ISERMANN 2004] ISERMANN, Rolf, “Model‐Based Fault Detection and Diagnosis ‐ Status and Applications”, IFAC, Banff, Canada, 2004.

[JACKSON 1990] JACKSON, Peter, “Introduction to expert systems”, Second Edition, Addison Wesley Publishing Company Inc., México, D.F., 1990.

[JEFFREY 1991] JEFFREY, J. M. (1991),”Using petri nets to introduce operating system concepts.”, Papers of the twenty‐second SIGCSE technical symposium on Computer science education, PP 324‐329.

[KAZAROV 1998] KAZAROV, A. y Yu Ryabov, “CLIPS expert system tool: a candidate for the Diagnostic System engine”, Notes of Atlas DAQ, Diciembre, 1998.

[KEARTON 1961] KEARTON William J., “Steam turbine theory and practice”, Sir Isaac Pitmain & Sons, Ltd, 7a. edición, Londres, 1961.

[KIAMEH 2003] KIAMEH, Philip, “Power Generation Handbook: Selection, application, operation and maintenance”, McGraw‐Hill Handbooks, New York, 2003.

[KUBIAK 1996] KUBIAK, Janus, “Turbinas de vapor”, IIE / Grupo Fogra, Abr 1996, México, DF.

[LEYZEROVICH 2007] LEYZEROVICH, Alexander S., “Steam Turbines for Modern Fossil‐Fuel Power Plants”, Fairmont Press, Lilburn, GA, USA, 2007.

[LICHTY 1967] LICHTY, Lester Clyde, “Combustion Engine Processes”, McGraw‐Hill, Inc., 5ta Edición, New York, 1967

[LO 1997] LO, K.L., H. S. Ng y J. Trecat, “Power systems fault diagnosis using Petri nets”, IEE Proceedings of Generation, Transmition and Distribution, IEE proceedings online, Vol. 144, pp. 231‐236.

[MCCONKEY 1970] McCONKEY, A. y T. D. Eastop, “Applied thermodynamics”, Longman Inc., New York, 1970.

[MITCHELL 1981] MITCHELL, John S., “Machinery analysis and monitoring”, Penwell book, 1981; Tulsa, Oklahoma, USA

[OBREJA 1990] OBREJA, I., “Diagnosis of power plant faults using qualitative models and heuristic rules.”, Proceedings of the 3rd international Conference on industrial and Engineering Applications of Artificial intelligence and Expert Systems ‐ Volume 1 (Charleston, South Carolina, United States). IEA/AIE '90. ACM Press, New York, NY, 1990, PP 41‐46.

CXXIII

[PEISCHL 2003] PEISCHL, Bernhard & Franz Wotawa, “Model‐Based Diagnosis or Reasoning from First Principles”, IEEE Intelligent Systems, Mayo‐Junio, 2003, PP. 32‐37.

[PIETERSMA 2007] PIETERSMA, J., A.J.C. van Gemund y A. Bos, "A Model‐based Approach to Sequential Diagnosis", In IEEE Measurement & Instrumentation, Vol. 10, No. 2, pp. 46‐52, April 2007.

[PRECIADO 2000] PRECIADO, Eduardo, “El Diagnóstico en Línea de Turbinas de Vapor”, Boletín IIE‐Turbomaquinaria, Vol. 28, Núm. 4, Año 28, Octubre‐ Diciembre, 2004, PP. 131‐136.

[PRESSMAN 1998] PRESSMAN, Roger S., “Software Engineering: A practitioner’s approach”, Fourth Edition, McGraw Hill Inc., New York, NY, 1997.

[RAMIREZ 2004] RAMÍREZ, J. Antonio, Juan J. Rivera, Víctor M. Cristalinas & Carlos A. Mariño, “El Diagnóstico en Línea de Turbinas de Vapor”, Boletín IIE‐Turbomaquinaria, Vol. 28, Núm. 4, Año 28, Octubre‐ Diciembre, 2004, PP. 131‐136.

[REITER 1987] REITER, Raymond, “A Theory of diagnosis from First Principles”, Artificial Intelligence, Num. 32, 1987, PP. 57‐95.

[RUZ 2005] RUZ Hernández, J.A., E. Sánchez y D.A. Suárez “Neural Networks‐based scheme fault diagnosis in fossil electric power plants”, Proceedings of the International Joint Conference on Neural Networks, pp. 1740 – 1745, Quebec, Canadá, 2005.

[SCHEIDEL 2004] SCHEIDEL, Michael, Karlheinz Bender & Robert Taud, “Use and Experience of Gas Turbine On‐Line Diagnosis”, Power‐Gen Europe 2004, Barcelona, España, Mayo, 2004.

[SHIRAKAWA 2006] SHIRAKAWA, M., “Development of a thermal power plant simulation tool based on object orientation”, Proceedings of the Institution of Mechanical Engineers; Sep 2006; 220, A6; ProQuest Science Journals PP. 569

[SUAREZ 2007] SUAREZ, Dionisio A., Alfredo Sánchez López, José E. Martínez Prieto y Carlos D. García Beltrán, “Diagnóstico de fallas en el generador de vapor de una termoeléctrica usando redes de Petri”, Boletín IIE, Enero ‐ Marzo, pp 3‐14, México, 2007

[TAYLOR 1959] TAYLOR, E. S., “An Interim Report on Engineering Design”, Massachusetts Institute of Technology, Cambridge, MA, 1959.

[TOUAF 2005] TOUAF, Samir, “Diagnostic Logique des Systèmes Complexes Dynamiques dans un Contexte Multi‐Agent”, Tesis doctoral, Université Joseph Fourier‐Grenoble1, Grenoble, Francia, Marzo, 2005.

[WALKER 2007] WALKER, J. Samuel, “Three Mile Island: A Nuclear Crisis in Historical Perspective“, Berkeley: University of California Press, 2004, p. 231

[WANG 2005] WANG, Baosheng, Yuejian Wu y André Ivanov, “A Fast Diagnosis Scheme for Distributed Small Embedded SRAMs”, Proceedings of

the Design, Automation and Test in Europe Conference and Exhibition (DATE’05), IEEE, 2005.

Referencias de Internet [energymanager] Introduction to the Steam Turbine, Fecha de consulta: 31/oct/2007,

http://www.energymanagertraining.com/power_plants/steam_turbine.htm [wikipedia1] Thermodynamic cycle – Wikipedia, the free encyclopedia, Fecha de

consulta: 31/sep/2007, http://en.wikipedia.org/wiki/Thermodynamic_cycle [cfe1] CFE ‐ Generación de electricidad, Fecha de consulta: 12/oct/2007,

http://www.cfe.gob.mx/es/LaEmpresa/generacionelectricidad/ [cfe2] CFE ‐ Generación termoeléctrica, Fecha de consulta: 12/oct/2007,

http://www.cfe.gob.mx/es/LaEmpresa/generacionelectricidad/termoelectrica/ [cfe3] CFE ‐ Generación nucleoeléctrica, Fecha de consulta: 12/oct/2007,

http://www.cfe.gob.mx/es/LaEmpresa/generacionelectricidad/nucleoelectlagverde/ [cfe4] CFE ‐ Generación nucleoeléctrica, Fecha de consulta: 12/oct/2007,

http://www.cfe.gob.mx/es/LaEmpresa/generacionelectricidad/nucleoelectlagverde/

diagnóstico automático de turbinas de vapor en línea · pdf...

Documents

problemas turbinas de turbinas de vapor

turbinas is vapor

especial turbinas de vapor

01 turbinas a vapor

4 - turbinas a vapor

2.2 turbinas de vapor

turbinas de vapor. turbinas de vapor turbinas de acción...

9 turbinas de vapor

turbinas vapor

54410204 turbinas a vapor

turbinas de vapor

iii.- turbinas de vapor de...

turbinas de vapor[1]

turbinas a vapor - schegliaiev.pdf

turbinas a vapor - apresentação

turbinas a gas e turbinas a vapor

turbinas de vapor

turbinas vapor cogeneración cfb

turbinas de vapor - copia.docx