Está en la página 1de 43

dit

UPM

Fiabilidad y tolerancia
de fallos
Juan Antonio de la Puente
DIT/UPM

Transparencias basadas en el captulo 5 del libro de A. Burns y A. Wellings Real-Time Systems and Programming Languuages, 3 edicin (2001)
Objetivos

u Veremos cules son los factores que afectan a la


fiabilidad de un sistema

u Tambin veremos algunas tcnicas para tolerar fallos de


software

STRL -30/05/01 2001 Juan Antonio de la Puente 1


ndice

u Fiabilidad, averas y fallos


u Modos de fallo
u Prevencin y tolerancia de fallos
u Redundancia esttica y dinmica
Programacin con N versiones
Bloques de recuperacin
u Redundancia dinmica y excepciones
u Seguridad, fiabilidad y confiabilidad

STRL -30/05/01 2001 Juan Antonio de la Puente 2


Fallos de funcionamiento

u Los fallos de funcionamiento de un sistema pueden tener


su origen en
Una especificacin inadecuada
Errores de diseo del software
Averas en el hardware
Interferencias transitorias o permanentes en las comunicaciones

u Nos centraremos en el estudio de los errores de software

STRL -30/05/01 2001 Juan Antonio de la Puente 3


Conceptos bsicos
u La fiabilidad (reliability) de un sistema es una medida de
su conformidad con una especificacin autorizada de su
comportamiento
u Una avera (failure) es una desviacin del
comportamiento de un sistema respecto de su
especificacin
u Las averas se manifiestan en el comportamiento externo
del sistema, pero son el resultado de errores (errors)
internos
u Las causas mecnicas o algortmicas de los errores se
llaman fallos (faults)

STRL -30/05/01 2001 Juan Antonio de la Puente 4


Fallos encadenados
u Los fallos pueden ser consecuencia de averas en los
componentes del sistema (que son tambin sistemas)

avera
avera fallo
fallo error
error avera
avera fallo
fallo

STRL -30/05/01 2001 Juan Antonio de la Puente 5


Tipos de fallos

u Fallos transitorios
desaparecen solos al cabo de un tiempo
ejemplo: interferencias en comunicaciones
u Fallos permanentes
permanecen hasta que se reparan
ejemplo: roturas de hardware, errores de diseo de software
u Fallos intermitentes
fallos transitorios que ocurren de vez en cuando
ejemplo: calentamiento de un componente de hardware

Debe impedirse que los fallos de todos estos tipos


causen averas

STRL -30/05/01 2001 Juan Antonio de la Puente 6


Tipos de avera (failure modes)

nunca avera
se avera

valor tiempo arbitrario

error de error de pronto nunca avera avera


intervalo valor (omisin) por retraso incontrolada

avera parada avera


silenciosa segura controlada

STRL -30/05/01 2001 Juan Antonio de la Puente 7


Prevencin y tolerancia de fallos

u Hay dos formas de aumentar la fiabilidad de un sistema:


Prevencin de fallos
Se trata de evitar que se introduzcan fallos en el sistema antes de que
entre en funcionamiento
Tolerancia de fallos
Se trata de conseguir que el sistema contine funcionando aunque se
produzcan fallos

u En ambos casos el objetivo es desarrollar sistemas con


tipos de averas bien definidos

STRL -30/05/01 2001 Juan Antonio de la Puente 8


Prevencin de fallos

u Se realiza en dos etapas:

Evitacin de fallos
Se trata de impedir que se introduzcan fallos durante la construccin
del sistema
Eliminacin de fallos
Consiste en encontrar y eliminar los fallos que se producen en el
sistema una vez construido

STRL -30/05/01 2001 Juan Antonio de la Puente 9


Tcnicas de evitacin de fallos

u Hardware
Utilizacin de componentes fiables
Tcnicas rigurosas de montaje de subsistemas
Apantallamiento de hardware

u Software
Especificacin de requisitos rigurosa o formal
Mtodos de diseo comprobados
Lenguajes con abstraccin de datos y modularidad
Utilizacin de entornos de desarrollo con computador (CASE)
adecuados para gestionar los componentes

STRL -30/05/01 2001 Juan Antonio de la Puente 10


Tcnicas de eliminacin de fallos

u Comprobaciones
Revisiones de diseo
Verificacin de programas
Inspeccin de cdigo

u Pruebas (tests)
Son necesarias, pero tienen problemas:
no pueden ser nunca exhaustivas
slo sirven para mostrar que hay errores, no que no los hay
a menudo es imposible reproducir las condiciones reales
los errores de especificacin no se detectan

STRL -30/05/01 2001 Juan Antonio de la Puente 11


Limitaciones de la prevencin de fallos

u Los componentes de hardware fallan,


