Tema 02 – Tolerancia a Fallos

Diferencia entre los conceptos: Fiabilidad, Fallos, Errores y Defectos

▪ Fiabilidad: es la medida del éxito con la que el sistema se ajusta a alguna especificación
definitiva de su comportamiento.

▪ Errores: son la manifestación externa de un problema interno del sistema. Suceden cuando
el comportamiento del sistema no se ajusta a la especificación dada.

▪ Fallos o Defectos: son las causas (mecánicas, algorítmicas o eléctricas) por las que se
producen un error.

Los sistemas están formados generalmente por componentes que son, a su vez, otros sistemas.

Tipos de fallos que se pueden producir

▪ Transitorios: son fallos que se produce sólo durante un intervalo de tiempo (Ejemplo: fallo
en componentes hardware debidos a interferencias de elementos externos).

▪ Permanentes: son fallos que comienzan en un instante de tiempo y permanecen en el

sistema hasta que son reparados (Ejemplo: cable roto, error en el diseño del software, etc.).

▪ Intermitentes: son fallos transitorios que ocurren de vez en cuando (Ejemplo: fallo que se
produce en un componente ante ciertas circunstancias periódicas).

¿Cuándo se puede considerar a un fallo dentro del dominio del tiempo o del valor?
Un sistema proporciona servicios, y, por tanto, puede fallar de varias maneras diferentes. Debido a
ello, podemos clasificar los modos de fallo de un sistema de acuerdo al impacto que tendrá en los
servicios que proporciona, identificando los dominios generales de fallos siguientes:

▪ Fallos de Valor: el valor asociado con el servicio es erróneo. Los fallos de valor pueden derivar
en un error de límites, ya que podría estar aún dentro del rango correcto de valores, o fuera
de ese rango esperado para ese servicio.

▪ Fallos de Tiempo: el servicio se completa a destiempo. Se puede dar el caso que el servicio
sea entregado:

➢ Demasiado pronto (adelantado): el servicio se entrega antes de lo requerido.

➢ Demasiado tarde (retraso): el servicio se entrega después de lo requerido (deriva en

un error de prestaciones).

➢ Infinitamente tarde (omisión): el servicio nunca es entregado (deriva en un fallo de

omisión).

▪ Arbitrarios: son fallos incontrolados, siendo estos una combinación de los fallos de valor y
los fallos de tiempo.
¿Como se pueden prevenir los fallos?
La prevención de fallos tiene como objetivo eliminar cualquier posibilidad de ocurrencia de fallos
antes de que el sistema entre en funcionamiento.

En contraparte, la tolerancia a fallos permite que un sistema siga funcionando, aunque exista
presencia de fallos.

Ambos enfoques pretenden producir sistemas fiables con modos de fallo bien definidos. En la
prevención de fallos existen dos fases:

▪ Evitación: intenta limitar la introducción de componentes potencialmente defectuosos

durante la construcción del sistema, y para conseguirlo, se realiza:

➢ Utilización de los componentes más fiables dentro de las restricciones de coste y

prestaciones dadas.

➢ Utilización de técnicas exhaustivamente refinadas para la interconexión de

componentes y el ensamblado de subsistemas.

➢ Aislamiento del hardware para protegerlo frente a interferencias.

➢ Especificación de requerimientos rigurosos y si no, formales.

➢ Utilización de metodologías de diseño que hayan sido probadas.

➢ Utilización de lenguajes que faciliten la abstracción de datos 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.

▪ Eliminación: consiste en procedimientos para encontrar y eliminar las causas de los errores.

Los fallos que no puedan prevenirse, ¿cómo puede proporcionar el sistema tolerancia a estos?
El sistema debe reconfigurarse, habitualmente haciendo funcionar algún tipo de componente
redundante que pueda sustituir al componente causante del fallo, por lo que debe conseguirse que
el sistema sea tolerante a fallos.

Para conseguir dicha tolerancia, se suele recurrir a los enfoques:

▪ Redundancia Dinámica del Software (Bloques de Recuperación)

▪ Redundancia Estática del Software (Programación de N-Versiones).

Tolerancia a Fallos
Con la tolerancia a fallos se permite que un sistema siga funcionando incluso ante la presencia de
fallos. Existen los siguientes niveles de tolerancia a fallos:

▪ Tolerancia Total: el sistema continúa operativo durante un tiempo limitado ante la presencia
de fallos sin que éste tenga una pérdida significativa de funcionalidad o prestaciones.

