SISTEMAS EN TIEMPO REAL

Fiabilidad y Tolerancia a Fallos en Sistemas en Tiempo Real

Manuel Agustín Ortiz López Área de Arquitectura y Tecnología de Computadores Departamento de Arquitectura de Computadores, Electrónica y Tecnología Electrónica Universidad de Córdoba Córdoba a 17 de enero de 2006

Índice

Fiabilidad y Tolerancia Sistemas en Tiempo Real

a

Fallos

en

• Índice: 1. Introducción 2. Fiabilidad y fallos 2.1. Definiciones y clasificación de los fallos 2.2. Prevención de fallos 2.3. Tolerancia a fallos 2.4. Redundancia

3. Redundancia del software 3.1. Programación de N-versiones 3.2. Estrategia de bloques de recuperación en la tolerancia a fallos software

4. Medición y predicción de la fiabilidad de software

Sistemas en Tiempo Real Manuel Ortiz. Universidad de Córdoba

Página 1

Sistemas en Tiempo Real Manuel Ortiz. Universidad de Córdoba

Página 2

Introducción

1. Introducción • El tema que iniciamos está basado en los trabajos de Anderson y Lee(1990) y en la bibliografía recomendada, la cual a su vez, hace referencia continua a estos trabajos. • Los requisitos de fiabilidad y seguridad de los sistemas de tiempo real son mucho más estrictos que los de un sistema informático de propósito general. Existen tres causas que provocan un fallo un sistema en tiempo real: Errores en una especificación inadecuada. Defectos en alguno de los componentes, tanto componentes hardware como software. Por efectos del entorno.

Sistemas en Tiempo Real Manuel Ortiz. Universidad de Córdoba

Página 3

Sistemas en Tiempo Real Manuel Ortiz. Universidad de Córdoba

Página 4

Fiabilidad y Fallos

2. Fiabilidad y Fallos.[Krisna,96][Burns, 03] 2.1. Definiciones y clasificación de los fallos • Fiabilidad es una medida del éxito de que el sistema se comporta de acuerdo a una especificación. • Fallo. Cuando el comportamiento del sistema se desvía del especificado, se dice que el sistema tiene un fallo. • Las definiciones de fiabilidad y fallo están relacionadas con el comportamiento externo del sistema. Los fallos son el resultado

de

problemas

internos

que

se

manifiestan

externamente. • Un error es la consecuencia de un fallo del sistema y una avería es un efecto del error en un servicio que da el sistema. • Los tipos de fallo se clasifican como: Fallos transitorios. Un fallo transitorio comienza en un instante de tiempo concreto se mantiene durante algún período y luego desaparece. Ejemplo de este tipo de fallos suelen darse en los componentes hardware debidos a alguna interferencia externa y se mantiene mientras se mantiene la interferencia. Muchos de los fallos de los sistemas de comunicaciones son transitorios. Fallos permanentes. Son fallos que comienzan en un instante de tiempo y permanece hasta que se repara el sistema. Fallos intermitentes. Son fallos transitorios que ocurren de vez en cuando. Ejemplo de este tipo de fallos suelen darse en componentes hardware sensibles a la temperatura, cuando se calienta demasiado Sistemas en Tiempo Real Manuel Ortiz. Universidad de Córdoba

Página 5

fallan y cuando se enfrían vuelven a funcionar fallando de nuevo cuando se calientan.

• Independientemente de la clasificación anterior los fallos se suelen clasificar también de acuerdo a su comportamiento temporal (fallos de tiempo) y su comportamiento de acuerdo a las salidas que provocan (fallos de valor). La siguiente figura muestra como se clasifican estos modos de fallo:

• Con la clasificación anterior un sistema puede fallar, en el dominio del tiempo, de la siguiente manera: Fallo descontrolado. El sistema produce errores descontrolados tanto en el dominio de valor como del tiempo, incluido los fallos de improvisación. Fallo de retraso. El sistema produce servicios correctos en el dominio de valor, pero sufre errores de retraso en el tiempo. Fallo de silencio. El sistema deja de producir servicios debidos a fallos de omisión provocando en el resto del sistema fallos de omisión. Sistemas en Tiempo Real Manuel Ortiz. Universidad de Córdoba

