PROCESOS CONFIABLES

Existen varias razones por las que la confiabilidad es la propiedad más importante de los
sistemas críticos:

 Los sistemas que son no fiables, inseguros o desprotegidos son rechazados a menudo
por sus usuarios. Si los usuarios no confían en un sistema, se negarán a utilizarlo. Es
más, también rehusarán comprar o utilizar productos de la misma compañía que
produjo el sistema no confiable, puesto que creen que éstos tampoco son confiables.
 Los costes de los fallos de funcionamiento del sistema pueden ser enormes. En
algunas aplicaciones, como un sistema de control de reactores o un sistema de
navegación aérea, el coste de un fallo en el sistema es mayor en varios órdenes de
magnitud que el coste de dicho sistema de control.
 Los sistemas no confiables pueden provocar pérdida de información. Es muy cara la
captura y mantenimiento de los datos; algunas veces cuesta más que el
sistema informático que los procesa. Se tiene que hacer un gran esfuerzo e
invertir mucho dinero para duplicar los datos importantes a fin de protegerlos de
cualquier corrupción.

El elevado coste de un fallo de funcionamiento en los sistemas críticos implica que se deben
usar métodos y técnicas confiables en su desarrollo. Como consecuencia, los sistemas críticos
generalmente se desarrollan utilizando técnicas muy probadas en lugar de técnicas
novedosas que no han sido objeto de una extensa experiencia práctica. En vez de utilizar
métodos y técnicas novedosas, los desarrolladores de sistemas críticos son conservadores por
naturaleza. Prefieren utilizar técnicas antiguas cuyas ventajas e inconvenientes son muy
conocidos, en lugar de nuevas técnicas que aparentemente son mejores pero cuyos problemas
a largo plazo se desconocen.
PROGRAMACIÓN CONFIABLE

Los defectos en los programas, y por lo tanto muchos fallos de ejecución de éstos, son
normalmente consecuencia de un error humano. Los programadores cometen errores debido
a que pierden la pista de todas las relaciones entre las variables de estado. Escriben
sentencias de programas que provocan un comportamiento inesperado y cambios en el
estado del sistema. Las personas siempre cometerán errores, pero fue evidente a finales de
la década de los 60 que algunas aproximaciones de programación eran más propensas a
error que otras.

INFORMACIÓN PROTEGID A

Debería utilizarse una aproximación para el diseño e implementación del software

basada en la ocultación y encapsulamiento de la ¡información. Cuando se programa.
debería adoptarse un principio análogo para controlar el acceso a los datos del
sistema. A los componentes del programa se les debería permitir el acceso solamente
a los datos que necesitan para su implementación. Pueden protegerse otros datos
mediante el uso de reglas de ámbito del lenguaje de programación para ocultarlos
desde otras partes del programa. Si se oculta información. ésta no puede ser viciada
por los com. Una especificación de una Cola utilizando una declaración de interfaz
Java. Una declaración de una Señal en Java que oculta el tipo de representación.
Programación confiable ponentes del programa que se supone que no la utilizan. Si
la interfaz sigue siendo la misma, la representación de los datos puede cambiarse sin
afectar a otros componentes en el sistema.

PROGRAMACIÓN SEGURA

La programación segura significa evitar, o al menos minimizar, el uso de estas

construcciones. Algunos estándares para el desarrollo de sistemas de seguridad
críticos prohíben completamente el uso de estas construcciones. Sin embargo. esta
posición extrema no es normalmente práctica. Todas estas construcciones y técnicas
son útiles, pero tienen que utilizarse con cuidado. Siempre y cuando sea posible, sus
potenciales efectos peligrosos deberían controlarse utilizándolos dentro de tipos
abstractos de datos u objetos. Éstos actúan como «cortafuegos» limitando el daño
ocasionado si se producen errores

MANEJO DE EXCEPCIONE S

Durante la ejecución del programa, los errores o eventos no esperados ocurren