▪ Degradación Controlada: el sistema continúa operativo ante la presencia de fallos donde,

además, se acepta una degradación parcial de la funcionalidad o de las prestaciones hasta
que se produzca la recuperación o reparación.
 ▪ Fallo Seguro: el sistema cuida de su integridad durante el fallo aceptando una parada
temporal de su funcionamiento.

El nivel requerido en cada caso dependerá de la aplicación. Los sistemas más críticos si exigirán una
tolerancia total frente a fallos.

Un bloque de recuperación es un bloque software, siendo una forma de redundancia dinámica. En

su entrada hay un punto de recuperación automática, y a la salida un test de aceptación. Estos
bloques se pueden anidar. Son empleados en la técnica de recuperación de errores hacia atrás.

Tolerancia a fallos: Enfoque de la programación de N-Versiones

Un esquema de programación de N-versiones consta de N programas y un mecanismo de votación.
A diferencia del enfoque de bloques de recuperación, todos los N programas alternativos se ejecutan
simultáneamente, y sus resultados se envían a un mecanismo de decisión (director) que selecciona
el resultado final.

Cuando al comparar los votos se producen resultados diferentes, se usan técnicas de votación
inexacta.

a) Suposición en la que se basa y ¿qué hay que realizar para que sea cierta y cuándo deja de
ser válida?
Se basa en la suposición de que se puede especificar completamente un programa de forma
consistente y sin ambigüedad, y que, los programas que han sido desarrollados
independientemente, fallarán de forma independiente (no existe relación entre los fallos de
una versión y los fallos de otra).

Esta suposición deja de ser válida si cada versión ha sido escrita en el mismo lenguaje de
programación, ya que los errores asociados con la implementación del lenguaje son comunes
a las distintas versiones.

Consecuentemente, se deben utilizar lenguajes y entornos de programación diferentes. Si se

utiliza el mismo lenguaje, los compiladores y los entornos utilizados deberían ser de distintos
fabricantes.

b) ¿De qué es responsable el Proceso Director (Driver Process)?

El Proceso Director controla al programa N-Versiones, y es responsable de:

▪ Invocar a cada una de las versiones

▪ Esperar a que las versiones realicen su trabajo
▪ Comparar los resultados y actuar basándose en los mismos

c) ¿Qué se entiende por Votación Inexacta (Inexact Voting)? ¿Como se puede resolver? ¿En
qué consiste el problema de la Comparación Consistente (Consistent Comparison)?
La Votación Inexacta son técnicas utilizadas en la comparación de los tipos de resultados que
producen diferentes versiones. Una técnica simple es acabar comprobando un rango,
utilizando una estimación previa o un valor medio de los N resultados, aunque, aun así,
puede ser difícil encontrar un enfoque general para la votación inexacta.

El problema de la Comparación Consistente se da cuando una aplicación tiene que realizar

una comparación basada en un valor finito dado en la especificación. El resultado de la
comparación es quien determina entonces el curso de la acción.
 d) Explicar los factores o aspectos principales del éxito de la programación de las N-versiones.

▪ Especificación Inicial
La mayoría de fallos en el software provienen de una especificación inadecuada.
Resulta evidente que un error de especificación se manifestará en todas las N
versiones de la implementación.

▪ Independencia en el Diseño
La aplicación rigurosa del paradigma de la programación de N-Versiones conduce a la
eliminación de todos los errores encontrados antes de la aceptación del sistema.

▪ Presupuesto adecuado
En la mayoría de sistemas embebidos, el principal coste se debe al software, por lo
que un sistema de tres versiones triplicaría el presupuesto, así como causará
problemas de rendimiento.

En un entorno competitivo, es raro que un cliente potencial proponga la técnica de la

programación de N-Versiones (a menos que sea obligatorio).

Tolerancia a fallos: Enfoque mediante Redundancia Dinámica de Software

Con la redundancia dinámica, los componentes redundantes sólo entran en juego cuando se ha
detectado un error.

Dispone de 4 fases constituyentes: (1) Detección de errores, (2) Confinamiento y valoración de

daños, (3) Recuperación del error y (4) Tratamiento del fallo y continuación del servicio.

a) Diferencia entre la detección de los errores por el entorno y por la aplicación.

La mayoría de errores se manifestarían bajo la forma de un error, de modo que no se utilizará
ningún esquema de tolerancia de fallos hasta que se haya detectado un error. Se identifican
dos clases de técnicas:

▪ Detección en el Entorno
Los errores se detectan en el entorno en el cual se ejecuta el programa, entre los que
se incluyen:
➢ Los detectados por el hardware.
➢ Los detectados en tiempo de ejecución por el sistema soporte del lenguaje de
programación de tiempo real.

▪ Detección en la Aplicación
Los errores se detectan por la propia aplicación, siendo las técnicas empleadas por
las aplicaciones para ello correspondientes a las categorías:

➢ Comprobación de Réplicas
➢ Comprobaciones Temporales
➢ Comprobaciones Inversas
➢ Códigos de Comprobación
➢ Comprobaciones de Racionalidad
➢ Comprobaciones Estructurales
➢ Comprobaciones de Racionalidad Dinámica
b) Para el confinamiento del daño, realizar una técnica de descomposición modular del
software, y definir acciones atómicas, ¿serían técnicas adecuadas, o cuál sería la
diferencia?
El Confinamiento del Daño se refiere a la estructuración del sistema de modo que se
minimicen los daños causados por un componente defectuoso. También se le conoce como
construcción de cortafuegos.

Se pueden emplear dos técnicas para estructurar los sistemas, de modo que se facilite el
confinamiento del daño:

▪ Descomposición Modular
El sistema debería ser descompuesto en componentes, cada uno de los cuales se
representa por uno o más módulos. La interacción entre los componentes se produce
a través de interfaces bien definidas, y los detalles internos de los módulos están
ocultos, no siendo accesibles desde el exterior.

La descomposición modular proporciona al sistema software una estructura estática

que, en su mayor parte, se pierde en el tiempo de ejecución.

▪ Acciones Atómicas
La actividad de un componente es atómica si no existen interacciones entre la
actividad y el sistema durante el transcurso de la acción.

Para el resto del sistema, una acción atómica aparece como indivisible, y se lleva a
cabo de modo instantáneo. No se puede pasar información desde la acción atómica
hacia el resto del sistema, y viceversa.

Las acciones atómicas reciben a menudo el nombre de transacciones o

detransacciones atómicas, las cuales se utilizan para mover el sistema de un estado
consistente a otro, así como para restringir el flujo de información entre
componentes.

Cuando dos o más componentes comparten un recurso, el confinamiento de daños debe

implicar restricciones de acceso a ese recurso.

c) La recuperación de errores hacia adelante ¿supone tener puntos de recuperación? Y ¿sería

apropiada para ellas técnicas que supusieran punteros redundantes?
La recuperación de errores es aquella fase en la que se debe transformar un estado erróneo
del sistema en otro, desde el cual, el sistema pueda continuar con su funcionamiento normal,
siendo esta, probablemente, la fase más importante de cualquier técnica de tolerancia a
fallos.

Se consideran dos estrategias para la recuperación de errores:

▪ Recuperación hacia adelante (forward)

Tratan de continuar desde el estado erróneo realizando correcciones selectivas en el
estado del sistema. Puede resultar eficiente, pero, a pesar de ello, es específica de
cada sistema, dependiendo de la precisión de las predicciones sobre la localización y
la causa del error. Ejemplos: punteros redundantes en las estructuras de datos, el uso
de códigos autocorrectores (Código de Hamming), y/o las excepciones.
 Durante la acción de recuperación resultará necesario disponer de la posibilidad de
abortar (excepción asíncrona) si más de un proceso se encontraba involucrado en la
realización del servicio cuando ocurrió el error.

▪ Recuperación hacia atrás (backward)

Se basa en restaurar el sistema a un estado seguro previo a aquél en el que se produjo
el error, para luego ejecutar una sección alternativa del programa.

Al punto al que el proceso es restaurado se denomina punto de recuperación (checkpoint), y

al proceso de su establecimiento checkpointing.

d) En la recuperación de errores hacia atrás, ¿por qué y cómo se produce el efecto dominó?
El efecto dominó se produce cuando un proceso P debe volver atrás a un punto de
recuperación R, desde el cual, a su vez, debe deshacer la comunicación con otro proceso
(deshacer la comunicación entre procesos, es decir, IPC: Interprocess Communication), y
cuando esto sucede, vuelve a darse de nuevo este caso, hasta que ambos procesos sean
retrotraídos al comienzo de su interacción conjunta. Esto, en algunos casos, puede implicar
el tener que abortar ambos procesos.

