PDF de programación - Capitulo 5. Fiabilidad, tolerancia a fallos

5

Capítulo 5. Fiabilidad, tolerancia a fallos

5.3.1
5.3.2
5.3.3

5.4.1
5.4.2

Fiabilidad, tolerancia a fallos................................................................................. 2
5.1
Fiabilidad, fallos y defectos. .......................................................................... 2
5.2 Modos de fallo............................................................................................... 3
Prevención de fallos y tolerancia a fallos. ...................................................... 4
5.3
Prevención de fallos............................................................................... 4
Tolerancia de fallos................................................................................ 5
Redundancia. ......................................................................................... 6
Programación N-Versiones. ........................................................................... 6
Comparación de votos............................................................................ 8
Aspectos principales de la programación N-Versiones. .......................... 9
Redundancia de software dinámico................................................................ 9
Detección de errores. ........................................................................... 10
Confinamiento y valoración de daños................................................... 11
Recuperación de errores....................................................................... 12
Tratamiento de los fallos y servicios continuo. ..................................... 12
La estrategia de bloques de recuperación en tolerancia a fallos software. ..... 13
El test de aceptación. ........................................................................... 13

5.5.1
5.5.2
5.5.3
5.5.4

5.6.1

5.4

5.5

5.6

5.8.1

Una comparación entre programación de N-Versiones y bloques de

5.7
recuperación............................................................................................................ 14
Redundancia dinámica y excepciones. ......................................................... 15
5.8
Componentes ideal de un sistema tolerante a fallos. ............................. 16
5.9 Medida y predicción de la fiabilidad del software. ....................................... 16
5.10 Seguridad, fiabilidad y confiabilidad............................................................ 17
5.10.1 Confiabilidad. ...................................................................................... 17



Rafael Álvarez García
Última revisión 01-12-07
[email protected]

Nota importante:
Este documento no pretende reemplazar al material propuesto por la UNED para
la asignatura Sistemas en Tiempo Real. Cualquier sugerencia, comentario o
corrección sobre este documento, envíelo a [email protected] para poder
realizar los cambios necesarios.



1

5 Fiabilidad, tolerancia a fallos.


Los requisitos de fiabilidad y seguridad de los sistemas de tiempo real y embebidos
habitualmente son mucho más estrictos que los de otros sistemas informáticos. Un
computador de control de procesos, por ejemplo, un sistema de navegación aérea debería
posibilitar que el piloto saltase fuera del avión antes de permitir que el avión se estrellara.


A medida que la sociedad siga confiando el control de sus funciones vitales a los
computadores, más necesario será que estos sistemas no fallen. Sin pretender definir de
forma precisa que significa un fallo de un sistema o un defecto, existen, en general, cuatro
causas de defectos que pueden propiciar el fallo de un sistema embebido.

• Especificación inadecuada.

• Defectos provocados por errores de diseño en los componentes de software.

• Defectos provocados por fallos en uno o más componentes del procesador de los

sistemas embebidos.

• Defectos provocados por una interferencia transitoria o permanente en el subsistema

de comunicaciones subyacente.



5.1 Fiabilidad, fallos y defectos.


La fiabilidad es una medida del éxito con el que el sistema se ajusta a alguna

especificación definitiva de su comportamiento.


Cuando el comportamiento de un sistema se desvía del especificado para el, se dice

que es un fallo.


Los fallos son el resultado de problemas internos no esperados que el sistema manifiesta
eventualmente en su comportamiento externo. Estos problemas se llaman errores, y sin
causas mecánicas o algorítmicas se denominan defectos.

Se pueden distinguir tres tipos de faltos.

• Fallos transitorios. Un fallo transitorio comienza en un instante de tiempo concreto,
se mantiene en el sistema durante algún periodo, y luego desaparece. Ejemplos de este
tipo de fallos se dan en componentes hardware en los que se produce una reacción
adversa a una interferencia externa, como la producida por un campo eléctrico o por
radiactividad. Después de que la perturbación desaparece, lo hace también el fallo
(aunque no necesariamente el error inducido). Muchos de los fallos de los sistemas de
comunicación son transitorios.