Página 6

Fallo de parada. Similar al fallos de silencio pero informa a otros sistemas que tiene fallo de silencio. Fallo controlado. El sistema falla según una forma especificada. Sin fallos. El sistema produce servicios correctos tanto en el dominio del valor como del tiempo.

Sistemas en Tiempo Real Manuel Ortiz. Universidad de Córdoba

Página 7

2.2. Prevención de fallos • La prevención de fallos se refiere al intento de impedir cualquier posibilidad de fallo antes de que el sistema esté operativo. Para ello es necesario evitar y eliminar los fallos durante la etapa de diseño. Para evitar los fallos se actúa tanto en el hardware como en el software. • Hardware: Utilización de los componentes más fiables dentro de las restricciones de coste/prestaciones. Utilización de técnicas refinadas para la interconexión y ensamblado de componentes. Aislamiento del hardware para evitar interferencias.

• Software: Especificaciones de requisitos rigurosas e incluso formales. Utilización de probadas metodologías de diseño. Utilización de lenguajes que faciliten la abstracción de datos y la modularidad. Uso de herramientas de ingeniería de software

para ayuda a la

manipulación de los componentes software.

• La segunda parte en la prevención de fallos consiste en su intento de eliminación, para ello el sistema se somete a un conjunto de pruebas lo más exhaustivas posibles.

Sistemas en Tiempo Real Manuel Ortiz. Universidad de Córdoba

Página 8

2.3. Tolerancia a Fallos • A pesar de todas las técnicas y pruebas de verificación los componentes hardware y software pueden fallar, y dado que muchas veces no es posible su mantenimiento y reparación se hace necesario recurrir a la idea de tolerancia a fallos. • Un sistema puede proporcionar distintos niveles de tolerancia a fallos: Tolerancia total frente a fallos. El sistema continua en presencia de fallos sin una pérdida significativa de funcionalidad o de prestaciones, aunque por un período limitado. Degradación controlada. El sistema continua en operación en presencia de errores, aunque con una funcionalidad parcial durante la reparación. Fallo seguro. El sistema cuida de su integridad durante el fallo aceptando una parada temporal de su funcionamiento.

• El nivel de tolerancia de un sistema dependerá de la aplicación, y aunque teóricamente los sistemas críticos deben tener tolerancia total frente a fallos, la realidad es que la mayoría admiten una degradación controlada. • La tolerancia a fallos consta de cuatro fases: Detección de errores Confinamiento y valoración de los daños Recuperación del error Tratamiento del fallo y continuación del servicio Sistemas en Tiempo Real Manuel Ortiz. Universidad de Córdoba

Página 9

• Detección de errores. Se pueden identificar dos clases técnicas de detección de errores: Detección por el entorno de ejecución del programa: Detectados por el hardware próximo al procesador. Por ejemplo , “la detección de una instrucción ilegal”, “salto a una dirección inválida”, ”violación de la protección”, etc. Detectados por el sistema soporte del lenguaje de programación de tiempo real. Por ejemplo “referencia a un apuntador nulo”, “valor fuera de rango”, etc. Detección por la aplicación. Los errores los detecta la propia aplicación: Comprobación de réplicas, como la programación de N-versiones que se verá posteriormente. Comprobaciones temporales. Por ejemplo a través del “watch-dog timer”. El componente software debe resetear el contador antes de que se desborde de forma continúa indicando así que funciona de forma “correcta”. Estas comprobaciones temporales no aseguran que esté funcionando correctamente desde el punto de vista lógico pero si al menos “funciona a tiempo”. Comprobaciones inversas. En aquellos componentes que tengan una relación uno a uno con la salidas, se puede tomar la salida y calcular la entrada que corresponde a esta salida y comprobarla con la entrada del sistema. Códigos de comprobación. Se utilizan sobre todo para comprobar la integridad de los datos. Es lo que habitualmente llamamos ”CheckSum”. Sistemas en Tiempo Real Manuel Ortiz. Universidad de Córdoba

Página 10

Comprobaciones estructurales. Se utilizan para comprobar la integridad de los objetos como listas o colas. En este caso se trata de comprobar si por ejemplo los punteros no está corruptos, o comprobar si el número de elementos del objeto es el correcto.

