ES2561311T3 - Validación y visualización de análisis de fallos - Google Patents

Validación y visualización de análisis de fallos Download PDF

Info

Publication number
ES2561311T3
ES2561311T3 ES13166291.8T ES13166291T ES2561311T3 ES 2561311 T3 ES2561311 T3 ES 2561311T3 ES 13166291 T ES13166291 T ES 13166291T ES 2561311 T3 ES2561311 T3 ES 2561311T3
Authority
ES
Spain
Prior art keywords
data
systems
failures
fault
complex system
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
ES13166291.8T
Other languages
English (en)
Inventor
Tyler Junichi Petri
Daniel J. Fogarty
David Harding Jones
Allison Moran
Kevin Nicholas King
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.)
Boeing Co
Original Assignee
Boeing Co
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
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=48446049&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=ES2561311(T3) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Boeing Co filed Critical Boeing Co
Application granted granted Critical
Publication of ES2561311T3 publication Critical patent/ES2561311T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F17/00—Digital computing or data processing equipment or methods, specially adapted for specific functions
    • 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/0262—Confirmation of fault detection, e.g. extra checks to confirm that a failure has indeed occurred

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Automation & Control Theory (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Mathematical Physics (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Testing And Monitoring For Control Systems (AREA)

Abstract

Un sistema (100) para integrar datos (904) de fallo para diferentes presentaciones de análisis de fallos, comprendiendo el sistema: un validador (202) de datos configurado para recibir y validar datos (904) de análisis de fallos para un sistema complejo que incluye una pluralidad de sistemas (902), caracterizado por los siguientes rasgos: los datos (904) de análisis de fallos incluyen datos (904) de fallos y datos de diseño, identificando los datos (904) de fallos a uno o más sistemas con fallos de la pluralidad de sistemas (902), y describiendo los datos de diseño al sistema complejo y a los posibles fallos de al menos algunos de sus sistemas (902), y el que el validador (202) de datos esté configurado para validar los datos (904) de análisis de fallos incluye que esté configurado para realizar una o más comprobaciones de consistencia entre los datos (904) de fallos y los datos de diseño para integrar de ese modo los datos (904) de fallos para una pluralidad de diferentes presentaciones de análisis de fallos; y un motor (302) de presentaciones acoplado al validador (202) de datos y configurado para generar de manera selectiva uno cualquiera o más de la pluralidad de diferentes presentaciones de los datos (904) de análisis de fallo, siendo compartidos al menos algunos de los datos (904) de análisis de fallos validados entre al menos algunos de los diferentes presentaciones.

Description

5
10
15
20
25
30
35
40
45
50
55
60
65
DESCRIPCION
Validacion y visualizacion de analisis de fallos ANTECEDENTES
La presente descripcion hace referencia de manera general a presentaciones de datos de analisis de fallos y, en particular, a presentaciones diferenciadas de datos de analisis de fallos para diferentes implicados de una manera que facilite la consistencia de los datos entre las presentaciones.
Los avances en el diseno de muchos sistemas complejos tales como los de las industrias aeroespacial, de automocion, marina y electronica han conducido al desarrollo de numerosos sistemas dependientes entre si. A menudo, los fallos o averlas de uno o mas de estos sistemas afectan, de manera directa o indirecta, a otros sistemas. Ademas, a menudo es necesario, como parte de un proceso de certificacion, un analisis de estos fallos/averlas y de sus efectos directos e indirectos. Tlpicamente estos analisis son realizados manualmente por grupos de analistas de sistemas, sin referencia a un sistema o proceso capaz de facilitar dichos analisis.
Los datos procedentes de los analisis de fallos se pueden representar como representaciones graficas que transmiten la information con mayor claridad que el texto. Los registros (por ejemplo, representaciones graficas, planes de pruebas) desarrollados a partir de estos datos se pueden utilizar para evaluar la aceptabilidad de analisis de fallos con sistemas federados as! como con sistemas integrados. En la actualidad, estos registros pueden ser creados por diferentes organizaciones de ingenierla, cada una con su propia perspectiva y sus propios intereses, por medio de metodos manuales, que consumen mucho tiempo, y los cuales pueden ser propensos a errores y pueden carecer de consistencia y de integration y controles suficientes.
En programas de aeronaves con sistemas federados, los analisis de fallos pueden ser sencillos, y suelen involucrar a un numero limitado de sistemas con efectos en cascada a nivel de la aeronave faciles de entender. Los registros utilizados para evaluar la aceptabilidad de los analisis de fallos con sistemas federados suelen estar limitados a lo que un experto en sistemas individual considera suficiente, y la evaluation de fallos puede ser realizada por un numero limitado de gente.
Por otro lado, cuando los analisis de fallos se realizan sobre sistemas complejos de la aeronave con arquitecturas muy integradas, dichos analisis de fallos pueden involucrar a muchos sistemas con efectos complejos en cascada e impactos a nivel de la aeronave que no son faciles de entender sin una imagen completa del evento. Para realizar una evaluacion valida de un analisis de fallos en este entorno, hay muchos mas implicados que deben estar involucrados que los que serlan necesarios para evaluar un fallo en el entorno de un sistema federado. Cada uno de estos implicados puede estar particularmente interesado en una presentation concreta del evento de fallo (todas las cuales son validas). Todas las presentaciones del evento de fallo se deben considerar junto con todos los implicados para garantizar que se ha realizado una evaluacion correcta y que la aeronave mantendra un nivel de seguridad adecuado. Las practicas mas antiguas son suficientes para aeronaves con sistemas federados (por ejemplo, los expertos en sistemas individuales utilizan presentaciones que ellos consideran suficientes para evaluar escenarios de fallo normalmente contenidos dentro de su sistema), pero no son suficientes para la actual generation de aeronaves cuando se trata de evaluar fallos.
Existe un desaflo en la creation de estos productos/registros/presentaciones, los cuales tlpicamente han sido creados de forma manual en diversos formatos por diferentes grupos. Los desaflos son tres - mantener consistencia entre los diferentes productos, reducir los recursos/el tiempo invertidos en el desarrollo de los productos, y crear alertas de cambios.
La Patente GB2275559 describe un sistema que valida datos de alarma.
BREVE SUMARIO
Por lo general, las realizaciones de ejemplo de la presente invention estan dirigidas a un sistema para la integracion de datos de fallo para diferentes presentaciones de analisis de fallos, y a un metodo y a un medio de almacenamiento informatico correspondientes. De acuerdo con realizaciones de ejemplo, a partir de datos de fallo generados a partir de analisis de fallos se pueden producir de manera automatica presentaciones de casos de fallo, lo cual puede reducir, e incluso eliminar, errores/malas interpretaciones asociados a su production manual, y puede reducir el tiempo de ingenierla necesario para su produccion manual. Se puede comprobar la consistencia de los datos de fallo para de ese modo integrar los datos, lo cual a su vez puede facilitar la consistencia entre presentaciones de los datos. Esto puede permitir una mejor evaluacion del caso de fallo (por ejemplo, la determinacion de si un caso de fallo es aceptable o si se debe realizar un cambio para garantizar la seguridad y la funcionalidad del sistema complejo global). Las comprobaciones de consistencia de los datos de fallo tambien pueden garantizar la produccion de un producto mas seguro, mas integrado, siendo necesario menos tiempo y menos recursos.
De acuerdo con un aspecto de las realizaciones de ejemplo, el sistema incluye un validador de datos y un motor de presentaciones acoplado al mismo. El validador de datos esta configurado para recibir y validar datos de analisis de
5
10
15
20
25
30
35
40
45
50
55
60
65
fallos para un sistema complejo que incluye una pluralidad de sistemas. Los datos de analisis de fallos incluyen datos de fallo que identifican a uno o mas sistemas con fallos de la pluralidad de sistemas, y tambien puede incluir datos de diseno que describen el sistema complejo y posibles fallos de al menos algunos de sus sistemas. En un ejemplo, los sistemas con fallos pueden incluir un sistema con fallos afectado directamente por un fallo de origen, y cualquier sistema con fallos de orden inferior afectado indirectamente por el fallo de origen. Y en un ejemplo mas concreto, los sistemas del sistema complejo pueden incluir uno o mas sistemas electricos, incluyendo los sistemas con fallos a uno o mas sistemas electricos con fallos.
El que el validador de datos este configurado para validar los datos de analisis de fallos puede incluir que este configurado para realizar una o mas comprobaciones de consistencia entre los datos de fallo y los datos de diseno para, de ese modo, integrar los datos de fallo para una pluralidad de diferentes presentaciones de analisis de fallos. A su vez, el motor de presentaciones esta configurado para generar de manera selectiva una presentacion cualquiera o mas de la pluralidad de diferentes presentaciones de los datos de analisis de fallos, siendo compartidos al menos algunos de los datos de analisis de fallos entre al menos algunas de las diferentes presentaciones.
En diferentes ejemplos, los datos de fallo pueden incluir cualquier dato de varios diferentes. Por ejemplo, los datos de fallo pueden incluir uno o mas mensajes del sistema (por ejemplo, mensajes de alerta, mensajes de estado, mensajes de mantenimiento) generados en respuesta a los respectivos fallos de los sistemas con fallos. De forma adicional o alternativa, por ejemplo, los datos de fallo pueden incluir niveles de riesgo para los respectivos fallos de los sistemas con fallos. En otro ejemplo, los datos de fallo pueden identificar estados de potencia del uno o mas sistemas electricos con fallos. Y en otro ejemplo adicional, los datos de fallo pueden incluir una lista de una o mas funciones a nivel del sistema complejo afectadas por los sistemas con fallos.
En diferentes ejemplos, los datos de diseno pueden incluir cualquier dato de varios diferentes. Por ejemplo, los datos de diseno pueden incluir informacion de la interfaz logica que describe relaciones logicas entre los sistemas del sistema complejo. De forma adicional o alternativa, por ejemplo, los datos de diseno pueden incluir una coleccion de mensajes de alerta asociados a diversos sistemas del sistema complejo. Los datos de diseno pueden incluir uno o mas diagramas esquematicos que describen relaciones flsicas entre el sistema complejo y sus sistemas, siendo el sistema complejo divisible en una pluralidad de zonas flsicamente diferenciadas. Es mas, por ejemplo, los datos de diseno pueden incluir una coleccion de niveles de riesgo asociados a diversos sistemas del sistema complejo. En otro ejemplo adicional, los datos de diseno pueden incluir datos de carga electrica que describen los estados de potencia de uno o mas de los sistemas electricos para diferentes estados operativos del sistema complejo. Y en otro ejemplo adicional mas, los datos de diseno pueden incluir una lista de una o mas funciones a nivel del sistema complejo y de sistemas del sistema complejo que implementan las funciones respectivas.
En diversos ejemplos, el validador de datos puede estar configurado para realizar cualquier comprobacion de consistencia de varias diferentes, incluidas por ejemplo, una o mas de entre: comprobacion de consistencia de la interfaz logica, comprobacion de consistencia de las alertas, comprobacion de consistencia de la ubicacion, comprobacion de consistencia de la interfaz logica, comprobacion de consistencia de la evaluacion de riesgos, comprobacion de consistencia de la carga electrica o comprobacion de consistencia de los impactos funcionales. En un ejemplo, el validador de datos puede estar configurado para realizar la comprobacion de consistencia de la interfaz logica incluyendo una comprobacion de que el sistema con fallos esta relacionado de manera logica con los sistemas con fallos de orden inferior, o de que los sistemas relacionados de manera logica con los sistemas con fallos son los sistemas con fallos de orden inferior.
La comprobacion de consistencia de las alertas puede incluir una comprobacion de que los uno o mas mensajes de alerta generados para los sistemas con fallos se correlacionan con mensajes de alerta asociados a los respectivos sistemas con fallos de la coleccion de mensajes de alerta. La comprobacion de consistencia de la ubicacion puede incluir una comprobacion de que los sistemas con fallos estan situados flsicamente en la misma zona del sistema complejo. En un ejemplo adicional, la comprobacion de consistencia de la ubicacion tambien puede incluir una comprobacion de consistencia de la interfaz logica, por ejemplo de la manera anteriormente indicada.
La comprobacion de consistencia de los riesgos puede incluir una comprobacion de que los niveles de riesgo para los respectivos fallos de los sistemas con fallos se correlacionan con niveles de riesgo asociados a los respectivos sistemas con fallos de la coleccion de niveles de riesgo. La comprobacion de consistencia de la carga electrica puede incluir una comprobacion de que los estados de potencia de los uno o mas sistemas electricos con fallos se correlacionan con los datos de carga electrica. Y en un ejemplo, la comprobacion de consistencia de los impactos funcionales puede incluir una comprobacion de que los datos de fallo que incluyen a las funciones a nivel del sistema complejo afectadas por los sistemas con fallos se correlacionan con los datos de diseno que incluyen a las funciones a nivel del sistema complejo implementadas por los respectivos sistemas con fallos.
En las figuras y en el texto, en un aspecto, se describe un sistema para la integracion de datos de fallo para diferentes presentaciones de analisis de fallos, incluyendo el sistema:
un validador de datos configurado para recibir y validar datos de analisis de fallos para un sistema complejo
que incluye una pluralidad de sistemas, donde los datos de analisis de fallos incluyen datos de fallo y datos de
5
10
15
20
25
30
35
40
45
50
55
60
65
diseno, identificando los datos de fallo a uno o mas sistemas con fallos de la pluralidad de sistemas, y describiendo los datos de diseno al sistema complejo y a posibles fallos de al menos algunos de sus sistemas, y donde el que el validador de datos este configurado para validar los datos de analisis de fallos incluye que este configurado para realizar una o mas comprobaciones de consistencia entre los datos de fallo y los datos de diseno para, de ese modo, integrar los datos de fallo para una pluralidad de diferentes presentaciones de analisis de fallos; y un motor de presentaciones acoplado al validador de datos y configurado para generar de manera selectiva una presentacion cualquiera o mas de la pluralidad de diferentes presentaciones de los datos de analisis de fallos, siendo compartidos al menos algunos de los datos de analisis de fallos validados entre al menos algunos de los diferentes presentaciones.
De forma alternativa, el sistema puede incluir el que los sistemas con fallos incluyan un sistema con fallos directamente afectado por un fallo de origen, y cualquier sistema con fallos de orden inferior afectado de manera indirecta por el fallo de origen, el que los datos de diseno incluyan informacion de la interfaz logica que describe relaciones logicas entre los sistemas del sistema complejo, y el que el hecho de que el validador de datos este configurado para realizar una o mas comprobaciones de consistencia incluya que este configurado para realizar una comprobacion de consistencia de la interfaz logica utilizando los datos de fallo y la informacion de la interfaz logica, incluyendo la comprobacion de consistencia de la interfaz logica una comprobacion de que el sistema con fallos esta relacionado de manera logica con los sistemas con fallos de orden inferior, o de que los sistemas relacionados de manera logica con el sistema con fallos son los sistemas con fallos de orden inferior.
De forma alternativa, el sistema puede incluir el que los datos de fallo incluyan uno o mas mensajes de alerta generados en respuesta a los respectivos fallos de los sistemas con fallos, y el que los datos de diseno incluyan una coleccion de mensajes de alerta asociados a diferentes sistemas del sistema complejo, y el que el hecho de que el validador de datos este configurado para realizar una o mas comprobaciones de consistencia incluya que este configurado para realizar una comprobacion de consistencia de las alertas utilizando los mensajes de alerta generados y la coleccion de mensajes de alerta, incluyendo la comprobacion de consistencia de las alertas una comprobacion de que los uno o mas mensajes de alerta generados para los sistemas con fallos se correlacionan con mensajes de alerta asociados a los respectivos sistemas con fallos de la coleccion de mensajes de alerta.
De forma alternativa, el sistema puede incluir el que los datos de diseno incluyan uno o mas diagramas esquematicos que describan relaciones flsicas entre el sistema complejo y sus sistemas, siendo el sistema complejo divisible en una pluralidad de zonas flsicamente diferenciadas, y el que el hecho de que el validador de datos este configurado para realizar una o mas comprobaciones de consistencia incluya que este configurado para realizar una comprobacion de consistencia de la ubicacion utilizando los datos de fallo y uno o mas diagramas esquematicos, incluyendo la comprobacion de consistencia de la ubicacion una comprobacion de que los sistemas con fallos estan situados flsicamente en la misma zona del sistema complejo.
De forma alternativa, el sistema puede incluir el que los datos de fallo incluyan niveles de riesgo para los respectivos fallos de los sistemas con fallos, y el que los datos de diseno incluyan una coleccion de niveles de riesgo asociados a diferentes sistemas del sistema complejo, y el que el hecho de que el validador de datos este configurado para realizar una o mas comprobaciones de consistencia incluya que este configurado para realizar una comprobacion de consistencia de la evaluacion de riesgos utilizando los mensajes de riesgo para los respectivos fallos de los sistemas con fallos y la coleccion de mensajes de alerta, incluyendo la comprobacion de consistencia de la evaluacion de riesgos una comprobacion de que los niveles de riesgo para los respectivos fallos de los sistemas con fallos se correlacionan con niveles de riesgo asociados a los respectivos sistemas con fallos de la coleccion de niveles de riesgo.
De forma alternativa, el sistema puede incluir el que los sistemas del sistema complejo incluyan uno o mas sistemas electricos, el que los sistemas con fallos incluyan uno o mas sistemas electricos con fallos, y el que los datos de fallo identifiquen estados de potencia de los uno o mas sistemas electricos con fallos, el que los datos de diseno incluyan datos de carga electrica que describen los estados de potencia de uno o mas de los sistemas electricos para diferentes estados operativos del sistema complejo, y el que el hecho de que el validador de datos este configurado para realizar una o mas comprobaciones de consistencia incluya que este configurado para realizar una comprobacion de consistencia de la evaluacion de riesgos utilizando los datos de fallo y los datos de carga electrica, incluyendo la comprobacion de consistencia de la carga electrica una comprobacion de que los estados de potencia de los uno o mas sistemas electricos con fallos se correlacionan con los datos de carga electrica.
De forma alternativa, el sistema puede incluir el que los datos de fallo incluyan una lista de una o mas funciones a nivel de sistema complejo afectadas por los sistemas con fallos, el que los datos de diseno incluyan una lista de una o mas funciones de a nivel de sistema complejo y de sistemas del sistema complejo que implementan las respectivas funciones, y el que el hecho de que el validador de datos este configurado para realizar una o mas comprobaciones de consistencia incluya que este configurado para realizar una comprobacion de consistencia de los impactos funcionales incluyendo una comprobacion de que los datos de fallo que incluyen a las funciones a nivel del sistema complejo afectadas por los sistemas con fallos se correlacionan con los datos de diseno que incluyen a las funciones de a nivel de sistema complejo implementadas por los respectivos sistemas con fallos.
5
10
15
20
25
30
35
40
45
50
55
60
65
En un aspecto, se describe un metodo de integracion de datos de fallo para diferentes presentaciones de analisis de fallos, incluyendo el metodo: recibir datos de analisis de fallos para un sistema complejo que incluye una pluralidad de sistemas, incluyendo los datos de analisis de fallos datos de fallo que identifican a uno o mas sistemas con fallos de la pluralidad de sistemas, validando los datos de analisis de fallos para de ese modo integrar los datos de fallo para una pluralidad de diferentes presentaciones de analisis de fallos, y generando de manera selectiva una presentacion cualquiera o mas de la pluralidad de diferentes presentaciones de los datos de analisis de fallos, siendo compartidos al menos algunos de los datos de analisis de fallos validados entre al menos algunas de las diferentes presentaciones.
De forma alternativa, el metodo puede incluir el que los datos de analisis de fallos incluyan ademas datos de diseno que describen el sistema complejo y posibles fallos de al menos algunos de sus sistemas, y el que la validacion de los datos de analisis de fallos incluya la realizacion de una o mas comprobaciones de consistencia entre los datos de fallo y los datos de diseno.
De forma alternativa, el metodo puede incluir el que los sistemas con fallos incluyan un sistema con fallos directamente afectado por un fallo de origen, y cualesquiera sistemas con fallos de orden inferior afectados indirectamente por el fallo de origen, el que los datos de diseno incluyan information de la interfaz logica que describa relaciones logicas entre los sistemas del sistema complejo, y el que la realizacion de las una o mas comprobaciones de consistencia incluya la realizacion de una comprobacion de consistencia de la interfaz logica utilizando los datos de fallo y la informacion de interfaz logica, incluyendo la comprobacion de consistencia de la interfaz logica una comprobacion de que el sistema con fallos esta relacionado de manera logica con los sistemas con fallos de orden inferior, o de que los sistemas relacionados de manera logica con el sistema con fallos son los sistemas con fallos de orden inferior.
De forma alternativa, el metodo puede incluir el que los datos de fallo incluyan uno o mas mensajes de alerta generados en respuesta a los respectivos fallos de los sistemas con fallos, y los datos de diseno incluyen una coleccion de mensajes de alerta asociados a diversos sistemas del sistema complejo, y el que la realizacion de una o mas comprobaciones de consistencia incluya la realizacion de una comprobacion de consistencia de las alertas utilizando los mensajes de alerta generados y la coleccion de mensajes de alerta, incluyendo la comprobacion de consistencia de las alertas una comprobacion de que los uno o mas mensajes de alerta generados para los sistemas con fallos se correlacionan con mensajes de alerta asociados a los respectivos sistemas con fallos de la coleccion de mensajes de alerta.
De forma alternativa, el metodo puede incluir el que los datos de diseno incluyan uno o mas diagramas esquematicos que describen relaciones flsicas entre el sistema complejo y sus sistemas, siendo el sistema complejo divisible en una pluralidad de zonas flsicamente diferenciadas, y el que la realizacion de las una o mas comprobaciones de consistencia incluya la realizacion de una comprobacion de consistencia de la ubicacion utilizando los datos de fallo y uno o mas diagramas esquematicos, incluyendo la comprobacion de consistencia de la ubicacion una comprobacion de que los sistemas con fallos estan situados flsicamente en la misma zona del sistema complejo.
De forma alternativa, el metodo puede incluir el que los datos de fallo incluyan niveles de riesgo para los respectivos fallos de los sistemas con fallos, y el que los datos de diseno incluyan una coleccion de niveles de riesgo asociados a diversos sistemas del sistema complejo, y
el que la realizacion de una o mas comprobaciones de consistencia incluya la realizacion de una comprobacion de consistencia de la evaluation de riesgos utilizando los niveles de riesgo para los respectivos fallos del sistema con fallos y la coleccion de mensajes de alerta, incluyendo la comprobacion de consistencia de la evaluacion de riesgos una comprobacion de que los niveles de riesgo para los respectivos fallos de los sistemas con fallos se correlacionan con niveles de riesgo asociados a los respectivos sistemas con fallos de la coleccion de niveles de riesgo.
De forma alternativa, el metodo puede incluir el que los sistemas del sistema complejo incluyan uno o mas sistemas electricos, los sistemas con fallos incluyan uno o mas sistemas electricos con fallos, y los datos de fallo identifican estados de potencia de los uno o mas sistemas electricos con fallos, el que los datos de diseno incluyan datos de carga electrica que describen los estados de potencia de uno o mas de los sistemas electricos para diferentes estados operativos del sistema complejo, y el que la realizacion de las una o mas comprobaciones de consistencia incluya la realizacion de una comprobacion de consistencia de la carga electrica utilizando los datos de fallo y datos de carga electrica, incluyendo la comprobacion de consistencia de la carga electrica una comprobacion de que los estados de potencia de los uno o mas sistemas electricos con fallos se correlacionan con los datos de carga electrica.
De forma alternativa, el metodo puede incluir el que los datos de fallo incluyan una lista de una o mas funciones a nivel del sistema complejo afectadas por los sistemas con fallos, incluyendo los datos de diseno una lista de una o mas funciones a nivel del sistema complejo y de sistemas del sistema complejo que implementan las funciones respectivas, y
5
10
15
20
25
30
35
40
45
50
55
60
65
el que la realizacion de las una o mas comprobaciones de consistencia incluye la realizacion de una comprobacion de consistencia de los impactos funcionales que incluye una comprobacion de que los datos de fallo que incluyen a las funciones a nivel del sistema complejo afectadas por los sistemas con fallos se correlacionan con los datos de diseno que incluyen a las funciones a nivel del sistema complejo implementados por los respectivos sistemas con fallos.
En un aspecto, se describe un medio de almacenamiento informatico que tiene partes de codigo de programa informatico almacenadas en su interior que, en respuesta a su ejecucion por un procesador, provocan que un aparato al menos: reciba y valide datos de analisis de fallos para un sistema complejo que incluye una pluralidad de sistemas, donde los datos de analisis de fallos incluyen datos de fallo y datos de diseno, identificando los datos de fallo a uno o mas sistemas con fallos de la pluralidad de sistemas, y describiendo los datos de diseno al sistema complejo y a posibles fallos de al menos algunos de sus sistemas, y donde el que se haga que el aparato valide los datos de analisis de fallos incluye que se haga que realice una o mas comprobaciones de consistencia entre los datos de fallo y los datos de diseno para, de ese modo, integrar los datos de fallo para una pluralidad de diferentes presentaciones de analisis de fallo, y generar de manera selectiva una presentacion cualquiera o mas de la pluralidad de diferentes presentaciones de los datos de analisis de fallo, siendo compartidos al menos algunos de los datos de analisis de fallos validados entre al menos algunas de las diferentes presentaciones.
De forma alternativa, el medio de almacenamiento informatico puede incluir el que los sistemas con fallos incluyan un sistema con fallos afectado directamente por un fallo de origen, y cualquier sistema con fallos de orden inferior indirectamente afectado por el fallo de origen, el que los datos de diseno incluyan informacion de la interfaz logica que describa relaciones logicas entre los sistemas del sistema complejo, y el que el hecho de que se haga que el aparato realice una o mas comprobaciones de consistencia incluya que se haga que realice una comprobacion de consistencia de la interfaz logica utilizando los datos de fallo y la informacion de la interfaz logica, incluyendo la comprobacion de consistencia de la interfaz logica una comprobacion de que el sistema con fallos esta relacionado de manera logica con los sistemas con fallos de orden inferior, o de que los sistemas relacionados de manera logica con el sistema con fallos son los sistemas con fallos de orden inferior.
De forma alternativa, el medio de almacenamiento informatico puede incluir el que los datos de fallo incluyan uno o mas mensajes de alerta generados en respuesta a los respectivos fallos de los sistemas con fallos, y los datos de diseno incluyen una coleccion de mensajes de alerta asociados a diversos sistemas del sistema complejo, y el hecho de que se haga que el aparato realice una o mas comprobaciones de consistencia incluya que se haga que realice una comprobacion de consistencia de las alertas utilizando los mensajes de alerta generados y la coleccion de mensajes de alerta, incluyendo la comprobacion de consistencia de las alertas una comprobacion de que los uno o mas mensajes de alerta generados para los sistemas con fallos se correlacionan con mensajes de alerta asociados a los respectivos sistemas con fallos de la coleccion de mensajes de alerta.
De forma alternativa, el medio de almacenamiento informatico puede incluir el que los datos de diseno incluyan uno o mas diagramas esquematicos que describan relaciones flsicas entre el sistema complejo y sus sistemas, siendo el sistema complejo divisible en una pluralidad de zonas flsicamente diferenciadas, y el que el hecho de que se haga que el aparato realice una o mas comprobaciones de consistencia incluya que se haga que realice una comprobacion de consistencia de la ubicacion utilizando los datos de fallo y uno o mas diagramas esquematicos, incluyendo la comprobacion de consistencia de la ubicacion una comprobacion de que los sistemas con fallos estan situados flsicamente en la misma zona del sistema complejo.
De forma alternativa, los datos de fallo incluyen niveles de riesgo para los respectivos fallos de los sistemas con fallos, y los datos de diseno incluyen una coleccion de niveles de riesgo asociados a diversos sistemas del sistema complejo, y donde el que se haga que el aparato realice una o mas comprobaciones de consistencia incluye que se haga que realice una comprobacion de consistencia de la evaluacion de riesgos utilizando los niveles de riesgo para los respectivos fallos de los sistemas con fallos y la coleccion de mensajes de alerta, incluyendo la comprobacion de consistencia de la evaluacion de riesgos una comprobacion de que los niveles de riesgo para los respectivos fallos de los sistemas con fallos se correlacionan con niveles de riesgo asociados a los respectivos sistemas con fallos de la coleccion de niveles de riesgo.
De forma alternativa, el medio de almacenamiento informatico puede incluir el que los sistemas del sistema complejo incluyan uno o mas sistemas electricos, los sistemas con fallos incluyan uno o mas sistemas electricos con fallos, y los datos de fallo identifiquen estados de potencia del uno o mas sistemas electricos con fallos, el que los datos de diseno incluyan datos electricos que describan los estados de potencia de uno o mas de los sistemas electricos para diferentes estados operativos del sistema complejo, y el que el hecho de que se haga que el aparato realice una o mas comprobaciones de consistencia incluya que se haga que realice una comprobacion de consistencia de la carga electrica utilizando los datos de fallo y datos de carga electrica, incluyendo la comprobacion de consistencia de la carga electrica una comprobacion de que los estados de potencia de los uno o mas sistemas electricos con fallos se correlacionan con los datos de carga electrica.
5
10
15
20
25
30
35
40
45
50
55
60
65
De forma alternativa, el medio de almacenamiento informatico incluye el que los datos de fallo incluyan una lista de una o mas funciones a nivel del sistema complejo afectadas por los sistemas con fallos, el que los datos de diseno incluyan una lista de una o mas funciones a nivel del sistema complejo y de sistemas del sistema complejo que implementan las respectivas funciones, y el que el hecho de que se haga que el aparato realice una o mas comprobaciones de consistencia incluya que se haga que realice una comprobacion de consistencia de los impactos funcionales que incluye una comprobacion de que los datos de fallo que incluyen a las funciones a nivel del sistema complejo afectadas por los sistemas con fallos se correlacionan con los datos de diseno que incluyen a las funciones a nivel del sistema complejo implementadas por los respectivos sistemas con fallos.
En otros aspectos de las realizaciones de ejemplo, se proporcionan un metodo y un medio de almacenamiento informatico para crear diferentes presentaciones de analisis de fallos consistentes para un sistema complejo.
Los rasgos, funciones y ventajas analizados anteriormente se pueden conseguir de forma independiente en diferentes realizaciones de ejemplo o se pueden combinar en otras realizaciones de ejemplo adicionales, de las cuales se pueden ver detalles adicionales con referencia a la siguiente descripcion y dibujos.
BREVE DESCRIPCION DEL/DE LOS DIBUJO(S)
Habiendo descrito de esta forma en terminos generales realizaciones de ejemplo de la invencion, se hara ahora referencia a los dibujos adjuntos, los cuales no estan dibujados necesariamente a escala, y en los cuales:
La Figura 1 es una ilustracion de un analisis de fallos de acuerdo con una realizacion de ejemplo;
La Figura 2 es una ilustracion de un sistema de recogida de datos de acuerdo con una realizacion de ejemplo; La Figura 3 es una ilustracion de un sistema de presentacion de datos de acuerdo con una realizacion de ejemplo;
Las Figuras 4 a 8 ilustran de forma esquematica diferentes comprobaciones de consistencia que se pueden realizar sobre datos de analisis de fallos de acuerdo con realizaciones de ejemplo; y
Las Figuras 9 a13 ilustran de forma esquematica modelos de presentacion apropiados de acuerdo con realizaciones de ejemplo.
DESCRIPCION DETALLADA
Se describiran ahora con mayor detalle algunas realizaciones de la presente invencion haciendo referencia en lo que sigue a los dibujos adjuntos, en los cuales se muestran algunas de las realizaciones de la invencion, pero no todas. Efectivamente, las diferentes realizaciones de la invencion se pueden implementar de muchas formas distintas y no se deberla interpretar que estan limitadas a las realizaciones descritas en este documento; mas bien, estas realizaciones de ejemplo se proporcionan para que esta descripcion sea minuciosa y completa, y transmita totalmente el alcance de la descripcion a aquellas personas que tengan experiencia en la tecnica. Asimismo, algo que se puede mostrar o describir como si estuviera por encima de otro elemento (a menos que se indique otra cosa) puede estar por debajo en vez de por encima, y viceversa; y de manera similar, algo mostrado o descrito como si estuviera a la izquierda de otro elemento puede estar a la derecha en vez de a la izquierda, y viceversa. Numeros de referencia similares hacen referencia a elementos similares a lo largo de toda la descripcion.
Las realizaciones de ejemplo de la presente invencion estan relacionadas de forma general con la presentacion de datos de analisis de fallos y, en particular, con la creacion de presentaciones de analisis de fallos diferentes y consistentes, para un sistema complejo. Las realizaciones de ejemplo se describiran principalmente en conjunto con aplicaciones aeroespaciales. Sin embargo, se deberla entender que las realizaciones de ejemplo se pueden utilizar en conjunto con una variedad de otras aplicaciones, tanto de dentro como de fuera de la industria aeroespacial. A este respecto, las realizaciones de ejemplo se pueden utilizar en conjunto con sistemas complejos, tales como en el caso de las industrias aeroespacial, de automocion, marina y electronica. El acceso a datos de fallo precisos y consistentes es importante porque puede afectar a multiples aspectos de operaciones de equipos, incluidos seguridad, operaciones, mantenimiento, soporte a ingenierla y similares.
En un sistema complejo, tal como por ejemplo una aeronave, los datos de analisis de fallos pueden estar relacionados con uno o mas fallos. Un sistema complejo puede estar compuesto generalmente por uno o mas componentes, subsistemas o similares (cada uno de ellos denominado generalmente “subsistema”), estando cada subsistema compuesto por una o mas partes, e incluyendo cada parte uno o mas rasgos. A este respecto, las partes del sistema complejo pueden estar ensambladas para formar varios subsistemas, los cuales a su vez pueden estar ensamblados para formar el sistema complejo. En el contexto de una aeronave, una o mas partes o subsistemas pueden estar disenados como un componente modular de la aeronave, denominado a menudo unidad sustituible en llnea (LRU), pudiendo una unica aeronave incluir varias LRUs y otras partes o subsistemas. A cualquier elemento de entre el propio sistema complejo o cualquiera de sus subsistemas, partes (de subsistemas), rasgos (de partes) o similares se les puede denominar en ocasiones, de forma general, “sistema”.
Haciendo ahora referencia a la Figura 1, se ilustra un sistema 100 de analisis de fallos de acuerdo con realizaciones de ejemplo de la presente invencion. El sistema puede incluir cualquier subsistema de varios diferentes (cada uno un sistema individual) para realizar una o mas funciones u operaciones con respecto a datos de analisis de fallos. Como se muestra, por ejemplo, el sistema puede incluir un sistema 102 de recogida de datos y/o un sistema 104 de
5
10
15
20
25
30
35
40
45
50
55
60
65
presentacion de datos. Aunque se muestran como parte del sistema de analisis de fallos, en vez de esto, uno o mas de entre el sistema de recogida de datos y/o el sistema de presentacion de datos puede ser independiente del sistema de analisis de fallos pero estar en comunicacion con el. Tambien se deberla entender que uno o mas de los subsistemas puede funcionar u operar como un sistema independiente sin tener en cuenta a otros subsistemas. Y ademas, se deberla entender que el sistema de analisis de fallos puede incluir uno o mas subsistemas adicionales o alternativos a los mostrados en la Figura 1.
Como se describe en este documento, los datos de analisis de fallos pueden incluir datos de fallo y/o datos de diseno, y pueden estar relacionados con uno o mas fallos de un sistema complejo. Como se describe en este documento, un fallo puede hacer referencia a una averla, a una degradacion o a un fallo. Generalmente, puede ser posible visualizar los datos de analisis de fallos de forma electronica y/o impresa (o imprimible); y a este respecto, los datos de analisis de fallos pueden incluir uno o mas de contenido en forma de texto, en forma grafica u otro contenido visual tal como imagenes fijas, video o similar.
Para cada uno de los uno o mas casos de fallo del sistema complejo, los datos de fallo pueden identificar o describir (siendo estos dos terminos sinonimos en este documento, y en ocasiones utilizandose de forma general “identificar”) un fallo a nivel de sistema y, en diferentes casos, uno o mas efectos del fallo a nivel de sistema. En un ejemplo, los datos de fallo pueden ser apropiados para su utilizacion en cualquiera de varios diferentes analisis de fallos de aeronaves, tales como evaluacion de riesgos particular (PRA), analisis de amenazas, analisis de seguridad zonal, analisis de modos de fallo y efectos (FMEA) a nivel del sistema, FMEA a nivel del avion (tambien conocido como FMEA de sistemas multiples), analisis de fallos debidos a causas comunes (CCA) o similares.
Los efectos de un fallo a nivel de sistema pueden incluir uno o mas efectos directos y, en diversos casos, uno o mas efectos indirectos, cada uno de los cuales se puede manifestar el mismo como un fallo. A este respecto, un efecto directo puede ser cualquier efecto primario (o de origen) que sea resultado directo de un fallo de origen a nivel de sistema. Un efecto indirecto puede ser cualquier efecto secundario (o de segundo orden), cualquier efecto terciario (o de tercer orden), cualquier efecto cuaternario (o de cuarto orden) y as! sucesivamente que sean resultados indirectos de un fallo de origen a nivel de sistema, y que sean resultados directos de un efecto directo o de otro efecto indirecto. En un ejemplo, los efectos indirectos se pueden manifestar ellos mismos como fallos de orden inferior. Por ejemplo, un efecto indirecto se puede manifestar el mismo como cualquier fallo secundario (o de segundo orden), cualquier fallo terciario (o de tercer orden), cualquier fallo cuaternario (o de cuarto orden) y as! sucesivamente. Un efecto puede estar asociado a una combinacion de casos de fallo, otros efectos o combinaciones de ambos, que solo se producen cuando se produce la combinacion. Por ejemplo, un cierto efecto directo se puede producir solo cuando se producen dos fallos, o un cierto efecto indirecto se puede producir solo cuando se producen dos efectos directos y/o dos efectos indirectos.
Una aeronave, por ejemplo, puede experimentar un fallo de un bus electrico o del sistema de navegacion de la aeronave. Este fallo puede producir a su vez efectos directos tales como efectos hidraulicos, efectos en la navegacion y/o efectos en la avionica, uno cualquiera o mas de uno de los cuales puede producir uno o mas efectos indirectos. Por ejemplo, un efecto hidraulico puede producir un efecto sobre el control de vuelo, el cual a su vez puede producir un efecto de vibracion del fuselaje.
Los datos de fallo para un caso de fallo pueden identificar un fallo y uno o mas efectos o fallos de orden inferior provocados por el, y pueden incluir ademas uno o mas mensajes de alerta tales como mensajes de alerta para la tripulacion, mensajes de estado, mensajes de mantenimiento o similares que se pueden haber generado en respuesta a un fallo (fallo de origen o de orden inferior). Por ejemplo, un mensaje de alerta puede ser un mensaje de alerta accionable para la tri pulacion que se muestra a la tripulacion de vuelo para indicar una falta de presurizacion adecuada de la cabina. Un ejemplo de un mensaje de alerta para la tripulacion de este tipo es un mensaje EICAS (sistema de indicacion de los motores y de alerta a la tripulacion).
Los datos de fallo pueden incluir una o mas acciones compensatorias (por ejemplo, conmutar a energla alternativa, hacer descender la aeronave) que pueden haber sido emprendidas en respuesta a un fallo, por ejemplo por la tripulacion o por uno o mas sistemas del sistema complejo. Los datos de fallo pueden incluir una descripcion del efecto adicional, que puede estar relacionado con uno o mas efectos adicionales del respectivo fallo (por ejemplo, perdida de iluminacion, falta de extension del tren de aterrizaje normal, perdida de visualizacion). Los datos de fallo pueden incluir ademas un mapeado o correlation entre cada fallo a nivel de sistema y un estado funcional de un respectivo sistema. En un ejemplo, los estados funcionales puede venir dados por categorlas, por ejemplo por las siguientes categorlas en orden decreciente de funcionalidad: “totalmente funcional”, “degradado”, y “con fallos”.
Los datos de fallo tambien pueden incluir una probabilidad y un nivel de riesgo para cada fallo o para cada sistema con fallos (sistema con fallos o sistema con fallos de orden inferior), y pueden incluir ademas un riesgo a nivel del sistema complejo global. A este respecto, la probabilidad puede indicar la posibilidad de que el fallo se produzca en vuelo, y el nivel de riesgo puede indicar el efecto del fallo sobre los ocupantes y/o sobre las operaciones del sistema complejo. En un ejemplo, los niveles de riesgo se pueden representar de forma numerica, por ejemplo en orden de “uno” a “cinco” en nivel de riesgo creciente. En otro ejemplo, los niveles de riesgo pueden venir dados por
5
10
15
20
25
30
35
40
45
50
55
60
65
categorlas, por ejemplo por las siguientes categorlas en orden creciente de nivel de riesgo: “ningun efecto sobre la seguridad”, “menor”, “grave”, “peligroso” y “catastrofico”.
Mas aun, los datos de fallo pueden incluir una lista de una o mas funciones a nivel de sistema complejo afectadas por cada fallo. En un ejemplo, funciones a nivel de la aeronave que pueden verse afectadas por un fallo pueden incluir integridad estructural, estabilidad y control, conciencia operativa, control ambiental, generacion y distribucion de energla, carga, mantenimiento y maniobrabilidad en tierra, control en tierra o similares.
Tambien como parte de los datos de analisis de fallos, los datos de diseno pueden incluir informacion que describa el sistema complejo y posibles fallos de al menos algunos de sus sistemas. Por ejemplo, los datos de diseno pueden incluir uno o mas diagramas esquematicos del sistema complejo y/o de sus sistemas, los cuales pueden describir las relaciones flsicas entre sistemas. De forma adicional o alternativa, por ejemplo, los datos de diseno pueden incluir informacion de la interfaz logica, la cual puede describir relaciones logicas entre sistemas, y donde dichas relaciones logicas pueden estar reflejadas mediante interfaces logicas entre los respectivos sistemas. Un ejemplo de informacion de la interfaz logica es la proporcionada por un documento de control de interfaces (ICD). Ademas, por ejemplo, los datos de diseno pueden incluir una lista de una o mas funciones a nivel del sistema complejo y de uno o mas sistemas del sistema complejo que implementan las respectivas funciones.
En otro ejemplo, los datos de diseno pueden incluir datos de carga electrica, los cuales pueden describir el estado de potencia de uno o mas sistemas electricos (por ejemplo, alimentado, no alimentado, alimentado de forma intermitente) en diversos estados operativos del sistema complejo. En el contexto de una aeronave, en ciertos estados operativos (por ejemplo, en tierra, arranque, apagado de un motor, etc.), un sistema electrico puede estar en diversos estados de potencia (por ejemplo, a media potencia, a un cuarto de potencia, etc.). En estas situaciones, ciertos sistemas pueden estar alimentados mientras que otros sistemas pueden no estar alimentados. Por lo tanto, los datos de diseno pueden indicar que sistemas estan en “interrupcion de la carga” (por ejemplo, energla desconectada de algunos equipos para mantener funcionalidad basica en ciertos escenarios). En un ejemplo, entonces, los datos de carga electrica se pueden dar en una o mas listas de “interrupcion de la carga”.
Los datos de diseno tambien pueden incluir, por ejemplo, una coleccion de mensajes de alerta que se pueden generar para diferentes sistemas asociados, y/o la logica de acuerdo con la cual se pueden configurar los respectivos mensajes. En un ejemplo, los mensajes de alerta pueden ser priorizados de acuerdo con una necesidad de accion creciente, como por ejemplo “aviso”, “precaucion” y “alerta”. En otro ejemplo, los datos de diseno pueden incluir una coleccion de acciones compensatorias que se pueden emprender en respuesta a un fallo, y/o la logica de acuerdo con la cual se pueden emprender las respectivas acciones. En otro ejemplo adicional, los datos de diseno pueden incluir una coleccion de niveles de riesgo que se pueden proporcionar para el sistema complejo y/o para diversos sistemas asociados, y/o conjuntos de fallos para los cuales se pueden configurar diferentes niveles de riesgo. En un ejemplo, los niveles de riesgo y los conjuntos de fallos pueden ser proporcionados por datos de evaluation de seguridad del sistema (SSA) y/o de evaluation de riesgos funcionales (FHA).
Como se explica con mayor detalle mas adelante, el sistema 102 de recogida de datos del sistema 100 de analisis de fallos puede estar configurado de manera general para recoger y validar datos de fallo para, de ese modo, integrar los datos de fallo para diferentes presentaciones de datos de analisis de fallos, los cuales pueden incluir al menos algunos de los datos de fallo y de los datos de diseno. Y el sistema 104 de presentation de datos puede estar configurado de manera general para generar de manera selectiva una cualquiera o mas de una pluralidad de diferentes presentaciones de datos de analisis de fallos, siendo compartidos al menos algunos de los datos de analisis de fallos entre al menos algunos de los diferentes presentaciones. La presentacion se puede presentar visualmente; y en un ejemplo, la presentacion visual de una presentacion puede ser visualizable por ejemplo en una interfaz grafica de usuario (GUI) presentada por una pantalla de visualization. En otro ejemplo, la presentacion visual puede ser imprimible por ejemplo por una impresora configurada para generar una impresion de la presentacion. En ocasiones, a la presentacion visual de una presentacion se le puede denominar simplemente la presentacion.
Los analisis de fallos son una practica habitual en industrias enfocadas a sistemas complejos, tal como la industria aeroespacial lo esta para las aeronaves. La evaluacion de la clasificacion de riesgo global (por ejemplo, “a nivel de sistema complejo”) y la aceptabilidad de casos de fallo concretos puede implicar a muchos implicados, cada uno de los cuales requiere su propia presentacion de eventos. Cada presentacion de un implicado puede proporcionar una explication parcial o incompleta de un caso de fallo concreto. Por lo tanto, realizaciones de ejemplo de la presente invention pueden crear presentaciones de fallo individuales y definir reglas y comprobaciones de consistencia para integrar datos de analisis de fallos que subyacen tras los presentaciones de tal manera que se puede hacer una evaluacion completa de un caso de fallo.
Se hara ahora referencia a las Figuras 2 y 3, las cuales ilustran ejemplos mas concretos de un sistema de recogida de datos y de un sistema de presentacion de datos apropiados, respectivamente, de acuerdo con realizaciones de ejemplo de la presente invencion.
5
10
15
20
25
30
35
40
45
50
55
60
65
La Figura 2 ilustra un sistema 200 de recogida de datos, el cual en una realization de ejemplo puede corresponder al sistema 102 de recogida de datos. Como se muestra, el sistema de recogida de datos puede incluir un validador de datos configurado para recibir datos de analisis de fallos incluyendo datos de fallo y/o datos de diseno. El validador de datos puede estar configurado para recibir los datos de analisis de fallos procedentes de cualquiera de varias fuentes diferentes, y los cuales pueden estar formateados de cualquier manera de varias diferentes. Por ejemplo, el validador de datos puede estar configurado para recibir datos de fallo para uno o mas casos de fallo procedentes directamente de un operador, por ejemplo a traves de tecnicas de introduction de datos. En otro ejemplo, el validador de datos puede estar configurado para recibir datos de fallo procedentes directamente de un sistema complejo que falla, el cual puede estar provisto de uno o mas sensores o sistemas integrados configurados para transmitir una senal en caso de que el o uno de sus sistemas experimente un fallo. En otro ejemplo adicional, el validador de datos puede estar configurado para recibir datos de fallo procedentes de un almacenamiento apropiado como por ejemplo un almacenamiento en ficheros, un almacenamiento en bases de datos, un almacenamiento en la nube o similares.
Cuando el validador 202 de datos recibe datos de analisis de fallos, o despues de recibirlos, el citado validador de datos puede estar configurado para validar al menos una parte de los datos de analisis de fallos, incluyendo la realizacion de una o mas comprobaciones de consistencia entre los datos de fallo y los datos de diseno. En el caso de que el validador de datos valide con exito los datos de analisis de fallos, el validador de datos puede estar configurado para comunicar los datos de fallo y los datos de diseno a respectivos almacenamientos 204, 206 para su almacenamiento y posterior recuperation. El almacenamiento puede ser residente con el sistema 200 de recogida de datos, o puede ser independiente del sistema de recogida de datos y estar en comunicacion con el. Los datos de analisis de fallos pueden ser formateados y almacenados de cualquier manera de varias diferentes y, por lo tanto, su almacenamiento puede ser de cualquier tipo de varios diferentes. Ejemplos de tipos de almacenamiento apropiados incluyen almacenamiento en ficheros, almacenamiento en bases de datos, almacenamiento en la nube o similares.
En el caso de que el validador 202 de datos no consiga validar con exito cualquier parte de los datos de analisis de fallos, el validador de datos puede estar configurado para senalizar con una bandera los respectivos datos de analisis de fallos, y puede estar ademas configurado para comunicar una indication de que existe una bandera. En un ejemplo, la indicacion de que existe una bandera se puede comunicar a una GUI en la cual se puede visualizar, o a una impresora para generar una impresion de ella. En otro ejemplo, la indicacion de que existe una bandera se puede comunicar a otro sistema, aparato o similar de acuerdo con cualquier tecnica de mensajerla de varias diferentes, tal como por ejemplo correo electronico, mensajerla instantanea o similar.
El validador 202 de datos puede estar configurado para validar o realizar una o mas comprobaciones de consistencia sobre al menos una parte de los datos de analisis de fallos de cualquier manera de varias diferentes. En un ejemplo, como se muestra en la Figura 4, el validador de datos puede estar configurado para realizar una comprobacion de consistencia de la interfaz logica utilizando la information de la interfaz logica de los datos de fallo que describe las interfaces logicas entre sistemas del sistema complejo. Las interfaces logicas entre un sistema y otro u otros sistemas pueden indicar sistemas en los que, en el caso de fallo del respectivo sistema, se deberla esperar que se produjeran efectos (por ejemplo, un efecto propiamente dicho, una reduction de redundancia, “ningun efecto”, etc.). Entonces, para un caso de fallo que identifica a un sistema con fallos (directamente afectado) y a uno o mas sistemas con fallos de orden inferior (indirectamente afectados), el validador de datos puede estar configurado para comprobar que el sistema con fallos esta relacionado de manera logica con todos los sistemas con fallos de orden inferior, y/o que todos los sistemas relacionados de forma logica del sistema con fallos son sistemas con fallos de orden inferior.
En otro ejemplo, como se muestra en la Figura 5, el validador 202 de datos puede estar configurado para realizar una comprobacion de consistencia de las alertas para la tripulacion utilizando los datos de fallo y la coleccion de mensajes de alerta que se pueden proporcionar para diversos sistemas asociados del sistema complejo. En un ejemplo mas concreto, los datos de fallo para un caso de fallo pueden incluir uno o mas mensajes de alerta que pueden ser enviados o generados para el fallo y/o uno o mas de sus efectos, y los cuales pueden estar asociados al sistema con fallos y/o a uno o mas sistemas con fallos de orden inferior. Los datos de diseno pueden incluir, de manera similar, una coleccion de mensajes de alerta que se pueden proporcionar para sistemas asociados del sistema complejo. Por lo tanto, el validador de datos puede comprobar que cualquier mensaje de alerta generado para un sistema con fallos o para un sistema con fallos de orden inferior se correlaciona con un mensaje de alerta asociado al respectivo sistema con fallos de la coleccion de mensajes de alerta.
En otro ejemplo, como se muestra en la Figura 6 en el contexto de una aeronave, el validador 202 de datos puede estar configurado para realizar una comprobacion de consistencia de la ubicacion utilizando los datos de fallo, uno o mas diagramas esquematicos del sistema complejo y/o de sus sistemas, y/o informacion de interfaz logica. Un sistema puede estar conectado a su ubicacion flsica dentro del sistema complejo, el cual puede estar dividido en varias zonas flsicamente diferenciadas. Algunos analisis de fallos tales como los analisis PRA (por ejemplo, analisis de choque con aves, analisis de explosion del rotor -rotoburst-, etc.), asumen fallos en todos los sistemas situados dentro de una zona concreta. A su vez, los sistemas afectados en la zona concreta pueden tener efectos “en cascada” sobre los sistemas relacionados de manera logica con ellos, los cuales pueden estar en la misma zona o en otra. Por lo tanto, el validador de datos puede comprobar que los sistemas con fallos y los sistemas con fallos de
5
10
15
20
25
30
35
40
45
50
55
60
65
orden inferior en un caso de fallo estan situados flsicamente en la misma zona del sistema complejo, y puede senalizar con una bandera cualquier fallo que falte o que este incompleto para sistemas situados dentro de la zona respectiva. El validador de datos puede entonces realizar una comprobacion de consistencia de la interfaz logica para sistemas relacionados de manera logica situados en otras zonas del sistema complejo, por ejemplo de la manera descrita anteriormente con respecto a la Figura 4.
Como se muestra en la Figura 7, el validador 202 de datos puede estar configurado para realizar una comprobacion de consistencia de la evaluacion de riesgos utilizando los datos de fallo y la coleccion de niveles de riesgos que se pueden proporcionar para el sistema complejo y/o para algunos de sus sistemas, pudiendo dicha coleccion ser proporcionada en un ejemplo mediante datos SSA y/o FHA. Los sistemas individuales del sistema complejo pueden proporcionar datos de fallo de sus respectivos sistemas y efecto del riesgo local (efecto y riesgo asociados a su sistema) - el riesgo a nivel del sistema complejo (por ejemplo, al nivel de la aeronave) puede no ser transparente a partir de los efectos a nivel de sistema y riesgos a nivel de sistema asociados.
En relacion con a la comprobacion de consistencia de la evaluacion de riesgos, se puede realizar por lo tanto un analisis a nivel de sistema complejo para determinar el efecto global, el cual puede ser reflejado por un riesgo a nivel de sistema complejo. El validador 202 de datos puede estar configurado para comprobar que el riesgo a nivel de sistema complejo asociado a un fallo no es menor que un riesgo a nivel de sistema individual (por ejemplo, que un riesgo a nivel de sistema complejo es calificado como “grave” mientras que uno de sus sistemas lo califica como “peligroso”). En un caso en el que el nivel de riesgo del sistema complejo sea menor que el de uno de sus sistemas, el validador de datos puede senalizar con una bandera el caso de fallo. Esta situacion se puede remediar en un ejemplo incrementando el riesgo a nivel de sistema complejo o reduciendo el mayor riesgo a nivel del sistema.
De forma adicional o alternativa, por ejemplo, la comprobacion de consistencia de la evaluacion de riesgos puede incluir que el validador 202 de datos compruebe que el nivel de riesgo local para un sistema con fallos o para un sistema con fallos de orden inferior es consistente con el nivel o niveles de riesgo del sistema que se pueden proporcionar para el respectivo sistema (por ejemplo, a partir de datos FHA). Es decir, el validador de datos puede comprobar que el nivel de riesgo local para sistemas con fallos o para sistemas con fallos de orden inferior se correlaciona con niveles de riesgo asociados a los respectivos sistemas de la coleccion de niveles de riesgo. En un caso en el que el nivel de riesgo local no es consistente, el caso de fallo se puede senalizar con una bandera. En un ejemplo, esta condicion inaceptable se puede remediar modificando el riesgo local para el analisis de fallos o modificando los datos FHA del sistema.
En un ejemplo adicional, el validador 202 de datos puede estar configurado para realizar una comprobacion de consistencia de la carga electrica utilizando los datos de fallo y los datos de carga electrica, los cuales de nuevo se proporcionan en una o mas listas de “interrupcion de la carga”. En algunos analisis de fallo, los sistemas electricos pueden verse afectados y, en estos casos, los datos de fallo pueden identificar a los estados de potencia (por ejemplo, alimentado o no alimentado) de estos sistemas electricos con fallos. Basandose en el efecto de potencia electrica y en el estado de “interrupcion de la carga” asociado, sistemas de la lista de “interrupcion de la carga” pueden estar “interrumpidos” o con fallos a efectos del analisis. Esta comprobacion de consistencia puede garantizar que todos los sistemas de la lista de interrupcion de la carga para casos de fallo concretos esten representados de manera apropiada en los analisis de fallo. Es decir, esta comprobacion de consistencia puede incluir una comprobacion de que los estados de potencia de uno o mas sistemas electricos con fallos se correlacionan con los datos de carga electrica. Las discrepancias se pueden senalizar con banderas para su revision y correccion/eliminacion.
En un ejemplo adicional mas, como se muestra en la Figura 8, el validador 202 de datos puede estar configurado para realizar una comprobacion de consistencia de los impactos funcionales utilizando los datos de fallo y los datos de diseno. En un ejemplo mas concreto, los datos de fallo para un caso de fallo pueden incluir una lista de una o mas funciones a nivel del sistema complejo afectadas por los sistemas con fallos o por los sistemas con fallos de orden inferior. De manera similar, los datos de diseno incluyen una lista de funcion o funciones a nivel de sistema complejo y del sistema o sistemas del sistema complejo que implementan la respectiva funcion o funciones. Por lo tanto, el validador de datos puede comprobar que las funciones a nivel de sistema complejo afectadas por los sistemas con fallos o por los sistemas con fallos de orden inferior se correlacionan con las funciones a nivel de sistema complejo implementadas por los respectivos sistemas con fallos.
En diversos casos, despues de que los datos de fallo y los datos de diseno se hayan comunicado al almacenamiento 204, 206 respectivo, cualquiera de ellos o los dos pueden ser modificados por ejemplo por un operador. En estos casos modification puede significar cualquier cambio a los datos de varios diferentes incluyendo, por ejemplo, una adicion, un borrado, una revision o similar. En estos casos, el validador 202 de datos puede estar configurado para validar los datos de fallo o de diseno modificados y cualquier otro dato del almacenamiento respectivo que puedan ser afectados por los datos de fallo o de diseno modificados.
En un ejemplo, se puede efectuar una modificacion de los datos de diseno mediante una solicitud de cambio (CR) u otro mecanismo similar. Una CR puede afectar a uno o mas sistemas del sistema complejo, y puede afectar a una o mas areas incluyendo interfaces logicas entre sistemas (por ejemplo, interfaces logicas nuevas/borradas/revisadas)
5
10
15
20
25
30
35
40
45
50
55
60
65
y/o mensajes de alerta (por ejemplo, asociaciones nuevas/borradas/revisadas entre alertas y sistemas). De forma adicional o alternativa, por ejemplo, una CR puede afectar a la ubicacion zonal de un sistema por ejemplo en el caso de que el sistema se mueva entre zonas. En eventos como este o similares, una CR puede incluir informacion acerca de las interfaces y del sistema implicados en el cambio (el lado del diseno), uno cualquiera o mas de los cuales puede estar relacionado con datos de fallo de uno o mas casos de fallo. Por lo tanto, el validador 202 de datos puede estar configurado para identificar caracterlsticas comunes entre interfaces afectadas y/o entre sistemas dentro del mecanismo de cambio y para relacionarlas con el caso o los casos de fallo apropiados. Si se encuentra una relacion, esta puede ser senalada con una bandera para su evaluacion en cuanto a si un cambio en el analisis de fallos puede estar justificado.
Se hace ahora referencia a la Figura 3, la cual ilustra un sistema 300 de presentacion de datos de acuerdo con una realizacion de ejemplo. Como se ha indicado anteriormente, el sistema 300 de presentacion de datos puede ser un ejemplo del sistemas 104 de presentacion de datos del sistema 100 de analisis de fallos de la Figura 1. El sistema de presentacion de datos puede estar configurado de manera general para generar una presentacion de datos de analisis de fallos que incluya datos de fallo y/o datos de diseno. Estos datos pueden ser o incluir, por ejemplo, datos procedentes del sistema 102 de recogida de datos, o mas concretamente en un ejemplo, del sistema 200 de recogida de datos de la Figura 2.
Como se muestra en la Figura 3, el sistema 300 de presentacion de datos puede incluir una interfaz de solicitud o similar configurada para recibir una solicitud de datos de analisis de fallos. En un ejemplo, la interfaz de solicitud puede ser parte de un motor 302 de presentaciones, de un generador de presentaciones o similar configurado para generar una presentacion de los datos de analisis de fallos solicitados. Los datos de analisis de fallos pueden incluir datos de fallo y/o datos de diseno, los cuales se pueden almacenar en un respectivo almacenamiento 304, 306, el cual en un ejemplo puede corresponder al respectivo almacenamiento 204, 206 mostrado en la Figura 2.
El motor 302 de presentaciones puede estar configurado para seleccionar un modelo de presentacion de entre una pluralidad de modelos de presentaciones para seleccionar y organizar los datos de analisis de fallos solicitados. El motor de presentaciones puede estar configurado para seleccionar el modelo de presentacion de cualquier manera de varias diferentes. En un ejemplo, el motor de presentaciones puede estar configurado para seleccionar el modelo de presentacion de acuerdo con la solicitud de datos de analisis de fallo, la cual puede indicar o reflejar un modelo de presentacion concreto. Los modelos de presentacion pueden incluir cualquier tipo de presentacion de varios de ellos diferentes para la organizacion de datos de analisis de fallos. Como se ha indicado anteriormente y se explica con mayor detalle mas adelante, ejemplos de modelos de presentacion apropiados incluyen un modelo de presentacion de efectos en cascada, un modelo de presentacion de cabina de vuelo, un modelo de presentacion del perfil de vuelo, un modelo de presentacion de impactos funcionales, un modelo de presentacion de planificacion de ensayos o similares. Otros ejemplos pueden incluir combinaciones de uno o mas de los anteriores modelos de presentacion. Los modelos de presentacion se pueden mantener en un respectivo almacenamiento, tal como por ejemplo almacenamiento en fichero, almacenamiento en base de datos, almacenamiento en la nube o similar, y se pueden formatear y almacenar de cualquier manera de varias diferentes de acuerdo con el almacenamiento respectivo.
El motor 302 de presentaciones puede estar configurado para recuperar del respectivo almacenamiento 304, 306 los datos de analisis de fallos solicitados para el modelo de presentacion seleccionado. El motor de presentaciones puede estar configurado para generar una presentacion de los datos de analisis de fallos solicitados, los cuales se pueden organizar de acuerdo con el modelo de presentacion seleccionado. El motor de presentaciones puede estar entonces configurado para comunicar la presentacion, por ejemplo a una GUI en la cual se puede visualizar una presentacion, o una impresora para generar una impresion de la presentacion.
La presentacion generada por el motor 302 de presentaciones puede ser generada de forma dinamica de acuerdo con un modelo de presentacion seleccionado, de tal manera que cambiando el modelo de presentacion seleccionado se pueda realizar una presentacion diferente de los datos de analisis de fallos. En un ejemplo, el motor de presentaciones puede por lo tanto estar ademas configurado para recibir una solicitud para una organizacion diferente de datos de analisis de fallo. En este ejemplo, el motor de presentaciones puede estar configurado para seleccionar un modelo de presentacion diferente de entre la pluralidad de modelos de presentacion en respuesta a la solicitud. El motor de presentaciones puede entonces estar configurado para generar una presentacion diferente de los datos de analisis de fallos recuperados. Esto puede incluir el que el motor de presentaciones este configurado para reorganizar datos de analisis de fallos de acuerdo con el modelo de presentacion diferente seleccionado.
Como se ha indicado anteriormente, los modelos de presentacion pueden incluir cualquier tipo de presentacion de varios diferentes para organizar datos de analisis de fallos. Se hara ahora referencia a las Figuras 9-13, las cuales ilustran de forma esquematica ejemplos de modelos de presentacion apropiados. Como se muestra, estos ejemplos incluyen una presentacion de efectos en cascada, una presentacion de cabina de vuelo, una presentacion del perfil de vuelo, una presentacion de impactos funcionales, una presentacion de planificacion de ensayos o similar.
La Figura 9 ilustra un modelo 900 de presentacion de efectos en cascada de acuerdo con una realizacion de ejemplo. El modelo de presentacion de efectos en cascada proporciona de manera general una representacion
5
10
15
20
25
30
35
40
45
50
55
60
65
grafica de efectos de fallo en cascada incluyendo uno o mas efectos directos, y en diferentes casos, uno o mas efectos indirectos. Como se ha explicado anteriormente, un efecto directo puede ser cualquier efecto primario (o de origen) que se produzca directamente como resultado de un fallo a nivel de sistema de origen. Un efecto indirecto puede ser cualquier efecto secundario (o de segundo orden), un efecto terciario (o de tercer orden), un efecto cuaternario (o de cuarto orden) y as! sucesivamente que se produzca indirectamente como resultado de un fallo a nivel de sistema de origen, y directamente de un efecto directo o de otro efecto indirecto. Este modelo de presentacion puede ser de particular interes para entender las razones detras de los efectos y los impactos a traves de sistemas del sistema complejo. Este modelo de presentacion puede ser util para varios implicados diferentes del sistema complejo tales como ingenieros de sistemas, representantes autorizados (ARs), ingenieros de seguridad, expertos en la materia del sistema individual (SMEs), pilotos o similares.
Como se muestra en la Figura 9, en el modelo 900 de presentacion de efectos en cascada para un caso de fallo, cada sistema del sistema complejo puede ser representado como un nodo 902 y puede incluir datos 904 de fallo respectivos tales como uno o mas mensajes de alerta (por ejemplo, mensajes ElCAS), nivel de riesgo a nivel de sistema y/o descripcion del efecto adicional (senalandose solo un nodo y mostrandose sus respectivos datos de fallo en la Figura 9). El modelo de presentacion de efectos en cascada tambien puede ilustrar conexiones 906 (senalandose solo una conexion) entre los nodos 902, las cuales pueden ilustrar como un fallo de un sistema del sistema complejo puede producir como resultado, de forma directa o indirecta, un fallo de uno o mas sistemas del sistema complejo. En un ejemplo, se pueden presentar estas conexiones para ilustrar efectos en cascada de un fallo de sistema. A este respecto, el modelo de presentacion de efectos en cascada puede identificar un sistema con fallos de origen, y que puede experimentar uno o mas efectos directos del fallo. A su vez, el sistema con fallos de origen puede estar conectado de manera directa o indirecta a uno o mas sistemas con fallos de orden inferior que pueden experimentar uno o mas efectos indirectos respectivos. Por ejemplo, el sistema con fallos de origen puede estar directamente conectado a uno o mas sistemas con fallos secundarios que pueden experimentar respectivos uno o mas efectos secundarios. A su vez, el sistema o sistemas con fallos secundarios respectivos pueden experimentar uno o mas respectivos efectos terciarios. Para el sistema complejo, esto puede ocurrir para n ordenes de sistemas extraldos del sistema con fallos de origen.
En un ejemplo, los nodos 902 del modelo 900 de presentacion de efectos en cascada se pueden organizar por el orden de sus efectos. El sistema con fallos de origen se puede organizar de acuerdo a que experimente o no efectos 908 directos. Este sistema con fallos de origen puede estar conectado entonces a uno o mas sistemas con fallos secundarios organizados de acuerdo a que experimente o no los efectos 910 secundarios, y los cuales pueden estar conectados a uno o mas sistemas con fallos terciarios organizados de acuerdo a que experimente o no los efectos 914 terciarios. Se deberla entender que aunque el modelo de presentacion de efectos en cascada de la Figura 9 parece indicar al menos dos ordenes de efectos resultantes de un fallo de origen, menos de dos ordenes de efectos pueden resultar de un fallo de origen (incluyendo un fallo de origen solo con efectos directos).
La Figura 10 ilustra un modelo 1000 de presentacion de cabina de vuelo de acuerdo con una realizacion de ejemplo. El modelo de presentacion de cabina de vuelo proporciona de manera general una representation grafica de efectos de fallo en cascada que pueden ser experimentados por uno o mas sistemas de cabina de vuelo. El modelo de presentacion de cabina de vuelo puede ser de particular interes para entender como puede aparecer un fallo concreto a la tripulacion de una aeronave u otro sistema complejo similar. Esta information puede ser util para implicados tales como ingenieros de sistemas, ARs, ingenieros de seguridad, PYMEs de sistemas, pilotos y similares.
Como se muestra en la Figura 10, el modelo 1000 de presentacion de cabina de vuelo puede incluir una representacion esquematica de una cabina de vuelo 1002 en la cual varios de sus diferentes sistemas se pueden ilustrar mediante respectivas representaciones 1004 esquematicas (algunas de las cuales, pero no todas ellas, se senalan en la Figura 10). En un ejemplo, la cabina de vuelo y sus sistemas se pueden representar de forma esquematica de una manera que refleja la colocation de los sistemas (o mas en concreto, en un ejemplo, de sus controles) que pueden ser visibles para la tripulacion de la cabina de vuelo. En un ejemplo, esta representacion esquematica se puede generar a partir de datos de diseno para la cabina de vuelo.
A continuation, para un caso de fallo, el modelo 1000 de presentacion de cabina de vuelo puede identificar uno o mas sistemas con fallos incluidos sistemas con fallos de origen o sistemas con fallos de orden inferior, y pueden hacerlo directamente sobre sus representaciones 1004 esquematicas respectivas. En un ejemplo, el modelo de presentacion de cabina de vuelo puede resaltar mediante texto, de forma grafica o de otra manera las representaciones esquematicas de uno o mas sistemas con fallos. En un ejemplo adicional, el modelo de presentacion de cabina de vuelo puede resaltar uno o mas sistemas con fallos de una manera que refleje datos de fallo adicionales tales como los estados funcionales de los sistemas con fallos. Como se muestra en la Figura 10, por ejemplo, el modelo de presentacion de cabina de vuelo puede resaltar representaciones 1006 de sistemas con fallos que tengan un estado “degradado”, y senalar con una cruz representaciones 1008 de sistemas con fallos que tengan un estado “con fallos”.
Ademas de lo anterior, el modelo 1000 de presentacion de cabina de vuelo puede incluir datos de fallo adicionales para sistemas con fallos en la cabina de vuelo. En un ejemplo, estos datos de fallo adicionales pueden incluir para al
5
10
15
20
25
30
35
40
45
50
55
60
65
menos algunos de los sistemas con fallos, uno o mas mensajes 1010 de alerta y/o acciones compensatorias que pueden haber sido generadas o adoptadas en respuesta a un fallo. De forma adicional o alternativa, por ejemplo, los datos de fallo adicionales pueden incluir nivel de riesgo a nivel de sistema y/o descripcion de efecto adicional para al menos algunos de los sistemas con fallos.
La Figura 11 ilustra un modelo 1100 de presentation del perfil de vuelo de acuerdo con una realization de ejemplo. El modelo de presentacion del perfil de vuelo proporciona de manera general una representation grafica de efectos de fallo en cascada sobre un perfil de vuelo teorico. Este modelo de presentacion puede ser diferente a las otras presentaciones “planas” en que proporciona una vista por tiempos/por fases del vuelo de un caso de fallo. No todos los fallos de sistema se producen al mismo tiempo. En los fallos en cascada pueden existir retrasos. Por ejemplo, la perdida de refrigeration puede conducir a fallos en sistemas que pueden estar degradados o tener fallos por encima de una cierta temperatura, pero puede llevar tiempo que la temperatura del sistema, una vez enfriado, aumente por encima de la respectiva temperatura. Esta information puede ser util para implicados tales como ingenieros de sistemas, ARs, ingenieros de seguridad, PYMEs de sistemas, pilotos o similares.
Como se muestra en la Figura 11, el modelo 1100 de presentacion del perfil de vuelo puede incluir una representacion grafica de un perfil 1102 de vuelo para un vuelo de la aeronave, el cual en un ejemplo puede parecer similar a un grafico lineal de altitud de la aeronave frente al tiempo. El modelo de presentacion del perfil de vuelo puede incluir entonces un cronograma de uno o mas casos de fallo que se producen durante el vuelo, y puede hacerlo sobre el perfil de vuelo. En un ejemplo, el modelo de presentacion del perfil de vuelo puede incluir datos de fallo tales como una identification de uno o mas fallos 1104 de origen o fallos de orden inferior, y/o una o mas descripciones 1106 de efecto adicional, mensajes 1108 de alerta y/o acciones 1110 compensatorias (algunas de las cuales, pero no todas, estan senaladas en la Figura 11).
Al menos algunos de los datos de fallo del modelo 1100 de presentacion del perfil de vuelo pueden estar asociados al tiempo (a traves de una fase de vuelo identificada). Por lo tanto, el modelo de presentacion del perfil de vuelo puede incluir conexiones 1112 entre datos de fallo y tiempos sobre el perfil de vuelo (que se muestran para un ejemplo como una conexion con forma de flecha) (senalandose algunas de las conexiones, pero no todas). Por ejemplo, un fallo 1104 de origen o de orden inferior puede estar asociado al instante en el que se produjo el fallo, y efectos 1106 adicionales de un fallo pueden estar asociados al instante en el que se experimentaron esos efectos. En otro ejemplo, un mensaje 1108 de alerta puede estar asociado con el instante en el que un sistema genero el respectivo mensaje, y una action 1110 compensatoria puede estar asociada al instante en el que la tri pulacion adopto la respectiva accion. En un ejemplo, el modelo de presentacion del perfil de vuelo puede ademas indicar un retraso 1114 temporal entre un fallo y datos de fallo que se pueden generar o adoptar en respuesta al fallo.
La Figura 12 ilustra un modelo 1200 de presentacion de impactos funcionales de acuerdo con una realizacion de ejemplo. Por lo general el modelo de presentacion de impactos funcionales proporciona una representacion tabular que resume efectos a nivel de sistema individual y sus impactos sobre las funciones a nivel de sistema complejo. Este modelo de presentacion puede ser unico con respecto a los otros modelos de presentacion porque proporciona a los ingenieros una forma de evaluar el efecto global de las degradaciones de cada funcion a nivel de sistema complejo. Esta informacion puede ser util para implicados tales como ingenieros de sistemas, ARs, ingenieros de seguridad, PYMEs de sistemas, pilotos o similares.
Como se muestra en la Figura 12, el modelo 1200 de presentacion de impactos funcionales puede incluir una tabla que tenga una o mas filas (o registros) 1202 para uno o mas casos de fallo respectivos, y una o mas columnas (o campos) 1204 que especifican informacion relativa al caso o casos de fallo respectivos. Para cada caso de fallo dentro de una fila, las columnas pueden identificar un fallo y/o uno o mas efectos o fallos de orden inferior provocados por ese fallo, y pueden identificar o resumir funciones a nivel de sistema complejo afectadas por el respectivo fallo y/o fallos de orden inferior. En un ejemplo, para cada caso de fallo, una de las columnas puede proporcionar ademas un resumen del efecto combinado de cada degradation de funcion a nivel de sistema complejo y de su efecto sobre la seguridad a nivel del sistema complejo global.
La Figura 13 ilustra un modelo 1300 de presentacion de planificacion de ensayos de acuerdo con una realizacion de ejemplo. Por lo general el modelo de presentacion de planificacion de ensayos proporciona una representacion tabular que resume planes o procedimientos de ensayo para uno o mas casos de fallo y datos de fallo asociados a los respectivos casos de fallo. A este respecto, un equipo de ensayos puede realizar muchos analisis de fallos durante los ensayos del sistema complejo. El modelo de presentacion de planificacion de ensayos de las realizaciones de ejemplo se puede utilizar para generar presentaciones de planificacion de ensayos directamente a partir de datos de fallo, y puede incluir datos de fallo incluidos en otros modelos de presentacion. Esto puede facilitar que el equipo de ensayos conteste a cualquier pregunta acerca de un fallo si esta surge durante los ensayos. Por ejemplo, se pueden ver preguntas acerca de relaciones entre fallos a partir de datos de fallo en los efectos en cascada, o preguntas acerca de cuando se pueden producir los fallos durante el funcionamiento del sistema complejo pueden ser respondidas por medio de presentaciones de perfil de vuelo.
Como se muestra en la Figura 13, el modelo 1300 de presentacion de planificacion de ensayos puede incluir una tabla que tenga una o mas filas (o registros) 1302 para uno o mas respectivos casos de fallo que se quieren
5
10
15
20
25
30
35
40
45
50
55
60
65
ensayar, y una o mas columnas (o campos) 1304 que especifiquen informacion referente al caso o casos de fallo respectivos. Como se muestra, por ejemplo, las columnas pueden identificar un caso de fallo, y datos de fallo y procedimientos de ensayo para el caso de fallo. Para cada caso de fallo dentro de una fila, las columnas pueden identificar un fallo y/o uno o mas efectos o fallos de orden inferior provocados por el, y puede identificar o resumir datos de fallo y procedimientos de ensayo para el caso de fallo. En un ejemplo, para cada caso de fallo, una de las columnas puede ademas proporcionar otra informacion miscelanea que puede ser util para un equipo de ensayos.
De acuerdo con realizaciones de ejemplo de la presente invention, el sistema 100 de analisis de fallos y sus subsistemas incluidos el sistema 102 de recogida de datos y el sistema 104 de presentation de datos se pueden implementar por diferentes medios. De manera similar, los ejemplos de un sistema 200 de recogida de datos y sistema 300 de presentacion de datos, incluyendo cada uno de sus elementos respectivos, pueden ser implementados por diferentes medios de acuerdo con realizaciones de ejemplo. Medios para implementar los sistemas, subsistemas y sus respectivos elementos pueden incluir hardware, solo o bajo la direction de una o mas instrucciones de codigo de programa informatico, instrucciones de programa o instrucciones de codigo de programa informatico ejecutables procedentes de un medio de almacenamiento informatico.
En un ejemplo, se pueden proporcionar uno o mas aparatos que estan configurados para funcionar como, o implementar, los sistemas, subsistemas y respectivos elementos mostrados y descritos en este documento. En ejemplos que implican a mas de un aparato, los respectivos aparatos pueden estar conectados, o en comunicacion, entre si de varias maneras diferentes, como por ejemplo de forma directa o indirecta por medio de una red por cable o inalambrica o similar.
De forma general, un aparato de las realizaciones de ejemplo de la presente description puede comprender, puede incluir, o puede estar implementado en uno o mas dispositivos electronicos fijos o portatiles. Ejemplos de dispositivos electronicos apropiados incluyen un telefono inteligente, una tableta, un ordenador portatil, un ordenador de sobremesa, una estacion de trabajo, un ordenador servidor o similar. El aparato puede incluir uno o mas de cada uno de varios componentes tales como, por ejemplo, un procesador (por ejemplo, una unidad de procesamiento) conectado a una memoria (por ejemplo, un dispositivo de almacenamiento).
El procesador es de forma general cualquier dispositivo hardware que es capaz de procesar informacion tal como, por ejemplo, datos, codigo de programa informatico, instrucciones o similares (en ocasiones denominados de manera general “programas informaticos”, por ejemplo, software, soporte logico inalterable -firmware-, etc.), y/u otra informacion electronica apropiada. Mas en concreto, por ejemplo, el procesador puede estar configurado para ejecutar programas informaticos, los cuales pueden estar almacenados dentro del procesador o almacenados en la memoria (del mismo aparato o de otro). El procesador puede ser varios procesadores, un nucleo con multiples procesadores o algun otro tipo de procesador, dependiendo de la implementation concreta. Ademas, el procesador se puede implementar utilizando varios sistemas procesadores heterogeneos, en los cuales existe un procesador principal con uno o mas procesadores secundarios en un unico chip. Como otro ejemplo ilustrativo, el procesador puede ser un sistema simetrico de multiples procesadores que contiene multiples procesadores del mismo tipo. En otro ejemplo adicional, el procesador puede estar implementado como, o puede incluir, uno o mas circuitos integrados de aplicacion especlfica (ASlCs), matrices de puertas programables in-situ (FPGAs) o similares. De esta forma, aunque el procesador puede ser capaz de ejecutar un programa informatico para realizar una o mas funciones, el procesador de diversos ejemplos puede ser capaz de realizar una o mas funciones sin la ayuda de un programa informatico.
La memoria es de forma general cualquier soporte flsico que es capaz de almacenar informacion tal como, por ejemplo, datos, programas informaticos y/u otra informacion apropiada de modo temporal y/o de modo permanente. La memoria puede incluir memoria volatil y/o permanente, y puede ser fija o extralble. Ejemplos de memorias apropiadas incluyen memoria de acceso aleatorio (RAM), memoria de solo lectura (ROM), un disco duro, una memoria flash, una memoria USB, un disquete informatico extralble, un disco optico, una cinta magnetica o alguna combination de los anteriores. Los discos opticos pueden incluir memorias de solo lectura en disco compacto (CD- ROM), discos compactos regrabables (CD-R/W), DVDs o similares. En diferentes casos, a la memoria se le puede denominar medio de almacenamiento informatico, el cual, como dispositivo no transitorio capaz de almacenar informacion, puede ser distinguible de medios de transmision informaticos tales como senales electronicas transitorias capaces de transportar informacion desde un lugar a otro. Al medio informatico descrito en este documento se le puede denominar de forma general medio de almacenamiento informatico o medio de transmision informatico.
Ademas de la memoria, el procesador tambien puede estar conectado a una o mas interfaces para mostrar, transmitir y/o recibir informacion. Las interfaces pueden incluir una interfaz de comunicaciones (por ejemplo, una unidad de comunicacion) y/o una o mas interfaces de usuario. La interfaz de comunicaciones puede estar configurada para transmitir y/o recibir informacion, por ejemplo a y/o desde otro(s) aparato(s), red(es) o similares. La interfaz de comunicaciones puede estar configurada para transmitir y/o recibir informacion mediante enlaces de comunicaciones flsicos (por cable) y/o inalambricos. Ejemplos de interfaces de comunicacion apropiados incluyen un controlador de interfaz de red (NIC), un NIC inalambrico (WNIC) o similares.
5
10
15
20
25
30
35
40
45
50
Las interfaces de usuario pueden incluir una pantalla y/o una o mas interfaces de entrada de usuario (por ejemplo, una unidad de entrada/salida). La pantalla puede estar configurada para presentar o mostrar informacion a un usuario, incluyendo ejemplos apropiados de dicha pantalla una pantalla de cristal llquido (LCD), una pantalla LED, una pantalla de plasma (PDP) o similar. Las interfaces de entrada de usuario pueden ser por cable o inalambricas, y pueden estar configuradas para recibir informacion que un usuario introduce en el aparato, por ejemplo para su procesamiento, almacenamiento y/o visualizacion. Ejemplos apropiados de interfaces de entrada de usuario incluyen un microfono, un dispositivo de captura de imagen o de video, un teclado o teclado numerico, una palanca de control, una superficie sensible al tacto (independiente de una pantalla tactil o integrada en ella), un sensor biometrico o similares. Las interfaces de usuario pueden ademas incluir una o mas interfaces para comunicacion con perifericos tales como impresoras, escaneres o similares.
Como se ha indicado anteriormente, instrucciones de codigo de programa pueden estar almacenadas en memoria, y pueden ser ejecutadas por un procesador, para implementar funciones de los sistemas, subsistemas y sus elementos respectivos descritos en este documento. Como se apreciara, desde un medio de almacenamiento informatico se puede cargar cualquier instruccion de codigo de programa en un ordenador u otro aparato programable para producir una maquina concreta, de tal manera que la maquina concreta se convierte en un medio para implementar las funciones especificadas en este documento. Estas instrucciones de codigo de programa tambien pueden estar almacenadas en un medio de almacenamiento informatico que puede controlar un ordenador, un procesador u otro aparato programable para que funcione de una manera concreta para, de ese modo, generar una maquina concreta o un artlculo de fabricacion concreto. Las instrucciones almacenadas en el medio de almacenamiento informatico pueden producir un artlculo de fabricacion, convirtiendose el artlculo de fabricacion en un medio para implementar las funciones descritas en este documento. Las instrucciones de codigo de programa pueden ser recuperadas de un medio de almacenamiento informatico y cargadas en un ordenador, procesador u otro aparato programable para configurar el ordenador, procesador u otro aparato programable para ejecutar operaciones que deben ser realizadas sobre o por el ordenador, procesador u otro aparato programable.
La recuperacion, carga y ejecucion de las instrucciones de codigo de programa se puede realizar secuencialmente de tal manera que una instruccion primero se recupere, luego se cargue y despues se ejecute en un instante. En algunas realizaciones de ejemplo, la recuperacion, carga y/o ejecucion se pueden realizar en paralelo de tal manera que se recuperen, se carguen y/o se ejecuten multiples instrucciones juntas. La ejecucion de las instrucciones de codigo de programa puede producir un proceso implementado por ordenador tal que las instrucciones ejecutadas por el ordenador, procesador u otro aparato programable proporcionen operaciones para implementar las funciones descritas en este documento.
La ejecucion de instrucciones por un procesador, o el almacenamiento de instrucciones en un medio de almacenamiento informatico, soporta combinaciones de operaciones para realizar las funciones especificadas. Se entendera tambien que una o mas funciones, y combinaciones de funciones, pueden ser implementadas mediante sistemas informaticos basados en hardware de proposito especial y/o procesadores que realizan las funciones especificadas, o combinaciones de hardware de proposito especial e instrucciones de codigo de programa.
A una persona con experiencia en la tecnica a la cual pertenece esta description se le ocurriran muchas modificaciones y otras realizaciones de la invention descrita en este documento que tengan el beneficio de las ensenanzas presentadas en las descripciones anteriores y en los dibujos asociados. Por lo tanto, se debe entender que la invencion no debe estar limitada a las realizaciones especlficas descritas y que se pretende que las modificaciones y otras realizaciones esten incluidas dentro del alcance de las reivindicaciones adjuntas. Ademas, aunque las descripciones anteriores y los dibujos asociados describen realizaciones de ejemplo en el contexto de ciertas combinaciones de ejemplo de elementos y/o de funciones, se deberla observar que realizaciones alternativas pueden proporcionar diferentes combinaciones de elementos y/o de funciones sin alejarse del alcance de las reivindicaciones adjuntas. A este respecto, por ejemplo, tambien se contemplan combinaciones de elementos y/o de funciones diferentes a los descritos anteriormente de forma expllcita, como pueden ser los que se describen en algunas de las reivindicaciones adjuntas. Aunque en este documento se emplean terminos especlficos, se utilizan solo en un sentido generico y descriptivo y no con fines limitativos.

Claims (15)

  1. 5
    10
    15
    20
    25
    30
    35
    40
    45
    50
    55
    60
    65
    REIVINDICACIONES
    1. Un sistema (100) para integrar datos (904) de fallo para diferentes presentaciones de analisis de fallos, comprendiendo el sistema:
    un validador (202) de datos configurado para recibir y validar datos (904) de analisis de fallos para un sistema complejo que incluye una pluralidad de sistemas (902), caracterizado por los siguientes rasgos:
    los datos (904) de analisis de fallos incluyen datos (904) de fallos y datos de diseno, identificando los datos (904) de fallos a uno o mas sistemas con fallos de la pluralidad de sistemas (902), y describiendo los datos de diseno al sistema complejo y a los posibles fallos de al menos algunos de sus sistemas (902), y
    el que el validador (202) de datos este configurado para validar los datos (904) de analisis de fallos incluye que este configurado para realizar una o mas comprobaciones de consistencia entre los datos (904) de fallos y los datos de diseno para integrar de ese modo los datos (904) de fallos para una pluralidad de diferentes presentaciones de analisis de fallos; y
    un motor (302) de presentaciones acoplado al validador (202) de datos y configurado para generar de manera selectiva uno cualquiera o mas de la pluralidad de diferentes presentaciones de los datos (904) de analisis de fallo, siendo compartidos al menos algunos de los datos (904) de analisis de fallos validados entre al menos algunos de los diferentes presentaciones.
  2. 2. El sistema de la reivindicacion 1, en el cual los sistemas con fallos incluyen un sistema con fallos directamente afectado por un fallo de origen, y cualquier sistema con fallos de orden inferior indirectamente afectado por el fallo de origen,
    en el cual los datos de diseno incluyen information de la interfaz logica que describe relaciones (906) logicas entre los sistemas del sistema complejo, y
    en el cual el que el validador (202) de datos este configurado para realizar una o mas comprobaciones de consistencia incluye que este configurado para realizar una o mas comprobaciones de consistencia de la interfaz logica utilizando datos (904) de fallos e informacion de interfaz logica, incluyendo la comprobacion de consistencia de la interfaz logica una comprobacion de que el sistema con fallos esta relacionado de manera logica (906) con los sistemas con fallos de orden inferior, o de que los sistemas relacionados de manera logica (906) con el sistema con fallos son los sistemas con fallos de orden inferior.
  3. 3. El sistema de cualquiera de las reivindicaciones 1 o 2, en el cual los datos (904) de fallo incluyen uno o mas mensajes (1010) de alerta generados en respuesta a fallos respectivos de los sistemas con fallos, y los datos de diseno incluyen una coleccion de mensajes (1010) de alerta asociados a diversos sistemas del sistema complejo, y en el cual el que el validador (202) de datos este configurado para realizar una o mas comprobaciones de consistencia incluye que este configurado para realizar una o mas comprobaciones de consistencia de las alertas utilizando los mensajes (1010) de alerta generados y la coleccion de mensajes (1010) de alerta, incluyendo la comprobacion de consistencia de las alertas una comprobacion de que los uno o mas mensajes (1010) de alerta generados para los sistemas con fallos se correlacionan con los mensajes (1010) de alerta asociados a los respectivos sistemas con fallos de la coleccion de mensajes (1010) de alerta.
  4. 4. El sistema de cualquiera de las reivindicaciones 1-3, en el cual los datos de diseno incluyen uno o mas diagramas (1004) esquematicos que describen relaciones flsicas entre el sistema complejo y sus sistemas (902), siendo el sistema complejo divisible en una pluralidad de zonas flsicamente diferenciadas, y
    en el cual el que el validador (202) de datos este configurado para realizar una o mas comprobaciones de consistencia incluye que este configurado para realizar una comprobacion de consistencia de la ubicacion utilizando los datos (904) de fallo y uno o mas diagramas (1004) esquematicos, incluyendo la comprobacion de consistencia de la ubicacion una comprobacion de que los sistemas con fallos estan situados flsicamente en la misma zona del sistema complejo.
  5. 5. El sistema de cualquiera de las reivindicaciones 1-4, en el cual los datos (904) de fallo incluyen niveles de riesgo para respectivos fallos de los sistemas con fallos, y los datos de diseno incluyen una coleccion de niveles de riesgo asociados a diversos sistemas (902) del sistema complejo, y
    en el cual el que el validador (202) de datos este configurado para realizar una o mas comprobaciones de consistencia incluye que este configurado para realizar una comprobacion de consistencia de la evaluation de riesgos utilizando los niveles de riesgo para respectivos fallos de los sistemas con fallos y la coleccion de mensajes (1010) de alerta, incluyendo la comprobacion de consistencia de la evaluacion de riesgos una comprobacion de que los niveles de riesgo para los respectivos fallos de los sistemas con fallos se correlacionan con niveles de riesgo asociados a los respectivos sistemas con fallos de la coleccion de niveles de riesgo.
  6. 6. El sistema de cualquiera de las reivindicaciones 1-5, en el cual los sistemas del sistema complejo incluyen uno o mas sistemas electricos, los sistemas con fallos incluyen uno o mas sistemas electricos con fallos, y los datos (904) de fallo identifican estados de potencia de los uno o mas sistemas electricos con fallos,
    5
    10
    15
    20
    25
    30
    35
    40
    45
    50
    55
    60
    65
    en el cual los datos de diseno incluyen datos de carga electrica que describen los estados de potencia de uno o mas sistemas electricos con fallos para diversos estados de funcionamiento del sistema complejo, y en el cual el que el validador (202) de datos este configurado para realizar una o mas comprobaciones de consistencia incluye que este configurado para realizar una comprobacion de consistencia de la carga electrica utilizando los datos (904) de fallo y datos de carga electrica, incluyendo la comprobacion de consistencia de la carga electrica una comprobacion de que los estados de potencia de los uno o mas sistemas electricos con fallos se correlacionan con los datos de carga electrica.
  7. 7. El sistema de cualquiera de las reivindicaciones 1-4, en el cual los datos (904) de fallo incluyen una lista de una o mas funciones a nivel de sistema complejo afectadas por los sistemas con fallos,
    en el cual los datos de diseno incluyen una lista de una o mas funciones a nivel de sistema complejo y de sistemas del sistema complejo que implementan las respectivas funciones, y
    en el cual el que el validador (202) de datos este configurado para realizar una o mas comprobaciones de consistencia incluye que este configurado para realizar una comprobacion de consistencia de los impactos funcionales incluyendo una comprobacion de que los datos (904) de fallo que incluyen a las funciones a nivel de sistema complejo afectadas por los sistemas con fallos se correlacionan con los datos de diseno que incluyen a las funciones a nivel de sistema complejo implementadas por los respectivos sistemas con fallos.
  8. 8. Un metodo de integracion de datos (904) de fallo para diferentes presentaciones de analisis de fallos, comprendiendo el metodo:
    recibir datos de analisis de fallos para un sistema complejo que incluye una pluralidad de sistemas (902), incluyendo los datos (904) de analisis de fallos datos (904) de fallos que identifican a uno o mas sistemas con fallos de la pluralidad de sistemas (902); caracterizado por los siguientes pasos:
    validar los datos de analisis de fallos para integrar de ese modo los datos (904) de fallos para una pluralidad de diferentes presentaciones (1004) de analisis de fallos; y
    generar de manera selectiva uno cualquiera o mas de la pluralidad de diferentes presentaciones (1004) de los datos de analisis de fallo, siendo compartidos al menos algunos de los datos (904) de analisis de fallos validados entre al menos algunos de los diferentes presentaciones (1004).
  9. 9. El metodo de la reivindicacion 8, en el cual los datos (904) de analisis de fallos incluyen ademas datos de diseno que describen al sistema complejo y a posibles fallos de al menos algunos de sus sistemas (902), y
    en el cual la validacion de los datos de analisis de fallos incluye la realizacion de una o mas comprobaciones de consistencia entre los datos (904) de fallo y los datos de diseno.
  10. 10. El metodo de la reivindicacion 9, en el cual los sistemas con fallos incluyen un sistema con fallos afectado directamente por un fallo de origen, y cualquier sistema con fallos de orden inferior afectado indirectamente por el fallo de origen,
    en el cual los datos de diseno incluyen informacion de la interfaz logica que describe relaciones (906) logicas entre los sistemas (902) del sistema complejo, y
    en el cual la realizacion de las una o mas comprobaciones de consistencia incluye la realizacion de una comprobacion de consistencia de la interfaz logica utilizando los datos (904) de fallo y la informacion de interfaz logica, incluyendo la comprobacion de consistencia de la interfaz logica una comprobacion de que el sistema con fallos esta relacionado de manera logica con los sistemas con fallos de orden inferior, o de que los sistemas (906) relacionados de manera logica con los sistemas con fallos son los sistemas con fallos de orden inferior.
  11. 11. El metodo de cualquiera de las reivindicaciones 9 o 10, en el cual los datos (904) de fallo incluyen uno o mas mensajes (1010) de alerta generados en respuesta a respectivos fallos de los sistemas con fallos, y los datos de diseno incluyen una coleccion de mensajes (1010) de alerta asociados a diversos sistemas (906) del sistema complejo, y
    en el cual la realizacion de las una o mas comprobaciones de consistencia incluye la realizacion de una comprobacion de consistencia de las alertas utilizando los mensajes (1010) de alerta generados y la coleccion de mensajes (1010) de alerta, incluyendo la comprobacion de consistencia de las alertas una comprobacion de que los uno o mas mensajes (1010) de alerta generados para el sistema con fallos se correlacionan con mensajes (1010) de alerta asociados a los respectivos sistemas con fallos de la coleccion de mensajes (1010) de alerta.
  12. 12. El metodo de cualquiera de las reivindicaciones 9-11, en el cual los datos de diseno incluyen uno o mas diagramas (1004) esquematicos que describen relaciones flsicas entre el sistema complejo y sus sistemas, siendo el sistema complejo divisible en una pluralidad de zonas flsicamente diferenciadas, y
    en el cual la realizacion de las una o mas comprobaciones de consistencia incluye la realizacion de una comprobacion de consistencia de la ubicacion utilizando los datos (904) de fallo y uno o mas diagramas esquematicos, incluyendo la comprobacion de consistencia de la ubicacion una comprobacion de que los sistemas con fallos estan situados flsicamente en la misma zona del sistema complejo.
    5
    10
    15
    20
    25
    30
  13. 13. El metodo de cualquiera de las reivindicaciones 9-10, en el cual los datos (904) de fallo incluyen niveles de riesgo para los respectivos fallos de los sistemas con fallos, y los datos de diseno incluyen una coleccion de niveles de riesgo asociados a diversos sistemas del sistema complejo, y
    en el cual la realizacion de las una o mas comprobaciones de consistencia incluye la realization de una comprobacion de consistencia de la evaluation de riesgos utilizando los niveles de riesgo para respectivos fallos de los sistemas con fallos y la coleccion de mensajes (1010) de alerta, incluyendo la comprobacion de consistencia de la evaluacion de riesgos una comprobacion de que los niveles de riesgo para los respectivos fallos de los sistemas con fallos se correlacionan con niveles de riesgo asociados a los respectivos sistemas con fallos de la coleccion de niveles de riesgo.
  14. 14. El metodo de cualquiera de las reivindicaciones 9-13, en el cual los sistemas (902) del sistema complejo incluyen uno o mas sistemas electricos, los sistemas con fallos incluyen uno o mas sistemas electricos con fallos, y los datos (904) de fallo identifican estados de potencia de los uno o mas sistemas electricos con fallos,
    en el cual los datos de diseno incluyen datos de carga electrica que describen los estados de potencia de uno o mas de los sistemas electricos con fallos para diversos estados de funcionamiento del sistema complejo, y en el cual la realizacion de las una o mas comprobaciones de consistencia incluye la realizacion de una comprobacion de consistencia de la carga electrica utilizando los datos (904) de fallo y datos de carga electrica, incluyendo la comprobacion de consistencia de la carga electrica una comprobacion de que los estados de potencia de los uno o mas sistemas electricos con fallos se correlacionan con los datos de carga electrica.
  15. 15. El metodo de cualquiera de las reivindicaciones 9-13, en el cual los datos (904) de fallo incluyen una lista de una o mas funciones a nivel de sistema complejo afectadas por los sistemas con fallos,
    en el cual los datos de diseno incluyen una lista de una o mas funciones a nivel de sistema complejo y sistemas del sistema complejo que implementan las respectivas funciones, y
    en el cual la realizacion de las una o mas comprobaciones de consistencia incluye la realizacion de una comprobacion de consistencia de los impactos funcionales incluyendo una comprobacion de que los datos (904) de fallo que incluyen a las funciones a nivel de sistema complejo afectadas por los sistemas con fallos se correlacionan con los datos de diseno que incluyen a las funciones a nivel de sistema complejo implementadas por los respectivos sistemas con fallos.
ES13166291.8T 2012-06-15 2013-05-02 Validación y visualización de análisis de fallos Active ES2561311T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201213524173 2012-06-15
US13/524,173 US10539955B2 (en) 2012-06-15 2012-06-15 Failure analysis validation and visualization

Publications (1)

Publication Number Publication Date
ES2561311T3 true ES2561311T3 (es) 2016-02-25

Family

ID=48446049

Family Applications (1)

Application Number Title Priority Date Filing Date
ES13166291.8T Active ES2561311T3 (es) 2012-06-15 2013-05-02 Validación y visualización de análisis de fallos

Country Status (8)

Country Link
US (1) US10539955B2 (es)
EP (1) EP2674826B1 (es)
JP (1) JP6272661B2 (es)
KR (1) KR102036381B1 (es)
CN (1) CN103514079B (es)
AU (1) AU2013205226B2 (es)
BR (1) BR102013013976B1 (es)
ES (1) ES2561311T3 (es)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015138327A1 (en) 2014-03-11 2015-09-17 Cessna Aircraft Company Touch screen instrument panel
US9672745B2 (en) 2014-03-11 2017-06-06 Textron Innovations Inc. Awareness enhancing display for aircraft
US9489597B2 (en) 2014-08-21 2016-11-08 The Boeing Company Visualization and analysis of a topical element of a complex system
US10191997B2 (en) 2014-08-21 2019-01-29 The Boeing Company Visualization and diagnostic analysis of interested elements of a complex system
CN106341248B (zh) * 2015-07-09 2020-04-07 阿里巴巴集团控股有限公司 一种基于云平台的故障处理方法和装置
CN105740465A (zh) * 2016-03-04 2016-07-06 浪潮软件集团有限公司 一种灵活的自定义比对方法
US20170372237A1 (en) * 2016-06-22 2017-12-28 General Electric Company System and method for producing models for asset management from requirements
CN108647428B (zh) * 2018-05-08 2020-07-28 南京航空航天大学 一种涡扇发动机自适应部件级仿真模型构建方法
US10776218B2 (en) * 2018-05-31 2020-09-15 EMC IP Holding Company LLC Availability-driven data recovery in cloud storage systems
CN109460478A (zh) * 2018-11-06 2019-03-12 北京京航计算通讯研究所 基于细粒度特征语义网络的系统接口时序知识分析方法
KR102407990B1 (ko) 2021-09-30 2022-06-13 한화시스템(주) 항공기 신규 개발을 위한 운용환경 데이터를 이용한 예방 정비 정보 제공 시스템 및 그 방법
CN115271129B (zh) * 2022-09-30 2023-01-13 北京国电通网络技术有限公司 应用于输电线路的故障维修方法、装置、设备和介质

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5161158A (en) * 1989-10-16 1992-11-03 The Boeing Company Failure analysis system
GB2275559B (en) 1989-11-02 1995-02-15 Combustion Eng Alarm console installation
US6208955B1 (en) * 1998-06-12 2001-03-27 Rockwell Science Center, Llc Distributed maintenance system based on causal networks
KR100302384B1 (ko) * 1999-07-01 2001-09-22 김오영 자동차 전기장치의 디지털 통합 제어장치 및 방법
US7403901B1 (en) * 2000-04-13 2008-07-22 Accenture Llp Error and load summary reporting in a health care solution environment
US8311697B2 (en) * 2004-07-27 2012-11-13 Honeywell International Inc. Impact assessment system and method for determining emergent criticality
US7702435B2 (en) * 2004-11-05 2010-04-20 Honeywell International Inc. Method and apparatus for system monitoring and maintenance
JP2006252422A (ja) 2005-03-14 2006-09-21 Kawasaki Heavy Ind Ltd 故障診断方法及び装置
US7770052B2 (en) 2006-05-18 2010-08-03 The Boeing Company Collaborative web-based airplane level failure effects analysis tool
FR2914764B1 (fr) 2007-04-06 2014-10-10 Airbus France Procede et dispositif de determination d'un diagnostic de panne d'une unite fonctionnelle dans un systeme avionique embarque
US7714702B2 (en) * 2007-06-04 2010-05-11 The Boeing Company Health monitoring system for preventing a hazardous condition
US8437904B2 (en) * 2007-06-12 2013-05-07 The Boeing Company Systems and methods for health monitoring of complex systems
US7681086B2 (en) * 2007-09-20 2010-03-16 Embraer- Empresa Brasileira De Aeronautica S.A. Fault tree map generation
CN101365212A (zh) 2008-10-10 2009-02-11 福建丰祥通信技术服务有限公司 室内覆盖维护管理系统
WO2011063269A1 (en) * 2009-11-20 2011-05-26 Alert Enterprise, Inc. Method and apparatus for risk visualization and remediation
US10019677B2 (en) * 2009-11-20 2018-07-10 Alert Enterprise, Inc. Active policy enforcement
US10027711B2 (en) * 2009-11-20 2018-07-17 Alert Enterprise, Inc. Situational intelligence
FR2966616B1 (fr) * 2010-10-22 2012-12-14 Airbus Procede, dispositif et programme d'ordinateur d'aide au diagnostic d'un systeme d'un aeronef, utilisant des graphes d'evenements redoutes

Also Published As

Publication number Publication date
BR102013013976A2 (pt) 2015-06-23
BR102013013976B1 (pt) 2021-07-13
JP2014002731A (ja) 2014-01-09
EP2674826A1 (en) 2013-12-18
CN103514079B (zh) 2018-01-12
KR102036381B1 (ko) 2019-10-24
AU2013205226B2 (en) 2017-12-07
KR20130141359A (ko) 2013-12-26
CN103514079A (zh) 2014-01-15
US20130339795A1 (en) 2013-12-19
AU2013205226A1 (en) 2014-01-16
US10539955B2 (en) 2020-01-21
EP2674826B1 (en) 2015-12-09
JP6272661B2 (ja) 2018-01-31

Similar Documents

Publication Publication Date Title
ES2561311T3 (es) Validación y visualización de análisis de fallos
EP2876519B1 (en) Safety analysis of a complex system using component-oriented fault trees
KR102357583B1 (ko) 고장의 누적 영향들을 평가하기 위한 시스템 및 방법
US7681086B2 (en) Fault tree map generation
US8788138B1 (en) Diagnostic methods and systems for an aircraft
US9087419B2 (en) Method and apparatus for remote e-Enabled aircraft solution management using an electronic flight bag (EFB)
JP2015507123A (ja) 内部車両エンジンを制御する装置及び方法
Silva et al. Divergence between flight crew mental model and aircraft system state in auto-throttle mode confusion accident and incident cases
CN104714450A (zh) 一种机械双余度电气三余度大气数据传感器余度管理算法
US20190155849A1 (en) Visualization and diagnostic analysis of interested elements of a complex system
KR102232876B1 (ko) 디지털 설비의 고장 유형 분석 시스템 및 방법
Bergstra et al. A promise theoretic account of the boeing 737 Max MCAS algorithm affair
Kim et al. Some empirical insights on diagnostic performance of the operating crew in a computer‐based advanced control room
CN106354930B (zh) 一种空间飞行器的自适应重构方法及系统
Martins et al. Human error in aviation: the behavior of pilots facing the modern technology
KR102589581B1 (ko) 선박 알람 관리 시스템
US11372839B2 (en) Anomalous event confirmation assistance apparatus, anomalous event confirmation assistance meithod, and recording medium
Wilkins Are Machines Better Than Humans in Crisis?
Wilkins Automated Procedures-A New Way of Improving Efficiency and Safety
JP2013156970A (ja) 制御図面表示装置