Fiabilidad y tolerancia a fallos

Los requisitos de fiabilidad y seguridad de los sistemas de tiempo real y embebido habitualmente
son mucho ms estrictos que los de otros sistemas informticos. En los tiempos actuales, cada vez
ms funciones de control antes realizadas por operadores humanos o mediante probados
mtodos analgico, estn siendo administradas por computadores digitales. En 1955, slo el 10
por ciento de los sistemas de armamento de EEUU necesitaba programas de computador. Al
principio de la dcada de 1980, este nmero creci hasta el 80 por ciento (Leveson, 1986)

En los primeros aos de la dcada de 1970, el programa responsable de controlar los globos
meteorolgicos de gran altura de un satlite meteorolgico francs emiti una solicitud de
autodestruccin de emergencia en lugar de una peticin de lectura de datos. El resultado fue
la destruccin de 72 de los 141 globos (Leveson, 1986). Muchos otros ejemplos como ste han
sido documentados, y es razonable pencar que muchos ms no lo fueron. En 1986. Hecht y Hecht
(1986b) estudiaron programas grandes, y concluyeron que, normalmente, por cada milln de
lneas de cdigo se introducan 20.000 imperfecciones en el software. Normalmente, el 90 por
ciento de sta& se encontraban mediante pruebas. Durante el primer ao de funcionamiento,
podan salir a la luz unos 200 defectos, mientras que otros 1.800 permanecan sin detectar. Las
rutinas de mantenimiento normalmente solan arreglar unos 200 agujeros, dejando otros 200
nuevos.

A medida que la sociedad siga confiando el control de sus funciones vitales a los computadores,
ms necesario ser que estos sistemas no fallen. Sin pretender definir de forma precisa qu
significa un fallo de un sistema o un defecto, existen, en general, cuatro causas de efectos que
pueden proporcionar el fallo de un sistema embebido.

1. Especificacin inadecuada. Se ha sugerido que la gran mayora de los defectos parten de

una especificacin inadecuada (Leveson, 1986).
2. Defectos provocados por errores de diseo en los componentes de software.
3. Defectos provocados por fallos en uno o ms componentes del procesador de los sistemas
embebidos.
4. Defectos provocados por una interferencia transitoria o permanente en el subsistema de
comunicaciones subyacente.

Estos tres ltimos tipos de defectos son los que plagan los lenguajes de programacin utilizados en
la implementacin de los sistemas embebidos. Los errores introducidos por defectos de diseo
son, en general, no previstos (en cuanto a sus consecuencias), mientras que los debidos a fallos en
el procesador o en la red son, de alguna manera, predecibles. Uno de los principales requisitos,
por lo tanto, para cualquier lenguaje de programacin de tiempo real es que debe facilitar la
construccin de sistemas altamente fiables.

Fiabilidad, fallos y defectos

Antes de proseguir, se hacen necesarias definiciones ms precisas de fiabilidad, fallo y defecto.
Randell et al. (1978) define la fiabilidad de un sistema como una medida del xito con el que el
sistema se ajusta a alguna especificacin definitiva de su comportamiento.
Los son el resultado de problemas internos no esperados que el sistema manifiesta eventualmente
en su comportamiento externo. Estos problemas se llaman errores, y sus causas mecnicas o
algortmicas se denominan defectos. Un componente defectuoso de un sistema es, por lo tanto,
un componente que producir un error bajo un conjunto concreto de circunstancias durante la
vida del sistema. Visto en trminos de transicin de estados un sistema puede ser considerado
como un nmero de estados externos e internos.

Se pueden distinguir tres tipos de fallos.

