Fiabilidad y tolerancia a fallos

1
Fiabilidad y tolerancia a fallos

• Informática III

There are two ways of producing error-free
software. But only the third will work ...
(Unknown author)
2
Bibliografía

• Alan Burns, Andy J. Wellings "Sistemas de Tiempo
  Real y Lenguajes de Programación", Addison-Wesley
  (3º edición) cap. 5
• Transparencias de Juan Antonio de la Puente
  http//polaris.dit.upm.es/jpuente/

3
Características de un STR

• Grandes y complejos
• Concurrencia/distribución
• Interacción con interfaces hardware
• Extremadamente fiable y seguro
• Implementación eficiente
• Funcionalidades de tiempo real
• Manipulación de números reales

4
Objetivos

• Entender los factores que afectan la fiabilidad
  de un sistema
• Introducir técnicas para tolerar fallos de
  software

5
Indice

• Fiabilidad, averías y fallos
• Modos de fallo
• Prevención y tolerancia de fallos
• Redundancia estática y dinámica
• Programación con N versiones
• Bloques de recuperación
• Redundancia dinámica y excepciones

6
Fallos de funcionamiento

• 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
• Nos centraremos en el estudio de los errores de
  software

7
Conceptos básicos

• Randell et al. (1978) define fiabilidad
  (reliability) como
• ... Una medida del éxito con que el sistema se
  ajusta a alguna especificación definitiva de su
  comportamiento.

8
Conceptos básicos

• Una avería (failure) es una desviación del
  comportamiento de un sistema respecto de su
  especificación
• Las averías se manifiestan en el comportamiento
  externo del sistema, pero son el resultado de
  errores (errors) internos
• Las causas mecánicas o algorítmicas (declaradas
  o hipotéticas) de los errores se llaman fallos
  (faults)

9
Fallos encadenados
10
Fallos encadenados
Avizinies et.al (2004)
11
Tipos de Fallo

• Fallos transitorios
• desaparecen solos al cabo de un tiempo
• ejemplo interferencias en comunicaciones
• Fallos permanentes
• permanecen hasta que se reparan
• ejemplo roturas de hardware, errores de diseño
  de software
• 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

12
Modos de averías de servicio (failure modes) -
Avizinies et.al (2004)
Dominio
Tiempo y valor
Valor
Tiempo
Temprano
Tarde
Avería de contenido
Avería de parada
Avería de performance
Avería errática
13
Mejoras en la Fiabilidad

• Hay dos técnicas complementarias para 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 a Fallos
• Se trata de conseguir que el sistema continúe
  funcionando aunque se produzcan fallos
• En ambos casos el objetivo es desarrollar
  sistemas con tipos de averías bien definidos

14
Técnicas para aumentar la fiabilidad
15
Prevención de Fallos

• Se realiza en dos etapas
• Evitación
• Se intenta acotar la introducción de componentes
  (hardware y software ) potencialmente defectuosos
  durante la construcción del sistema
• A pesar de utilizar técnicas para evitar fallos,
  éstos se encontrarán inevitablemente en el
  sistema una vez construido. En concreto, pueden
  existir errores de diseño en los componentes.
• Eliminación
• Consiste en encontrar y eliminar los fallos que
  se producen en el sistema una vez construido

16
Hardware

• Utilización de componentes mas confiables
• Empleo de técnicas refinadas para la
  interconexión y ensamblado de subsistemas
• Aislamiento de interferencias externas

17
Software

• Especificaciones rigurosas/formales
• Metodologías de diseño comprobadas
• Uso de herramientas con abstracción,
  encapsulamiento y modularidad
• Uso de herramientas de ingeniería de software
  para ayudar en la manipulación de los componentes
  software y en la gestión de la complejidad

18
Técnicas de Eliminación de Fallos

• Comprobaciones
• Revisión de diseño
• Verificación de programas
• Inspección de código
• Prueba (test)
• Son necesarias, pero tienen problemas
• Nunca pueden ser exhaustivas
• Sólo se pueden utilizar para demostrar la
  presencia de fallos, no su ausencia
• A menudo resulta imposible realizarlas bajo
  condiciones reales ? simulación
• Los errores de especificación no se detectan

19
Limitaciones de la prevención de fallos

• Los componentes de hardware pueden fallar
• La prevención resulta insuficiente si
• la frecuencia o la duración de las reparaciones
  es inaceptable
• no se puede detener el sistema para efectuar
  operaciones de mantenimiento. Ejemplo naves
  espaciales no tripuladas
• La alternativa es utilizar técnicas de tolerancia
  a fallos

20
Niveles de tolerancia a fallos