• Confinamiento y valoración de los daños. Cuando ocurre un error en un componente, este error puede transmitir una información errónea a todo el sistema. Se trata de construir cortafuegos para evitar la propagación del error. • Recuperación del error. Una vez detectado el fallo y valorado el daño que haya podido producir hay que recuperar el error. Existe dos estrategias para la recuperación: recuperación hacia delante y recuperación hacia atrás. Ejemplos de la recuperación hacia delante son los códigos autocorrectores como el código Hamming o la utilización de punteros redundantes en las listas enlazadas. Un ejemplo de recuperación hacia atrás es la estrategia de bloques de recuperación que se tratará más adelante en este tema. • Tratamiento del fallo y continuación del servicio. Aunque se haya localizado el problema y recuperado el error, puede que el fallo se vuelva a producir. El tratamiento de los fallos se divide en dos fases: la localización del fallo y la recuperación del sistema. En el caso del hardware puede bastar con cambiar el componente, en el caso del software puede que baste con instalar una nueva versión del software. Sin embargo existen sistemas que no pueden parar y el programa deberá ser Sistemas en Tiempo Real Manuel Ortiz. Universidad de Córdoba

Página 11

modificado mientras se está ejecutando, este es un problema bastante complejo que no estudiaremos en este tema.

Sistemas en Tiempo Real Manuel Ortiz. Universidad de Córdoba

Página 12

2.4. Redundancia • Todas las técnicas que se utilizan para conseguir la tolerancia a fallos se basan en añadir elementos redundantes que detecten y recuperen los fallos. Estos elementos son innecesarios en el funcionamiento normal del sistema, por lo que se trata de minimizar la redundancia y maximizar la fiabilidad dentro de los costes y tamaño del sistema. • Existen varias clasificaciones de redundancia dependiendo de los elementos hardware o software considerados y de la terminología

utilizada.

A

continuación

repasaremos

brevemente la redundancia hardware dejando la redundancia software para los siguientes capítulos. Redundancia hardware • En el caso de los elementos hardware, se distingue entre la redundancia estática o enmascarada y la redundancia dinámica. En el caso de la redundancia estática, los componentes se utilizan dentro de un sistema para ocultar los efectos de los fallos. Un ejemplo es la redundancia triple modular TMR (caso particular de la N-modular redundancy en el que N=3). La TMR consiste en tener tres componentes idénticos y unos circuitos que comparan continuamente la salida y en el caso de que alguna difiera de las otras dos, se bloquea la salida.

Sistemas en Tiempo Real Manuel Ortiz. Universidad de Córdoba

Página 13

En el caso de la redundancia dinámica es el mismo componente el que indica si la salida es errónea. El sistema debe tener la capacidad de detección de errores y debe ser otro sistema el que realice la recuperación del error. Un ejemplo de ello es el detector de paridad en el caso de memoria DRAM.

Sistemas en Tiempo Real Manuel Ortiz. Universidad de Córdoba

Página 14

Redundancia del software

3. Redundancia del software.[Krisna, 96][Burns, 03] • La realización de software tolerante a fallos está emergiendo actualmente y está en su fase inicial. Dado que el software no se degrada, la tolerancia a fallos en el software está basada en la búsqueda de errores de diseño. Como es sabido es imposible escribir un programa largo sin cometer errores. La práctica indica que la tasa de fallos software es mayor que la tasa de fallos hardware en un aplicación compleja. • La redundancia en software en la búsqueda de errores de diseño tiene dos enfoques distintos. Uno de ellos es similar a la redundancia

enmascarada

del

hardware

denominada

programación de N-versiones y el otro se basa en la detección y recuperación de errores que es análogo a la redundancia dinámica del hardware en el sentido de que se activan los procedimientos de recuperación después de que se ha detectado el error.

Sistemas en Tiempo Real Manuel Ortiz. Universidad de Córdoba

Página 15

Redundancia del software

3.1. Programación de N-versiones • La programación de N-versiones se basa en la generación independiente de N programas funcionalmente equivalentes. Una vez diseñados los programas se ejecutan de forma independiente

y un programa director va comparando los

