Capítulo 13 -Ingeniería de Confiabilidad · 2020-02-03 · §Sistemas nucleares §Sistemas de control de tráfico aéreo ... §Sistemas de reactores que el fallo del sistema de

Capítulo 13 - Ingeniería de Confiabilidad

Ciclo de conferencias 1

1Capítulo 13 Ingeniería Confiable

Temas tratados

² Redundancia y diversidad § Enfoques fundamentales para lograr la tolerancia a fallos.

² Procesos confiables § ¿Cómo el uso de procesos confiables conduce a sistemas

fiables?

² Arquitecturas de sistemas confiables § Patrones de arquitectura para la tolerancia a fallos del software

² Programación fiable § Directrices de la programación para evitar errores.


Software confiable

² En general, los clientes de software esperan que todo el software sea confiable. Sin embargo, para aplicaciones no críticas, que pueden estar dispuestos a aceptar algunas fallas en el sistema.

² Algunas aplicaciones (sistemas críticos) tienen requisitos muy altos de confiabilidad y técnicas especiales de ingeniería de software se pueden utilizar para lograrlo. § Los sistemas médicos § Telecomunicaciones y sistemas de energía § Sistemas Aeroespaciales


Logro de Confiabilidad

² Evitación de fallos§ El sistema está desarrollado de tal manera que se evita el error

humano y por lo tanto fallos del sistema se reducen al mínimo. § El proceso de desarrollo se organiza de manera que los fallos

en el sistema son detectadas y reparadas antes de la entrega al cliente.

² La detección de fallos § Las técnicas de verificación y validación se utilizan para

descubrir y eliminar los fallos en un sistema antes de que se despliegue.

² La tolerancia a fallos § El sistema está diseñado de manera que los fallos en el

software entregado no dan lugar a un fallo del sistema.


Los costos crecientes de la eliminación de fallos residual


Sistemas Regulados

² Muchos sistemas críticos son sistemas regulados, lo que significa que su uso debe ser aprobado por un regulador externo antes de que los sistemas entren en servicio. § Sistemas nucleares § Sistemas de control de tráfico aéreo § Dispositivos médicos

² Un estudio de seguridad y fiabilidad tiene que ser aprobado por el regulador. Por lo tanto, el desarrollo de sistemas críticos tiene que crear la evidencia para convencer a un regulador que el sistema es confiable, seguro y protegido.


Diversidad y Redundancia

² Redundancia § Mantener más de 1 versión de un componente crítico disponible

de modo que si uno falla entonces una copia de seguridad está disponible.

² Diversidad § Proporcionan la misma funcionalidad de diferentes maneras

para que no se producirá un error de la misma manera. ² Sin embargo, la adición de la diversidad y la

redundancia añade complejidad y esto puede aumentar las posibilidades de error.

² Algunos ingenieros abogan por la simplicidad y la extensa V & V es una vía más eficaz para la fiabilidad del software.


Ejemplos de Diversidad y Redundancia

² La redundancia. Cuando la disponibilidad es crítica (por ejemplo, en sistemas de comercio electrónico), las empresas normalmente mantienen servidores de copia de seguridad y cambian a estos de forma automática si se produce un fallo.

² Diversidad. Para proporcionar resistencia frente a ataques externos, distintos servidores pueden implementarse utilizando diferentes sistemas operativos (por ejemplo, Windows y Linux)


Proceso de diversidad y redundancia

² Las actividades del proceso, como la validación, no deberían depender de un único enfoque, como las pruebas para validar el sistema.

² Por el contrario, varias diferentes actividades del proceso se complementan entre sí y permiten la verificación cruzada de ayuda para evitar errores en el proceso, lo que puede dar lugar a errores en el software


Procesos Confiables

² Para garantizar un número mínimo de errores de software, es importante disponer de un proceso de software repetible bien definido.

² Un proceso repetible bien definido es aquel que no depende enteramente de las habilidades individuales; más bien pueden llevarse a cabo por diferentes personas.

² Los reguladores utilizan información sobre el proceso para comprobar si una práctica de buena ingeniería del software se ha utilizado.

² Para la detección de fallos, es evidente que las actividades del proceso deben incluir significativo esfuerzo dedicado a la verificación y validación.


Atributos de procesos confiables