• Fallos permanentes. Los fallos permanentes comienzan en un instante determinado
y permanecen en el sistema hasta que son reparados; es el caso, por ejemplo, de un
cable roto o de un error de diseño del software.



2

• Fallos intermitentes Son fallos transitorios que ocurren de vez en cuando. Un
ejemplo es un componente hardware sensible al calor, que funciona durante un rato,
deja de funcionar, se enfría, y entonces comienza a funcionar de nuevo.


Para crear sistemas fiables, se deben tener en cuenta todos estos tipos de fallos


5.2 Modos de fallo.


Un sistema proporciona servicios, Resulta posible, por lo tanto, clasificar los modos de
fallo de un sistema de acuerdo con el impacto que tendrán en los servicios que se proporciona.


Se pueden identificar dos dominios generales de modos de fallo:

• Fallos de valor: el valor asociado con el servicio es erróneo.
• Fallos de tiempo: el servicio se completa a destiempo,

Las combinaciones de fallos de valor y de tiempo normalmente se denominan fallos

arbitrarios.


En general, un error de valor podría estar aún dentro del rango correcto de valores, o
podría encontrarse fuera del rango esperado para ese servicio. Esto ultimo equivale a un
error de escritura en los lenguajes de programación, y se denomina error de límites.
Normalmente, estos tipos de fallos se reconocen fácilmente.


Los fallos en el dominio del tiempo pueden hacer que el servicio sea entregado:

• Demasiado pronto: el servicio es entregado antes de lo requerido
• Demasiado tarde: el servicio se entrega después de lo requerido (en estos casos

•

se suele hablar de error de prestaciones).
Infinitamente tarde: el servicio nunca es entregado (en estos casos se suele hablar de un
fallo de omisión).

• Cuando un servicio es entregado sin ser esperado. A este tipo de fallo habitualmente

se le denomina fallo de encargo o improvisación.

Dada la clasificación anterior de los modos de fallo, se pueden realizar algunas

suposiciones sobre el modo en que un sistema puede fallar:

• Fallo descontrolado: un sistema que produce errores arbitrarios, tanto en el domino

del valor como en el del tiempo (incluyendo errores de improvisación).

• Fallo de retraso: un sistema que produce servicios correctos en el dominio del valor,

pero que sufre errores de retraso en el tiempo.

• Fallo de silencio: un sistema que produce servicios correctos tanto en el dominio del
valor como en el del tiempo, hasta que falla. El único fallo posible es un fallo de
omisión, y cuando ocurre todos los servicios siguientes también sufrirán fallos de
omisión.



3

• Fallo de parada: un sistema que tiene todas las propiedades de un fallo silencioso,
pero que permite que otros sistemas puedan detectar que ha entrado en el estado de
fallo de silencio.

• Fallo controlado: un sistema que falla de una forma especificada y controlada.

• Sin fallos: un sistema que siempre produce los servicios correctos, tanto en el

dominio del valor como en el del tiempo.



5.3 Prevención de fallos y tolerancia a fallos.

Se pueden considerar dos formas diferentes de ayudar a los diseñadores a mejorar la
fiabilidad de sus sistemas. La primera es conocida como prevención de fallos, y se
refiere al intento de impedir que cualquier posibilidad de fallo se cuele en el sistema antes de
que este operativo. La segunda se denomina tolerancia a fallos, y hace posible que el
sistema continúe funcionando incluso ante la presencia de fallos. Ambas aproximaciones
intentan producir sistemas con modos de fallo bien definidos.

5.3.1 Prevención de fallos.


Existen dos fases en la prevención de fallos: evitación y eliminación

Con la evitación se intenta limitar la introducción de componentes potencialmente
defectuosos durante la construcción del sistema. En lo que respecta al hardware, esto
puede implicar:


• La utilización de los componentes más fiables dentro de las restricciones de coste y

prestaciones dadas.

• La utilización de técnicas exhaustivamente refinadas para la interconexión de

componentes y el ensamblado de subsistemas.

• El aislamiento del hardware para protegerlo de formas de interferencia

esperadas.


Los componentes software de los grandes sistemas embebidos actualmente son mucho
más complejos que sus correspondientes elementos hardware. Aunque el software no se
deteriora con el tiempo, resulta en cualquier caso virtualmente imposible escribir programas
libres de fallos. Sin