1. Fallos transitorios Un fallo transitorio comienza en un instante de tiempo concreto, se
mantiene en el sistema durante algn periodo, y luego desaparece. Ejemplos de este tipo
de fallos se dan en componentes hardware en los que se produce una reaccin adversa a
una interferencia externa, como la producida por un campo elctrico o por radiactividad.
Despus de que la perturbacin desaparece, lo hace tambin el fallo (aunque no
necesariamente el error inducido). Muchos de los fallos de los sistemas de comunicacin
son transitorios.
2. Fallos permanentes Los fallos permanentes comienzan en un instante determinado y
permanecen en el sistema hasta que son reparados; es el caso, por ejemplo, de un cable
roto o de un error de diseo del software.
3. Fallos intermitentes Son fallos transitorios que ocurren de vez en cuando. Un ejemplo es
un componente hardware sensible al calor, que funciona durante un rato, deja de
funcionar, se enfra, y entonces comienza a funcionar de nuevo.

Modos de fallo
Un sistema proporciona servicios. Resulta posible, por lo tanto, clasificar los modos de fallo de un
sistema de acuerdo con el impacto que tendrn en los servicios que se proporciona. Se pueden
identificar dos dominios generales de modos de fallo:

Fallos de valor: el valor asociado con el servicio es errneo.

Fallos de tiempo: el servicio se completa a destiempo

Las combinaciones de fallos de valor y de tiempo normalmente se denominan fallos arbitrarios.

En general, un error de valor podra estar an dentro del rango correcto de valores, o podra
encontrarse fuera del rango esperado para ese servicio. Esto ltimo equivale a un error de
escritura en los lenguajes de programacin, y se denomina error de lmites. Normalmente, estos
tipos de fallos se reconocen fcilmente.
Los fallos en el dominio del tiempo pueden hacer que el servicio sea entregado:

Demasiado pronto: el servicio es entregado antes de lo requerido.

Demasiada tarde: el servicio se entrega despus de lo requerido (en estos casos se suele
hablar de erro de prestaciones).
Indefinidamente tarde: el servicio nunca es entregado (en estos casos se suele hablar de
un fallo de omisin).

Existe un fallo ms, que se produce cuando un servicio es entregado sin ser esperado. A este tipo
de fallo habitualmente se le denomina fallo de encargo o improvisacin.

Por supuesto que, a menudo, resulta difcil distinguir entre final lo en el dominio del valor y del
tiempo de un fallo de encargo seguido de un fallo de omisin.

Fallo descontrolado: un sistema que produce errores arbitrarios, tanto en el domino del
valor como en el del tiempo incluyendo errores de improvisacin).
Fallo de retraso: un sistema que produce servicios correctos en el dominio del valor; pero
que sufre errores de retraso en el tiempo.
Fallo de silencio: un sistema que produce servicios correctos tanto en el dominio del valor
como en el del tiempo, hasta que falla. El nico fallo posible es un fallo de omisin, y
cuando ocurren todos los servicios siguientes tambin sufrirn fallos de omisin.
Fallo de parada: un sistema que tiene todas las propiedades de un fallo silencioso, pero
que permite que otros sistemas puedan detectar que ha entrado en el estado de fallo de
silencio.
Fallo controlado: un sistema que falla de una forma especificada y controlada
Sin fallos: un sistema que siempre produce los servicio\ correcto\, tanto en el dominio dcl
valor con en el del tiempo.

Prevencin de fallos y tolerancia a fallos

Se pueden considerar dos formas diferentes de ayudar a los diseadores a mejorar la fiabilidad de
sus sistemas (Anderson y Lee, 1990)

La primera es conocida como prevencin de fallos, y se refiere al intento de impedir que

cualquier posibilidad de fallo se cuele en el sistema antes de que est operativo.
La segunda se denomina tolerancia a fallos, y hace posible que el sistema contine
funcionando incluso ante la presencia de fallos.
Prevencin de fallos
Evitacin y eliminacin.

Con la evitacin se intenta limitar la introduccin de componentes potencialmente defectuosos

durante la construccin del sistema. En lo que respecta a1 hardware, esto puede implicar:

