PDF de programación - Fiabilidad y tolerancia de fallos

ditdit

UPM

Fiabilidad y tolerancia

de fallos

Juan Antonio de la Puente

DIT/UPM

Transparencias basadas en el capítulo 5 del libro de A. Burns y A. Wellings Real-Time Systems and Programming Languuages, 3ª edición (2001)

Objetivos

u Veremos cuáles son los factores que afectan a la

fiabilidad de un sistema

u También veremos algunas técnicas para tolerar fallos de

software

STRL -30/05/01

©2001 Juan Antonio de la Puente

1

Índice

u Fiabilidad, averías y fallos
u Modos de fallo
u Prevención y tolerancia de fallos
u Redundancia estática y dinámica

– Programación con N versiones
– Bloques de recuperación

u Redundancia dinámica 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 especificación inadecuada
– Errores de diseño del software
– Averías 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 básicos

u La fiabilidad (reliability) de un sistema es una medida de
su conformidad con una especificación autorizada de su
comportamiento

u Una avería (failure) es una desviación del

comportamiento de un sistema respecto de su
especificación

u Las averías se manifiestan en el comportamiento externo

del sistema, pero son el resultado de errores (errors)
internos

u Las causas mecánicas o algorítmicas 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 averías en los
componentes del sistema (que son también sistemas)

avería
avería

fallo
fallo

error
error

avería
avería

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 diseño 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 averías

STRL -30/05/01

©2001 Juan Antonio de la Puente

6

Tipos de avería (failure modes)

nunca
se avería

valor

avería

tiempo

arbitrario

error de
intervalo

error de

valor

pronto

nunca

(omisión)

avería

por retraso

avería

incontrolada

avería

silenciosa

parada
segura

avería

controlada

STRL -30/05/01

©2001 Juan Antonio de la Puente

7

Prevención y tolerancia de fallos

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

– Prevención 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 continúe funcionando aunque se

produzcan fallos

u En ambos casos el objetivo es desarrollar sistemas con

tipos de averías bien definidos

STRL -30/05/01

©2001 Juan Antonio de la Puente

8

Prevención de fallos

u Se realiza en dos etapas:

– Evitación de fallos

» Se trata de impedir que se introduzcan fallos durante la construcción

del sistema

– Eliminación 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

Técnicas de evitación de fallos

u Hardware

– Utilización de componentes fiables
– Técnicas rigurosas de montaje de subsistemas
– Apantallamiento de hardware

u Software

– Especificación de requisitos rigurosa o formal
– Métodos de diseño comprobados
– Lenguajes con abstracción de datos y modularidad
– Utilización de entornos de desarrollo con computador (CASE)

adecuados para gestionar los componentes

STRL -30/05/01

©2001 Juan Antonio de la Puente

10

Técnicas de eliminación de fallos

u Comprobaciones

– Revisiones de diseño
– Verificación de programas
– Inspección de código

u Pruebas (tests)

– Son necesarias, pero tienen problemas:

» no pueden ser nunca exhaustivas
» sólo sirven para mostrar que hay errores, no que no los hay
» a menudo es imposible reproducir las condiciones reales
» los errores de especificación no se detectan

STRL -30/05/01

©2001 Juan Antonio de la Puente

11

Limitaciones de la prevención de fallos

u Los componentes de hardware fallan,
a pesar de las técnicas de prevención
– La prevención es insuficiente si

» la frecuencia o la duración 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 técnicas 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 Degradación aceptable (fail soft, graceful degradation)

– El sistema sigue funcionando con una pérdida parcial de
funcionalidad o prestaciones hasta la reparación 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 aplicación

STRL -30/05/01

©2001 Juan Antonio de la Puente

13

Ejemplo : control de tráfico aéreo

funcionalidad
funcionalidad

completa y tiempo
completa y tiempo

de respuesta
de respuesta

correcto
correcto

funcionalidad
funcionalidad

mínima para control
mínima para control

de tráfico básico
de tráfico básico

funcionalidad
funcionalidad
de emergencia
de emergencia
(sólo separación
(sólo separación
entre aviones)
entre aviones)

sistema de reserva
sistema de reserva

para fallos
para fallos
catastróficos
catastróficos

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 estática

– Los componentes redundantes están siempre activos
– Se utilizan para enmascarar los fallos
– Ejemplo:

» Redundancia modular triple (ó N), TMR/NMR

u Redundancia dinámica

– Los componentes redundantes se activan cuando se detecta un

fallo

– Se basa en la detección y posterior recuperación de los fallos
– Ejemplos:

» sumas de comprobación
» bits de paridad

STRL -30/05/01

©2001 Juan Antonio de la Puente

16

Tolerancia de fallos de software

u Técnicas para detectar y corregir errores de diseño

u Redundancia estática

– Programación con N versiones

u Redundancia dinámica

– Dos etapas: detección y recuperación de fallos
– Bloques de recuperación

» Proporcionan recuperación hacia atrás

– Excepciones

» Proporcionan recuperación hacia adelante

STRL -30/05/01

©2001 Juan Antonio de la Puente

17

Programación con N versiones

u Diversidad de diseño

– N programas desarrollados independientemente con la misma

especificación

– sin interacciones entre los equipos de desarrollo

u Ejecución 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 votación

STRL -30/05/01

©2001 Juan Antonio de la Puente

18

Programación con N versiones

cordinador

estado

votos

versión 1

versión 2

versión 3

STRL -30/05/01

©2001 Juan Antonio de la Puente

19

Comparación consistente

X1

X2

X3

> x0

sí

> y0

no

no

> x0

> y0

> x0

sí

> y0

sí

V1

V2

V3

u La comparación de valores
reales o texto no es exacta
u Cada versión produce un

resultado correcto, pero
diferente de las otras

u No se arregla comparando con

x0+D

, y0+D

STRL -30/05/01

©2001 Juan Antonio de la Puente

20

Problemas

u La correcta aplicación de este método depende de:

– Especificación inicial

» Un error de especificación aparece en todas las versiones

– Desarrollo independiente

» No debe haber interacción entre los equipos
» No está claro que distintos programadores cometan errores

independientes

– Presupuesto suficiente

» Los costes de desarrollo se multiplican

u ¿sería mejor emplearlos en mejorar una versión única?

» El mantenimiento es también más costoso

u Se ha utilizado en sistemas de aviónica críticos.

STRL -30/05/01

©2001 Juan Antonio de la Puente

21

Redundancia dinámica en software

Cuatro etapas:

1. Detección de errores

» no se puede hacer nada hasta que se detecta un error

2. Evaluación y confinamiento de los daños

» diagnosis: averiguar hasta dónde ha llegado la información errónea

3. Recuperación de errores

» llevar el sistema a un estado correcto, desde el que pueda seguir

funcionando (tal vez con funcionalidad parcial)

4. Reparación 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

Detección de errores

u Por el entorno de ejecución

– hardware (p.ej.. instrucción ilegal)
– núcleo o sistema operativo (p.ej. puntero nulo)

u Por el software de aplicación

– Duplicación (redundancia con dos versiones)
– Comprobaciones de tiempo

» watchdog timer
» deadline checks

– Inversión de funciones
– Códigos detectores de error
– Validación de estado
– Validación estructural

STRL -30/05/01

©2001 Juan Antonio de la Puente

23

Evaluación y confinamiento de daños

u Es importante confinar los daños causados por un fallo a

una parte limitada del sistema (firewalling)

u Se trata de estructurar el sistema de forma que