ES2675755T3 - Apoyo al análisis de modos de fallo y efectos de un sistema que comprende una pluralidad de componentes - Google Patents

Apoyo al análisis de modos de fallo y efectos de un sistema que comprende una pluralidad de componentes Download PDF

Info

Publication number
ES2675755T3
ES2675755T3 ES08863035.5T ES08863035T ES2675755T3 ES 2675755 T3 ES2675755 T3 ES 2675755T3 ES 08863035 T ES08863035 T ES 08863035T ES 2675755 T3 ES2675755 T3 ES 2675755T3
Authority
ES
Spain
Prior art keywords
component
data
components
model
failure
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES08863035.5T
Other languages
English (en)
Inventor
John Brian Bell
Richard Lee Bovey
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
BAE Systems PLC
Original Assignee
BAE Systems PLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from GB0724593A external-priority patent/GB0724593D0/en
Priority claimed from GB0805464A external-priority patent/GB0805464D0/en
Application filed by BAE Systems PLC filed Critical BAE Systems PLC
Application granted granted Critical
Publication of ES2675755T3 publication Critical patent/ES2675755T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00—Testing or monitoring of control systems or parts thereof
    • G05B23/02—Electric testing or monitoring
    • G05B23/0205—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
    • G05B23/0259—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterized by the response to fault detection
    • G05B23/0275—Fault isolation and identification, e.g. classify fault; estimate cause or root of failure
    • G05B23/0278—Qualitative, e.g. if-then rules; Fuzzy logic; Lookup tables; Symptomatic search; FMEA
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/008—Reliability or availability analysis

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Mathematical Physics (AREA)
  • General Engineering & Computer Science (AREA)
  • Fuzzy Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Testing And Monitoring For Control Systems (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)
  • Debugging And Monitoring (AREA)

Abstract

Un método implementado por ordenador para el apoyo al análisis de modos de fallo y efectos de un sistema que comprende una pluralidad de componentes (402A, 402B) y uno o varios grupos de componentes (206, 208), usando un modelo del sistema que tiene datos de componente (404A, 404B) y datos de tipo de componente (406) asociados para la pluralidad de componentes y uno o varios grupos, en que el método incluye: obtener datos electrónicos (404) asociados a un componente (402) del sistema; en que el método está caracterizado por: comprobar la existencia de sucesos relacionados con el modelo, y detectar un suceso, en que el suceso comprende la adición de un componente al modelo, analizar un modelo del sistema para determinar (602, 604) si el componente está ya asociado a unos datos de tipo de componente (406) que incluyen datos relacionados con al menos una característica de fallo común a todos los componentes de ese tipo, y si el componente no está asociado todavía a unos datos de tipo de componente tales, entonces son creados datos de tipo de componente para el componente y son asociados al componente, y almacenar y/o transferir los datos de componente y los datos de tipo de componente (606, 608, 610) para uso en un análisis de modos de fallo y efectos del sistema (610).

Description