a pesar de las tcnicas de prevencin
La prevencin es insuficiente si
la frecuencia o la duracin de las reparaciones es inaceptable
no se puede detener el sistema para efectuar operaciones de
mantenimiento

u Ejemplo: naves espaciales no tripuladas

u La alternativa es utilizar tcnicas de tolerancia de fallos

STRL -30/05/01 2001 Juan Antonio de la Puente 12


Grados de tolerancia de fallos

u Tolerancia completa (fail operational)


El sistema sigue funcionando, al menos durante un tiempo, sin
perder funcionalidad ni prestaciones
u Degradacin aceptable (fail soft, graceful degradation)
El sistema sigue funcionando con una prdida parcial de
funcionalidad o prestaciones hasta la reparacin del fallo
u Parada segura (fail safe)
El sistema se detiene en un estado que asegura la integridad del
entorno hasta que se repare el fallo

El grado de tolerancia de fallos necesario depende


de la aplicacin

STRL -30/05/01 2001 Juan Antonio de la Puente 13


Ejemplo : control de trfico areo

funcionalidad
funcionalidad
completa
completa yy tiempo
tiempo
de
de respuesta
respuesta
correcto
correcto

funcionalidad
funcionalidad
funcionalidad
funcionalidad de
de emergencia
emergencia
mnima
mnima para
para control
control (slo
(slo separacin
separacin
de
de trfico
trfico bsico
bsico entre
entre aviones
aviones))

sistema
sistema de
de reserva
reserva
para
para fallos
fallos
catastrficos
catastrficos

STRL -30/05/01 2001 Juan Antonio de la Puente 14


Redundancia

u La tolerancia de fallos se basa en la redundancia

u Se utilizan componentes adicionales para detectar los


fallos y recuperar el comportamiento correcto

u Esto aumenta la complejidad del sistema y puede


introducir fallos adicionales

u Es mejor separar los componentes tolerantes del resto del


sistema

STRL -30/05/01 2001 Juan Antonio de la Puente 15


Redundancia en hardware

u Redundancia esttica
Los componentes redundantes estn siempre activos
Se utilizan para enmascarar los fallos
Ejemplo:
Redundancia modular triple ( N), TMR/NMR

u Redundancia dinmica
Los componentes redundantes se activan cuando se detecta un
fallo
Se basa en la deteccin y posterior recuperacin de los fallos
Ejemplos:
sumas de comprobacin
bits de paridad

STRL -30/05/01 2001 Juan Antonio de la Puente 16


Tolerancia de fallos de software

u Tcnicas para detectar y corregir errores de diseo

u Redundancia esttica
Programacin con N versiones

u Redundancia dinmica
Dos etapas: deteccin y recuperacin de fallos
Bloques de recuperacin
Proporcionan recuperacin hacia atrs
Excepciones
Proporcionan recuperacin hacia adelante

STRL -30/05/01 2001 Juan Antonio de la Puente 17


Programacin con N versiones

u Diversidad de diseo
N programas desarrollados independientemente con la misma
especificacin
sin interacciones entre los equipos de desarrollo

u Ejecucin concurrente
proceso coordinador (driver)
intercambia datos con los procesos que ejecutan las versiones
todos los programas tienen las mismas entradas
las salidas se comparan
si hay discrepancia se realiza una votacin

STRL -30/05/01 2001 Juan Antonio de la Puente 18


Programacin con N versiones

cordinador
estado
votos

versin 1 versin 2 versin 3

STRL -30/05/01 2001 Juan Antonio de la Puente 19


Comparacin consistente

X1 X2 X3
u La comparacin de valores
reales o texto no es exacta
no u Cada versin produce un
> x0 > x0 > x0 resultado correcto, pero
s s diferente de las otras
u No se arregla comparando con
no
> y0 > y0 > y0
x0+, y0+

V1 V2 V3

STRL -30/05/01 2001 Juan Antonio de la Puente 20


Problemas

u La correcta aplicacin de este mtodo depende de:

Especificacin inicial
Un error de especificacin aparece en todas las versiones
Desarrollo independiente
No debe haber interaccin entre los equipos
No est claro que distintos programadores cometan errores
independientes
Presupuesto suficiente
Los costes de desarrollo se multiplican
u sera mejor emplearlos en mejorar una versin nica?

El mantenimiento es tambin ms costoso

u Se ha utilizado en sistemas de avinica crticos.

STRL -30/05/01 2001 Juan Antonio de la Puente 21


Redundancia dinmica en software

Cuatro etapas:
1. Deteccin de errores
no se puede hacer nada hasta que se detecta un error
2. Evaluacin y confinamiento de los daos
diagnosis: averiguar hasta dnde ha llegado la informacin errnea
3. Recuperacin de errores
llevar el sistema a un estado correcto, desde el que pueda seguir
funcionando (tal vez con funcionalidad parcial)
4. Reparacin de fallos
Aunque el sistema funcione, el fallo puede persistir y hay que
repararlo