inevitablemente. Esto puede darse debido a un defecto en el programa o puede ser
el resultado de circunstancias externas no predecibles. Un error o un evento
inesperado que ocurra durante la ejecución de un programa se denomina una
excepción. Las excepciones pueden ser provocadas por condiciones hardware o
software. Cuando ocurre una excepción, ésta debe ser manejada por el sistema. Esto
puede hacerse dentro del mismo programa o puede implicar la transferencia de
control a un mecanismo de manejo de excepciones del sistema. Normalmente, el
 mecanismo de manejo de excepciones del sistema simplemente informa del error y
abandona la ejecución. Por lo tanto, para asegurar que las excepciones del programa
no provocan fallos de ejecución del sistema, debería definirse un manejador de
excepciones para todas las posibles excepciones que puedan ocurrir y asegurarse de
que todas las excepciones se manejan de forma explícita.

TOLERANCIA A DEFECTOS
Un sistema tolerante a defectos puede continuar en funcionamiento después de que se manifiesten algunos
defectos en el programa. Los mecanismos de tolerancia a defectos en el sistema aseguran que estos defectos
del sistema no provocan fallos de funcionamiento del sistema. Se necesita tolerancia a defectos en situaciones
en las que un fallo de funcionamiento del sistema podría provocar un accidente catastrófico o en las que una
pérdida de funcionamiento del sistema pudiese causar grandes pérdidas económicas.

DETECCIÓN DE DEFECTOS Y EVALUACION DE DAÑOS

La primera etapa de la tolerancia a defectos es detectar que un defecto (un estado

del sistema erróneo) o bien ha ocurrido u ocurrirá a menos que se realice
inmediatamente alguna acción. Para hacer esto, se necesita conocer cuándo el valor
de una variable de estado es ilegal o cuándo las relaciones entre variables de estado
no se mantienen. Por lo tanto, se necesita definir restricciones de los estados que
determinan las condiciones que deberían cumplirse para todos los estados legales. Si
estos predicados son falsos. entonces ha tenido lugar un defecto.

Existen dos tipos de detección de defectos que se pueden utilizar:

1. Detección de defectos preventiva. En este caso. el mecanismo de detección de

defectos se inicia antes de que se produzca un cambio en el estado. Si se detecta un
estado potencialmente erróneo, entonces el cambio de estado no se realiza.

2. Detección de defectos retrospectiva. En este caso, el mecanismo de detección de

defectos se inicia después de que el estado del sistema ha sido cambiado para
comprobar si ha tenido lugar un defecto. Si se descubre un defecto. se provoca una
excepción y se utiliza un mecanismo de reparación para recuperarse de ese defecto.

Otras técnicas de detección de defectos y de evaluación de daños dependen de la

representación de los estados del sistema y del tipo de aplicación. Estas técnicas de
evaluación de daños incluyen:

l. El uso de comprobaciones de código y sumas de verificación en las comunicaciones

de datos y comprobaciones de dígitos en datos numéricos.

2. El uso de enlaces redundantes en estructuras de datos que contienen punteros.

3. El uso de temporizadores en sistemas concurrentes.

 RECUPERACIÓN Y REPAR ACIÓN DE DEFECTOS

La recuperación de defectos es el proceso de modificar el espacio de estados del

sistema para que los efectos del defecto sean eliminados o reducidos. El sistema
puede continuar funcionando, quizás de forma algo degradada. La recuperación
hacia adelante implica intentar corregir el sistema dañado y crear el estado
esperado. La recuperación hacia atrás restaura el estado del sistema a un estado
«correcto» conocido.

La recuperación de errores hacia adelante sólo es posible en situaciones en las que

la información del estado incluye redundancia. Existen dos situaciones generales
(ambas descritas en la sección previa) en las que pueden aplicarse técnicas de
recuperación de errores: l. Cuando los datos del códiKo están dañados. El uso de
técnicas de codificación que añaden redundancia a los datos permite corregir los
errores así como detectarlos. 2. Cuando las estructuras enlazadas están dañadas.
Cuando los punteros hacia adelante y hacia atrás se incluyen en la estructura de
datos. la estructura puede volverse a crear -si un número suficiente de punteros
pennanece sin dañar-o Esta técnica se utiliza frecuentemente para sistemas de
ficheros y reparación de bases de datos.

ARQUITECTURAS TOLERANTES A DEFECTOS