SISTEMAS EN TIEMPO REAL

Fiabilidad y Tolerancia a Fallos en

Sistemas en Tiempo Real

Manuel Agustn Ortiz Lpez

rea de Arquitectura y Tecnologa de Computadores
Departamento de Arquitectura de Computadores,
Electrnica y Tecnologa Electrnica
Universidad de Crdoba
Crdoba a 17 de enero de 2006
 ndice

Fiabilidad y Tolerancia a Fallos en

Sistemas en Tiempo Real
ndice:

1. Introduccin
2. Fiabilidad y fallos
2.1. Definiciones y clasificacin de los fallos
2.2. Prevencin de fallos
2.3. Tolerancia a fallos
2.4. Redundancia
3. Redundancia del software
3.1. Programacin de N-versiones
3.2. Estrategia de bloques de recuperacin en la tolerancia a fallos
software
4. Medicin y prediccin de la fiabilidad de software

Sistemas en Tiempo Real

Manuel Ortiz. Universidad de Crdoba Pgina 1
Sistemas en Tiempo Real
Manuel Ortiz. Universidad de Crdoba Pgina 2
 Introduccin

1. Introduccin

El tema que iniciamos est basado en los trabajos de Anderson

y Lee(1990) y en la bibliografa recomendada, la cual a su vez,
hace referencia continua a estos trabajos.

Los requisitos de fiabilidad y seguridad de los sistemas de

tiempo real son mucho ms estrictos que los de un sistema
informtico de propsito general. Existen tres causas que
provocan un fallo un sistema en tiempo real:
Errores en una especificacin inadecuada.

Defectos en alguno de los componentes, tanto componentes

hardware como software.

Por efectos del entorno.

Sistemas en Tiempo Real

Manuel Ortiz. Universidad de Crdoba Pgina 3
Sistemas en Tiempo Real
Manuel Ortiz. Universidad de Crdoba Pgina 4
 Fiabilidad y Fallos

2. Fiabilidad y Fallos.[Krisna,96][Burns, 03]

2.1. Definiciones y clasificacin de los fallos
Fiabilidad es una medida del xito de que el sistema se
comporta de acuerdo a una especificacin.

Fallo. Cuando el comportamiento del sistema se desva del

especificado, se dice que el sistema tiene un fallo.

Las definiciones de fiabilidad y fallo estn relacionadas con el

comportamiento externo del sistema. Los fallos son el
resultado de problemas internos que se manifiestan
externamente.

Un error es la consecuencia de un fallo del sistema y una

avera es un efecto del error en un servicio que da el sistema.

Los tipos de fallo se clasifican como:

Fallos transitorios. Un fallo transitorio comienza en un instante de
tiempo concreto se mantiene durante algn perodo y luego
desaparece. Ejemplo de este tipo de fallos suelen darse en los
componentes hardware debidos a alguna interferencia externa y se
mantiene mientras se mantiene la interferencia. Muchos de los fallos
de los sistemas de comunicaciones son transitorios.

Fallos permanentes. Son fallos que comienzan en un instante de

tiempo y permanece hasta que se repara el sistema.

Fallos intermitentes. Son fallos transitorios que ocurren de vez en

cuando. Ejemplo de este tipo de fallos suelen darse en componentes
hardware sensibles a la temperatura, cuando se calienta demasiado

Sistemas en Tiempo Real

Manuel Ortiz. Universidad de Crdoba Pgina 5
 fallan y cuando se enfran vuelven a funcionar fallando de nuevo
cuando se calientan.

Independientemente de la clasificacin anterior los fallos se

suelen clasificar tambin de acuerdo a su comportamiento
temporal (fallos de tiempo) y su comportamiento de acuerdo a
las salidas que provocan (fallos de valor). La siguiente figura
muestra como se clasifican estos modos de fallo:

Con la clasificacin anterior un sistema puede fallar, en el

dominio del tiempo, de la siguiente manera:
Fallo descontrolado. El sistema produce errores descontrolados
tanto en el dominio de valor como del tiempo, incluido los fallos de
improvisacin.

Fallo de retraso. El sistema produce servicios correctos en el

dominio de valor, pero sufre errores de retraso en el tiempo.

Fallo de silencio. El sistema deja de producir servicios debidos a

fallos de omisin provocando en el resto del sistema fallos de
omisin.
Sistemas en Tiempo Real
Manuel Ortiz. Universidad de Crdoba Pgina 6
 Fallo de parada. Similar al fallos de silencio pero informa a otros