STRL -30/05/01 2001 Juan Antonio de la Puente 22


Deteccin de errores

u Por el entorno de ejecucin


hardware (p.ej.. instruccin ilegal)
ncleo o sistema operativo (p.ej. puntero nulo)

u Por el software de aplicacin


Duplicacin (redundancia con dos versiones)
Comprobaciones de tiempo
watchdog timer
deadline checks
Inversin de funciones
Cdigos detectores de error
Validacin de estado
Validacin estructural

STRL -30/05/01 2001 Juan Antonio de la Puente 23


Evaluacin y confinamiento de daos

u Es importante confinar los daos causados por un fallo a


una parte limitada del sistema (firewalling)

u Se trata de estructurar el sistema de forma que se


minimice el dao causado por los componentes
defectuosos (compartimentos estancos, firewalls)

u Tcnicas
Descomposicin modular: confinamiento esttico
Acciones atmicas: confinamiento dinmico

STRL -30/05/01 2001 Juan Antonio de la Puente 24


Recuperacin de errores

u Es la etapa ms importante
u Se trata de situar el sistema en un estado correcto desde
el que pueda seguir funcionando
u Hay dos formas de llevarla a cabo:
Recuperacin directa (hacia adelante) (FER)
Se avanza desde un estado errneo haciendo correcciones sobre
partes del estado
Recuperacin inversa (hacia atrs) (BER)
Se retrocede a un estado anterior correcto que se ha guardado
previamente

STRL -30/05/01 2001 Juan Antonio de la Puente 25


Recuperacin directa

u La forma de hacerla es especfica para cada sistema


u Depende de una prediccin correcta de los posibles fallos
y de su situacin
u Hay que dejar tambin en un estado seguro el sistema
controlado
u Ejemplos
punteros redundantes en estructuras de datos
cdigos autocorrectores

STRL -30/05/01 2001 Juan Antonio de la Puente 26


Recuperacin inversa

u Consiste en retroceder a un estado anterior correcto y


ejecutar un segmento de programa alternativo
(con otro algoritmo)
El punto al que se retrocede se llama punto de recuperacin
(recovery point)
La accin de guardar el estado se llama chekpointing
u No es necesario averiguar la causa ni la situacin del fallo
Sirve para fallos imprevistos
u Pero no puede deshacer los errores que aparecen en el
sistema controlado!

STRL -30/05/01 2001 Juan Antonio de la Puente 27


Efecto domin

u Cuando hay tareas concurrentes la recuperacin se


complica
deteccin
de error
R11 R12 R13
T1

T2

R21 R22

u Solucin: lneas de recuperacin consistentes para


todas las tareas

STRL -30/05/01 2001 Juan Antonio de la Puente 28


Reparacin de fallos

u La reparacin automtica es difcil y depende del sistema


concreto
u Hay dos etapas
Localizacin del fallo
Se pueden utilizar tcnicas de deteccin de errores
Reparacin del sistema
Los componentes de hardware se pueden cambiar
Los componentes de software se reparan haciendo una nueva versin
En algunos casos puede ser necesario reemplazar el componente
defectuoso sin detener el sistema

STRL -30/05/01 2001 Juan Antonio de la Puente 29


Bloques de recuperacin

u Es una tcnica de recuperacin inversa integrada en el


lenguaje de programacin
u Un bloque de recuperacin es un bloque tal que
su entrada es un punto de recuperacin
a su salida se efecta una prueba de aceptacin
sirve para comprobar si el mdulo primario del bloque termina en un
estado correcto
si la prueba de aceptacin falla,
se restaura el estado inicial en el punto de recuperacin
se ejecuta un mdulo alternativo del mismo bloque
si vuelve a fallar, se siguen intentando alternativas
cuando no quedan ms, el bloque falla y hay que intentar al
recuperacin en un nivel ms alto

STRL -30/05/01 2001 Juan Antonio de la Puente 30


Esquema de recuperacin

restaurar
punto de
recuperacin error
entrada
al bloque establecer ok abandonar
s ejecutar
punto de ms test punto de
alternativa
recuperacin recuperacin
no

fallo del bloque

STRL -30/05/01 2001 Juan Antonio de la Puente 31


Sintaxis

ensure <condicin de aceptacin>


by
<mdulo primario>
else by
<mdulo alternativo>
else by
<mdulo alternativo>
...
else by
<mdulo alternativo>
else error;

Puede haber bloques anidados


si falla el bloque interior, se restaura el punto de
recuperacin del bloque exterior

STRL -30/05/01 2001 Juan Antonio de la Puente 32


Ejemplo: ecuacin diferencial