5
10
15
20
25
30
35
40
45
50
DESCRIPCION
Apoyo al análisis de modos de fallo y efectos de un sistema que comprende una pluralidad de componentes
La presente invención se refiere al apoyo al análisis de modos de fallo y efectos de un sistema que comprende una pluralidad de componentes.
El análisis de modos de fallo y efectos es una técnica que se usa para crear un modelo de fallos-síntomas que puede usarse para identificar los fallos más probables en un sistema usando datos acerca de los síntomas conocidos y de sus relaciones con fallos conocidos. Aplicaciones de diagnóstico de sistema experto (por ejemplo, las basadas en redes bayesianas probabilísticas) pueden usar entonces el modelo para identificar la causa probable, dada la información acerca de los síntomas. La construcción de un modelo que define relaciones entre fallos y síntomas asociados ha requerido convencionalmente conocimiento experto tanto del sistema como de la técnica de análisis y es un ejercicio manual repetitivo. En algunos casos, puede usarse una representación de datos tal como una hoja de cálculo para crear el modelo y esto requiere que el usuario realice muchas operaciones de copiar/pegar y resulta en una gran cantidad de datos repetidos. Además, la gran cantidad de datos de modelo que son creados por estos métodos convencionales son susceptibles de fallar en cuanto a ser actualizados adecuadamente en su totalidad cuando el modelo es actualizado.
Un ejemplo de razonamiento basado en modelo, usado en análisis de modos de fallo y efectos, se divulga en “AUTAS: a tool for supporting FMECA generation in aeronautic systems” de C. PICARDI ET AL, publicado en Internet en “PROCEEDINGS OF THE 16TH EUROPEAN CONFERENCE ON ARTIFICIAL INTELLIGENCE”, 22 a 27 de agosto, páginas 1-5.
Las realizaciones de la presente invención están destinadas a abordar algunos de los problemas anteriormente discutidos.
De acuerdo con un aspecto de la presente invención, se proporciona un método implementado por ordenador para el apoyo a análisis de modos de fallo y efectos de un sistema que comprende una pluralidad de componentes y uno o varios grupos de componentes, usando un modelo del sistema que tiene datos de componente y datos de tipo de componente asociados para la pluralidad de componentes y uno o varios grupos, en que el método incluye:
obtener datos electrónicos asociados a un componente del sistema;
en que el método está caracterizado por:
comprobar la existencia de sucesos relacionados con el modelo, y detectar un suceso, en que el suceso comprende la adición de un componente al modelo,
analizar un modelo del sistema para determinar si el componente está ya asociado a unos datos de tipo de componente que incluyen datos relacionados con al menos una característica de fallo común a todos los componentes de ese tipo, y si el componente no está asociado todavía a unos datos de tipo de componente tales, entonces son creados datos de tipo de componente para el componente y son asociados al componente, y
almacenar y/o transferir los datos de componente y los datos de tipo de componente para uso en un análisis de modos de fallo y efectos del sistema.
El paso de analizar un modelo del sistema puede incluir detectar una forma de una representación gráfica del componente en el modelo, y determinar un patrón o plantilla en el que se basa la forma para determinar los datos de tipo de componente a asociar al componente.
Los datos de característica de fallo pueden ser seleccionados de un conjunto: tipo/nombre/modo del fallo; efecto(s) del fallo sobre el sistema y/u otros componentes; síntoma(s) del fallo; un valor que representa una probabilidad de que ocurra(n) el (los) síntoma(s) de fallo conducente(s) al fallo; una probabilidad a priori de que ocurra el fallo; una probabilidad condicional de un síntoma dado un fallo y sólo un fallo tal; una probabilidad de un síntoma dada la ausencia de cualquier fallo modelado.
Los datos de tipo de componente pueden ser almacenados independientemente de los datos de componente. Los datos de componente pueden incluir, o estar asociados a, datos relacionados con características de fallo de ese componente/grupo específico, típicamente datos que describen efecto(s) del fallo del componente/grupo sobre otros componentes y/u otros grupos y/o el sistema.
Cada componente tal en el modelo puede ser asignado a un identificador único y cada tipo de componente tal puede ser asignado a un identificador único. El paso de almacenar y/o transferir los datos de componente y de tipo de componente puede incluir almacenar/transferir los datos de componente con una referencia entre el identificador
10
15
20
25
30
35
40
45
único del componente y el identificador único del tipo de componente asociado al componente.
De acuerdo con otro aspecto de la presente invención, se proporciona un producto de programa de ordenador que comprende un medio legible por ordenador, que lleva en él medios de código de programa de ordenador, para hacer que cuando el código de programa es cargado el ordenador ejecute un método de apoyo al análisis de modos de fallo y efectos de un sistema que comprende una pluralidad de componentes, y uno o varios grupos de componentes, sustancialmente como se describe aquí.
De acuerdo con otro aspecto de la presente invención, se proporciona un equipo adaptado para el apoyo al análisis de modos de fallo y efectos de un sistema que comprende una pluralidad de componentes, y uno o varios grupos de componentes, usando un modelo del sistema que tiene datos de componente y datos de tipo de componente asociados para la pluralidad de componentes y uno o varios grupos, en que el equipo incluye:
un dispositivo adaptado para obtener datos electrónicos asociados a un componente de un sistema;
en que el equipo está caracterizado por:
un dispositivo adaptado para comprobar la existencia de sucesos relacionados con el modelo, en que un suceso comprende la adición de un componente al modelo,
en que el dispositivo está adaptado además para analizar el modelo del sistema para determinar, al detectarse un suceso, si el componente en un grupo de componentes está ya asociado a unos datos de tipo de componente que incluyen datos relacionados con al menos una característica de fallo común a todos los componentes de ese tipo, y si el componente no está asociado todavía a unos datos de tipo de componente tales, entonces son creados datos de tipo de componente y son asociados al componente, y
un dispositivo para almacenar y/o transferir los datos de componente y los datos de tipo de componente para uso en un análisis de modos de fallo y efectos del sistema.
La invención puede ser realizada de diversos modos, y sólo a modo de ejemplo, serán descritas ahora realizaciones de ella, haciéndose referencia a los dibujos adjuntos en los cuales:
La figura 1 es un dibujo esquemático que muestra relaciones entre componentes en un sistema a modo de ejemplo;
la figura 2 es un dibujo esquemático que muestra un dispositivo computacional configurado para generar un modelo de fallos/síntomas y realizar un análisis de modos de fallo y efectos basado en el modelo;
la figura 3 es una ilustración esquemática de datos de componente y datos de tipo de componente usados por una realización;
la figura 4 es una visualización por pantalla a modo de ejemplo generada por una aplicación usada para crear un modelo de fallos/síntomas, y
la figura 5 es un diagrama de flujo que ilustra pasos llevados a cabo por la realización cuando un componente nuevo es añadido a un modelo.
Se dará ahora una vista general de las etapas típicamente implicadas en la creación de un modelo de fallos/síntomas. Primero, se crea una descripción del sistema de interés. Como las otras etapas, la etapa de creación de descripción puede ser automatizada al menos parcialmente usando software de ordenador, por ejemplo usando una herramienta tal como Microsoft Visio™ para dibujar un modelo de los componentes del sistema y las relaciones entre ellos. La segunda etapa puede implicar identificar estados y modos de fallo de los componentes del sistema. Por ejemplo, en un equipo de bandeja de bombas los componentes pueden comprender un tanque y un estado de fallo que puede estar asociado a esa válvula es “fuga”. La identificación de los modos de fallo puede basarse en el conocimiento de al menos un experto. A continuación es creada una tabla (o cualquier otra estructura de datos adecuada) que almacena información que describe el (los) síntoma(s) asociado(s) a cada modo de fallo. Nuevamente, esto estará típicamente basado en conocimiento experto, que puede ser obtenido de la experiencia de construir realmente el sistema que está siendo modelado. La cuarta etapa implica generar una matriz de modos de fallo/síntomas que contiene valores que representan la probabilidad de que un modo de fallo particular cause el síntoma. La siguiente etapa es validar la tabla y los resultados de la validación pueden usarse para modificar la tabla. Esto puede implicar comparar la tabla frente a un banco de pruebas o datos en servicio que proporcionan una lista de fallos y sus síntomas asociados. Pueden crearse pruebas de unidad (por ejemplo usando una herramienta tal como Matlab™ de la compañía The MathWorks de Natick, MA, EE.UU) y utilizarse para comprobar que la herramienta de diagnóstico identifica el fallo correcto cuando los síntomas son añadidos a la herramienta. Cuando está siendo procesado un modelo grande, un número establecido de fallos pueden ser seleccionados entonces para
5
10
15
20
25
30
35
40
45
50
55
validar la tabla, pero todos los fallos pueden ser comprobados con un modelo más pequeño.
Como se ha mencionado anteriormente, una etapa temprana en el proceso de creación del modelo implica crear una descripción del sistema. La figura 1 ilustra esquemáticamente un sistema que ha sido descompuesto en una jerarquía 200. El ejemplo es un sistema de bandeja de bombas que comprende dos subsistemas idénticos de bandeja de bombas. Tres tipos diferentes de componentes pueden ser usados para generalizar todos los componentes individuales de este sistema a modo de ejemplo: un tipo de bomba 202A, un tipo de sensor 202B y un tipo de válvula 202C. En el subsistema de bandeja de bombas a modo de ejemplo, hay dos ejemplares de los dispositivos de tipo de bomba, 204A, 204B; un ejemplar de un sensor 204C, y un ejemplar de una válvula 204D. El propio subsistema que comprende estos componentes puede ser identificado como un tipo de subsistema general 206. Ejemplares de los dos tipos de subsistema 208A, 208B se muestran en la parte inferior del diagrama. De este modo, se apreciará que en cualquier sistema que tiene que ser modelado los componentes/subsistemas del modelo pueden ser divididos en datos de tipo y datos de ejemplar.
Para la creación de un modelo de fallos/síntomas, los datos de tipo pueden incluir (por ejemplo la estructura de datos de tipo puede incluir campo(s) apropiado(s)) o estar asociados a (por ejemplo una estructura de datos separada puede ser usada para contener realmente la información) información que describe característica(s) de fallo que es/son común/comunes a todos los componentes/subsistemas del mismo tipo. Además, los datos de ejemplar pueden incluir/estar asociados a datos que describen efectos de fallo locales, que pueden diferir para diferentes ejemplares debido a que pueden depender de los elementos contiguos particulares.
En el ejemplo aquí descrito, se usa una aplicación de software que tiene una interfaz gráfica de usuario para ayudar a construir un modelo de fallos/síntomas que pueda ser usado entonces por una herramienta de diagnóstico para identificar la causa probable de un conjunto dado de síntomas en el sistema. La figura 2 es una ilustración esquemática de un dispositivo computacional 300 que ha sido configurado para realizar estas tareas. El ordenador 300 incluye un procesador 302 y una memoria interna 304. Se entenderá que el ordenador puede incluir otras características convencionales, tales como una pantalla, dispositivos de entrada para usuarios (por ejemplo un ratón/teclado), una memoria externa y conexiones de red. La memoria 304 almacena código que incluye una aplicación de construcción de modelo 306 que es usada para crear datos que representan un modelo de fallos/síntomas 308 y una herramienta de diagnóstico 310 que puede usar los datos del modelo.
En el ejemplo aquí descrito, la aplicación de construcción de modelo 306 comprende Microsoft Visio™ 2003 o 2077 Profesional; sin embargo, se entenderá que pueden ser usados/adaptados otros paquetes de dibujo adecuados, tales como SmartDraw™ de smartdraw.com o Kivio™ de koffice.org. Microsoft Visio™ es un paquete de dibujo vectorial usado a menudo para crear diagramas de flujo, diagramas y bocetos. Al igual que la mayoría de los paquetes gráficos vectoriales, pueden crearse formas a partir de objetos primitivos, pero Visio™ incluye diversas formas predefinidas denominadas “patrones” en conjuntos denominados “plantillas”. Pueden cargarse múltiples plantillas junto con un dibujo/documento, permitiendo al usuario arrastrar y soltar desde un patrón sobre el dibujo, lo que añade un ejemplar de patrón denominado una “forma”. Visio™ crea un enlace entre patrón y formas; si se realiza cualquier cambio en el patrón, la forma es actualizada. Esquemas en papel pueden ser incluidos por escaneo y la imagen puede ser pegada como fondo en un documento Visio™. El usuario puede entonces dibujar formas encima como si estuviera calcando y esto puede ayudar a la transferencia de datos desde papel a formato electrónico. De este modo, Visio™ es una herramienta adecuada para crear dibujos esquemáticos que representan componentes/subsistemas que forman un sistema que tiene que ser modelado.
Los datos de forma pueden ser asociados a cualquier forma, incluyendo las formas que constituyen patrones usando la característica “Editar Forma de Patrón” que permite al usuario introducir datos en campos predefinidos. Es también posible cambiar los campos usando un botón de “Definir”, que permite que conjuntos de campos de datos sean creados y soltados sobre una forma, permitiendo que múltiples formas tengan los mismos campos de datos de forma. Esta capacidad de “datos de forma” fue contemplada para asociar datos de características de fallo a los componentes/subsistema que están siendo modelados. Sin embargo, mientras los presentes inventores estaban experimentando con la creación de subsistemas usando Visio™, se descubrió una limitación de esa aplicación. Cuando un subsistema es agrupado y creado dentro de un patrón (es decir, el grupo es arrastrado desde el documento a la plantilla), se pierden los enlaces desde las formas dentro del subsistema a sus patrones originales. Esto evita que el usuario siga todos los ejemplares de un patrón dentro del documento.
Normalmente (es decir, sin agrupación), si la válvula patrón es cambiada, cada ejemplar de válvula en el documento es también actualizada. Por ejemplo, un usuario puede cambiar todas las válvulas, en un sistema a modo de ejemplo que hay que mostrar en rojo, modificando esa característica usando el cuadro de diálogo de “datos de forma”. Sin embargo, se ha encontrado que cuando, por ejemplo, el color del patrón de válvula es cambiado a rojo, no actualiza las formas de válvula dentro de los subsistemas; es decir, las formas de válvula dentro de los subsistemas ya no enlazan con la válvula patrón en la plantilla. Esto demuestra que sería problemático intentar simplemente usar datos de forma de Visio™ para crear/almacenar información de características de fallo a asociar a tipos de componente/subsistema.
5
10
15
20
25
30
35
40
45
50
55
60
En vista del problema relacionado con una herramienta diseñada para el propósito técnico de simular/encontrar fallos en un sistema de hardware que identificaron, los presentes inventores decidieron extender la funcionalidad de Visio™ para permitir que datos de características de fallo sean asociados de forma precisa a componentes/subgrupos de sistema. Los inventores encontraron que la forma más conveniente de conseguir esto era por medio de un “complemento” (“add-on") de Visio™, pero se apreciará por parte de aquellas personas experimentadas en la técnica que existen alternativas, por ejemplo usando Visual Basic™ para Aplicaciones (VBA). Los complementos de Visio™ permiten a los usuarios extender la funcionalidad de la aplicación desarrollando herramientas de software que tienen permiso extensivo de acceso a la aplicación Visio™. Un complemento puede ser escrito en cualquier lenguaje (por ejemplo, C++, C#, VB o VB.NET) que soporte el Modelo de Objetos Componentes (COM, del inglés “Component Object Model”). Para una realización, se escribió código C++ que estaba parcialmente basado en código incluido en el ejemplo de “diagrama de flujo” incluido en el kit de desarrollo de software de Visio™ 2003. El código incluye funcionalidad para “captar” sucesos persistentes en la ejecución de Visio™. Cuando se ejecuta el complemento, éste comprueba si el documento activo está siendo monitorizado actualmente; si no, crea entonces un sumidero de sucesos y lo añade a una envoltura de documentos (document wrapper), el sumidero de sucesos comprueba la existencia de sucesos. Esto es útil para detectar cuándo está siendo añadida una nueva forma al dibujo, lo que, como se describirá posteriormente, puede resultar en la creación/referencia cruzada de datos de tipo de componente.
Los términos “patrones” y “formas” de Visio™ pueden igualarse aproximadamente a tipos y ejemplares, respectivamente. Aquí, los términos “tipo de componente” y “componente” denotan un tipo de componente y un ejemplar de un componente, respectivamente (por ejemplo, un tipo de bomba y un ejemplar específico de una bomba, tal como la bomba número 4) tal como son tratados por el complemento. En el complemento a modo de ejemplo, los datos que describen un componente incluyen el nombre del componente, una descripción del componente y una indicación del tipo del componente. Sin embargo, se entenderá que podrían usarse datos diferentes/adicionales para un componente. Los datos de tipo de componente incluyen el nombre y la descripción del tipo.
La figura 3 ilustra gráficamente la relación entre datos de componente y datos de tipo de componente. En la figura a modo de ejemplo, hay dos (ejemplares de) componentes, la Bomba 1 (402A) y la Bomba 2 (402B). Cada una de éstos está asociado a datos de componente 404A, 404B, respectivamente. Cada componente 402A, 402 está también asociado a datos de tipo de componente 406 únicos (debido a que ambos componentes son del mismo tipo, es decir bombas). En el ejemplo, los datos de tipo de componente 406 incluyen datos que describen modos de fallo y efectos que son comunes a todos los componentes de ese tipo y que son compartidos por cada ejemplar de ese componente. Los datos de componente 404a y 404B incluyen una lista de efectos locales para bombas 402A y 402B, respectivamente, por ejemplo efectos específicos para componentes directamente contiguos de cada bomba. Se entenderá que los datos pueden ser almacenados y manipulados usando cualquier estructura adecuada de datos, por ejemplo una tabla simple, un árbol, etc.
Se describirá ahora un ejemplo de la creación de un modelo usando Visio™ y una realización del complemento. Se entenderá que algunas de las operaciones descritas a continuación pueden ser realizadas en un orden diferente o que algunas pueden ser omitidas, dependiendo del modelo particular que está siendo creado. Primero, puede ser creado un documento nuevo para el modelo y pueden ser abiertas plantillas (por ejemplo basadas en las encontradas en la Pauta de Diagramas de Flujo de Proceso (Process Flow Diagram Témplate) suministrada con Visio™ Profesional 2007) que contienen las formas necesarias a abrir. Una imagen de un esquema del sistema a abrir puede ser pegada en el dibujo. Para permitir que sean vistos claramente nuevos componentes, puede ser alterada la transparencia de la imagen pegada. La figura 4 es un ejemplo de una visualización por pantalla de Visio™ que muestra una imagen pegada de este tipo (mostrada en líneas claras) con algunos componentes dibujados usando Visio™ (mostrados en líneas más oscuras, por ejemplo la forma de bomba 502) superpuestos sobre ella.
Una vez dibujado el esquema encima del dibujo transparente pueden ser añadidos datos de modos de fallo y efectos a los componentes. Se apreciará que esto podría hacerse en cualquier momento durante o después del dibujo de los componentes del sistema, por ejemplo seleccionando una opción de menú, pero en el ejemplo el complemento detecta un suceso de “añadir forma” y puede solicitar una entrada de datos de fallo para un nuevo componente. Si el componente es de un tipo nuevo, se solicita entonces una entrada de datos de fallo para ese tipo de componente.
Con referencia al ejemplo de la figura 4, se muestra un cuadro de entrada de datos 504 para introducir datos relacionados con el tipo del componente de bomba 502. El cuadro permite que sea introducido un nombre 506 del tipo de componente, al igual que una descripción 508 del tipo de componente. Esta presente también una lista de modos de fallo 510 comunes a todos los componentes de los tipos, así como una lista de efectos de fallo 512 comunes a todos los componentes de los tipos. Pueden añadirse, editarse o borrarse entradas en estas listas usando los botones apropiados. Modos de fallo a modo de ejemplo han sido introducidos en la figura. Se apreciará que serán añadidos datos adicionales para completar el modelo de fallos/síntomas. Esto puede hacerse exportando los datos parciales introducidos a través del complemento, por ejemplo como un fichero de variables separadas por comas, y añadir a esto datos usando otra aplicación, por ejemplo una hoja de cálculo. Alternativamente, el cuadro de
entrada de datos en el complemento puede ser expandido para permitir que sean introducidos datos de fallos/efectos adicionales. Por ejemplo, puede proporcionarse un cuadro de entrada de datos de componente (ejemplar en vez de tipo) para introducir datos de fallo específicos del componente. Además, se apreciará que grupos de componentes pueden ser identificados como subsistemas y datos de tipo de subsistema pueden ser 5 creados y manipulados de una manera similar a los datos de componente/tipo de componente aquí detallados. La tabla siguiente ilustra un ejemplo parcial adicional de información de características de fallo que puede ser capturada para un sistema:
Componente
Modo de Fallo Prob. de Fallo Efecto de Fallo Efecto de sistema Probabilidad de Síntoma dado un solo fallo Fugas
Tanque principal
Escape 0,00328 Escape de fluido Monitor de presión PT3 indica presión alta 0,9 0,01
Tubería entre válvula y conjunción
Bloqueada 0,00328 Pérdida de flujo Válvula SOV3 debe estar ABIERTA pero conmutador cerrado responde CERRADA 0,88 0,02
Válvula SOV3
Válvula SOV3 cerrada conmutador falló activación 0,00329 Válvula SOV3 está abierta, pero Válvula SOV4 está cerrada
Válvula SOV3 cerrada conmutador falló desactivación 0,00327 Válvula SOV3 debe estar ABIERTA pero conmutador abierto no responde ABIERTO
Fallo de camino de control de Válvula SOV3 (válvula permanece cerrada) 0,00328 Válvula SOV3 debe estar ABIERTA pero conmutador cerrado responde CERRADA
10 Cada patrón y forma en Visio™ tiene un identificador único que puede ser usado para el seguimiento de un ejemplar de una forma. Los patrones también tienen un identificador ID único que permite identificar patrones comunes. Construir un mapa de componentes y tipos de componente indexados mediante el ID único evita la duplicación de datos y permite un acceso rápido a los datos. De este modo, los datos recogidos mediante el complemento pueden ser exportados (en cualquier formato adecuado) y pueden ser usados directamente por la aplicación de diagnóstico 15 para encontrar fallos. El sistema que está siendo modelado puede ser adaptado (automáticamente) sobre la base de los hallazgos de la herramienta de diagnóstico, por ejemplo abrir una válvula de emergencia.
La figura 5 ilustra esquemáticamente pasos realizados por el complemento cuando captura un suceso de “añadir forma”, es decir cuando ha sido dibujado un componente nuevo. En el paso 602 es determinado el patrón de la forma dibujada. En el paso 604 se realiza una pregunta acerca de si los datos de tipo de componente 20 correspondientes a ese patrón ya existen. Si la respuesta es negativa, son creados entonces datos de tipo de componente para el componente representado por la forma, por ejemplo a través de un cuadro de entrada de datos como se ha descrito anteriormente. Los datos de tipo de componente son almacenados entonces en el mapa
5
10
15
20
25
30
35
40
mantenido por el complemento.
En el paso 606, la forma es envuelta en/asociada a los datos de componente para permitir que el complemento la reconozca como componente. En el paso 608, un enlace es creado desde el componente al tipo de componente y en el paso 610 esta información es almacenada en el mapa del complemento. De este modo, datos que representan una lista de componentes y tipos de componente (con asociaciones entre cada componente y el tipo apropiado) son creados y pueden ser almacenados/transferidos para uso con una herramienta de diagnóstico como se ha descrito anteriormente. Como el complemento permite que componentes del mismo tipo compartan datos, se evita una introducción repetitiva de datos y esto puede reducir la probabilidad de errores. Los datos creados por la aplicación pueden ser almacenados como una “librería” para reutilización. Pueden hacerse cambios a los datos de forma rápida y conveniente encontrando la forma relevante en el dibujo, en vez de buscando líneas de caracteres como en técnicas de construcción de datos de modelo basadas en texto. La característica de “añadir selección” permite que esquemas existentes dibujados en Visio™ sean usados sin la necesidad de redibujar un diagrama completo.

Claims (8)

  1. 5
    10
    15
    20
    25
    30
    35
    40
    45
    50
    REIVINDICACIONES
    1. Un método implementado por ordenador para el apoyo al análisis de modos de fallo y efectos de un sistema que comprende una pluralidad de componentes (402A, 402B) y uno o varios grupos de componentes (206, 208), usando un modelo del sistema que tiene datos de componente (404A, 404B) y datos de tipo de componente (406) asociados para la pluralidad de componentes y uno o varios grupos, en que el método incluye:
    obtener datos electrónicos (404) asociados a un componente (402) del sistema; en que el método está caracterizado por: comprobar la existencia de sucesos relacionados con el modelo, y detectar un suceso, en que el suceso comprende la adición de un componente al modelo,
    analizar un modelo del sistema para determinar (602, 604) si el componente está ya asociado a unos datos de tipo de componente (406) que incluyen datos relacionados con al menos una característica de fallo común a todos los componentes de ese tipo, y si el componente no está asociado todavía a unos datos de tipo de componente tales, entonces son creados datos de tipo de componente para el componente y son asociados al componente, y
    almacenar y/o transferir los datos de componente y los datos de tipo de componente (606, 608, 610) para uso en un análisis de modos de fallo y efectos del sistema (610).
  2. 2. Un método según la reivindicación 1, en que el modelo comprende patrones o plantillas para componentes, y el paso de analizar el modelo incluye detectar una forma de una representación gráfica (502) del componente en el modelo, y determinar (602) un patrón o plantilla en el que se basa la forma para determinar los datos de tipo de componente a asociar al componente.
  3. 3. Un método según una cualquiera de las reivindicaciones precedentes, en que los datos de característica de fallo son seleccionados de un conjunto: tipo/nombre/modo del fallo; efecto(s) del fallo sobre el sistema y/u otros componentes; síntoma(s) del fallo; una probabilidad a priori de que ocurra el fallo; una probabilidad condicional de un síntoma dado un fallo y sólo un fallo tal; una probabilidad de un síntoma dada la ausencia de cualquier fallo modelado.
  4. 4. Un método según una cualquiera de las reivindicaciones precedentes, en que los datos de tipo de componente (406) son almacenados independientemente de los datos de componente (404).
  5. 5. Un método según una cualquiera de las reivindicaciones precedentes, en que los datos de tipo de componente (406) incluyen, o están asociados a, datos relacionados con características de fallo de ese componente o grupo específico, tales como datos que describen efecto(s) del fallo del componente o grupo sobre otros componentes y/u otros grupos y/o el sistema.
  6. 6. Un método según una cualquiera de las reivindicaciones precedentes, en que cada componente tal en el modelo es asignado a un identificador único y cada tipo de componente tal es asignado a un identificador único, y el paso de almacenar y/o transferir los datos de componente y de tipo de componente incluye almacenar/transferir los datos de componente con una referencia entre el identificador único del componente y el identificador único del tipo de componente asociado al componente.
  7. 7. Un producto de programa de ordenador que comprende un medio legible por ordenador, que lleva en él medios de código de programa de ordenador, para hacer que cuando el código de programa es cargado el ordenador ejecute un método de apoyo al análisis de modos de fallo y efectos de un sistema que comprende una pluralidad de componentes (402A, 402B), y uno o varios grupos de componentes (206, 208), según una cualquiera de las reivindicaciones precedentes.
  8. 8. Equipo (300) adaptado para el apoyo al análisis de modos de fallo y efectos de un sistema que comprende una pluralidad de componentes (402A, 402b) y uno o varios grupos de componentes (206, 208), usando un modelo del sistema que tiene datos de componente (404A, 404B) y datos de tipo de componente (406) asociados para la pluralidad de componentes y uno o varios grupos, en que el equipo incluye:
    un dispositivo (300) adaptado para obtener datos electrónicos (404) asociados a un componente (402) de un sistema; en que el equipo está caracterizado por:
    un dispositivo (300) adaptado para comprobar la existencia de sucesos relacionados con el modelo, en que un suceso comprende la adición de un componente al modelo,
    en que el dispositivo (300) está adaptado además para analizar el modelo del sistema para determinar (602, 604), al detectarse un suceso, si el componente en un grupo de componentes está ya asociado a unos datos de tipo de componente (406) que incluyen datos relacionados con al menos una característica de fallo
    común a todos los componentes de ese tipo, y si el componente no está asociado todavía a unos datos de tipo de componente tales, entonces son creados datos de tipo de componente y son asociados al componente, y
    un dispositivo (304) para almacenar y/o transferir (606, 608, 610) los datos de componente y los datos de 5 tipo de componente para uso en un análisis de modos de fallo y efectos del sistema.
ES08863035.5T 2007-12-18 2008-11-26 Apoyo al análisis de modos de fallo y efectos de un sistema que comprende una pluralidad de componentes Active ES2675755T3 (es)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
GB0724593 2007-12-18
GB0724593A GB0724593D0 (en) 2007-12-18 2007-12-18 Assisting failure mode and effects analysis of a system comprising a plurality of components
GB0805464 2008-03-26
GB0805464A GB0805464D0 (en) 2008-03-26 2008-03-26 Assisting failure mode and effects analysis of a system comprising a plurality of components
PCT/GB2008/051116 WO2009077776A2 (en) 2007-12-18 2008-11-26 Assisting failure mode and effects analysis of a system comprising a plurality of components

Publications (1)

Publication Number Publication Date
ES2675755T3 true ES2675755T3 (es) 2018-07-12

Family

ID=40670937

Family Applications (1)

Application Number Title Priority Date Filing Date
ES08863035.5T Active ES2675755T3 (es) 2007-12-18 2008-11-26 Apoyo al análisis de modos de fallo y efectos de un sistema que comprende una pluralidad de componentes

Country Status (8)

Country Link
US (1) US8347146B2 (es)
EP (1) EP2225636B1 (es)
JP (1) JP5450443B2 (es)
AU (1) AU2008337296B2 (es)
CA (1) CA2708628C (es)
ES (1) ES2675755T3 (es)
TR (1) TR201809088T4 (es)
WO (1) WO2009077776A2 (es)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011046869A2 (en) * 2009-10-12 2011-04-21 Abbott Patrick D Targeted equipment monitoring system and method for optimizing equipment reliability
US20120233112A1 (en) * 2011-03-10 2012-09-13 GM Global Technology Operations LLC Developing fault model from unstructured text documents
EP2778818B1 (en) * 2013-03-12 2017-04-19 Hitachi Ltd. Identification of faults in a target system
WO2015003127A2 (en) * 2013-07-05 2015-01-08 Oceaneering International, Inc. Intelligent diagnostic system and method of use
CN105900022A (zh) * 2013-11-27 2016-08-24 精通人工智能系统有限公司 使用概率介质的基于人工智能模型的动态过程控制的方法和系统
US10019305B2 (en) 2013-12-11 2018-07-10 Robert Bosch Gmbh Internet-based diagnostic assistant for device analysis
US9483342B2 (en) * 2014-03-20 2016-11-01 Siemens Aktiengesellschaft Supporting failure mode and effects analysis
EP2960837A1 (en) * 2014-06-27 2015-12-30 Siemens Aktiengesellschaft System and method for supporting global effect analysis
US9798605B2 (en) * 2014-06-27 2017-10-24 Siemens Aktiengesellschaft Supporting global effect analysis
US10241852B2 (en) * 2015-03-10 2019-03-26 Siemens Aktiengesellschaft Automated qualification of a safety critical system
EP3274880A1 (en) * 2015-06-12 2018-01-31 Siemens Aktiengesellschaft A method and apparatus for performing a model-based failure analysis of a complex industrial system
WO2018052433A1 (en) 2016-09-16 2018-03-22 Siemens Aktiengesellschaft Generation of failure models for embedded analytics and diagnostic/prognostic reasoning
US10771369B2 (en) * 2017-03-20 2020-09-08 International Business Machines Corporation Analyzing performance and capacity of a complex storage environment for predicting expected incident of resource exhaustion on a data path of interest by analyzing maximum values of resource usage over time
EP3410384A1 (en) * 2017-06-02 2018-12-05 Siemens Aktiengesellschaft A method and system for optimizing measures within a value chain of an investigated system
CN109919574A (zh) * 2019-01-28 2019-06-21 江苏徐工工程机械研究院有限公司 一种基于数据融合的工程机械失效模式分析系统及方法

Family Cites Families (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2705087B2 (ja) * 1988-03-30 1998-01-26 三菱電機株式会社 試験装置
US4965743A (en) * 1988-07-14 1990-10-23 The United States Of America As Represented By The Administrator Of The National Aeronautics And Space Administration Discrete event simulation tool for analysis of qualitative models of continuous processing system
US7337090B1 (en) * 1994-05-25 2008-02-26 Emc Corporation Apparatus and method for event correlation and problem reporting
US6453209B1 (en) * 1999-09-01 2002-09-17 Daimlerchrysler Corporation Computer-implemented method and apparatus for integrating vehicle manufacturing operations
US6405108B1 (en) 1999-10-28 2002-06-11 General Electric Company Process and system for developing predictive diagnostics algorithms in a machine
WO2002007495A1 (de) * 2000-07-22 2002-01-31 Abb Research Ltd. System zur unterstützung einer fehlerursachenanalyse
EP1352327A4 (en) 2001-01-08 2007-04-18 Vextec Corp METHOD AND DEVICE FOR PREDICTING FAILURES IN A SYSTEM
GB2378248A (en) 2001-05-09 2003-02-05 Worcester Entpr Ltd A fault prediction system for vehicles
WO2003019523A1 (en) * 2001-08-23 2003-03-06 Fei Company Graphical automated machine control and metrology
JP4186503B2 (ja) * 2002-04-22 2008-11-26 Ｊｆｅスチール株式会社 故障診断装置、故障診断方法及びそのプログラム
US7162695B2 (en) * 2002-06-17 2007-01-09 The United States Of America As Represented By The Secretary Of The Navy Safety analysis training device
US7249284B2 (en) * 2003-03-28 2007-07-24 Ge Medical Systems, Inc. Complex system serviceability design evaluation method and apparatus
US7254747B2 (en) * 2003-03-28 2007-08-07 General Electric Company Complex system diagnostic service model selection method and apparatus
DE102004029222A1 (de) * 2003-06-24 2005-02-17 Omron Corp. Verbesserungsunterstützungssystem
JP4237610B2 (ja) * 2003-12-19 2009-03-11 株式会社東芝 保守支援方法及びプログラム
CA2465155C (en) * 2004-04-21 2008-12-09 Ibm Canada Limited-Ibm Canada Limitee Recommendations for intelligent data caching
EP1794693B1 (en) * 2004-10-01 2016-05-11 Mentor Graphics Corporation Feature failure correlation
JP2006127410A (ja) * 2004-11-01 2006-05-18 Tomoyuki Suwa 間取図画像処理方法
US8676538B2 (en) 2004-11-02 2014-03-18 Advanced Micro Devices, Inc. Adjusting weighting of a parameter relating to fault detection based on a detected fault
EP1842191A4 (en) * 2005-01-19 2012-05-09 Favoweb Ltd SYSTEM AND METHOD FOR ANALYSIS OF REPEATED FAILURES
US7379799B2 (en) 2005-06-29 2008-05-27 General Electric Company Method and system for hierarchical fault classification and diagnosis in large systems
JP3808893B1 (ja) * 2005-07-14 2006-08-16 国立大学法人 岡山大学 故障診断装置、プログラム及び記録媒体
WO2007016360A2 (en) * 2005-07-28 2007-02-08 Metaldyne Company, Llc Look-across system
US7627388B2 (en) * 2005-10-28 2009-12-01 Core, Inc. Reliability tools for complex systems
US8015550B2 (en) * 2005-12-01 2011-09-06 Siemens Corporation Systems and methods for hazards analysis
JP4967430B2 (ja) * 2006-04-11 2012-07-04 オムロン株式会社 不具合管理装置、不具合管理プログラム、およびこれを記録した記録媒体
WO2008036921A2 (en) * 2006-09-21 2008-03-27 Impact Technologies, Llc Systems and methods for predicting failure of electronic systems and assessing level of degradation and remaining useful life
EP1980964B1 (en) * 2007-04-13 2016-03-23 Yogitech Spa Method and computer program product for performing failure mode and effects analysis of an integrated circuit
US20080300888A1 (en) * 2007-05-30 2008-12-04 General Electric Company Systems and Methods for Providing Risk Methodologies for Performing Supplier Design for Reliability

Also Published As

Publication number Publication date
EP2225636A2 (en) 2010-09-08
JP5450443B2 (ja) 2014-03-26
JP2011507125A (ja) 2011-03-03
WO2009077776A3 (en) 2010-04-15
CA2708628A1 (en) 2009-06-25
TR201809088T4 (tr) 2018-07-23
US20100262867A1 (en) 2010-10-14
US8347146B2 (en) 2013-01-01
AU2008337296B2 (en) 2013-02-14
WO2009077776A2 (en) 2009-06-25
EP2225636B1 (en) 2018-05-30
CA2708628C (en) 2017-03-07
AU2008337296A1 (en) 2009-06-25

Similar Documents

Publication Publication Date Title
ES2675755T3 (es) Apoyo al análisis de modos de fallo y efectos de un sistema que comprende una pluralidad de componentes
US10169347B2 (en) Layer identification and dependency analysis for management of images
US9092586B1 (en) Version management mechanism for fluid guard ring PCells
US9612806B2 (en) Verification of computer-executable code generated from a model
US8869103B2 (en) Using intermediate representations to verify computer-executable code generated from a model
US7861217B2 (en) Non-graphical model dependencies in graphical modeling environments
US9418230B2 (en) Automated tools for building secure software programs
US9075544B2 (en) Integration and user story generation and requirements management
US7530056B1 (en) Method and system for detecting runtime defects in a program by comparing correct and incorrect runs
Semeráth et al. Iterative and incremental model generation by logic solvers
Deransart et al. Analysis and visualization tools for constraint programming: constraint debugging
KR20130133203A (ko) 양방향 텍스트 검사기
Moha et al. Refactorings of design defects using relational concept analysis
WO2019039534A1 (ja) データ分析処理支援装置、及びデータ分析処理支援方法
EP3113016A1 (en) Tracing dependencies between development artifacts in a development project
CN110928761B (zh) 需求链及其应用的系统和方法
JP2011170697A (ja) ソフトウェア構造分析装置
Spönemann et al. Port constraints in hierarchical layout of data flow diagrams
CN113222164B (zh) 量子计算程序的生成方法及其表达形式
US20100058288A1 (en) Method And System for Structuring a Software Implementation
JP5465118B2 (ja) 編集方法および編集装置
Kosiol et al. A Generalized Concurrent Rule Construction for Double-Pushout Rewriting
Aparna et al. Building a common notation for enabling comparison of design and execution
CN112948244B (zh) 用于工业互联网信息模型测试的方法、装置和设备
JP2003108405A (ja) 試験仕様の作成支援装置及びプログラム