resultados. • En la programación de N-versiones se supone que se ha podido especificar completamente y sin ambigüedad una aplicación y que los programas se han escrito independientemente y por tanto deben fallar de forma independiente. Esta suposición supone que se deben utilizar lenguajes y entornos diferentes para evitar errores debidos a la implementación el lenguaje. Si se utiliza el mismo lenguaje deben utilizarse compiladores y procesadores de distintos fabricantes. Por ejemplo para el boeing 777 se escribió un único programa en ADA pero se utilizaron tres compiladores y procesadores distintos.

Sistemas en Tiempo Real Manuel Ortiz. Universidad de Córdoba

Página 16

Redundancia del software

Cada versión realiza el calculo y comunica la programa director el resultado (voto). El programa director comunica el estatus de la comparación a cada versión en función del resultado de la comparación o de si han sido entregados a tiempo. Los posibles resultados suelen ser: Continuación; terminación de una o más versiones, continuación después de modificar uno o más votos respecto al valor de la mayoría.

Comparación de votos • Es crucial en la programación de N–versiones la eficacia y la facilidad con que el programa director compara los votos. En algunas aplicaciones donde los resultados del procesamiento de cada versión son exactos, el programa director puede comparar fácilmente

el

resultado

y

Sistemas en Tiempo Real Manuel Ortiz. Universidad de Córdoba

Página 17

tomar

una

decisión.

Redundancia del software

Desafortunadamente en la mayoría de las aplicaciones dicha comparación no resulta tan fácil. Para ahondar en este aspecto de la comparación de votos se puede consultar la bibliografía recomendada y los trabajos de Anderson y Lee del año 1990.

Sistemas en Tiempo Real Manuel Ortiz. Universidad de Córdoba

Página 18

Redundancia del software

3.2. Estrategia de bloques de recuperación en la tolerancia a fallos software • La programación N-versiones se le considera el equivalente software a la redundancia estática en hardware ya que cada versión tiene una relación fija con el director y siempre entra en funcionamiento se hayan producidos fallos o no. En el caso de la redundancia dinámica los componentes redundantes solo entran en funcionamiento cuando se ha detectado un error • Cabe decir que la estrategia de bloques de recuperación no está implementada en ningún lenguaje de programación comercial solo se han desarrollado algunos sistemas experimentales. • Los bloques de recuperación (propuestos por Horning et al., 1974) son bloques en el sentido habitual de los lenguajes de programación, excepto

que en la entrada del bloque se

encuentra un punto de recuperación automático, y en la salida se encuentra un test de aceptación. • El test de aceptación se utiliza para comprobar que el sistema se encuentra dentro de un estado aceptable después de la ejecución del bloque. Si el test de aceptación falla, provoca que el programa sea restaurado al punto de recuperación del principio del bloque y se ejecuta otro módulo alternativo. Si de nuevo falla el test de aceptación se ejecuta de nuevo otro módulo y así alternativamente. Si falla todos los módulos entonces el bloque falla. La siguiente figura muestra Sistemas en Tiempo Real Manuel Ortiz. Universidad de Córdoba

Página 19

Redundancia del software

esquemáticamente

como

funcionan

los

bloques

de

recuperación:

Test de aceptación • El test de aceptación es crucial en la técnica de bloques de recuperación ya que proporciona el mecanismo para la detección de errores. Este test no debe sobrecargar al sistema para que no influya en el rendimiento libre de errores del sistema.

Sistemas en Tiempo Real Manuel Ortiz. Universidad de Córdoba

Página 20

Medición y predicción de la fiabilidad de software

4. Medición y predicción de la fiabilidad de software. [Burns, 03] • La fiabilidad del software se considera como la probabilidad de que un programa funcione correctamente en un entorno concreto y durante un periodo de tiempo. Se han propuesto varios modelos para estimar la fiabilidad y calidad del software, los cuales se pueden clasificar en: Modelos de crecimiento de la fiabilidad del software. Estos modelos intentan predecir la fiabilidad de un programa basándose en su historial de errores Modelos estadísticos. Estiman la fiabilidad del software mediante la respuesta exitosa o fallida en determinados casos de prueba aleatorios.

Sistemas en Tiempo Real Manuel Ortiz. Universidad de Córdoba

Página 21