Características del Proceso DescripciónDocumentable El proceso debe tener un modelo de proceso

definido que establece las actividades en elproceso y la documentación que se ha deproducir durante estas actividades.

Estandarizado Un amplio conjunto de normas de desarrollo desoftware que abarcan la producción ydocumentación de software debe estar disponible.

Auditable El proceso debe ser comprensible por personasaparte de los participantes del proceso, quepueden comprobar que el proceso se estánsiguiendo las normas y hacer sugerencias para lamejora de procesos.

Diverso El proceso debe incluir las actividades deverificación y validación redundantes y diversos.

Robusto El proceso debe ser capaz de recuperarse de losfracasos de las actividades individuales delproceso.


Actividades de Validación

² Requerimientos y opiniones.

² La gestión de requisitos.

² Especificación formal.

² La modelación de sistemas

² Diseño e inspección de código. ² El análisis estático.

² La planificación de pruebas y la gestión.

² La gestión del cambio, discutido en el capítulo 25, es también esencial.


Tolerancia al Fallo

² En situaciones críticas, los sistemas de software deben ser a tolerante a fallos.

² Se requiere tolerancia a fallos en caso de requisitos de alta disponibilidad o donde los costos de fallo del sistema son muy altos.

² La tolerancia a fallos significa que el sistema puede seguir funcionando a pesar del fallo de software.

² Incluso si el sistema ha sido probado para cumplir con sus especificaciones, sino que también debe ser tolerante a fallos ya que puede haber errores de especificación o la validación puede ser incorrecta.


Arquitecturas de sistemas confiables

² Arquitecturas de sistemas confiables se utilizan en situaciones en las que la tolerancia a fallos es esencial. Estas arquitecturas son generalmente todos se basan en la redundancia y diversidad.

² Ejemplos de situaciones en las que se utilizan arquitecturas confiables: § Sistemas de control de vuelo, en los que un fallo del sistema

podría poner en peligro la seguridad de los pasajeros § Sistemas de reactores que el fallo del sistema de control podría

llevar a una sustancia química o de emergencia nuclear § Sistemas de telecomunicaciones, donde hay una necesidad de

disponibilidad 24/7.


Protección de los sistemas

² Un sistema especializado que está asociado con algún otro sistema de control, puede tomar medidas de urgencia en caso de caída. § Sistema para detener un tren si pasa un alto.§ Sistema para apagar un reactor si la temperatura / presión es

demasiado alta

² Los sistemas de protección controlan de forma independiente el sistema controlado y el medio ambiente.

² Si se detecta un problema, emite órdenes para tomar medidas de emergencia para apagar el sistema y evitar una catástrofe.


Arquitectura de la protección del sistema


Funcionalidad del sistema de protección

² Los sistemas de protección son redundantes, ya que incluyen las capacidades de seguimiento y control que se replican las del software de control.

² Los sistemas de protección deben ser diversas y utilizan una tecnología diferente del software de control.

² Son más simple que el sistema de control de modo más esfuerzo puede ser gastado en la validación y la garantía de fiabilidad.

² El objetivo es asegurarse de que hay una baja probabilidad de fallo


Arquitecturas auto controladas

² Arquitecturas multi-canal en el que el sistema controla sus propias operaciones y toma medidas si se detectan inconsistencias.

² El mismo cálculo se lleva a cabo en cada canal y los resultados se comparan. Si los resultados son idénticos y se producen al mismo tiempo, entonces se asume que el sistema está funcionando correctamente.

² Si los resultados son diferentes, entonces se asume que un fracaso y se levanta una excepción de incumplimiento.


Arquitectura de Autocontrol


Sistemas de Auto-control

² El hardware en cada canal tiene que ser diverso modo que un fallo de hardware en modo común no dará lugar a cada canal de la producción de los mismos resultados.

² Software en cada canal también debe ser diversa, de lo contrario el mismo error de software afectaría a cada canal.

² Si se requiere una alta disponibilidad, puede utilizar varios sistemas de autocontrol en paralelo. § Este es el enfoque adoptado en la familia de aviones Airbus

para sus sistemas de control de vuelo.


Arquitectura del sistema de control de vuelo de Airbus


Analisis sobre la Arquitectura Airbus