sistemas que tiene fallo de silencio.

Fallo controlado. El sistema falla segn una forma especificada.

Sin fallos. El sistema produce servicios correctos tanto en el dominio

del valor como del tiempo.

Sistemas en Tiempo Real

Manuel Ortiz. Universidad de Crdoba Pgina 7
2.2. Prevencin de fallos

La prevencin de fallos se refiere al intento de impedir

cualquier posibilidad de fallo antes de que el sistema est
operativo. Para ello es necesario evitar y eliminar los fallos
durante la etapa de diseo. Para evitar los fallos se acta tanto
en el hardware como en el software.

Hardware:
Utilizacin de los componentes ms fiables dentro de las
restricciones de coste/prestaciones.

Utilizacin de tcnicas refinadas para la interconexin y ensamblado

de componentes.

Aislamiento del hardware para evitar interferencias.

Software:
Especificaciones de requisitos rigurosas e incluso 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 ayuda a la

manipulacin de los componentes software.

La segunda parte en la prevencin de fallos consiste en su

intento de eliminacin, para ello el sistema se somete a un
conjunto de pruebas lo ms exhaustivas posibles.

Sistemas en Tiempo Real

Manuel Ortiz. Universidad de Crdoba Pgina 8
2.3. Tolerancia a Fallos
A pesar de todas las tcnicas y pruebas de verificacin los
componentes hardware y software pueden fallar, y dado que
muchas veces no es posible su mantenimiento y reparacin se
hace necesario recurrir a la idea de tolerancia a fallos.

Un sistema puede proporcionar distintos niveles de tolerancia a

fallos:
Tolerancia total frente a fallos. El sistema continua en presencia de
fallos sin una prdida significativa de funcionalidad o de
prestaciones, aunque por un perodo limitado.

Degradacin controlada. El sistema continua en operacin en

presencia de errores, aunque con una funcionalidad parcial durante la
reparacin.

Fallo seguro. El sistema cuida de su integridad durante el fallo

aceptando una parada temporal de su funcionamiento.

El nivel de tolerancia de un sistema depender de la aplicacin,

y aunque tericamente los sistemas crticos deben tener
tolerancia total frente a fallos, la realidad es que la mayora
admiten una degradacin controlada.

La tolerancia a fallos consta de cuatro fases:

Deteccin de errores

Confinamiento y valoracin de los daos

Recuperacin del error

Tratamiento del fallo y continuacin del servicio

Sistemas en Tiempo Real
Manuel Ortiz. Universidad de Crdoba Pgina 9
 Deteccin de errores. Se pueden identificar dos clases
tcnicas de deteccin de errores:
Deteccin por el entorno de ejecucin del programa:

Detectados por el hardware prximo al procesador. Por ejemplo ,

la deteccin de una instruccin ilegal, salto a una direccin
invlida, violacin de la proteccin, etc.

Detectados por el sistema soporte del lenguaje de programacin

de tiempo real. Por ejemplo referencia a un apuntador nulo,
valor fuera de rango, etc.

Deteccin por la aplicacin. Los errores los detecta la propia

aplicacin:

Comprobacin de rplicas, como la programacin de N-versiones

que se ver posteriormente.

Comprobaciones temporales. Por ejemplo a travs del watch-dog

timer. El componente software debe resetear el contador antes de
que se desborde de forma contina indicando as que funciona de
forma correcta. Estas comprobaciones temporales no aseguran
que est funcionando correctamente desde el punto de vista
lgico pero si al menos funciona a tiempo.

Comprobaciones inversas. En aquellos componentes que tengan

una relacin uno a uno con la salidas, se puede tomar la salida y
calcular la entrada que corresponde a esta salida y comprobarla
con la entrada del sistema.

Cdigos de comprobacin. Se utilizan sobre todo para comprobar

la integridad de los datos. Es lo que habitualmente llamamos
CheckSum.

Sistemas en Tiempo Real

Manuel Ortiz. Universidad de Crdoba Pgina 10
 Comprobaciones estructurales. Se utilizan para comprobar la
integridad de los objetos como listas o colas. En este caso se trata
de comprobar si por ejemplo los punteros no est corruptos, o
comprobar si el nmero de elementos del objeto es el correcto.

Confinamiento y valoracin de los daos. Cuando ocurre un

