ES2328057T3 - Sistema de control tolerante a fallos. - Google Patents
Sistema de control tolerante a fallos. Download PDFInfo
- Publication number
- ES2328057T3 ES2328057T3 ES06114052T ES06114052T ES2328057T3 ES 2328057 T3 ES2328057 T3 ES 2328057T3 ES 06114052 T ES06114052 T ES 06114052T ES 06114052 T ES06114052 T ES 06114052T ES 2328057 T3 ES2328057 T3 ES 2328057T3
- Authority
- ES
- Spain
- Prior art keywords
- software
- program
- safeguard
- data processing
- mode
- 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
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/2097—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements maintaining the standby controller/processing unit updated
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operations
- G06F11/1479—Generic software techniques for error detection or fault masking
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/1629—Error detection by comparing the output of redundant processing systems
- G06F11/1641—Error detection by comparing the output of redundant processing systems where the comparison is not performed by the redundant processing components
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/18—Error detection or correction of the data by redundancy in hardware using passive fault-masking of the redundant circuits
- G06F11/183—Error detection or correction of the data by redundancy in hardware using passive fault-masking of the redundant circuits by voting, the voting not being performed by the redundant components
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Hardware Redundancy (AREA)
Abstract
Un sistema de procesamiento de datos tolerante a fallos para controlar un proceso en tiempo real, siendo dicho sistema tolerante a fallos sistemáticos producidos en su software, comprendiendo dicho sistema una pluralidad de unidades de procesamiento de datos (240 a 244) cada una con una memoria de programa (146) y una memoria de datos (144) y unas unidades de entrada y salida en las que un software de programa que reside en la memoria de programa (146) puede ser ejecutado en cada unidad de procesamiento de datos (240 a 244), en el que el sistema comprende un programa software de modo normal que reside en dicha cada memoria de programa (146) y un programa software de modo de salvaguarda que, así mismo, reside en cada dicha memoria de programa (146) dispuesto para llevar a cabo la misma o similar función del programa software de modo normal pero estando implementado de manera diferente que el programa software de modo normal, en el que cada unidad de procesamiento de datos (240 a 244) ejecuta el mismo software, y donde una señal de disparo recibida por cada unidad de procesamiento de datos (240 a 244) puede cambiar el control de ejecución, de tal manera que el programa software de modo normal deje de ejecutar y el programa software de modo de salvaguarda empiece a ejecutar, comprendiendo así mismo dicho sistema un sistema de activación de salvaguarda que comprende una pluralidad de unidades de activación (222 a 226) capaz de emitir una señal de error cuando se descubre un error, caracterizado porque cada unidad de activación está conectada a una unidad de votante común único (130), estando dicha unidad de votante común único (130) conectada a cada unidad de procesamiento de datos, y dispuesta para emitir dicha señal de disparo cuando una mayoría de las unidades de activación (222 a 226) emita una señal de error, y porque las unidades de activación de salvaguarda son implementadas en el software de modo normal.
Description
Sistema de control tolerante a fallos.
La presente invención se refiere al campo de los
sistemas de control tolerantes a fallos y a un procedimiento para
la activación de unas funciones de salvaguarda y, especialmente, a
unos sistemas y procedimientos de control en un vehículo de vuelo
en el que un sistema de salvaguarda es dividido para
detectar/gestionar los fallos generados por diferentes causas.
Las aeronaves de hoy día están provistas de una
pluralidad de sistemas de control, estos sistemas de control
requieren un sistema de salvaguarda independiente con el fin de
asegurar que ningún fallo aislado (fallos producidos de manera
sistemática o aleatoria) pueda provocar un fallo del sistema. El
sistema de salvaguarda tradicional a menudo intenta resolver dos
problemas al mismo tiempo, es decir, ocuparse ante de los fallos
sistemáticos, como de los fallos producidos de forma aleatoria, de
tal manera que el sistema pueda operar de manera independiente si
el fallo es un fallo generado de manera aleatoria o un fallo
generado de forma sistemática. Los fallos sistemáticos se
producirán siempre cuando se cumplan determinados criterios durante
la ejecución de un programa, por ejemplo durante la recepción de
determinados datos de entrada. Los cálculos tradicionales de
probabilidades de fallos y del MTBF (tiempo medio entre fallos) se
basan en la probabilidad de fallos generados de forma
aleatoria.
El documento de Murugesan S. "Software fiable
en la tolerancia a fallos" ["Dependable Software through fault
tolerance"] divulga los antecedentes técnicos generales de la
eliminación de errores y de la gestión de fallos en el software. El
documento Murugesan divulga la diversidad de diseños y la
programación de la versión N que se refiere a la ejecución de
diferentes variantes del programa para establecer un consenso sobre
una salida correcta.
El documento WO, A1, 02073505 se refiere a unos
sistemas de computación en tiempo real de recuperación después de
un episodio de perturbación aislado, esto es, un fallo de aparición
aleatoria. El sistema cambia entre dos programas cuando se produce
un error en la memoria de uno de los programas.
El documento de Hecht M. et al. "Una
arquitectura tolerante a fallos distribuida para un reactor nuclear
y otras aplicaciones críticas de control de procesos" ["A
distributed fault tolerant architecture for nuclear reactor and
other critical porcess control applications"] se refiere a un
sistema tolerante a fallos que comprende un nodo supervisor que
supervisa un nodo activo y un nodo en la sombra. El sistema cambia
de nodo cuando se produce un error en el sistema.
El documento "Estructura de sistema para
tolerancia a fallos por software" ["System structure for
software fault tolerance"] de Randell Brian, divulga un sistema
tolerante a fallos basado en bloques de recuperación a partir de un
caché. El sistema utiliza múltiples bloques de recuperación en los
que se evalúan diferentes alternativas cada vez que se ejecuta una
función. El sistema es un programa informático que de una forma
robusta estructura el programa para gestionar fallos pero el
programa no es fiable.
El principal problema de los sistemas de
salvaguarda de hoy en día es que incrementan el peso y el coste de
los sistemas de computación así como que reducen la disponibilidad
del sistema. El objetivo de la presente invención es resolver el
problema sin reducir la seguridad de los sistemas. Ninguno de los
documentos mencionados con anterioridad se refiere a dividir el
sistema de salvaguarda en dos partes de acuerdo con la presente
invención y a la reducción con ello de la cantidad de hardware en
el sistema de salvaguarda de hoy en día. Sin embargo, el documento
US 4,890,284 describe un sistema de ese tipo.
La presente invención resuelve el problema
expuesto con anterioridad mediante la provisión de unos sistemas de
acuerdo con la reivindicación 1 y de un procedimiento de acuerdo con
la reivindicación independiente 12.
Se proporciona un sistema que divide el sistema
de salvaguarda en dos partes en el que los fallos generados de
forma aleatoria son detectados y gestionados mediante la utilización
de un hardware más o menos idéntico al que se necesita ya con el
fin de garantizar la viabilidad de las funciones normales del
sistema de control y en el que el sistema de salvaguarda, un
programa de software, está enfocado a gestionar los fallos generados
de forma sistemática y de esta manera puede reducirse la cantidad
de hardware.
De acuerdo con un primer aspecto, la presente
invención proporciona un sistema de procesamiento de datos tolerante
a fallos para controlar un proceso en tiempo real, siendo dicho
sistema tolerante a fallos sistemáticos en su software y
comprendiendo unas unidades de procesamiento de datos con una
memoria de programa y una memoria de datos y unas unidades de
entrada y salida donde el software de programa que reside en la
memoria de programa puede ser ejecutado sobre las unidades de
procesamiento de datos. El sistema comprende un programa software
de modo normal que reside en dicha memoria de programa, y un
programa software de modo de salvaguarda que también reside en
dicha memoria de programa dispuesta para llevar a cabo la misma o
similar función del programa software de modo normal pero que es
implementado de modo diferente que el programa software de modo
normal, y donde una señal de disparo recibida por las unidades de
procesamiento de datos pueden conmutar el control de ejecución, de
manera que el programa software de modo normal cesa de ejecutar y el
programa software de modo de salvaguarda comienza a ejecutar.
El programa software de modo de salvaguarda
puede ser implementado de manera diferente que el programa software
de modo normal mediante la utilización de diferentes algoritmos,
diferentes leyes de control o similares.
El programa software de modo de salvaguarda
puede, así mismo, ser implementado de manera diferente que el
programa software de modo normal mediante la utilización de un
lenguaje de programa diferente, diferentes compiladores, diferentes
editores de enlace o similares.
El sistema puede comprender un sistema de
activación de la salvaguarda que comprende una pluralidad de
dispositivos de activación capaces de emitir una señal de error
cuando se descubre un error, estando cada dispositivo de activación
conectado a una unidad de votante, estando dicha unidad de votante
conectada a las unidades de procesamiento de datos y dispuesta para
emitir una señal de disparo cuando una mayoría de los dispositivos
de activación emite una señal de error.
Dicha conmutación del control de ejecución puede
ser implementada dejando que la señal de disparo accione una
Interrupción No Enmascarable (NMI) la cual a continuación transfiere
el control de ejecución al programa software de modo de
salvaguarda.
Dicha conmutación de control de ejecución puede
ser implementada mediante la activación de una subrutina de
Reinicialización y a continuación forzando el control de ejecución
hacia el programa software de modo de salvaguarda.
Dicho software de modo de salvaguarda puede
comprender unas instrucciones software para leer y actualizar los
datos del proceso procedentes de los medios de entrada antes de
llevar a cabo el control del proceso por medio de los medios de
salida.
Los datos del proceso pueden ser almacenados en
más de un lugar en la memoria de datos y ser protegidos contra
corrupciones no detectadas por una suma de control o un código de
corrección de errores. El sistema puede ser un sistema de control
de un vehículo.
De acuerdo con un segundo aspecto, la presente
invención se refiere a un procedimiento para activar un programa
software de modo de salvaguarda en un proceso en tiempo real de un
sistema que es tolerante a los fallos sistemáticos del software del
sistema, que comprende las etapas;
- -
- la detección de un fallo en dicho sistema que ejecuta un programa software de modo normal,
- -
- el disparo de una interrupción en la ejecución del software de modo normal
- -
- el cambio de ejecución, de manera que el programa software de modo normal cesa de ejecutarse y el programa software de modo de salvaguarda comienza a ejecutarse, en el que el programa software de modo de salvaguarda lleva a cabo la misma o similar función que el programa software de modo normal pero es implementado de manera diferente que el programa software de modo normal.
El procedimiento comprende así mismo una etapa
de:
- -
- la determinación de un votante si una señal de disparo debe ser enviada para interrumpir el proceso.
El procedimiento puede así mismo comprender la
etapa de:
- -
- la sincronización del programa software de modo de salvaguarda mediante la recuperación de parámetros y el almacenamiento de los parámetros en un almacenamiento seguro del sistema de control.
El procedimiento puede así mismo comprender,
después de que el sistema ha sido interrumpido, las etapas de:
- -
- la recuperación de los parámetros desde el almacenaje seguro; y
- -
- la verificación mediante sumas de control de que los parámetros son fiables.
El procedimiento puede ser un procedimiento para
activar un programa software de modo de salvaguarda en un proceso
en tiempo real de un sistema de control de un vehículo.
El sistema de procesamiento de datos en tiempo
real tolerante a fallos puede comprender una pluralidad de réplicas
de software y diferentes de unidades de procesamiento de datos que
ejecuten el mismo software.
\newpage
El sistema puede así mismo comprender un votante
de salida dispuesto para determinar una salida desde dichas
unidades de procesamiento de datos. La presente invención divulga
así mismo el sistema en el que el votante de salida puede estar
dispuesto para efectuar una elección de mayoría con el fin de
determinar la salida desde dichas unidades de procesamiento de
datos.
El sistema puede así mismo comprender un votante
dispuesto para determinar si una señal de disparo para activar
dicho cambio debe ser enviada a las unidades de procesamiento de
datos.
El sistema puede ser un sistema de control de un
vehículo.
La invención se describirá seguidamente con
mayor detalle con referencia a formas de realización preferentes y
con referencia a los dibujos adjuntos, de los cuales:
La Fig. 1a ilustra de forma esquemática una
primera forma de realización de un sistema de control del proceso
de acuerdo con la invención;
la Fig. 1b ilustra de forma esquemática la forma
en que dos conjuntos de instrucciones de software, correspondientes
a un programa de modo normal, y a un programa de modo de salvaguarda
están almacenados en la memoria del programa del sistema de la fig.
1a;
la Fig. 1c ilustra de forma esquemática un
sistema de control de una aeronave;
la Fig. 2 ilustra de forma esquemática un
dispositivo para la detección de fallos en un sistema de
control;
la Fig. 3 ilustra de forma esquemática la
activación de una función de salvaguarda de la presente
invención;
la Fig. 4 es un diagrama de bloques que ilustra
la activación de la función de salvaguarda que utiliza la presente
invención; y
la Fig. 5 es un diagrama de bloques que ilustra
de forma esquemática el proceso de desarrollo de un programa de
software.
Las definiciones que siguen serán utilizadas en
el presente documento con la finalidad de explicar la presente
invención.
- Un fallo producido de manera aleatoria es un fallo que se produce en un sistema debido a la ruptura de un componente o a que la aparición de un episodio se produce de manera aleatoria.
- Un fallo producido de manera sistemática es un fallo que se genera durante la construcción del sistema, como por ejemplo errores de programación. Los fallos sistemáticos se producirán siempre cuando se cumplan determinados criterios durante la ejecución de un programa, como por ejemplo la recepción de determinados datos de entrada.
- Una réplica distinta es una réplica que es similar en la funcionalidad de un hardware a lo que es una réplica, pero que es diferente, distinta, en la estructura del hardware.
- Un almacenamiento seguro es un almacenamiento de datos que no está afectado por un fallo producido de manera sistemática en un software del sistema.
- Implementado de manera diferente significa que un programa de software es diferente de otro programa de software en la cuestión del proceso de desarrollo del software. Esto significa que los diferentes programas de software difieren en algoritmos, la utilización de lenguajes de programación diferentes, compiladores, intérpretes, editores de enlace, diseño o similares.
- Una unidad de activación es una unidad capaz de detectar un error resultante de un fallo sistemático, lo cual da lugar a manifestaciones a partir de las cuales es posible extraer la conclusión de que se ha producido un error.
La Figura 1a muestra una ilustración esquemática
de una primera forma de realización preferente de un sistema de
control de proceso 110 de acuerdo con la invención. Una unidad de
procesamiento de datos 140 que incorpora una memoria de programa
146, una memoria de datos 144, una unidad de procesamiento central
(UPC) 142 y unos medios de entrada y salida están provistos de una
unidad de disparo 145 y la unidad de disparo 145 está conectada a
la UPC 142 a través de los medios de entrada/salida. En otra forma
de realización la unidad de disparo 145 está conectada directamente
a la UPC 142, la unidad de disparo 145 está conectada a un votante
130 para recibir una señal de activación de disparo desde dicho
votante 130. El votante 130 está conectado a tres pulsadores 122 a
126. Cuando un operador decide que se ha producido un fallo en el
sistema, pulsa los tres pulsadores 122 a 126, y una señal de
activación del votante es enviada desde cada pulsador hasta el
votante 130. Para evitar una activación accidental de un modo de
salvaguarda, el votante 130 está dispuesto para emitir una señal de
activación de disparo solo en el caso de que dos o más de los tres
pulsadores 122 a 126 sean presionados.
La unidad de disparo 145 está dispuesta para
transferir el control de ejecución a partir de las instrucciones
software de modo normal que residen en la memoria de programa de la
unidad de procesamiento de datos empezando en el emplazamiento de
memoria N (véase la figura 1b) hasta las instrucciones software de
modo de salvaguarda que residen en la memoria de programa de la
unidad de procesamiento de datos que comienzan en el emplazamiento
de memoria M.
La unidad de disparo 145 está conectada a la UPC
142 de manera que dicha unidad de disparo 145 activa una
Interrupción No Enmascarable, NMI. En una forma de realización
preferente de la invención, una Reinicialización es activada para
interrumpir el programa de software. Dicha interrupción fuerza a la
UPC 142 a ejecutar las instrucciones de modo de salvaguarda en
lugar de las instrucciones de modo normal. Las instrucciones de modo
de salvaguarda están dispuestas en el emplazamiento de memoria (M +
0), correspondientes a la NMI, como se muestra en la Fig. 1b. En
una forma de realización de la invención, una clavija de la UPC 142
es conectada a la NMI y la clavija es activada para energizar la
clavija con 5V alternativa 0 dependiendo de la forma en que la UPC
es implementada, esto es, la NMI es activada energizando o
desenergizando la clavija. Cuando la NMI es activada el procesador
es forzado a ir a una dirección predeterminada que contiene las
instrucciones del modo de salvaguarda, esto es, el programa
software de salvaguarda.
La diferencia entre la instrucción del modo
normal y las instrucciones del modo de salvaguarda en la primera
forma de realización es que las instrucciones del modo normal han
sido desarrolladas en un proceso con una pluralidad de objetivos de
diseño otorgando una alta prioridad a la elevada eficacia y
rendimiento y que utiliza un elevado nivel de lenguaje y un
determinado generador de instrucciones del lenguaje de bajo nivel a
la hora de programar. Las instrucciones del modo de salvaguarda han
sido desarrolladas en un proceso con una pluralidad de objetivos de
diseño que otorgan una alta prioridad a la sencillez y a la robustez
y que utilizan otro lenguaje de alto nivel y otro generador de
instrucciones de lenguaje de bajo nivel a la hora de programar. De
esta manera, un fallo o un gazapo en las instrucciones del modo
normal que provoque un error de ejecución bajo ciertas condiciones
no es probable que tengan un equivalente en las instrucciones del
modo de salvaguarda.
Así, el software del programa de salvaguarda
puede diferir en cuanto a los requisitos de software del programa
normal mediante la utilización de diferentes algoritmos y diferir en
la implementación del programa mediante la utilización de un diseño
de software diferente que se escribiría en un lenguaje de
programación diferente, utilizando diferentes compiladores,
utilizando leyes de control facilitadas o requisitos similares con
el fin de evitar incurrir en el mismo sistemático fallo del
programa.
Con referencia ahora a la Fig. 1c, se divulga
una ilustración esquemática de una segunda forma de realización de
la presente invención, un sistema de control de vuelo distribuido 1
de un vehículo de vuelo. El sistema de control 1 comprende una
pluralidad de elementos de control, por ejemplo unos instrumentos 2
de la cabina del piloto, una computadora de control de vuelo (FCC)
3, un nodo accionador 4, un motor 5, unos aerofrenos 6 y elementos
similares. Un nodo accionador 4 puede estar adaptado para controlar
las superficies de control de once superficies estabilizadoras o
similares del vehículo de vuelo. El sistema, así mismo, recibe las
lecturas procedentes de una pluralidad de sensores 7 a 9. Estos
sensores se utilizan para recoger datos, parámetros, para dotar al
sistema de control de vuelo de datos de entrada. Los sensores pueden
ser acelerómetros, giroscopios que miden la velocidad angular de
viraje, instrumentos que recogen datos del aire y similares. La FCC
3, en la forma de realización ilustrada, comprende unas leyes de
control, unas unidades de activación y un sistema de salvaguarda de
acuerdo con la presente invención, mientras que otros nodos del
sistema pueden no requerir sistemas de salvaguarda. Este puede ser
el caso cuando los nodos comprenden funciones más bien poco
complejas que pueden ser completamente comprobadas y analizadas, un
llamado nodo FAT, Completamente Analizable y Comprobable.
La presente invención está adaptada para ser
implementada en un sistema que lleve a cabo tareas, como por
ejemplo de navegación y guía; control de vuelo, control del empuje,
control de fuego, gestión de almacenamiento de armas y gestión de
misiones o similares.
En la Fig. 2 se muestra una panorámica de un
sistema de control de acuerdo con una tercera forma de realización
de la invención. En la forma de realización ilustrada, la activación
del programa software del modo de salvaguarda se decide en base a
una pluralidad de unidades de activación, en el que el sistema
comprende tres unidades de activación 222, 224, 226, unidades de
activación 222, 224, 226 que pueden ser implementadas en una
pluralidad de otros nodos del sistema, cada uno de estos nodos de
sistemas puede calcular algoritmos similares como el sistema de
control y comparar la salida del sistema de control con respecto a
su cálculo. Si la mayoría de los nodos del sistema detectan una
contradicción significativa entre el valor de salida del sistema de
control con respecto al valor calculado pueden activar el programa
software de modo de salvaguarda del sistema de control por medio de
un votante 230. Las unidades de activación pueden ser dispositivos
de supervisión que supervisen la FCC de la Fig. 1c. Una unidad de
activación está supervisando que se genera una salida desde un
proceso situado dentro de la FCC, otro es un sensor que está
supervisando un instrumento afectado por dicho proceso dentro de la
FCC y la tercera unidad de activación es un activador operado
manualmente que debe ser activado por el piloto cuando el piloto
detecta un error en la FCC. Debe, sin embargo, entenderse que las
unidades de activación pueden ser implementadas en un software de
modo normal.
El votante 230 decide, en la forma de
realización, mediante el empleo de una votación de mayoría acerca de
la detección de un fallo para disparar la activación del programa
software de modo de salvaguarda. Una unidad de disparo 245 está
dispuesta en un procesador, como por ejemplo una unidad de
procesamiento central, un microprocesador, o una FPGA 240 y es
activado cuando el votante 230 decide que la activación es deseable.
La unidad de disparo 245 ejecuta una Interrupción No Enmascarable,
NMI, o una rutina de Reinicialización con el fin de asegurar que el
sistema puede ser forzado hasta el modo de salvaguarda.
Debe entenderse que el sistema de hardware puede
y, de modo preferente, comprende una pluralidad de sistemas de
hardware que son réplicas distintas unas de otras, 240, 242 y 244 en
la fig. 2. Estos sistemas de hardware redundantes distintos son, en
sí mismos, suficientes para gestionar cualquier fallo aleatorio del
hardware. Sin embargo, aunque las diferentes réplicas pueden verse
afectadas por el mismo fallo introducido en los requisitos, el
diseño o la implementación del software, el modo de salvaguarda
proporcionará, no obstante, un medio para resolver ese
problema.
En una forma de realización (no mostrada), con
el fin de detectar un fallo, estos procesadores de réplicas 240 a
244 discurren en paralelo y un votante de salida o elemento similar
continuamente determina, mediante verificación, los valores
derivados de los diferentes procesadores 240, 242, 244. Cuando el
votante detecta una disparidad de los valores procedentes de los
procesadores, el votante selecciona el valor mediante una decisión
mayoritaria de los procesadores. Mediante la utilización de estas
réplicas, el sistema es tolerante a los fallos producidos de manera
aleatoria.
Con referencia a la Fig. 3, una sucesión
temporal se lleva a cabo a lo largo de la cual se efectúa un proceso
llamado de sincronización de salvaguarda. Dicha sincronización de
salvaguarda resulta preferente con el fin de contar con parámetros
del proceso (por ejemplo, parámetros de datos del vuelo)
actualizados y disponibles para el programa software del modo de
salvaguarda, cuando se efectúa un cambio a partir de la ejecución de
un programa software en el modo normal (una función ordinaria). Un
sistema de control está almacenando una pluralidad de parámetros y
actualizando los valores de los parámetros durante el proceso de
sincronización de salvaguarda. Con el fin de almacenar los
diferentes parámetros del sistema, lo que se divulga y se indica
genéricamente en la referencia numeral 50 en la Fig. 3a, el proceso
de sincronización de salvaguarda 52 es ejecutado en el que los
diferentes parámetros son determinados, recogidos y almacenados en
un almacenamiento de parámetros seguro, designado con la referencia
numeral 54. Debe entenderse que, incluso si el proceso de
sincronización de salvaguarda se ilustra discurriendo antes de que
sea ejecutada la función ordinaria, esta sincronización de
salvaguarda puede discurrir en segundo plano, simultáneamente junto
con la función ordinaria. En una forma de realización de la
invención, los parámetros son almacenados en diversos lugares en una
memoria y pueden o pueden no estar protegidos por una suma de
control. Después de que, o en el curso de lo expuesto con
anterioridad, el sistema de control ha sincronizado los parámetros y
almacenado los parámetros, el sistema de control ejecuta una
función ordinaria desarrollándola en un modo normal, como se muestra
en la referencia numeral 56. Sin embargo, en el caso de que se
produzca un fallo, esto es, un fallo producido de forma
sistemática, el sistema es forzado a pasar al modo de salvaguarda
60, tal y como se ilustra en la Fig. 3b. Como se expuso con
anterioridad, el sistema de control sincroniza en primer término
todos los parámetros 62 y almacena los mismos parámetros en un
almacenamiento seguro 64. El sistema a continuación discurre en un
modo normal 66 y, cuando se produce un fallo en el sistema, como
por ejemplo un error de programa sistemático, como en el bloque
indicado con la referencia numeral 68, el sistema inicia una NMI o
una Reinicialización. Esto implica que el programa de ejecución
normal se detiene y el sistema entonces cambia a un programa
software de modo de salvaguarda 70 que recupera los parámetros
previamente almacenados del sistema extrayéndolos del almacenaje de
seguridad del sistema 64, y el programa software de modo de
salvaguarda se ejecuta utilizando los parámetros recuperados, con
tal de que cualquier suma de control utilizada no indique la
corrupción del parámetro, en el que el programa software del modo
de salvaguarda utiliza un conjunto de parámetros por defecto. Este
programa software del modo de salvaguarda a continuación discurre
hasta que el modo de salvaguarda es reinicializado, desactivado o
adopta otros modos similares.
Con referencia a la Fig. 4, se describe un
procedimiento de activación del programa software del modo de
salvaguarda con el fin de clarificar la presente invención. En la
etapa 80 se detecta un fallo. Esta detección puede llevarse a cabo
mediante diferentes sistemas, diferentes partes de un sistema de
control, maniobras del piloto o sistemas similares. A modo de
ejemplo, con el fin de que un votante de un sistema active el modo
de salvaguarda, esto es, el programa de software separado, el
votante debe recibir dos señales procedentes de una cabina de piloto
de una aeronave de que se ha producido un fallo de un sistema de
control de una aeronave. En la cabina del piloto, un piloto, en el
ejemplo, tiene tres botones, debiendo el piloto apretar al menos dos
de estos tres botones con el fin de activar el sistema de
salvaguarda situado en el procesador, el cual evita que el modo de
salvaguarda sea disparado de forma accidental. En la presente
memoria, el votante puede estar situado en la cabina del piloto
donde el procesador con el programa software de salvaguarda puede
estar situado en un emplazamiento diferente. En otro ejemplo, dos
unidades de activación son utilizadas de forma que una primera
unidad es un sensor que está dispuesto sobre la superficie
estabilizadora del ala para detectar un fallo y una segunda unidad
es una unidad de fallos de sistema de control de la superficie
estabilizadora para detectar también un fallo. Un votante recibe
unas indicaciones de fallo procedentes del sensor así como del
detector de fallos y el votante determina que el fallo sistemático
se ha producido y envía un comando de disparo al procesador que
controla la superficie estabilizadora.
Cuando se detecta un fallo el sistema es
interrumpido mediante la implementación de una función de
reinicialización, una NMI o función similar, véase la etapa 82. De
esta forma, si el sistema está discurriendo en un bucle erróneo o
está siendo ejecutado de otra forma, esta operación defectuosa se
interrumpe. En el ejemplo expuesto de la superficie estabilizadora
el votante envía el comando de disparo al procesador del sistema de
control de la superficie estabilizadora y el procesador ejecuta una
reinicialización del programa de software de ejecución de modo
normal. El sistema de control de la superficie estabilizadora es
entonces forzado hasta adoptar un modo de salvaguarda. Esto se
divulga en la Fig. 4 como etapa 84. El modo de salvaguarda
mencionado es un programa de software que se ejecuta separado del
programa software normal existente en el procesador, con el fin de
evitar que se vea afectado por un fallo sistemático. Mediante la
disposición del sistema de salvaguarda para fallos generados por un
error sistemático como una parte del software del sistema de
control, el peso y el costo del sistema de control puede ser
reducido. El programa software de salvaguarda difiere del programa
software de modo normal con el fin de que no resulte afectado por el
mismo error sistemático. Con referencia a la Fig. 5, en ella se
muestra un diagrama de bloques esquemático de un proceso de
desarrollo software. Para crear un programa software, el proceso de
desarrollo de dicho programa comprende una primera etapa en la que
se establecen unos requisitos del programa software, una etapa 90 de
establecimiento de requisitos, que genera, por ejemplo,
determinados algoritmos y similares. A continuación el proceso
continúa hasta una etapa de diseño 92, en la que el programa se
diseña y, después de esa etapa, el programa se crea, esto es, se
programa utilizando un lenguaje de alto nivel, dentro de una etapa
de programación 94, y para posibilitar que el programa ejecute el
lenguaje que está compilado/interpretado utilizando un compilador,
en una etapa de compilación 96. El programa software de salvaguarda
puede diferir del programa software normal en el sentido de que
puede estar escrito en un lenguaje de programa diferente,
utilizando algoritmos diferentes, utilizando compiladores
diferentes, utilizando leyes de control facilitadas o similares con
el fin de evitar que se incurra en el mismo fallo sistemático del
programa, esto es, puede diferir en las etapas del proceso
divulgadas en la Fig. 5. El programa software del modo de
salvaguarda puede comprender las funciones más básicas con el fin de
llevar el avión hasta un punto de aterrizaje o puede comprender
todos/casi todos los rasgos característicos del software de
programa normal.
Para alcanzar el principal objetivo de la
invención el sistema está adaptado para inhabilitar un programa
software de modo normal erróneo y, en su lugar, llevar a cabo un
programa software de modo de salvaguarda que probablemente no
contiene el mismo fallo generado de manera sistemática. Si dicho
programa software de modo de salvaguarda es diseñado e implementado
de forma adecuada, este modo de salvaguarda puede gestionar todos
los fallos generados de manera sistemática provocados por fallos en
la programación del software, por ejemplo, leyes de control, y/o
implementación del hardware, como por ejemplo un diseño, un código
de fuente, una lógica o un código ejecutable erróneos.
La decisión para activar y ejecutar un programa
software de modo de salvaguarda debe, por razones de seguridad,
adoptarse por una unidad que no pueda resultar influenciada por el
mismo problema sistemático que puede provocar un fallo en un modo
normal. Esto implica que el software de detección en algunos casos
puede ser implementado en el modo normal, pero que es probablemente
más fácil, desde el punto de vista de la verificación, implementar
el software de detección en un sistema diferente. Una forma ejemplar
de la unidad de detección que es implementada en un sistema
diferente consiste en implementarlo en una función activada por un
piloto que active la función de salvaguarda o que diversos sistemas
examinen/supervisen y determinen si la función de salvaguarda debe
ser activada o una combinación de ambas. Los sistemas pueden
determinar la activación del programa software de modo de
salvaguarda mediante la implementación de una elección mayoritaria,
esto es, activarse cuando una mayoría de sistemas determine que se
ha producido un fallo. Sin embargo, debe entenderse que algunos
fallos deben inmediatamente producir una activación del programa
software de modo de salvaguarda.
Una activación segura puede ser implementada en
un sistema de software mediante la activación de la reinicialización
y, a continuación, del ajuste del software en un modo de
salvaguarda o mediante una NMI la cual, por definición, no puede
ser ignorada por un procesador. Ambas soluciones implican que,
incluso si el software ha finalizado en un bucle sin fin, la
función de salvaguarda se activará e implementará de una forma
estable y segura.
En una forma de realización del sistema, será
necesario mantener la función de salvaguarda actualizada con los
parámetros del sistema, como por ejemplo la altitud, la velocidad,
la posición, el modo servo o similares, con el fin de operar
adecuadamente. En un sistema de software, estos parámetros pueden
ser actualizados mediante un ciclo de activación y ser almacenados
de forma segura para que funcionen normalmente cuando el sistema
esté siendo ejecutado en un modo normal y experimente un fallo que
no pueda ocasionar daños a las funciones de salvaguarda.
El almacenamiento seguro puede ser implementado
utilizando un hardware o almacenando datos en una parte diferente
de la memoria. En una forma de realización adicional de la invención
la función de salvaguarda determina que los datos son fiables
mediante la utilización de sumas de control u otro tipo de códigos
de corrección o de detección de errores.
Claims (16)
1. Un sistema de procesamiento de datos
tolerante a fallos para controlar un proceso en tiempo real, siendo
dicho sistema tolerante a fallos sistemáticos producidos en su
software, comprendiendo dicho sistema una pluralidad de unidades de
procesamiento de datos (240 a 244) cada una con una memoria de
programa (146) y una memoria de datos (144) y unas unidades de
entrada y salida en las que un software de programa que reside en la
memoria de programa (146) puede ser ejecutado en cada unidad de
procesamiento de datos (240 a 244), en el que el sistema comprende
un programa software de modo normal que reside en dicha cada memoria
de programa (146) y un programa software de modo de salvaguarda
que, así mismo, reside en cada dicha memoria de programa (146)
dispuesto para llevar a cabo la misma o similar función del
programa software de modo normal pero estando implementado de
manera diferente que el programa software de modo normal, en el que
cada unidad de procesamiento de datos (240 a 244) ejecuta el mismo
software, y donde una señal de disparo recibida por cada unidad de
procesamiento de datos (240 a 244) puede cambiar el control de
ejecución, de tal manera que el programa software de modo normal
deje de ejecutar y el programa software de modo de salvaguarda
empiece a ejecutar, comprendiendo así mismo dicho sistema un
sistema de activación de salvaguarda que comprende una pluralidad de
unidades de activación (222 a 226) capaz de emitir una señal de
error cuando se descubre un error, caracterizado porque cada
unidad de activación está conectada a una unidad de votante común
único (130), estando dicha unidad de votante común único (130)
conectada a cada unidad de procesamiento de datos, y dispuesta para
emitir dicha señal de disparo cuando una mayoría de las unidades de
activación (222 a 226) emita una señal de error, y porque las
unidades de activación de salvaguarda son implementadas en el
software de modo normal.
2. El sistema de acuerdo con la reivindicación
1, en el que dichas unidades de procesamiento de datos son réplicas
de hardware distintas.
3. El sistema de acuerdo con las
reivindicaciones 1 o 2, que comprende así mismo un votante de
salida dispuesto para determinar una salida desde dichas unidades
de procesamiento de datos (240 a 244).
4. El sistema de acuerdo con la reivindicación
3, en el que el votante de salida está dispuesto para utilizar una
elección de mayoría con el fin de determinar la salida desde dichas
unidades de procesamiento de datos (240 a 244).
5. El sistema de acuerdo con cualquiera de las
reivindicaciones 1 a 4, en el que el programa software de modo de
salvaguarda es implementado de manera diferente que el programa
software de modo normal mediante la utilización de algoritmos
diferentes y/o leyes de control diferentes.
6. El sistema de acuerdo con cualquiera de las
reivindicaciones 1 a 4, en el que el programa software de modo de
salvaguarda es implementado de manera diferente que el programa
software de modo normal mediante la utilización de un diseño de
software diferente y/o un lenguaje de programación y/o unos
compiladores diferentes y/o unos editores de enlace diferentes.
7. El sistema de acuerdo con cualquiera de las
reivindicaciones 1 a 6, en el que dicho cambio de control de
ejecución es implementado dejando que la señal de disparo dispare
una Interrupción No Enmascarable (NMI) la cual a continuación
transfiere el control de ejecución al programa software de modo de
salvaguarda.
8. El sistema de acuerdo con cualquiera de las
reivindicaciones 1 a 6 en el que dicho cambio de control de
ejecución es implementado mediante la activación de una subrutina
de Reinicialización y a continuación reforzando el control de
ejecución hasta el programa software de modo de salvaguarda.
9. El sistema de acuerdo con cualquiera de las
reivindicaciones 1 a 8, en el que dicho software de modo de
salvaguarda comprende unas instrucciones de software para leer y
actualizar los datos del proceso desde la unidad de entrada antes
de llevar a cabo el control del proceso por medio de la unidad de
salida.
10. El sistema de acuerdo con cualquiera de las
reivindicaciones 1 a 9, en el que los datos del proceso son
almacenados en más de un lugar de la memoria de datos y son
protegidos contra una corrupción no detectada por una suma de
control o un código de corrección de error.
11. El sistema de acuerdo con cualquiera de las
reivindicaciones 1 a 10, en el que dicho sistema es un sistema de
control de un vehículo.
12. Un procedimiento para activar un programa
software de modo de salvaguarda en un proceso en tiempo real de un
sistema que es tolerante a fallos sistemáticos en el software de un
sistema de acuerdo con las reivindicaciones 1 a 11 que comprende
las etapas siguientes;
- -
- la detección de un fallo, por un software de detección en dicho sistema que ejecuta un programa de modo normal
- -
- la determinación mediante un votante común único (130) de si una señal de disparo debe ser enviada para interrumpir el proceso
- -
- el disparo de una interrupción del software de modo normal de ejecución
- -
- el cambio de la ejecución de manera que el programa software de modo normal deje de ejecutar y el programa software de modo de salvaguarda empiece a ejecutar, de manera que el programa software de modo de salvaguarda lleve a cabo la misma o similar función que el programa software de modo normal pero sea implementado de manera diferente que el programa software de modo normal.
13. El procedimiento para activar un programa
software de modo de salvaguarda de acuerdo con la reivindicación
12, en el que el procedimiento comprende la etapa de:
- -
- la sincronización de los parámetros del proceso mediante la ejecución de dicho sistema de programa de modo normal y el almacenamiento de dichos parámetros en un almacenamiento seguro de dicho sistema.
14. El procedimiento para activar un programa
software de modo de salvaguarda de acuerdo la reivindicación 13, en
el que el procedimiento comprende así mismo, después de que el
sistema ha sido interrumpido, las etapas de:
- -
- la recuperación de dichos parámetros extrayéndolos del almacenamiento de seguridad mediante dicho sistema que ejecuta un programa de modo de salvaguarda; y
- -
- la verificación de las sumas de control de que dichos parámetros son fiables.
15. El procedimiento para la activación de una
función de salvaguarda de acuerdo con cualquiera de las
reivindicaciones 12 a 14, en el que el sistema es un sistema de
control de un vehículo.
16. Un producto de programa informático que
puede ser cargado en una unidad de procesamiento de datos con
destino a un sistema de procesamiento de datos en tiempo real de
acuerdo con las reivindicaciones 1 a 11, siendo capaz dicho
producto, cuando es ejecutado en dicha unidad de procesamiento de
datos capaz, de realizar el procedimiento de la reivindicación
12.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP06114052A EP1857934B1 (en) | 2006-05-16 | 2006-05-16 | Fault tolerant control system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2328057T3 true ES2328057T3 (es) | 2009-11-06 |
Family
ID=37307290
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES06114052T Active ES2328057T3 (es) | 2006-05-16 | 2006-05-16 | Sistema de control tolerante a fallos. |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US7840832B2 (es) |
| EP (1) | EP1857934B1 (es) |
| DE (1) | DE602006007825D1 (es) |
| ES (1) | ES2328057T3 (es) |
Families Citing this family (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| ES2420110T3 (es) * | 2007-01-08 | 2013-08-22 | Saab Ab | Un procedimiento, un sistema eléctrico, un módulo de control digital y un módulo de control de activador en un vehículo |
| CN102622279B (zh) * | 2012-03-16 | 2015-08-19 | 华为技术有限公司 | 冗余控制系统、方法及管理控制器 |
| US9197934B2 (en) * | 2012-05-17 | 2015-11-24 | Stmicroelectronics, Inc. | Fault tolerant system with equivalence processing driving fault detection and backup activation |
| EP2813949B1 (en) * | 2013-06-11 | 2019-08-07 | ABB Schweiz AG | Multicore processor fault detection for safety critical software applications |
| CN105573876A (zh) * | 2015-12-10 | 2016-05-11 | 中国航空工业集团公司西安航空计算技术研究所 | 一种确定性通信的分布式容错飞控计算机的中间件系统 |
| WO2018052435A1 (en) * | 2016-09-16 | 2018-03-22 | Siemens Aktiengesellschaft | Cyberattack-resilient control system design |
| US10387139B2 (en) | 2017-07-25 | 2019-08-20 | Aurora Labs Ltd. | Opportunistic software updates during select operational modes |
| FR3072475B1 (fr) * | 2017-10-17 | 2019-11-01 | Thales | Procede de traitement d'une erreur lors de l'execution d'une procedure avionique predeterminee, programme d'ordinateur et systeme de detection et d'alerte associe |
| US10795668B2 (en) * | 2017-12-20 | 2020-10-06 | Hamilton Sundstrand Corporation | Software version synchronization for avionics systems |
| CN112084049B (zh) * | 2019-06-14 | 2024-07-26 | 佛山市顺德区顺达电脑厂有限公司 | 用于监控基板管理控制器的常驻程序的方法 |
| CN113608957B (zh) * | 2021-07-02 | 2023-07-18 | 南瑞集团有限公司 | 一种水电站控制软件故障在线监测方法及系统 |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4141066A (en) * | 1977-09-13 | 1979-02-20 | Honeywell Inc. | Process control system with backup process controller |
| EP0096510B1 (en) * | 1982-06-03 | 1988-07-27 | LUCAS INDUSTRIES public limited company | Control system primarily responsive to signals from digital computers |
| US4890284A (en) * | 1988-02-22 | 1989-12-26 | United Technologies Corporation | Backup control system (BUCS) |
| JP2755437B2 (ja) * | 1989-07-20 | 1998-05-20 | 富士通株式会社 | 通信制御プログラムの連続運転保証処理方法 |
| US5617425A (en) * | 1993-05-26 | 1997-04-01 | Seagate Technology, Inc. | Disc array having array supporting controllers and interface |
| US6154850A (en) * | 1993-11-01 | 2000-11-28 | Beaufort River, Inc. | Data storage system and method |
| JP2004528637A (ja) | 2001-03-12 | 2004-09-16 | ハネウェル・インターナショナル・インコーポレーテッド | 放射線イベント後にフライト・クリティカル・コンピュータを回復する方法 |
-
2006
- 2006-05-16 DE DE602006007825T patent/DE602006007825D1/de active Active
- 2006-05-16 ES ES06114052T patent/ES2328057T3/es active Active
- 2006-05-16 EP EP06114052A patent/EP1857934B1/en active Active
-
2007
- 2007-05-16 US US11/798,719 patent/US7840832B2/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| DE602006007825D1 (de) | 2009-08-27 |
| US7840832B2 (en) | 2010-11-23 |
| US20080072099A1 (en) | 2008-03-20 |
| EP1857934B1 (en) | 2009-07-15 |
| EP1857934A1 (en) | 2007-11-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7840832B2 (en) | Fault tolerant control system | |
| US20190316908A1 (en) | Master control system for satellite image processing | |
| US20060200278A1 (en) | Generic software fault mitigation | |
| US20020046365A1 (en) | Self-testing and -repairing fault-tolerance infrastructure for computer systems | |
| US9540117B2 (en) | Failure analysis system | |
| US20130268798A1 (en) | Microprocessor System Having Fault-Tolerant Architecture | |
| EP0263055A2 (en) | Autoequalization in redundant channels | |
| ES2835575T3 (es) | Una unidad de monitorización, así como un método para predecir el funcionamiento anormal de sistemas de ordenador activados por tiempo | |
| Iturbe et al. | Addressing functional safety challenges in autonomous vehicles with the arm TCL S architecture | |
| KR20020063237A (ko) | 중요시스템의 고장안전처리실행, 모니터링 및 출력제어를위한 시스템 및 방법 | |
| US11538346B2 (en) | Flight management assembly of an aircraft, of a transport aircraft in particular, and to a method of monitoring such a flight management assembly | |
| JP4643977B2 (ja) | プログラマブル・ロジック・デバイス、情報処理装置、プログラマブル・ロジック・デバイスの制御方法 | |
| BR102016004145B1 (pt) | Aparelho, e, método para controlar um atuador | |
| US8374734B2 (en) | Method of controlling an aircraft, the method implementing a vote system | |
| US10546504B2 (en) | Secure sequencing of aircraft flight plan | |
| US12523181B2 (en) | Device for blocking the shut-off of a propulsion engine for aircraft | |
| Li et al. | Software Availability Protection in {Cyber-Physical} Systems | |
| CN110673975A (zh) | 一种星载计算机软件的安全内核结构及安全运行方法 | |
| Pignol | How to cope with SEU/SET at system level? | |
| JP6011687B1 (ja) | 記憶装置およびその制御方法 | |
| JP7278478B2 (ja) | 情報処理装置及び情報処理方法 | |
| JP6907976B2 (ja) | コントローラ及びデータ保存方法 | |
| Venu et al. | A fail-functional automotive CPU subsystem architecture for mitigating single point of failures | |
| Duarte et al. | A fault-tolerant attitude determination system based on COTS devices | |
| Avizienis et al. | Means for dependability |