² El Airbus FCS tiene 5 equipos distintos, uno cualquiera de los cuales pueden ejecutar el software de control.

² El uso extensivo se ha hecho de la diversidad § Los sistemas primarios utilizan un procesador diferente de los

sistemas secundarios. § Los sistemas primarios y secundarios utilizan chipsets de

diferentes fabricantes. § Software en sistemas secundarios es menos complejo que en el

sistema principal - sólo proporciona funcionalidad crítica. § Software en cada canal se desarrolla en diferentes lenguajes de

programación por diferentes equipos. § Los diferentes lenguajes de programación utilizados en los

sistemas primarios y secundarios.22Capítulo 13 Ingeniería Confiable

Puntos Claves

² La confiabilidad de un programa se puede lograr evitando la introducción de defectos, mediante la detección y eliminación de fallos antes de la implementación del sistema, y la inclusión de las instalaciones de tolerancia a fallos.

² El uso de la redundancia y diversidad en hardware, software y procesos de sistemas de software es esencial para el desarrollo de sistemas confiables.

² El uso de un proceso repetible bien definido es esencial para la reducción de los fallos en un sistema

² Arquitecturas de sistemas confiables son las arquitecturas de sistemas que están diseñadas para tolerancia a fallos. Los estilos arquitectónicos que apoyan la tolerancia a fallos incluyen los sistemas de protección, arquitecturas de auto-monitoreo y programación N-versión.


Capítulo 13 - Ingeniería de Confiabilidad

Ciclo de Conferencias 2


Programación N-versión

² Múltiples versiones de un sistema de software llevan a cabo cálculos al mismo tiempo. Debe haber un número impar de equipos que participan, por lo general 3.

² Los resultados se compararon mediante un sistema de votación y el resultado mayoritario se toma para ser el resultado correcto.

² Enfoque deriva de la noción de redundancia triple modular, tal como se utiliza en sistemas de hardware.


Hardware con tolerancia a fallos

² Depende de triple redundancia modular (TMR).

² Hay tres componentes idénticos replicados que reciben la misma entrada y cuyos resultados se comparan.

² Si una salida es diferente, se ignora y se asume fallo de un componente.

² Sobre la base de la mayoría de los defectos que resulten de fallos de los componentes en lugar de errores de diseño y una baja probabilidad de fallo de un componente simultáneo.


Triple redundancia modular


Programación N-versiones


Programación N-versiones

² Las diferentes versiones de los sistemas son diseñados e implementados por diferentes equipos. Se supone que hay una baja probabilidad de que se cometan los mismos errores. Los algoritmos utilizados pueden pero no deben ser diferentes.

² Existe alguna evidencia empírica de que los equipos comúnmente malinterpretan las especificaciones de la misma manera y eligieron los mismos algoritmos en sus sistemas.


Diversidad en el Software

² Enfoques para la tolerancia a fallos de software dependen de la diversidad del software donde se supone que las diferentes implementaciones de la misma especificación fallará en diferentes maneras.

² Se supone que las implementaciones son: (a) independiente y (b) no incluyen errores comunes.

² Estrategias para lograr la diversidad § Los diferentes lenguajes de programación § Diferentes métodos de diseño y herramientas § Especificación explícita de diferentes algoritmos


Problemas con el diseño y la diversidad

² Los equipos no son culturalmente diversos por lo que tienden a hacer frente a los problemas de la misma manera.

² Errores característicos § Diferentes equipos cometen los mismos errores. Algunas partes

de una aplicación son más difíciles que otros, por lo que todos los equipos tienden a cometer errores en el mismo lugar;

§ Errores de especificación; § Si hay un error en la memoria descriptiva a continuación, esto se

refleja en todas las implementaciones; § Esto puede ser abordado en cierta medida mediante el uso de

múltiples representaciones de especificación.


Dependencia en la Especificación

² Ambos enfoques de la redundancia de software son susceptibles a errores de especificación. Si la especificación es incorrecta, el sistema podría fallar

² Este es también un problema con las especificaciones de hardware pero de software son por lo general más complejo que las especificaciones de hardware y más difícil de validar.

² Esto se ha abordado en algunos casos mediante el desarrollo de especificaciones de software independientes de la misma especificación del usuario.


Mejoras en Practica

