CARRERA: TECNICO SUPERIOR EN SISTEMAS INFORMATICOS
D E SISTEMAS CRITICOS TEMA: DESARROLLO DE MATERIA: INGENIERIA DE SOFTWARE DOCENTE: Lic. DIOEGENES PONCE ESTUDIANTES: GIAN VIDAL FLOWER
HADE NOEMI LOAYZA MAMANI GRUPO: SIM-008 GESTION: 2017
Los fallos de funcionamiento del software son relativamente comunes. En la mayoría de los casos, estos fallos provocan molestias. Sin embargo, en algunos sistemas un fallo de funcionamiento puede ocasionar pérdidas económicas significativas, daño físico o amenazas a la vida humana. Estos sistemas se conocen como sistemas críticos.
SISTEMAS CRITICOS
Los sistemas críticos son sistemas técnicos o socio-técnicos de los cuales dependen las personas o los negocios. Si estos sistemas no ofrecen sus servicios de la forma esperada, pueden provocar graves problemas y pérdidas importantes. Hay tres tipos principales de sistemas críticos:
Sistemas de seguridad críticos: Son sistemas cuyo fallo de funcionamiento puede provocar perjuicio, pérdida de vidas o daños graves al medio ambiente. Sistemas de misión críticos: Son sistemas cuyo fallo de funcionamiento puede provocar errores en algunas actividades dirigidas por objetivos. Sistemas de negocio críticos: Son sistemas cuyo fallo de funcionamiento puede provocar costes muy elevados para el negocio que utiliza un sistema de este tipo.
La propiedad más importante de un sistema crítico es su confiabilidad. El término confiabilidad fue propuesto por Laprie (Laprie, 1995) para hacer referencia a las siguientes propiedades relacionadas de los sistemas: disponibilidad, fiabilidad, seguridad y protección. 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. Para el desarrollo de sistemas críticos, a menudo se utilizan técnicas de ingeniería del software que por lo general no son rentables. Una razón por la que se usan estos métodos formales es que ayudan a reducir la cantidad de pruebas requeridas. Para sistemas críticos, los costes de verificación y validación generalmente son muy elevados más del 50% de los costes totales de desarrollo del sistema.
Si bien un número reducido de sistemas se pueden automatizar completamente, la mayoría de los sistemas críticos son sistemas socio-técnicos en los que las personas monitorizan y controlan el funcionamiento de dichos sistemas informáticos. Los costes de un fallo de funcionamiento de los sistemas críticos generalmente son tan altos que es necesario contar con personal adicional en el sistema que pueda hacer frente a situaciones inesperadas, y que pueda recuperar el funcionamiento normal del sistema cuando las cosas van mal. Desde luego, a pesar de que los operadores del sistema pueden ayudar a recuperarlo cuando algo va mal, ellos mismos a su vez pueden generar problemas si cometen errores. Existen tres tipos de «componentes de sistemas» susceptibles de generar un fallo en el sistema:
El hardware del sistema puede fallar debido a errores en su diseño, también debido a que los componentes fallan como resultado de errores de fabricación, o debido a que dichos componentes han llegado al final de su vida útil. El software del sistema puede fallar debido a errores en su especificación, diseño o implementación. Los operadores del sistema pueden provocar fallos en el sistema debido a un uso incorrecto del mismo. Así como el hardware y el software son cada vez más fiables, hoy en día los fallos debidos a un mal uso del sistema son probablemente la principal causa de fallos de funcionamiento en el sistema.
Estos fallos pueden interrelacionarse. Un componente hardware que deja de funcionar puede implicar que los operadores del sistema tengan que afrontar una situación inesperada y una carga de trabajo adicional. Esto hace que los operadores trabajen en estado de estrés y las personas que sufren estrés a menudo cometen errores. Esto puede ocasionar que el software falle, lo que supone más trabajo para los operadores, más estrés, y así sucesivamente. Como resultado de todo lo anterior, es particularmente importante que los diseñadores de los sistemas críticos adopten una perspectiva holística del sistema en lugar de centrarse en un único aspecto del mismo. SÍ el hardware, el software y las formas de utilización del sistema se diseñan de forma separada sin tener en cuenta los puntos débiles potenciales del resto de las partes del sistema, entonces será más probable que los errores se produzcan en las interfaces entre las distintas partes del sistema.
DESARROLLO DE SISTEMAS CRITICOS
Los sistemas críticos tales como aquellos que controlan maquinaria automática, sistemas médicos, centrales de comunicación o aviones necesitan niveles más altos de confiabilidad. Existen aproximaciones complementarias para desarrollar software confiable: Prevención de defectos.- El proceso de diseño e implementación del sistema debería utilizar aproximaciones al desarrollo del software que ayuden a evitar errores de programación y así minimizar el número de defectos en un programa. Detección de defectos.- Los procesos de verificación y validación se diseñan para descubrir y validar defectos en un programa antes de que éste sea desplegado para su uso. Tolerancia a defectos.- El sistema se diseña para que los defectos o comportamientos inesperados del sistema durante la ejecución sean detectados y gestionados de tal forma que no ocurran fallos de funcionamiento.
Resulta fundamental, para conseguir la confiabilidad en cualquier sistema, nociones básicas sobre redundancia y diversidad. Los sistemas críticos pueden incluir componentes que reproducen la funcionalidad de otros componentes o código de comprobación adicional que no es estrictamente necesario para que el sistema funcione es redundancia. Si los componentes redundantes no son exactamente iguales que otros componentes es diversidad, añadir diversidad y redundancia a los sistemas los hacen más complejos por lo tanto más difíciles de entender. El software libre de defectos es aquel software que cumple exactamente con su especificación, sin embargo esto no significa que el software nunca llegue a fallar ya que puede haber errores en la especificación que se refleja en el software o los usuarios pueden no comprender o no usar correctamente el sistema software. Para sistemas de tamaño pequeño y medio, las técnicas de ingeniería de software son tales que probablemente sea posible desarrollar software libre de defectos, para alcanzar este objetivo es necesario utilizar varias técnicas de ingeniería del software:
Procesos software confiable.- El uso de un proceso software confiable con actividades de
verificación y validación adecuadas resulta esencial si tiene que minimizarse el número de defectos en el programa y tiene que detectarse aquellos que se produzcan. Gestión de calidad.- La organización que desarrolla el sistema debe tener una cultura en la que la calidad guie el proceso software. Esta cultura debería motivar al desarrollo de software libre de errores y debería establecer estándares de diseño y desarrollo, así como procedimientos para comprobar que dichos estándares se cumplen. Especificación formal.- debe realizarse una especificación del sistema precisa que defina el sistema que se va a implementar. Muchos errores de diseño y programación son el resultado de una mala interpretación de una especificación ambigua o pobremente redactada.
Verificación estática.- Las técnicas de verificación estáticas como el uso de analizadores estáticos
pueden encontrar características anómalas en el programa que podrían ser defectos. Tipado fuerte.- Para el desarrollo se debe usar un lenguaje de programación fuertemente tipado, como Java, si el lenguaje es fuertemente tipado, el compilador del lenguaje puede detectar muchos errores de programación antes de que puedan ser introducidos en el programa a entregar. Programación segura.- Algunas construcciones de lenguaje de programación son más complejas y propensas a error que otras, y es más probable que se cometan errores si se usan. La programación segura significa evitar o al menos minimizar el uso de estas construcciones. Información protegida.- 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.
A medida que el software se hace más fiable se necesita emplear más y más tiempo y esfuerzo para encontrar menos y menos defectos. En algún momento, los costes de este esfuerzo para encontrar menos y menos defectos se convierten en justificables. Como consecuencia las compañías desarrolladoras de software siempre tendrán algún defecto residual. Procesos confiables
Los procesos confiables están adaptados a la prevención y detección de defectos. Los procesos confiables están definidos y son repetibles, e incluyen una variedad de actividades de verificación y validación.
Un proceso bien definido es un proceso que ha sido estandarizado y documentado. Un proceso repetible es aquel que no depende de un juicio e interpretación individual, independientemente de la gente implicada en el proceso.
Un proceso confiable debería incluir siempre actividades de verificación y validación bien planificadas y organizadas cuyo objetivo es asegurar el descubrimiento de defectos residuales en el software antes de que éste sea desplegado. Las actividades del proceso que se llevan a cabo para prevenir y detectar los defectos son:
Inspección de requerimientos.- Estas
pretenden descubrir problemas en la especificación del sistema. Una proporción elevada de defectos en el software entregado es consecuencia de errores en los requerimientos. Si estos pueden descubrirse y eliminarse de la especificación entonces esta clase de defectos se minimizaran. Gestión de requerimientos.- Está relacionada con la realización de un seguimiento de los cambios en los requerimientos y extender dicho seguimiento a lo largo del diseño y la implementación. Muchos errores en los sistemas entregados son el resultado de no asegurar que realmente se incluya un cambio de requerimientos en el diseño e implementación del sistema. Verificación de modelos.- La verificación de modelos implica el uso de herramientas CASE para analizar los modelos del sistema y asegurar su consistencia interna y externa. La consistencia interna significa que un modelo del sistema es consistente. La consistencia externa significa que diferentes modelos del sistema por ejemplo un modelo de estados y un modelo de objetos son consistentes. Inspecciones de diseño y código.- las inspecciones de diseño y código frecuentemente se basan en líneas de verificación de defectos comunes y pretenden descubrir y eliminar estos defectos antes de la prueba del sistema. Análisis estático.- El análisis estático es una técnica automática de análisis de programas en la que el programa se analiza con detalle para encontrar condiciones potencialmente erróneas.
Planificación y gestión de las pruebas.- Debería diseñarse un conjunto completo de pruebas para el
sistema y gestionar cuidadosamente el proceso de pruebas para asegurar una cobertura completa de las pruebas y el seguimiento de los requerimientos y el diseño del sistema a través de las pruebas. Programación confiable
La programación confiable implica el uso de técnicas y construcción de programación que contribuyen a prevenir y tolerar los defectos. Mientras que algunos errores tienen lugar debido a que los programadores cometen errores o a malas interpretaciones de la especificación, otros tienes lugar debido a la complejidad de los programas o al uso de construcciones propensas a error, para alcanzar la confiabilidad sería preciso realizar diseños simples, proteger la información de accesos no autorizados y minimizar el uso de construcciones de programación no seguras. Las técnicas de programación para la prevención de defectos se basan en el hecho de que hay una distinción entre defectos y fallos de ejecución. Un fallo de ejecución es algo que es observable para los usuarios de un sistema. Un defecto de ejecución es una característica interna del sistema. Si un defecto se manifiesta en un programa en ejecución es posible toléralo detectándolo y realizando la acción de recuperación antes de que se convierta en un fallo de ejecución del sistema. Información protegida
Es la protección de los datos del sistema, es decir que los componentes del programa deberían tener acceso solo a los datos que necesitan para su implementación de ese modo pueden protegerse otros datos y ocultarlos desde otra partes del programa ya que si se oculta información esta no puede llegar a ser corrompida por los componentes del programa que se supone no la utilizan. La protección de información es mucho más sencilla en Java que en lenguajes más antiguos, debido a que estos lenguajes no tienen construcciones de encapsulación tales como clases de objetos. Generalmente cuando se programa en lenguaje orientado a objetos, proporciona métodos que acceden a estos atributos directamente, esto significa que puede cambiarse la representación del atributo sin preocuparse de cómo otros objetos utilizan el atributo, es importante utilizar esta aproximación para estructuras de datos y otros atributos complejos. La construcción de definiciones de interfaces Java hace posible utilizar esta aproximación y es posible declarar la interfaz de un objeto sin hacer referencia a su implementación. Los usuarios de los objetos de tipo Queue pueden insertar objetos en la cola, eliminarlos de la cola y consultar el tamaño de la cola, sin embargo en la clase que implementa esta interfaz la implementación real debería ocultarse declarando los atributos y métodos como particulares de esa clase de objetos.
Una especificación de una cola utilizando una declaración de interfaz Java.
Otro tipo de protección de protección de información: en situaciones en las que un conjunto de valores limitados puede asignarse a alguna variable, esto valores deberían declarase como contantes. Lenguajes tales como C soportan tipos enumerados, pero en Java esto debe implementarse asociando estas restricciones con la declaración de la clase. Consideremos un sistema de señalización, implementando en Java que soporte luces rojas, amarillas y verdes, debería definirse un tipo Signal que incluya declaraciones de constantes que reflejan estos colores, por lo tanto es posible hacer referencia a Signal.red, Signal.yellow, Signal.green y asi sucesivamente,esto evitara asignaciones de valores incorrectos a las variable de tipo Signal.
Class Signal { Por lo tanto, se están protegiendo variables de tipo Signal de asignaciones incorrectas y al mismo tiempo ocultando la representación de rojo, amarillo y verde. Pueden cambiarse estos valores constantes más tarde sin tener que realizar ningún otro cambio en el programa.
static public final int red=1 ; static public final int yellow=2 ; static public final int green=3 ;
public int sigState ; } Una declaración de una señal en JAVA que oculta el tipo de representación.
Programación segura
La sentencia Goto o salto incondicional era una construcción de programación propensa a error. Esta observación condujo al desarrollo de la programación estructurada, este tipo de programación es sin sentencias Goto utilizando solamente bucles while y sentencias if como construcciones de control y un diseño mediante una aproximación descendente. Es menos probable introducir defectos en los programas si se evitan o al menos se usan lo menos posible, las construcciones potencialmente propensas a error, estas comprenden: Números en coma flotante.- Los números en coma flotante son imprecisos, este es un problema particular cuando hay comparaciones debido a que la imprecisión en la representación puede llevar a comparaciones incorrectas. Punteros.- Los punteros son construcciones de bajo nivel que almacenan direcciones que hacen referencia directamente a zonas de memoria de la máquina. Asignación dinámica de memoria.- La memoria del programa puede asignarse en tiempo de ejecución en lugar de en tiempo de compilación.
Paralelismo.- El paralelismo es peligroso debido a las dificultades de predecir los efectos sutiles de
las interacciones temporales entre los procesos en paralelo. Los problemas temporales normalmente no pueden detectarse mediante la inspección de programa, el paralelismo puede ser inevitable pero su uso debería ser cuidadosamente controlado para minimizar las dependencias entre los procesos. Recursión.- LA recursión se produce cuando un proceso o método se llama a sí mismo o llama otro procedimiento, el cual a su vez llama al procedimiento original que realizo la llamada. Su uso puede generar programas concisos, pero puede ser difícil seguir la lógica de los programas recursivos, por lo tanto los errores de programación son más difíciles de detectar. Interrupciones.- Son un modo de forzar la transferencia de control a una sección de código independientemente del código que se esté ejecutando actualmente, pero la interrupción puede provocar la terminación de una operación crítica. Herencia.- el problema de la herencia en la programación orientada a objetos es que el código asociado con el objeto no está todo en un mismo sitio, esto hace más difícil comprender el comportamiento del objeto. Aliasing.- Esto ocurre cuando se utiliza más de un nombre para referiré a la misma entidad en un programa. Vectores no limitados.- Los vectores son formas de acceder a la memoria y pueden hacerse asignaciones más allá del final de un vector. El soporte de ejecución del sistema no comprueba que las asignaciones realmente se refieren a los elementos del vector. Una vulnerabilidad conocida de la protección es el desbordamiento del búfer en el que un intruso deliberadamente desarrolla un programa para escribir en la memoria más allá del final de un búfer que se implementa como un vector. Procesamiento de entradas por defecto.- Algunos sistemas proporcionan un procesamiento de las entradas por defecto independientemente de las entrada presentada al sistema, esto es un agujero en la protección, que un intruso puede aprovechar para presentar al programa entradas no esperadas y que no sean rechazadas por el sistema.
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, estos actúan limitando el daño ocasionado si se producen errores. Manejo de excepciones
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 denominan una excepción, esta puede ser provocada por condiciones de hardware o software. Cuando ocurre una excepción, esta 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.
Algunos lenguajes de programación como Java, C , incluyen construcciones que soportan el manejo de excepciones de forma que no se necesitan sentencias condicionales adicionales para comprobar las excepciones, en su lugar el lenguaje de programación incluye un tipo de construcción especial, con frecuencia llamado Exception y diferentes excepciones pueden declararse con este t ipo. Cuando ocurre una situación excepcional, la excepción es capturada y el soporte de ejecución del lenguaje transfiere el control a un manejador de excepciones adecuadas para manejar cada excepción. En Java pueden declararse nuevos tipos de excepciones extendiendo la clase Exception, las excepciones son provocadas en Java utilizando una sentencia throw. El manejador de una excepción se indica por la palabra clave catch, seguida por un bloque de códigos que maneja la excepción. Esta clase Java es una implementación de un congelador de temperatura de un congelador de comida. La temperatura requerida puede fijarse entre -18 y -40 grados Celsius, la comida congelada puede comenzar a descongelarse y las bacterias se vuelven activas a temperaturas por encima de -18 grados. El sistema de control mantiene la temperatura alternando el encendido y apagado de una bomba refrigerante de acuerdo con el valor de un sensor de temperatura, si la temperatura requerida no puede mantenerse, el controlador dispara una alarma. En la implementación Java, la temperatura del congelador se obtiene interrogando a un objeto denominado tempSensor, y la temperatura requerida se obtiene inspeccionando un objeto denominado temDial. Un objeto bomba (Pump) responde a las señales para cambiar su estado, una vez que la bomba ha sido encendida, el sistema espera durante algún tiempo (llamado a Thread.sleep) para que la temperatura se reduzca, si no ha sido disminuido suficientemente se lanza una excepción denominada FreezerTooHotException. El manejador de excepciones (situado al final del código catch) captura esta excepción y activa el objeto Alarm, también se incluye un manejador para la excepción InterrupmtedException que puede ser provocada por Thread.sleep, este registra la excepción y a continuación vuelve a provocar la excepción para su manejo en el método principal.
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. Existen cuatro aspectos a considerar en la tolerancia a defectos:
Detección de defectos.- El sistema debe detectar un defecto que podría conducir a un fallo de
ejecución del sistema. Generalmente esto implica comprobar que el estado del sistema es consistente. Evaluación de los daños.- Se deben detectar las partes del estado del sistema que han sido afectadas por el defecto. Recuperación de defectos.- El sistema debe restaurar su estado a u estado <> conocido. Esto puede conseguirse corrigiendo el estado dañado (recuperación de errores hacia adelante) o restaurando el sistema a un estad <> conocido (recuperación de errores hacia atrás). Reparación de defectos.- Esto implica modificar el sistema para que no vuelva a aparecer el defecto. Sin embargo muchos defectos del software se manifiestan como estados transitorios, no es necesario realizar ninguna reparación y el procesamiento normal puede continuarse inmediatamente después de la recuperación de los defectos.
Si no hay defectos en el sistema podría parecer que no hay ninguna posibilidad de un fallo de ejecución del sistema, pero “libre de defectos” no significa “libre de fallos de ejecución”.
Detección de defectos y evaluación de daños
La primera etapa de la tolerancia a defectos es detectar que un defecto (un estado del sistema erróneo) ha ocurrido u ocurrirá a menos que se realice inmediatamente alguna acción. Existen dos tipos de detección de defectos que se pueden utilizar.
Detección de defectos preventiva.- El mecanismo 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. Detección de defectos retrospectiva.- 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 efecto.
En Java la forma más segura de implementar la detección de defectos preventiva es comprobar la presencia de defectos y utilizar el mecanismo de manejo de excepciones en el lenguaje para indicar que un estado erróneo del sistema ha sido detectado.
La detección de defectos preventiva es posible cuando se conoce el rango de valores que pueden asignarse a una variable de estado. Sin embargo cuando un valor valido depende del valor asignado a otro valor asignado a otras variables en el estado, la detección de defectos preventiva puede muy difícil. Una forma de implementar la detección de defectos retrospectiva en Java consiste en asociar una función comprobado con un objeto. Esta función puede llamarse después de que los cambios en el estado hayan tenido lugar para asegurar que se cumplan las restricciones del estado, estas pueden llamarse cuando sea necesario (puede que no sea necesario comprobar el estado después de cada cambio haya tenido lugar)
Interfaz que puede ser utilizada para funciones de comprobación.
Los objetos a comprobar son instancias de una clase de objetos que implementan esta interfaz, por lo que cada objeto tiene una función de comprobación asociada. Cada clase de objetos implementan su propia función de comprobación que define las restricciones particulares que se aplican a los objetos de esa clase, cuando se comprueba un estado en su totalidad se utiliza enlaces dinámicos para asegurar que se aplica la función de comprobación adecuada para la clase de objeto que se está comprobando.
La función check comprueba que los elementos de un vector satisfacen alguna restricción.
La evaluación de daños implica analizar el estado del sistema para estimar el alcance de la corrupción del estado, la evaluación de daños es necesaria cuando no se puede evitar realizar un cambio de estado o cuando un defecto tiene lugar por una secuencia invalida de cambios de estado correctos individualmente.
Otras técnicas de detección de defectos y de evaluación de daños depende 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:
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. El uso de enlaces redundantes en estructuras de datos que contienen punteros. El uso de temporizadores en sistemas concurrentes.
Recuperación y reparació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. 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 <> conocido. La recuperación de errores hacia adelante solo es posible en situaciones en las que la información del estado incluye redundancia. Existen dos situaciones generales en las que pueden aplicarse técnicas de recuperación de errores:
Cuando los datos del código 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 detectarlo. 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. Esta técnica se utiliza frecuentemente para sistemas de ficheros y reparación de base de datos.
La recuperación de errores hacia atrás es una técnica que restaura el estado a un estado seguro conocido después de haberse detectado un error, la mayoría de los sistemas de base de datos incluyen recuperación de errores hacia atrás. Arquitecturas tolerantes a defectos
Para la mayoría de los sistemas críticos puede necesitarse una arquitectura específica del sistema diseñada para soportar la tolerancia a defectos. Durante muchos años ha habido una necesidad de construir hardware tolerante a defectos, las técnicas más comúnmente utilizada de tolerancia a defectos hardware está basada en la noción de redundancia modular triple (TMR). La unidad hardware se reproduce tres veces (o algunas veces más) , la salida de cada unidad se envía a un comprobador de salida que normalmente se implementa como un sistema de votaciones, si una de las unidades falla y no produce la misma salida que el resto de las unidades, se pasa por alto su salida. Un gestor de defecto puede intentar reparar la unidad defectuosa de forma automática, pero si esto es imposible el sistema continua funcionando con dos unidades.
Redundancia modular triple para tratar los fallos de ejecución del hardware.
Esta aproximación a la tolerancia a defectos cubre la mayoría de fallos de ejecución del hardware que son el resultado de fallos en los componentes en lugar de defectos de diseño, por lo tanto es probable que los componentes fallen de forma independiente. Se supone que cuando son completamente funcionales todas las unidades hardware funcionan de acuerdo con su especificación, por lo tanto hay una baja probabilidad de fallos simultáneas en los componentes en todas las unidades hardware. Si los requerimientos de disponibilidad y fiabilidad de un sistema son tales que se necesita utilizar hardware tolerante a defectos también puede necesitar software tolerante a defectos. Existen dos aproximaciones relacionadas con la provisión de software tolerante a defectos, estas son:
Programación con n-versiones.- Utilizando una especificación común, el sistema software se
implementa en varias versiones por diversos equipos, estas versiones se ejecutan en paralelo sobre computadoras diferentes. Sus salidas se comparan utilizando un sistema de votaciones y las salidas inconsistentes o las que no se producen a tiempo son rechazadas. Al menos deberían estar disponibles tres versiones del sistema para que dos versiones fuesen consistentes en el caso de que sólo una de ellas fallase. Esta es la aproximación comúnmente más utilizada para tolerancia defectos del software.
Programación con n-versiones
Bloques de recuperación.- En esta aproximación, cada componente del programa incluye una
prueba para verificar que el componente se ha ejecutado con éxito, también incluye código alternativo que permite que el sistema vuelva hacia atrás y repita los cálculos si la prueba detecta un fallo de ejecución. De forma delibera, las implementaciones son interpretaciones diferentes de la misma especificación. Se ejecutan en secuencia en lugar de en paralelo de forma que no se requiere la replicación de hardware.
Bloques de recuperación
Bibliografía
Ingeniería de software de Ian Sommerville http://idsuba.blogspot.com/2014/06/sistemas-criticos.html