error en un componente, este error puede transmitir una
informacin errnea a todo el sistema. Se trata de construir
cortafuegos para evitar la propagacin del error.

Recuperacin del error. Una vez detectado el fallo y valorado

el dao que haya podido producir hay que recuperar el error.
Existe dos estrategias para la recuperacin: recuperacin hacia
delante y recuperacin hacia atrs. Ejemplos de la recuperacin
hacia delante son los cdigos autocorrectores como el cdigo
Hamming o la utilizacin de punteros redundantes en las listas
enlazadas. Un ejemplo de recuperacin hacia atrs es la
estrategia de bloques de recuperacin que se tratar ms
adelante en este tema.

Tratamiento del fallo y continuacin del servicio. Aunque se

haya localizado el problema y recuperado el error, puede que el
fallo se vuelva a producir. El tratamiento de los fallos se divide
en dos fases: la localizacin del fallo y la recuperacin del
sistema. En el caso del hardware puede bastar con cambiar el
componente, en el caso del software puede que baste con
instalar una nueva versin del software. Sin embargo existen
sistemas que no pueden parar y el programa deber ser
Sistemas en Tiempo Real
Manuel Ortiz. Universidad de Crdoba Pgina 11
 modificado mientras se est ejecutando, este es un problema
bastante complejo que no estudiaremos en este tema.

Sistemas en Tiempo Real

Manuel Ortiz. Universidad de Crdoba Pgina 12
2.4. Redundancia
Todas las tcnicas que se utilizan para conseguir la tolerancia a
fallos se basan en aadir elementos redundantes que detecten y
recuperen los fallos. Estos elementos son innecesarios en el
funcionamiento normal del sistema, por lo que se trata de
minimizar la redundancia y maximizar la fiabilidad dentro de
los costes y tamao del sistema.

Existen varias clasificaciones de redundancia dependiendo de

los elementos hardware o software considerados y de la
terminologa utilizada. A continuacin repasaremos
brevemente la redundancia hardware dejando la redundancia
software para los siguientes captulos.

Redundancia hardware

En el caso de los elementos hardware, se distingue entre la

redundancia esttica o enmascarada y la redundancia dinmica.
En el caso de la redundancia esttica, los componentes se utilizan
dentro de un sistema para ocultar los efectos de los fallos. Un
ejemplo es la redundancia triple modular TMR (caso particular de la
N-modular redundancy en el que N=3). La TMR consiste en tener
tres componentes idnticos y unos circuitos que comparan
continuamente la salida y en el caso de que alguna difiera de las otras
dos, se bloquea la salida.

Sistemas en Tiempo Real

Manuel Ortiz. Universidad de Crdoba Pgina 13
 En el caso de la redundancia dinmica es el mismo componente el
que indica si la salida es errnea. El sistema debe tener la capacidad
de deteccin de errores y debe ser otro sistema el que realice la
recuperacin del error. Un ejemplo de ello es el detector de paridad
en el caso de memoria DRAM.

Sistemas en Tiempo Real

Manuel Ortiz. Universidad de Crdoba Pgina 14
 Redundancia del software

3. Redundancia del software.[Krisna, 96][Burns, 03]

La realizacin de software tolerante a fallos est emergiendo

actualmente y est en su fase inicial. Dado que el software no
se degrada, la tolerancia a fallos en el software est basada en
la bsqueda de errores de diseo. Como es sabido es imposible
escribir un programa largo sin cometer errores. La prctica
indica que la tasa de fallos software es mayor que la tasa de
fallos hardware en un aplicacin compleja.

La redundancia en software en la bsqueda de errores de

diseo tiene dos enfoques distintos. Uno de ellos es similar a la
redundancia enmascarada del hardware denominada
programacin de N-versiones y el otro se basa en la deteccin
y recuperacin de errores que es anlogo a la redundancia
dinmica del hardware en el sentido de que se activan los
procedimientos de recuperacin despus de que se ha detectado
el error.

Sistemas en Tiempo Real

Manuel Ortiz. Universidad de Crdoba Pgina 15
 Redundancia del software

3.1. Programacin de N-versiones

La programacin de N-versiones se basa en la generacin
independiente de N programas funcionalmente equivalentes.
Una vez diseados los programas se ejecutan de forma
independiente y un programa director va comparando los
resultados.

En la programacin de N-versiones se supone que se ha podido

