Fiabilidad y tolerancia a fallos

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)

Informática III Ing. Nora Blet Pág. 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/

http://polaris.dit.upm.es/~jpuente/


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


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


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


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


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.”


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)


Fallos encadenados


Fallos encadenados

Avizinies et.al (2004)


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


Modos de averías de servicio (failure modes) - Avizinies et.al (2004)

Dominio

Valor Tiempo Tiempo y valor

Temprano TardeAvería de contenido

Avería de parada

Avería erráticaAvería de

performance


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


Técnicas para aumentar la fiabilidad


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


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


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


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


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


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


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


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


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


Programación con N versiones

Version 2Version 1 Version 3

Drivervote

status

votevote

statusstatus


Comparación consistenteT3

> Tth

no

P3

> Pth

T1

> Tth

yesP1

> Pth

yes

V1

T2

> Tth

yesP2

no> Pth

V2 V3

Cada versión produce un resultado distinto aunque correcto. No se arregla comparando con Tth, Pth


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


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


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


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


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)


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 sistemaSon 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


Recuperación de erroresEs la etapa más importante Se trata de situar el sistema en un estado correcto desde el que pueda seguir funcionandoSe 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)


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)


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!


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


Efecto dominó

R22

R21

R13

R12

R11

IPC4

IPC3

IPC2

IPC1

Tiem

po d

e ej

ecuc

ión

Terror

P1 P2

Si el error es detectado en P1 rollback a R13

Y si es detectado en P2 ?


Líneas de recuperación


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


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


Esquema de recuperación


Posible sintaxis Puede haber bloques anidados si falla el bloque interior, se restaura

el punto de recuperación del bloque exteriorensure <acceptance test>

by <primary module>else by <alternative module>else by <alternative module> ...else by <alternative module>else error


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 Methodelse by Implicit Kutta Method

else error


Prueba de aceptación Es fundamental para el buen funcionamiento de los bloques de recuperaciónPueden 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


Comparación


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


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


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


Modelo

Actividad Normal Manejador de Excepciones

Vuelta al Servicionormal

Excepción Interna

PeticiónDe Servicio

PeticiónDe Servicio

RespuestaNormal

RespuestaNormal

Excepciónde Interfaz

Excepciónde Fallo

Excepciónde Fallo

Excepciónde Interfaz


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!


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


Aspectos de confiabilidadConfiabilidad

Disponibilidad

disponibilidadde

utilización

Fiabilidad

serviciodisponible

continuamente

Seguridad

no haysituaciones

catastróficas

Confidencialidad

no hay fugasde

informaciónno

autorizadas

Integridad

no hayalteraciones

de información

Mantenibilidad

aptitud para

reparacionesy

cambios


Aspectos de confiabilidad Laprie (1995) incorpora también el concepto de security (protección?) vista en términos de Confidencialidad: divulgación de

información no autorizada Disponibilidad sólo para acciones

autorizadas Integridad: ausencia de alteraciones

del sistema no autorizados


Terminología

Confiabilidad(y security)

Disponibilidad

Confidenciabilidad

Fiabilidad

Seguridad

Integridad

Mantenibilidad Prevención de fallos

Tolerancia a fallos

Reparación de fallos

Predicción de fallos

Fallos

Errores

Averías

Atributos

Medios

Impedimentos

Documents

Fiabilidad y tolerancia a fallos