• Un sistema puede proveer tres niveles
• Tolerancia total de fallos (Fail operational)
• El sistema sigue funcionando, al menos durante un
  tiempo, sin perder funcionalidad ni prestaciones
• Degradación controlada (Graceful Degradation,
  fail soft)
• El sistema sigue funcionando con una pérdida
  parcial de funcionalidad o prestaciones hasta la
  reparación del fallo
• Parada segura (Fail Safe)
• El sistema cuida de su integridad durante el
  fallo aceptando una parada temporal de su
  funcionamiento
• El grado de tolerancia de fallos necesario
  depende de la aplicación

21
Redundancia

• La tolerancia de fallos se basa en la
  redundancia
• Se utilizan componentes adicionales para
  detectar los fallos y recuperar el comportamiento
  correcto
• Esto aumenta la complejidad del sistema y puede
  introducir fallos adicionales
• Resulta aconsejable separar los componentes
  tolerantes a fallos del resto del sistema

22
Tolerancia a fallos de software

• Técnicas para detectar y corregir errores de
  diseño
• Redundancia estática (enmascaramiento)
• Programación con N versiones
• Redundancia dinámica
• Dos etapas detección y recuperación de errores
• Bloques de recuperación
• Proporcionan recuperación hacia atrás
• Excepciones

23
Programación con N versiones

• Diversidad de diseño
• N (Ngt1) programas desarrollados
  independientemente con la misma especificación
• sin interacciones entre los equipos de desarrollo
• 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

24
Programación con N versiones
status
status
status
vote
vote
vote
Driver
25
Comparación consistente
Cada versión produce un resultado distinto aunque
correcto. No se arregla comparando con Tth??, Pth
??
V1
V3
26
Problemas

• La aplicación correcta de este método depende
  de
• Especificación inicial
• Un error de especificación se manifestará en
  todas las N versiones de la implementación

27
Problemas

• Independencia en el diseño
• No está claro que distintos programadores cometan
  errores independientes
• Presupuesto suficiente
• Los costes de desarrollo se multiplican
• sería mejor emplearlos en mejorar una versión
  única?
• El mantenimiento es también más costoso

28
Resumen

• Se ha utilizado en sistemas de aviónica críticos
• Cuando el algoritmo de votación está
  implementado correctamente constituye un marco de
  trabajo simple y atractivo para obtener
  tolerancia a fallos

29
Redundancia dinámica en software

• Cuatro etapas (dos pasivas y dos activas)
• Detección de errores
• no se puede hacer nada hasta detectar un error
• una falla no puede ser detectada directamente por
  el sistema mientras que su manifestación generará
  errores
• Valoración y confinamiento de los daños
• diagnosis averiguar hasta dónde ha llegado la
  información errónea
• Recuperación de errores
• llevar el sistema a un estado correcto, desde el
  que pueda seguir funcionando (tal vez con
  funcionalidad parcial)
• Reparación de fallos
• Aunque el sistema funcione, el fallo puede
  persistir y hay que repararlo

30
Técnicas de detección de errores

• Por el entorno de ejecución
• Por el hardware (Ej. desbordamiento aritmético)
• núcleo o sistema operativo (Ej. puntero nulo)
• Por el software de aplicación
• Comprobación de réplicas (programación con
  N-versiones)
• Comprobaciones de tiempo
• Temporizador guardián (watchdog timer)
• deadline checks
• Inversión de funciones
• Códigos detectores de error (checksum)
• Validación de estado (aserciones)
• Validación estructural (cuenta de elementos de
  listas)

31
Valoración y confinamiento de daños

• Es importante confinar los daños causados por un
  fallo a una parte limitada del sistema
  (firewalling)
• Las técnicas de valoración están estrechamente
  relacionadas con las técnicas de confimiento
  usadas, se parte de una estima inicial del daño
  anticipado de antemano por el diseñador del
  sistema
• Son difíciles de implementar, las mecanismos que
  son importantes para ello son aquéllos que tratan
  de estructurar el sistema de forma que se
  minimice el daño causado por los componentes
  defectuosos (compartimentos estancos, firewalls),
  poniendo restricciones al flujo de información
  del sistema
• Técnicas
• Descomposición modular
• Acciones atómicas

32
Recuperación de errores

• Es la etapa más importante
• Se trata de situar el sistema en un estado
  correcto desde el que pueda seguir funcionando
• Se han propuesto dos estrategias
• Hacia delante (forward) continuación desde el
  estado erróneo con correcciones selectivas
• Hacia atrás (backward) Se basa en restaurar el
  sistema a un estado seguro previo a la aparición
  del error y ejecutar una secuencia alternativa.
  El estado seguro se llama punto de recuperación
  (checkpoint)