² En principio, si la diversidad y la independencia se pueden lograr, programación multi-versión conduce a mejoras muy significativas en la fiabilidad y disponibilidad.

² En la práctica, observaron mejoras son mucho menos importantes, pero el enfoque parece conduce a mejoras en la fiabilidad de entre 5 y 9 veces.

² La pregunta clave es si estas mejoras son la pena los considerables costes de desarrollo adicionales para la programación multi-versión.


Programación Confiable

² Las buenas prácticas de programación se pueden adoptar de forma que ayuden a reducir la incidencia de los defectos del programa.

² Esta programación apoya las prácticas de:§ Evitación de Fallor§ Detección de fallos § Tolerancia a fallos


Directrices sobre buenas prácticas de programación confiable

Directrices de programación confiables

1. Limite la visibilidad de la información en un programa 2. Revise todos los insumos para la validez 3. Proporcionar un controlador para todas las excepciones 4. Reducir al mínimo el uso de construcciones propensas a errores 5. Proporcionar funciones de reinicio 6. Compruebe límites de la matriz 7. Incluir los tiempos de espera al llamar componentes externos 8. Nombrar todas las constantes que representan los valores de la vida real


Control de la visibilidad de la información en un programa

² Los componentes del programa sólo deben permitir el acceso a los datos que necesitan para su implementación.

² Esto significa que la corrupción accidental de partes del estado del programa por parte de estos componentes es imposible.

² Puede controlar la visibilidad por el uso de tipos de datos abstractos, donde la representación de datos es privada y sólo se permitirá el acceso a los datos a través de operaciones predefinidas tales como get () y put ().


Revisar todos las entradas para validar

² Todo programa toma entradas de su entorno y hace suposiciones acerca de estas entradas.

² Sin embargo, las especificaciones del programa rara vez definen lo que debe hacer si una entrada no es coherente con estos supuestos.

² En consecuencia, muchos programas se comportan de forma impredecible cuando se presenta con entradas inusuales y, a veces, estas son las amenazas a la seguridad del sistema.

² En consecuencia, usted debe comprobar siempre las entradas antes del procesamiento en contra de las suposiciones hechas sobre estas entradas de datos.


Controles de validación

² Control de rango § Compruebe que la entrada está dentro de un rango conocido.

² Control del tamaño § Compruebe que la entrada no supera un cierto tamaño por

ejemplo, máxima 40 caracteres para el nombre.

² Control de representación § Compruebe que la entrada no incluye caracteres que no deben

formar parte de su representación por ejemplo, nombres no incluyen números.

² Control de razonabilidad § Utilice la información sobre la entrada para comprobar si es

razonable en vez de un valor extremo.38Capítulo 13 Ingeniería Confiable

Proporcionar un controlador para todas las excepciones

² Una Excepción del programa es un error un tipo de situación inesperado como el corte de la energía.

² El Manejo de excepciones permite controlar esta clase de eventos sin la necesidad de realizar un control constante de las excepciones

² Utilizar un control normal para detectar excepciones requiere al adición de varias sentencias o códigos extras al programa. Esta adición aumenta potencialmente el error.


Manejo de Excepciones


Manejo de Excepciones

² Tres posibles estrategias de manejo de excepciones § Informar a un componente que se ha producido una excepción y

proporcionar información sobre el tipo de excepción. § Llevar a cabo un procesamiento alternativo al tratamiento donde

se produjo la excepción. Esto sólo es posible cuando el controlador de excepciones tiene información suficiente para recuperarse del problema que se ha planteado.

§ Pasar el control a un sistema de soporte en tiempo de ejecución para controlar la excepción.

² El manejo de excepciones es un mecanismo para proporcionar una cierta tolerancia a fallos


Minimizar el uso de construcciones propensas a errores

² Los fallos en los programas son generalmente consecuencia de un error humano porque los programadores pierden la pista de las relaciones entre las diferentes partes del sistema

² Esto se ve agravado por las construcciones propensas a errores en los lenguajes de programación que son inherentemente complejos, o que no comprueban errores cuando podrían hacerlo.

² Por lo tanto, cuando se programa, usted debe tratar de evitar o al menos reducir al mínimo el uso de estas construcciones propensas a errores.


Construcciones propensas a errores

