APARATO Y MÉTODO PARA ANÁLISIS DE DATOS DE FUNCIONAMIENTO Y DE FALLAS
ANTECEDENTES DE LA INVENCIÓN
Esta invención está relacionada con un método y aparato para automáticamente analizar el funcionamiento paramétrico y los datos relacionados con fallas de un vehículo o una máquina, como una locomotora de ferrocarril o una flotilla de locomotoras de ferrocarril. Una locomotora es un ejemplo de un sistema electromecánico complejo compuesto de varios subsistemas complejos. Cada uno de estos subsistemas está construido a partir de componentes que con el tiempo tienden a fallar. Cuando un componente falla, frecuentemente es difícil determinar la causa del componente que falló debido a que los efectos o problemas que produce la falla en el subsistema muy a menudo no son ni fácilmente aparentes en términos de su fuente ni típicamente únicos. La habilidad de automáticamente diagnosticar problemas que han ocurrido o que ocurrirán en los subsistemas de locomotora tiene un impacto positivo en cuanto a la minimización del tiempo no productivo de la locomotora. El tiempo no productivo de cualquier máquina o vehículo puede tener un impacto ventajoso mediante un diagnóstico exacto y temprano. También se conoce que la operación eficiente en cuanto costo de un ferrocarril o cualquier flotilla vehicular, requiere la
l H i i ii JÜB"*-**" •"" -*^^^--.^^^^^^^^^^^^^^^ fl??H minimización de las fallas de línea fuera del camino y el tiempo no productivo de la locomotora. La falla de un subsistema de vehículo principal puede provocar daños serios, reparaciones costosas y demoras operativas significativas. La avería de una locomotora estando en servicio es un evento especialmente costoso, requiriendo despachar una locomotora de reemplazo para jalar la composición de tren y posiblemente provocando que un segmento de vía esté fuera de servicio hasta que el tren sea movido. Como resultado, el buen estado de un motor de locomotora y sus subsistemas constituyentes es de importancia significativa. Previos intentos para diagnosticar problemas una vez que han ocurrido en un vehículo u otra máquina compleja usualmente implican realizar inspecciones por personal experimentado que tienen un entrenamiento y experiencia individual profunda con las locomotoras o los vehículos. Típicamente, estos individuos experimentados utilizan información disponible que ha sido introducida en un registro. Revisando el registro, utilizan su entrenamiento y experiencia acumulados para mapear incidentes que ocurren en sistemas en cuanto a problemas que pueden provocar los incidentes. Si el escenario de incidente-problema es simple, entonces este enfoque funciona bastante bien. Sin embargo, si el escenario de incidente-problema es complejo, entonces es muy difícil diagnosticar y corregir cualquier falla asociada con los incidentes. Actualmente, se están utilizando sistemas basados en computadora para automáticamente diagnosticar los problemas en un
j^fc^^^^^j^^^fak^^^jW?j^í^^^^ja=ggji é^^&^k vehículo para solucionar algunas de las desventajas asociadas al apoyarse completamente en el personal experimentado. Típicamente, un sistema basado en computadora utiliza un mapeo entre los síntomas observados de las fallas y los problemas de equipo utilizando técnicas como cuadros de búsqueda, matrices de síntoma-problema y reglas de producción. Estas técnicas funcionan bastante bien para sistemas simplificados que tienen mapeos simples entre síntomas y problemas. Sin embargo, los diagnósticos de proceso y de equipo complejos muy pocas veces tienen correspondencias simples. Además, no todos los sistemas estarán necesariamente presentes si ha ocurrido un problema, de este modo haciendo que otros enfoques sean más difíciles de aplicar. Los enfoques antes mencionados, ya sea toman una cantidad de tiempo considerable antes de que se diagnostiquen las fallas, o proporciona resultados poco menos que confiables, o son incapaces de funcionar bien en sistemas complejos. Existe la necesidad de rápida y eficientemente poder determinar la causa de cualquier falla que ocurre en el sistema de vehículo, mientras que al mismo tiempo minimiza la necesidad de intervención humana. También existen mecanismos sistemáticos o automáticos para identificar de problemas de máquina incipientes. En su lugar, convencionalmente, los propietarios se han basado en inspecciones regulares y la observación de anomalías de funcionamiento por el operador. Algunos procesos de inspección superficiales pueden lograrse mientras que la máquina o el vehículo están en servicio;
^^^^^^¿^^^^^M^^^^^^^^^^?^^^^^?^^^^^^^^^^^^^»^^^^^^í^ .
inspecciones más completas requieren que la máquina se ponga fuera de servicio durante varios días. En cualquier caso, el tiempo no productivo de la máquina o del vehículo, ya sea para inspección o reparación, representa un costo operacional significativo. El evitar estos costos mediante un pronóstico y diagnóstico de falla exacto de las fallas potenciales representa una oportunidad de ahorro de costo importante para los operadores y propietarios de la máquina. Como un medio adicional para reducir el tiempo no productivo, se ha enfocado en los procesos de diseño de ingeniería con el objetivo de incrementar el tiempo promedio entre las fallas para los subsistemas y componentes. Mientras que esto es ciertamente un objetivo recomendable, aún resta que los propietarios continúen con sus metas de mantenimiento de costo a través de la recolección y verificación de datos de funcionamiento en tiempo real y de información relacionada con la falla directamente del vehículo, y la implementación de reparaciones antes de que el problema requiera un tiempo reproductivo significativo.
COMPENDIO DE LA INVENCIÓN
Generalmente hablando, la presente invención cumple con las necesidades anteriores proporcionando el método para analizar datos de funcionamiento en tiempo real y para identificar una pluralidad de fallas y fallas críticas en máquinas. El método generalmente incluye recolectar de una pluralidad determinada de máquinas datos de
n. .....^...... ,. *m.m m ^flgflr t üifflffir i iiílTJiíl ftt t i I máquina respectivos que indica el funcionamiento sobre un período de tiempo predeterminado. El método además incluye pasos de identificación respectivos que permiten la identificación en los datos de máquina recolectados de fallas respectivas que ocurren más 5 frecuentemente con relación una de la otra y para identificar las fallas que ocurren más frecuentemente, fallas respectivas que, relacionadas una con la otra, afecta un número mayor de máquinas. Un paso de clasificación permite clasificar las fallas identificadas en el paso de identificación antes mencionado en base al nivel esperado
10 de degradación de máquina asociado con las fallas identificadas. El paso de almacenado permite almacenar en una base de datos de fallas críticas, cualquier falla clasificada como probable de suceder
• en una falla de emisión de máquina inminente. El sistema además incluye medios para identificar en los datos
15 de máquina recolectados fallas respectivas que ocurren más frecuentemente con relación una de la otra. También se proporcionan medios para identificar, en las fallas que ocurren más frecuentemente, fallas respectivas que, relacionadas una con la otra, afectan un número mayor de máquinas. Los medios de clasificación
• 20 permiten la clasificación de fallas identificadas con los medios de identificación antes mencionados en base a un nivel esperado de degradación de máquina asociada con las fallas identificadas. Una base de datos se acopla a los medios para clasificar y almacenar cualquier falla clasificada como probable de suceder en una falla de
25 emisión de máquina inminente, las fallas almacenadas comprenden la
pluralidad de fallas críticas. En una aplicación de la presente invención, cada locomotora en una flotilla de locomotoras de ferrocarril incluye un monitor a bordo para recolectar datos operativos en tiempo real. El monitor a bordo transmite datos de fallas y de funcionamiento regularmente a un centro de servicio de diagnóstico y de verificación, donde la presente invención analiza los datos recibidos. Pueden existir tantas como 3,000 locomotoras en una flotilla, cada una reportando datos diariamente. Dicha enorme cantidad de datos fácilmente sobrecargaría un operador humano. Por lo tanto es necesario automatizar la ejecución de las herramientas de análisis de modo que el análisis de los datos de funcionamiento paramétricos y de fallas de las descargas de datos automatizadas pueda lograrse en una manera productiva y eficiente. De acuerdo con las enseñanzas de la presente invención, la programación y ejecución de cada herramienta de análisis de falla ocurre sin intervención humana y se basa en criterios de tiempo crítico y dinámicos aplicados a los datos recibidos. Por ejemplo, uno de dichos criterios puede ser la prioridad de los datos en fila que espera el análisis. La presente invención automáticamente programa, da prioridad y vigila la ejecución de una o más herramientas de análisis y diagnóstico para analizar los datos de locomotora. El programador de análisis de la presente invención también lleva a cabo una verificación en línea de los datos descargados, da prioridad a los datos en fila para cada herramienta de análisis, y asegura que
^^¿^^^^^^^^^^^^^^^MS^^j^^ s^^m^^^^^^^^^^^^^á^^^^ todos los pre-requisitos sean cumplidos antes de activar la ejecución de una herramienta de análisis o diagnósticos. En una modalidad, por ejemplo, pueden existir límites en el número de instancias que cada herramienta puede ejecutarse simultáneamente, y los límites 5 pueden depender de la prioridad de los datos. Por ejemplo, un límite se aplica a los datos de prioridad normales y un segundo límite se aplica a los datos de alta prioridad. El programador de análisis mantiene y ejecuta estos límites. En el caso de que ocurra una interrupción de sistema, el programador de análisis automáticamente
10 puede iniciar cada herramienta de análisis que estuviera en proceso cuando haya ocurrido la interrupción. En el caso de una falla de herramienta de análisis, el programador automático vuelve a intentar
• a operación de la herramienta que falló, hasta que se alcance un límite de reintento predeterminado. 15 Después de la ejecución de las herramientas de análisis, la presente invención crea un caso de problema para cada problema o anomalía identificada por el proceso de análisis automatizado. Para enfocar los recursos humanos limitados en la resolución de problemas actuales, es deseable automáticamente crear los casos
• 20 problema. El caso de problema incorpora los resultados de los múltiples análisis de herramientas de diagnóstico e incluye todos los datos relevantes, incluyendo síntomas, la naturaleza de cualquier falla, parámetros de funcionamiento de almacenado, información de diagnóstico, y recomendaciones de reparación como fueron
25 generadas por el proceso de análisis automatizado. El generador de
caso de problema muestra toda esta información visualmente para que pueda ser vista por un experto en reparación y diagnóstico humano.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
La presente invención puede entenderse más fácilmente y las ventajas y usos de la misma pueden ser evidentes, tomando en consideración la descripción de las modalidades preferidas y los siguientes dibujos en los cuales: La Figura 1 muestra una máquina ejemplar, por ejemplo, una locomotora, que puede fácilmente beneficiarse de las enseñanzas de la presente invención; La Figura 2 ilustra los dispositivos periféricos con los cuales se comunica el programador de análisis de la presente invención; La Figura 3 representa una implementación de dicho procesador de la presente invención; La Figuras 4, 5A, 5B, 6 y 7 ilustran subprocesos del programador de análisis de la presente invención; La Figura 8 ilustra el proceso de creación de caso de la presente invención; Las Figuras 9A y 9B son diagramas de flujo de software que representan el proceso de creación de caso; Las Figuras 10, 11, 12, 13, 14 y 15 ilustran la operación de las herramientas de diagnóstico y de análisis mostradas en la Figura 8;
^¿¿^^^^^»^^^^^^^^fe ^^^^Afe^^^A^¡^^fej ^¡^ ^¿¿ La Figura 16 ilustra los procesos de detección de repetición de caso de la presente invención; y La Figura 17 es un diagrama de flujo que ilustra la identificación de fallas críticas.
DESCRIPCIÓN DETALLADA DE LAS MODALIDADES PREFERIDAS
La Figura 1 muestra una vista esquemática de una locomotora ejemplar 2. La locomotora puede ser una locomotora de corriente 10 directa o de corriente alterna. La locomotora 2 está compuesta de varios sistemas complejos, cada uno realizando funciones separadas. Algunos de los sistemas y sus funciones se mencionarán más
• adelante. Nótese que la locomotora 2 está compuesta de muchos otros sistemas y que la presente invención no se limita a los 15 sistemas descritos aquí. Un sistema de freno de aire y de aire 4 proporciona aire comprimido a la locomotora, que utiliza el aire comprimido para activar los frenos de aire en la locomotora y los vagones detrás de la misma. • 20 Un sistema de alternador 5 auxiliar alimenta todo el equipo auxiliar. En particular, suministra energía directamente a un motor soplador auxiliar y a un motor ventilador. Otro equipo en la locomotora es alimentado a través de un saltador de ciclo. Una batería suministra energía a un sistema de palanca 6 para 25 iniciar la operación de un motor a diesel para la operación de una
barra colectora de corriente directa y un sistema HVAC. La barra colectora de corriente directa a su vez proporciona voltaje para mantener la batería a una carga óptima. El sistema de comunicaciones de intracomposición recolecta, 5 distribuye y muestra datos de composición a través de todas las locomotoras en la composición. Un sistema de señal de cabina 7 enlaza el lado del camino al sistema de control de tren. En particular, el sistema 7 recibe señales codificadas de los rieles a través de receptores de riel localizados en 10 la parte frontal y trasera de la locomotora. La información recibida se utiliza para informar al operador de la locomotora del límite de velocidad y del modo de operación. • Un sistema de control de energía distribuido proporciona capacidad de control remoto de composiciones de locomotora
15 múltiples en el tren. También proporciona control de energía de tracción para hacer andar y frenar, al igual que el control de freno de aire. Un sistema de enfriamiento de motor 8 proporciona los medios mediante los cuales el motor y los otros componentes rechazan el
• 20 calor al agua de enfriamiento. Además, minimiza el ciclo térmico del motor manteniendo una temperatura de motor óptima a través del rango de carga y eviten el sobrecalentamiento en los túneles. Un extremo del sistema de tren proporciona comunicación entre la cabina de la locomotora y el último vagón, por medio de un enlace 25 de radio, para el propósito de frenado de emergencia.
»»-*h. fc-i^Mt, aa --^-?TJ-Jrtiliiiiil Un sistema de ventilación de equipo 9 proporciona los medios para enfriar el equipo de locomotora. Un sistema de grabación de evento registra los datos FRA
(Administración de Ferrocarril Federal) requeridos y los datos definidos limitados para la evaluación del operador y la investigación de accidentes. Puede almacenar hasta 72 horas de datos, por ejemplo. Un sistema de verificación de combustible proporciona medios para verificar el nivel del combustible y proporcionar la información a la tripulación. Un sistema de colocación global ejemplar utiliza señales de satélite para proporcionar mediciones de altitud, velocidad y posición exacta a los diferentes sistemas de control. Además, también proporciona una referencia UTC precisa al sistema de control. Un sistema de paquete de comunicación móvil proporciona el enlace de datos principal entre la locomotora y el lado del camino por medio de una radio adecuado (por ejemplo, una radio de 900 MHz). Un sistema de propulsión 10 proporciona los medios para mover la locomotora. También incluye los motores de tracción y la capacidad del frenado dinámico. En particular, el sistema de propulsión 10 recibe energía del alternador de tracción y a través de los motores de tracción la convierte en movimiento de locomotora. Un sistema de recursos compartidos incluye los dispositivos de comunicación l/O, que son compartidos por sistemas múltiples.
t,U, «JfcMM **ké*^. *~ .^ f] |rtri|%.*-»t^-^^S ^^g¿^^...^-,M1||t .^H^ Un sistema de alternador de tracción 11 convierte la energía mecánica a energía eléctrica la cual entonces se proporciona ai sistema de propulsión. Un sistema de control de vehículo de los datos introducidos por 5 el operador y determina los modos de operación de la locomotora. Los sistemas antes mencionados son verificados por un sistema de monitor a bordo (OBM) 12. El sistema OBM 12 mantiene un
• registro de cualquiera de los incidentes que ocurren en los sistemas con un registro de incidentes. La locomotora 2 puede opcionalmente 10 incluir un sistema de diagnóstico a bordo 13, como se describe con detalles en la patente de E. U. A. No. 5,845,272. La Figura 2 muestra un programador de análisis 15 y los
• diferentes cuadros y bases de datos con los cuales se comunica. El programador de análisis 15 se implementa como un dispositivo de 15 cómputo como se ilustra en la Figura 3. Los elementos del dispositivo de cómputo son bien conocidos por aquellos expertos en la técnica e incluyen un microprocesador 16, una memoria no volátil 17, una RAM 18, y una interfaz de entrada/salida 19. La estructura y operación de estos dispositivos son convencionales en todos los
• 20 aspectos y bien conocidas. Regresando a la Figura 2, un módulo de descarga 20 recibe datos de fallas y funcionamiento, por ejemplo de un sistema de monitor a bordo 12. El módulo de descarga 20 recibe los datos de falla y de funcionamiento, crea un caso de descarga que incluye los
25 datos descargados, e introduce el cargo del caso de descarga un
tAJ.Ati.»fl3fe-».i J t .?mhM* , a^»».a...i^<á^j>>¿A^¿^ja^«,aiQo¿^a¿¿<^.-'-^^^»?'..A ¿«Ai tí cuadro de datos de funcionamiento 21 y un cuadro de datos de falla 22. Los datos descargados durante una sesión de descarga con una locomotora dada se ensamblan automáticamente para formar un caso de descarga de acuerdo con las enseñanzas de la presente invención. La información relevante al caso de descarga puede más adelante "unirse" a este caso de descarga y sus subcasos. Diferentes casos de descarga son creados cada vez que los datos son descargados de una locomotora. El módulo de descarga 20 también adiciona un registro a un cuadro de estado de descarga 24 cuando la carga de datos de falla u otros datos al cuadro de datos de falla y de funcionamiento 22 está completa. El programador de análisis 15 verifica el cuadro de estado de descarga 24 y activa las diferentes herramientas de análisis y diagnóstico, como se discutirá más adelante, cuando los datos necesarios por aquellas herramientas están disponibles en el cuadro de datos de falla y de funcionamiento 22, o en otras palabras, cuando se completa la creación del caso de descarga. El programador de análisis 15 borra las entradas en el cuadro de estado de descarga 24 cuando la ejecución de la herramienta en los datos descargados ha sido programada, es decir, cuando se ha creado un registro en una fila 34. En una modalidad, cada herramienta tiene una fila única, aunque esto no se muestra específicamente en la Figura 1. Específicamente, cuando el cuadro de estado y de descarga 24 indica que una descarga particular de datos está completa, el
programador de análisis 15 crea un subcaso de herramienta de descarga, es decir, un subcaso para el caso de descarga, para cada herramienta que procesará los datos descargados y enseguida despacha un registro de aquel subcaso de herramienta de descarga a la fila 34 para esa herramienta específica. Los subcasos se almacenan en un cuadro de subcaso 26. Se le da prioridad a la ejecución de herramienta actual sobre los datos específicos por el tipo de datos en la fila 34 y también en tiempo cuando el registro de subcaso de herramienta de descarga fue creado. Ciertos tipos de datos de falla y de funcionamiento descargados tendrán mayor prioridad que otros. El programador de análisis 10 recoge las herramientas, como se discutirá más adelante. A medida que las diferentes herramientas de análisis procesan los datos descargados, crean datos de salida impropios. Cada subcaso de herramienta de descarga es aumentado con estos datos de salida de la herramienta de análisis asociada, al igual que la información de estado acerca del progreso de la ejecución de la herramienta. El programador de análisis 15 actualiza la información de ejecución de herramienta en los subcasos de herramienta de descarga, como se almacenan en el cuadro de subcaso 26. cada subcaso de herramienta de descarga incluye una entrada de estado de herramienta que indica el estado de ejecución de cada herramienta. Por ejemplo, una sola herramienta puede correr simultáneamente en cuatro diferentes paquetes de datos de falla y de funcionamiento, es decir, casos de descarga. Cada una de estas
cuatro ejecuciones muy probablemente será a un punto diferente en el proceso de ejecución de herramienta, y la ejecución de herramienta puede tomar varios minutos, dependiendo de la cantidad de datos que será procesada y la herramienta específica. De este 5 modo, el subcaso de herramienta de descarga refleja el estado que está corriendo de cada herramienta para cada instancia simultánea para la herramienta. Incluidos entre estos indicadores de estado se
• encuentran: ejecución no iniciada, la herramienta ha excedido su límite de reintento, la herramienta ha excedido su límite de tiempo de
10 ejecución, la ejecución de herramienta ha sido completada normalmente, y una serie de valores secuenciales, en donde cada valor en la secuencia indica el punto actual en la línea de tiempo de ejecución de herramienta. El programador de análisis 15, al revisar el subcaso de herramienta de descarga en el cuadro de subcaso 26,
15 puede detectar cuando sea completada una ejecución de herramienta específica, cuando ha fallado o cuando ha terminado antes de haberse completado. Un cuadro de ejecución de herramienta 28 contiene un registro para cada herramienta, incluyendo parámetros operativos para cada
20 herramienta, como pre-requisitos de ejecución y límites de ejecución. Uno de estos parámetros fija un límite sobre el número de ejemplos simultáneos para la herramienta cuando una ejecución de prioridad normal se encuentra siguiente en la fila. Existe también un límite de ejemplificación separado que se puede aplicar a tareas de alta
25 prioridad en la fila. El cuadro de ejecución de herramienta 28
también incluye varios requerimientos de valor pre-requeridos, por ejemplo, un requerimiento de que una cierta herramienta debe correrse antes de que otra herramienta pueda procesar los datos. Las filas son verificadas y las herramientas activadas de acuerdo con 5 estos controles almacenados en el cuadro de ejecución de herramienta 28. Cuando un número de tareas de ejecución cae por debajo del límite de prioridad normal, la siguiente tarea (en orden de prioridad) en la fila será recogida. Si una tarea de alta prioridad se encuentra en fila, entonces el límite de prioridad normal se ignora a
10 favor de la tarea de alta prioridad. Mientras que no se exceda el límite de alta prioridad, la tarea de alta prioridad se activa para su procesamiento. Un cuadro de configuración 30 almacena información que indica que herramientas (y que versiones de las mismas) deberán correrse
15 para descargar casos de un número de camino de locomotora específico. Por ejemplo, los cambios de número de versión de herramienta representan cambios en el software de herramienta, que pueden hacer que la herramienta sea incompatible con ciertos datos descargados. Como resultado, los datos descargados pueden primero
• 20 requerir la conversión de unidades de modificación, por ejemplo, antes de correr las herramientas en los datos. El cuadro de configuración 30 también incluye la ubicación de archivo de los ejecutables de herramienta. Cada caso de descarga se almacena en el cuadro de caso de
25 descarga 32. Como se mencionó anteriormente, cada caso de
descarga incluye los datos de falla y de funcionamiento específicos de una locomotora. En los subcasos de herramienta de descarga, la información descargada es agrupada a paquetes para su ejecución por cualquiera de las herramientas de análisis o diagnóstico. Los 5 subcasos de herramienta de descarga individuales creados bajo cada caso de descarga incluyen los datos de falla y de funcionamiento que serán procesados por la herramienta. Después de que se ha creado
• un subcaso de herramienta de descarga y se han hecho entradas apropiadas en el cuadro de subcaso 26, el programador de análisis
10 15 mueve el subcaso de herramienta de descarga a una fila 34. De aquí, el subcaso de herramienta de descarga será ejecutado por la herramienta identificada, cuando el procesamiento alcanza ese punto
• en la fila 34. En la Figura 2 también ilustra que el programador de análisis 15 controla que las herramientas corran, después de que
15 toda la información pertinente está disponible. Esto se muestra generalmente por el cuadro que porta el carácter de referencia 36 y se discutirá con detalle más adelante en conjunto con los diagramas de flujo de las Figuras 4-7. También, la operación de un generador de caso de problema 31 se discutirá más adelante. Una vez que se
• 20 completa un subcaso de herramienta de descarga (es decir, el procesamiento de datos por la herramienta termina) entonces el programador de análisis 10 cierra ese subcaso de herramienta de descarga en el cuadro de caso de descarga 32. La Figura 4 ¡lustra el proceso ejecutado por el programador de
25 análisis 15 en preparación para correr una herramienta de análisis
de diagnóstico. El procesamiento comienza en el paso de inicio 40 y continúa hasta el paso de decisión 42 donde se hace una encuesta en cuanto a si uno o más registros en el cuadro de estado de descarga 24 incluye que el procesamiento no ha sido aún iniciado en un caso de descarga, es decir, los datos de falla o de funcionamiento recibidos de la locomotora. Si el resultado del paso de decisión es verdadero, el procesamiento se mueve a un paso 44 donde la entrada que corresponde a los datos de más alta prioridad se selecciona para ser procesados. En el paso 46, el programador de análisis 15 localiza el caso de descarga asociado en el cuadro de caso de descarga 32, la información de ejecución y configuración de herramienta necesarias del cuadro de configuración 30 y el cuadro de ejecución de herramienta 28. En el paso 48, el programador de análisis 15 crea los registros de subcaso de herramienta de descarga en el cuadro de subcaso 26 (en base a la información en el cuadro de configuración 30 y el cuadro de ejecución de herramienta 28) y mueve la información pertinente a la fila 34. Ahora que la información ha sido puesta en fila, en el paso 50, el programador de análisis 15 borra el registro de caso de descarga asociado en el cuadro de estado de descarga 24. Un caso de compromiso 51 asegura que las modificaciones hechas en los pasos 48 y 50 actualizan los cuadros apropiados simultáneamente. El procesamiento entonces regresa al paso de decisión 42, para recuperar los casos de descarga adicionales. Si el resultado de paso de decisión 42 es falso, en el paso 52,
¿ia mAí^a el programador de análisis 15 recupera el tiempo de espera de un cuadro de parámetro de sistema 23 de la Figura 2 y enseguida cae en un modo de espera, como se indica en el paso 53. Cuando vence el tiempo de espera, el procesamiento regresa al paso de decisión 42, donde los registro en el cuadro de estado de descarga 42 se revisan una vez más. Las Figuras 5A y 5B son los diagramas de flujo de proceso para el software que recoge la herramienta, que lanza la ejecución de cada una de las herramientas de diagnóstico y de análisis. El software que recoge la herramienta es otro componente de software del programador de análisis 15 y es ejecutado por el mismo. Solo existe un recogedor de herramienta para cada herramienta, como es ejecutado por el programador de análisis 15. El procesamiento comienza en el paso de inicio 48 en donde la identificación de herramienta específica se introduce en el proceso recogedor de herramienta. En el paso 59, el tiempo de espera del recogedor es recuperado y en el paso 60 los parámetros de ejecución de herramienta (del cuadro de ejecución de herramienta 18 y el cuadro de configuración 30) se introducen en el recogedor de herramienta. Por ejemplo, uno de estos parámetros es el número de prioridades de herramienta simultáneas de alta prioridad permitidas. El procesamiento entonces se mueve al paso 61 donde el subcaso de herramienta de descarga de más alta prioridad para el cual se requiere un reintento (es decir, donde el valor del señalizador de reintento es uno) se selecciona Se requiere un reintento, por
ejemplo, si el sistema se cae mientras que la herramienta está procesando los datos de prioridad de herramienta de descarga. El establecimiento del señalizador de reintento se discutirá más adelante en conjunto con la Figura 5. El procesamiento entonces se 5 mueve a un paso de prioridad 62 donde se revisa la cuenta de selección. Si los datos fueron seleccionados en el paso 61, entonces la cuenta de selección tendrá un valor que no será cero y el procesamiento continúa al paso 63 donde se recoge la prioridad de herramienta (es decir, la herramienta procesa los datos). 10 Si no se seleccionaron datos en el paso 61, debido a que no existe registro de prioridad de herramienta de descarga esperando una prioridad de reintento, el resultado del paso de prioridad 62 es
• verdadero, el procesamiento se mueve a un paso 64. En el paso 64, el recogedor de herramienta cuenta el número de prioridad de
15 herramienta de descarga que están actuando y recorriendo bajo esa herramienta, y fija un valor de cuenta de prioridad igual a ese número. El procesamiento entonces se mueve a un paso 65 donde el recogedor de herramienta selecciona la prioridad de herramienta de descarga de alta prioridad en la fila 34 para los cuales se han
• 20 cumplido todos los pre-requisitos (incluyendo la completación del proceso de descarga) pero que tiene un valor de señalizador de reintento igual a cero. En el paso de prioridad 66, se revisa la cuenta de selección del paso 65. Si se seleccionó un registro de prioridad de herramienta de descarga en el paso 65, el resultado del paso 66
25 será falso y el procesamiento se mueve a un paso de prioridad 67.
ÍifeÍJ^ É¡A A,, Aquí, la cuenta de prioridad (que representa el número de casos de herramienta de descarga en proceso) se compara el límite simultáneo para casos de alta prioridad. Si el último valor es mayor que o igual al anterior, entonces no se pueden recoger prioridades de herramienta adicionales y el procesamiento se mueve al paso de espera 68. Nótese que el tiempo de espera para cada herramienta específica fue introduciendo prioridades al recogedor de herramienta en el paso 59. Después de que el tiempo de espera ha transcurrido, el procesamiento regresa al paso 64. Si el límite de prioridad simultáneo no se excede, la decisión del paso 67 produce un resultado verdadero y la herramienta se recoge en el paso 73. Si no se seleccionaron subcasos de herramienta de descarga de "alta prioridad" en el paso 64, el resultado del paso de decisión 66 es verdadero el procesamiento se mueve al paso 69. Aquí, los subcasos de herramienta de descarga de prioridad normal se examinan para determinar si cualquiera tiene todos los pre-requisitos satisfechos y por lo tanto está listo para correrse. En el paso de decisión 70, el valor de selección establecido en el paso 69 se revisa y si es cero, indicando que no se hicieron selecciones en el paso 69, el procesamiento se mueve al paso de espera 71. Después de que ha transcurrido el tiempo en espera, el procesamiento se mueve del paso de espera 71 de regreso al paso 64. Si el paso 69 dio como resultado una selección, el resultado del paso de decisión 70 es falso y el procesamiento se mueve a un paso de decisión 72. Aquí la cuenta de ejecución se compara con el límite de ejecución simultáneo para los subcasos de herramienta de descarga de prioridad normal. Si el resultado es verdadero, el procesamiento se mueve al paso 73 donde se recoge la herramienta que está corriendo. Si el resultado del paso de decisión 72 es falso, el proceso espera, como se indica por el paso de espera 74. Al alertarse, el procesamiento regresa al paso 64. Después del paso 73, el proceso regresa al paso 64 para una vez más establecer la cuenta de ejecución y seleccionar casos para recoger herramientas en el paso 65 y 69. El proceso de software de monitor de herramienta, ilustrado en la Figura 6, verifica la ejecución de las diferentes herramientas asociadas con la presente invención para asegurar que la ejecución de herramienta no está excediendo ningún límite de herramienta. El procesamiento comienza en el paso de inicio 77 y continúa al paso 78 donde el tiempo de espera de monitor se obtiene del cuado de configuración 30 y se fija a un valor para indicar el paso inicial a través del monitor de herramienta. En el paso 79, se obtienen los parámetros de ejecución de herramienta del cuado de ejecución de herramienta 28. En el paso 80, los subcasos de herramienta de descarga se seleccionan en cuanto al orden de prioridad entre aquellos subcasos de herramienta de descarga que se están ejecutando. Del paso 80, el procesamiento se mueve al paso 81 donde el siguiente (o primero, como sea el caso) subcaso de herramienta de descarga en la lista se obtiene. En el paso de decisión 82, se hace una revisión para determinar si se está
iMii^.¡? .-..?^?s^s.^íi??tíi« féílS'- -l-jA'<?!Ma.>«^??AiMt.Aátil-«A,< procesando el subscaso de herramienta de descarga. Si se ejecuta el subcaso de herramienta de descarga, el procesamiento se mueve a un paso de decisión 83. Si esta es la primera vez para el procesamiento del subcaso de herramienta de descarga, la decisión del paso de decisión 83 es verdadera. El procesamiento entonces continúa a un paso 84 donde el señalizador de reintento se establece en uno y el subcaso de herramienta de descarga se compromete a ser ejecutado por la herramienta. Si no es el primer intento de procesamiento, el resultado del paso de decisión 83 es falso y en el paso de decisión 85, la cuanta de reinicio (que es un valor contenido dentro del registro de subcaso de herramienta de descarga) se compara con el límite de reintento. Si la cuenta es mayor que o igual al límite de reintento, entonces la ejecución se termina en el paso 86 del subcaso removido de la fila. Si el límite de reintento no ha sido alcanzado, el procesamiento se mueve del paso de decisión 85 de regreso al paso 84 y el subcaso se hace esperar para su procesamiento a través de la herramienta. Si el subcaso de herramienta de descarga no está actualmente siendo procesado, el resultado del paso de decisión 82 es falso. El procesamiento entonces se mueve a paso 87 donde se calcula el tiempo de procesamiento transcurrido. En el paso de decisión 88, el tiempo de procesamiento se compara con el límite de tiempo de procesamiento. Si el límite ha sido excedido, el procesamiento se mueve al paso 86 donde se termina la ejecución. Cuando se termina una ejecución, se crea un registro llamando la atención del usuario
r^&TJbdk .AyJk, del sistema acerca de esta ocurrencia. En este punto, se requiere la intervención humana para resolver un problema de procesamiento. Por ejemplo, el procesamiento puede haber sido no exitoso debido a los datos conocidos en el caso de descarga. Si el resultado del paso 5 de decisión 88 es falso, la herramienta continúa ejecutando el subcaso y el proceso de monitor de herramienta se mueve a un paso de decisión 89. Nótese que el procesamiento también se mueve al
• paso de decisión 89, después del paso 84. En el paso de decisión 89, si el final de la lista no ha sido alcanzado, el procesamiento
10 regresa al paso 81 para buscar el siguiente subcaso de herramienta de descarga. Si el final de la lista ha sido alcanzado, el primer señalizador de tiempo se fija en "no" en el paso 90. El monitor de
• herramienta entonces espera, como se indica en el paso 91. Cuando el tiempo de espera vence, el procesamiento regresa al paso 80
15 donde una vez más se recuperan los subcasos de herramienta de descarga. El programador de análisis 15 también cierra la ejecución de herramienta después de procesar todos los subcasos de herramienta de descarga. La Figura 7 ilustra los pasos de software para un
• 20 programa de cierre de caso de descarga ejecutado para el programador de análisis 15. El procesamiento comienza en el paso de inicio 94 y continúa a un paso de decisión 95. Aquí los casos de descarga se examinan para determinar si alguno indica que tanto las descargas de falla como de parámetro han sido completadas y todos
25 los subcasos de herramienta de descarga bajo el caso de descarga
iiÍB*AjÍ^.f.--¿«*^t^vfe&i^ han sido cerrados después del procesamiento de herramienta del subcaso de herramienta de descarga, o la descarga ha fallado debido a problemas de comunicación. Si cualquiera de estas declaraciones es verdadera, el procesamiento se mueve al paso 96 donde se cierra el caso de descarga. Una vez que se han cerrado todos los subcasos de herramienta de descarga, el caso de descarga correspondiente puede cerrarse. También, si la descarga de datos de la locomotora ha fallado, el caso de descarga puede cerrarse. Si la respuesta del paso de decisión 95 es falsa, el cierre de caso descarga el tiempo de espera de la base de datos en el paso 97. El programa de cierre de caso entonces espera, como se indica en el paso de espera 98. Al final de tiempo de espera, el procesamiento regresa al paso de decisión 95. En una modalidad de la presente invención, el tiempo de espera es 24 horas. La Figura 8 ilustra el proceso utilizado por la presente invención para crear un caso de reparación y de análisis, de otro modo denominado como un caso de problema. Un caso de problema es una recolección de información relevante con una o más fallas o anomalías de funcionamiento, por ejemplo, como se aplica en la presente invención, el caso incluye información de entrada de las diferentes herramientas de diagnóstico y de análisis, códigos de reparación de fallas, identificación de fallas críticas, y datos de código de anomalías asociados con el caso descargado. En comparación con el caso de problema, el caso de descarga comprende la información parámetrica de funcionamiento descargada de la locomotora, o en otras modalidades, la máquina o el vehículo. El caso de problema también incluye recomendaciones de reparación y mantenimiento, una vez más como se determina por las herramientas de diagnóstico de análisis. Toda la información de caso está disponible para un usuario, que es alguien conocedor en el área de la operación, fallas y reparación de locomotoras. El usuario revisa el caso para determinar la exactitud de la información presentada en éste y puede además anexar información adicional. Por ejemplo, el usuario puede adicionar recomendaciones de reparación en base sus experiencias. Una vez que se completa el caso de problema, el usuario transmite el caso al personal de servicio y mantenimiento de ferrocarril. Esto puede lograrse simplemente llamando al ferrocarril enviando el caso por medio de correo electrónico. El objetivo es proporcionar el caso de problema al ferrocarril de modo que las recomendaciones de mantenimiento o reparación incluidas en este pueden ¡mplementarse en una manera oportuna para evitar que la locomotora se descomponga, o regresar una locomotora fuera de servicio a la flotilla. La mayoría del tiempo, el procesamiento de un caso de descarga dado no es significativo, y no existen fallas o anomalías de preocupación. En dichas situaciones, no se requiere un caso al problema, y el caso de descarga y los subcasos de herramienta de descarga se guardan para constar esto. Sin embargo, si una o más de las herramientas de análisis detecta una condición falla anómala, entonces se crea un caso de problema, que sirve para recolectar y
resumir todos los resultados de todas las herramientas de análisis. La Figura 8 muestra una locomotora que proporciona tres diferentes tipos de información a un sistema de creación de caso de problema construido de acuerdo con las enseñanzas de la presente invención. Como se discute con detalle en la patente aplicando el título "On-board Monitor for a Railroad Locomotive", citada anteriormente, varias fallas severas dentro de la locomotora inmediatamente genera una llamada a casa (como se define por el carácter de referencia 101) al centro de servicio de verificación y diagnóstico, donde reside el sistema de creación de caso de problema. Estas fallas son ya sea severas en naturaleza o requieren atención inmediata y de este modo crean un caso de problema directamente, como se indica por el paso de crear caso 102. (Ver también el generador de caso 137 en la Figura 1). Para crear el caso de problema, el proceso de llamada a casa inicia una descarga de datos de falla y una descarga de parámetros verificados como se muestra en el caso 104. El caso de problema entonces se crea en el paso 102. Más adelante, después de que sea analizada la información de parámetro verificada y de falla por las herramientas de diagnóstico, los resultados de éstas muy probablemente se adicionarán al caso de problema creado por la secuencia de llamada a casa. Es posible, sin embargo, que un nuevo caso de problema, derivado solamente de los datos descargados, pueda también crearse. Como se discutió anteriormente en conjunto con el programador
fcte«tAJ «*t*«..
de análisis 15, un paso 106 representa la descarga de datos de falla de la locomotora al centro de diagnóstico y de verificación donde ocurre el proceso de análisis. En una modalidad, los datos de falla se descargan por lo menos diariamente. Es posible, sin embargo, que no existan datos de falla al ser descargados y en este caso las herramientas de fallas no corren ya que no existen datos introducidos a ser analizados. Una vez que se descargan los datos de falla, el procesamiento se mueve al paso 108 donde se ejecuta el proceso de análisis programador como se discutió anteriormente en conjunto con el programador de análisis 10. En los pasos 110, 112, 114 y 116, se corren respectivamente las herramientas de razonamiento basado al caso (CVBR), la red de creencia Bayesiana (BBN), la clasificación de falla y la detección de anomalía de paquete de datos (DPAD). Estas herramientas son ejemplos de herramientas de análisis de datos y de fallas que pueden utilizarse en conjunto con la presente invención. Aquellos expertos en la técnica reconocen que están disponibles otras herramientas de análisis similares. Estas herramientas, que fueron mencionadas generalmente por el paso de proceso 36 en la Figura 2, se discutirán con detalle más adelante. Aunque no se muestra en la Figura 8, existe una fila de datos asociada con cada una de las herramientas presentadas. Estas filas contienen los datos hasta que la herramienta está disponible para su ejecución Esencialmente, cada herramienta analiza los datos en base a mediciones y reglas diferentes, incluyendo casos históricos (fallas, reparaciones e información paramétrica operacional) y esquemas de inteligencia artificial, para determinar la naturaleza de la falla e identificar reparaciones específicas (por el código de reparación) que puede implementarse para mejorar la falla. Las herramientas pueden 5 también identificar problemas incipientes dentro de la locomotora, y de este modo permitir que el ferrocarril tome una acción correctora antes de que el problema se torne más severo. Aunque las herramientas se muestran funcionando en una manera paralela en la Figura 7, como se conoce por aquellos
10 expertos en la técnica, esto no es un requisito necesario. Otras modalidades de la presente invención incluyen alternativas de ejecución. Por ejemplo, las herramientas pueden correr de manera serial o en paralelo después de que se ha creado un caso descargado (es decir, todos los datos pertinentes están disponibles
15 para la ejecución de herramientas) y cada uno de los subcasos de herramienta de descarga han sido creados, o cada herramienta puede correr independientemente después de que el subcaso de herramienta de descarga para esa herramienta específica esté disponible. Después de que todas las herramientas han procesado
• 20 los datos, el paso de detección de repetición de caso, se ilustra por el carácter de referencia 118 se ejecuta Finalmente, cada herramienta puede ejecutarse independientemente después de que se han completado sus subcasos de herramienta de descarga y enseguida inmediatamente ejecutar el paso de detección de
25 repetición de caso 118 La selección de una de estas alternativas no
m mm t?? M ñ » 1 riaiÉiiiafciiatf^,,.^^ es crucial para el alcance o funcionamiento esencial de la presente invención. El componente recogedor de herramienta (ilustrado en las Figuras 5A y 5B) de la presente invención controla la secuencia de 5 ejecución de las herramientas ilustradas en la Figura 8. Por supuesto, una herramienta no puede ejecutarse hasta que sea recolectada la información pre-requerida, es decir, hasta que se completa el subcaso de herramienta de descarga. El cuadro de ejecución de herramienta 28 ilustrado en la Figura 2 almacena las
10 condiciones que deben cumplirse antes de que se pueda correr una herramienta específica. La herramienta de detección de repetición de caso (del carácter de referencia 118 de la Figura 8) es una
• herramienta adicional de la presente invención para la cual se incluye información en el cuadro de ejecución de herramienta 28. La
15 herramienta de detección de repetición de caso 118 se corre para detectar casos repetitivos después de que se han ejecutado una o más de las otras herramientas de análisis. Las herramientas de detección de repetición de caso se discutirán más adelante en conjunto con las Figuras 9A y 9B. • 20 Cuando se crea un nuevo caso de problema, como se indica por el paso 102 de la Figura 8, se introduce cierta información dentro de los campos del caso para ayudar al usuario experto en el centro de servicio de diagnóstico y de verificación a analizar el caso de problema. La información en los campos de caso pude incluir: 25 códigos de falla y descripciones de sistemas que indican, códigos de
reparación y descripciones de reparaciones indicadas, códigos de anomalía y descripciones de avisos indicados, valores paramétricos verificados asociados con fallas, reparaciones y anomalías, factores de tolerancia o de probabilidad asociadas con los códigos indicados 5 (donde los factores de tolerancia indican la probabilidad de que la reparación indicada solucionará la falla indicada), la fecha, el tiempo durante el cual los datos fueron recolectados y número de camino de locomotora del cual fueron recolectados los datos. Regresando a la Figura 8, además de los datos de falla, la
10 descarga realizada por el paso 106, los datos de funcionamiento parámetricos también se descargan de la locomotora, como se identifica en el paso 124. El procesamiento del programador de
• análisis ocurre, (ver paso 126), como se discutió en conjunto con las Figuras 2-7, cuando se completa la descarga. Después del paso 126,
15 se corre la herramienta de detección de anomalía (ilustrada por el paso 128), y se corre la herramienta de tendencia (ilustrada por el paso 130). El problema de detección de repetición de caso entonces se corre en el paso 118. Si es necesario, se crea un caso en el paso 102 como se discutirá más adelante. • 20 Los diagramas de flujo de las Figuras 9A y 9B ilustran el algoritmo para crear un caso de acuerdo con la presente invención, combinando las características del paso 118 (correr la detección de repetición de caso) y 102 (crear casos problema). El procesamiento comienza en el paso 160, representando el proceso de descarga de
25 datos. Del paso 160, el procesamiento se mueve tanto al paso 162 como al paso 164. En el paso 162, las herramientas de razonamiento basa en caso (CBR), la red de creencia Bayesiana (BBN), y la anomalía de paquete de datos (DVAD) se ejecutan para el propósito de desarrollar un caso de problema ventajosamente para desarrollar recomendaciones de reparación para ese caso de problema. La ejecución de estas herramientas se discutirá con detalle más adelante. En el paso 162, las herramientas se corren utilizando su período de tiempo de retroconsulta normal. Como se discutirá más adelante, el tiempo de retroconsulta es aquel período medido desde el presente hasta el punto en el pasado, durante el cual los datos recolectados se procesarán por la herramienta. En un ejemplo, el período de retroconsulta es de 7 días. Por lo tanto, la herramienta analizará datos de falla proporcionados durante los últimos 7 días en un intento por clasificar fallas y desarrollar recomendaciones de reparación. Del paso 162, el procesamiento se mueve al paso de decisión 166 para determinar si se han generado recomendaciones de reparación por la herramienta de razonamiento basado en caso, la red de creencia Bayesiana, o la detección de anomalía de paquete de datos. Si no se ha recomendado ninguna de dichas reparaciones, entonces esta etapa del procesamiento se completa, como se ilustra en el paso 168. Si se recomendaron reparaciones, el procesamiento se mueve del paso de decisión 166 a otro paso de decisión 170, donde el proceso determina si existe algún caso de problema recomendado observado existente. Los casos cerrados son aquellos para los cuales las recomendaciones de reparación han sido
implementadas por el ferrocarril. Los casos recomendados son aquellos donde las recomendaciones de reparación han sido transmitidas al ferrocarril, y de este modo, en un sentido, no están ya sujetas a cambios o adiciones por el personal experto en el centro 5 de servicio de diagnóstico y de verificación. Solo los casos abiertos pueden aumentarse en cuanto a información desde su ejecución actual de las herramientas de diagnóstico y análisis. Si no existen casos cerrados o recomendados, el procesamiento se mueve al paso 172 donde las reparaciones recomendadas por la herramienta se
10 adicionan a la lista de reparaciones, identificada en la Figura 9A y 9B por el carácter de referencia 174. Si existen casos recomendados encerrados, entonces el
• procesamiento se mueve desde el paso de decisión 170 hasta el paso de decisión 180. El paso de decisión 180 determina si alguna
15 reparación recomendada es idéntica a las reparaciones en los casos problema recomendados encerrados que fueron creados dentro del período de tiempo de retroconsulta. Si no existen dichas reparaciones idénticas, entonces el procesamiento regresa al paso 172 donde se adicionan estas reparaciones o la lista de
• 20 reparaciones, donde pueden utilizarse posteriormente para crear un caso de problema. Si todas las reparaciones son idénticas a las reparaciones en los casos problemas recomendados cerrados, entonces es necesario cambiar el tiempo de retroconsulta de modo que solo los datos recolectados después del caso más recientemente
25 recomendado o cerrado se incluya en el análisis de herramienta. De
esta manera, el proceso asegura que sólo los datos de fallas y parámetros recolectados después de la recomendación de reparación más reciente puedan genera un nuevo caso de problema, debido a que los datos basados para crear un caso de problema recomendado o cerrado previo ya no son relevantes para crear nuevos casos problema. Si el ferrocarril ya no ha realizado una reparación recomendada, entonces el mismo tipo de falla se verá durante la siguiente descarga de información de funcionamiento y de falla resultante de la generación de las mismas recomendaciones de reparación. El proceso de detección de repetición de caso (ver carácter de referencia 118 de la Figura 8) entonces combinará el caso de problema recomendado actual con los casos problema recomendados existentes. Este cambio de intervalo de tiempo de retroconsulta es representado por el paso 182, en donde el período de retroconsulta cambia para comenzar inmediatamente después del caso más recientemente recomendado o cerrado. En el paso 184, las herramientas de razonamiento basado en caso, red de creencia Bayesiana y la anomalía de paquete de datos se vuelven a correr con el parámetro de retroconsulta modificado. En el paso de decisión 186, el proceso determina si se recomendaron reparaciones por la ejecución de herramienta en el paso 184, es decir, en base a volver a correr la herramienta utilizando el nuevo período de retroconsulta. Si no se recomendaron reparaciones, entonces esta etapa del procesamiento se completa, como se representa por el paso 190. Si existen reparaciones
fcA, ia¡¿«¿ u,ii?iM??-A**? Ét& --a«rt*t.«¿ - fc.tAA&aAjfcdbiHÁ recomendadas, pueden adicionarse a la lista de reparaciones, como se ilustra en el paso 188. Regresando al paso de datos de descarga 160, en el paso 164, se corre a las herramientas de detección de tendencia de anomalía y de detección de anomalía (AD). También, en el paso 196, se ejecutan las herramientas de detección de anomalía y de clasificación de falla. Todas las anomalías encontradas se adicionan a una lista de anomalías 200 en el paso 198. A partir del paso 164, después de que se ejecuta la herramienta de tendencia de anomalía, el procesamiento se mueve al paso de decisión 202 para determinar si se recomendaron anomalías. Si no se recomendaron, el procesamiento termina en el paso 204. Si se encontraron anomalías y se recomendaron, el procesamiento se mueve a un paso de decisión 206 donde, al igual que antes, el proceso determina si están abiertos casos problemas recomendados o existentes. Si no existe ningún caso de problema abierto, el procesamiento se mueve al paso 208 donde las nueva anomalías se adicionan a la lista de anomalías 200. Si existen casos problema recomendados o cerrados, entonces el paso 206 el procesamiento continúa a un paso de decisión 210. Aquí, se hace una determinación en cuanto a que si las anomalías detectadas son idénticas a cualquier tendencia de anomalía en los casos problema recomendados o cerrados. Si no existen dichas identidades, el procesamiento una vez más se mueve al paso 208, donde las anomalías de tendencia se adicionan a la lista de anomalías. Si una o más de las anomalías son idénticas a las anomalías enlistadas de los casos problema recomendados o cerrados, el procesamiento se mueve al paso 212 donde la herramienta de tendencia de anomalía se corre una vez más sin el uso del archivo de estado, que almacena tendencias operativas históricas. Este proceso de volver a correr las herramientas sin los archivos de estado remueve el efecto de anomalías que debieran haberse solucionado por los casos cerrados o recomendados previos. Después de que se vuelve a correr la herramienta de anomalía, en el paso de decisión 214, se hace una determinación en cuanto a que si se detectaron anomalías. Si no se detectaron, el procesamiento termina en el paso 216. Si sí se detectaron anomalías, se adicionan a la lista de anomalías mediante el procesamiento a través del paso 208. Después de que se adicionan las reparaciones a la lista de reparaciones 174 y se adicionan las anomalías a la lista de anomalías (representadas por el carácter de referencia 200) el procesamiento se mueve a un paso de decisión 222. Aquí, el proceso determina si existe algún caso de problema abierto. Si no existen casos problema abiertos en este punto, se crea un nuevo caso en el paso 224 y el procesamiento termina en el paso 226. El nuevo caso de problema contiene todas las anomalías de la lista de anomalías 200 y todas las reparaciones de la lista de reparaciones 174. Alternativamente, sí existen casos problemas abiertos, deberá determinarse si las reparaciones o anomalías pueden adicionarse a los mismos en el paso de decisión 230. Aquí se determina si existen
i^fc^feaa »^^^^^«;fe^«^>..8Jttea^^-.A=K.i iJ casos problema abiertos menores a x horas de edad, donde x es un valor de umbral asignado por el usuario. Si dicho caso de problema abierto está disponible, el procesamiento se mueve al paso 232 donde todas las anomalías y reparaciones se adicionan a la lista de 5 reparaciones para ese caso de problema. También, el caso de descarga para el cual se derivaron las anomalías y/o fallas se enlaza como un producto al caso de problema abierto. Los mismos síntomas de locomotora pueden aparecer en descargas múltiples sobre muchos días y todas las descargas deberán enlazarse al mismo caso de
10 problema abierto. Si no existen casos abiertos menores a x horas de edad, el procesamiento se mueve del paso de decisión 230 a un paso de
• decisión 234 para determinar si existen reparaciones en la lista de reparaciones 174. Si no existen reparaciones, entonces el
15 procesamiento continúa al paso de decisión 236 donde se determina donde se encuentran todas las anomalías en un caso abierto. Si la respuesta es no, el procesamiento se mueve al paso 238 donde se crea un nuevo caso que contiene todas las anomalías. El procesamiento entonces termina en el paso 226. Si todas las
• 20 anomalías ya se encuentran en un caso abierto, el procesamiento se mueve del paso de decisión 236 al paso 242 donde el caso de descarga del cual se derivaron las anomalías actuales se enlaza como un producto al caso de problema abierto. Regresando al paso de decisión 234, si existen reparaciones en
25 la lista de reparaciones 174, el procesamiento se mueve al paso de
.miií ¿^?míi..ríi......^¿í..i.. : Jmiií... iú..fíAÍa :.j .1,1 decisión 244. Aquí, se determina si todas las reparaciones son idénticas a aquellas en el caso de problema abierto. Si esto es una declaración verdadera, el procesamiento regresa al paso 242 donde el caso de descarga se enlaza como a un producto al caso de problema abierto. Si todas las reparaciones no son idénticas aquellas en el caso de problema abierto, el procesamiento se mueve del paso de decisión 244 al paso 224 donde se crea un nuevo caso de problema. El procesamiento entonces termina en el paso 226. La Figura 10 ilustra las características operativas de la herramienta de razonamiento basado en caso como se identifica por el carácter de referencia 299. En el contexto de la herramienta basada en caso, un "caso" es una recolección de fallas, anomalías, reparaciones recomendadas e información paramétrica operacional agregadas para el propósito de compararse con otros "casos" para determinar una reparación recomendada para solucionar la falla. Como discutió anteriormente, al pasar por primera vez, la herramienta de razonamiento basada en caso utiliza un periodo de retroconsulta estándar de 7 días. Esto puede modificarse para ejecuciones subsecuentes, también como se discutió anteriormente, dependiendo de si existen reparaciones idénticas a aquellas recomendadas por la herramienta de razonamiento basada en caso en un caso recomendado o cerrado. La herramienta de razonamiento basada en caso analiza los datos de falla y sus combinaciones, utilizando información de la base de caso de razonamiento basada en caso 300.
El cuadro de configuración 30 (ver Figura 2) identifica la versión de la herramienta de razonamiento basada en caso 299 que deberá correrse, en base al número de camino de locomotora del cual se obtuvieron los datos operativos paramétricos y de falla. El carácter de referencia 304 ilustra la introducción de información paramétrica operacional relacionada y de falla a la herramienta de razonamiento basada en caso 299. Los datos de falla cubren sólo el periodo de retroconsulta actual y se reduce el ruido. La reducción del ruido es el proceso de eliminar fallas conocidas en la locomotora. Por ejemplo, cuando la locomotora está en un estado de reposo, ciertos parámetros medidos pueden estar más allá de un umbral preestablecido y, por lo tanto, indicar falsamente la ocurrencia en una falla. El cuadro de configuración 30 también proporciona el umbral de probabilidad utilizado por la herramienta de razonamiento basado en caso como un límite de probabilidad para recomendar reparaciones. Si la herramienta de razonamiento basada en caso determina que la probabilidad de que una reparación específica resolverá una falla está por encima de un valor de probabilidad de umbral, entonces esa reparación (en la forma de un código de reparación) será reportada por la herramienta de razonamiento basada en caso 299. La herramienta de razonamiento basada en caso 299 da prioridad a las recomendaciones de reparación y reporta los cinco primeros códigos de reparación, como se representa por el carácter de referencia 306 Después del procesamiento por la herramienta de razonamiento
i, a AatfiJa.1- • ..t .-.Á?.í ¡a •>
40 basado en caso 299, el sistema correrá este proceso de detección de repetición de caso (ver carácter de referencia 118 en la Figura 8). La Figura 11 ilustra la herramienta de red de creencia Bayesiana 310. Cada versión de la herramienta de red de creencia Bayesiana 310 utiliza una base de regla específica, como se representa por el carácter de referencia 314. La configuración específica seleccionada se basa en el número de camino de locomotora. Un carácter de referencia 316 representa un cuadro de causa de enlace identificado por la herramienta de red de creencia Bayesiana 310 para reparaciones específicas para un caso de problema. La base de regla de red de creencia Bayesiana 314 también identifican los umbrales de probabilidad de reparación utilizados para dar prioridad a las reparaciones. Al igual que la herramienta de razonamiento basado en caso 299, la herramienta de red de creencia Bayesiana 310 utiliza una retroconsulta de 7 días en una modalidad. Esta retroconsulta se modifica (como se discute en conjunto con las Figuras 9A y 9B) para eliminar los efectos de los casos recomendados o se reduce. Los resultados de la herramienta de red de creencia Bayesiana 310 son los primeros tres códigos de reparación. Después de que corre la herramienta de red de creencia Bayesiana 310, el sistema corre la herramienta de detección de repetición de caso como se ilustra por el carácter de referencia 118 en la Figura 8. La Figura 12 ¡lustra la herramienta de clasificación de fallas 326. Esta herramienta recibe entradas del registro de fallas de la
descarga actual, al igual que las herramientas mencionadas previamente, como se muestra por el carácter de referencia 328. No existe un período de retroconsulta asociado con la ejecución de la herramienta de clasificación de fallas 326. También introducida a la herramienta de clasificación de fallas 326 se encuentra un cuadro de estrategia de servicios de fallas 330. Este cuadro comprende una lista de fallas típicas encontradas dentro de una locomotora de ferrocarril y una clasificación de prioridad para cada una. Cada falla en el cuadro es identificada con un valor indicador ya sea como una "falla crítica", "otra falla", o "no encontrada en el cuadro de estrategia de servicio de fallas". La herramienta de clasificación de fallas compara las fallas del registro de fallas 328 con aquellas enlistadas en el cuadro de estrategia de servicio de fallas 330, para asignar un valor indicador a cada falla. Los códigos de fallas resultantes con el valor indicador se representan por el carácter de referencia 330 en la Figura 12. La Figura 13 ilustra la herramienta de detección de anomalías del paquete de datos (DPAD) 336. Esta herramienta opera en datos paramétricos operativos de registro de fallas (también denominados como datos de "paquete de datos") (ver carácter de referencia 338) dentro del período de retroconsulta. Los datos del paquete de datos se recolectan cuando ocurre una falla y proporcionan una medida de condiciones operativas (voltaje, temperatura, etc.) de los sistemas de locomotora seleccionados. Las reglas DPAD se programan en la herramienta de detección de anomalías de paquete de datos 336, y la
herramienta de detección de anomalías de paquete de datos 336 se configura, utilizando el número de camino de locomotora, por parámetros en el cuadro de configuración 30. El "paquete de datos" consiste de 16 parámetros (en una modalidad) que son muestreados sobre la ocurrencia de cada falla. La herramienta de detección de anomalía de paquete de datos examina los valores paramétricos y la falla anexa para determinar una recomendación de reparación. El resultado de la herramienta de detección de anomalía de paquete de datos 336 es una lista de códigos de reparación que incluye todos los códigos de reparación que son indicados por el proceso de comparación de regla. Los códigos de reparación resultantes son representados generalmente en la Figura 13 por el carácter de referencia 344. La herramienta de detección de anomalía 350 se ilustra en la Figura 14. Esta herramienta analiza los parámetros recibidos del caso de descarga actual (del carácter de referencia 352) y compara los parámetros con los límites y criterios de las definiciones de anomalía. Un archivo de mapa de motor de diagnóstico 354 suministra códigos de anomalía internos que son mapeados en parámetros en el cuadro de definición de anomalías. De este modo, cuando un parámetro particular se correlaciona con una anomalía en el cuadro, la herramienta de detección de anomalía da como resultado el código interno asociado con esa anomalía. Los datos de configuración para la herramienta de detección de anomalías 350 se introduce desde un archivo de iniciación almacenado en el cuadro de
configuración 30. Este archivo proporciona los datos de configuración iniciales, incluyendo el número de versión de detección de anomalías que será ejecutado en base al número de camino de locomotora del cual se recolectaron los datos de funcionamiento paramétricos descargados. Los indicadores de anomalía proporcionados como un resultado por la herramienta de detección de anomalías 350 se indican por el carácter de referencia 360. Además de los indicadores de anomalías 360, la herramienta de detección de anomalías 350 proporciona parámetros derivados (por ejemplo, estadísticas) como un resultado. Estos se indican en la Figura 14 por el carácter de referencia 362. Estos parámetros derivados se calculan de los datos de funcionamiento paramétricos en el caso de descarga y se guardan en una base de datos o cuadros para utilizarse en gráficas y otros auxiliares de análisis. La Figura 15 ilustra la herramienta de anomalía de tendencia 370. Al igual que la herramienta de detección de anomalía 350, esta herramienta también compara parámetros operativos específicos de la locomotora con valores definidos en el cuadro de definición de anomalías, representado generalmente por el carácter de referencia 372. La información de configuración se proporciona del cuadro de configuración 30 para identificar la versión específica de la herramienta de anomalía de tendencia 370 que deberá operar en los datos, en base al número de camino de locomotora. Los parámetros de funcionamiento paramétpcos cargados de la locomotora (ilustrados por el carácter de referencia 376) se introducen en la
herramienta de tendencia 370. Sólo se utiliza información de caso de descarga actual por la herramienta de anomalía de tendencia 370. También introducido en la herramienta de anomalía de tendencia 370 se encuentra un archivo de estado 378, que incluye datos estadísticos (por ejemplo, desviación estándar media y promedio) derivada de los datos de funcionamiento históricos. La herramienta de anomalía de tendencia 370 analiza los datos de parámetro actuales contra las estadísticas históricas y compara los resultados de este análisis con límites y criterios establecidos en las definiciones de anomalía, como se proporciona en el cuadro de definición 372. La herramienta de anomalía de tendencia 370 da como resultado los identificadores de anomalía asociados con los resultados de este proceso de comparación (ver carácter de referencia 380), y actualiza las estadísticas contenidas dentro del archivo de estado, como se indica por el carácter de referencia 382. El archivo de estado vuelve a iniciarse si existen casos recomendados o cerrados dentro del periodo de retroconsulta. También obtenidos de la herramienta de anomalía de tendencia 370 se encuentran los parámetros 384, los cuales son útiles para crear gráficas, diagramas y otros auxiliares de análisis. Como se discutió en conjunto con las otras herramientas que se corren, seguido de la ejecución de la herramienta de anomalía de tendencia 370, se corre un programa de detección de repetición de caso (como se ilustra por el carácter de referencia 118 en la Figura 8). Para enfocar los recursos limitados para solucionar sólo nuevos
* * ** - ? lá&Áv ák&fM -üBBftl^ problemas no reportados," es necesario evitar la creación de nuevos casos problema cuando los casos existentes cubren el mismo problema previamente reportado. Las características del elemento de detección de repetición de caso incluye: la habilidad de distinguir un nuevo caso de problema en base a la realización de fallas detectadas, condiciones anómalas y reparaciones recomendadas reportadas por las herramientas de análisis automatizadas de la presente invención; la habilidad de crear un nuevo caso de problema para almacenar información a cerca de un nuevo problema, la habilidad de mantener un período de tiempo abierto de modo que los datos relacionados puedan analizarse y combinarse en un solo caso de problema si es necesario; y la habilidad de distinguir y enlazar datos relevantes adicionales a los casos preexistentes en lugar de crear un nuevo caso. Regresando a las Figuras 9A y 9B, el elemento de detección de repetición de caso de la presente invención se muestra dentro de las líneas punteadas identificado por el carácter de referencia 420. El resultado del proceso de detección de repetición de caso es la creación de un nuevo caso (ver pasos 224 y 238) o la adición de información de fallas y anomalías actuales a un caso existente, como se representa en el caso 232. El proceso de detección de repetición de caso también se muestra diagramáticamente en la Figura 16. Los caracteres referencia 422 y 424 representan valores de entrada al proceso de repetición de caso 420. El valor de entrada representado por el
?&,.,T,..T<s « ^=aB¿ 4d carácter de referencia 422 es el número de horas después de que se ha creado un caso de problema durante el cual todos los resultados de las herramientas deberán combinarse en un solo caso (ver carácter de referencia 422), en lugar de crear casos múltiples. Este valor de entrada es definido por el usuario y denominado como "x" en el paso de decisión 230 de la Figura 9A. Para correr el proceso de detección de repetición de caso, reparaciones actuales, fallas y anomalías identificadas por otras herramientas de análisis se utilizan como valores de entrada (ver carácter de referencia 424 de la Figura 16). Si no existen casos del problema dentro del periodo de combinación seleccionado, entonces se creará un nuevo caso de problema. Si sí existe un caso de problema dentro del período de combinación, entonces todas las recomendaciones de reparación hechas durante ese período (incluyendo las reparaciones recomendadas actuales) se combinan en un solo caso de problema. Como se discutió anteriormente, cada caso incluye las fallas de anomalías asociadas con la recomendación de reparación y por lo tanto esta información también está contenida dentro del caso de problema. Si el procesamiento está fuera del periodo de combinación de caso, el proceso de detección de repetición de caso 420 revisa todos los casos problema abiertos fuera del período de combinación de caso y fija el nuevo caso de problema como un producto a un caso de problema existente si las reparaciones de los dos casos problema concuerda y si la lista de anomalías o fallas en el nuevo caso de problema están contenidas en el caso de problema existente. Esta
IramimrtíiS? .Jbíik .lL-?r.
característica también se representa en el paso 232 y 242 de las Figuras 9A y 9B. Si no existe una concordancia, entonces se crea un nuevo caso de problema. La creación de un nuevo caso por el proceso de detección de repetición de caso 420 se representa en un paso de salida 426. Otra característica importante de la presente invención es el re-análisis de los casos problema creados después de la completación de una reparación recomendada. Este proceso se muestra en las Figuras 9A y 9B haciendo referencia al carácter 440. Este aspecto de la presente invención se implementa por el uso de un parámetro de retroconsulta como se discutió previamente aquí. El objetivo de esta característica es seleccionar anomalías o fallas que de hecho ya han sido solucionadas a través de recomendaciones o adiciones de reparación recientes. A continuación se muestra un resumen de los pasos implicados en el proceso de reanálisis 440. Las reparaciones no se adicionan a la lista si se cumplen todas las siguientes condiciones: los resultados del análisis indican que existe una condición anómala y/o es necesario un código de reparación (ver el paso de decisión 166 de la Figura 9A); la locomotora ha sido reparada o se han hecho recomendaciones de reparación recientemente (ver el paso de decisión 170 de la Figura 9A); y las condiciones anómalas y/o códigos de reparación son los mismos que aquellos que fueron identificados antes de la operación o recomendación de reparación (ver el paso de decisión 180 de la Figura 9A); los datos que indicaron una reparación o una condición
anómala se vuelven a analizar de modo que los datos de descarga de entrada que preceden la operación o recomendación de reparación no se incluyen dentro de ese re-análisis (ver el paso 182 de la Figura 9A; y el re-análisis indica que no está presente una condición anómala y que no se necesita una reparación (ver el paso 184 y el paso de decisión 186 de la Figura 9A). La Figura 17 ilustra el proceso para identificar ciertas fallas como fallas críticas y para indicar esto en el cuadro de estrategia de servicio de falla 330. Además, el monitor abordo comunica información de falla para su análisis de acuerdo con el proceso de análisis establecido aquí en base a una programación de tiempo específico o de acuerdo con la severidad de la falla particular encontrada. En particular, se requiere tener un proceso para determinar las llamadas "fallas críticas", como se definirá más adelante. La Figura 17 ilustra un diagrama de flujo ejemplar de un proceso para identificar malos funcionamientos, por ejemplo, fallas y/o parámetros operativos, que indican fallas de camino de locomotora inminentes. Al iniciar las operaciones en el paso 500, en el paso 502, todas las fallas registradas por un intervalo de tiempo predeterminado, por ejemplo, los últimos 12 meses o cualquier otro intervalo de tiempo seleccionado, se recuperan. Este paso se logra revisando, por ejemplo, los casos problemas creados en el paso 102 de la Figura 8. En el paso 504, el proceso identifica fallas que ocurren relativamente frecuentes. El paso 506 permite la
identificación de número de locomotoras que se ven afectadas en su mayoría por fallas que ocurren frecuentemente. Por ejemplo, como se muestra en el Cuadro 1 más adelante, el código de falla 1000 ocurre 1306 veces sobre un intervalo de tiempo predeterminado, el código de falla 1001 ocurre 500 veces sobre el mismo intervalo de tiempo, y el código de falla 1002 ocurre 1269 veces sobre el mismo intervalo de tiempo. Como se muestra adicionalmente en el Cuadro 1, aunque el código de falla 1002 ocurre más frecuentemente con relación al código de falla 1001, ya que el número de locomotoras afectas por el código de falla 1001 es mayor en comparación con el número de locomotoras afectas por el código de fallas 1002, entonces la clasificación relativa del código de falla 1001 en términos de porcentaje de flotilla afectado, es más alto para el código de falla 1001 que para el código de falla 1002. En un paso 508, las fallas son clasificadas en varios tipos de fallas, por ejemplo, críticas, restrictivas, no restrictivas, de interés especial, etc. Como se utiliza aquí, una falla crítica es una indicación de mal funcionamiento que pudiera indicar una pérdida completa inminente de la potencia de la locomotora, daño potencial al subsistema que está fallando y/o la locomotora, o cuestiones de seguridad. Una falla descriptiva es una indicación de mal funcionamiento que pudiera evitar que la locomotora operara a su funcionamiento o potencia total debido a, por ejemplo, malos funcionamientos mecánicos, eléctricos y/o de potencia de tracción. Una falla de interés especial puede estar relacionada con un experimento de campo a la medida o un análisis
llevado a cabo para un operador o proyecto del ferrocarril, puede utilizarse para verificar la tendencia de parámetros operativos predeterminados, etc.
CUADRO 1
El paso 512 permite que se lleve a cabo una revisión o análisis experto por personal experimentado, por ejemplo personal MDSC y/o equipos de ingeniería responsables por dar servicio a cualquier subsistema afectado, por ejemplo, motores de tracción, subsistema de suministro de combustible, etc. Como se sugirió anteriormente, el paso 314 permite que el procesamiento, si se desea, de fallas de interés especial, de tendencias de fallas, de fallas críticas, etc. En particular, el programador de análisis 15 (ver Figura 2) puede utilizarse para procesar en lotes cualquier grupo de datos de falla de acuerdo con las enseñanzas de la presente invención. El paso 516 permite el almacenaje, en una base de datos adecuada, de cada falla que pudiera activar una locomotora respectiva para hacer una petición de
llamada a casa. En una modalidad, estas se clasifican como las fallas críticas o de llamada a casa. Como se muestra en el paso 518, el proceso es un proceso interactivo que puede repetirse para mantener una base de datos actualizada de las fallas de llamada a casa. La actualización puede realizarse a intervalos de tiempo predeterminados, o puede realizarse debido a casos especiales, como es desplazamiento de nuevos modelos de locomotoras, actualizaciones de locomotora, etc.