33
Recuperación hacia adelante

• La forma de hacerla es específica para cada
  sistema
• Depende de una predicción correcta de los
  posibles fallos y de su situación (valoración de
  daños)
• Ejemplos de técnicas
• punteros redundantes en estructuras de datos
• códigos autocorrectores (Ej. código de Hamming)

34
Recuperación hacia atrás

• Consiste en retroceder a un estado anterior
  correcto y ejecutar un segmento de programa
  alternativo (con otro algoritmo, igual
  funcionalidad)
• El punto al que se retrocede se llama punto de
  recuperación (checkpoint)
• La acción de guardar el estado se llama
  chekpointing
• No es necesario averiguar la causa ni la
  situación del fallo
• Sirve para fallos imprevistos (Ej. errores de
  diseño)
• Pero no puede deshacer los errores que aparecen
  en el sistema controlado!

35
Efecto dominó

• Cuando hay tareas concurrentes la recuperación
  hacia atrás se complica
• Los puntos de recuperación deben ser diseñados
  consistentemente, de forma que un error detectado
  en uno de los procesos no produzca que todos los
  procesos con los que interactúa sean revertidos
• En lugar de esto, los procesos pueden ser
  reiniciados desde un conjunto consistente de
  puntos de recuperación (líneas de recuperación)
  para todos ellos

36
Efecto dominó
P1
P2
R11
Si el error es detectado en P1 rollback a R13 Y
si es detectado en P2 ?
IPC1
R21
IPC2
R12
Tiempo de ejecución
IPC3
R22
IPC4
R13
Terror
37
Líneas de recuperación
38
Reparación de fallos

• La reparación automática es difícil y depende
  del sistema concreto
• Hay dos etapas
• Localización del fallo
• Las técnicas de detección de errores pueden
  ayudar a realizar un seguimiento del fallo de un
  componente
• Reparación del sistema
• Los componentes de hardware se pueden cambiar
• Los componentes de software se reparan haciendo
  una nueva versión
• En algunos casos puede ser necesario reemplazar
  el componente defectuoso sin detener el sistema

39
Bloques de recuperación

• Es una técnica de recuperación hacia atrás
  integrada en el lenguaje de programación
• Son bloques en el sentido normal de los
  lenguajes de programación pero,
• su entrada es un punto de recuperación
• a su salida se efectúa una prueba de aceptación
• sirve para comprobar si el módulo primario del
  bloque termina en un estado aceptable
• si la prueba de aceptación falla,
• se restaura el estado inicial en el punto de
  recuperación
• se ejecuta un módulo alternativo del mismo bloque
• si vuelve a fallar, se siguen intentando
  alternativas
• cuando no quedan más, el bloque falla y hay que
  intentar al recuperación en un nivel más alto

40
Esquema de recuperación
41
Posible sintaxis

• Puede haber bloques anidados
• si falla el bloque interior, se restaura el punto
  de recuperación del bloque exterior

ensure ltacceptance testgt by ltprimary
modulegt else by ltalternative modulegt else by
ltalternative modulegt ... else by
ltalternative modulegt else error
42
Ejemplo ecuación diferencial

• El método explícito es más rápido, pero no es
  adecuado para algunos tipos de ecuaciones
• El método implícito sirve para todas las
  ecuaciones, pero es más lento
• Este esquema sirve para todos los casos
• Puede tolerar fallos de programación (test
  general)

ensure Rounding_err_has_acceptable_tolerance by
Explicit Kutta Method else by Implicit
Kutta Method else error
43
Prueba de aceptación

• Es fundamental para el buen funcionamiento de
  los bloques de recuperación
• Pueden usarse algunas de las técnicas de
  detección de error vistas
• Hay que buscar un compromiso entre detección
  exhaustiva de fallos y eficiencia de ejecución
  (normal)
• Se trata de asegurar que el resultado es
  aceptable, no forzosamente correcto
• lo que permite que un componente pueda
  proporcionar un servicio degradado
• Si es defectuoso pueden quedar errores
  residuales sin detectar o resultados aceptables
  resultar rechazados

44
Comparación
45
Excepciones y redundancia dinámica

• Son ocurrencias concretas de un error
• Cuando un componente detecta un error debe
  señalarlo al invocador lanzando (raise, signal,
  throw) una excepción
• La respuesta del invocador se denomina gestión
  (manejo, captura) de la excepción

46
Excepciones

• La gestión de excepciones se puede considerar
  como un mecanismo de recuperación hacia delante
• Sin embargo, también se pueden utilizar para
  proporcionar una recuperación de errores hacia
  atrás

47
Modelo
Actividad Normal
Manejador de Excepciones