La utilizacin de los componentes mis fiables dentro de las restricciones de coste y

prestaciones dadas.
La utilizacin de tcnicas exhaustivamente refinadas para la interconexin de
componentes y el ensamblado de subsistemas.
El aislamiento del hardware para protegerlo de formas de interferencia esperadas.

Los componentes software de los grandes sistemas embebidos actualmente son mucho ms
complejos que sus correspondientes elementos hardware. Aunque el software no se deteriora con
el uso, resulta en cualquier caso virtualmente imposible escribir programas libres de fallos.

Especificaciones de requisitos rigurosas, si no formales.

Utilizacin de probadas metodologas de diseo.
Utilizacin de lenguajes que faciliten la abstraccin de datos y la modularidad.
Uso de herramientas de ingeniera de software para ayudar en la manipulacin de los
componentes software y en la gestin de la complejidad.

Tolerancia a fallos

Un sistema puede proporcionar diferentes niveles de tolerancia a fallos

Tolerancia total frente a fallos: el sistema contina en funcionamiento en presencia de

fallos, aunque por un periodo limitado, sin una prdida significativa de funcionalidad o
prestaciones.
Degradacin controlada (o cada suave): el sistema contina en operacin en presencia de
errores, aceptndose una degradacin parcial de la funcionalidad o de las prestaciones
durante la recuperacin o la reparacin.
Fallo seguro: el sistema cuida de su integridad durante el fallo aceptando una parada
temporal de su funcionamiento.

El nivel de tolerancia a fallos requerido depender de la aplicacin. Aunque, al menos

tericamente, los sistemas ms crticos respecto a la seguridad exigirn una tolerancia total frente
a fallos, en la prctica muchos se conformarn con una degradacin controlada. En concreto
aquellos sistemas que puedan sufrir un dao fsico, como los aviones de combate, pueden
proporcionar varios grados de degradacin controlada.

Los primeros acercamientos al diseo de sistemas tolerantes a fallos realizaban tres suposiciones:

1. Los algoritmos del sistema han sido diseados correctamente.

2. Se conocen todos los posibles modos de fallos de los componentes.
3. Se han tenido en cuenta todas las posibles interacciones entre el sistema y el entorno.
Redundancia
Todas las tcnicas utilizadas para conseguir tolerancia a fallos se basan en aadir elementos extra
al sistema para que detecte y se recupere de los fallos. Estos componentes son redundantes un el
sentido de que no son necesarios para el normal funcionamiento del sistema. Esto se llama a
menudo redundancia protectora. La intencin ltima de la tolerancia a fallos es minimizar la
redundancia maximizando la fiabilidad proporcionada, siempre bajo las restricciones de coste y
tamao del sistema. Se debe tener cuidado al estructurar los sistemas tolerantes a fallos, ya que
los distintos componentes incrementan inevitablemente la complejidad de todo el sistema.

La redundancia dinmica es la redundancia aportada dentro de un componente que hace que el

mismo indique, explcita o implcitamente, que la salida es errnea.

Programacin de N-versiones
El xito de TMR y NMR en hardware han motivado un enfoque similar en el tratamiento de la
tolerancia a fallos software. Sin embargo, como el software no se deteriora con el uso, se utilizan
para la deteccin de fallos de diseo.

Cuando la frmula resulta muy complicada, puede ser algebraicamente dispuesta para la
computacin de dos o ms formas distintas con lo que se pueden conseguir dos o mis conjuntos
de tarjetas. Si se emplean las mismas constantes con cada conjunto, y si bajo estas circunstancias
coinciden los resultados, podremos estar bastantes seguros de la precisin de todos ellos.

La programacin de N-versiones se define como la generacin independiente de N programas

