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 • Seguridad, fiabilidad y confiabilidad

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 (N>1) 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. Version 2 Version 1 Version 3 Programación con N versiones status status status vote vote vote Driver

25. T1 T2 T3 no > Tth > Tth > Tth yes yes P1 P2 P3 no > Pth > Pth > Pth yes V2 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 correcto • 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 <acceptance test> • by • <primary module> • else by • <alternative module> • else by • <alternative module> • ... • else by • <alternative module> • 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. Excepciones • Las excepciones y su gestión pueden utilizarse para: • Enfrentarse a condiciones anormales que surgen en el entorno (propósito original) • Tolerar fallos en el diseño del programa • Proporcionar unas capacidades de propósito general para la detección de errores y la recuperación

48. Excepción de Interfaz Excepción de Fallo Petición De Servicio Respuesta Normal Vuelta al Servicio normal Excepción Interna Petición De Servicio Respuesta Normal Excepción de Interfaz Excepción de Fallo Modelo Actividad Normal Manejador de Excepciones

49. Seguridad y fiabilidad • Un sistema es seguro si no se pueden producir situaciones que puedan causar muertes, heridas, enfermedades, ni daños en los equipos ni en el ambiente • Un accidente (mishap) es un suceso (o una serie de sucesos) imprevisto que puede producir daños inadmisibles • La fiabilidad es la probabilidad de que un sistema se comporte de acuerdo con su especificación • La seguridad (safety) es la probabilidad de que no ocurra ningún suceso que provoque un accidente • ¡Seguridad y fiabilidad pueden estar en conflicto!

50. Confiabilidad • La confiabilidad (dependability) es una propiedad de los sistemas que permite confiar justificadamente en el servicio que proporcionan • Tiene varios aspectos (Laprie, 1995) • Puede describirse en relación con 3 componentes • Impedimentos • Mecanismos • Atributos