especificar completamente y sin ambigedad una aplicacin y
que los programas se han escrito independientemente y por
tanto deben fallar de forma independiente. Esta suposicin
supone que se deben utilizar lenguajes y entornos diferentes
para evitar errores debidos a la implementacin el lenguaje. Si
se utiliza el mismo lenguaje deben utilizarse compiladores y
procesadores de distintos fabricantes. Por ejemplo para el
boeing 777 se escribi un nico programa en ADA pero se
utilizaron tres compiladores y procesadores distintos.

Sistemas en Tiempo Real

Manuel Ortiz. Universidad de Crdoba Pgina 16
 Redundancia del software

Cada versin realiza el calculo y comunica la programa director el

resultado (voto).

El programa director comunica el estatus de la comparacin a cada

versin en funcin del resultado de la comparacin o de si han sido
entregados a tiempo.

Los posibles resultados suelen ser: Continuacin; terminacin de una

o ms versiones, continuacin despus de modificar uno o ms votos
respecto al valor de la mayora.

Comparacin de votos

Es crucial en la programacin de Nversiones la eficacia y la

facilidad con que el programa director compara los votos. En
algunas aplicaciones donde los resultados del procesamiento de
cada versin son exactos, el programa director puede comparar
fcilmente el resultado y tomar una decisin.

Sistemas en Tiempo Real

Manuel Ortiz. Universidad de Crdoba Pgina 17
 Redundancia del software

Desafortunadamente en la mayora de las aplicaciones dicha

comparacin no resulta tan fcil. Para ahondar en este aspecto
de la comparacin de votos se puede consultar la bibliografa
recomendada y los trabajos de Anderson y Lee del ao 1990.

Sistemas en Tiempo Real

Manuel Ortiz. Universidad de Crdoba Pgina 18
 Redundancia del software

3.2. Estrategia de bloques de recuperacin en la

tolerancia a fallos software

La programacin N-versiones se le considera el equivalente

software a la redundancia esttica en hardware ya que cada
versin tiene una relacin fija con el director y siempre entra
en funcionamiento se hayan producidos fallos o no. En el caso
de la redundancia dinmica los componentes redundantes solo
entran en funcionamiento cuando se ha detectado un error

Cabe decir que la estrategia de bloques de recuperacin no est

implementada en ningn lenguaje de programacin comercial
solo se han desarrollado algunos sistemas experimentales.

Los bloques de recuperacin (propuestos por Horning et al.,

1974) son bloques en el sentido habitual de los lenguajes de
programacin, excepto que en la entrada del bloque se
encuentra un punto de recuperacin automtico, y en la salida
se encuentra un test de aceptacin.

El test de aceptacin se utiliza para comprobar que el sistema

se encuentra dentro de un estado aceptable despus de la
ejecucin del bloque. Si el test de aceptacin falla, provoca que
el programa sea restaurado al punto de recuperacin del
principio del bloque y se ejecuta otro mdulo alternativo. Si de
nuevo falla el test de aceptacin se ejecuta de nuevo otro
mdulo y as alternativamente. Si falla todos los mdulos
entonces el bloque falla. La siguiente figura muestra
Sistemas en Tiempo Real
Manuel Ortiz. Universidad de Crdoba Pgina 19
 Redundancia del software

esquemticamente como funcionan los bloques de

recuperacin:

Test de aceptacin

El test de aceptacin es crucial en la tcnica de bloques de

recuperacin ya que proporciona el mecanismo para la
deteccin de errores. Este test no debe sobrecargar al sistema
para que no influya en el rendimiento libre de errores del
sistema.

Sistemas en Tiempo Real

Manuel Ortiz. Universidad de Crdoba Pgina 20
 Medicin y prediccin de la fiabilidad de software

4. Medicin y prediccin de la fiabilidad de

software. [Burns, 03]

La fiabilidad del software se considera como la probabilidad de

que un programa funcione correctamente en un entorno
concreto y durante un periodo de tiempo. Se han propuesto
varios modelos para estimar la fiabilidad y calidad del
software, los cuales se pueden clasificar en:
Modelos de crecimiento de la fiabilidad del software. Estos modelos
intentan predecir la fiabilidad de un programa basndose en su
historial de errores

Modelos estadsticos. Estiman la fiabilidad del software mediante la

respuesta exitosa o fallida en determinados casos de prueba
aleatorios.

Sistemas en Tiempo Real

Manuel Ortiz. Universidad de Crdoba Pgina 21