funcionalmente equivalentes (con N mayor o igual a 2) a partir de la misma especificacin inicial
(Chen y Avizienis, 1978). La generacin independiente de N programas significa que N individuos o
grupos producen las N versiones necesarias del software sin interaccin (por esta razn la
programacin de iV-versiones se denomina frecuentemente diversidad en el diseo). Una vez
diseados y escritos, los programas se ejecutan de forma concurrente con las mismas entradas, y
un programa director compara sus resultados. En principio, los resultados deberan ser idnticos,
pero en la prctica existirn algunas diferencias, en cuyo caso se toma como correcto, por
consenso, uno de ellos, suponiendo que exista alguno.

La programacin de IV-versiones se basa en la suposicin de que se puede especificar

completamente un programa de forma consistente y sin ambigedad, y que los programas que
han sido desenrollados independientemente fallarn de forma independiente.

Comparacin de votos
Desafortunadamente, no todos los resultados son de una naturaleza exacta. En concreto, en
aquellos votos que requieren clculos con nmeros reales, ser difcil que diferentes versiones
produzcan exactamente el mismo resultado. Esto podra deberse a la inexactitud de la
representacin hardware de los nmeros reales, o a la sensibilidad de los datos respecto a un
algoritmo concreto. Las tcnicas utilizadas en la comparacin de estos tipos de resultados se
denominan votacin inexacta. Una tcnica simple es acabar comprobando un rango utilizando una
estimacin previa o un valor medio de los N resultados. Sin embargo, puede que sea difcil
encontrar un enfoque general para la votacin inexacta.
Otra dificultad asociada a la aritmtica de precisin finita es el llamado problema de la
comparacin consistente (Brilliant et al., 1987). Este problema se da cuando una aplicacin tiene
que realizar una comparacin basada en un valor finito dado en la especificacin; el resultado de
la comparacin determina entonces el curso de la accin.

Aspectos principales de la programacin de N-versiones

Especificacin inicial: se ha sugerido que la gran mayora de Los fallos en el software provienen de
tina especificacin inadecuada (Leveson, 1986). Las tcnicas actuales estn lejos de producir
especificaciones completas, consistentes, comprensibles y no ambiguas, aunque los mtodos de
especificacin formal proporcionan una fructfera lnea de investigacin. Resulta evidente que un
error de especificacin se manifestar en todas Las N versiones de la implementacin.

Independencia en el diseo: se han realizado algunos experimentos (Knight et al., 1985;

Avizienis et al., 1988: Brilliant et al., 1990; Eckhardt et al., 1991; Hattoii, 1997) para

comprobar la hiptesis de que el software producido independientemente mostrar fallos

distintos. Sin embargo, se obtienen resultados conflictivos. Knight et al. < 1985) han demostrado

que para un problema particular con una especificacin concienzudamente refinada.

la hipctesis tuvo que ser rechazada con un nivel de confianza del 99 por ciento.

Por contra, Avizienis et al. (1988) afirmaron que era muy raro encontrar fallos idnticos

en dos versiones de tm sistema de seis versiones. Comparando sus resultodos y los ohtenidos

por Knight et al., concluyeron que el problema estudiacto por Knight et al. tena un

potencial de diversidad Limitado, y que los test de aceptacih eran totalmente inadecuados

le acuerdo con los estndares industriales habituales. Avizienis et al. afirmaron que

la aplicacin rigurosa del paradigma de la programacin de N-versiones habra conducido

a la eliminacin de todos los errores encontridos por Knight et al. antes de la aceptacin

del sistema. Sin embargo, existe la certeza de que all donde la especificacin resulte

compleja, inevitablemente se producir una distorsin de la comprensin de los requisitos

entre los equipos independientes. Si estos requisitos tambin se refieren a datos de entrada

poco frecuentes: entonces los errores de diseo comunes pueden no ser capturados

en la fase de pruebas. En aos ms recientes, estudios de Hatton (1997) han encontrado

que un sistema de tres versiones es, a pesar de todo, entre 5 y 9 veces ms fiable que un

sistema de alta calidad de versin nica.