ensure error <= tolerance


by
Explicit_Runge_Kutta;
else by
Implicit_Runge_Kutta;
else error;

u El mtodo explcito es ms rpido, pero no es adecuado para


algunos tipos de ecuaciones
u El mtodo implcito sirve para todas las ecuaciones, pero es
ms lento
u Este esquema sirve para todos los casos
u Puede tolerar fallos de programacin

STRL -30/05/01 2001 Juan Antonio de la Puente 33


Prueba de aceptacin

u Es fundamental para el buen funcionamiento de los


bloques de recuperacin
u Hay que buscar un compromiso entre deteccin
exhaustiva de fallos y eficiencia de ejecucin
u Se trata de asegurar que el resultado es aceptable, no
forzosamente correcto
u Pero hay que tener cuidado de que no queden errores
residuales sin detectar

STRL -30/05/01 2001 Juan Antonio de la Puente 34


Comparacin

N versiones Bloques de recuperacin


u Redundancia esttica u Redundancia dinmica
u Diseo u Diseo
algoritmos alternativos algoritmos alternativos
proceso coordinador prueba de aceptacin
u Ejecucin u Ejecucin
mltiples recursos puntos de recuperacin
u Deteccin de errores u Deteccin de errores
votacin prueba de aceptacin

Ambos m todos son sensibles a los errores en los requisitos!

STRL -30/05/01 2001 Juan Antonio de la Puente 35


Excepciones y redundancia dinmica

u Una excepcin es una manifestacin de un cierto tipo de


error
u Cuando se produce un error, se eleva (raise, signal,
throw) la excepcin correspondiente en el contexto donde
se ha invocado la operacin errnea
u Esto permite manejar la excepcin en este contexto
u Se trata de un mecanismo de recuperacin directa de
errores (no hay vuelta atrs)
u Pero se puede utilizar para realizar recuperacin inversa
tambin

STRL -30/05/01 2001 Juan Antonio de la Puente 36


Aplicaciones de las excepciones

u Tratar situaciones anormales en el entorno de ejecucin


u Tolerar fallos de diseo de software
u Facilitar un mecanismo generalizado de deteccin y
correccin de errores

STRL -30/05/01 2001 Juan Antonio de la Puente 37


Componente ideal tolerante con los fallos

peticin respuesta excepcin excepcin


de servicio normal de interfaz de avera

reanudacin

manejadores
actividad normal
de excepciones

excepcin
interna
peticin respuesta excepcin excepcin
de servicio normal de interfaz de avera

STRL -30/05/01 2001 Juan Antonio de la Puente 38


Seguridad y fiabilidad

u Un sistema es seguro si no se pueden producir


situaciones que puedan causar muertes, heridas,
enfermedades, ni daos en los equipos ni en el ambiente
Un accidente (mishap) es un suceso (o una serie de sucesos)
imprevisto que puede producir daos inadmisibles
u La fiabilidad es la probabilidad de que un sistema se
comporte de acuerdo con su especificacin
u La seguridad es la probabilidad de que no ocurra ningn
suceso que provoque un accidente

Seguridad y fiabilidad pueden estar en conflicto!

STRL -30/05/01 2001 Juan Antonio de la Puente 39


Confiabilidad

u La confiabilidad (dependability) es una propiedad de los


sistemas que permite confiar justificadamente en el
servicio que proporcionan
u Tiene varios aspectos

confiabilidad

disponibilidad servicio no hay no hay fugas no hay aptitud para


de utilizacin disponible situaciones de informacin alteraciones reparaciones
continuamente catastrficas no autorizadas de informacin y cambios

disponibilidad fiabilidad seguridad confidencialidad integridad mantenibilidad

STRL -30/05/01 2001 Juan Antonio de la Puente 40


Terminologa
Disponibilidad
Fiabilidad
Seguridad
Atributos
Confidencialidad
Integridad
Mantenibilidad

Prevencin de fallos
Tolerancia de fallos
Confiabilidad Medios
Reparacin de fallos
Prediccin de fallos

Fallos
Daos Errores
Averas

STRL -30/05/01 2001 Juan Antonio de la Puente 41


Resumen
u La fiabilidad de un sistema es una medida de su conformidad con
una especificacin autorizada de su comportamiento
u La fiabilidad de un sistema se puede aumentar mediante tcnicas de
prevencin o de tolerancia de fallos
u La tolerancia de fallos se basa en la redundancia
esttica (por ejemplo, N versiones)
dinmica (por ejemplo, bloques de recuperacin)
u Las excepciones proporcionan redundancia dinmica con
recuperacin directa
u La confiabilidad de un sistema es una propiedad ms amplia que la
fiabilidad

STRL -30/05/01 2001 Juan Antonio de la Puente 42

También podría gustarte