Comparación entre programación N-Versiones y los Bloques de Recuperación, como

aproximaciones, para proporcionar software tolerante a fallos
Tanto la programación N-Versiones como los Bloques de Recuperación comparten algunos aspectos
en su filosofía básica, pero presentan las siguientes diferencias:

▪ Redundancia estática frente a la dinámica

La programación N-Versiones se basa en la redundancia estática, es decir, todas las versiones
corren en paralelo, independientemente de si se producen o no fallos.

Los Bloques de Recuperación son dinámicos, ya que los módulos alternativos sólo se ejecutan
cuando ha sido detectado algún error.

▪ Sobrecargas asociadas
Tanto la programación N-Versiones como los Bloques de Recuperación implican cierto coste
al desarrollo, al requerir ambos la creación de algoritmos alternativos.

En la programación N-Versiones se debe diseñar el proceso conductor, y en los bloques de

recuperación el test de aceptación.

En tiempo de ejecución, la programación N-Versiones necesita N veces los recursos de una

única versión. Aunque los Bloques de Recuperación sólo necesitan un conjunto de recursos
en un instante de tiempo, el establecimiento de los puntos de recuperación y la restauración
del estado del proceso son caros.

▪ Diversidad en el diseño
Ambas aproximaciones exploran la diversidad en el diseño para conseguir la tolerancia de
errores no previstos, siendo ambas susceptibles de contener errores originados en la
especificación de requisitos.

▪ Detección de errores
La programación N-Versiones utiliza la comparación de votos para detectar los errores,
mientras que en los bloques de recuperación se utiliza un test de aceptación.
 ▪ Atomicidad
La programación N-Versiones elude el problema de la recuperación de errores hacia atrás
(cuando no se pueden deshacer los errores que se hayan podido producir en el entorno) ya
que, se supone, las versiones no interfieren entre ellas (son atómicas).

En contraparte, es totalmente posible estructurar un programa de forma que las operaciones no

recuperables no aparezcan en los Bloques de Recuperación.

Tareas para las que es posible utilizar excepciones y su gestión

Las excepciones son la ocurrencia de un error, y son usadas para gestionar errores: condiciones
anormales o tolerar defectos en el diseño del programa. Además, proporcionan capacidad para la
detección y recuperación de errores.

La gestión de una excepción, también denominada como manejo o captura de la excepción, viene
dada por la respuesta del invocador, y se entiende como un mecanismo de recuperación hacia
adelante, ya que, cuando la excepción ha sido lanzada, el sistema no es retrotraído al estado anterior,
sino que se pasa el control al gestor, de forma que se puedan iniciar los procedimientos de
recuperación.

Las excepciones y la gestión de excepciones, pueden utilizarse para las siguientes tareas:

▪ Enfrentarse a condiciones anormales que surgen en el entorno.

▪ Tolerar los defectos en el diseño del programa.
▪ Proporcionar unas capacidades de propósito general para la detección de errores y la
recuperación.

¿Se podría considerar fiable un programa que es conforme a una especificación errónea de su
comportamiento?
La fiabilidad de un sistema es la medida del éxito con la que el sistema cumple con alguna de las
especificaciones obligatorias de su comportamiento. Que la especificación sea errónea, no hace al
sistema menos o nada fiable, ya que la fiabilidad se determina en función de la especificación dada
(el cómo de bien se ajusta a ella), por lo que sería un problema de especificación, no de fiabilidad.

Por ello, un programa que es conforme a una especificación, sin importar que sea errónea, es fiable.

Distinguir entre: Seguridad, Fiabilidad y Confiabilidad

▪ Seguridad: es la ausencia de condiciones que puedan causar muerte, lesión, enfermedad

laboral, daño/pérdida de equipos/propiedades, o aspectos nocivos para el medio ambiente.
La seguridad software se considera a menudo en términos de percance (evento no planeado
o secuencias de eventos que puedan causar algunas de las situaciones anteriores). La
seguridad también se conoce como la improbabilidad de que se den las condiciones que
conducen a un percance, independientemente de si se realiza la función prevista.

▪ Fiabilidad: es la medida del éxito con la que un sistema se ajusta a la especificación de su

comportamiento. Esto se expresa habitualmente en términos de probabilidad.

▪ Confiabilidad: es la propiedad del sistema que permite calificar justificadamente como es de

fiable el servicio que proporciona.