² Salto incondicional (GOTO) ² Números de punto flotante ² Inherentemente imprecisa. La imprecisión puede

llevar a no válidos? Comparaciones. ² Punteros ² Punteros en referencia a las áreas de memoria

equivocadas puede alterar los datos. ² Asignación dinámica de memoria ² Asignación de tiempo de ejecución puede causar

desbordamiento de memoria.



² Paralelismo§ Puede dar lugar a errores sutiles de tiempo debido a la

interacción imprevista entre procesos paralelos. ² Recursividad

§ Los errores en la recursividad puede causar desbordamiento de la memoria como la pila del programa se llena.

² Interrupciones § Las interrupciones pueden causar una operación crítica que

se debe terminar. ² Herencia

§ Código no está traducido. Esto puede dar lugar a un comportamiento inesperado cuando se realizan y los problemas de la comprensión del código cambios.



² Nombres duplicados§ El uso de más de 1 nombre para referirse a la misma variable de

estado. ² Matrices no acotadas

§ Fallos de desbordamiento de búfer, pueden ocurrir si hay comprobación de limites en las matrices o vectores.

² Procesamiento de la entrada por defecto § Una acción de entrada que se produce independientemente de

la entrada. § Esto puede causar problemas si la acción predeterminada

consiste en transferir el control en otra parte del programa. En una entrada incorrecta o deliberadamente malintencionado puede provocar una falla del programa


Proporcionar funciones de reinicio

² Para los sistemas que involucran transacciones largas o las interacciones del usuario, siempre se debe proporcionar una capacidad de reinicio que permite que el sistema se reinicie después de un fallo sin que los usuarios tengan que volver a hacer todo lo que ellos han hecho.

² Reiniciar depende del tipo del sistema § Guarde copias de las formas para que los usuarios no tienen

que rellenarlos de nuevo si hay un problema § Ahorra estado periódicamente y reiniciar desde el estado

guardado


Compruebe límites de la matriz

² En algunos lenguajes de programación, como C, es posible hacer frente a una ubicación de memoria fuera del rango permitido para en una declaración de matriz.

² Esto lleva a la conocida vulnerabilidad "buffer limitado 'donde los atacantes escribir código ejecutable en la memoria por escrito deliberadamente más allá del elemento superior de una matriz.

² Si su idioma no incluye la comprobación de la envolvente, debe, por tanto, comprobar siempre que un acceso a una matriz está dentro de los límites de la matriz.


Incluya los tiempos de espera al llamar componentes externos

² En un sistema distribuido, el fracaso de un equipo remoto puede ser "silencioso" para que los programas que esperan un servicio de ese equipo no pueden recibir el servicio o cualquier indicación de que ha habido un fracaso.

² Para evitar esto, siempre debe incluir los tiempos de espera en todas las llamadas a componentes externos.

² Después de que haya transcurrido un período de tiempo definido sin una respuesta, su sistema, entonces debe asumir el fracaso y tomar todas las acciones requeridas para recuperarse de esto.


Nombra todas las constantes que representan los valores de la vida real

² Siempre dar constantes que reflejan los valores de la vida real (por ejemplo, las tasas de impuestos) los nombres en lugar de utilizar los valores numéricos y siempre se refieren a ellos por su nombre

² Es menos probable que cometa errores y escribe un valor incorrecto cuando se utiliza un nombre en lugar de un valor.

² Esto significa que cuando el cambio estas 'constantes' (por cierto, que no son realmente constante), entonces sólo tiene que hacer el cambio en un lugar en su programa.


Puntos clave

² La diversidad de software es difícil de lograr porque es prácticamente imposible garantizar que cada versión del software es verdaderamente independiente.

² Programación confiable se basa en la inclusión de redundancia en un programa para comprobar la validez de las entradas y los valores de las variables del programa.

² Algunas construcciones y técnicas, tales como sentencias goto, punteros, recursividad, la herencia y los números de punto flotante de programación, son propensos a errores inherentemente. Usted debe tratar de evitar estas construcciones en el desarrollo de sistemas fiables.


Documents

Capítulo 13 -Ingeniería de Confiabilidad · 2020-02-03 · §Sistemas nucleares §Sistemas de control de tráfico aéreo ... §Sistemas de reactores que el fallo del sistema de