Machine Translated by Google

Calidad Total para Software

Gestión de Ingeniería
G. Albeanu y Fl. Popencio Vladicescu

32.1 Introducción
32.1.1 El significado de la calidad del software
32.1.2 Enfoques en el aseguramiento de la calidad del software
32.2 La práctica de la ingeniería de software
32.2.1 Ciclo de vida del software
32.2.2 Proceso de desarrollo de software
32.2.3 Medidas de software
32.3 Modelos de calidad del software
32.3.1 Medición de aspectos de la calidad
32.3.2 Ingeniería de Confiabilidad del Software
32.3.3 Modelos de esfuerzo y costo
32.4 Gestión de calidad total para ingeniería de software
32.4.1 Teoría de Deming
32.4.2 Mejora continua
32.5 Conclusiones

32.1 Introducción procesos y entornos que cumplen o superan

32.1.1 El significado del software
Calidad
Definir la calidad, en general, es una tarea difícil.
Diferentes personas y organizaciones definen la calidad
Expectativas".
¿Qué pasa con el software? El software es el componente
que permite que una computadora o dispositivo digital
para realizar operaciones específicas y procesar datos.
Principalmente, el software consiste en programas de computadora.
Sin embargo, las bases de datos, los archivos y los procedimientos

en un número de diferentes maneras. La mayoría de la gente operativos están estrechamente relacionados con el software. cualquier usuario

asociar la calidad con un producto o servicio en
fin de satisfacer los requerimientos del cliente.
Según Uselac [1], “La calidad no es sólo
productos y servicios, pero también incluye procesos,
medio ambiente y personas”. También, Deming [2], en
su célebre obra dice “que la cualidad tiene muchas
diferentes criterios y que estos criterios cambian
continuamente". Esta es la principal razón para “medir
preferencias de los consumidores y volver a medirlas
frecuentemente”, como observan Goetsch y Davis [3].
Finalmente, concluyen: “La calidad es una dinámica
estado asociado con productos, servicios, personas,
se ocupa de dos categorías de software: el sistema operativo
que controla las operaciones básicas del
sistema digital y el software de aplicación que controla el
procesamiento de datos para computadora específica
aplicaciones como dibujo asistido por ordenador, diseño y
fabricación, procesamiento de textos, etc.
Como cualquier otro producto, el software de calidad es
el que hace lo que el cliente espera
que hacer. El propósito por el cual un sistema de software
se pretende se describe en un documento por lo general
conocida como la especificación de requisitos del usuario.
Los requisitos del usuario se dividen en dos categorías [4]:

567
Machine Translated by Google
568 Prácticas y aplicaciones emergentes
1. capacidades que necesitan los usuarios para lograr un
objetivo o para resolver un problema;
2. Restricciones sobre cómo lograr el objetivo o resolver
el problema.
Los requisitos de capacidad describen las funciones y
operaciones que necesitan los clientes. Estos incluyen al
menos atributos de rendimiento y precisión. Los requisitos
de restricción imponen restricciones sobre cómo se puede
construir y operar el software, y los atributos de calidad de
confiabilidad, disponibilidad, portabilidad y seguridad. Todos
estos requisitos de usuario se traducen en requisitos de
software. Para construir un producto de software de alta
calidad, estos requisitos deben describirse rigurosamente.
Los requisitos de software se pueden clasificar en las
siguientes categorías: funcional, de rendimiento, de interfaz,
operativo, de recursos, de portabilidad, de seguridad, de
documentación, de verificación y pruebas de aceptación, de
calidad, de confiabilidad, de seguridad y de mantenimiento.
Los requisitos funcionales especifican el propósito del
software y pueden incluir atributos de desempeño. Los
requisitos de desempeño especifican valores numéricos
para variables medibles (en general, como un rango de
valores).
Un usuario puede especificar requisitos de interfaz para
hardware, software y comunicaciones. Las interfaces de
software consisten en sistemas operativos y entornos de
software, sistemas de administración de bases de datos y
formatos de archivo. La configuración del hardware está
determinada por los requisitos de la interfaz del hardware.
El uso de algunos protocolos de red especiales y otras
limitaciones de la interfaz de comunicación se registran
como requisitos de la interfaz de comunicación.
Algunos usuarios especifican cómo funcionará el sistema
y cómo se comunicará con los operadores humanos.
Tales requisitos de interfaz de usuario, interacción hombre-
máquina o persona-computadora (el sistema de ayuda, el
diseño de la pantalla, el contenido de los mensajes de error,
etc.) son requisitos operativos.
Como usuario final, la especificación de los límites
superiores de los recursos físicos (potencia de procesamiento,
memoria interna, espacio en disco, etc.) es necesaria,
especialmente cuando las futuras ampliaciones son muy
caras. Estas restricciones se clasifican como recursos.
requisitos El grado en que el software utiliza los recursos
informáticos explica un importante factor de calidad: la
eficiencia.
Siguiendo a Ince [5], otro factor de calidad es la
portabilidad. “Este es el esfuerzo que se requiere para
transferir un sistema de una plataforma de hardware a otra”.
Las posibles computadoras y sistemas operativos, distintos
de los de la plataforma de destino, deben describirse
claramente como requisitos de portabilidad.
La confidencialidad, la integridad y la disponibilidad son
requisitos de seguridad fundamentales. Según Ince,
“Integridad se utiliza para describir hasta qué punto el
sistema y sus datos son inmunes al acceso de usuarios no
autorizados”. Matemáticamente, la integridad es la
probabilidad de que un sistema funcione sin penetración de
seguridad durante un tiempo específico cuando se especifica
una tasa de llegada de amenazas y un perfil de amenazas.
Sin embargo, dicho factor de calidad no se puede medir con
precisión. Para aumentar la seguridad, los comandos de
operador entrelazados, la inhibición de comandos, el acceso
de solo lectura, un sistema de contraseña y la protección
contra virus informáticos son técnicas importantes. Como
dijo Musa [6], la disponibilidad del software es “la fracción
esperada del tiempo operativo durante el cual un componente
o sistema de software funciona aceptablemente”.
Para tener un software confiable, las restricciones
sobre cómo se debe verificar el software deben establecerse
como requisitos de verificación. La simulación, la emulación,
las pruebas con entradas simuladas, las pruebas con
entradas reales y la interfaz con el entorno real son
requisitos comunes de verificación.
También es necesario incluir las pruebas de aceptación
para la validación del software. Sin embargo, la capacidad
de prueba rara vez es especificada por el cliente.
Los requisitos de confiabilidad pueden tener que
derivarse de los requisitos de disponibilidad del usuario.
Es importante mencionar que la confiabilidad está orientada
al usuario. Para Ince, la confiabilidad del software “describe
la capacidad de un sistema de software para continuar
ejecutándose con poca interrupción de su funcionamiento”.
Musa [6] dice que “La confiabilidad del software es el
aspecto más importante de la calidad para el usuario porque
cuantifica qué tan bien funcionará el producto de software
con respecto a sus necesidades”. Mencionamos aquí que
aunque la confiabilidad del hardware y el software tienen la
misma
Machine Translated by Google
Calidad Total para la Gestión de la Ingeniería del Software 569
definición: probabilidad de operación libre de fallas por
un intervalo de tiempo específico, existen diferencias
entre ellas (una falla es cualquier comportamiento en la
operación que causará la insatisfacción del usuario). La
principal diferencia es que la confiabilidad del software
cambia con el tiempo, cuando se eliminan las fallas
durante la prueba de crecimiento de confiabilidad o
cuando se agrega un nuevo código (que posiblemente
contenga fallas adicionales).
Los requisitos de seguridad pueden identificar
funciones críticas para reducir la posibilidad de daños
que pueden derivarse de una falla del software. Como
mencionó Musa [6], la seguridad del software se puede
definir como “la ausencia de percances, donde un
percance es un evento que causa la pérdida de vidas
humanas, lesiones o daños a la propiedad”.
La mantenibilidad o modificabilidad “describe la
facilidad con la que se puede cambiar un sistema
software” según Ince. Describe tres categorías de
modificaciones: cambios correctivos (debido a la
corrección de errores), cambios adaptativos (debido a la
respuesta a cambios en los requisitos) y cambios
perfectivos (que mejoran un sistema). La facilidad de
realizar tales tareas se cuantifica por el tiempo medio
para reparar una falla. Los requisitos de mantenibilidad
se derivan de los requisitos de disponibilidad y
adaptabilidad de un usuario.
Un factor de calidad importante es la corrección: el
sistema de software debe cumplir con las especificaciones
de requisitos. La usabilidad, como otro factor de calidad,
es “el esfuerzo necesario para aprender, operar e
interrumpir un sistema en funcionamiento” como dice
Ince, porque un sistema que cumple todas las funciones
en su especificación de requisitos pero tiene una interfaz
deficiente es altamente inutilizable.
Para cualquier proyecto de software, se debe
proporcionar una documentación correcta y clara
denominada "manual de usuario del software". Son útiles
dos estilos de documentación para el usuario: el tutorial
y el manual de referencia. El estilo tutorial es adecuado
para nuevos usuarios y el estilo de referencia es mejor
para usuarios más experimentados que buscan
información específica.
Existen algunas razones importantes para establecer
un programa de calidad del software. Según Breisford
[7], estos incluyen: reducción del riesgo de producir un
producto de baja calidad, reducción de
el costo del desarrollo de software, mayor satisfacción
del cliente y limitación de la responsabilidad de la
empresa. Para algunos software industriales, el énfasis
está en la confiabilidad y los costos del ciclo de vida,
mientras que para otros, la seguridad es más importante.
Un programa de calidad eficaz es necesario cuando el
cliente lo requiere, como las operaciones de la industria
de defensa, las industrias espacial y nuclear. Como se
menciona en [8], “La gestión de la seguridad forma parte
integral de la gestión de riesgos del proyecto y debe
recibir la misma consideración que la gestión de la
Calidad y la Confiabilidad”. Esta observación también es
válida para el software de computadora. Basta mencionar
el informe [9] sobre la falla del cohete Ariane 5 en 1996,
donde los problemas fueron causados por unas pocas
líneas de código Ada que contenían tres variables
desprotegidas. Según Ince [5], un sistema de calidad
“contiene procedimientos, normas y directrices”. Un
procedimiento es “un conjunto de instrucciones que
describen cómo debe llevarse a cabo una tarea de
software en particular”, y un estándar es un conjunto de
tareas o elementos obligatorios que se deben tener en
cuenta al implementar un procedimiento o un paquete de
procedimientos. Los lineamientos solo aconsejan tomar
en consideración algunos trámites. La literatura sobre
calidad utiliza el término estándar con un significado modificado, per
32.1.2 Enfoques en el aseguramiento de la
calidad del software
El IEEE define el aseguramiento de la calidad del
software como un “patrón planificado y sistemático de
todas las acciones necesarias para brindar la confianza
adecuada de que el artículo o producto cumple con los
requisitos técnicos establecidos” [10]. Una familia
estándar relevante para la industria del software es la
ISO 9000 desarrollada por la Organización Internacional
para la Estandarización. Más precisamente, ISO 9001 [11]
“Sistemas de calidad: modelo para el aseguramiento de
la calidad en el diseño, desarrollo, producción, instalación
y mantenimiento” describe el sistema de calidad utilizado
para respaldar el desarrollo de un producto que implica
diseño; ISO 9003 [12] “Directrices para la aplicación de
ISO 9001 al desarrollo, suministro y mantenimiento de
software” interpreta la ISO 9001 para el desarrollador de
software; ISO 9004-2 [13] “Gestión de la Calidad y
Sistema de Calidad
Machine Translated by Google
570 Prácticas y aplicaciones emergentes
Elementos—Parte 2” proporciona pautas para la
servicio de software.
Hay 20 elementos para describir el
requisitos: responsabilidad de la dirección; calidad
sistema; revisión del contrato; control de diseño; documento
y control de datos; adquisitivo; suministrado por el comprador
producto; identificación y trazabilidad de productos;
control de procesos; inspección y prueba; control
de equipos de inspección, medición y ensayo;
estado de inspección y prueba; Control de producto no
conforme; correctivo y preventivo
acción; manipulación, almacenamiento, embalaje,
conservación y entrega; registros de calidad; calidad interna
auditorías; capacitación; mantenimiento; técnicas estadísticas.
Otro enfoque es el de "Madurez de la capacidad".
Model for Software” (CMM) [14], desarrollado por
el Instituto de Ingeniería de Software (SEI). los
SEI ha sugerido que hay cinco niveles de
madurez del proceso, que va desde la etapa inicial (la
menos predecible y controlable) a repetible,
definida, gestionada y optimizada (lo más
predecible y controlable).
Los conceptos fundamentales que subyacen al proceso.
madurez aplicada para la organización del software son: la
proceso de software; La capacidad; el desempeño;
y la madurez. El proceso de software es un "conjunto
de actividades, métodos, prácticas y transformaciones”
utilizadas por las personas para desarrollar y mantener
el software y los productos asociados (manuales de usuario,
documento arquitectónico, documento de diseño detallado,
código y planes de prueba). La capacidad del
proceso de software ejecutado por una organización proporciona
una base para predecir los resultados esperados que pueden ser
logra siguiendo el proceso del software. Tiempo
la capacidad del proceso de software se centra en los
resultados esperados, el rendimiento del proceso de software
representa los resultados reales alcanzados. la madurez es
un concepto que implica la capacidad de crecimiento en
capacidad y da el grado de maduración en
definir, administrar, medir, controlar y
correr. Como corolario, una organización de software
ganancias en la madurez del proceso de software al ejecutar
su proceso de software a través de políticas, estándares y
Estructuras organizacionales. Una breve descripción de
el CMM sigue.
Excepto por el Nivel 1, cada una de las cuatro capacidades
niveles tiene un conjunto de áreas clave de proceso que un
organización debe enfocarse para mejorar su
proceso de software. El primer nivel describe un
proceso de desarrollo de software que es caótico, un
enfoque ad hoc basado en esfuerzos individuales (un
genio que tiene una idea brillante), no en el equipo
logros El modelo de madurez de la capacidad
enfatiza el control cuantitativo del proceso,
y los niveles superiores dirigen a una organización a utilizar
medición y análisis cuantitativo.
Cada área de proceso clave comprende un conjunto de
prácticas que muestren el grado (efectivo, repetible, duradero)
de la implementación e institucionalización de esa área. El
área clave del proceso de
el segundo nivel contiene las siguientes prácticas clave:
gestión de requisitos; proyecto de software
planificación, seguimiento y supervisión de proyectos de software;
gestión de subcontratos de software; aseguramiento de la
calidad del software y gestión de la configuración del software.
En este nivel “gestión básica de proyectos
Se establecen procesos para rastrear costos, cronogramas,
y funcionalidad”. Hay una disciplina entre
miembros del equipo, para que el equipo pueda repetir antes
éxitos en proyectos con aplicaciones similares. A
el nivel definido (Nivel 3), “el proceso de software
tanto para actividades de gestión como de ingeniería
está documentado, estandarizado e integrado en
un proceso de software estándar para la organización”.
Dado que algunos proyectos difieren de otros, el proceso
estándar, bajo la aprobación de la dirección,
se adapta a las necesidades especiales. El proceso clave,
en este nivel de madurez, está orientado a aspectos
organizacionales: enfoque de procesos organizacionales;
definición del proceso de la organización; programa de
entrenamiento; gestión integrada de software; producto de software
ingeniería; coordinación intergrupal y revisiones por pares.
Un proceso administrado (Nivel 4) agrega supervisión de la
administración a un proceso definido: “detalle
medidas del proceso y producto del software
se recoge la calidad”. Hay información cuantitativa sobre el
proceso de software y los productos para comprenderlos y
controlarlos. Proceso clave
las áreas se centran en la gestión cuantitativa de procesos
y gestión de la calidad del software. Un proceso de
optimización es el último nivel de madurez del proceso, donde
se incorpora la retroalimentación cuantitativa.
en el proceso para producir proceso continuo
mejoras Las áreas clave del proceso incluyen: defecto
Machine Translated by Google
Calidad Total para la Gestión de la Ingeniería del Software 571
prevención; gestión del cambio tecnológico; y gestión de
cambios de procesos.
Finalmente, los siguientes elementos reanudan el CMM
estructura:
1. los niveles de madurez indican la capacidad del
proceso y contienen áreas clave del proceso; 2. las
áreas clave del proceso logran objetivos y están
organizadas por características comunes; 3. las
características comunes abordan la implementación y la
institucionalización y contienen prácticas clave que
describen la infraestructura o las actividades.
El CMM fue el punto de partida para producir nuevos
métodos de evaluación de procesos. Solo notamos el
enfoque bootstrap [15] (una extensión del CMM desarrollado
por un proyecto ESPRIT de la Comunidad Europea) y el
nuevo estándar llamado SPICE [16] (para la mejora del
proceso de software y la determinación de la capacidad).
Al igual que CMM, SPICE se puede utilizar tanto para la
mejora de procesos como para la determinación de la
capacidad. El modelo SPICE considera cinco actividades:
suministrada por el cliente, ingeniería, proyecto, soporte y
organización, mientras que las prácticas genéricas,
aplicables a todos los procesos, se organizan en seis
niveles de capacidad: 0—“no realizado”, 1—“realizado
informalmente”, 2—“planificado y rastreado”, 3—“bien
definido”, 4—“controlado cuantitativamente”, 5—“mejorando
continuamente”. Un informe de evaluación, un perfil, para
cada área de proceso describe el nivel de capacidad.
Al finalizar esta sección, el lector debe observar que
CMM tiende a abordar el requisito de mejora continua de
procesos de manera más explícita que ISO 9001, y que
CMM aborda organizaciones de software mientras que
SPICE aborda procesos.
Sin embargo, independientemente del modelo que se
utilice, la evaluación debe administrarse de modo que se
minimice la subjetividad en las calificaciones.
32.2 La práctica de la ingeniería
de software 32.2.1 Ciclo de vida
del software
La creciente complejidad del software y las limitaciones de
costo y tiempo contra la confiabilidad del software.
La maximización para la mayoría de los proyectos de
software ha hecho obligatorio el uso de un enfoque
estandarizado en la producción de dichos elementos.
El conjunto de técnicas que aplican un enfoque de
ingeniería a la construcción y soporte de software se
conoce como “ingeniería de software”. Los fundamentos
teóricos para el diseño y desarrollo de software los
proporciona la informática. Sin embargo, la ingeniería de
software proporciona el mecanismo para implementar el
software de forma controlada y científica. Según [17], la
ingeniería del software es “la aplicación de un enfoque
sistemático, disciplinado y cuantificable al desarrollo,
operaciones y mantenimiento del software, es decir, la
aplicación de la ingeniería al software”. Es posible decir,
como en [18, 19] que “la ingeniería de software está
evolucionando de un arte a una disciplina de ingeniería
práctica”.
Este enfoque también fue adoptado por ESA [4], que
establece y mantiene estándares de ingeniería de software
para la adquisición, desarrollo y mantenimiento de software.
El estándar ESA PSS-05-0 describe los procesos
involucrados en el ciclo de vida completo del software.
Organizado en dos partes, el estándar define un conjunto
de prácticas para hacer productos de software. Dichas
prácticas también se pueden utilizar para implementar los
requisitos de ISO 9001. La Junta de Estandarización y
Control de Software de la ESA dice que [20]:
1. Los Estándares de Ingeniería de Software de la ESA
son una base excelente para un sistema de gestión
de la calidad del software; 2. los estándares de la ESA
cubren prácticamente todos los requisitos para el
desarrollo de software: dos tercios de los requisitos
de la norma ISO 9001 están cubiertos por los
estándares de ingeniería de software de la ESA, y los
requisitos descubiertos no están relacionados con el
desarrollo de software; 3. las normas ESA no
contradicen las de ISO 9001.
Según [4], el ciclo de vida de un software consta de las
siguientes seis fases sucesivas: (1) definición de los
requisitos del usuario; (2) definición de los requisitos del
software; (3) definición del diseño arquitectónico; (4) diseño
detallado y producción de código; (5) transferencia del
software
Machine Translated by Google
572 Prácticas y aplicaciones emergentes
a las operaciones; (6) operaciones y mantenimiento.
Estas fases son obligatorias cualquiera que sea el tamaño, el
tipo de aplicación, la configuración del hardware, el funcionamiento
sistema o lenguaje de programación utilizado para codificar. El
ciclo de vida del software comienza con la entrega
del "documento de requisitos del usuario" al desarrollador para
su revisión. Cuando este documento sea aprobado,
tres fases importantes tienen que ser atravesadas antes
el software se transfiere a los usuarios para su funcionamiento.
Para iniciar una nueva etapa, los resultados de la
fase anterior son revisados y aprobados. los
el ciclo de vida del software termina después de un período de operación,
cuando se retira el software.
Pham [19], considerando la confiabilidad del software
reino, identifica cinco fases sucesivas para el ciclo de vida del
software: análisis (requisitos y especificaciones funcionales),
diseño, codificación, prueba y
operando. Desde el punto de vista de la fiabilidad, “un
una especificación bien desarrollada puede reducir la incidencia
de fallas en el software y minimizar la repetición del trabajo”.
Es bien sabido (ver [19]) que un bien hecho
análisis “generará recompensas significativas en términos
de confiabilidad, mantenibilidad, productividad,
y calidad general del software”. La fase de diseño
consta de dos etapas de diseño: diseño de arquitectura de
sistema y diseño de detalle”. Las principales actividades en la
etapa de diseño de la arquitectura del sistema son:
(1) construcción del modelo físico; (2) especificar el diseño
arquitectónico; (3) seleccionando el
lenguaje de programación (o desarrollo de software)
ambientes); y (4) revisar el diseño.
Usando la terminología de implementación, el desarrollador
derivará un modelo físico a partir de
el modelo lógico desarrollado en la fase de análisis
(etapa de requisitos de software). Para construir un modelo
físico, algunas actividades son importantes: la descomposición
del software en componentes (un
enfoque de arriba hacia abajo, pero cuidado con los
componentes de nivel inferior); la implementación de requisitos
no funcionales; el diseño de calidad
criterios; y especial atención a alternativas
diseños La última actividad es necesaria porque, en
En general, no existe un diseño único para un software.
sistema. El diseño tiene que ser fácil de modificar y
mantener, solo hacer un uso mínimo de los recursos disponibles
recursos, y debe ser comprensible para
ser efectivamente construido, operado y mantenido.
Otros criterios de calidad relacionados con el diseño son: la
sencillez de forma y función, y la modularidad.
El documento de diseño arquitectónico contiene
diagramas que muestran el flujo de datos y el control
flujo entre los componentes. Para cada componente
se especifican: entrada de datos, funciones a ser
realizado (derivado de un requisito de software
documento) y salida de datos. Entrada de datos, datos
salida, y las celdas de memoria temporal son claramente
definidas como estructuras de datos (con nombre, tipo,
dimensión, relaciones entre los elementos,
rango de valores posibles de cada elemento, y
valores iniciales de cada elemento). La definición
del flujo de control entre componentes
describe operaciones secuenciales y paralelas,
incluyendo también síncrono y asíncrono
comportamiento. Sobre esta fase, Pham dice que “la
el documento de arquitectura del sistema describe el sistema
componentes, subsistemas e interfaces”.
Las estructuras de datos y algoritmos seleccionados,
en la fase de diseño detallado, se implementará en un lenguaje
de programación particular en
una plataforma particular (sistema de hardware y software).
Los lenguajes de programación seleccionados deben
admite descomposición de arriba hacia abajo, orientada a objetos
programación y producción simultánea de los
software. Además, la elección de un lenguaje de programación
depende de los requisitos no funcionales. Finalmente, el diseño
arquitectónico y la
El lenguaje de programación debe ser compatible.
El diseño detallado se trata de diseñar el proyecto.
y los detalles algorítmicos. Los componentes de nivel inferior
del diseño arquitectónico se descomponen
hasta que puedan presentarse como módulos o funciones en
el lenguaje de programación seleccionado. Para
muchos proyectos recientes, un orientado a objetos (OO)
Se ha considerado el enfoque de análisis y diseño. Los
objetivos del análisis OO son identificar todos los objetos
principales en el dominio del problema, incluidos todos los
datos y las operaciones principales obligatorias.
para establecer las funciones del software, y para
producir un diagrama de clases que contenga toda la semántica
del proyecto de software en un conjunto de instrucciones concisas pero
definiciones detalladas. Una especificación de clase y una
diccionario de datos también se entregan. El diseño OO
mapea el desarrollo del producto de análisis durante el
fase de análisis a una estructura que permitirá la
Machine Translated by Google
Calidad Total para la Gestión de la Ingeniería del Software 573
codificación y ejecución. Varias metodologías llaman a este
enfoque OOA/OOD porque en una actividad práctica de
análisis/diseño, es casi imposible encontrar los límites entre
OOA y OOD.
La producción de software, después de la fase de diseño
detallado, comienza con la codificación. El código debe ser
coherente (para reducir la complejidad) y estructurado (para
reducir los errores y mejorar la capacidad de mantenimiento).
Desde el punto de vista de la programación estructurada,
cada módulo tiene una sola entrada y un punto de salida, y
el flujo de control procede desde el principio hasta el final.
Según [4], “a medida que avanza la codificación de un
módulo, la documentación de los supuestos de diseño, la
función, la estructura, la interfaz, los datos internos y la
utilización de los recursos debe proceder al mismo tiempo”.
Como dice Pham, el proceso de codificación consta de las
siguientes actividades: la identificación de los "módulos
reutilizables", la edición del código, la "inspección" del código
y la "planificación de la prueba final". Los módulos existentes
de otros sistemas o proyectos que son similares al sistema
actual se pueden reutilizar con modificaciones.
Esta es una forma efectiva de ahorrar tiempo y esfuerzo. “La
inspección de código incluye revisiones de código, calidad y
mantenibilidad”. El objetivo del proceso de revisión del
código es comprobar la lógica y la legibilidad del módulo
(software). “La verificación de calidad garantiza que todos
los módulos realicen la funcionalidad descrita en el diseño
detallado. El control de calidad se centra en la fiabilidad, el
rendimiento y la seguridad”.
La mantenibilidad se verifica para garantizar que el proyecto
de software sea fácil de mantener. El plan de prueba final
proporciona información para la fase de prueba: lo que debe
probarse, las estrategias y métodos de prueba, los programas
de prueba, etc.
Además, un paso importante en la fase de producción,
incluso antes de la prueba, es la integración. Como menciona
ESA [4], “la integración es el proceso de construcción de un
sistema de software mediante la combinación de componentes
en una entidad de trabajo” y debe proceder en una secuencia
ordenada función por función.
Las pruebas consisten en la verificación y validación del
producto de software. Los objetivos de estas actividades
están relacionados con la calidad del software. El objetivo
más importante es afirmar la calidad detectando y eliminando
fallas en el software.
proyecto. A continuación, todas las funcionalidades
especificadas del software deben estar presentes en el
producto. Finalmente, pero como un objetivo considerable,
está la estimación de la confiabilidad operativa del producto de software
uct.
El proceso de prueba de un sistema de software integrado
se denomina "prueba del sistema". Los procesos previos
relacionados con la fase de pruebas son: pruebas unitarias
y pruebas de integración. Las pruebas unitarias comprueban
el diseño y la implementación de todos los componentes,
“desde el nivel más bajo definido en la fase de diseño
detallado hasta el más bajo definido en el diseño
arquitectónico” según los estándares de la ESA. Las pruebas
de integración están dirigidas a la parte de interfaz: para
verificar que los componentes principales interactúan
correctamente (tanto como estructuras de datos como niveles
de flujo de control). El equipo de prueba debe incluir un gran
conjunto de actividades, como: pruebas de sistema de
extremo a extremo (el conducto de entrada-ejecución-salida
funciona correctamente); verificación de que los requisitos
de los usuarios serán cubiertos en su totalidad (pruebas de
aceptación); mediciones de límites de rendimiento (pruebas
de estrés); estimación preliminar de confiabilidad y
mantenibilidad; y la verificación del “manual de usuario del
software”. Según Pham [19], la prueba de aceptación consta
de una prueba interna y una prueba de campo. “La prueba
interna incluye la prueba de capacidad y la prueba de
invitado, ambas realizadas internamente. La prueba de
capacidad prueba el sistema en un entorno configurado de forma similar
La prueba de invitado la realizan los usuarios en sus sitios
de organización de software”. La prueba de campo, también
llamada “prueba beta”, permite al usuario probar el software
instalado, definiendo y desarrollando los casos de prueba.
“Las pruebas realizadas por un grupo independiente
garantizan que el sistema cumple con la intención de los
requisitos originales”.
Teniendo en cuenta la fase de transferencia, el
desarrollador “instalará el software en el entorno operativo y
demostrará al iniciador y a los usuarios que el software tiene
todas las capacidades” formuladas en la fase de requisitos
del usuario.
Las pruebas de aceptación demostrarán las capacidades del
software en su entorno operativo y son necesarias para la
aceptación provisional.
La decisión final de aceptación la toma el cliente.
Machine Translated by Google
574 Prácticas y aplicaciones emergentes
La fase final del ciclo de vida del software es la
operación, que consta de las siguientes actividades:
capacitación, soporte y mantenimiento. Siguiendo a Pham
[19], el mantenimiento se define como “cualquier cambio
realizado en el software, ya sea para corregir una
deficiencia en el rendimiento, para compensar cambios
ambientales o para mejorar su funcionamiento”. Después
de un período de garantía, el mantenimiento del software
se transfiere del desarrollador a una organización de
mantenimiento dedicada.
32.2.2 Proceso de desarrollo de software objetos para mejorar la calidad del software aprovechando
Un modelo de proceso de software es diferente de una
metodología de software. El modelo de proceso determina
las tareas o fases involucradas en el desarrollo del
producto y todos los criterios para pasar de una tarea a
la siguiente. La metodología del software define los
resultados de cada tarea y describe cómo deben lograrse.
El enfoque ESA, Parte I, describe un modelo de proceso
de software y para cada fase describe las entradas,
salidas y actividades.
La segunda parte del estándar ESA describe los
procedimientos utilizados para gestionar un proyecto de software.
Estos aspectos se tratarán en la Sección 32.4.
Es difícil definir claramente qué métodos deben
usarse para completar una fase del desarrollo y
producción del producto. Como comenta Cederling [21],
“casi ningún método es adecuado para usar en el
desarrollo de todo tipo de aplicaciones y solo existen
unos pocos métodos que pretenden cubrir todo el ciclo
de vida del software”. Desde el punto de vista de la
calidad del software, los pasos se pueden organizar en
tres elementos: gestión de la calidad del software,
ingeniería de la calidad del software y control de la
calidad del software. Tales aspectos se discutirán en la
Sección 32.3.
Hay tres procesos de desarrollo de software
favorecidos: el modelo en cascada, el modelo en espiral
y el entorno de desarrollo de software integrado genérico.
ESA [20] también sugiere tres modelos de ciclo de vida
llamados: cascada, incremental y evolutivo. El modelo en
cascada es el más utilizado; es un enfoque secuencial y
los pasos de implementación son las actividades en la
secuencia en que aparecen. Esta es la razón principal
por la que los cronogramas de desarrollo pueden basarse
fácilmente en él. En
En el modelo espiral, cada ciclo implica una progresión a
través de la misma serie de pasos, que se aplican a todo,
desde el concepto general hasta la codificación detallada
del software. Tal enfoque se aplica al desarrollo y
mantenimiento. Según [20], el modelo incremental “divide
la fase de diseño detallado en partes manejables”. El
entorno integrado genérico se utiliza cuando es necesaria
una integración global de las herramientas residuales del
proyecto. El impacto de los métodos orientados a objetos
en la calidad del software es muy importante. Capper et
al. [22], muestra cómo y cuándo utilizar la orientación a
la reutilización y la modularidad del código. ESA [20]
explica las ventajas de un enfoque orientado a objetos:
“el análisis corresponde más estrechamente al dominio
de la aplicación”, “el diseño (modelo físico) es una
elaboración del modelo de análisis de requisitos (el
modelo lógico)”, y “Los métodos orientados a objetos
utilizan el concepto de herencia que, si se utiliza
adecuadamente, permite la construcción de software
reutilizable”. Estos métodos orientados a objetos que
recomiendan bucles de retroalimentación entre las fases
de análisis, diseño e implementación cuando se incluyen
en un estándar de ingeniería de software requieren un
tratamiento especial para mantener el concepto PSS-05-0
de fases de desarrollo bien definidas.
El desarrollo de software con prototipos es un nuevo
enfoque. Como se menciona en [5], “la creación de
prototipos es el proceso de desarrollar un modelo
funcional de un sistema en las primeras etapas de un
proyecto”. El modelo de trabajo se muestra al cliente,
quien sugiere mejoras. La incorporación de mejoras da
lugar a un prototipo mejorado que se vuelve a mostrar al
cliente y el proceso puede continuar.
La producción de un prototipo se basa en las siguientes
técnicas: la relajación de los estándares de garantía de
calidad del proyecto; implementación parcial; el enfoque
del procesador basado en tablas; el uso de un lenguaje
de programación orientado a aplicaciones, etc. Los
lenguajes de programación orientados a objetos también
son un medio excelente para la creación de prototipos
(ver [23]). Hay tres modelos populares de creación de
prototipos: creación de prototipos desechables, creación
de prototipos evolutivos y creación de prototipos
incrementales. Mediante la creación de prototipos
desechables, eficaz para proyectos cortos, el desarrollador construy
Machine Translated by Google
Calidad Total para la Gestión de la Ingeniería del Software 575
luego comienza el proceso iterativo de mostrar:
modificación ya descrita. Cuando el “juego”
está terminado, el prototipo está archivado y
se inicia el desarrollo de software convencional,
basado en una especificación de requisitos escrita
examinando la funcionalidad detallada del
prototipo. La creación de prototipos evolutivos permite la
desarrollador “para mantener vivo el prototipo” como Ince
dice. Después de que el cliente haya decidido que todos
se incluyen los requisitos, las bases del desarrollador
el resto del trabajo en el prototipo
ya generado. El prototipo incremental es
eficaz para proyectos donde los requisitos pueden
dividirse en áreas funcionalmente separadas, el
El sistema se está desarrollando como una serie de piezas pequeñas,
cada uno de ellos implementando un subconjunto de funciones.
Una ingeniería basada en la teoría y orientada al equipo
El proceso para desarrollar software de alta calidad es
el enfoque de sala limpia. Según [24], la
proceso de sala limpia “combina métodos formales de
especificación y diseño de la estructura de la caja basada en
objetos, verificación de la corrección teórica de la función,
y pruebas de uso estadístico para la certificación de confiabilidad
para producir software que se acerque a cero
defectos”. El desarrollo de software para salas limpias
El método tiene tres atributos principales [25]: un conjunto de
actitudes; una serie de procesos cuidadosamente prescritos;
y una base matemática rigurosa. “Sala blanca
Los procesos son bastante específicos y se prestan
al control de procesos y medidas estadísticas”. Como
Una vez mencionado, “un método formal de software
desarrollos hace uso de las matemáticas para la especificación
y el diseño de un sistema, junto con
la demostración matemática como método de validación”. Los
métodos formales requieren los mismos modelos de desarrollo
convencionales, a diferencia de los prototipos y la tecnología
orientada a objetos. Una nueva matemática útil
marco importante para los desarrolladores de software es
el proceso de jerarquía analítica generalizada [26],
que proporciona información cualitativa y cuantitativa para la
asignación de recursos.
El final de la década de 1980 trajo nuevos gráficos
herramientas de software para la especificación de requisitos y
herramientas de diseño, llamadas ingeniería de software
asistida por computadora (CASE), con las siguientes capacidades:
(1) creación de los diagramas que describen las funciones del
sistema de software; (2) creación de la
diagramas que describen el diseño del sistema tanto del
procesos y los datos en el sistema; (3) procesamiento de la
especificación de requisitos gráficos y
simulando sus acciones como un prototipo rudimentario; (4) la
identificación de errores en el flujo de
datos; (5) la generación de código a partir del diseño;
y (6) el almacenamiento y manipulación de información
relacionada con la gestión del proyecto. Estas
herramientas mejoran el sistema de gestión de la calidad
de las empresas de desarrollo de software al hacer cumplir
su propia especificación y sistema de requisitos
estándares de diseño, y haciendo un montón de trámites burocráticos
comprobando actividades.
32.2.3 Medidas de software
Como mencionan Fenton y Pfleeger [27], podemos
ni predecir ni controlar lo que no podemos medir. La medición
“nos ayuda a entender lo que
está sucediendo durante el desarrollo y el mantenimiento”, “nos
permite controlar” y “alienta
para mejorar nuestros procesos y productos”. La medición es
el primer paso hacia la calidad del software
mejora. Por la variedad y complejidad
de productos de software, procesos y operaciones
condiciones, no se puede identificar un sistema métrico único
como una medida de la calidad del software. Varios
atributos tienen que ser medidos, relacionados con:
• el producto en sí: tamaño, complejidad, modularidad,
reutilización, flujo de control, flujo de datos, etc.;
• el proceso de desarrollo: costo y esfuerzo
estimación, productividad, cronograma, etc.;
• calidad y confiabilidad: fallas, correcciones,
tiempos a fallas, densidad de fallas, etc.;
• mantenimiento y actualización: documentación,
etc.
La calidad de cualquier programa de medición es
depende de una cuidadosa recopilación de datos. Por ejemplo,
Para realizar un análisis de confiabilidad, se deben recopilar
los siguientes tipos de datos: internos
atributos (tamaño, idioma, funciones, verificación
y métodos y herramientas de validación, etc.) y atributos
externos (tiempo de ocurrencia de la falla, naturaleza
de los fallos, consecuencia, la versión actual de
el entorno de software en el que se ha producido el fallo
sido activado, condiciones bajo las cuales la falla
Machine Translated by Google
576 Prácticas y aplicaciones emergentes
ha sido activado, tipo de fallas, localización de fallas, etc.).
Según [27], “un atributo interno puede medirse examinando
el producto, proceso o recurso por sí solo, separado de su
comportamiento”, mientras que los atributos externos están
relacionados con el comportamiento del proceso, producto o
recurso y “ puede medirse sólo con respecto a cómo el
producto, proceso o recurso se relaciona con su entorno”.
Considerando el proceso de construcción de la especificación,
los atributos internos son: tiempo, esfuerzo, cantidad de
cambios en los requisitos, etc. y calidad, costo, estabilidad
son algunos atributos externos. Cualquier artefacto,
entregable o documento que resulte de una actividad de
proceso se identifica como producto: las especificaciones,
diseños, código, prototipos, documentos, etc. Por ejemplo, si
estamos interesados en medir el código de un producto de
software, el interno Los atributos cubren: tamaño, reutilización,
modularidad, funcionalidad, acoplamiento, complejidad
algorítmica, estructuras de flujo de control, estructuras de
clases jerárquicas (el número de clases, funciones e
interacciones de clases), etc. Algunas métricas de procesos
de software populares son: número de "problemas"
encontrados por el desarrollador, número de "problemas"
encontrados durante las pruebas beta, número de "problemas"
solucionados que fueron encontrados por el desarrollador en
una versión anterior, número de "problemas" solucionados
que fueron encontrados por las pruebas beta en la versión
anterior, número de "problemas" resueltos que el cliente
encontró en la versión anterior, número de cambios en el
código debido a nuevos requisitos, número total de cambios
en el código por cualquier motivo, número de requisitos
distintos que provocaron el cambio s al módulo, aumento
neto de líneas de código, número de miembros del equipo
que realizan cambios, número de actualizaciones de un
módulo, etc.
Medir el tamaño de los productos de software es
consistente con los principios de la teoría de la medición [27].
El tamaño del software se puede describir con tres atributos:
longitud (el tamaño físico del producto), funcionalidad (las
funciones proporcionadas por el producto al usuario) y
complejidad del problema, algoritmos, estructura del software
y esfuerzo cognitivo.
La medida más utilizada de la longitud del programa de
código fuente es el LOC (número de líneas de código), a
veces interpretado como NCLOC (solo líneas no comentadas)
o ELOC (efectivo).
líneas de código). Sin embargo, la dependencia del lenguaje
de programación y el impacto de los entornos de ventanas
de programación visual son factores importantes que tienen
una gran influencia en el código. La longitud también es una
medida para las especificaciones y el diseño, que consta
tanto de texto (la longitud del texto) como de diagramas (la
longitud del diagrama). Otras métricas de declaraciones son:
número de archivos distintos incluidos, número de
declaraciones de control, número de declaraciones
declarativas, número de declaraciones ejecutables, número
de variables globales utilizadas, etc.
La funcionalidad captura "la cantidad de función contenida
en un producto entregado o en una descripción de cómo se
supone que debe ser el producto"
[27]. Hay tres enfoques comúnmente utilizados: el método
de estimación del esfuerzo de Albrecht (basado en puntos
de función), COCOMO 2.0 (basado en puntos de objeto) y el
peso de especificación de DeMarco.
La complejidad es difícil de medir. La complejidad de un
enfoque se da en términos de los recursos necesarios para
implementar dicho enfoque (el tiempo de ejecución de la
computadora o la memoria de la computadora utilizada para
el procesamiento). Como menciona Pham [19], "la teoría de
la métrica del software de Halstead es probablemente la
técnica más conocida para medir la complejidad de un
programa de software y la cantidad de dificultad que implica
probar y depurar el software". Sin embargo, el foco de las
medidas de Halstead es el código fuente de un lenguaje
imperativo. Este enfoque del software basado en la
programación declarativa no es adecuado. Las siguientes
métricas, utilizadas por Halstead, dan lugar a modelos
empíricos: el número de operadores distintos y el número de
operandos distintos en un programa para desarrollar
expresiones para la longitud total del programa, el volumen
y el número de defectos restantes en un programa. Otra
medida métrica de la complejidad del software es el número
ciclomático, propuesto por McCabe (ver [19, 27] y las
referencias citadas allí), que proporciona una medida
cuantitativa de la complejidad lógica de un programa contando
los puntos de decisión.
La observación anterior también se aplica a los entornos de
software visual, especialmente a la programación orientada
a objetos, que necesita una medida de complejidad especial.
seguro
Machine Translated by Google
Calidad Total para la Gestión de la Ingeniería del Software 577
La estructura del software tiene al menos tres partes:
estructura de flujo de control (abordando la secuencia en
qué instrucciones se ejecutan), la estructura del flujo de datos
(que muestra el comportamiento de los datos a medida que
interactúan con el software) y la estructura de los datos (incluidos
los arreglos de datos y los algoritmos para crearlos, modificarlos
o eliminarlos). La complejidad
de las estructuras de flujo de control se obtiene usando
medidas jerárquicas, cada programa de computadora
construyéndose de manera singular a partir de los llamados
estructuras primos de acuerdo con los principios de programación
estructurada. Algunos controles de flujo populares
las métricas gráficas (para diagramas de flujo) son: número de arcos
que no son arcos condicionales, número de non-loop
arcos condicionales (construcciones si-entonces), número de
construcciones de bucle, número de nodos internos, número de
nodos de entrada, número de nodos de salida, etc.
Los atributos del producto de software externo serán
considerado en la siguiente sección. sin presentar
ecuaciones, el enfoque descriptivo anterior muestra
lo que tienen los desarrolladores, los administradores de software
medir para comprender, controlar y
evaluar. Se prestará especial atención a los datos
colección no sólo para diferentes medidas internas, sino también
para la investigación de relaciones
y tendencias futuras.
32.3 Modelos de calidad del software
32.3.1 Medición de aspectos de la calidad
En la primera sección señalamos que la calidad es un compuesto
de muchas características. Temprano
modelos de Boehm et al. [28] y McCall et al.
[29] describió la calidad por descomposición. Ambas cosas
Los modelos identifican los atributos clave de la calidad a partir de
la perspectiva del cliente, llamados factores de calidad,
que se descomponen en atributos de nivel inferior,
llamados criterios de calidad y directamente medibles.
Por ejemplo, el modelo de McCall considera los siguientes
factores de calidad: usabilidad, integridad, eficiencia,
corrección, confiabilidad, mantenibilidad, comprobabilidad,
flexibilidad, reutilización, portabilidad e interoperabilidad.
Observamos que la mayoría de estos factores también
describir los requisitos de software que fueron
descrito en la primera sección.
Una derivación del modelo de McCall, llamado "Evaluación
de productos de software: características de calidad".
y Directrices para su Uso”, es conocida como la
Modelo de calidad estándar ISO 9126, descomposición
la calidad solo en seis factores de calidad: funcionalidad,
confiabilidad, eficiencia, usabilidad, mantenibilidad,
y portabilidad [30]. Desafortunadamente, las definiciones
de estos atributos difieren de un estándar a otro.
otro.
Otro enfoque amplía las ideas de Gilb [31]
y proporciona una forma automatizada de usarlos: el
COQUAMO modelo de Kitchenham y Walker
[32]. Otros enfoques ven la calidad del software como
una ecuación basada en medidas basadas en defectos, medidas
de usabilidad y medidas de mantenibilidad.
Algunas medidas populares son: la densidad del defecto
(dado como la división del número de conocidos
defectos por el tamaño del producto), el deterioro del sistema
(la división del tiempo para corregir los defectos posteriores al
lanzamiento por el tiempo total de desarrollo del sistema), el
medidas de rendimiento del usuario definidas por MUSiC
proyecto [33], el esfuerzo total dedicado al mantenimiento [34], la
medida de legibilidad de Gunning [35]
(para documentación escrita), etc. Otras medidas
aparecerá en las próximas secciones. Recientemente, aparecieron
herramientas de software sofisticadas para apoyar a los
desarrolladores de software, con modelos de calidad de software.
Por ejemplo, [36] describe el soporte de decisiones
herramienta EMERALD (medición mejorada para la
Sistema de Evaluación de Riesgos de Defectos Latentes). Como
[37] señala que tales herramientas “son la clave para mejorar
calidad del software” y puede “predecir qué módulos
es probable que sean propensos a fallas” usando la base de datos de
medidas disponibles.
32.3.2 Confiabilidad del software
Ingeniería
Mejorar la confiabilidad de un producto de software puede
obtener midiendo diferentes atributos durante la fase de desarrollo
del software. Medición
utiliza los resultados de un proceso de recopilación de datos. Dos
tipos de datos están relacionados con la confiabilidad del software:
datos en el dominio del tiempo y datos en el dominio del intervalo. los
El enfoque de datos en el dominio del tiempo requiere que los
tiempos individuales en los que ocurrió la falla deben ser
Machine Translated by Google
578 Prácticas y aplicaciones emergentes
grabado. Para el enfoque de dominio de intervalo, es necesario
contar el número de fallas que ocurren durante un período fijo.
Desde el punto de vista de la precisión en el proceso de
estimación de la confiabilidad, el enfoque en el dominio del
tiempo es adecuado, pero se necesitan más esfuerzos de
recopilación de datos. A continuación, se presentará la
confiabilidad como un concepto de ingeniería, mejorando el
marco de la calidad total para la gestión de ingeniería de
software.
Según Musa [6], “la confiabilidad del software de ingeniería
significa desarrollar un producto de tal manera que el producto
llegue al mercado en el momento adecuado, a un costo
aceptable y con una confiabilidad satisfactoria”. La confiabilidad
incorpora todas aquellas propiedades del software que se
pueden asociar con el software en ejecución (corrección,
seguridad, facilidad de uso y facilidad de uso). Existen dos
enfoques para medir la confiabilidad del software: un enfoque
orientado al desarrollador que cuenta las fallas o defectos
encontrados en un producto de software y un enfoque orientado
al usuario que tiene en cuenta la frecuencia con la que ocurren
los problemas.
Un enfoque básico del proceso de ingeniería de confiabilidad
del software (SRE), según [6], requiere las siguientes actividades.
1. Identificar los módulos que deben tener una prueba
separada.
2. Defina la falla con clases de gravedad (una clase de
gravedad de falla es un conjunto de fallas que tienen el
mismo impacto por falla en los usuarios, según un atributo
de calidad).
3. Elija la unidad natural o de tiempo (una unidad natural es
la relacionada con la salida de un producto basado en
software).
4. Establecer el objetivo de intensidad de fallas del sistema
para cada módulo a probar (fallas por unidad natural).
5. Determinar el objetivo de intensidad de falla del software
desarrollado.
6. Aplicar, de manera ingenieril, las estrategias de
confiabilidad para cumplir con el objetivo de intensidad de
falla.
7. Determinar los modos operativos de cada módulo a probar.
8. Para cada módulo a probar, desarrollar el módulo y el perfil
operativo (por
identificar los iniciadores de operaciones, crear la lista de
operaciones, determinar las tasas de ocurrencia y las
probabilidades de ocurrencia).
9. Preparar casos de prueba (con los siguientes pasos:
estimación del número de nuevos casos de prueba
necesarios para la versión actual, asignación de los casos
de prueba entre los módulos a probar, para cada módulo
asignar nuevos casos de prueba entre sus nuevas
operaciones, especificar los nuevos casos de prueba y
agregar estos nuevos casos de prueba a los de versiones
anteriores).
10. Preparar procedimientos de prueba (un procedimiento de
prueba para cada modo operativo).
11. Ejecutar la prueba mediante la asignación del tiempo de
prueba, probar los sistemas (componentes adquiridos,
productos y variaciones, y supersistemas) e identificar
cuidadosamente las fallas (analizando la salida de la
prueba en busca de desviaciones, determinando qué
desviaciones son fallas, estableciendo cuándo las fallas
ocurridas y asignando clases de severidad de fallas).
12. Aplicar datos de fallas para guiar las decisiones.
La introducción de SRE en una organización es una fuerte
función de la madurez del proceso de software de esa
organización. El período necesario para la introducción puede
oscilar entre seis meses y varios años. Se recomienda un
enfoque incremental.
El proceso debe comenzar con las actividades necesarias para
establecer una línea de base y aprender sobre el producto y
las expectativas del cliente.
Un conjunto importante de actividades de SRE está
relacionado con la medición y predicción de la confiabilidad y
disponibilidad del software. Esto incluye el modelado del
comportamiento de fallas del software y el modelado del
proceso que desarrolla y elimina las fallas. Según [6, 21, 38–
40] y las referencias allí citadas, se dispone de un amplio
conjunto de métricas y modelos para tal fin.
Hay muchos tipos de modelos de confiabilidad de software.
Algunos modelos bien conocidos son: la métrica de software
de Halstead y la métrica de complejidad ciclomática de McCabe
(ambos modelos deterministas). La métrica de Halstead se
puede usar para estimar el número de errores en el programa,
mientras que la métrica de complejidad ciclomática de McCabe
se puede usar para determinar un límite superior en el número
de pruebas.
Machine Translated by Google
Calidad Total para la Gestión de la Ingeniería del Software 579
en un programa Los modelos incluidos en el segundo grupo,
denominados “modelos de siembra de errores”, estiman el
número de errores en un programa utilizando una técnica de
muestreo multietapa, cuando los errores se dividen en errores
autóctonos y errores inducidos (errores sembrados). Ejemplos
de tales modelos son [19]: el modelo de siembra de errores de
Mills, el modelo de distribución hipergeométrica y el modelo de
Cai.
Otro grupo de modelos se usa para estudiar la tasa de falla del
software por falla en los intervalos de falla. Los modelos incluidos
en este grupo son: Jelinski y Moranda (JM), Poisson binomial
negativo, depuración imperfecta de Goel-Okumoto y un gran
número de variaciones del modelo JM. Otros modelos, a saber,
los modelos de ajuste de curvas, utilizan el análisis de regresión
estadística para estudiar la relación entre la complejidad del
software y la cantidad de fallas en un programa, la cantidad de
cambios o la tasa de fallas. Al asumir que el futuro del proceso
es estadísticamente independiente del pasado, se proponen
modelos NHPP (proceso de Poisson no homogéneo) (ver [19,
cap.4]): Duane, Musa exponencial, Goel–Okumoto, S- modelos
de crecimiento conformado, modelos de crecimiento
hiperexponencial, NHPP generalizado, etc. El último grupo, en
la clasificación de Pham, incluye modelos de Markov [19].
Desafortunadamente, debido a que la confiabilidad se define en
términos de fallas, es imposible medirla antes de que se complete
el desarrollo. Incluso recopilando datos cuidadosamente sobre
los tiempos entre fallas y utilizando modelos de crecimiento de
la confiabilidad del software, es difícil producir predicciones
precisas sobre todos los conjuntos de datos en todos los
entornos; eso significa que las técnicas mencionadas
anteriormente funcionan de manera efectiva solo si el entorno
operativo futuro del software es similar a aquel en el que se
recopilaron los datos de falla. El consejo de Fenton y Pfleeger
[27] es muy importante: "Si debemos predecir la confiabilidad de
un sistema que no se ha lanzado a un usuario, entonces
debemos simular el entorno operativo objetivo en nuestras
pruebas".
Desde el punto de vista de SRE, es esencial que una
persona que selecciona modelos y hace predicciones de
confiabilidad esté debidamente capacitada tanto en ingeniería
de software (confiabilidad) como en estadística (consulte el
enfoque de sala limpia [25]).
El filtrado de datos y la identificación de valores atípicos son
pasos fundamentales para la validación de datos. Datos
la partición también es importante. La aplicación de modelos de
crecimiento de la confiabilidad a las fallas más severas permite,
por ejemplo, evaluar la tasa de fallas del software correspondiente
al comportamiento más crítico. Tal tasa es más significativa que
la tasa general de fallas del software que incorpora fallas que no
tienen un impacto importante en el comportamiento del sistema.
Los programas de mejora de la confiabilidad ayudarán a las
empresas a mejorar la madurez de su producción de software,
adoptando el enfoque CMM, el estándar ESA u otros estándares
especialmente desarrollados para producir aplicaciones críticas
para la seguridad.
32.3.3 Modelos de esfuerzo y costo
Una de las mayores objeciones a la aplicación de programas
para desarrollar bajo requisitos de confiabilidad es el esfuerzo
total, el cual se ha considerado durante mucho tiempo que
aumenta con el nivel requerido.
Es por esto que la estimación del esfuerzo es crucial para la
organización de desarrollo de software. El esfuerzo sobreestimado
puede convencer a la gerencia general de desaprobar los
sistemas propuestos que podrían contribuir significativamente a
la calidad del proceso de desarrollo. El esfuerzo subestimado
puede convencer a la gerencia general para que apruebe, pero
el exceso de sus presupuestos y la falla final es la forma común.
Pham y Zhang [41] proponen un modelo que considera el costo
de la prueba, el costo de eliminar los errores detectados durante
la fase de prueba, el costo de eliminar los errores detectados
durante el período de garantía y el costo del riesgo debido a la
falla del software. Como mencionan los autores: “este modelo
se puede usar para estimar el costo total realista del software”
para algunos productos de software, y “para determinar las
políticas de lanzamiento de prueba óptimas del sistema de
software”.
Otros modelos de costos de software basados en las funciones
de confiabilidad del software NHPP se pueden encontrar en [19].
Hay muchas soluciones propuestas, pero, en general, es
muy restrictivo aplicarlas en un gran conjunto de proyectos de
software. La aplicación del análisis de datos a datos empíricos
indica que las tendencias de esfuerzo dependen de ciertos
parámetros medibles. Hay dos clases de modelos para la
estimación del esfuerzo: modelos de costos y modelos de
restricciones. COCOMO es un modelo empírico de costos
Machine Translated by Google
580 Prácticas y aplicaciones emergentes
(una compuesta) que proporciona estimaciones directas
de esfuerzo o duración. Con frecuencia, los modelos de costos
tener un parámetro de entrada principal y un número
de los generadores de costos (características del proyecto,
proceso, producto o recursos que tienen una importancia
influencia sobre el esfuerzo o la duración). Restricción
Los modelos describen una relación en el tiempo entre
dos o más parámetros de esfuerzo, duración,
o nivel de personal. Porque estas matemáticas
los modelos se definen en términos de un algoritmo,
se denominan modelos algorítmicos. Boehm [42]
clasifica los modelos algorítmicos utilizados para el software
estimación de costos de la siguiente manera:
1. modelos lineales que intentan ajustar una línea simple a
los datos observados;
2. modelos multiplicativos que describen el esfuerzo como un
producto de constantes con varios factores de costo
como sus exponentes;
3. modelos analíticos que generalmente describen el esfuerzo
como una función que no es ni lineal ni
multiplicativo;
4. modelos tabulares que representan la relación
entre los generadores de costos y el esfuerzo de desarrollo
en forma de matriz;
5. modelos compuestos usando una combinación de todos
o algunos de los enfoques mencionados anteriormente,
que son lo suficientemente genéricas para representar una gran
clase de situaciones.
Los modelos compuestos se utilizan principalmente en la práctica.
Otro modelo compuesto, ampliamente utilizado en la industria,
es el modelo SLIM (gestión del ciclo de vida del software) de
Putnam. Tanto el modelo COCOMO como el de Put nam
utilizan la distribución de Rayleigh como
aproximación a la curva de distribución del trabajo suavizada.
SLIM usa curvas de Rayleigh separadas
para diseño y código, prueba y validación, mantenimiento,
gestión. Boehm y sus colegas
[43] han definido un COCOMO actualizado, útil para una
colección más amplia de técnicas y tecnologías de desarrollo
de software, incluyendo reingeniería, generadores de
aplicaciones y enfoques orientados a objetos.
Sin embargo, los profesionales también utilizan
consideraciones informales: la opinión subjetiva de un experto,
la disponibilidad de recursos, la analogía , etc.
usar más de una técnica simultáneamente. Para
razones de mejora de la calidad, es útil asignar
las responsabilidades de la estimación de costos a un
grupo específico de personas [44]. Según [27],
“los miembros del grupo están familiarizados con las técnicas
de estimación y calibración”, “su experiencia de estimación les
da un mejor sentido de
cuando un proyecto se desvía del promedio o
estándar”, “monitorizando la base de datos, el
el grupo puede identificar tendencias y realizar análisis
que son imposibles para proyectos individuales”, y con
la ventaja de estar separado del proyecto
personal que pueden volver a estimar periódicamente diferentes
atributos externos.
32.4 Gestión de la calidad total
para ingeniería de software
32.4.1 Teoría de Deming
El Departamento de Defensa de EE. UU. define el enfoque de
calidad total (también llamado gestión de calidad total o TQM)
de la siguiente manera (de la ref. 11, cap. 1,
citado en [3]): “TQM consiste en actividades de mejora continua
que involucran a todos en el
organización—gerentes y trabajadores—en un esfuerzo
totalmente integrado para mejorar el desempeño en todos los
niveles”. Una definición de TQM tiene
dos componentes: “el qué y el cómo de la calidad total”. El
componente how tiene 10 puntos críticos.
elementos: orientación al cliente, obsesión por la calidad,
enfoque científico, compromiso a largo plazo,
trabajo en equipo, mejora continua de los sistemas, educación
y formación, libertad en todo el control, unidad de propósito y
participación de los empleados
y empoderamiento. Muchas personas y organizaciones
contribuyen a desarrollar varios conceptos, conocidos
colectivamente como TQM. La calidad más conocida
pionero es el Dr. W. Edwards Deming [2]. Deming
La filosofía de los “catorce puntos” también es aplicable
a la calidad del software. Según Goetsch y
Davis [3] y Zultner [45], siguiendo el plan–
hacer-verificar-actuar-analizar Ciclo de Deming, las 14 reglas
son (los números no representan ni un orden de
progresión ni prioridades relativas).
Machine Translated by Google
Calidad Total para la Gestión de la Ingeniería del Software 581
1. Crear constancia de propósito para la mejora del desarrollo
con el objetivo de ser excelente (nivel de optimización en
el enfoque SEI).
2. Adoptar una nueva filosofía: los proyectos de software
fracasan por falta de gestión y control.
La gerencia de ingeniería de software debe aprender de la
experiencia que la calidad es vital para la supervivencia.
3. El logro de la calidad debe ser independiente del proceso de
inspección. Desarrollar para la calidad.
4. Deje de adjudicar contratos en función del precio de etiqueta
solo.
5. Mejorar constantemente y para siempre el proceso de
desarrollo del sistema para mejorar la calidad y la
productividad, creando mayor valor con menor costo.
6. Instituir capacitación en el trabajo. La formación es la mejor
manera de mejorar a las personas de forma continua.
7. Instituto de liderazgo (para ayudar a las personas y la
tecnología a trabajar mejor).
8. Expulsar el miedo para que todos puedan trabajar con
eficacia.
9. Rompe las barreras entre departamentos.
El trabajo en equipo, especialmente en la parte delantera
del proyecto, mejora la calidad del producto final.
10. Eliminar consignas y objetivos que pidan nuevos niveles de
productividad o titulaciones competitivas.
Crean relaciones de confrontación.
11. Eliminar las cuotas.
12. Eliminar las barreras que les roban a los empleados su
orgullo por la mano de obra.
13. Instituir un programa vigoroso de educación/capacitación y
superación personal.
14. Ponga a todos a trabajar para lograr la transformación.
Las reglas anteriores resumen los puntos de vista de Deming
sobre lo que la organización de software debe hacer para
efectuar una transición positiva de "negocios como siempre a
calidad de clase mundial". Para construir software de calidad, la
casa de software debe realizar cambios sustanciales en la forma
en que se desarrollan y administran los sistemas (ver Zultner
[45]). Los factores que pueden inhibir tal transformación se
denominan “las siete enfermedades mortales de Deming”.
Al adaptarlos a la calidad del software, se obtiene la siguiente
lista.
1. Falta de constancia en el propósito de planificar productos
de software que satisfagan los requisitos del usuario y
mantengan a la empresa en funcionamiento. Costes de
mantenimiento excesivos.
2. Énfasis en el cronograma a corto plazo.
3. Revisar los sistemas y administrar por objetivos sin
proporcionar métodos o recursos para lograr los objetivos.
4. Movilidad de profesionales y directivos de sistemas.
5. Administrar solo por “cifras visibles” con poca o ninguna
consideración a las cifras que se desconocen o no se
pueden conocer.
6. Costo de personal excesivo.
7. Costos excesivos de las responsabilidades legales.
TQM puede eliminar o reducir el impacto de la falta de
constancia, el sistema de revisión, la movilidad y el uso de
figuras visibles. Sin embargo, la calidad total no liberará a la
organización de costos personales excesivos o responsabilidades
legales de la presión para producir ganancias a corto plazo,
siendo estas “las enfermedades de los sistemas financieros, de
salud y legales de la nación”, como mencionan Goetsch y Davis
[ 3].
32.4.2 Mejora Continua
La mejora continua es el elemento más fundamental de TQM.
Se aplica no solo a los productos sino también a los procesos y
las personas que los operan. Se debe definir el proceso a
mejorar (se describen claramente todas las actividades a
realizar). Además, el proceso debe usarse (aplicarse) en muchos
proyectos para crear experiencia.
Para decidir sobre el comportamiento del proceso, se deben
recopilar y analizar datos y métricas. La sección anterior sobre
medición y la literatura citada explican el importante papel de la
medición para TQM. Otros modelos y referencias pueden
encontrarse en Popentiu y Burschy [46].
La mejora de procesos se puede abordar a nivel
organizacional, a nivel de proyecto y a nivel individual. Tanto
CMM como ISO 9001
Machine Translated by Google
582 Prácticas y aplicaciones emergentes
Identificar procesos a nivel organizacional. El CMM
identifica áreas de proceso clave obligatorias para
lograr un cierto nivel de madurez. De acuerdo con Paulk
[14], en el CMM, la mejora de procesos está implícita
en el concepto de madurez en sí mismo, y se aborda
más específicamente en las áreas clave de proceso del
Nivel 5, mientras que ISO 9001 solo establece los
criterios mínimos para lograr la certificación ISO.
A nivel de proyecto, el modelo SPICE se ocupa de la
mejora de procesos, mientras que el modelo de proceso
de software personal, desarrollado por Humphrey [47],
se ocupa de la mejora de procesos a nivel individual.
En el modelo de Humphrey, cada individuo pasa por
una serie de cuatro niveles, en los que se añaden
nuevos pasos que hacen un proceso más maduro.
Observemos que si bien algunos modelos de calidad
incorporan el concepto de mejora del software, no
explican cómo se debe obtener.
El estándar ESA, y sus actualizaciones a las nuevas
tecnologías, es más específico. Proporciona un
algoritmo tanto desde el punto de vista de la ingeniería
de software como de la gestión. Un proyecto colaborativo
ESPRIT en el que participan nueve centros europeos
de excelencia, denominado “ami” [48], es una adaptación
del método objetivo-pregunta-métrica (GQM) ideado por
Basili [49]. El enfoque “ami” contó con el apoyo de la
ESA. Otro proceso de ingeniería de sistemas que
transforma los deseos del cliente/usuario en el lenguaje
requerido, en todos los niveles del proyecto, es el
despliegue de la función de calidad (QFD). QFD, según
Goetsch y Davis [3], brinda una serie de beneficios a
las organizaciones que intentan mejorar su competitividad
mejorando continuamente la calidad y la productividad.
El proceso tiene las ventajas de ser: centrado en el
cliente, eficiente en el tiempo, orientado al trabajo en
equipo y orientado a la documentación.
El objetivo de las actividades de gestión es construir
el producto de software dentro del presupuesto, de
acuerdo con el cronograma y con la calidad requerida.
Para lograr esto, según ESA [4], una organización debe
establecer planes para: gestión de proyectos de
software, gestión de configuración de software,
verificación y validación de software y garantía de
calidad del software.
El plan de gestión de proyectos de software (SPMP)
contiene “las funciones, actividades y tareas técnicas y
de gestión del proyecto necesarias para satisfacer
los requisitos de un proyecto de software”. Siguiendo el
paradigma de la mejora continua, el SPMP debe
actualizarse y refinarse, a lo largo del ciclo de vida, “a
medida que sean posibles estimaciones más precisas
del esfuerzo involucrado”, y cada vez que ocurran
cambios en algunos atributos u objetivos.
La gestión de la configuración del software, esencial
para el control adecuado de la calidad del software, es
una actividad tanto de gestión como técnica. Ince [5]
identifica las siguientes actividades que componen el
proceso de gestión de la configuración: identificación
de elementos de configuración, control de configuración,
contabilidad de estado y auditoría de configuración.
Todas las actividades de verificación y validación
del software se documentarán en el plan correspondiente.
Según ESA [4], las actividades de verificación incluyen:
revisión, inspección, prueba, verificación formal y
auditoría. Mediante la validación, la organización
determinará si el producto final cumple con los requisitos
del usuario.
El plan de aseguramiento de la calidad del software
define cómo se monitorearán los estándares adoptados
para el desarrollo del proyecto. Dicho plan es una lista
de verificación de las actividades que deben llevarse a
cabo para garantizar la calidad del producto. Para cada
documento, el enfoque de ESA proporciona un diseño
claro, con formato y contenido estrictos. Existen otras
prácticas de gestión de software, y Kenet y Baker [50]
dan una visión pragmática del tema.
32.5 Conclusiones
Se examinan estrategias para obtener software de
calidad. Se cubren los enfoques básicos en el
aseguramiento de la calidad del software; Se están
considerando las normas ISO 9000 y CMM. La práctica
de la ingeniería de software está ilustrada por los
estándares de la ESA y las técnicas modernas de
desarrollo de software. Otras metodologías son:
ingeniería de confiabilidad del software, economía de
la ingeniería del software y administración del software.
Poniéndolos juntos, y utilizando la filosofía de Deming
adaptada, la organización de software implementará el
paradigma de gestión de calidad total.
Machine Translated by Google
Calidad Total para la Gestión de la Ingeniería del Software 583
Referencias
[1] Uselac S. Liderazgo Zen: el lado humano de la gestión de equipos de
calidad total. Londonville, OH: Mohican Publishing Company; 1993.
[2] Deming NOSOTROS. Fuera de la crisis. Cambridge, MA: Centro de
Estudios de Ingeniería Avanzada del Instituto Tecnológico de
Massachusetts; 1986.
[3] Goetsch DL, Davis S. Introducción a la calidad total. calidad, productividad,
competitividad: Englewood Cliffs, NJ: Prentice Hall; 1994.
[4] ESA PSS-05-0: Estándares de ingeniería de software de ESA, número 2;
febrero de 1991.
[5] Ince D. Una introducción a la garantía de calidad y su implementación.
Londres: McGraw-Hill; 1994.
[6] Musa JD. Ingeniería de confiabilidad del software. Nueva York: McGraw-
Hill; 1999.
[7] BreisfordJJ. Establecer un programa de calidad del software.
Quality Progress, noviembre de 1988.
[8] CODERM: “¿Es seguro?” El Boletín 1998/99;15,(2):6–7.
[9] Leones JL. Falla del vuelo 501 de Ariane 5: Informe de la Junta de
Investigación. París; 19 de julio de 1996.
[10] Estándar IEEE para planes de garantía de calidad de software: IEEE Std.
730.1-1989.
[11] Organización Internacional de Normalización. ISO 9001: Sistemas de
calidad: modelo para el aseguramiento de la calidad en el diseño,
desarrollo, producción, instalación y servicio. Organización de Estándares
Internacionales; 1987.
[12] Organización Internacional de Normalización. Estándares de gestión y
aseguramiento de la calidad—Parte 3. Directrices para la aplicación de
la norma ISO 9001 al desarrollo, suministro y mantenimiento de
software. ISO/IS 9000-3. Ginebra; 1990.
[13] Organización Internacional de Normalización. Directrices sobre la gestión
de la calidad y los elementos del sistema de calidad—Parte 2.
Norma ISO 9004-2. Ginebra; 1991.
[14] Paul MC. Cómo se compara ISO 9001 con el CMM. Software IEEE
1995;12(1):74–83.
[15] Kuvaja P, Bicego A. Bootstrap: una metodología de evaluación europea.
Software Qual J 1994;3(3):117–28.
[16] Organización Internacional de Normalización. SPICE Baseline Practice
Guide, Descripción del producto, edición 0.03 (borrador); 1993.
[17] IEEE. Glosario de terminología de ingeniería de software.
Norma IEEE 610.12-1990.
[18] Lyu SR. Manual de ingeniería de confiabilidad del software.
Nueva York: McGrawHill; 1996.
[19] Pham H. Fiabilidad del software. Singapur: Springer; 2000.
[20] Jones M, Mazza C, Mortensen UK, Scheffer A. 1977–1997: Veinte años
de estandarización de ingeniería de software en ESA. ESA Bull 1997;
90.
[21] Cederling U. Desarrollo de software industrial: un estudio de caso. En:
Sommerville I, Paul M, editores. Ingeniería de software—ESEC'93.
Berlín: Springer-Verlag; 1993. págs. 226–37.
[22] Capper NP, Colgate RJ, Hunter JC, James. El impacto de la tecnología
orientada a objetos en la calidad del software: tres historias de casos.
Software Qual 1994;33(1):131–58.
[23] Blaschek G. Programación orientada a objetos con prototipos. Berlín:
Springer-Verlag; 1994.
[24] Hausler PA. Linger RC, Trammell CJ. Adoptar la ingeniería de software de
salas limpias con un enfoque por etapas. Software Qual 1994;33(1):89–
110.
[25] Mills HD, Poore JH. Poner el software bajo control estadístico de calidad.
Qual Prog 1988; Nov.
[26] Lee M, Pham H, Zhang X. Una metodología para el establecimiento de
prioridades con aplicación al proceso de desarrollo de software.
Eur J Operat Res 1999;118(2):375–89.
[27] Fenton NE, Pfleeger SL. Métricas de software: un enfoque riguroso y
práctico, 2ª ed. Prensa informática internacional Thomson; 1996.
[28] Boehm BW, Brown JR, Kaspar H, Lipow M, Macleod G, Merrit M.
Características de la calidad del software. Serie TRW de tecnología de
software. Ámsterdam: Holanda Septentrional;
1978.
[29] McCall JA, Richards PK, Walters GF. Factores en el software
calidad. RADC TR-77-369; 1977.
[30] Organización Internacional de Normalización. Tecnología de la información
—evaluación de productos de software—características de calidad y
lineamientos para su uso. ISO/IEC IS 9126. Ginebra; 1991.
[31] Gilb T. Métricas de software. Cambridge, MA: Chartwell Bratt; 1976.
[32] Kitchenham BA, Walker JG. Un enfoque cuantitativo para monitorear el
desarrollo de software. Software Eng J 1989;4(1):2–13.
[33] Bevan N. Midiendo la usabilidad como calidad de uso. Software Qual J
1995,4(2):115–30.
[34] Belady LA, Lehman MM. Un modelo de desarrollo de grandes programas.
IBM Syst J 1976;15(3):225–52.
[35] Gunning R. La técnica de la escritura clara. Nueva York: McGraw-Hill;
1968.
[36] Hudepohl JP, Aud SJ, Khoshoftaar TM, et al. EMERALD: métricas y
modelos de software en el escritorio. IEEE Software 1996;13
(septiembre): 56–60.
[37] Khoshgoftaar TM, Allen EB, Jones WD, et al.
Modelos de árbol de clasificación de la calidad del software en múltiples
versiones. IEEE Trans Reliab 2000;49(1):4–11.
[38] Musa JD, Iannino A, Okumoto K. Confiabilidad del software: medición,
predicción, aplicación. Nueva York: Mc Graw Hill; 1987.
[39] Xie M. Modelado de confiabilidad del software. Singapur: World Scientific;
1991.
[40] Burtschy B, Albeanu G, Boros DN, Popentiu FL, Nicola V.
Mejora de la previsión de fiabilidad del software. Microelectron Reliab
1997;37(6):901–7.
[41] Pham H, Zhang X. Un modelo de costo de software con garantía y costos
de riesgo. IEEE Trans Comput 1999;48(1):71–5.
[42] Böhm BW. Economía de la ingeniería de software. Englewood
Acantilados, Nueva Jersey: Prentice Hall; 1981.
[43] Boehm BW, Clark B, Horowitz E, Westland JC, Madachy RJ, Selby RW.
Modelos de costes para futuros procesos de ciclo de vida: COCOMO
2.0. Ann Software Eng 1995;1(1):1–24.
Machine Translated by Google

584 Prácticas y aplicaciones emergentes

[44] DeMarco T. Proyectos de software de control. Nueva York: Yourdon Press; mil
novecientos ochenta y dos.
[45] Zultner R. El enfoque de Deming para la ingeniería de calidad
del software. Qual Progr 1988; Nov.
[46] Popentiu Fl, Burschy B. Calidad total para la gestión de
ingeniería de software. Informe final para la OTAN:
HTECH.LG 941434; septiembre de 1997.
[47] Humphrey WS. Una disciplina para la ingeniería de software.
Lectura, MA: Addison Wesley; 1995.
[48] Kuntzmann-Combelles A. Enfoque cuantitativo de la gestión
de software: el método “ami”. En: Sommerville I, Paul M,
editores. Ingeniería de software—ESEC'93. Berlín: Springer-
Verlag; 1993. págs. 238–50.
[49] Basili VR, Rombach D. El proyecto TAME: hacia entornos de
software orientados a la mejora. IEEE Trans Software Eng
1988;14(6):758–73.
[50] Kenet RS, Baker ER. Calidad del proceso software: gestión
y control. Nueva York: Marcel Dekker; 1999.
Machine Translated by Google

Tolerancia a fallos de software

Xiaolin Teng y Hoang Pham

33.1 Introducción
33.2 Metodologías tolerantes a fallas de software
33.2.1Programación de la versión N

33.2.2Bloque de recuperación
33.2.3 Otras técnicas de tolerancia a fallas
33.3 Modelado de programación de versión N
33.3.1 Análisis básico

33.3.1.1 Modelado de dominio de datos

33.3.1.2 Modelado en el dominio del tiempo
33.3.2 Confiabilidad en presencia de correlación de fallas
33.3.3 Análisis y Modelado de Confiabilidad
33.4 Formulación del modelo de proceso de Poisson no homogéneo generalizado
33.5 Modelo de confiabilidad del proceso de Poisson no homogéneo para la versión N

Sistemas de programación
33.5.1 Supuestos del modelo
33.5.2 Formulaciones modelo
33.5.2.1 Funciones de valor medio
33.5.2.2 Fallas Comunes

33.5.2.3 Fallas Independientes Concurrentes

33.5.3 Confiabilidad del sistema de programación de la versión N
33.5.4 Estimación de parámetros
33.6 Programación de versión N: crecimiento de la confiabilidad del software
33.6.1 Aplicaciones de la programación de versiones N: modelos de crecimiento de confiabilidad del software
33.6.1.1 Datos de prueba
33.7 Conclusión

33.1 Introducción generalmente fallas físicas. Fallas físicas de hardware

La tolerancia a fallas del software se logra mediante
técnicas especiales de programación que permiten la
software para detectar y recuperarse de fallas.
Esto requiere elementos de software redundantes que
proporcionar medios alternativos para cumplir con los mismos
especificaciones. Las diferentes versiones deben ser
desarrollados independientemente de tal manera que no
puede ser tolerado en copias redundantes (de repuesto) de
un componente que es idéntico al original,
ya que comúnmente se supone que el hardware
los componentes fallan de forma independiente. Sin embargo, software
Las fallas de diseño generalmente no pueden ser toleradas en este
manera porque es probable que el error se repita en el repuesto
componente si es idéntico al original [1].
Dos de los software tolerantes a fallos más conocidos

tienen defectos comunes, si los hay, para evitar simultáneos
fallas en respuesta a las mismas entradas.
La diferencia entre la tolerancia a fallas del software
y la tolerancia a fallos de hardware es que los fallos de software
suelen ser fallas de diseño, y las fallas de hardware son
Los esquemas son la programación de versión N (NVP) y
bloque de recuperación (RB). Ambos esquemas se basan
sobre la redundancia de componentes de software y la
suposición de que las fallas coincidentes de los componentes
son raros.

585
Machine Translated by Google
586 Prácticas y aplicaciones emergentes
Versión 1
Aporte Versión 2
Versión norte
Figura 33.1. Esquema de programación de la versión N
33.2 Metodologías tolerantes a fallas de
software 33.2.1 Programación de versión N
NVP fue propuesto por Chen y Avizienis.
En este esquema existen N ÿ 2 programas funcionalmente
equivalentes, llamados versiones, que se desarrollan
independientemente de la misma especificación inicial.
Un desarrollo independiente significa que cada versión
será desarrollada por diferentes grupos de personas.
Esos individuos y grupos no se comunican entre sí
durante el desarrollo del software. Siempre que es
posible, en cada versión se utilizan diferentes algoritmos,
técnicas, lenguajes de programación y herramientas.
NVP es en realidad una generalización de software del
enfoque de redundancia modular N (NMR) utilizado en
la tolerancia a fallas de hardware. Todas estas N
versiones generalmente se ejecutan simultáneamente
(es decir , en paralelo) y envían sus resultados a un
votante, que determina el "correcto" o el mejor resultado,
si existe, mediante un mecanismo de votación, como se
muestra en la Figura 33.1.
Suponga que todas las N versiones son estadísticamente
independientes entre sí y tienen la misma confiabilidad r, y
si se usa la votación por mayoría, entonces la confiabilidad
del esquema NVP (RNVP) se puede expresar como:
norte
norte
RNVP = ri (1 ÿ r)Nÿi
i
i=N/2
Se han propuesto varias técnicas de votación diferentes.
La más simple es la votación por mayoría,
Salida
Votante
correcta
Fallo de sistema
que ha sido investigado por varios investigadores [3–6].
En la votación por mayoría, normalmente N es impar y
el votante necesita al menos N/2 versiones de software
para producir el mismo resultado para determinar un
resultado "correcto". La votación por consenso está
diseñada para software de múltiples versiones con un
espacio de salida pequeño, en cuyo caso las versiones
de software pueden dar resultados idénticos pero incorrectos [7].
El votante seleccionará la salida que dan la mayoría de
las versiones de software. Por ejemplo, suponga que
hay seis versiones de software y tres salidas posibles.
Si tres versiones dan la salida A, dos versiones dan la
salida B y una versión da la salida C, entonces el votante
considerará el resultado correcto como la salida A.
Leung [8] propone un método de votación de máxima
probabilidad, que aplica una función de máxima
probabilidad a decidir el resultado correcto más probable.
Al igual que la votación por consenso, este método de
votación de máxima probabilidad también necesita un
espacio de salida pequeño.
33.2.2 Bloque de recuperación
El esquema RB fue propuesto por Randell [9].
Este esquema consta de tres elementos: módulo primario,
pruebas de aceptación (AT) y módulos alternativos para
una tarea determinada. El esquema más simple del bloque
de recuperación es el que se muestra en la Figura 33.2.
El proceso comienza cuando se prueba la
(33.1) aceptabilidad de la salida del módulo principal.
Si la prueba de aceptación determina que la salida del
módulo primario no es aceptable, restaura, recupera o
"hace retroceder" el estado del
Machine Translated by Google
Y Salida
Módulo 1 A
"correcta"
norte
Módulo 2
norte
Módulo 3
Figura 33.2. esquema de bloques de recuperación
sistema antes de que se ejecutara el módulo primario.
Luego permite que se ejecute el segundo módulo y
evalúa su salida, y si la salida no es aceptable, inicia el
tercer módulo y evalúa su salida, y así sucesivamente.
Si todos los módulos se ejecutan y ninguno da los
resultados aceptables, entonces el sistema falla.
Un problema con este esquema es cómo encontrar
un AT simple y altamente confiable, porque el AT
depende bastante de la aplicación.
También puede haber una prueba de aceptación
diferente para cada módulo. En algunos casos, el AT
será muy simple. Un ejemplo interesante se da en Fairley
[10]. Una especificación implícita de la función de raíz
cuadrada SQRT puede servir como AT:
(ABS((RAÍZ CUADRADA(x)ÿRAÍZ CUADRADA(x)) ÿ x) <Error)
para 0 ÿ x ÿ y
donde x e y son números reales. Error es el rango de
error permisible.
En este caso, es mucho más fácil hacer AT que
SQRT, entonces podemos configurar fácilmente un AT
confiable para SQRT. Desafortunadamente, a veces no
es fácil desarrollar una AT confiable y simple, y una AT
puede ser compleja y tan costosa como la solución
completa del problema. En algunas aplicaciones, es
suficiente que el AT verifique solo la salida del software,
Tolerancia a fallos de software 587
Y Salida
A
"correcta"
Y Salida
A
"correcta"
norte
Y Salida
Módulo N A
"correcta"
norte
Fallo de
sistema
pero en algunas otras aplicaciones, esto puede no ser
suficiente. Los estados internos del software también
deben verificarse para detectar una falla. Comparado
con el votante en un esquema NVP, el AT es mucho
más difícil de construir.
Una de las diferencias entre RB y NVP es que los
módulos se ejecutan secuencialmente en RB y
simultáneamente en NVP. Además, el AT en RB puede
determinar si una versión da el resultado correcto, pero
NVP no incorpora ningún tipo de mecanismo de este
tipo. NVP solo puede confiar en el votante para decidir
el mejor resultado. Además, dado que el RB necesita
cambiar a los módulos de respaldo cuando falla un
módulo de software principal, se necesitan tiempos de
cálculo mucho más largos para finalizar el cálculo en RB
que en NVP si fallan muchos módulos en una tarea. Por
lo tanto, el bloque de recuperación generalmente no es
aplicable a sistemas críticos donde la respuesta en
tiempo real es de gran preocupación.
33.2.3 Otras técnicas de
tolerancia a fallas
Hay algunos estudios que combinan RB y NVP para
crear nuevas técnicas híbridas, como el bloque de
recuperación de consenso [5] y la votación de aceptación [11].
Machine Translated by Google

588 Prácticas y aplicaciones emergentes

Aporte prueba. Esto implica que es posible que el votante no

procese el mismo número de salidas en cada invocación
y, por lo tanto, el algoritmo de votación debe ser dinámico.
Éxito El sistema falla si no se envían resultados al votante. Si
NVP Salida "correcta"
solo se envía un resultado, el votante debe asumir que
es correcto y luego pasarlo a la siguiente etapa.
Falla

RB Salida "correcta"

33.3 Modelado de programación

Fallo de sistema de versión N
Figura 33.3. Bloque de recuperación de consenso En los últimos 20 años, tanto la academia como la
industria han llevado a cabo una serie de estudios
experimentales sistemáticos sobre problemas de software
tolerante a fallos [6, 12, 13]. El modelado de un esquema
El bloque de recuperación de consenso es un sistema
NVP da una idea de su comportamiento y permite la
híbrido que combina NVP y RB en ese orden (Figura
cuantificación de su mérito. Se han realizado algunas
33.3). Si NVP falla, el sistema vuelve a RB usando los
investigaciones en el modelado de confiabilidad de
mismos módulos (se pueden usar los mismos resultados
sistemas de software tolerantes a fallas. El modelado de
del módulo). Solo cuando tanto NVP como RB fallan, el
confiabilidad para sistemas de software tolerantes a fallas
sistema falla.
se divide en dos categorías: modelado de dominio de
La votación de aceptación también es un esquema
datos y modelado de dominio de tiempo. Ambos análisis
NVP, pero agrega un AT a cada versión (Figura 33.4).
utilizan la suposición de que los eventos de falla son
El resultado de cada versión se envía primero al AT, si el independientes entre diferentes versiones.
AT acepta el resultado, el resultado se pasará al votante.
El votante ve solo aquellas salidas que han sido
aprobadas por la aceptación
33.3.1 Análisis básico

33.3.1.1 Modelado de dominio de datos

Aporte
El modelado de dominio de datos utiliza la suposición de
que los eventos de falla entre diferentes versiones de
software son independientes entre sí. Esta abstracción
M1 M2 M3 Minnesota
simplifica el modelado y proporciona información sobre
el comportamiento de los esquemas NVP.
Si ri representa la confiabilidad de la i-ésima versión
del software, y RV representa la confiabilidad del votante,
A1 A2 A3 UN
que también se supone independiente de las fallas de la
versión del software, entonces la confiabilidad del sistema
de un sistema tolerante a fallas NVP de tres versiones es:
Votante Fallo de sistema

Éxito RNVP3(r1,r2,r3, RV)

= RV(r1r2 + r1r3 + r2r3 ÿ 2r1r2r3) (33.2)
Salida "correcta"

Figura 33.4. Votación de aceptación

Si todas las versiones tienen la misma confiabilidad r,
entonces la probabilidad de que funcione un sistema NVP
Machine Translated by Google

Tolerancia a fallos de software 589

0.8

0.6

0.4

0.2

0
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9
Fiabilidad de la versión

2 de 3 3 de 5 4 de 7

Figura 33.5. Comparación de la confiabilidad del sistema y la confiabilidad de la versión

exitosamente bajo la estrategia de votación mayoritaria Si asumimos que todas las versiones tienen el mismo nivel
viene dada por la siguiente expresión: de confiabilidad, entonces la confiabilidad del sistema de NVP
norte viene dada por:
norte

RNVP(r, RV) = RV i ri (1 ÿ r)Nÿi

yo = m RNVP(r(t), RV)
(33.3) norte

norte
donde m (m ÿ N) es el límite inferior del número de = VD ri (t)(1 ÿ r(t))Nÿi (33.5)
i
espacio requerido de versiones que tienen el mismo yo = m

resultado. La figura 33.5 muestra varias funciones de

confiabilidad del sistema frente a la confiabilidad de la Si N = 3, entonces
versión para RV = 1.
Para lograr una mayor confiabilidad, la confiabilidad RNVP3(t) = 3 eÿ2ÿt ÿ 2 eÿ3ÿt (33.6)
de una sola versión debe ser superior a 0,5, luego la
Dado ÿ = 0,05 por hora, podemos trazar las curvas de
confiabilidad del sistema aumentará con la cantidad de
versiones involucradas. Si el espacio de salida tiene función r(t) y RNVP3(t) y comparar la mejora de la
fiabilidad (Figura 33.6). Es fácil ver que cuando t ÿ t =
cardinalidad ÿ, entonces NVP dará como resultado un ÿ
14 ÿ 0.7/ÿ, el sistema es más confiable
versión, peroque una sola
cuando t>tÿ, el
sistema que es más confiable que un solo componente
solo si r > 1/ÿ [7]. sistema es menos confiable que una sola versión.

33.3.1.2 Modelado en el dominio del tiempo

El modelado en el dominio del tiempo se ocupa del
comportamiento de la confiabilidad del sistema a lo largo
del tiempo. El modelo de falla dependiente del tiempo más
simple asume que las fallas llegan aleatoriamente con
tiempos entre llegadas distribuidos exponencialmente con
una tasa constante ÿ. La confiabilidad de una sola versión
de software será: r(t) = eÿÿt
El análisis anterior es muy simple, y el problema real
es mucho más complejo. Se ha demostrado que las
versiones desarrolladas de forma independiente pueden
no fallar de forma independiente debido a las
correlaciones de fallas entre las versiones de software [12, 14].
La siguiente sección analiza varios modelos existentes
que consideran la correlación de fallas entre versiones
(33.4) de software.
Machine Translated by Google
590 Prácticas y aplicaciones emergentes
R t NVP3( )
0.8
rt ( )
0.6
0.4
0.2
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Tiempo (horas)
Figura 33.6. Confiabilidad de una sola versión versus confiabilidad del sistema de tres versiones
33.3.2 Confiabilidad en presencia
de correlación de fallas
Los experimentos muestran que la incidencia de fallas
correlacionadas de los componentes del sistema NVP
puede no ser despreciable en el contexto de las técnicas
actuales de desarrollo y prueba de software [5, 15, 16].
Aunque las versiones de software se desarrollan de forma
independiente, muchos investigadores han revelado que
esas versiones de software desarrolladas de forma
independiente no fallan necesariamente de forma
independiente [12, 17]. Según Knight y Leveson [14], los
experimentos han demostrado que el uso de diferentes
lenguajes y filosofías de diseño tiene poco efecto sobre
la confiabilidad en NVP porque los desarrolladores
tienden a cometer errores lógicos similares en una parte
del software difícil de programar.
En los sistemas NVP, una falla coincidente ocurre
cuando una falla relacionada entre versiones es activada
por alguna entrada o dos fallas no relacionadas en
diferentes versiones son activadas en la misma entrada.
Laprie et al. [18] clasifican las fallas del software
según su independencia en relacionadas o independientes.
Las fallas relacionadas se manifiestan como errores
similares y conducen a fallas de modo común, mientras
que las fallas independientes generalmente causan
errores distintos y fallas separadas.
Debido a la dificultad de distinguir las fallas
relacionadas de las fallas independientes, en este capítulo
simplificamos esta clasificación de fallas como
t*
sigue. Si dos o más versiones dan resultados idénticos
pero todos erróneos, entonces las fallas son causadas
por fallas relacionadas entre versiones; si dos o más
versiones dan resultados diferentes pero erróneos,
entonces las fallas son causadas por fallas de software
independientes o no relacionadas.
Para el resto del capítulo, nos referiremos a las fallas
relacionadas como fallas comunes por simplicidad. La
Figura 33.7 ilustra las fallas comunes y las fallas
independientes en los sistemas NVP.
Las fallas comunes son aquellas que se ubican en los
módulos funcionalmente equivalentes entre dos o más
versiones de software porque sus programadores son
propensos a cometer errores iguales o similares, aunque
desarrollan las versiones de forma independiente. Estas
fallas serán activadas por las mismas entradas para hacer
que esas versiones fallen simultáneamente, y estas fallas
por fallas comunes se denominan fallas comunes.
Las fallas independientes generalmente se ubican en
módulos diferentes o funcionalmente no equivalentes
entre diferentes versiones de software. Dado que son
independientes entre sí y sus fallas resultantes
generalmente se distinguen del mecanismo de decisión,
a menudo se consideran inofensivos para los sistemas
tolerantes a fallas. Sin embargo, todavía existe una
probabilidad, aunque muy pequeña en comparación con
la de fallas comunes (CF), de que una entrada imprevista
active dos fallas independientes en diferentes versiones
de software que conducirán
Machine Translated by Google

Tolerancia a fallos de software 591

Aporte

fallas comunes

Módulo 1 Módulo 1 Módulo funcionalmente equivalente

Módulo 2 Módulo 2 Módulo funcionalmente equivalente

Módulo k Módulo k Módulo funcionalmente equivalente

Independiente

Versión 1 Versión 2

Figura 33.7. Fallos comunes y fallos independientes

Tabla 33.1. Fallos comunes y fallos independientes concurrentes

fallas comunes Fallos independientes concurrentes

Tipo de falla fallas comunes fallas independientes

Producción normalmente lo mismo Usualmente diferente
Ubicación de la falla (lógicamente) Igual Diferente

Resultado de la Elija la solución incorrecta No se puede elegir la solución correcta

votación (votación mayoritaria)

estas dos versiones fallan al mismo tiempo.
Estas fallas por fallas independientes se denominan fallas
independientes concurrentes (CIF). La Tabla 33.1 muestra
las diferencias entre las fallas comunes y las fallas
independientes concurrentes.
33.3.3 Análisis y Modelado de
Confiabilidad
El modelo de confiabilidad de los sistemas NVP debe
considerar no solo las fallas comunes, sino también las
fallas independientes concurrentes entre versiones de
software. Se han propuesto algunos modelos de
confiabilidad para incorporar la dependencia de falla de
interversión.
Eckhardt y Lee [4] desarrollaron un modelo teórico que
proporciona un marco probabilístico para evaluar
empíricamente la efectividad de una estrategia general de
múltiples versiones cuando las versiones de los
componentes están sujetas a errores coincidentes al asumir
las distribuciones estadísticas de elección de entrada y
elección de programa. Su trabajo se encuentra entre los
primeros que mostraron que las versiones de programas
desarrollados de forma independiente fallaban de manera dependiente
Littlewood y Miller [6] demostraron además que existe
una dualidad precisa entre la elección de entrada y la
elección de programa, y consideraron una generalización
en la que se pueden desarrollar diferentes versiones
utilizando diversas metodologías. Se muestra que el uso
de diversas metodologías disminuye la probabilidad de
falla simultánea de varias versiones.
Machine Translated by Google

592 Prácticas y aplicaciones emergentes

Nicola y Goyal [12] propusieron usar una distribución

binomial beta para modelar fallas correlacionadas en
sistemas de software de múltiples versiones y presentaron
V1 V2 V3
un modelo combinatorio para predecir la confiabilidad de
una configuración de software de múltiples versiones.
H H H
Los modelos anteriores se centran en el modelado de
diversidad de software y se basan en el análisis detallado
de las dependencias en software diversificado. Otros
investigadores se enfocan en modelar el comportamiento
del sistema de software tolerante a fallas. 3c _ 3 (1 _ c)
Dugan y Lyu [19] presentaron un análisis de confiabilidad
cuantitativa para una aplicación de programación de versión
N. Los sistemas de software de esta aplicación fueron Yo estado de falla
_

desarrollados y programados por 15 equipos de la

Universidad de Iowa y las divisiones de aviónica de
Rockwell/Collins. El modelo general es un modelo de
recompensa de Markov en el que los estados de la cadena
de Markov representan la evolución a largo plazo de la
estructura del sistema.
La figura 33.8 ilustra el modelo de Markov en Dugan y
Lyu [19]. En el estado inicial, tres versiones de software
desarrolladas de forma independiente se ejecutan en tres
procesadores activos. Los procesadores tienen la misma
tasa de fallas ÿ. Después de que falla el primer hardware,
el sistema TMR se reconfigura exitosamente a un sistema
símplex con probabilidad c. Entonces, la tasa de transición
al estado de reconfiguración es 3ÿc y la tasa de transición
al estado de falla causada por una falla descubierta es 3ÿ(1
ÿ c). El sistema falla cuando falla el único procesador
restante, por lo que la tasa de transición del estado de
reconfiguración al estado de falla es ÿ.
Su modelo considera fallas de software independientes,
fallas de software relacionadas, fallas de hardware
transitorias, fallas de hardware permanentes y cobertura
imperfecta. Los resultados experimentales de esta aplicación
se utilizaron para estimar las probabilidades asociadas con
la activación de fallas de software.
La confiabilidad general de NVP se obtiene combinando la
confiabilidad del hardware y la confiabilidad del software
3VP.
Tai et al. [20] propusieron un modelo de rendimiento y
confiabilidad para evaluar y mejorar la efectividad de los
sistemas NVP. En su investigación, el modelo de rendimiento
de NVP es un proceso de renovación y la confiabilidad es
un modelo de manifestación de fallas. Proponen un plan
para mejorar la
H
Figura 33.8. Modelo de Markov de la estructura del sistema en Dugan
y Lyu [19]
rendimiento y confiabilidad de los sistemas NVP.
Este esquema es un esquema de 3VP, en el que la versión
más lenta se utiliza como desempate (TB) cuando las dos
primeras versiones “empatan” al estar en desacuerdo.
Se agrega una prueba de aceptación (AT) en el esquema
NVP-AT, donde AT se utilizará para decidir si el resultado
es correcto después de que la función de decisión alcance
una decisión de consenso. En esta investigación, las fallas
por fallas relacionadas y fallas no relacionadas fueron bien
modeladas, y sus efectos sobre la efectividad de estos
esquemas de NVP están bien evaluados.
Mientras que los métodos de modelado de Eckhardt y
Lee [4], Littlewood y Miller [6] y Nicola y Goyal [12] son
bastante diferentes de todos los demás métodos de
modelado [19, 20], Goseva Popstojanova y Grnarov [21]
incorporan sus metodologías en un modelo de rendimiento
markoviano y presentar un enfoque unificado destinado a
modelar el comportamiento conjunto del sistema de la
versión N y su entorno operativo. Este nuevo enfoque
proporciona una idea de cómo la confiabilidad se ve
afectada por las características de la versión y el entorno
operativo.
Lin y Chen [22] propusieron dos modelos de depuración
de software con dependencia lineal, que
Machine Translated by Google
parece ser el primer esfuerzo para aplicar un proceso de
Poisson no homogéneo (NHPP) a un sistema NVP. Estos
dos modelos definen un parámetro de correlación ÿi para la
intensidad de falla de la versión de software i, y la función
de valor medio de la versión i es un tiempo de ejecución de
Poisson logarítmico:
mi(ÿi, ÿi, t) = (1/ÿi) log(ÿiÿit + 1)
En el modelo I, el efecto de la dependencia s entre versiones
de software se modela aumentando la intensidad de falla
inicial de cada versión:
yo
_ = ÿ1ÿ1 +···+ ÿiÿ1ÿiÿ1 + ÿi + ÿi+1ÿi+1 (33.8)
+···+ ÿN ÿN
En el modelo II, el efecto de la dependencia s entre
versiones de software se modela aumentando la función de
valor medio nominal de cada versión, a:
m i(ÿ , ÿ, t) = ÿ1m1(ÿ1, ÿ1, t) +···
···+ ÿiÿ1miÿ1(ÿiÿ1, ÿiÿ1, t)
+ mi(ÿi, ÿi, t)
+ ÿi+1mi+1(ÿi+1, ÿi+1, t) +··· (33.9) ···+
(ÿN , ÿN , t)
Aunque estos dos modelos utilizan el método de proceso
de Poisson no homogéneo, no son modelos de crecimiento
de confiabilidad de software (SRGM). Este capítulo no
considera el crecimiento de la confiabilidad del software
debido a la eliminación continua de fallas de los componentes
de los sistemas NVP. Las modificaciones debidas a la
eliminación progresiva de fallas residuales de diseño de las
versiones de software hacen que crezca su confiabilidad, lo
que a su vez hace que crezca la confiabilidad de los sistemas
de software NVP. Entonces, la confiabilidad de los sistemas
NVP puede crecer como resultado de la eliminación continua
de fallas en las versiones de software. Kanun et al. [23]
propusieron un modelo de crecimiento de confiabilidad para
sistemas NVP utilizando el modelo hiperexponencial. La
función de intensidad de falla está dada por:
ÿÿsup exp(ÿÿsupt) + ¯ÿÿinf exp(ÿÿinft) h(t) =
ÿ exp(ÿÿsupt) + ¯ÿ exp(ÿÿinft) (33.10) donde 0 ÿ ÿ ÿ 1,
ÿ¯ = 1 ÿ ÿ, y ÿsup y ÿinf son,
respectivamente,
el modelo hiperexponencial
Tolerancia a fallos de software 593
parámetros que caracterizan el crecimiento de la confiabilidad
debido a la eliminación de las fallas. Cabe señalar que la
función h(t) en la Ecuación 33.10 no es creciente con el
tiempo t para 0 ÿ ÿ ÿ 1, desde h(0) = ÿÿsup + ¯ÿÿinf hasta
h(ÿ) = ÿinf.
Este modelo es el primero que considera el impacto del
crecimiento de la confiabilidad como resultado de la
(33.7) eliminación progresiva de fallas de cada versión de software
en la confiabilidad del software. Al interpretar el modelo
hiperexponencial como un modelo de Markov que puede
manejar el crecimiento de la confiabilidad, este modelo
permite modelar el crecimiento de la confiabilidad de un
sistema NVP a partir del crecimiento de la confiabilidad de sus compon
Sha [24] investigó la relación entre complejidad,
confiabilidad y recursos de desarrollo dentro de un sistema
de programación de versión N y presentó un enfoque para
construir un sistema que pueda administrar actualizaciones
y repararse cuando fallan componentes de software
complejos. Su resultado contradice la creencia de que la
diversidad da como resultado una mayor confiabilidad con
recursos de desarrollo limitados: la confiabilidad de la
programación de una sola versión con un esfuerzo indiviso
es superior a la programación de tres versiones en una
amplia gama de esfuerzos de desarrollo. También señaló
ÿNmN
que la programación de una sola versión puede no ser
siempre superior a su contraparte de la versión N, porque
algunas versiones adicionales se pueden obtener a bajo
costo.
Se ha realizado poca investigación en el modelado de
confiabilidad de los sistemas NVP. La mayor parte de la
investigación del sistema NVP se enfoca en modelar la
diversidad del software [4, 6, 12], o apunta principalmente a
evaluar algunas medidas de confiabilidad para tipos
específicos de sistemas de software [13, 19]. La mayoría de
estos modelos propuestos asumen una confiabilidad estable,
es decir , no consideran el crecimiento de la confiabilidad
debido al mantenimiento correctivo, por lo que pueden no
ser aplicables a las fases de desarrollo y prueba en el ciclo
de vida del software, donde la confiabilidad de los sistemas
NVP crece como resultado del mantenimiento progresivo.
eliminación de fallas residuales de los componentes de software.
Durante las fases de desarrollo y prueba, algunas
preguntas importantes son:
• ¿Qué tan confiable es el software?
• ¿Cuántas fallas restantes hay en el software?
Machine Translated by Google
594 Prácticas y aplicaciones emergentes
• ¿Cuántas pruebas necesita todavía para alcanzar el nivel
de confiabilidad requerido (es decir, cuándo dejar de
probar)?
Para el software tradicional de una sola versión, el SRGM
se puede utilizar para proporcionar respuestas a estas
preguntas. Kanun et al. [23] desarrolló el primer SRGM para
sistemas NVP, que no considera el impacto de la depuración
imperfecta tanto en fallas independientes como en fallas
comunes.
El papel de las fallas en los sistemas NVP puede cambiar
debido a la depuración imperfecta, algunas fallas comunes
(potenciales) pueden reducirse a fallas comunes de bajo nivel
o incluso a fallas independientes. Debido a que el modelo de
Kanoun no se basa en las características del software y el
proceso de prueba/depuración, los usuarios no pueden obtener
mucha información sobre el sistema NVP y sus componentes,
como el número inicial de fallas comunes e independientes.
Finalmente, este modelo es extremadamente complicado, lo
que impide que se aplique con éxito a grandes N (N > 3)
versiones de aplicaciones de programación.
Por lo tanto, existe una gran necesidad de desarrollar un
nuevo modelo de confiabilidad para los sistemas NVP que
brinde información sobre el proceso de desarrollo de los
sistemas NVP y pueda responder las preguntas anteriores.
En otras palabras, el motivo de esta investigación es desarrollar
un SRGM para sistemas NVP. A diferencia de la investigación
de Kanoun et al. [23], este modelo será el primer intento de
establecer un modelo de confiabilidad de software para
sistemas NVP con consideraciones de eficiencia de eliminación
de errores y tasa de introducción de errores durante las pruebas
y la depuración. En este capítulo, presentamos un modelo
NHPP generalizado para un solo programa de software, luego
aplicamos este modelo NHPP generalizado a los sistemas NVP
para desarrollar un modelo de crecimiento de confiabilidad del
software NVP.
33.4 Formulación
del modelo de proceso de
Poisson no homogéneo generalizado
Como una clase general de modelos de procesos estocásticos
bien desarrollados en ingeniería de confiabilidad, los modelos
NHPP se han aplicado con éxito al software.
modelado de confiabilidad. Los modelos NHPP son
especialmente útiles para describir procesos de falla que
poseen ciertas tendencias, como el crecimiento o el deterioro
de la confiabilidad. Zhang et al. [25] propusieron un modelo
NHPP generalizado con los siguientes supuestos.
1. Un programa de software puede fallar durante la ejecución.
2. La ocurrencia de fallas de software sigue NHPP con función
de valor medio m(t).
3. La tasa de detección de fallas del software en cualquier
momento es proporcional a la cantidad de fallas que
quedan en el software en ese momento.
4. Cuando ocurre una falla de software, se realiza un esfuerzo
de depuración de inmediato. Este esfuerzo elimina las
fallas inmediatamente con probabilidad p, donde p 1 ÿ p.
Esta depuración es independiente en cada ubicación de
las fallas del software.
5. Para cada esfuerzo de depuración, ya sea que la falla se
elimine con éxito o no, algunas fallas nuevas pueden
introducirse en el sistema de software con probabilidad
ÿ(t), ÿ(t) p.
A partir de los supuestos anteriores, podemos formular las
siguientes ecuaciones
m(t) = b(t)(a(t) ÿ pm(t))
a(t) = ÿ(t)m(t) (33.11)
dónde
m(t) = número esperado de fallas de software en el tiempo
t, m(t) = E[N(t)]
a(t) = número esperado de software inicial
errores más errores introducidos por tiempo tb(t)
= tasa de detección de fallas por falla en el tiempo tp =
probabilidad de que una falla se elimine con éxito del
software
ÿ(t) = tasa de introducción de fallas en el tiempo t.
Si las condiciones marginales se dan como m(0) = 0, a(0) = a,
las soluciones a la Ecuación 33.11 se muestran a continuación:
t
en
b(u) eÿ 3 0 (pÿÿ(ÿ))b(ÿ) dÿ de (33.12)
m(t) = un 2 0
t
en
(pÿÿ(ÿ ))b(ÿ ) dÿ du
ÿ(u)b(u) eÿ 3 0
un(t) = un 1+ 2 0
(33.13)
Machine Translated by Google

Tolerancia a fallos de software 595

Este modelo se puede utilizar para derivar la mayoría de los nd (t) Nd (t) = NAB(t) + NAC(t) + NBC(t)
modelos NHPP conocidos. Si cambiamos los supuestos + NABC(t); proceso de conteo que
sobre b(t), ÿ(t) yp, podemos obtener todos los modelos NHPP cuenta fallas comunes descubiertas
conocidos. La tabla 33.2, por ejemplo, muestra que algunos en el sistema NVP hasta el tiempo
modelos de crecimiento de la confiabilidad del software t función de valor medio del proceso
NHPP bien conocidos pueden derivarse de este modelo mx(t) de conteo Nx (t), mx(t) = E[Nx (t)],
generalizado de confiabilidad del software [26]. x = A, B, C, AB, AC , BC, ABC, d
número total de fallas tipo x en el
sistema más aquellas fallas tipo x
33.5 Modelo de confiabilidad ya eliminadas del sistema en el
del proceso de Poisson no hacha(t) tiempo t. ax(t) es una función no
decreciente, y ax(0) denota el
homogéneo para sistemas de
número inicial de fallas tipo x en el
programación de versión N sistema, x = tasa de detección de
fallas A, B, C, AB, AC, BC, ABC por
NVP está diseñado para lograr una alta confiabilidad del falla en el tiempo t probabilidad de
sistema al tolerar fallas de software. En esta sección solo que se introduzca una nueva falla
presentamos el modelado de NVP donde N = 3, basado en en la versión 1, 2 y 3 durante la
los resultados de Teng y Pham [30], pero la metodología se depuración, respectivamente
puede aplicar directamente al modelado de NVP donde N > probabilidad de que se elimine con
3. segundo(t) éxito una nueva falla de la versión
1, 2 y 3 durante la depuración,
Supongamos que tenemos tres versiones de software
ÿ1, ÿ2 respectivamente número de tipos
desarrolladas de forma independiente 1, 2 y 3, y usamos la
y ÿ3 A, B y C fallas en el tiempo t que
votación por mayoría, y la confiabilidad del votante es 1.
Se utiliza la siguiente notación: permanecen en el sistema
respectivamente, es decir
FC falla comun
p1, p2,
C.I.F. fallo independiente concurrente
y p3
fallos independientes en la
A versión 1 fallos independientes
en la versión 2 fallos
B independientes en la versión XA(t), XB(t) y
3 fallos comunes entre la XC(t)
C versión 1 y la versión 2 fallos
comunes entre la versión 1 y XA(t) = aA(t) ÿ p1mA(t)
AB la versión 3 fallos comunes XB(t) = aB(t) ÿ p2mB(t)
entre la versión 2 y la versión XC(t) = aC(t) ÿ p3mC(t) función
C.A. 3 fallos comunes entre la
R(x | t) de confiabilidad del software para
versión 1 y la versión 2 , y el
el tiempo x de misión dado y el
antes de Cristo proceso de conteo de la
tiempo para detener la prueba t;
versión 3 que cuenta el
ABC R(x | t) = Pr{ninguna falla durante
número de fallas tipo x
descubiertas hasta el tiempo la misión x | dejar de probar a t}
t, x = A, B, C, AB, intensidad de falla por par de fallas
N x (t) KAB, KAC y para CIF entre la versión 1 y 2,
KBC entre 1 y 3, y entre 2 y 3
respectivamente

CA, BC, ABC

Machine Translated by Google
Machine Translated by Google

Tolerancia a fallos de software 597

NAB(t), NAC(t) y procesos de conteo que

NBC(t) cuentan el número de CIF que
involucran las versiones 1 y 2, Versión 1 A AB B Versión 2

versión 1 y 3, y versión 2 y 3
ABC
hasta el tiempo t respectivamente
C.A. antes de Cristo

proceso de conteo que cuenta el

NI (t) número total de CIF hasta el tiempo
t; NI (t) = NAB(t) + NAC(t) + NBC(t) C
funciones de valor medio de los Versión 3

procesos de conteo correspondientes

mAB(t), mAC(t), m(t) = E[N(t)].
Figura 33.9. Diferentes fallas de software en el sistema de software
mBC(t) y mI (t) de tres versiones

Por ejemplo, funciones de

hAB(t), hAC(t) y intensidad de falla mAB(t) =
Hay dos tipos de fallas coincidentes en los sistemas NVP:
hBC(t) E[NAB(t)] de CIF que involucran
las versiones 1 y 2, entre 1 y 3, y fallas comunes (CF) y fallas independientes concurrentes

entre 2 y 3; d hAB(t) = dt estimación (CIF). Los CF son causados por fallas comunes entre
de máxima verosimilitud versiones, y los CIF son causados por fallas independientes
modelo de crecimiento
mAB(t) dedel
confiabilidad
MLE software para sistemas NVP RNVP- (no relacionadas) entre versiones. Un CIF ocurre cuando dos
o más versiones fallan en la misma entrada en fallas
SRGM(x | t) Función de confiabilidad
NVP-SRGM del sistema NVP para un tiempo independientes, es decir , en A, B o C, no en AB, AC, etc.

de misión dado x y tiempo para

detener la prueba t con consideración de fallas comunes en
el NAB(t) y NAB(t) cuentan el número de fallas coincidentes
entre la versión 1 y la versión 2. La diferencia entre ellos es
que NAB(t) cuenta el número de CF en la versión 1 y la
versión 2, y NAB(t) cuenta el número de CIF en la versión 1 y

Sistema NVP
RInd(x | t) Función de confiabilidad del
sistema NVP para un tiempo de
misión dado x y tiempo para
detener la prueba t, asumiendo
que no hay CF en el sistema NVP,
es decir , ambas versiones fallan
de forma independiente. En la Figura 33.9 se muestran
diferentes tipos de fallas y sus relaciones. Generalmente, este
esquema de notación usa números para referirse a versiones
de software y letras para referirse a tipos de fallas de software.
Por ejemplo, el proceso N1(t) cuenta el número de fallas en
la versión 1 del software hasta el tiempo t, por lo tanto:
la versión 2. La Tabla 33.3 ilustra los diferentes tipos de fallas
entre las diferentes versiones de software.
Para establecer el modelo de crecimiento de confiabilidad
para un sistema de software tolerante a fallas de NVP,
necesitamos analizar la confiabilidad de los componentes, así
como la correlación entre las versiones de software.
33.5.1 Supuestos del modelo
Para desarrollar un modelo NHPP para sistemas NVP,
hacemos las siguientes suposiciones.

N1(t) = NA(t) + NAB(t) + NAC(t) + NABC(t) 1. norte = 3.

Similarmente: 2. Se supone que el votante es perfecto todo el tiempo, es decir

Rvotante = 1.
N2(t) = NB(t) + NAB(t) + NBC(t) + NABC(t)
3. Las versiones más rápidas tendrán que esperar a que finalicen
N3(t) = NC(t) + NAC(t) + NBC(t) + NABC(t)
las versiones más lentas (antes de la votación).
Machine Translated by Google

598 Prácticas y aplicaciones emergentes

Tabla 33.3. Tipos de fallas en el software de programación de tres versiones

sistema

Tiempo de falla Versión 1 Versión 2 Versión 3 Tipo de falla

t1 A
t2 C
t3 A
t4 BC o BC
t5 B
t6 A
t7 C
t8 CA o CA
t9 B
t10 AB o AB
... ... ... ... ...
de ABC
... ... ... ... ...
Nota: el sistema 3VP falla cuando fallan más de dos versiones al mismo tiempo.

4. Cada versión de software puede fallar durante la ejecución,
debido a fallas en el software.
5. Dos o más versiones de software pueden fallar en
la misma entrada, que puede ser causada por
las fallas comunes, o las fallas independientes
entre o entre diferentes versiones.
6. La ocurrencia de fallas de software (por fallas
independientes, fallas comunes de dos versiones
o fallas comunes de tres versiones) sigue un
NHPP.
7. La tasa de detección de fallas de software en cualquier momento
es proporcional al número de restantes
fallas en el software en ese momento.
8. Las tasas de detección de errores unitarios para todo tipo
de las fallas A, B, C, AB, AC, BC y ABC son
11. Algunas fallas comunes pueden reducirse a fallas comunes
de bajo nivel o fallas independientes debido
a los intentos fallidos de eliminación.
12. Los CIF son causados por la activación de
fallas independientes entre diferentes versiones,
y la probabilidad de que un CIF involucre tres
versiones es cero. Esos fracasos sólo implican
dos versiones
13. Cualquier par de fallas independientes restantes
entre versiones tiene la misma probabilidad de
estar activado
14. La intensidad de los CIF que involucran dos
versiones es proporcional al resto
pares de fallas independientes en esos dos
versiones.

la misma y constante, es decir , b(t) = b.

9. Cuando se produzca un fallo de software en cualquiera de los
tres versiones, se ejecuta un esfuerzo de depuración
inmediatamente. Ese esfuerzo elimina la(s) falla(s)
correspondiente(s) inmediatamente con probabilidad 1 ÿ
pi , pi 2 pi (i es la versión número 1,
o 3).
10. Para cada esfuerzo de depuración, si el
las fallas se eliminan con éxito o no, algunas
pueden introducirse nuevas fallas independientes
en esa versión con probabilidad ÿi, ÿi (i es Pi
el número de versión 1, 2 o 3), pero no hay nuevos
la falla común se introducirá en el NVP
sistema.
Las siguientes son algunas explicaciones adicionales para
supuestos 8–11,
Todas las versiones aceptan las mismas entradas y ejecutan
simultáneamente, la versión más rápida tiene que esperar
para que termine la versión más lenta. Por lo tanto, los
la tasa de detección de errores unitarios, b, puede ser la misma
para todo tipo de averías (supuesto 8). N grupos
se asignan para realizar pruebas y depuración
en N versiones de forma independiente, entonces el error
eficiencia de remoción p y la introducción del error
rate ÿ son diferentes para diferentes versiones de software
(supuesto 9). Cuando dos grupos intentan
para eliminar una falla AB de la versión 1 y
Machine Translated by Google

Tolerancia a fallos de software 599

33.5.2 Formulaciones modelo

Con base en las suposiciones dadas en la última

sección, podemos establecer las siguientes ecuaciones
NHPP para diferentes tipos de fallas y fallas de software.

33.5.2.1 Funciones de valor medio

1. Escriba ABC

m ABC(t) = b(aABC ÿ p1p2p3mABC(t))

Figura 33.10. Pares de fallas independientes entre la versión 1 y 2
(33.14)
con condiciones marginales mABC(0) = 0 y aABC(0)
= aABC donde aABC es el número inicial de fallas

versión 2, cada uno puede introducir una nueva falla en tipo ABC en el sistema de software 3VP. La
su propia versión. Pero la probabilidad de que estos ecuación 33.14 se puede resolver directamente
dos grupos cometan el mismo error de introducir una como:
nueva falla AB en ambas versiones es cero (supuesto
ABC
10), esto significa que solo se pueden introducir fallas mABC(t) = (1 ÿ eÿbp1p2p3t ) (33.15)
p1p2p3
independientes en el sistema. Debido a que una falla
AB puede eliminarse con éxito de la versión 1, pero no 2. Tipo AB
eliminarse de la versión 2, la falla común anterior (AB)
ya no es común a la versión 1 y la versión 2, se reduce m AB(t) = b(aAB ÿ p1p2mAB(t)) a
a una falla B, que solo existe en la versión 2 (supuesto AB(t) = (1 ÿ p1)(1 ÿ p2)p3m AB(t) (33.16)
11).

La Figura 33.10 muestra los pares de fallas Tipo CA

independientes entre la versión 1 y la versión 2 del software.
Hay tres fallas independientes (tipo A) en la versión 1 y m AC(t) = b(aAC(t) ÿ p1p3mAC(t)) a
hay dos fallas independientes (tipo B) en la versión 2. AC(t) = (1 ÿp1)(1 ÿp3)p2m ABC(t) (33.17)
Entonces hay 3 × 2 = 6 pares de fallas independientes
entre la versión 1 y la versión 2. Se supone que cada
uno de estos seis pares tiene la misma probabilidad de Tipo BC
ser activado.
En este estudio, no se espera que el votante decida m BC(t) = b(aBC(t) ÿ p2p3mBC(t)) a
si una versión de software falla o no durante la prueba, BC(t) = (1 ÿ p2)(1 ÿ p3)p1m ABC(t) (33.18)
pero asumimos que las personas tienen métodos o
herramientas avanzados para determinar exactamente
si una versión de software falla o tiene éxito y cuándo. con condiciones marginales
Esos métodos o herramientas para detectar una falla
mAB(0) = 0, aAB(0) = aAB
de software dependen bastante de la aplicación y son
demasiado incómodos o poco prácticos para integrarlos mACA(0) = 0, aCA(0) = aCA
en un sistema NVP. Por lo tanto, después del mBC(0) = 0, aBC(0) = aBC
lanzamiento del sistema de software NVP, no contamos
con esas herramientas para decidir si una versión del Al aplicar la Ecuación 33.15 Ecuaciones a
sistema NVP falla, solo podemos confiar en que el 33.16–33.18, podemos obtener las funciones de
votante decida la mejor o la salida correcta. valor medio para el tipo de falla AB,
Machine Translated by Google

600 Prácticas y aplicaciones emergentes

AC y BC respectivamente: a A(t) = ÿ1(m A(t) + m AB(t) + m AC(t) + m

ABC(t)) + (1 ÿ p1)p2m AB(t) + (1 ÿ
mAB(t) = CAB1 ÿ CAB2 eÿbp1p2t
p1)p3m AC(t) + (1 ÿ p1)p2p3m ABC(t)
+ CAB3 eÿbp1p2p3t (33.19)
(33.25)
mAC(t) = CAC1 ÿ CAC2 eÿbp1p3t
Tipo B
+ CAC3 eÿbp1p2p3t (33.20)
m B(t) = b(aB(t) ÿ p2mB(t)) a B(t)
mBC(t) = CBC1 ÿ CBC2 eÿbp2p3t
= ÿ2(m B(t) + m AB(t) + m BC(t)
+ CBC3 eÿbp1p2p3t (33.21)
+ m ABC(t)) + (1 ÿ p2)p1m AB(t) + (1 ÿ

dónde p2)p3m BC(t) + (1 ÿ p2)p1p3m ABC(t)

(33.26)
aAB aABC(1 ÿ p1)(1 ÿ p2) + p2
CAB1 = 1p2 2 aABC(1 ÿ p1)(1 ÿ p2) Tipo C
p1p2 + p2 1p2 2
aAB aABC(1 ÿ p1)(1 ÿ p2) p2 m C(t) = b(aC(t) ÿ p3mC(t)) a C(t)
CAB2 = 1p2 2(1 ÿ p3) ÿ aABC(1 ÿ p1)
p1p2 = ÿ3(m C(t) + m AC(t) + m BC(t)
(1 ÿ p2)
+ m ABC(t)) + (1 ÿ p3)p1m AC(t) + (1 ÿ
ÿ

p3)p2m BC(t) + (1 ÿ p3)p1p2m ABC(t)

(33.27)
CAB3 = (33.22)
p2 1p2 2(1 ÿ p3) con condiciones marginales
AC aABC(1 ÿ p1)(1 ÿ p3) + mA(0) = mB(0) = mC(0) = 0
CAC1 =
p1p3 p2 3
aA(0) = aA, aB(0) = aB, aC(0) = aC
AC 1p2 aABC(1 ÿ p1)(1 ÿ p3)
CAC2 = +
p1p3 Las soluciones a estas ecuaciones son muy
p2 1p2
3 aABC(1
complicadas y pueden obtenerse de Teng y Pham [30].
ÿ
ÿ p1)(1 ÿ p3) p2 1p2 3(1 ÿ p2)

ÿaABC(1 ÿ p1)(1 ÿ p3) p2

33.5.2.2 Fallas Comunes
CAC3 = 1p2 3( 1 - p3) (33.23)
Después de obtener los procesos de conteo de fallas
comunes NAB(t), NAC(t), NBC(t) y NABC(t), podemos
definir un nuevo proceso de conteo Nd (t):
aBC aABC(1 ÿ p2)(1 ÿ p3) p2
CBC1 = + Nd (t) = NAB(t) + NAC(t) + NBC(t)
p2p3 2p2 aABC(1
3 ÿ
+ NABC(t)
aBC p2)(1 ÿ p3)
CBC2 = + p2 2p2
En un sistema de 3VP que utiliza un mecanismo de
p2)(1 ÿ p3)
p2p3p2aABC(1
2p2 3(1ÿÿ 3
votación por mayoría, las fallas comunes en dos o tres
p1) ÿaABC(1 ÿ p2)(1 ÿ p3)
ÿ

versiones conducen a las fallas del sistema. Por lo tanto,

Nd (t) cuenta el número de fallas del sistema de software
NVP debido a los CF entre las versiones de software.
CBC3 = (33.24)
De manera similar, tenemos la función de valor medio de la
p2 2p2 3(1 ÿ p1)
siguiente manera:

3. Tipo A md (t) = mAB(t) + mAC(t) + mBC(t) +

mABC(t) (33.28)
m A(t) = b(aA(t) ÿ p1mA(t))
Machine Translated by Google

Tolerancia a fallos de software 601

t
Dado el tiempo de lanzamiento t y el tiempo de misión x, la (33.34)
mBC(t) = 2 hBC(ÿ ) dÿ
probabilidad de que un sistema de software NVP sobreviva a 0
la misión sin un CF es: dónde

hAC(t) = KACXA(t)XC(t) hBC(t) (33.35)

Pr{no CF durante x | T } = eÿ(md (t+x)ÿmd(t )) (33.29)

= KBCXB(t)XC(t) (33.36)
La ecuación anterior no es la función final de confiabilidad del
sistema, ya que debemos considerar la probabilidad de que También las probabilidades condicionales son
el sistema falle en fallas independientes en el sistema de
Pr{ningún tipo de falla de CA durante x}
software.
= eÿ(mAC(t+x)ÿmAC(t ))
33.5.2.3 Fallos independientes concurrentes Por lo general,

el sistema de software NVP falla por CF que involucran Pr{ningún error de tipo BC durante x}
múltiples versiones. Sin embargo, todavía existe una pequeña
= eÿ(mBC(t+x)ÿmBC(t ))
probabilidad de que dos versiones de software fallen en la
misma entrada debido a fallas independientes. Si definimos un nuevo proceso de conteo
Este tipo de falla es una falla independiente concurrente.
Ni(t) = NAB(t) + NAC(t) + NBC(t) (33.37)

A partir de los supuestos 12, 13 y 14, la intensidad de falla con función de valor medio
hAB(t) para los CIF entre la versión 1 y la versión 2 viene
mi(t) = mAB(t) + mAC(t) + mBC(t) (33.38) entonces la
dada por:
probabilidad de que no haya CIF para un sistema NVP durante
hAB(t) = KABXA(t)XB(t) (33.30)
el intervalo (t, t + x) es: Pr{no CIF durante x} = eÿ(m1(t+x)
donde XA(t) y XB(t) denotan el número de fallas independientes (33.39)
ÿm1(t ))
restantes en la versión 1 y la versión 2 respectivamente, y
KAB es la intensidad de falla por par de fallas para CIF entre 33.5.3 Confiabilidad del sistema de
la versión 1 y la versión 2. Luego tenemos otro no- Proceso
de Poisson homogéneo para CIF, NAB(t), con función de valor programación de la versión N
medio:
Después de obtener la probabilidad de fallas comunes y fallas
independientes concurrentes, podemos determinar la
t confiabilidad de un sistema de software tolerante a fallas NVP
(33.31) (N = 3):
mAB(t) = 2 hAB(ÿ ) dÿ
0

Dado el tiempo de lanzamiento t y el tiempo de misión x, RNVP-SRGM(x | t)

podemos obtener la probabilidad de que no haya un tipo AB = Pr{sin CF y sin CIF durante x | t}
CIF durante (t, t + x)
Debido a que los CF y los CIF son independientes entre sí,
entonces:
Pr{sin falla tipo AB durante x} = eÿ

(mAB(t+x)ÿmAB(t )) (33.32) RNVP-SRGM(x | t) = Pr{no CF durante x | t} × Pr{sin

CIF durante x | t}
Del mismo modo, tenemos otros dos NHPP para CIF entre la
versión 1 y la versión 3 y entre la versión 2 y la versión 3, con A partir de las Ecuaciones 33.29 y 33.39, la confiabilidad de
funciones de valor medio: un sistema NVP se puede determinar mediante:

RNVP-SRGM(x | t)
t
(33.33) = eÿ(md (t+x)+mi(t+x)ÿmd(t )ÿmi(t )) (33.40)
mA(t) = 2 hAC(ÿ ) dÿ
0
Machine Translated by Google

602 Prácticas y aplicaciones emergentes

Tabla 33.4. Información disponible y parámetros desconocidos a estimar

Información disponible Parámetros a estimar

Tipo de falla Tiempo de falla Nº de fallos acumulados Parámetros desconocidos en la función de valor medio

A ti, yo = 1, 2,... madre) aABC, aAB, aAC, aA, b, ÿ1

B ti, i = 1, 2,... mB(ti) ti, i = 1, 2,... aABC, aAB, aBC, aB, b, ÿ2
C mC(ti) ti, i = 1, 2,... mAB(ti)
1 ,ti, i=
2,... aABC, aAC, aBC, aC, b, ÿ3
AB mAC(ti) ti, i = 1, 2,... mBC(ti) ti, i = aABC, aAB, b
C.A. 1, 2,... mABC(ti) tÿ aABC, aAC, b
antes de Cristo aBC, aABC, b
ABC aABC, b
AB
yo = 1, 2,... mAB(ti) yo , tÿ aABC, aAB, aAC, aBC, aA, aB, b, ÿ1, ÿ2, KAB
C.A.
i = 1, 2,... mAC(ti) i , aABC, aAB, aAC, aBC, aA, aC, b, ÿ1, ÿ3, KAC

antes de Cristo
tÿ aABC, aAB, aAC, aBC, aB, aC, b, ÿ2, ÿ3, KBC
yo , i = 1, 2, ... mBC (ti)

ÿ
El tiempo de falla y el número de fallas acumulativas de tipo AB, AC y BC también se incluyen en las fallas de tipo A, B y C.

Generalmente, las fallas comunes son las principales fallas 2. el número acumulado de fallos independientes concurrentes

dentro de los sistemas NVP, y los grupos de prueba hasta un momento dado o el
debe prestar mucha más atención a los comunes tiempo real en que ocurre cada falla.
fallas Después de obtener una confiabilidad final del sistema La tabla 33.4 muestra toda la información disponible y
modelo para los sistemas NVP, necesitamos estimar
esos parámetros a estimar.
los valores de todos los parámetros desconocidos. Parámetro
Uno puede usar fácilmente el método MLE para obtener
se discutirá la estimación para este NVP-SRGM
las estimaciones de todos los parámetros en el modelo [30].
Siguiente.

33.5.4 Estimación de parámetros

33.6 Programación de la versión N–
Este modelo de crecimiento de confiabilidad de software para NVP Crecimiento de la confiabilidad del software
Los sistemas consisten en muchos parámetros. En este capítulo,
usamos la estimación de máxima verosimilitud
33.6.1 Aplicaciones de la versión N
(MLE) para estimar todos los parámetros desconocidos. Para
Programación: confiabilidad del software
simplificar el problema, supongamos que
Modelos de crecimiento
las eficiencias de eliminación de errores p1, p2 y p3 son
conocido. De hecho, se pueden obtener de varios
datos de pruebas empíricas. Por lo tanto, necesitamos 33.6.1.1 Datos de prueba
estimar los siguientes parámetros: b, aABC, aAB, aAC, En esta sección, ilustramos los resultados del modelo por
aBC, aA, aB, aC, ÿ1, ÿ2, ÿ3, KAB, KAC y KBC.
analizando una aplicación de software tolerante a fallas de
Los parámetros desconocidos en el modelo de confiabilidad
el sistema de control del depósito de agua [31].
NHPP se pueden estimar utilizando un MLE
Considere una lógica de control de software simplificada para
método basado en cualquiera de los siguientes dados
un sistema de control de depósito de agua (WRC). Agua es
conjuntos de datos:
suministrado a través de una tubería fuente controlada por una fuente
1. el número acumulativo de tipo ABC, AB, válvula y eliminado a través de un tubo de drenaje controlado
fallas AC, BC, A, B y C hasta un por una válvula de drenaje. Hay dos sensores de nivel,
tiempo o el tiempo real que cada falla posicionado en los límites alto y bajo; La altura
ocurre; salidas del sensor por encima si el nivel está por encima de él y
Machine Translated by Google

Tolerancia a fallos de software 603

Tabla 33.5. Datos de falla normalizados del sistema WRC 2VT

falla no. Tiempo de falla falla no. Tiempo de falla

Versión 1 Versión 2 Versión 1 Versión 2

1,2 3,6 14 39,2 34.8

1 2,8 8,4 15 40 44 36.4
2 8,4 12,8 16 44,8 36.8
3 10 14,4 17 54 56 38
4 16,4 17,2 18 62,4 39.2
5 20 18 20 19 80 92 41.6
6 24,4 23,2 20 99,6 42
7 28 25,2 21 46.4
8 29,2 28 22 59.6
9 31,2 28,4 23 62.4
10 34 36 30,8 24 98.8
11 36,8 31,2 25 99.6
12 13 26 100

el sensor bajo sale por debajo si el nivel está por debajo cada versión R1(x | t) y R2(x | t), y más
eso. El sistema de control debe mantener el agua obtener la fiabilidad de todo el sistema mediante
nivel entre estos dos límites, lo que permite la precipitación simplemente usando el modelo de confiabilidad del sistema paralelo:
y filtraciones desde el depósito. Si acaso,
RInd(x | t) = 1 ÿ (1 ÿ R1(x | t))(1 ÿ R2(x | t))
el agua sube por encima del nivel alto, una alarma
(33.41)
debería sonar. El sistema WRC falla
donde x es el tiempo de la misión, y
tolerancia y alta fiabilidad mediante el uso de
Lógica de control del software NVP con N = 2. El WRC R1(x | t) = eÿ(m1(t+x)ÿm1(t ))
Sistema de software NVP con N = 2 prueba normalizada
los datos se enumeran en la Tabla 33.5. R2(x | t) = eÿ(m2(t+x)ÿm2(t ))
En términos generales, un sistema NVP consta de
Las figuras 33.11 y 33.12 muestran la falla del software
N versiones de software, donde N debe ser mayor
curva de ajuste de la función de valor medio m1(t) (para
que o igual a 3 para que un mecanismo de votación pueda
versión 1) y m2(t) para (versión 2) respectivamente.
aplicarse para elegir una salida correcta. Por este 2VP
Las Figuras 33.13 y 33.14 muestran la independiente
aplicación del sistema, asumimos que la confiabilidad
curva de función de confiabilidad del sistema 2VP y
del votante es igual a 1, y el sistema de 2VP
la curva de la función de confiabilidad de cada versión en x
falla solo cuando sus dos componentes (software
= 50 y x = 10 respectivamente cuando dos software
versiones) fallan en los mismos datos de entrada.
las versiones fallan de forma independiente.
Aplicaremos este conjunto de datos en dos casos.
Una es que se supone que dos versiones de software El significado real de la confiabilidad del sistema.
RInd(t) es la probabilidad de que al menos uno
fallan s-independientemente, otra es que ambas versiones
la versión no falla durante el tiempo de la misión x
no se supone que fallan s-independientemente, y el
dado t (tiempo para detener la prueba). Si cada versión puede
se aplicará la NVP–SRGM propuesta.
fallar como máximo una vez durante el tiempo de misión x, entonces
RInd(t) es la confiabilidad del sistema de 2VP mientras que no
Caso 1: NVP independiente–SRGM Suponga que fallas comunes ocurren entre versiones.
esas dos versiones de software son independientes
uno del otro, podemos aplicar la generalización Caso 2: Tipos de fallas de SRGM de NVP dependientes .
modelo de confiabilidad del software en la Sección 33.4 para cada De la Tabla 33.5, podemos observar que dos versiones
versión por separado, y estimar la fiabilidad de fallar simultáneamente en algún momento, por ejemplo,
Machine Translated by Google

604 Prácticas y aplicaciones emergentes

25 1
mt 1( )
20 0.8
Corteza( )t
Datos reales R t 1( )
0.6
15
Rt 2( )
0.4
10
0.2
5
0
0 50 100 150 200 250
0
0 50 100 150 200 250
Tiempo de prueba (con misión = 10) x

Tiempo (horas)
Figura 33.14. Curvas de confiabilidad del sistema independiente con tiempo
de misión x = 10
Figura 33.11. Función de valor medio m1(t ) curva de ajuste para la versión 1

en t = 8,4, 20, 28,..., 99,6. Estas fallas se consideran fallas

coincidentes causadas por fallas comunes o fallas no
relacionadas entre dos versiones. Por lo tanto, la
suposición de independencia no es válida para estos datos
30
de prueba.
25 establecer.

20
En este ejemplo, asumimos que todas las fallas
15 coincidentes son fallas comunes. Entonces podemos
10 clasificar las fallas de software en este sistema de 2VP de
5 acuerdo con la notación de la Sección 33.5. La Tabla 33.6
0 se genera directamente a partir de la Tabla 33.5 pero
0 50 100 150 200 250
muestra los diferentes tipos de fallas en este sistema de 2VP.
Tiempo (horas) Modificaciones de confiabilidad para NVP (N = 2)
Sistemas. Dado que el sistema que presentamos en la
Figura 33.12. Función de valor medio m2(t ) curva de ajuste para la versión 2 Sección 33.5 es un sistema 3VP, y el sistema aquí es un
sistema NVP (N = 2), el modelo de confiabilidad se puede
modificar fácilmente. Si mantenemos las mismas
suposiciones que para los sistemas NVP (N = 3) en la
Sección 33.5, podemos obtener las siguientes ecuaciones:
1. Tipo de error AB
1

0.8
m AB(t) = b(aAB ÿ p1p2mAB(t)) (33.42)
0.6
Corteza( ) t con condiciones marginales mAB(0) = 0 y aAB(0) = aAB.
0.4 La solución a la Ecuación 33.42 es:
R t 1( )
0.2 aAB
mAB(t) = (1 ÿ eÿpb1p2t ) (33.43)
Rt 2( )
0 p1p2 2.
0 50 100 150 200 250
Tipo de falla A
Tiempo de prueba (con misión = 50) x
m A(t) = b(aA(t) ÿ p1mA(t)) a A(t)
Figura 33.13. Fiabilidad del sistema independiente con tiempo de misión x = = (1 ÿ p1)p2m AB(t) + ÿ1(m A(t)
50
+ m AB(t)) (33.44)
Machine Translated by Google

Tolerancia a fallos de software 605

Tabla 33.6. Tabla de tipos de fallas para el sistema 2VP Sustituya la Ecuación 33.43 en la Ecuación 33.46
y resolvemos, obtenemos la función de valor medio
falla no. Tiempo de falla (hr)
como:

Fallo A Fallo B Fallo AB

1,2 3,6 8.4 mB(t) = CB1 + CB2 eÿbp1p2t + CB3 eÿb(p2ÿÿ2)t

1 2,8 12,8 20
(33.47)
2 10 14,4 28
dónde
3 16,4 17,2 31.2
4 24,4 18 36.8
5 29,2 23,2 39.2 ab aAB((1 ÿ p2)p1 + ÿ2)
6 34 25,2 62.4
CB1 = + p1p2(p2 ÿ
p2 ÿ ÿ2 ÿ2)
7 36 28,4 99.6
8 40 30,8
9 44 34.8
10 44,8 36.4 ((1 ÿ p2)p1 + ÿ2)aAB
11 54 38 CB2 = ÿ
12 56 41.6 p1p2(p2(1 ÿ p1) ÿ ÿ2)
13 80 92 42
14 46.4
15 59.6
((1 ÿ p2)p1 + ÿ2)aAB ab
16 98.8
CB3 =
ÿ

17 18 100 (p2 ÿ ÿ2)(p2(1 ÿ p1) ÿ ÿ2) p2 ÿ ÿ2

Las funciones de verosimilitud son:

con condiciones marginales mA(0) = 0 y aA(0) =

n/A
aA, donde aA es el número inicial de falla tipo A [mA(ti) ÿ mA(tiÿ1)] yAiÿyA(iÿ1)
LA =
en el sistema de software de programación de dos versiones. yo=1 (yAi ÿ yA(iÿ1))!
Sustituya la Ecuación 33.43 en la Ecuación 33.44
y resolvemos, obtenemos la función de valor medio × eÿ [mA (ti) ÿmA (ti ÿ 1)] (33.48)
como:

nótese bien

[mB(ti) ÿ mB(tiÿ1)] yBiÿyB(iÿ1)

mA(t) = CA1 + CA2 eÿbp1p2t + CA3 eÿb(p1ÿÿ1)t LB =
(33.45) yo=1 (yBi ÿ yB(iÿ1))!
dónde
× eÿ[mB(ti)ÿmB(tiÿ1)] (33.49)
Automóvil club británico
((1 ÿ p1)p2 + ÿ1)aAB
CA1 = +
p1 ÿ ÿ1 p1p2(p1 ÿ ÿ1) n AB
[mAB(ti) ÿ mAB(tiÿ1)] yABiÿyAB(iÿ1)
LABORATORIO =
((1 ÿ p1)p2 + ÿ1)aAB (yABi ÿ yAB(iÿ1))!
CA2 = ÿ yo=1
p1p2(p1(1 ÿ p2) ÿ ÿ1)
((1 ÿ p1)p2 + ÿ1)aAB Automóvil club británico × eÿ[mAB(ti)ÿmAB(tiÿ1)] (33.50)
CA3 =
ÿ

(p1 ÿ ÿ1)(p1(1 ÿ p2) ÿ ÿ1) p1 ÿ ÿ1

3. Tipo de falla B La función de verosimilitud unida es:

m B(t) = b(aB(t) ÿ p2mB(t))

a B(t) = (1 ÿ p2)p1m AB(t) L = LALBLAB (33.51)

+ ÿ2(m B(t) + m AB(t)) (33.46)

y el logaritmo de la función de verosimilitud unificada es:
con condiciones marginales mB(0) = 0 y aB(0) =
aB, donde aB es el número inicial de falla tipo B
en el sistema de software de programación de dos versiones. ln(L) = ln(LA) + ln(LB) + ln(LAB) (33.52)
Machine Translated by Google

606 Prácticas y aplicaciones emergentes

Tabla 33.7. Diferentes MLE con respecto a diferentes valores de p

p1 p2 b b1 B2 Automóvil club británico ab aAB MLES

0,8 0,8 0,01154 0,09191 0,00697 10,9847 15,0367 6,26062 ÿ55,4742

0,8 0,85 0,0108 11,916 16,15360.05699
6,431050.0175
ÿ55,4736
0,8 0,9 0,00979 0,0074 0,01101 13,2279 17,7376 7,00032 ÿ55,4822
0,8 0,95 0,01151 0,0824 0,17392 10,9706 14,2399 6,86717 ÿ55,4422
0,85 0,8 0,01317 0,1892 0,09393 9,5187 12,3296 6,10969 ÿ55,4370
0,85 0,85 0,01043 0,09122 0,0069 12,2912 16,3465 7,01585 ÿ55,4645
0,85 0,9 0,00965 0,05227 0,00823 13,2884 17,7446 7,40755 ÿ55,4674
0,85 0,95 0,00901 0,01475 0,00893 14,3285 19,1661 7,7771 ÿ55,4709
0,9 0,8 0,01105 0,15425 0,00372 11,6603 14,8114 7,10012 ÿ55,4644
0,9 0,85 0,0114 0,18026 0,07047 11,0824 14,3879 6,91714 ÿ55,4428
0,9 0,9 0,00956 0,0983 0,00513 13,465 17,7861 7,77652 ÿ55,4583
0,9 0,95 0,00997 0,1196 0,09461 12,7394 16,5588 7,77522 ÿ55,4468
0,95 0,8 0,01126 0,2196 0,01224 11,2847 14,5756 6,94388 ÿ55,4478
0,95 0,85 0,01069 0,20046 0,0329 11,8325 15,4577 7,3401 ÿ55,4449
0,95 0,9 0,02206 13,3545
0,0096317,2171
0,1448 0,95
7,9219 ÿ55,4485
0,95 0,00936 0,1384 0,05541 13,6155 17,7036 8,22915 ÿ55,4484

o equivalente, Estimación de máxima verosimilitud. el conjunto de datos

en la Tabla 33.5 no proporciona suficiente información sobre
qué categoría (fallas comunes
n/A

en L = o fallas independientes concurrentes) esas fallas

{(yAi ÿ yA(iÿ1)) ln(mA(ti) ÿ mA(tiÿ1))
yo=1
pertenece a. Dado que las fallas comunes son fallas
dominantes, simplemente asumimos que todas las fallas
ÿ (mA(ti) ÿ mA(tiÿ1))
coincidentes son fallas comunes para simplificar esto.
ÿ ln((yAi ÿ yA(iÿ1))!)} problema.
nótese bien
La eficiencia de eliminación de errores, p, suele ser
+ {(yBi ÿ yB(iÿ1)) considerado como un parámetro conocido, en su mayoría 0.8 ÿ
yo=1
p ÿ 0,95. Se puede determinar empíricamente
× ln(mB(ti) ÿ mB(tiÿ1)) datos. En este estudio, primero elegimos el valor de p
ÿ (mB(ti) ÿ mB(tiÿ1)) arbitrariamente, luego calcule los MLE para todos los demás
parámetros desconocidos.
ÿ ln((yBi ÿ yB(iÿ1))!)}
La tabla 33.7 muestra los resultados del cálculo para
coger

+ MLE con respecto a varios valores de p1 y p2 .

{(yABi ÿ yAB(iÿ1))
yo=1
Aquí elegimos p1 = p2 = 0.9, por lo que los MLE para todos
los parámetros son:
× ln(mAB(ti) ÿ mAB(tiÿ1))
ÿ (mAB(ti) ÿ mAB(tiÿ1)) aˆA = 15.47 aˆB = 18.15 aˆAB = 7.8

ÿ ln((yABi ÿ yAB(iÿ1))!)} (33.53) ÿˆ 1 = 0 ÿˆ 2 = 0.002324 bˆ = 0.009

Entonces podemos obtener la confiabilidad del software de este

Obtenga derivados en la Ecuación 33.53 con respecto a
cada parámetro desconocido y establecerlos en 0,
entonces obtenemos un conjunto de ecuaciones. Al resolver esos
ecuaciones simultáneamente, finalmente podemos obtener
los parámetros del modelo.
Sistema NVP (N = 2) como:
RNVP-SRGM(t) = R(x | t) = eÿ(mAB(t+x)ÿmAB(t ))
(33.54)
La tabla 33.8 muestra los resultados del cálculo de la media
funciones de valor Las Figuras 33.15–33.17 muestran el
Machine Translated by Google
Machine Translated by Google

608 Prácticas y aplicaciones emergentes

y la matriz de varianza es:

10
41.473 40.4 5.625
8
ÿ 40.4 143.61 13.28
ÿ

6 ÿ1
ÿ
5.625 13.28 9.511
V=H = ÿ

ÿ
ÿ1.384 ÿ1.397 ÿ0,215
4 ÿ

ÿ
ÿ1,33 ÿ4.645 ÿ0,467
2 ÿ0.0194 ÿ0.0431 ÿ0,0063
ÿ
0 ÿ1.384 ÿ1,33 ÿ0.0194
0 20 40 60 80 100 ÿ
ÿ1.397 ÿ4.645 ÿ0.0431
ÿ

tiempo normalizado
ÿ0,215 ÿ0,467 ÿ0,0063 ÿ

0.0778 0.046 0.00067 ÿ

Figura 33.17. Función de valor medio mAB(t )curva de ajuste ÿ

0.046 0.181 0.00142 ÿ

0.00067 0.00142 2,067 × 10ÿ5 ÿ

Entonces las varianzas de las estimaciones son:

Dada la función de verosimilitud logarítmica

Sí(aˆA) = 41.473 Sí(aˆB) = 143,61

L = ln(LA) + ln(LB) + ln(LAB) sí(aˆAB) = 9.511

Var(ÿˆ 1) = 0,0778 Var(ÿˆ 2) = 0,181

Si usamos xi, i = 1, 2,..., 6, para denotar todos los parámetros
en el modelo para simplificar la expresión: Var(b)ˆ = 2.067 × 10ÿ5

Las figuras 33.18–33.20 muestran las funciones de valor medio

x1 ÿ aA y sus intervalos de confianza del 95%, así como
x2 ÿ aB el número de fallas acumuladas.
x3 ÿ aAB
La Figura 33.21 muestra la confiabilidad del sistema NVP
x4 ÿ ÿ1 y su intervalo de confianza del 95% dado el valor fijo
x5 ÿ ÿ2 tiempo de misión x = 10 horas asumiendo la confiabilidad
x6 ÿ segundo estimación sigue una distribución normal. Uno puede

ver que el intervalo de confianza de confiabilidad se reduce

El resultado numérico real para Fisher cuando las personas dedican más tiempo a eliminar las fallas
matriz de información es: del sistema NVP. Esto significa que después de que la gente

0,0763 0.0042
ÿ 0 0,0042 0 ÿ0,051 0.0037
ÿ

ÿ
1,028 0,0037 0.132
H= ÿ

ÿ
0 0.0825
ÿ
0 1.043 0.133

ÿ 39.48 36.55 40.11

1.028 0 39.48
0 1.043 36.55 ÿ
ÿ

0.0825 0.133 40.11 ÿ

31.68 0 ÿ37,38 ÿ

0 33.26 ÿ68,38 ÿ

ÿ37,38 ÿ68,38 179746.12 ÿ Figura 33.18. Intervalo de confianza para la función de valor medio
mA (t)
(33.55)
Machine Translated by Google

Tolerancia a fallos de software 609

30 0.8

25
0.6
Fiabilidad

20 límite superior
fallas R t NVP–SRGM( ) R 1t ( )
acumuladas
fallas
de
#

15 0.4
metro B( )
10
Límite inferior 0.2
5
Rt 2( )
0 0
0 50 100 150 200 250 0 50 100 150 200 250

Tiempo (horas) Tiempo de prueba (misión = 50) x

Figura 33.19. Intervalo de confianza para la función de valor medio Figura 33.22. Sistema NVP y curvas de confiabilidad de una sola versión
mB(t) con tiempo de misión x = 50

dieciséis Fiabilidad 0.8

R t NVP–SRGM( )
R 1t ( )
14
0.6
12
límite superior Rt 2( )
10 0.4
monte
A()B
acumuladas
fallas
de
#

8
fallas 0.2
6
4 0
Límite inferior 0 50 100 150 200 250
2
0 Tiempo de prueba (misión = 10) x
0 50 100 150 200 250

Tiempo (horas) Figura 33.23. Sistema NVP y curvas de confiabilidad de una sola versión
con tiempo de misión x = 10

Figura 33.20. Intervalo de confianza para la función de valor medio

mAB(t )

adquirir más conocimientos sobre el sistema NVP, más

Se pueden hacer estimaciones precisas para evaluar la
Confiabilidad del sistema NVP.
1 La función de confiabilidad del sistema NVP
0.9 límite superior RNVP-SRGM(x | t) y software de versión única
0.8
Fiabilidad
confiabilidad R1(x | t) y R2(x | t) se muestran en
0.7
0.6 Figuras 33.22 y 33.23 con tiempo de misión x = 50
0.5 y x = 10, respectivamente.
R xt NVP–SRGM( /)
0.4
De las Figuras 33.22 y 33.23, podemos ver
0.3 Límite inferior
0.2 que el esquema 2VP tiene mayor confiabilidad que
0.1 cualquier componente individual. Esto significa que el esquema
0
0 50 100 150 200 250 300 de programación de la versión N puede proporcionar
mayor confiabilidad del sistema.
Tiempo de prueba (horas) (tiempo de misión = 10) x
Si comparamos la Figura 33.23 con la Figura 33.14,
entonces podemos ver claramente que aunque el software
Figura 33.21. Fiabilidad del sistema NVP y su confianza del 95 %
intervalo las versiones se desarrollan de forma independiente, común
las fallas no se pueden ignorar en este sistema NVP.
Machine Translated by Google
610 Prácticas y aplicaciones emergentes
Cuando la confiabilidad del componente es alta, la
suposición independiente conducirá a la sobreestimación
de la confiabilidad del sistema.
En este ejemplo, asumimos que todas las fallas
simultáneas son fallas comunes. Si los tipos de fallas
concurrentes son diferentes, la función de confiabilidad
será un poco diferente: las fallas independientes se
incorporarán a la función de confiabilidad, aunque
generalmente las fallas comunes dominan las fallas
concurrentes entre las versiones.
Como el primer modelo de este tipo en el área de
modelado de confiabilidad NVP, el modelo de crecimiento
de confiabilidad del software NVP propuesto se puede
utilizar para superar las deficiencias del modelo de
confiabilidad independiente. Predice la confiabilidad del
sistema con mayor precisión que el modelo independiente
y se puede usar para ayudar a determinar cuándo
detener la prueba, que será una de las preguntas clave
en la fase de prueba y depuración del ciclo de vida del sistema NVP. B. Estructura del sistema para tolerancia a fallas de software.
33.7 Conclusión
Este capítulo presenta un modelo de confiabilidad de
progreso de Poisson no homogéneo para sistemas de
programación de versión N. Separamos todas las fallas
dentro de los sistemas NVP en fallas independientes y
fallas comunes, y modelamos cada tipo de falla como NHPP.
Además, desarrollamos un modelo de confiabilidad para
fallas comunes en los sistemas NVP y también
presentamos un modelo para fallas independientes
concurrentes en los sistemas NVP. Al combinar el modelo
CF y el modelo CIF, establecemos un modelo de
confiabilidad NHPP para los sistemas NVP. También
damos un ejemplo para ilustrar cómo estimar todos los
parámetros desconocidos usando el método de
estimación de máxima verosimilitud, y cómo calcular las
varianzas para todas las estimaciones de parámetros
para obtener los intervalos de confianza de la predicción
de confiabilidad del sistema NVP.
Referencias
[1] Voas J, Dugan JB, Hatton L, Kanoun K, Laprie JC, Vouk MA. Mesa
redonda de tolerancia a fallas. Software IEEE 2001; julio/agosto: 54–
7.
[2] Chen L, Avizienis A. Programación de versión N: un enfoque de
tolerancia a fallas para el software confiable. Proc 8th Int Symp
Computación tolerante a fallas, Toulouse, Francia; 1978. págs. 3–9.
[3] Avizienis A, Chen L. Sobre la implementación de la programación de
la versión N para la tolerancia a fallas del software durante la
ejecución del programa. Proc COMPASAC 77; 1977. págs. 149–55.
[4] Eckhardt D, Lee L. Una base teórica para el análisis de software
multiversión sujeto a errores coincidentes. IEEE Trans Software Eng
1985;SE-11(12):1511–7.
[5] Scott RK, Gault JW, McAllister DF. Modelado de confiabilidad tolerante
a fallas. IEEE Trans Software Eng 1987;SE 13(5):582–92.
[6] Littlewood B, Miller DR. Modelado conceptual de fallas coincidentes en
software multiversión. IEEE Trans Software Eng 1989;15(12):1596–
614.
[7] McAllister DF, Sun CE, Vouk MA. Confiabilidad de votación en
sistemas de software tolerantes a fallas para espacios de salida pequeños.
IEEE Trans Reliab 1990;39(5):524–34.
[8] Leung YW. Votación de máxima probabilidad para software tolerante
a fallas con espacio de salida finito. IEEE Trans Reliab 1995;44(3):419–
26.
[9] Randell
IEEE Trans Software Eng 1975;SE-1(2):220–32.
[10] Fairley R. Conceptos de ingeniería de software. McGraw Hill:
Nueva York; 1985.
[11] Belli F, Jedrzejowicz P. Programas tolerantes a fallas y su
fiabilidad. IEEE Trans Reliab 1990;29(2):184–92.
[12] Nicola VF, Goyal A. Modelado de fallas correlacionadas y recuperación
de errores de la comunidad en software multiversión. IEEE Trans
Software Eng 1990;16(3):350–9.
[13] Lyu SR. Mejorar el proceso de programación de la versión N a través
de la evolución de un paradigma de diseño. IEEE Trans Reliab
1993;42(2):179–89.
[14] Knight JC, Leveson NG. Una evaluación experimental de la suposición
de independencia en la programación multiversión. IEEE Trans
Software Eng 1986;SE-12.
[15] Scott RK, Gault JW, McAllister DF, Wiggs J. Validación experimental
de seis modelos de confiabilidad de software tolerante a fallas.
Documentos de excavación FTCS-14: 14th Ann Symp Informática
tolerante a fallas, Kissemmee, NY; 1984. págs. 102–7.
[16] Eckhardt DE, Caglayan AK, Knight JC, Lee LD, McAllister DF, Vouk
MA, Kelly JPJ. Una evaluación experimental de la redundancia de
software como estrategia para mejorar la confiabilidad. IEEE Trans
Software Eng 1991;17(7):692–702.
[17] Voas J, Ghosh A, Charron F, Kassab L. Reducción de la incertidumbre
sobre las fallas de modo común. En: Proc Int Symp on Software
Reliability Engineering, ISSRE; 1997. págs. 308–19.
[18] Laprie JC, Arlat J, Beounes C, Kanoun K. Definición y análisis de
arquitecturas tolerantes a fallas de hardware y software. Computación
IEEE 1990;23(7):39–51.
[19] Dugan JB, Lyu MR. Análisis de confiabilidad del sistema de una
aplicación de programación de versión N. IEEE Trans Reliab
1994;43(4):513–9.
[20] Tai AT, Meyer JF, Aviziems A. Mejora de la capacidad de ejecución
del software tolerante a fallas. IEEE Trans Reliab 1993;42(2):227–
37.
Machine Translated by Google
[21] Goseva-Popstojanova K, Grnarov A. Modelado de capacidad de
ejecución de la técnica de programación de versión N. En: Proc 6th
IEEE Int Symp on Software Reliability Engineering (ISSRE'95),
Toulouse, Francia.
[22] Lin HH, Chen KH. Modelos de depuración de software de proceso de
Poisson no homogéneos con dependencia lineal.
IEEE Trans Reliab 1993;42(4):613–7.
[23] Kanoun K, Kaaniche M, Beounes C, Laprie JC, Arlat J.
Crecimiento de la confiabilidad del software tolerante a fallas. IEEE
Trans Reliab 1993;42(2):205–18.
[24] Sha L. Usar la simplicidad para controlar la complejidad. IEEE
Software 2001; julio/agosto: 20–8.
[25] Zhang X, Teng X, Pham H. Un modelo de confiabilidad de software
generalizado con eficiencia de eliminación de errores. IEEE Trans
Syst, Man Cybernet 2002: presentado.
Tolerancia a fallos de software 611
[26] Pham H. Fiabilidad del software. Springer-Verlag; 2000.
[27] Goel AL, Okumoto K. Modelo de tasa de detección de errores
dependiente del tiempo para software y otras medidas de rendimiento.
IEEE Trans Reliab1979;28:206–11.
[28] Pham H, Nordmann L, Zhang X. Un modelo de depuración de software
imperfecto general con tasa de detección de fallas en forma de s.
IEEE Trans Reliab 1999;48(2):168–75.
[29] Pham H, Zhang X. Un modelo de confiabilidad del software NHPP y su
comparación. Int J Reliab, Qual Safety Eng 1997;4(3):269–82.
[30] Teng X, Pham H. Un modelo de crecimiento de la confiabilidad del
software para la programación de versiones N. IEEE Trans Reliab
2002;51(3):en prensa.
[31] Pham H, Pham M. Modelos de confiabilidad de software para
aplicaciones críticas. INEL, EG&G-2663; 1991.
Machine Translated by Google

Esta página se dejó en blanco intencionalmente

Machine Translated by Google

markoviano
Fiabilidad/Performabilidad
Modelado de Sistemas Tolerantes a Fallos
Juan A. Carrasco

34.1 Introducción

34.2 Medidas

34.2.1
Tasa esperada de recompensa en estado estacionario
34.2.2 Recompensa acumulada esperada hasta la salida de un subconjunto de estados

34.2.3 Recompensa acumulativa esperada durante la estadía en un subconjunto de estados

34.2.4 Tasa de Recompensa Transitoria Esperada

34.2.5 Tasa de recompensa promedio esperada

34.2.6 Distribución acumulativa de recompensas hasta la salida de un subconjunto de estados

34.2.7 Distribución acumulativa de recompensas durante la estadía en un subconjunto de estados

34.2.8 Distribución acumulativa de recompensas

34.2.9 Estructuras de recompensas extendidas

34,3 especificación del modelo

34,4 Solución modelo

34,5 El problema de la grandeza

34,6 Un caso de estudio
34,7 Conclusiones

34.1 Introducción configuración del sistema. Este último es, por lo general,
más complejo de implementar y requiere falla
Creciente demanda de confiabilidad del sistema detección (reconociendo que ha ocurrido una falla),
(entendido en su sentido amplio, es decir , como el ubicación de la falla (identificación del componente defectuoso),
capacidad del sistema para funcionar correctamente) ha contención de fallas (aislar el componente defectuoso
motivó un mayor interés en tolerancia a fallas para que no produzca errores que se propaguen
sistemas Un sistema tolerante a fallos es aquel que en todo el sistema), y la recuperación de fallas
puede continuar la operación correcta con o sin (restaurar el sistema a un estado correcto desde el cual
desempeño degradado en presencia de fallas, para continuar la operación si un estado incorrecto ha sido
es decir , defectos físicos, imperfecciones, alcanzó). Todas estas técnicas de tolerancia a fallas
perturbaciones o fallas de diseño en el hardware o requieren la adición de redundancia de hardware
componentes de software La tolerancia a fallas puede ser componentes de hardware), redundancia de información
logrado por el enmascaramiento de fallas, es decir , por la prevención de fallas (información redundante), redundancia de tiempo (extra
de producir errores sin eliminar la cálculos), o redundancia de software (extra
componentes defectuosos del sistema operativo componentes de software). replicación de hardware
configuración, o por reconfiguración, es decir , eliminando componentes es un ejemplo de hardware
los componentes defectuosos de la operativa redundancia; detección de errores y corrección de errores

613
Machine Translated by Google
614 Prácticas y aplicaciones emergentes
los códigos son ejemplos de redundancia de información;
cálculo repetido y puntos de control son
ejemplos de redundancia de tiempo; consistencia
comprobaciones, programación de versión N y recuperación
Los bloques son ejemplos de redundancia de software.
La adición de redundancia afecta negativamente
algunas características del sistema como
costo, rendimiento, tamaño, peso y potencia
consumo y, durante el diseño de un sistema tolerante a fallas,
esos impactos deben equilibrarse
contra el aumento logrado en la confiabilidad del sistema.
La tolerancia a fallas es un enfoque atractivo para
diseñar sistemas que, sin tolerancia a fallos,
tendría un nivel de confiabilidad inaceptable.
Esto incluye sistemas para computación crítica
aplicaciones tales como control de vuelo de aeronaves y
control de procesos químicos peligrosos, sistemas irreparables
con largos tiempos de misión como
sistemas no tripulados de naves espaciales de larga duración, sistemas
que requieren una alta disponibilidad de computación
recursos, datos o ambos, como el cambio de llamadas
sistemas y sistemas de reservas de líneas aéreas, y
sistemas con grandes cantidades de hardware/software
como grandes multiprocesadores. nanométrica
sistemas en chip es un área en la que falla
la tolerancia puede volverse cada vez más atractiva.
Esto se debe a que, a medida que se reducen los tamaños de las características,
Las estructuras nanoelectrónicas se vuelven cada vez más
susceptible a defectos de fabricación, degradación
procesos y perturbaciones externas, y
puede suceder en un futuro cercano que aceptable
niveles de rendimiento/fiabilidad operativa para complejos
Los sistemas nanométricos en chip solo se pueden lograr
mediante el uso de la tolerancia a fallos.
El modelado juega un papel importante en el diseño y
análisis de sistemas tolerantes a fallas. Esto es
claramente cierto en las primeras etapas de diseño y cuando
tiene que ser certificado que un sistema existente logra
un nivel de fiabilidad muy alto. El modelado también permite
Estudiemos cómo los cambios en el diseño y la operación de
un sistema existente pueden afectar su confiabilidad sin
modificar realmente el sistema.
Fallas de componentes, mecanismos de recuperación de fallas,
las actividades de mantenimiento y, a menudo, las actividades
relacionadas con el rendimiento tienen un comportamiento estocástico y, niveles Un ejemplo del concepto de performabilidad.
por lo tanto, se deben utilizar modelos estocásticos. Típico
los parámetros de esos modelos son fallas de componentes
tasas, probabilidades de cobertura (es decir, las probabilidades
que las fallas de ciertas clases se recuperen con éxito),
características del tiempo de reparación del componente
distribuciones y características de las actividades relacionadas
con el desempeño. Estimación de esos parámetros
es el primer paso para construir un modelo. Tales estimaciones
pueden obtenerse de las especificaciones del sistema,
datos recopilados de sistemas similares que están bajo
operación, datos proporcionados por los fabricantes/
desarrolladores de componentes (por ejemplo, tiempo medio para
fallas de componentes de hardware/software), modelos
estandarizados disponibles (por ejemplo, el modelo MIL
HDBK-217E para la estimación de tasas de falla
de componentes de hardware), o la experimentación en
el sistema real, un prototipo o un modelo de simulación más o
menos detallado del sistema (experimentos de inyección de
fallas para estimar los parámetros de cobertura
son un ejemplo; ver Iyer y Tang [1] para una encuesta
de esas técnicas).
La confiabilidad de un sistema tolerante a fallas puede
cuantificarse mediante varias medidas que resumen
el comportamiento del sistema percibido por sus
usuarios Muchos sistemas pueden ser considerados como
funcionando correctamente (hacia arriba) o funcionando
incorrectamente o sin funcionar en absoluto (hacia abajo). Para esos
sistemas, medidas simples de confiabilidad tales como
el tiempo medio hasta el fallo, la medida de fiabilidad
(probabilidad de que el sistema haya estado continuamente
activo), y la disponibilidad (probabilidad de que
el sistema está activo en un momento dado) son apropiados.
Muchos otros sistemas, sin embargo, son degradables, en
la sensación de que su desempeño puede degradarse como
los componentes fallan. Medidas simples de confiabilidad
puede generalizarse para evaluar la fiabilidad de
esos sistemas asociando niveles de desempeño
con estados del sistema e incluidos en el subconjunto up
los estados en los que el sistema tiene un rendimiento
por encima o igual a cada uno de esos niveles [2]. un mas
El enfoque general es el concepto de performabilidad
introducido por Meyer [3]. En ese enfoque, el comportamiento
percibido por el usuario del sistema se cuantifica mediante un
conjunto discreto o continuo de niveles de logro y la
realizabilidad se define como la probabilidad de un subconjunto
medible de logros
sería la distribución del acumulado
rendimiento (por ejemplo, número de procesados)
Machine Translated by Google
Modelado markoviano de confiabilidad/rendimiento de sistemas tolerantes a fallas
transacciones en un sistema orientado a transacciones) de
un sistema durante un intervalo de tiempo. Otro ejemplo [4]
sería la distribución de la fracción de tiempo durante un
intervalo de tiempo en el que un canal de comunicación deja
de proporcionar una determinada calidad de servicio a las
fuentes de tráfico admitidas.
Una vez que se ha seleccionado un modelo y una medida,
se debe especificar y resolver el modelo. La dificultad para
resolver el modelo depende tanto de las características del
modelo como de la medida. Los métodos de solución
combinatoria permiten un análisis eficiente de sistemas muy
complejos, pero tienen un ámbito de aplicación restringido.
En los métodos combinatorios (ver Abraham [5] y Aggarwal
et al. [6]), el sistema tolerante a fallas se conceptualiza como
compuesto de componentes que pueden fallar/no fallar y el
sistema está arriba/abajo según lo determinado por la falla/
fallo. estado de los componentes por una función de
estructura, generalmente representada por un árbol de fallas.
Los métodos combinatorios calculan la probabilidad de que
el sistema esté arriba/abajo a partir de las probabilidades de
que los componentes no fallen/fallen, asumiendo que los
estados de los componentes son independientes. Esto
permite calcular la disponibilidad de sistemas que tienen
componentes con comportamiento independiente y la
confiabilidad de sistemas no reparables con funciones de
estructura coherente y componentes con comportamiento
independiente, ya que para esos sistemas la confiabilidad en
el tiempo t es igual a la disponibilidad en el tiempo t.
Recientemente se han desarrollado métodos combinatorios
que permiten una cobertura imperfecta [7–9]. Cuando el
sistema tolerante a fallas se puede descomponer en
subsistemas con comportamiento independiente, algunas
medidas se pueden calcular jerárquicamente. La herramienta
SHARPE ha sido diseñada para adaptarse a tales técnicas, y
los ejemplos presentados por Sahner y Trivedi [10] las ilustran
muy bien. Sin embargo, el cálculo de medidas más complejas
o el cálculo de medidas simples cuando los componentes del
sistema tienen interacciones requieren un análisis directo de
un proceso estocástico que represente el comportamiento de
todo el sistema. En ese contexto, se utilizan comúnmente
cadenas de Markov de tiempo continuo homogéneo (CTMC).
Los CTMC surgen naturalmente cuando las actividades que
modifican el estado del sistema (procesos de falla, reparación
615
procesos y actividades relacionadas con el desempeño)
tienen duraciones con distribuciones exponenciales.
Las distribuciones de tipo de fase [11], particularmente las
distribuciones de tipo de fase acíclica, para las cuales existen
algoritmos de ajuste eficientes [12], se pueden usar para
acomodar (aproximadamente) distribuciones no exponenciales
en el marco CTMC, al precio de, por lo general, aumento
significativo en el tamaño de la CTMC.
En este capítulo hacemos una revisión, necesariamente
incompleta, de las técnicas para el modelado markoviano de
confiabilidad/rendimiento de sistemas tolerantes a fallas. En
la revisión, a menudo haremos referencia a la herramienta
METFAC-2.1, actualmente en desarrollo. El resto del capitulo
esta organizado como sigue. La Sección 34.2 define y, en
algunos casos, formaliza el cálculo de un conjunto de medidas
genéricas definidas sobre CTMC recompensadas que abarcan
muchas medidas de confiabilidad, así como instancias
particulares de la medida general de rendimiento. La Sección
34.3 revisa las metodologías de especificación de modelos.
La sección 34.4 revisa las técnicas numéricas para la solución
de modelos.
La sección 34.5 revisa las técnicas disponibles para tratar el
problema de la amplitud con énfasis en los métodos de
delimitación. La Sección 34.6 ilustra algunas de las técnicas
revisadas en las secciones anteriores con un estudio de caso.
Finalmente, la Sección 34.7 presenta algunas conclusiones.
34.2 Medidas
Los modelos CTMC recompensados han surgido en los
últimos años como un poderoso formalismo de modelado.
Un CTMC recompensado es un CTMC con una estructura de
recompensas impuesta sobre él. La estructura de recompensas
puede incluir tasas de recompensa asociadas con estados y
recompensas de impulso asociadas con transiciones.
Las tasas de recompensa especifican la tasa a la que se
gana la recompensa mientras la CTMC se encuentra en
estados particulares; Las recompensas de impulso son
recompensas obtenidas cada vez que se sigue una transición de la CTM
Se puede usar una estructura de recompensa adecuada para
cuantificar muchos aspectos del comportamiento del sistema:
confiabilidad, rendimiento, costo de operación, consumo de
energía, etc. El comportamiento probabilístico de la
recompensa resultante se puede resumir
Machine Translated by Google
616 Prácticas y aplicaciones emergentes
utilizando diferentes medidas de recompensa. Muchas
medidas de confiabilidad tradicionales se obtienen como
instancias particulares de esas medidas genéricas mediante
el uso de estructuras de recompensa particulares. En esta
sección, definiremos y, en algunos casos, formalizaremos
el cálculo de ocho medidas de recompensa. Todas esas
medidas estarán respaldadas por la herramienta
METFAC-2.1 y asumirán una estructura de recompensa
que incluye solo tasas de recompensa.
Para formalizar el cómputo de algunas de esas medidas,
es necesario utilizar algunos conceptos básicos sobre
CTMC. La terminología de las CTMC no está bien
establecida y utilizaremos la nuestra.
Además, utilizaremos sin referencia ni prueba tanto los
resultados conocidos como los resultados que se pueden
obtener con algún esfuerzo. Sea X = {X(t); t ÿ 0} sea una
CTMC con espacio de estado finito y vector fila de
distribución de probabilidad inicial ÿ = (ÿi)iÿ , donde ÿi =
P[X(0) = i]. Sea ÿi,j , i, j ÿ i = j la tasa de transición de, Xestado
del
i al estado j , sea ÿi,B = jÿB ÿi,j , B ÿ ÿ {i}, sea ÿi = jÿ ÿ {i} ÿi,j ,
i ÿ denota(ai,j
la tasa
)i,jÿ de
, i =salida
ÿi,jde
j denota Xladel yo ÿ
estado
transición
, matriz de tasas, i,ai,i
y(también
sea A ai,j
= ÿÿi,
llamada
generador infinitesimal) de X. El diagrama de transición de
estado de X es un conjunto
dígrafodeetiquetado
nodos y un
etiquetado con ÿi,j de cada estado i a cada estado j con ÿi,j
> 0.elElvector
transición de estado junto con análisis
fila del diagrama de
de distribución
de probabilidad inicial ÿ proporciona información sobre el
comportamiento cualitativo de las probabilidades transitorias
pi(t) = P[X(t) = i], i ÿ de los estados de X .
Se dice que dos estados i, j ÿ están fuertemente
conectados si y solo si hay caminos en el diagrama de
transición de estado tanto de i a j como de j a i. Un estado
está fuertemente conectado consigo mismo. La conectividad
de estado fuerte es una relación de equivalencia.
Las clases de equivalencia correspondientes se denominan
componentes de la CTMC. Un componente es, entonces,
un subconjunto máximo de estados fuertemente conectados.
Se dice que un estado i es inalcanzable si pi(t) = 0 para
todo t y alcanzable en caso contrario. Es fácil probar que
todos los estados de un componente son alcanzables o
todos los estados de un componente son inalcanzables.
Entonces, podemos hablar correctamente sobre componentes
alcanzables e inalcanzables.
Para determinar qué componentes de una CTMC son
inalcanzables, es útil definir el dígrafo de componentes de
una CTMC. El dígrafo de componentes de un CTMC es el
dígrafo acíclico que tiene un nodo para cada componente
del CTMC y un arco desde el componente C al componente
C si y solo si el diagrama de transición de estado del CTMC
tiene un arco desde algún estado en C a algún estado Cía .
Para ilustrar los conceptos definidos hasta ahora, la Figura
34.1 muestra el diagrama de transición de estado de un
CTMC pequeño y el dígrafo de componentes correspondiente.
Sea ÿB = iÿB ÿi, B ÿ . Entonces, un componente C es
inalcanzable si y solo si ÿC =dígrafo
0 y no de
haycomponentes
un camino endesde
el
un componente C con ÿC > 0 a C. Los estados en
componentes inalcanzables pueden descartarse al analizar
un CTMC y, en lo siguiente , supondremos que han sido
descartados y que todos los estados de la CTMC son
alcanzables.
Se dice que un estado i (alcanzable) es transitorio si, a
= = partir de i, existe una probabilidad no nula de que X
abandone i y nunca vuelva a él. Para un estado transitorio
conarco
un
i, limtÿÿ pi(t) = 0. Para un estado no transitorio i (alcanzable),
limtÿÿ pi(t) > 0. Se dice que un estado i es absorbente si y
solo si ÿi = 0. Se puede demostrar que todos los estados de
un componente son transitorios o no transitorios. Entonces,
podemos hablar apropiadamente de componentes
transitorios. Se dice que un componente que no es transitorio
está atrapado.
La clasificación de los componentes (alcanzables) de un
CTMC en transitorios y captura se puede realizar fácilmente
examinando el dígrafo de los componentes.
Un componente está reventado si y solo si el componente
no tiene un arco saliente en el dígrafo de componentes.
Para el ejemplo dado en la Figura 34.1, suponiendo que
todos los componentes son accesibles, los componentes
C1, C2 y C3 serían transitorios y los componentes C4 y C5
estarían atrapados.
Los componentes de reventado se denominan así porque,
una vez que X entra en un componente de reventado, nunca
lo abandona. Debe quedar claro que un estado absorbente
constituye en sí mismo un componente de captura. Se dice
que una CTMC que tiene un solo componente (de captura)
es irreducible.
Definimos en las Secciones 34.2.1–34.2.8 y, en algunos
casos, formalizamos el cálculo de ocho medidas de
recompensa definidas sobre CTMC recompensados X
Machine Translated by Google

Modelado markoviano de confiabilidad/rendimiento de sistemas tolerantes a fallas 617

C1 C2

1 3

2 4 C1 C2

C3

5
C3

C4 C4 C5

9
8 C5

Figura 34.1. Diagrama de transición de estado de un CTMC pequeño (izquierda) y el dígrafo de componentes correspondiente (derecha)

con espacio de estado finito. La estructura de la tasa de sea el vector fila que tiene como componentes las
recompensa incluye tasas de recompensa ri ÿ 0, con i ÿ probabilidades condicionales de estado estacionario de los
(medidas ESSRR, ETRR(t), EARR(t) y CRD(t, s)) o i ÿ B, estados en Ck (es decir, pkde
i estacionario esque
la probabilidad
X esté en elde estado
estado i
siendo B un subconjunto de (medidas ECRTE, ECRDS, condicionada a que X esté en Ck); for malmente, pk = limtÿÿ
CRDTE(s) y CRDDS(s)). Para estar bien definidas, algunas P[X(t) = i | iX(t)
apropiadas
ÿ Ck]. Sean
con0 todos
y 1 vectores
los elementos
fila de dimensiones
iguales a,
medidas requieren que X tenga propiedades especiales. respectivamente, 0 y 1; sea ACk,Ck la restricción de A a los
Más adelante, en la Sección 34.2.9, mostraremos cómo se estados en Ck (ACk ,Ck = (ai,j )i,jÿCk ); y sea xT la
pueden acomodar estructuras de recompensas más transpuesta de un vector x. Entonces, pk es la solución
generales para algunas medidas. normalizada (pk1TSea
= 1)pCk
del sistema
= limtÿÿ lineal
P[X(t)pkA Ck= ,Ck
ÿ Ck] iÿCk= pi.
0.
Tenemos pi = pCkpk i ÿ Ck . Ese resultado nos permite
34.2.1 Tasa esperada de recompensa en calcular pi, i ÿ Ck, 1 ÿ k ÿ my, por lo tanto, ESSRR a partir
estado estacionario de los vectores pk y pCk el
continuación , 1cálculo
ÿ k ÿ m.deDiscutimos
pCk , 1 ÿ kaÿ m.
yo ,

La medida se define como ESSRR = limtÿÿ E[rX(t )] y se

puede calcular como:

ESRR = ¿cuál?
iÿ
donde pi = limtÿÿ pi(t) es la probabilidad de estado
estacionario del estado i. Los estados transitorios tienen
probabilidades nulas de estado estacionario. Los estados
no transitorios tienen probabilidades de estado estacionario
> 0. Esas probabilidades se pueden calcular de la siguiente
manera. Sea S el subconjunto de estados transitorios de X
y sean C1, C2,...,Cm los componentes de captura de iX.
pkSea
= (pk )iÿCk
Si X tiene un solo componente de captura C1, entonces
X estará en C1 con probabilidad 1 para t ÿ ÿ y pC1 = 1. Si X
tiene varios componentes de captura y X no tiene estados
transitorios, entonces pCk = ÿCk .
Si X tiene estados transitorios y más de
un componente de captura, pCk = ÿCk + ÿk, donde ÿk es la
probabilidad de que X salga de S a través de Ck. Las
cantidades ÿk, 1 ÿ k ÿ m, pueden
Machine Translated by Google
618 Prácticas y aplicaciones emergentes
calcularse de la siguiente manera. Sea ÿi, i ÿ S el valor
esperado del tiempo pasado por X en el estado i (ÿi = 3
ÿ
pi(t) dt, <0 ÿ ya que i es transitorio). Después,
S el vector fila ÿ = (ÿi)iÿS es la solución de donde
sistema lineal ÿ SAS,S = ÿÿS son , AS,S y ÿS
las restricciones de, respectivamente, A y ÿ a S.
Sea el vector fila = (ÿi,Ckk )iÿS, entonces ÿk puede ser S kT.
S obtenido de ÿ como
de la medida ÿk = ÿsuponga
ESSRR, Como ejemplo
que
X modela un sistema tolerante a fallas que puede estar
activo o inactivo. Entonces, si se asigna una tasa de
recompensa 1 a los estados en los que el sistema está
activo y una tasa de recompensa 0 a los estados en los
que el sistema está inactivo, la medida ESSRR sería la
disponibilidad en estado estable del sistema tolerante a
fallas. sistema.
34.2.2 Recompensa acumulada esperada hasta
la salida de un subconjunto de estados
En esa medida, se supone que = B ÿ {a}, donde todos los
estados en B son transitorios y a es un estado absorbente.
La medida se define como:
T
rX(t) dt
ECRTE = E 2 0 Sea B un subconjunto propio de y suponga que cada
donde T = min{t : X(t) = a}. Es decir, 3 0 rX(tEn
) dt es la
T B y un estado fuera de B. Bajo esas circunstancias, X
variable
momento aleatoria
en que“recompensa
abandona el obtenida por B”
subconjunto X hasta el
y ECRTE
es su expectativa. Desde el punto de vista del modelado,
el CTMC X recompensado puede verse como un CTMC
que realiza un seguimiento del comportamiento hasta la
salida de B de un CTMC Y recompensado más grande que
en realidad modela el sistema en estudio. Formalmente, X
se puede definir a partir de Y como:
Y (t) si Y (ÿ ) ÿ B, 0 ÿ ÿ ÿ t
X(t) =
a de lo contrario
El diagrama de transición de estado de X se puede obtener
del diagrama de transición de estado de Y eliminando los
estados que no están en B, agregando el estado absorbente
a y dirigiendo a a las tasas de transición de los estados en
B a los estados fuera de B. La distribución de probabilidad
inicial de X está relacionado con la distribución de
probabilidad inicial de Y
por ÿi = P[Y (0) = i], i ÿ B, ÿa = P[Y (0) /ÿ B] y X tiene
asociado con los estados i ÿ B las mismas tasas de
recompensa que Y . Entonces, ECRTE es
de la recompensa el valor esperado
acumulada por Y
hasta la salida de B.
La medida ECRTE se puede calcular utilizando iÿB riÿi,
tiempo empleado
donde
por Xÿien
esi.elSea
ECRTE
el vector
= valor
fila esperado
ÿB = (ÿi)iÿB.
del
Entonces, ÿB es la solución del sistema lineal ÿBAB,B =
ÿÿB, donde AB,B y ÿB son las restricciones de,
respectivamente, A y ÿ a B.
La condición de que todos los estados en B sean transitorios
se requiere para ECRTE < ÿ.
Como ejemplo de la medida ECRTE, suponga que un
CTMC Y modela un sistema tolerante a fallas que puede
estar activo o inactivo y que B es el subconjunto de estados
de Y en los que el sistema está activo.
Entonces, asignando una tasa de recompensa 1 a todos los
estados en B de la CTMC X haciendo un seguimiento del
comportamiento de Y hasta la salida de B, ECRTE sería el
tiempo medio de falla (MTTF) del sistema.
34.2.3 Recompensa acumulativa esperada
durante la estadía en un subconjunto de estados
componente de captura de X tiene al menos un estado en
cambiará indefinidamente entre los subconjuntos B y ÿ B.
Sea tn el tiempo en en el que X hace su enésima entrada
en B (por convención, si X(0) ÿ B, t1 = 0) y sea Tn el
momento en que X hace su enésima salida de B. La
medida se define como:
Tennesse
ECRDS = límite rX(t) dt
nÿÿ y2 Tennesse
En palabras, ECRDS es el valor esperado de la recompensa
acumulada por X durante su n-ésima estancia en el
subconjunto B cuando n ÿ ÿ.
Discutimos a continuación cómo se puede calcular la
medida ECRDS. Sea En la variable aleatoria “estado a
través del cual X hace su enésima entrada en B” y sea qi
= limnÿÿ P[En = i], i ÿ B. Sean C1, C2,...,Cm los
componentes de captura de X y sea Bk = B ÿ Ck , 1 ÿ k ÿ
m. Sea pCk =
Machine Translated by Google

Modelado markoviano de confiabilidad/rendimiento de sistemas tolerantes a fallas 619

límiteÿÿ P[X(t) ÿ Ck], 1 ÿ k ÿ metro. Vamos qk yo , i ÿ Bk, 34.2.4 Transitorio esperado

1 ÿ k ÿ m sea el límite para n ÿ ÿ de la
Tasa de recompensa
probabilidad de que En = i condicionada a En ÿ

negro ; formalmente, qk = limnÿÿ P[En = i | A ÿ Bk ]. La medida se define como:

i
Vamos pk = límiteÿÿ P[X(t) = i | X(t) ÿ Ck], i ÿ Ck,
i
1 ÿ k ÿ metro. Las probabilidades pk yo , yo ÿ Ck, 1 ÿ k ÿ metro ETRR(t) = E[rX(t )]

se puede calcular como se describe al tratar con

y se puede calcular en términos del transitorio
la medida ESSRR. Las probabilidades qk yo , i ÿ Bk,
régimen de X como:
1 ÿ k ÿ m se puede calcular a partir de pk yo , yo ÿ ck, 1 ÿ
k ÿ m usando: ETRR(t) = rasgar)
iÿ

= jÿCk j ÿj,i
paquete

qki Como ejemplo de la medida ETRR(t), suponga

lÿBk jÿCk
Considere los CTMC recompensados Xk, 1 ÿ k ÿ m
haciendo un seguimiento del comportamiento de X en Bk
desde la entrada en Bk con probabilidad de estado de entrada
distribución qk yo , yo ÿ Bk . El premiado CTMC Xk
tiene espacio de estado Bk ÿ {a}, las mismas tasas de transición
entre los estados en Bk como X, las tasas de transición de
i ÿ Bk a a, = ÿi,CkÿBk
ÿki,a , las mismas tasas de recompensa
pk jÿj,l que X modela un sistema tolerante a fallos que puede
ser hacia arriba o hacia abajo, y que una tasa de recompensa 1 es
asignado a los estados arriba y una tasa de recompensa 0 es
asignado a los estados inactivos. Entonces, ETRR(t) sería
Sea la disponibilidad del sistema en el tiempo t.
34.2.5 Recompensa promedio esperada
Velocidad

en Bk como X, y distribución de probabilidad inicial

P[Xk (0) = i] = qk yo , i ÿ Bk, P[Xk(0) = a] = 0. Sea La medida se define como:
k
yo
_ Sea el valor esperado del tiempo empleado por t
3 0 rX(ÿ ) dÿ
Xk en i ÿ Bk . Tenga en cuenta que todos los estados en Bk de Xk son ERROR(t) = E
t
transitorio. Entonces, ECRDS se puede calcular a partir de
1 ÿ k ÿ m, y ÿ pCk , k
yo , i ÿ Bk, 1 ÿ k ÿ m, usando:
y se puede calcular en términos del transitorio
metro
régimen de X como:
ECRDS = k
paquete yo _
t
k=1 iÿBk iÿ ri 3 pi(ÿ ) dÿ
0
TEAR(t) =
t
Los vectores fila ÿ k = (ÿ k
i )iÿBk son las soluciones de
los sistemas lineales ÿ kABk ,Bk Como ejemplo de la medida EARR(t), suponga
= ÿqk, donde ABk ,Bk
es la restricción de la matriz de tasa de transición que X modela un sistema tolerante a fallos que puede
de Xk a Bk y qk es el vector fila (qk ser hacia arriba o hacia abajo, y que una tasa de recompensa 1
i )iÿBk .
Las probabilidades pCk y pk i ÿ Ck puede ser se asigna a los estados up y una tasa de recompensa 0
yo ,

computado como se describe al tratar con el se asigna a los estados inactivos. Entonces, TEAR(t)
Medida ESSRR. sería la disponibilidad de intervalo esperada, es decir , la

Como ejemplo de la medida ECRDS, suponga valor esperado de la fracción de tiempo que el

que X modela un sistema reparable tolerante a fallas el sistema está activo en el intervalo de tiempo [0, t].

que puede ser hacia arriba o hacia abajo, que B es el

34.2.6 Recompensa acumulativa
subconjunto de estados activos, y que una tasa de recompensa 1 es
asignado a los estados en B. Entonces, el ECRDS Distribución hasta la salida de un subconjunto de estados
medida sería la limitación de la duración esperada
de un intervalo de subida del sistema tolerante a fallos, es decir En esa medida, se supone que = B ÿ {a},
el límite para n ÿ ÿ de la duración esperada de donde a es un estado absorbente y que cada
el n-ésimo intervalo ascendente. componente de captura de X diferente de {a} tiene
Machine Translated by Google
620 Prácticas y aplicaciones emergentes
algún estado i con ri > 0. La medida se define
como:
T Como ejemplo de la(s) medida(s) CRDTE, suponga
rX(t ) dt ÿ s
CRDTE(s) = P 2 0
donde T = min{t : X(t) = a} o T = ÿ si X(t) ÿ B para t ÿ [0, ÿ)
y s ÿ 0. Desde un punto de vista de modelado, el CTMC X
recompensado puede ser visto como un CTMC que realiza
un seguimiento del comportamiento hasta la salida de B
de un CTMC Y recompensado más grande que en realidad
modela el sistema en estudio. Las relaciones entre X e Y
son las discutidas al tratar la medida ECRTE.
El cálculo de la(s) medida(s) CRDTE puede reducirse
al análisis transitorio de un CTMC Xÿ modificado [13]. El
diagrama de transición de estados y la distribución de
probabilidad inicial del CTMC Xÿ se obtienen a partir de los
de X reemplazando los estados i ÿ B con ri = 0 por cambios
instantáneos con probabilidades de salto a los estados j ,
ÿi,j = ÿi,j /ÿi, y dividiendo las tasas de transición ÿi,j de los
estados i con ri > 0 por ri. El proceso de reemplazar
estados con una tasa de recompensa nula por cambios
instantáneos es análogo a eliminar las marcas que
desaparecen en las redes de Petri estocásticas
generalizadas y se pueden usar varios algoritmos [14]. Una
vez que se ha obtenido Xÿ , CRDTE(s) puede calcularse
usando CRDTE(s) = P[Xÿ(s) = a].
Sea Bÿ ÿ {a} el espacio de estado de Xÿ y suponga que
Bÿ = ÿ. Cuando no todos los estados en Bÿ son transitorios,
los CRDTE(s) se pueden calcular realizando el análisis
transitorio de un CTMC Xÿ de tamaño menor que Xÿ. El
CTMC Xÿ se puede construir a partir de Xÿ. Sean C1,
C2,...,Cm las componentes de Xÿ distintas de {a} que no
tienen camino en el dígrafo de las componentes de Xÿ a
{a}. Sea C = Bm Ck. Una vez que Xÿ entra en C,
permanecerá allí para
k=1 siempre
a. y nunca entrará en el estado
Luego, el CTMC Xÿ con diagrama de transición de estados
y distribución de probabilidad inicial obtenida de los de Xÿ
eliminando los estados en C, agregando un estado
absorbente b con probabilidad inicial igual a P[Xÿ(0) ÿ C],
y agregando tasas de transición de los estados i ÿ Bÿ = Bÿ
ÿ C a b con tasas ÿÿ = ÿÿ i,bi,C, donde ÿÿ es la suma lasde
tasas de
transición de (s)
i i,C= aa]los
= estados en C en X ÿ, satisface P[Xÿ
P[Xÿ(s) = a], y podemos calcular CRDTE(s) como P[Xÿ (s)
= a].
que un CTMC Y modela un sistema tolerante a fallas que
puede estar activo o inactivo, y que B es el subconjunto de
estados de Y en los que el sistema está activo. Entonces,
asignando a los estados en B de X una tasa de recompensa
1, CRDTE(t) sería la falta de confiabilidad en el tiempo t
(probabilidad de que el sistema haya fallado en algún
tiempo ÿ ÿ [0, t]).
34.2.7 Distribución acumulativa de
recompensas durante la estadía en un
subconjunto de estados
Sea B un subconjunto propio de y suponga que cada
componente de captura de X tiene al menos un estado en
B y un estado fuera de B. Bajo esas circunstancias, X
cambiará indefinidamente entre los subconjuntos B y ÿ B.
Sea tn el tiempo en en el que X hace su enésima entrada
en B (por convención, t1 = 0 si X(0) ÿ B) y sea Tn el
momento en que X hace su enésima salida de B. La
medida se define como:
Tennesse
CRDDS(s) = límite
nÿÿ
rX(t ) dt ÿ s
PAG 2 Tennesse
con s ÿ 0. En palabras, CRDDS(s) es la distribución de la
recompensa acumulada por X durante su n-ésima estancia
en el subconjunto B como n ÿ ÿ.
Discutimos a continuación cómo se pueden calcular los
CRDDS. Sean C1, C2,...,Cm las componentes de captura
de X y sean Bk = B ÿ Ck, 1 ÿ k ÿ 1 ÿ k ÿ m y qk 1 ÿ k ÿ m
m. Sea Esas
de la medida ECRDS. pCk , cantidades
i ÿ Bk ,yodefinido
, como como
discusión
se pueden
se en la al
describe
calcular
tratar con la medida ECRDS. Considere los CTMC
recompensados Xk, 1 ÿ k ÿ m, haciendo un seguimiento
del comportamiento de X en Bk desde la entrada en Bk
con una distribución de probabilidad de estado de entrada
qk i ÿ Bk . El CTMC Xk recompensado tiene un espacio de
estado Bk ÿ {a}, las mismas tasas de transición entre
estados en Bk que X, ÿk tasas yode
, itransición
ÿ Bk a a, i,a
de ÿi,CkÿBk
los estados
,
las mismas tasas de recompensa en Bk como X, y
distribución de probabilidad inicial P[Xk (0) = i] = qk
=
yo ,
Machine Translated by Google

Modelado markoviano de confiabilidad/rendimiento de sistemas tolerantes a fallas 621

i ÿ Bk, P[Xk (0) = a] = 0. Sea CRDTEk(s) la distribución asumiendo X(t) = jÿ i,ÿ{i}

la ri,j
probabilidad
ÿi,j t + O( t2).
de que
EstoXes
permanezca
ri t + porque,
en i
acumulada de recompensas de Xk hasta la salida de Bk. durante todo el intervalo es 1 ÿ O( t), la probabilidad de que X
Entonces tenemos: haga una transición de i a j en el intervalo es ÿi,j t + O( t2), y
metro
la probabilidad de que X haga más de una transición en el
CRDDS(s) = pCkCRDTEk(s) intervalo es O( t2).
k=1

donde CRDTEk(s) se puede calcular como se describe cuando

Esto permite el cálculo de versiones extendidas, incluidas las recompensas
se trata de la medida CRDTE(s), teniendo en cuenta que,
por impulso, de las medidas ESSRR, ECRTE, ECRDS, ETRR(t) y
siendo Ck un componente de captura de X y Bk un subconjunto
EARR(t) como aquellas medidas con tasas de recompensa r = ri + i
propio de Ck, todos los estados de Bk serán transitorios en
Xk.
jÿ ÿ{i} ri,j ÿi,j . Las medidas ampliadas
definirse formalmente como:
34.2.8 Distribución acumulativa
ESRR =
de recompensas
límite
tÿÿ límite tÿ0
La medida se define como: E[recompensa acumulada en [t,t + t]]
t t
rX(ÿ ) dÿ ÿ s ECRTE = E[recompensa acumulada en [0, T]]
CRD(t, s) = P2 0
ECRDS
En palabras, CRD(t, s) es la probabilidad de que la recompensa = límite E[recompensa acumulada en (tn, Tn]]
nÿÿ
obtenida por X hasta el momento t sea ÿ s.
La medida se puede ver como una instancia particular de la ETRR(t) =
límite tÿ0
medida genérica de rendimiento donde ri tiene el significado
de "tasa a la que se acumula el rendimiento", cada valor E[recompensa acumulada en [t,t + t]]
posible para el rendimiento acumulado en el intervalo [0, t] es
t
un nivel de logro, y el subconjunto medible incluye todos los
recompensa acumulada en [0, t]
niveles de logro ÿ s. ERROR(t) = E
t

La distribución de disponibilidad de intervalo IAVD(t, p), donde T , tn y Tn se definen como para las medidas no

definida como la probabilidad de que la disponibilidad de extendidas.

intervalo (es decir, la fracción de tiempo que el sistema está
activo en el intervalo [0, t]) sea ÿ p puede verse como una
instancia particular de la medida CRD(t, s) cuando se asigna
una tasa de recompensa 1 a los estados activos y una tasa de
recompensa 0 a los estados inactivos. Con esa estructura de
tasa de recompensa, CRD(t, s) es la probabilidad de que el
tiempo activo durante el intervalo [0, t] sea ÿ s y, entonces,
IAVD(t, p) = CRD(t, pt).
Hemos supuesto ri ÿ 0, i ÿ o i ÿ B, ya que esto asegura la
estabilidad numérica de muchos métodos de solución. Sin
embargo, esa restricción se puede eludir para las ocho
medidas de recompensa definidas en las Secciones 34.2.1–
34.2.8, excepto las medidas CRDTE(s) y CRDDS(s),
cambiando, en caso de que algún ri, i ÿ o i ÿ B sea < 0, todas
las tasas de recompensa por una cantidad positiva d para que
la nueva recompensa = ri + d sea ÿ 0 para todo i ÿ e i ÿ B.
tarifas ri

Las medidas del CTMC recompensado original están

34.2.9 Estructuras de recompensas extendidas relacionadas con las medidas del CTMC recompensado con
tasas de recompensa desplazadas, indicadas por “ ”, por
Con tasas de recompensari ÿ 0 y recompensas de impulso ri,j
ESSRR = ESSRR ÿ d,
ÿ 0 asociadas con las transiciones i ÿ j , el valor esperado de
la
ECRT = ECTER ÿ dECTTE,
recompensa acumulada durante el intervalo de tiempo [t,t +
t], suponiendo que X(t) = i, ECRDS = ECDRS ÿ d ECTDS,
Machine Translated by Google
622 Prácticas y aplicaciones emergentes
ETRR(t) = ETRR(t) ÿ d,
TEAR(t) = TEAR(t) ÿ d,
CRD(t, s) = CRD (t, s + dt),
donde ECTTE es la medida ECRTE con recompensa = 1, i ÿ
tasas r i B y ECTDS es la ECRDS = 1, i ÿ B.
mido con tasas de recompensa r i
34.3 Especificación del modelo
La especificación directa de CTMC, incluso de tamaño
mediano, es engorrosa y propensa a errores. Para superar
ese problema, la mayoría de las herramientas admiten
especificaciones más concisas de alto nivel a partir de las
cuales se pueden derivar automáticamente las CTMC.
Algunas herramientas como SAVE [15] ofrecen un lenguaje
de modelado diseñado específicamente para describir sistemas tolerantes a fallas. que el sistema continúe funcionando sin
paridad permite
Esto proporciona la máxima facilidad de uso y hace explícito
el conocimiento de alto nivel sobre el modelo que puede
explotarse durante la solución del modelo, pero inevitablemente
introduce restricciones que dificultan o incluso imposibilitan
acomodar modelos distintos de los previstos por los
diseñadores del lenguaje. Los formalismos de los que se
pueden derivar CTMC arbitrarios incluyen redes de Petri
estocásticas, redes de actividad estocásticas, álgebras de
procesos estocásticos y especificaciones basadas en reglas
de producción. DSPNexpress [16], GreatSPN [17], SPNP
[18], SURF-2 [19] y TimeNET [20] son ejemplos de
herramientas en las que la especificación del modelo se
realiza mediante redes de Petri estocásticas. UltraSAN [21]
admite la especificación de modelos a través de redes de
actividad estocástica. PEPA Workbench [22] y TIPPtool [23]
utilizan álgebras de procesos estocásticos como formalismo
de especificación del modelo. METFAC-2.1 y TANGRAM [24]
ofrecen lenguajes de modelado basados en reglas de
producción. La especificación básica del modelo para el
malismo es, en algunos casos, demasiado simple para
adaptarse fácilmente a características complejas del modelo
y, en aras de la facilidad de uso, algunas herramientas
permiten extensiones tales como habilitar funciones en redes
de Petri estocásticas generalizadas. Otra característica
importante que incorporan la mayoría de las herramientas es
la especificación del modelo paramétrico. Los parámetros
pueden afectar la "estructura" del diagrama de transición de
estado, los valores de
las tasas de transición, la distribución de probabilidad inicial
y la estructura de recompensa de la CTMC, y a menudo
permiten una especificación compacta de modelos para una
"clase" más o menos amplia de sistemas tolerantes a fallas.
Para ilustrar las técnicas de especificación de modelos,
revisaremos el lenguaje de modelado basado en reglas de
producción que ofrecerá METFAC-2.1 utilizando un modelo
paramétrico de un subsistema RAID de nivel 5. El subsistema
incluye ocho discos, dos controladores de disco redundantes
y dos fuentes de alimentación redundantes. La información
almacenada en los discos está organizada en grupos de ocho
bloques, de los cuales siete contienen bits de datos y un
bloque contiene bits de paridad. Cada bloque de un grupo se
almacena en un disco diferente. Dado que se accede a los
bloques de paridad con más frecuencia que a los bloques de
datos, los bloques de paridad se distribuyen uniformemente
entre los discos para lograr el equilibrio de carga y la máxima
eficiencia para el subsistema RAID. El uso de bloques de
pérdida de datos en caso de falla del disco. La falla de un
segundo disco provocaría la caída del sistema e implicaría la
pérdida de datos. Después de reparar un disco defectuoso
con el subsistema activo, un proceso de reconstrucción
genera los bloques que deben almacenarse en el disco
reparado para tener grupos de bloques consistentes. La falla
de un disco diferente del disco en reconstrucción hace que el
subsistema se caiga. Los discos fallan con una tasa ÿD
cuando el RAID no tiene ningún disco en reconstrucción y
con una tasa ÿDR cuando el RAID tiene un disco en
reconstrucción.
Dado que la carga de los discos es mayor cuando el RAID
tiene un disco en reconstrucción, se debe esperar que ÿDR
> ÿD. Los controladores fallan con una tasa ÿC2 cuando
ambos controladores no fallan y con una tasa ÿC1 cuando
solo un controlador no falla.
Por lo general, las solicitudes de acceso se distribuirían entre
los controladores cuando ambos no fallan, lo que implica que
tendrían una actividad menor que un solo controlador sin
fallas y, entonces, se debe esperar que ÿC1 > ÿC2. Las
fuentes de alimentación funcionan en redundancia de espera
en frío, y el repuesto en frío tiene una tasa de fallas nula. La
fuente de alimentación activa falla con tasa ÿP. Las fallas del
controlador y de la fuente de alimentación están cubiertas
con probabilidades CC y CP, respectivamente. Un controlador
descubierto o una falla en la fuente de alimentación hace que
el subsistema se apague.
Machine Translated by Google
Modelado markoviano de confiabilidad/rendimiento de sistemas tolerantes a fallas
Se supone que el proceso de reconstrucción tiene una duración
con una distribución exponencial con parámetro µDR. Los
componentes no fallan cuando el subsistema está inactivo.
Cuando el subsistema está activo, los componentes
defectuosos son reparados por un número ilimitado de
reparadores con tasa µU. Un sistema inactivo se lleva a un
estado completamente operativo sin fallas en ningún
componente y ningún disco en reconstrucción con tasa µD.
En METFAC-2.1, se proporciona una especificación de
modelo en un archivo llamado nombre.espec, donde nombre
es una cadena que identifica el modelo. Esa especificación del
modelo puede invocar funciones C específicas del modelo externo. con un parámetro int que se llama para calcular las tasas de
Además, es posible que se deban proporcionar otras funciones
C con nombres y prototipos predefinidos para especificar las
características de la medida que se calculará (el subconjunto
B en las medidas ECRTE, ECRDS, CRDTE(s) y CRDDS(s)),
u otras usos (por ejemplo, para verificar afirmaciones sobre las
descripciones de estado de los estados generados, o para
proporcionar información requerida por algunos métodos de
solución modelo). Todas estas funciones deben incluirse en
un archivo opcional name.c. La Figura 34.2 muestra el
contenido de un archivo de especificación de modelo a partir
del cual se puede generar una CTMC recompensada adecuada
para evaluar la indisponibilidad en estado estable del
subsistema RAID descrito anteriormente utilizando la medida
genérica ESSRR. El contenido de ese archivo debe seguir un
lenguaje con sintaxis similar a C.
El lenguaje distingue entre mayúsculas y minúsculas y, como
en C, los comentarios están encerrados entre /* y */. La
especificación del modelo comienza con una declaración
opcional de los parámetros del modelo. Los parámetros del
modelo pueden ser de dos tipos: doble e int. En el ejemplo,
todos los parámetros son de tipo doble.
La siguiente construcción sintáctica es una declaración
obligatoria de las variables de estado del modelo.
Todas las variables de estado tienen tipo int. El conjunto de
variables de estado debe proporcionar en conjunto una
descripción suficientemente detallada del estado del modelo
para permitir una especificación inequívoca de la distribución
de probabilidad inicial, las tasas de transición y las tasas de
recompensa de la CTMC. En el ejemplo se han utilizado cinco
variables de estado. La variable de estado DF toma el valor sí
(definido implícitamente como 1) cuando el subsistema RAID
está activo y un disco falla y el valor no (definido implícitamente
como 1)
623
como 0) de lo contrario. Las otras variables de estado, DR,
CF, PF y DOWN, identifican estados en los que,
respectivamente, el subsistema está activo y un disco está en
reconstrucción, el subsistema está activo y un controlador
falla, el subsistema está activo y una fuente de alimentación
falla y el subsistema está inactivo.
El uso de funciones C externas mejora la flexibilidad del
lenguaje de modelado. Esas funciones pueden ser de tipo
double o int, solo pueden incluir parámetros double o int, y
tienen que ser declaradas por una construcción externa
opcional que sigue a la declaración de las variables de estado
del modelo. El ejemplo utiliza una función doble rew_essrr()
recompensa que se asociarán con los estados de la CTMC.
El núcleo de la especificación del modelo es un conjunto
de reglas de producción que sigue a la sección declarativa y
comienza con la palabra clave production_rules. Esas reglas
de producción determinan cómo puede cambiar el estado de
la CTMC y con qué tarifas. Hay dos tipos de reglas de
producción: simples y con respuestas. Una regla de producción
simple describe una acción simple que puede cambiar el
estado de la CTMC e incluye una condición opcional, la acción
de palabra clave, un nombre opcional, una especificación de
tasa y una descripción de cambio de estado. La condición
determina si la acción está activa o no en un estado particular
(la acción está activa si la condición se evalúa a un valor
diferente de 0 y está inactiva de lo contrario). Si la descripción
de la acción no incluye ninguna condición, la acción está activa
en cualquier estado. Por ejemplo, la acción descrita por la
primera regla de producción del ejemplo modela la falla de un
disco cuando ningún disco falla o está en reconstrucción. Esa
acción está activa cuando todos DOWN, DF y DR tienen valor
0 (no), tienen nombre DFAIL_NFDR, ocurren con tasa 8ÿD y
conducen a un estado que difiere del actual solo en que la
variable de estado DF tiene valor 1 ( sí). Las reglas de
producción con respuestas describen acciones con respuestas
e incluyen una condición de acción opcional, la palabra clave
acción, un nombre de acción opcional, una especificación de
tasa y un conjunto de respuestas, cada una con una condición
de respuesta opcional, la palabra clave respuesta, un nombre
opcional ,
Machine Translated by Google

624 Prácticas y aplicaciones emergentes

Figura 34.2. Especificación del modelo adecuada para el cálculo de la indisponibilidad en estado estable del subsistema RAID utilizando el ESSRR
medida
Machine Translated by Google

Modelado markoviano de confiabilidad/rendimiento de sistemas tolerantes a fallas 625

una especificación de probabilidad opcional y un estado Tabla 34.1. Descripciones de los estados de la CTMC obtenidas de
Cambiar Descripción. Cada respuesta describe una manera la especificación del modelo de la figura 34.2

en el que el estado puede cambiar. Suponiendo que ambos Estado DF RD FC FP ABAJO

la acción y la respuesta están activas, tal estado
FOP no no no no no
cambio ocurre a una tasa dada por el producto de
C no no si no si no no no
la tasa de acción y la probabilidad de respuesta (con
D no no
un valor predeterminado 1 si la respuesta no incluye no no no
PAGS
sí No
una especificación de probabilidad). La quinta producción R no si no si no si no no
regla del ejemplo ilustra la sintaxis de un CD no no no si si no no
PC
regla de producción con respuestas. Modela el
falla de un controlador cuando no falla ningún controlador. RC no si si no si no no si no no
DP
Esa acción está activa solo cuando el subsistema no
relaciones públicas
si no si no
está activo y ningún controlador falla y ocurre en CDP si no si si no
velocidad 2ÿC2. Con probabilidad CC, la falla del RCP no si si si no
ABAJO no no no no sí
El controlador está cubierto. Esto es modelado por la primera
respuesta. Con probabilidad 1 ÿ CC, la falla de
la CTMC, y cualquier distribución de probabilidad inicial
el controlador no está cubierto y toma el sistema
es bastante bueno.
abajo. Esto está modelado por la segunda respuesta.
La Tabla 34.1 describe los estados de la CTMC
Después de las reglas de producción, la especificación del
generado a partir de la especificación del modelo del
modelo incluye una construcción start_state para
subsistema RAID. La figura 34.3 da el estado
definir un estado de "inicio". Se genera el CTMC
diagrama de transición del CTMC generado.
aplicando todas las reglas de producción al “inicio”
En METFAC-2.1, las especificaciones del modelo deben
estado y todos los estados generados. La especificación del
ser "construido" antes de que se puedan generar CTMC y
modelo termina con una construcción de tasa_recompensa para
resuelto La construcción de una especificación de modelo implica,
especificar la estructura de la tasa de recompensa y una opción
primero, preprocesando el archivo de especificación del modelo para
construcción initial_probability para especificar
obtener un archivo fuente C específico del modelo y, después
la distribución de probabilidad inicial de la CTMC.
eso, compilar ese archivo fuente C y, si está presente,
Las expresiones dadas en esos constructos se evalúan para
el nombre del archivo.c, y vincular el objeto obtenido
obtener las tasas de recompensa y las probabilidades iniciales
asociadas con los estados del CTMC. archivos con archivos de objetos independientes del modelo para
obtener un nombre de archivo ejecutable específico del modelo.exe.
Si la construcción initial_probability está ausente, una
Todos estos pasos se realizan automáticamente al invocar un
distribución de probabilidad inicial por defecto con
comando apropiado. Los CTMC son
probabilidad 1 para el estado de "inicio" y probabilidad
generado y resuelto ejecutando el ejecutable
Se utiliza 0 para los estados restantes. En el ejemplo, la tasa
nombre.exe. Este enfoque hace que la generación de modelos
de recompensa asociada con un estado es la
sea extremadamente eficiente (por ejemplo, el CTMC agregado
valor devuelto por la llamada rew_essrr(DOWN),
que es 1.0 para los estados con variable de estado ABAJO para el cálculo de la indisponibilidad en estado estable del
sistema con ocho RAID).
igual a 1 (sí) y 0.0 para los estados con estado
subsistemas descritos en la Sección 34.6, que tiene
variable DOWN igual a 0 (no). Esto hace que el
Se generaron 125 970 estados y 2 670 564 transiciones en
medida genérica ESSRR igual al estado estacionario
una estación de trabajo UltraSPARC1 de 167 MHz y 128 MB
indisponibilidad del subsistema RAID. La especificación del
en 69 segundos).
modelo no incluye ninguna construcción de probabilidad inicial
y el valor predeterminado
distribución de probabilidad inicial se asigna a la 34.4 Solución modelo
CTMC. Esto es apropiado ya que el generado
CTMC es irreducible, la medida ESSRR no La Sección 34.2 ha reducido el cómputo de todos
dependen de la distribución de probabilidad inicial de medidas definidas allí pero la medida CRD(t, s)
Machine Translated by Google

626 Prácticas y aplicaciones emergentes

EN

PC C

EN

2 C2C
C PAGS

PETIMETRE C 8 D
8 CDP
D
D C1 P +
C ABAJO
PÁGINAS

PAGS

2 (1C2_ ) + (1 C
_C) PAGS
C PAGS
DR
ABAJO RC C

EN

R
EN

C PETIMETRE
DR
8 CD
D
CD C
PÁGINAS

RCP
C
PÁGINAS
PC 7 +RD
+ (1
C1_ ) PAGS
C PAGS

+ ABAJO
C1 PAGS
(1 _ c ) PAGS

ABAJO
EN

DP D
EN

D R EN

2 C2C
C relaciones públicas

CD 2 C2C
C
C CDP
PÁGINAS
DP 7 +D2 (1 _ )C2
+ CC PAGS

ABAJO
+ (1 _ ) CC
7 +D2 (1 _ )C2 PAGS
C PAGS

ABAJO
DR
relaciones públicas PAGS

EN

PAGS PETIMETRE
EN

2 C R
C2C
PC DR
8 DP
D
DP 2 C2C
C
CC RCP
2 (1C2_ ) + PAGS

ABAJO 7 +DR
2 (1 _ ) +C2 CC PAGS

ABAJO

DR EN

R PETIMETRE CDP CD
DR EN
D DP
2 C2C
C EN

RC RCP

PÁGINAS
C 7+ D
+ C1 PAGS

relaciones públicas ABAJO

2 (1 _ ) +C2(1 _ ) CC
7 +DR PAGS
C PAGS

ABAJO DR
RCP PC
EN EN

CD D RC

EN EN

RC relaciones públicas

PÁGINAS
C DR
CDP CDP

7 +D+ (1 _C1
) C 7++RD C1 PAGS
PAGS PAGS

ABAJO ABAJO

D
ABAJO PETIMETRE

Figura 34.3. Diagrama de transición de estado de la CTMC obtenido a partir de la especificación del modelo de la Figura 34.2
Machine Translated by Google
Modelado markoviano de confiabilidad/rendimiento de sistemas tolerantes a fallas
a la solución de los siguientes tres problemas
numéricos: (1) cálculo de la solución normalizada (p1T
= 1) del sistema lineal
pCA,C = 0 (34.1)
donde AC,C es la restricción de la matriz de tasa de
transición de un CTMC a un componente de captura
C, p es un vector fila y 0 y 1 son vectores fila con
todos los componentes iguales a, respectivamente, 0
y 1; (2) cálculo de la solución del sistema lineal
ÿAS,S = ÿÿ (34.2)
donde AS,S es la restricción de la matriz de tasa de
transición de un CTMC a un subconjunto de estados
transitorios S, ÿ es un vector fila y ÿ es un vector fila
con componentes ÿi ÿ 0, i ÿ S; y (3) cálculo de las
probabilidades transitorias pi(t) = P[X(t) = i], o sus
integrales, de un CTMC X. En esta sección
comenzamos analizando los métodos numéricos
disponibles para resolver estos problemas.
Comenzaremos considerando los primeros dos
problemas numéricos, luego analizaremos los métodos
numéricos disponibles para resolver el tercer problema Las implementaciones escasas de métodos directos pueden
y, finalmente, revisaremos brevemente los métodos ser significativamente menos costosas, pero son complejas
numéricos para calcular la medida CRD(t, s), que son mucho más
y muy
La matriz AS,S puede ser reducible. Esto ocurre ese caso, la memoria disponible puede agotarse rápidamente.
cuando el CTMC XS que tiene un diagrama de
transición de estado igual al diagrama de transición
de estado del CTMC subyacente restringido a S tiene
varios componentes. Sean C1, C2,...,Cm esas
componentes, y sea Ak,l, 1 ÿ k, l ÿ m el bloque de
AS,S = (ai,j )i,jÿS incluyendo los elementos i ÿ Ck, j ÿ
tengo, yo , Cl. Una clasificación topológica de los
componentes en el dígrafo de componentes de XS
pone AS,S en forma triangular de bloque superior:
A1,1 A1,2 A1,3 ··· A1,m
ÿ 0 A2,2 A2,3 A2 ,m ÿ
ÿ ÿ
0 0A3,3 A3 ,m
ÿ ÿ
COMO,S = ÿ
ÿ .. .. .. ..
ÿ
ÿ
ÿ
. . . ... . ÿ
ÿ 000 ··· Am,m ÿ PC,Cx = 0T
donde se ha cambiado el nombre de los componentes
para que la ordenación topológica de los componentes
sea C1, C2,...,Cm. Esa forma triangular del bloque
superior se puede usar para reducir la solución del
627
sistema lineal (34.2) a la solución de sistemas lineales
semejantes con matrices irreducibles Ak,k, 1 ÿ k ÿ m.
Llamando ÿk y ÿk las restricciones de los vectores ÿ y
ÿ al subconjunto de estados Ck, tenemos:
ÿ1A1,1 = ÿÿ1
ÿ2A2,2 = ÿÿ2 ÿ ÿ1A1,2
ÿ3A3,3 = ÿÿ3 ÿ ÿ1A1,3 ÿ ÿ2A2,3
..
.
ÿmAm,m = ÿÿm ÿ ÿ1A1,m ÿ ÿ2A2,m ÿ
ÿ3A3,m ÿ···ÿ ÿmÿ1Amÿ1,m
Esta reducción es beneficiosa desde el punto de vista
computacional y debe realizarse siempre que sea
posible. Por lo tanto, en lo que sigue, supondremos
que AS,S es irreducible.
Los sistemas lineales 34.1 y 34.2 pueden resolverse
mediante métodos directos, por ejemplo , eliminación
gaussiana, o métodos iterativos. Las implementaciones
no escasas de métodos directos son costosas cuando
la matriz es grande, ya que requieren O(n3) tiempo y
O(n2) memoria, siendo n la dimensión de la matriz.
costosos.
a menudo dan como resultado un relleno excesivo. En
Los métodos iterativos, por otro lado, se pueden
implementar sin modificar la matriz y tienen requisitos
mínimos de memoria, lo que permite el análisis de
CTMC con espacios de estado muy grandes. Por esa
razón, los métodos iterativos se han preferido
tradicionalmente a los métodos directos.
Sin embargo, la falta de convergencia o la baja tasa de
convergencia son problemas potenciales de los métodos iterativos.
Stewart [25] es una excelente fuente reciente de
métodos directos e iterativos aplicados a la solución
de CTMC.
Para evitar divisiones, que suelen ser costosas,
conviene transformar los sistemas lineales 34.1 y 34.2
en:
(34.3)
PS,Sy = ÿÿT (34.4)
donde x e y son vectores columna,
PC,C = CA,C Tdiag(CA,C)ÿ1, =y PS, S
Machine Translated by Google
628 Prácticas y aplicaciones emergentes
AS,S Tdiag(AS,S)ÿ1, BT que denota la transpuesta de la
matriz B y diag(B) que denota la matriz con elementos
diagonales iguales a los elementos diagonales de B y
elementos fuera de la diagonal nulos, y aplique los métodos
numéricos a esos sistemas lineales.
La solución normalizada del Sistema 34.1 se puede obtener
de una solución no nula del Sistema 34.3 usando: pT =
diag(AC,C) ÿ1x/)diag(AC,C) ÿ1x)1 La solución del Sistema
34.2 se puede obtener de la solución del Sistema 34.4
usando:
Tt _ = diag(AS,S) ÿ1y
Los métodos iterativos básicos incluyen Jacobi, Gauss-
Seidel y la relajación excesiva sucesiva (SOR).
Para describir esos métodos, considere un sistema lineal Bz
= b, donde z y b son vectores columna.
Sea B dividido como D ÿ L ÿ U, donde D es diagonal, L es
estrictamente triangular inferior y U es estrictamente
triangular superior. Los métodos iterativos básicos se pueden
describir como:
z(k+1) = Hz(k) + Mÿ1b
donde las iteraciones z(k) deben converger a la solución del
sistema lineal. El método de Jacobi se define por H = Dÿ1(L
+ U) y M = D.
El método de Gauss-Seidel está definido por H = (D ÿ L)ÿ1U
y M = D ÿ L. El método SOR está definido por H = (D ÿ ÿL)
ÿ1[(1 ÿ ÿ)D + ÿU] y M = D/ÿ ÿ L, donde ÿ es el parámetro de
relajación. Tenga en cuenta que para ÿ = 1, SOR se reduce
a Gauss-Seidel. Se conocen los siguientes resultados [25–
29] sobre la convergencia de estos métodos cuando se
aplican a los sistemas lineales 34.3 y 34.4.
1. Para el sistema lineal 34.3: (a) Gauss-Seidel converge
si AC,C tiene un elemento subdiagonal no nulo en
todas las filas excepto en la primera, y (b) SOR solo
puede converger para 0 <ÿ< 2 y converge para 0 <ÿ< 1.
2. Para el sistema lineal 34.4: (a) Jacobi y Gauss-Seidel
convergen, (b) Gauss-Seidel converge asintóticamente
más rápido que Jacobi, (c) SOR solo puede converger
para 0 <ÿ< 2 y converge para 0 < ÿ ÿ 1, y (d) para 0 <
ÿ ÿ 1 SOR no puede converger asintóticamente más
rápido a medida que ÿ disminuye.
La condición que garantiza la convergencia de Gauss-Seidel
para el sistema lineal 34.3 se puede lograr fácilmente
clasificando los estados en C según lo visitado por un
recorrido en anchura, siguiendo los arcos entrantes, de la
restricción del diagrama de transición de estado del CTMC
subyacente a C, comenzando en cualquier estado. Por lo
general, Gauss-Seidel convergerá más rápido que Jacobi
para el sistema lineal 34.3. Además, SOR con una selección
adecuada del valor del parámetro de relajación puede
converger significativamente más rápido que Gauss-Seidel.
A excepción de las matrices que tienen estructuras
especiales, no existe ninguna teoría que sustente una
selección óptima de ÿ. Según los resultados disponibles, la
búsqueda del óptimo ÿ debe restringirse al intervalo (0, 2)
para el sistema lineal 34.3 y al intervalo [1, 2) para el sistema
lineal 34.4. Un método SOR optimizado aparentemente
eficiente y robusto es descrito por Suñé et al. [28]. Esa
referencia también compara el rendimiento de métodos
iterativos básicos, algunos métodos iterativos de bloques y
un método de proyección. Los métodos iterativos básicos
pueden exhibir una tasa de convergencia extremadamente
pobre para el sistema lineal 34.4 para modelos CTMC de
falla/reparación. Sin embargo, recientemente se ha
desarrollado una técnica de aceleración que funciona muy
bien para esos modelos [30].
El cálculo de las probabilidades transitorias de una
CTMC se puede realizar utilizando solucionadores de ODE
(ecuación diferencial ordinaria) o aleatorización (también
llamada uniformización). Se pueden encontrar buenas
revisiones de esos métodos con nuevos resultados en
Malhotra et al. [31], Malhotra [32] y Reibman y Trivedi [33].
Haciendo el vector fila p(t) = (pi(t))iÿ , p(t) satisface la
ecuación diferencial ordinaria:
dp
= p(t)A dt
donde A es la matriz de tasas de transición de la CTMC.
Esto permite el uso de solucionadores ODE para calcular
las probabilidades transitorias pi(t), i ÿ .
Sin embargo, el rendimiento de los solucionadores de ODE
se ve gravemente afectado por la rigidez del modelo.
Una medida práctica de rigidez es maxiÿ ÿit [33].
Los solucionadores de ODE estándar (no rígidos) requieren
una gran cantidad de pasos cuando el modelo es rígido
(tiene un valor maxiÿ ÿit grande ). Solucionadores rígidos de ODE
Machine Translated by Google

Modelado markoviano de confiabilidad/rendimiento de sistemas tolerantes a fallas 629

funcionar mucho mejor en esos casos. Cada paso de un El punto de truncamiento N se puede elegir utilizando
solucionador de EDO rígido requiere la solución de un criterio de error adecuado, por ejemplo ,
sistemas lineales con matrices que tengan el mismo imponiendo )p(t)T ÿ pa(t)T)1 ÿ ÿ, donde ÿ es una
patrón no nulo que A. Por lo general, esos sistemas cantidad suficientemente pequeña. Dado que )p(t)T ÿ
ÿ
lineales se resuelven mediante un método iterativo, por k=N+1
pa(t)T )1 ÿ eÿ t( t)k/k!, N se puede elegir como:
ejemplo , Gauss-Seidel. Para grandes maxiÿ ÿit, el
ÿ
número resultante de multiplicaciones matriz-vector es t
(t)k ÿ
N = mínimo metro ÿ 0 : eÿ e
típicamente del orden de varios miles, e incluso los k!
k=m+1
solucionadores rígidos de ODE son costosos para CTMC grandes y rígidos.
El método de aleatorización es atractivo porque es Cálculo estable y eficiente de las probabilidades de
numéricamente estable y el error de cálculo está bien hijo de Pois eÿ t( t)k/k! evitando sobre
controlado y se puede especificar de antemano. El flujos y subdesbordamientos intermedios es un tema
método de aleatorización se basa en el siguiente delicado, y se han propuesto varias alternativas [35–
resultado [34, teorema 4.19]. Considere cualquier ÿ 38]. Para t grande, es decir , para CTMC rígidos, el
maxiÿ ÿi y defina la cadena de Markov de tiempo punto de truncamiento N requerido es ÿ ty, entonces, el
discreto homogéneo aleatorizado (DTMC) método de aleatorización será costoso si el modelo
Xˆ = {Xˆ k; k = 0, 1, 2,... } con el mismo espacio de es grande. Aunque hemos revisado el método de
aleatorización para el cálculo de p(t), el método se
estado y distribución de probabilidad inicial que X y
probabilidades de transición P[Xˆ k+1 =P[Xˆ
j | Xˆk+1 j ,k =|
yo = yo puede adaptar fácilmente para calcular con un error
bien controlado las medidas ETRR(t) y EARR(t) (ver,
Sea t ÿ 0} un proceso Xˆ
de i]Poisson
= Pi,j = con
ÿÿi,jÿi//tasa
., Sea
k =de
i]Q=llegada
=Pi,i =1
{Q(t);
por ejemplo, Carrasco [39] ).
independiente de Xˆ Entonces, X = {X(t); t ÿ 0} es
probabilísticamente idéntico a {Xˆ Q(t ); t ÿ 0}. A esto lo.
Se han propuesto varias variantes del método de
llamamos el “resultado de aleatorización”. El rendimiento
aleatorización (estándar) para mejorar su eficiencia.
del método de aleatorización
aumenta se degrada
y, por este a medida
motivo, suele que
tomarse
Miller [40] ha usado la aleatorización selectiva para
igual a maxiÿ ÿi.
resolver modelos de confiabilidad con una representación
detallada de las actividades de manejo de errores.
La idea detrás de la aleatorización selectiva [41] es
Sea q(k) = (P[Xˆ k = i])iÿ el vector fila de probabilidad
aleatorizar el modelo solo en un subconjunto del
de Xˆ en el paso k. Entonces, usando el resultado de la espacio de estado. Reibman y Trivedi [33] han
aleatorización, condicionando el número de llegadas propuesto un enfoque basado en el concepto de varios
de Poisson en el tiempo t, Q(t), y usando P[Q(t) = k] = pasos. La idea es calcular PM explícitamente, donde M
eÿ t( t)k/k!, podemos expresar p(t) como: es la longitud del multipaso, y usar la recurrencia q(k +
ÿ
(t)k M) = q(k)PM para hacer avanzar Xˆ más rápido para
t
p(t) = q(k) eÿ (34.5) los pasos que tienen contribuciones insignificantes a la
k!
k=0
solución transitoria de X. Dado que, para t grande, el
Los vectores fila q(k) se pueden obtener usando: número de q(k)s con contribuciones significativas es
del orden de ÿ t, el concepto de pasos múltiples permite
q(k + 1) = q(k)P
una reducción significativa en el número requerido de
donde P = (Pi,j )i,jÿ es la matriz de probabilidad de multiplicaciones vector-matriz. Sin embargo, al calcular
transición de Xˆ
. método
En unade implementación
aleatorización,práctica
se puededel PM, puede ocurrir un relleno significativo si P es escaso.
obtener un valor aproximado para p(t) truncando la La uniformización adaptativa [42] es un método reciente
serie infinita de la Ecuación 34.5: en el que la tasa de aleatorización se adapta
dependiendo de los estados en los que puede estar el
DTMC aleatorizado en un paso dado.
norte

t
(t)k Los experimentos numéricos han demostrado que la
pa(t) = q(k) eÿ
k! uniformización adaptativa puede ser más rápida que la estándar.
k=0
Machine Translated by Google
630 Prácticas y aplicaciones emergentes
aleatorización para tiempos de misión cortos a
medianos. Además, se puede utilizar para resolver
modelos con espacios de estado infinitos y tasas de
salida no acotadas uniformemente. Recientemente, se
ha propuesto la combinación de uniformización
adaptativa y estándar para obtener un método más
rápido para la mayoría de los modelos [38]. Otra
propuesta para acelerar el método de aleatorización es
la detección en estado estacionario [31]. Recientemente,
se ha desarrollado un método basado en la detección
de estado estacionario que proporciona límites de error
[43]. La detección de estado estacionario es útil para
los modelos que alcanzan su estado estacionario antes
del tiempo máximo en el que se debe calcular la medida.
La aleatorización regenerativa [39, 44] es otro método
similar a la aleatorización propuesto recientemente. El
método requiere la selección de un estado “regenerativo”
y cubre modelos CTMC recompensados con espacio
de estado = S ÿ {f1, f2,...,fA}, |S| ÿ 2, A ÿ 0, donde fi
son estados absorbentes y todos los estados en S son
transitorios o S tiene un solo componente de captura y
el estado regenerativo elegido pertenece a ese
componente, con una distribución de probabilidad inicial
con P[X(0) ÿ S] > 0, y tal que todos los estados sean
legibles. El estado regenerativo tiene que pertenecer a
S. Una variante de ese método, llamada aleatorización
regenerativa límite [45], permite el cálculo de límites
para medidas similares a la confiabilidad. Para una
clase de modelos, incluidos los modelos típicos de falla/
reparación, existe una selección natural para el estado
regenerativo y, con esa selección, el método de
aleatorización regenerativo delimitador es rápido y
parece obtener límites estrechos.
Los métodos numéricos disponibles [46–54] para el
cálculo de la medida CRD(t, s) son costosos y, cuando
el modelo es rígido, su aplicabilidad se limita a CTMC
de tamaño pequeño.
La mayoría de esos métodos [46, 48, 50, 51, 53, 54] se
basan en el resultado de la aleatorización. Algunos de
ellos [50, 51, 54] permiten tanto tasas de recompensa
como recompensas por impulso. Se ha demostrado que
los métodos descritos en Nabli y Sericola [48] y Qureshi
y Sanders [51] son numéricamente estables. Como se
discutió en la Sección 34.2, la medida IAVD(t, p) de
distribución de disponibilidad de intervalo puede verse
como un caso particular de la medida CRD(t, s) y se
han desarrollado métodos numéricos especiales.
para calcularlo [55-58]. Muchos de esos métodos se
basan en el resultado de la aleatorización y son
particularizaciones de métodos para el cálculo de
CRD(t, s).
34.5 El problema de la grandeza
El modelado de sistemas tolerantes a fallas de
complejidad incluso moderada generalmente requiere
grandes CTMC. Además, el tamaño de la CTMC tiende
a crecer rápidamente con la complejidad del sistema.
Ese fenómeno se conoce como el problema de la
explosión del espacio de estados o de la amplitud. Los
enfoques para tratar el problema de la amplitud incluyen
la agregación de estados, los métodos de delimitación
y las técnicas de solución "sobre la marcha". En la
agregación de estados, las simetrías del sistema se
explotan para generar modelos CTMC de tamaño
reducido a partir de un formalismo de especificación de
modelo adecuado que hace explícitas esas simetrías
(ver, por ejemplo, Chiola et al. [59] y Sanders y Meyer
[60]). Los métodos de delimitación calculan los límites
de la medida de interés utilizando un conocimiento
detallado del modelo CTMC en un subconjunto de
estados. Para que los límites sean estrictos, el
subconjunto debe incluir los estados "más probables"
del modelo. Las técnicas de solución sobre la marcha
(ver Deavours y Sanders [61] y las referencias citadas
allí) reducen los requisitos de memoria al evitar el
almacenamiento de la matriz de tasa de transición de la
CTMC. Los tres enfoques se pueden combinar. A continuación, re
X indicará la CTMC "exacta".
Las medidas ETRR(t), EARR(t) y CRD(t, s) son
fáciles de acotar. Sea G un subconjunto propio del
espacio de estado del CTMC recompensado X. Sea Xlb
el CTMC recompensado con diagrama de transición de
estado obtenido a partir del de X eliminando los estados
en ÿ G, agregando un estado absorbente a y dirigiendo
a a la transición tasas de X de los estados i ÿ G a ÿ G;
que tiene una distribución de probabilidad inicial en G
igual a la de X y una probabilidad inicial en a igual a
P[X(0) ÿ ÿ G]; y tener una estructura de tasa de
recompensa con las mismas tasas de recompensa
que X para los estados en G y una tasa de recompensa
rlb ÿ miniÿ ri para el estado a. Deje que Xub sea el
CTMC recompensado que difiere de Xlb solo en eso
Machine Translated by Google
Modelado markoviano de confiabilidad/rendimiento de sistemas tolerantes a fallas
se asigna una tasa de recompensa rub ÿ maxiÿ ri al estado
absorbente a. Entonces, las medidas ETRR(t) y EARR(t)
para Xlb limitan por debajo las medidas correspondientes
para X y las medidas ETRR(t) y EARR(t) para Xub limitan
por arriba las medidas correspondientes para X. Además,
el CRD(t , s) para los límites inferiores de Xub , la medida
CRD(t, s) para X, y la medida CRD(t, s) para los límites
superiores de Xlb , la medida CRD(t, s) para X.
Limitar la(s) medida(s) CRDTE es un poco más
complejo. Sea G un subconjunto propio de B (X tiene un
espacio de estado B ÿ {a}, donde a es un estado
absorbente). Sea Xlb el CTMC con el diagrama de
transición de estado obtenido a partir del de X eliminando
los estados en B ÿ G, agregando un estado absorbente b y
dirigiendo a b las tasas de transición de X desde los
estados i ÿ G a B ÿ G; teniendo una distribución de
probabilidad inicial en G ÿ {a} idéntica a la de X y una
probabilidad inicial en b igual a P[X(0) ÿ B ÿ G]; y tener una
estructura de tasa de recompensa sobre G ÿ {b} con las
mismas tasas de recompensa que X para los estados en
G y cualquier tasa de recompensa > 0 para el estado b.
Entonces, la(s) medida(s) de CRDTE para Xlb con el
subconjunto “B” igual a G ÿ {b} limita por debajo la(s)
medida(s) de CRDTE para X. Sea Xub la CTMC con el
diagrama de transición de estado obtenido a partir del de
X eliminando el estados en B ÿ G y dirigiendo las tasas de
transición de los estadosi ÿ G a a; teniendo una distribución
de probabilidad inicial en G idéntica a la de X y una
probabilidad inicial en a igual a P[X(0) ÿ (B ÿ G) ÿ {a}]; y
tener una estructura de tasa de recompensa sobre G con
las mismas tasas de recompensa que X. Luego, la(s)
CRDTE(s) miden para Xub con el subconjunto “B” igual a
G límites superiores que la(s) CRDTE(s) miden para X.
Los métodos de delimitación para la medida ESSRR
son más sofisticados y se han desarrollado recientemente
[62–68]. Revisaremos el método con duplicación de estado
descrito por Muntz et al. [66], con generalizaciones que
utilizan resultados obtenidos por Carrasco [62] y Mahévas
y Rubino [65].
El método se puede implementar fácilmente utilizando una
herramienta de modelado Markoviano de propósito general
como METFAC-2.1. El método asume X irreducible
y requiere para encontrar una partición Ck de con k=0
BM las siguientes propiedades:
P1. |C0| = 1.
631
P2. Para cada i ÿ Ck, 1 ÿ k ÿ M, existe un camino dentro de
Ck que va de i a la “izquierda” (subconjunto B
kÿ1
cl).
l=0
El método obtiene los límites utilizando un conocimiento
detallado de X en un subconjunto G = BK k=0 ck , K <
M de , y calcula los límites usando dos CTMC Xlb,
Xub que tienen el mismo diagrama de transición de estado
y difieren solo en su estructura de tasa de recompensa. El
diagrama de transición de estado de esos CTMC incluye
tasas de transición "limitantes" f k,l, 1 ÿ k<M, 1 ÿ l ÿ M ÿ yk+
gÿ 1 ÿ k ÿ M. k,
+límite superior k,l Si todos los
La tasa de transición f tiene unestados i ÿ Ck tienen un non
entonces cualquiera puede ser
maxiÿCk ÿi,Ck+l .
,
tasa de transición nula a la izquierda l=0 cl
l=0 cl
ÿi,Bkÿ1 límite inferior > 0 para miniÿCk ÿi,Bkÿ1
tomado como gÿk . De lo contrario, puede tomarse como
gÿ k
cualquier cota inferior > 0 para miniÿCk qi/hi, donde qi es
la probabilidad de que, comenzando en el estado i, X salga
de Ck por la izquierda, e hi es el tiempo medio de retención
de X en Ck, suponiendo entrada en Ck a través del estado
i. Obtener tal cota inferior puede ser difícil, pero teóricamente
es posible debido a la propiedad P2 de la partición. Los
CTMC Xlb y Xub tienen espacio de estado G ÿ {c1,
c2,...,cM}, tasas de transición entre estados en G como X,
tasas de transición de estados i ÿ G a estados ck igual a
ÿi,Ck , tasa de transición de cada estado ck a cada
cl con
estado
l>ka
tasa de transición de cada estado
+
igual a f k,lÿk, ck,
y una tasa de transición
k > 2 a ckÿ1 igual a gÿ de c1 a k ,
o, siendo o el estado en C0, igual a gÿ 1.
La figura 34.4 ilustra el diagrama de transición de estado
de Xlb y Xub. Los estados en G de CTMC Xlb y Xub tienen
asociadas las mismas tasas de recompensa que X; los
estados ck tienen asociada una tasa de recompensa igual
a rlb, donde rlb ÿ miniÿ ri, en Xlb, y una tasa de recompensa
igual a rub, donde rub ÿ maxiÿ ri, en Xub. Luego, la medida
ESSRR para los límites inferior y superior de Xlb y Xub ,
respectivamente, la medida ESSRR para X. Una situación
en la que el método de delimitación puede ser eficiente, es
decir , puede dar límites estrechos con valores moderados
de K, es cuando se realiza una transición a la derecha (es
decir , de los estados i ÿ Ck, 0 ÿ k<M, a BM Cl) son
“lentos” (tienenl=k+1
tasas pequeñas)
y aumente el índice k moderadamente, y existe un camino
"rápido" (compuesto por transiciones "rápidas")
Machine Translated by Google

632 Prácticas y aplicaciones emergentes

+
f
1,2
GRAMO

+ + F+
f f
1,1 2,1 _ M 1,1

c1 c2 c3 cm _ 1 cm

_ _ _
gramo gramo gramo

O _ 2 3 METRO

gramo

Figura 34.4. Diagrama de transición de estado de los CTMC que limitan la medida ESSRR

dentro de Ck a la izquierda de cualquier estado i ÿ Ck , 1 ÿ k ÿ a, tenemos:

M, que debe permitir la derivación de la transición
ECRTE
tasas gÿ significativamente más grande que la transición ESRR =
k+ ECTTE + 1/
tasas f como
k,l, es deseable. Este es típicamente el
caso para modelos de falla/reparación cuando Ck incluye ECTTE
los estados con exactamente k componentes fallados, ya que, pB =
ECTTE + 1/
para estos modelos, las tasas de falla suelen ser mucho
de donde podemos obtener:
menores que las tasas de reparación.
Los límites para la medida ECRTE pueden ser ESRR
ECRTE = (1
obtenido utilizando la delimitación descrita anteriormente
ÿ p B)
método para la medida ESSRR. Primero, nota
que ECRTE = ÿSECRTE , donde ECRTE es el Entonces, podemos usar lo descrito anteriormente
recompensa acumulada esperada hasta la salida del subconjunto método de delimitación para la medida ESSRR para
B del CTMC recompensado X que difiere de X obtener inferior ([ESSRR ]lb, [p B]lb) y superior
solo en que su distribución de probabilidad inicial ([ESSRR ]ub, [p B]ub) límites para ESSRR y
restringida a B se ha escalado de modo que la p B, y, a partir de ellos, obtener los siguientes límites
las probabilidades iniciales de los estados en B se suman para la medida ECRTE:
a 1, es decir , P[X (0) = i] = ÿi/ÿS = ÿi, i ÿ B, y
[ESRR ]lb
la probabilidad inicial del estado absorbente a [ECRTE]lb = ÿS
es 0. Sea X el CTMC recompensado irreducible (1 ÿ [pB ]lb)

cuyo diagrama de transición de estado se obtiene de [ESRR ]ub

la de X agregando una tasa de transición del estado [ECRTE]ub = ÿS
(1 ÿ [ pB]ub)
a a cada estado i ÿ B con valor ÿi , donde es suficientemente
grande, por ejemplo = maxiÿB ÿi,
y tiene una estructura de tasa de recompensa con la misma
34.6 Un estudio de caso
tasas de recompensa como X para los estados en B y una recompensa

tasa 0 para el estado a. Sea ECTTE lo esperado
tiempo acumulado hasta la salida de B de, X sea ESSRR
, y
la tasa de recompensa de estado estacionario esperada de X
sea p B la probabilidad de estado estacionario de B en X
Usando la teoría del proceso regenerativo [69], tomando como
puntos de regeneración los tiempos en los que X entra
Esta sección ilustra algunas de las técnicas
revisado en las secciones anteriores con un caso
estudiar. El estudio de caso implica el cálculo
. de la indisponibilidad en estado estacionario y la falta de confiabilidad
de un sistema de almacenamiento tolerante a fallas compuesto por
de N subsistemas RAID como los descritos
Machine Translated by Google
Modelado markoviano de confiabilidad/rendimiento de sistemas tolerantes a fallas
en la Sección 34.3. Desde el punto de vista de la fiabilidad,
el sistema es una configuración en serie del RAID
subsistemas, es decir , el sistema está activo si y sólo si
todos los subsistemas RAID están activos. Componentes fallidos
de subsistemas RAID son reparados por un número ilimitado
de reparadores con tasa µU. Sin embargo,
un solo reparador está disponible para traer a tarifa
µD reduce los subsistemas RAID a un estado totalmente operativo
estado. En caso de que varios subsistemas RAID estén inactivos,
el subsistema RAID que se abre es seleccionado al azar entre
ellos por el reparador.
Nos ocuparemos primero del cálculo
de la indisponibilidad en estado estacionario. El modelo
especificación dada en la Sección 34.3 puede ser trivialmente
extendido al sistema bajo estudio usando
un conjunto independiente de variables de estado para describir
el estado de cada subsistema RAID. Esto tiene,
sin embargo, dos inconvenientes principales. El primero es
que cada valor de N requiere un modelo diferente
especificación. La segunda es que la resultante
CTMC tendría 13N estados, un número que
crece muy rápido con N y hace imposible la
análisis de sistemas incluso con valores moderados de
N. El primer problema se puede resolver y el segundo
aliviado, explotando el hecho de que todos los RAID
subsistemas tienen exactamente el mismo comportamiento y
usando una especificación de modelo que produce un agregado
CTMC con menos estados. Tal agregado
CTMC se puede obtener usando variables de estado
NFOP, NC, ND, NP, NR, NCD, NCP, NCR, NDP,
NPR, NCDP, NCPR y NDOWN, haciendo un seguimiento de
el número de subsistemas RAID en cada uno de los
estados enumerados en la Tabla 34.1. Las reglas de producción de
tal especificación de modelo se puede obtener fácilmente
del diagrama de transición de estado de la figura 34.3,
como se ilustra en la Figura 34.5, que da la
reglas de producción correspondientes a las transiciones
del estado FOP del diagrama de transición de estado
de la figura 34.3. La regla de producción correspondiente
a la transición del estado DOWN al estado FOP
tendría una tasa µD, debido a que hay un
único reparador para derribar los subsistemas RAID
al estado de pleno funcionamiento. Al definir N como
parámetro del modelo y definiendo como estado inicial el
estado en el que NFOP tiene valor N y todos los demás
las variables de estado tienen valor 0, una especificación del modelo
independiente de N se puede obtener. Tabla 34.2
633
Tabla 34.2. Tamaño de los modelos CTMC agregados para el
cálculo de la indisponibilidad en estado estacionario del almacenamiento
sistema en función de N
norte estados Transiciones
13 53
1 91 689
2 455 4823
3 1820 24 115
4 6188 96 460
5 18 564 327 964
6 50 388 983 892
78 125 970 2 670 564
da el tamaño de los CTMC agregados obtenidos
de tal especificación de modelo. La talla de
esos CTMC es sustancialmente más pequeño que el
tamaño de los CTMC no agregados (por ejemplo,
para N = 8, la CTMC no agregada tendría
8.157 × 108 estados mientras que el CTMC agregado tiene
125 970 estados), pero todavía crece rápido con N, haciendo
imposible el análisis de sistemas con grandes
valores de N debido a los requisitos excesivos de almacenamiento
(el requisito de almacenamiento para N = 8 fue de 91 MB).
Los métodos de acotación se pueden usar para reducir aún
más los requisitos de almacenamiento y permitir el análisis de
sistemas con valores más grandes de N. Dada la
estructura del CTMC agregado, es posible
k=0 ck con las propiedades
para encontrar una partición BM
requerido por el método de delimitación para el ESSRR
medida descrita en la Sección 34.5, y para la cual
el método de delimitación puede ser eficiente. Sea NC(s),
ND(s), NP(s), NR(s) y NDOWN(s) , respectivamente, el número
de subsistemas RAID activos con
un controlador fallido en el estado s, el número de hasta
Subsistemas RAID con un disco fallido en estado
s, el número de subsistemas RAID activos con uno
fuente de alimentación fallida en el estado s, el número de hasta
Subsistemas RAID con un disco en reconstrucción en el estado
s y el número de subsistemas RAID inactivos en el estado s.
Sea N(s) = NC(s) + ND(s) +
NP(s) + NR(s) + NDOWN(s). Entonces, una partición apropiada
es Ck = {s: N(s) = k}. Con esta partición, C0 solo incluye el
estado en el que todos
Los subsistemas RAID están en pleno funcionamiento
estado, y, asumiendo tasas de falla mucho menores
que µDR, µU y µD, transiciones a la derecha
Machine Translated by Google
634 Prácticas y aplicaciones emergentes
Figura 34.5. Algunas reglas de producción de una especificación de modelo a partir de la cual se pueden obtener los modelos CTMC agregados para el cálculo de la
indisponibilidad en estado estacionario del sistema de almacenamiento
son lentos y aumentan moderadamente el índice k, y existe
un camino rápido dentro de Ck hacia la izquierda desde
cualquier estado s ÿ Ck, k > 0. Para comprobarlo, la Tabla
34.3 clasifica los diferentes tipos de eventos del modelo en
“lentos” y “rápido”, dependiendo de los valores de las tasas
de transición asociadas con ellos, y enumera los valores por
los cuales los tipos de eventos pueden modificar N(s) (para
cada tipo de evento, la tabla da los valores posibles para
N(s, s ) = N(s ) ÿ N(s), donde s y s son estados tales que el
tipo de evento provoca una transición de s a s ). Los posibles
valores de N(s, s ) se obtienen analizando cómo el tipo de
evento puede modificar NC(s), ND(s), NP(s), NR(s) y
NDOWN(s), teniendo en cuenta que un subsistema RAID
activo no puede tener un disco fallado y un disco en
reconstrucción.
Así, por ejemplo, el tipo de evento 2 disminuirá ND(s) en 1,
incrementará NDOWN(s) en 1 y puede disminuir NC(s) y
NP(s) en 1, ya que el subsistema que incluye el disco fallido
podría tener tenía un controlador y una fuente de alimentación
fallaron.
De esa tabla, está claro que: (1) las transiciones hacia la
derecha son lentas y aumentan el índice k en 1, (2) cada
estado s ÿ Ck, k > 0 con NC(s) + NP(s) + NR (s) + NDOWN(s)
> 0 tiene una transición rápida hacia la izquierda debido al
final de una reconstrucción de disco en un subsistema activo,
la reparación de un controlador en un subsistema activo, la
reparación de una fuente de alimentación en un subsistema
activo , o una reparación global de un subsistema RAID
caído, y (3) cada estado s ÿ Ck , k > 0 con NC(s) + NP(s) +
NR(s) + NDOWN(s) = 0, lo que implica ND (s) > 0, tiene una
transición rápida a un estado s ÿ Ck con NC(s ) + NP(s ) +
NR(s ) +
NDOWN(s ) > 0 (porque NR(s ) = 1) debido a una reparación
de disco en un subsistema up, implicando con (2) la
existencia de un camino rápido dentro de Ck a la izquierda
desde cualquier estado s ÿ Ck, k > 0.
El valor máximo de N(s) es M = 3N.
Las transiciones a la derecha (consulte la Tabla 34.3) solo
pueden deberse a fallas de disco en subsistemas ascendentes
sin disco fallado o en reconstrucción, fallas de controlador
en subsistemas ascendentes sin controlador fallado y fallas
de fuente de alimentación en subsistemas ascendentes sin
fuente de alimentación fallada , y pasar de un subconjunto
Ck a un subconjunto Ck+1. Entonces, como tasa de transición
acotante a la derecha podemos tomar:
+
f k, 1 = N(8ÿD + 2ÿC2 + ÿP) = f
+
f = 0 l = 1 k, l
Obtención de tasas de transición adecuadas gÿ k
(es decir, significativamente mayor que f ) es más difícil
porque algunos estados en los subconjuntos Ck, 1 ÿ k ÿ 3N
no tienen una transición rápida hacia la izquierda. Sea C0
k = {s: N(s) = k ÿ NC(s) + NP(s) + NR(s) +
NDOWN(s) = 0}. Entonces, los estados en C0
k no tienen una transicion rapida a la izquierda. Estados s ÿ C1
= Ck ÿ C0 k k>, 0 tienen NC(s) + NP(s) + NR(s) +
k
NDOWN(s) > 0 y, por tanto, tienen una transición rápida
hacia la izquierda.
Para N<k ÿ 3N, s ÿ Ck , ND(s) ÿ N implica NC(s) + NP(s)
+ NR(s) + NDOWN(s) > 0 y C0 = ÿ. Entonces, para N<k ÿ
3N, todos losizquierda
hacia la estados en Ck tienentomar
y podemos una transición rápida > 0
un límite inferior
k
para la tasa de transición hacia la izquierda desde cualquier
estado s ÿ Ck como gÿ k . Dado que los estados s con
Machine Translated by Google

Modelado markoviano de confiabilidad/rendimiento de sistemas tolerantes a fallas 635

Tabla 34.3. Tipos de eventos y propiedades en el modelo CTMC para el cálculo del estado estacionario
indisponibilidad del sistema de almacenamiento

Tipo de evento Descripción Lento rápido N(s, s)

1 Falla de disco en subsistema superior sin lento 1

disco fallado o en reconstrucción
2 Falla de disco en el subsistema superior lento ÿ2, ÿ1, 0
con un disco fallido
3 Fallo de un disco que no está en reconstrucción en lento ÿ2, ÿ1, 0
el subsistema superior con un disco en reconstrucción
4 Fallo del disco en reconstrucción en el lento 0
subsistema superior con un disco en reconstrucción
5 Fallo del controlador cubierto en el subsistema lento 1
superior sin falla del controlador
6 Fallo del controlador descubierto en el subsistema lento ÿ1, 0, 1
superior sin fallo del controlador
7 Fallo del controlador en el subsistema superior lento ÿ2, ÿ1, 0
con un controlador fallido
8 Fallo de la fuente de alimentación cubierto en el subsistema lento 1
superior sin falla de la fuente de alimentación
9 Falla descubierta de la fuente de alimentación en el subsistema lento ÿ1, 0, 1
superior sin falla de la fuente de alimentación
10 Fallo de la fuente de alimentación en el subsistema lento ÿ2, ÿ1, 0
superior con una fuente de alimentación fallida
11 Reparación de disco en subsistema up rápido 0
12 Fin de la reconstrucción del disco en el subsistema up rápido ÿ1
13 Reparación de controlador en subsistema up rápido ÿ1
14 Reparación de fuente de alimentación en subsistema up rápido ÿ1
15 Reparación global de subsistema de bajada rápido ÿ1

NC(s) > 0 tienen una tasa de transición a la izquierda ÿµU
(porque en esos estados al menos un controlador de
se está reparando un subsistema up), afirma s con
NP(s) > 0 tienen una tasa de transición a la izquierda ÿµU
(porque en esos estados al menos una fuente de alimentación
de un subsistema up está siendo reparado), estados s
con NR(s) > 0 tienen una tasa de transición a la izquierda
ÿµDR (porque en esos estados al menos un disco
de un subsistema superior está en reconstrucción), y
los estados s con NDOWN(s) > 0 tienen una tasa de transición
a la izquierda ÿ µD (porque en esos estados un down
subsistema RAID se está poniendo en marcha), podemos tomar
gÿ = min{µDR, µU , µD} = g1.
= (C0
k Para 1 ÿ k ÿ N, C0 k k incluye solo el
estado en el que hay k subsistemas RAID
con solo un disco fallado y los N ÿ k restantes
Los subsistemas RAID están en pleno funcionamiento
estado), y no todos los estados en Ck tienen una transición rápida
A la izquierda. Sin embargo, la existencia de un camino rápido
dentro de Ck a la izquierda nos permite obtener un “grande”
límite inferior >0 para minsÿCk qs/hs, donde qs es
la probabilidad de que, a partir de s, X salga de Ck
por la izquierda, y hs es el tiempo medio de espera
de X en Ck, suponiendo entrada en Ck a través de s, y
ese límite inferior se puede usar como gÿ k _ Para derivar eso
límite inferior usaremos los siguientes dos resultados,
que puede probarse fácilmente.
Lema 1. Sea Z un CTMC transitorio con
espacio de estado B ÿ {aL, aR } , donde aL y aR son
estados absorbentes y todos los estados en B son transitorios,
y P[Z(0) ÿ B] = 1. Sea PL = limtÿÿ P[Z(t) =
aL] y PR = limtÿÿ P[Z(t) = aR] (PL y PR
son, respectivamente, las probabilidades de que Z sea
absorbido en aL y aR ). Denotar por gi la transición
razón de i ÿ B a aL y denotamos por fi la
Machine Translated by Google

636 Prácticas y aplicaciones emergentes

tasa de transición de i ÿ B a aR. Suponga gi > 0, i ÿ B, sea Lemas 1 y 2 que:

gÿ ÿ miniÿB gi, gÿ > 0, y sea f ÿ maxiÿB fi. Entonces, PL+ ÿ g1
q1s ÿ g1 + f + NÿDR
s ÿ C1k , 1 ÿ k ÿ norte
gÿ/(gÿ + f +).
(34.8)
Lema 2. Sea Z un CTMC transitorio con espacio de estado 1
B ÿ {a}, donde a es un estado absorbente y todos los h1s ÿ s ÿ C1k , 1 ÿ k ÿ norte (34.9)
g1
estados en B son transitorios, y P[Z(0) ÿ B] = 1.
Considere ahora el estado sk. Está claro (vea la figura
Sea gi, i ÿ B la tasa de transición de i a a, suponga gi > 0, i
ÿ B, y sea gÿ ÿ miniÿB gi, 3 P[Z(t) = i] dt el gÿ > 0. Sea h = 34.6) que qsk tiene un límite inferior por q0 q1 . Luego,
ÿ
usando las Relaciones 34.6 y
sk minutos ÿC1 s
iÿB tiempo
0 Z. medio
Entonces,
de absorción
h ÿ 1/gÿ. de k
34.8 tenemos:

Sea s ÿ C0k , 1 ÿ k ÿ N. Como se indicó anteriormente, kµU g1

qsk ÿ
s es el estado en el que hay k subsistemas RAID con solo kµU + F 1 g1 + f + NÿDR
un disco fallado y los N ÿ k subsistemas RAID restantes ÿ k ÿ norte
están en su estado completamente operativo. Llamemos a
ese estado sk . La reparación de un disco en sk conducirá Además, teniendo en cuenta que 1 ÿ q1 1 ÿs ,k sÿ ÿN,C1
elk límite
,

a un estado s con N(s ) = N(sk) (ver Tabla 34.3) y NR(s ) > superior de la probabilidad de que, comenzando por C0 en
0 y, entonces, s ÿ C1 k_
un límite superior (ver Figura
k s, 34.6)
X salga
por:
de C1 k , hsk tiene
Esto implica que sk tiene una tasa de transición ÿ kµU a C1
k _ Además, la tasa de transición de sk a
h0 h1s + máx s (1 ÿ q1 s
+ máx s ÿC1 h1s
+ máx s ÿC1
la derecha es ÿf . Sea q0 laskprobabilidad de que, sk
ÿC1 k ) / h0
sk
k k
comenzando en sk, X salga de C0 yde
sea
seak ,
k a
eltravés
tiempode C1 h0
medio
+ máx s (1 ÿ q1 h1s
+ máx s ÿC1
permanencia de
2 tenemos: X en sk. Entonces, usando los Lemas 1y s ) / h0
sk
sk ÿC1 k k

+ máx s (1 ÿ q1
kµU s )[· · · ]00
ÿC1
q0sk ÿ kµU + f 1 ÿ k ÿ norte (34.6) k

y usando las Relaciones 34.7 y 34.9 y 1 ÿ q1 (f + NÿDR)/

s
ÿ
1
h0 ÿ 1 ÿ k ÿ norte (34.7) k, 1ÿkÿ
(g1 + f + NÿDR), s ÿ C1 n, que se sigue de la Relación
sk
kµU 34.8, tenemos:
Sea ahora s ÿ C1 k1, ÿ k ÿ N. Tal estado tiene una tasa de
1 1 f + NÿDR g1
transición a la izquierda ÿg1 y una tasa de transición a la hsk ÿ + kµU g1
+
+ f + NÿDR f + NÿDR
derecha ÿf. Además, s tiene una tasa de transición ÿNÿDR
1 1 g1 + f + NÿDR
a C0 k . Esto se puede demostrar
únicos observando
tipos de quepueden
eventos que los × + + [· · · ]
llevar de s a un estado s ÿ Ck son los tipos de eventos 2, kµU g1 f + NÿDR g1 + f +
ÿ
3, 4, 6, 7, 9, 10 y 11 enumerados en la tabla 34.3. Los 1 1 NÿDR
norte

= +
tipos de eventos 2, 3, 6, 7, 9 y 10 conducen a estados s kµU g1
n=0
con NDOWN(s ) > 0, que no pueden pertenecer a C0 k . El
1 1 1
tipo de evento 11 conduce a un que
estado
no spuede
con NR(s) > 0,
pertenecer = +
a C0 k . Entonces, el único tipo de evento que puede kµU g1 1- f +NÿDR
g1+f +NÿDR
conducir a untipo
de ese estado s ÿ C0está
de evento es ellimitada
tipo depor
evento 4 y la tasa
NÿDR. 1 1 g1 + f + NÿDR
= +
k
kµU g1 kµU g1

La figura 34.6 aclara la situación. Entonces, denotando por = + g1 kµUg1

q1 lasprobabilidad
la izquierda,dey que,
por h1
a partir
el tiempo
de s,medio
X salga
de de C1 por g1 + f +
permanencia de X en C1 k , a partir de s, se sigue de
k s × NÿDR
1 ÿ k ÿ norte
g1
Machine Translated by Google

Modelado markoviano de confiabilidad/rendimiento de sistemas tolerantes a fallas 637

lo que da: Combinando las relaciones 34.11 y 34.12:

2
qsk kµU g1
ÿ qs g1 g1+f +NÿDR
g1 + f + NÿDR mín ÿ
hsk kµU + f 1 (kµU+g1)(f +NÿDR) kµUg1
sÿC1hs
k
kµUg1 g1 / 1 + 0
× 1 ÿ k ÿ norte (34.10)
kµU + g1 kµUg1
=
Sea ÿ C1 k , 1 ÿ k ÿ N. Es claro que qs está acotado kµUg1 + (kµU + g1)(f + NÿDR)
g1
inferiormente porsq1 y, entonces, usando la Relación 34.8: × g1 1 ÿ k ÿ norte
g1 g1 + f + NÿDR
qs ÿ g1 + f + NÿDR s ÿ C1k , 1 ÿ k ÿ norte (34.13)
(34.11)
Finalmente, combinando las Relaciones 34.10 y 34.13
Por otro lado, 1 ÿ q1 es el límite superior
s de la probabilidad
obtenemos, para 1 ÿ k ÿ N:
de que, comenzando en s, X salga de C1 a través de C0k
qs
k , y, entonces, tenemos (ver Figura 34.6): min
sÿCkhs
h1
hs ÿ h1 +s(1 ÿ q1 s ÿC1+ max sk s s + máx s (1 ÿ q1 s) qsk qs
) / h0 ÿC1
k k = min , min hs
hsk sÿC1
k
h1
ÿC1+ max sk s s + máx s (1 ÿ q1 s 2
× / h0 ÿC1 )[· · · ]00 g1
k k kµU
ÿ mín.
s ÿ C1k , 1 ÿ k ÿ norte kµU + f g1 + f + NÿDR

kµUg1 kµU
y, usando las Relaciones 34.7, 34.9 y × ,
+ g1
f + NÿDR
1 ÿ q1s ÿ kµUg1
g1 + f + NÿDR s ÿ
kµUg1 + (kµU + g1)(f + NÿDR)
C1 1 ÿk k, ÿ norte
g1
× g1
obtenemos: g1 + f + NÿDR

1 f + NÿDR g1 + 1 1 g1 kµU
hs ÿ + + = min
g1 f + NÿDR f + NÿDR kµU g1 g1 + f + NÿDR kµU + f
g1 + f + NÿDR 1 g1 kµUg1 kµU
+ [· · · ] × ,
g1 + f + NÿDR + g1
1 1 kµUg1
= + + g1
g1 kµU g1 kµUg1 + (kµU + g1)(f + NÿDR) = g2(k)
ÿ

f + NÿDR
×
n=1 g1 + f + NÿDRn
y, para 1 ÿ k ÿ N, podemos tomar gÿ = kg2(k).
f +NÿDR
1 1 1 g1+f +NÿDR f Es posible modificar la especificación del modelo del
= + + +NÿDR 1
ÿ g1+f +NÿDR modelo agregado para obtener una especificación del
g1 kµU g1
modelo que implemente el método de acotación con un
1 1 1 f + NÿDR parámetro int que especifique el valor del parámetro K del
= + +
g1 kµU g1 (kµU
g1 + g1)(f + método de acotación y otro parámetro UB int tal que,
1 NÿDR) 1 + kµUg1 cuando el parámetro UB tenga el valor sí, se asigna una
=
g1 tasa de recompensa 1 a los estados de la parte
delimitadora (estados c1, c2,...,cM) y el ESSRR genérico
s ÿ C1k , 1 ÿ k ÿ norte (34.12)
Machine Translated by Google

638 Prácticas y aplicaciones emergentes

norte F
DR

sk
ck_1 _ C1k ck + 1
C0k
k
gramo1 EN

Figura 34.6. Resultados conocidos sobre las tasas de transición de los estados en Ck, 1 ÿ k ÿ N

Tabla 34.4. Límites para la indisponibilidad de estado estacionario obtenida Tabla 34.5. Tamaño de los modelos agregados delimitadores para el
usando los modelos agregados acotados para N = 8 cálculo de la indisponibilidad en estado estacionario para K = 4 como
función de N
K Límite inferior límite superior
norte estados Transiciones
1 5,270 7062 × 10ÿ5 2 5,341 1,208 9440 × 10ÿ4
13 53
5080 × 10ÿ5 3 5,341 6410 × 10ÿ5 5.352 3252 × 10ÿ5
1 84 575
4 5,341 6411 × 10ÿ5 5 5,341 5.341 6506 × 10ÿ5
2 197 1593
6411 × 10ÿ5 5.341 6411 × 10ÿ5
3 270 2158
5.341 6411 × 10ÿ5 4 273 2165
5 ÿ6 258 + 3N 2135 + 6N

medida se convierte en un límite superior para la indisponibilidad muestra la influencia del número de RAID

de estado estable y, cuando ese parámetro tiene subsistemas N y la cobertura al controlador

el valor no, se asigna una tasa de recompensa 0 a
los estados de la parte delimitante y el genérico
La medida ESSRR se convierte en un límite inferior para la
indisponibilidad en estado estacionario. Un valor moderado de
K es suficiente para obtener cotas muy ajustadas. Esto es
ilustrado en la tabla 34.4, que da los límites
obtenido con valores crecientes de K para N = 8,
ÿD = 2 × 10ÿ6 hÿ1, ÿDR = 3 × 10ÿ6 hÿ1, ÿC2 =
5 × 10ÿ6 hÿ1, ÿC1 = 8 × 10ÿ6 hÿ1, ÿP = 6 ×
10ÿ6 hÿ1, CC = 0,99, CP = 0,995, µDR = 0,4 hÿ1,
µU = 0,125 hÿ1 y µD = 0,02 hÿ1. esos valores
de tasas de falla, coberturas, reconstrucción de disco
fallas CC en la indisponibilidad en estado estacionario.
Todos los resultados se obtuvieron utilizando K = 4, que
produjo límites muy estrechos en todos los casos. como N
aumenta, la indisponibilidad en estado estacionario aumenta.
Esto es de esperar, ya que con más RAID
subsistemas la probabilidad de que cualquiera de ellos
está abajo es más grande. Mejorar la cobertura de
fallas del controlador más allá del valor de referencia CC =
0.99 tiene un impacto significativo en el estado estacionario
indisponibilidad solo hasta que CC alcanza un valor ÿ0.999.
Más allá de ese punto, la indisponibilidad en estado estacionario
se ve poco afectado.

tarifa, y las tarifas de reparación se utilizarán a partir de entonces
a menos que se diga lo contrario. La tabla 34.5 da el tamaño
de los modelos delimitadores agregados para K = 4 como
una función del número de subsistemas RAID N.
Los modelos agregados delimitadores son muy pequeños.
y su tamaño crece muy suavemente con N.
Los modelos agregados acotados permiten la
análisis de sistemas con N muy grande. Figura 34.7
La falta de fiabilidad de un subsistema RAID puede ser
computado como la medida genérica CRDTE(s) por
modificando la especificación del modelo produciendo el
CTMC utilizado para el cálculo de la indisponibilidad de estado
estable del subsistema RAID por lo que
que el estado DOWN es absorbente y una recompensa
tasa 1 se asigna a los estados arriba. ese modelo
la especificación puede extenderse trivialmente para generar
Machine Translated by Google

Modelado markoviano de confiabilidad/rendimiento de sistemas tolerantes a fallas 639

0.001 Tabla 34.6. Tamaño de los modelos CTMC agregados para el

norte =1 norte = 10 cálculo de la falta de fiabilidad del sistema de almacenamiento
norte =2 norte = 20
norte estados Transiciones
norte =5 norte = 50
0.0001 13 52
1 79 558
2 365 3484
3 1366 15 925
10_5
4 4369 58 968
5 12 377 187 096
6 31 825 526 864
78 75 583 1 384 542
10_6
10_5 0.0001 0.001 0.01
1 _ CC
Tabla 34.7. Límites para la falta de confiabilidad de un año obtenida usando
Figura 34.7. Influencia de N y CC en el estado estacionario los modelos agregados delimitadores para N = 8
indisponibilidad del sistema de almacenamiento
K Límite inferior límite superior

1 9,290 5804 × 10ÿ3 2 9,314 1.423 4973 × 10ÿ2

una CTMC de la que la falta de fiabilidad de un almacenamiento 6951 × 10ÿ3 3 9,314 7213 × 10ÿ3 9.319 9494 × 10ÿ3
4 9,314 7213 × 10ÿ3 5 9,314 9.314 7248 × 10ÿ3
Se puede calcular un sistema con N subsistemas RAID
7213 × 10ÿ3 9.314 7213 × 10ÿ3
mediante el uso de un conjunto independiente de variables de estado
9.314 7213 × 10ÿ3
DF, DR, CF y PF para cada subsistema RAID
y una variable de estado DOWN para representar que el
el sistema ha fallado. El número de estados de la
CTMC resultante sería 12N + 1, que es Tabla 34.8. Tamaño de los modelos agregados delimitadores para el
inmanejable para N grande. Además, el modelo cálculo de la falta de fiabilidad del sistema de almacenamiento para K = 4
la especificación sería diferente para cada valor en función de N

de N. Una especificación de modelo independiente de N N Modelo de límite inferior Modelo de límite superior
produciendo CTMC agregados de tamaño mucho más pequeño estados Transiciones estados Transiciones
se puede desarrollar utilizando el conteo de variables de estado
el número de subsistemas RAID en cada uno de los hasta 1 13 2 67 3 52 13 52

estados enumerados en la Tabla 34.1 y una variable de estado ABAJO 137 ÿ4 172 444 66 421
1004 136 931
representando que el sistema ha fallado. Cuadro 34.6
1234 171 1126
da el tamaño del CTMC agregado resultante
en función de N. Aunque más pequeño que el
CTMC agregados que permiten el cálculo
de la indisponibilidad en estado estacionario del almacenamiento Es posible modificar la especificación del modelo.
sistema, los CTMC agregados son todavía demasiado grandes del modelo de falta de fiabilidad agregada para obtener una
para permitir el análisis de sistemas con gran N. especificación del modelo que implementa el límite
El método de delimitación para la medida. método con un parámetro de modelo int que especifica
Se pueden usar los CRDTE descritos en la Sección 34.5 el valor de K y otro parámetro int UB
para permitir el análisis de sistemas con gran N. tal que, cuando ese parámetro tiene el valor
Para obtener límites estrechos, G tiene que incluir el sí, se genera el modelo de límite superior
estados "más probables". Dada la estructura de y, cuando ese parámetro tiene el valor no, el
la CTMC agregada, una selección razonable es se genera un modelo de límite inferior. En cuanto a
incluir en G todos los estados s en los que el sistema indisponibilidad en estado estacionario, un valor moderado de
está arriba y NC(s) + ND(s) + NP(s) + NR(s) ÿ K. K es suficiente para obtener límites muy estrechos para el
Machine Translated by Google
640 Prácticas y aplicaciones emergentes
0.1
CC= =0.99999
0.9999 PP
C = 0.99
0.999P P C =
0.01
0.001
0.0001
10_5 0.0001 0.001
1 _ CC
Figura 34.8. Influencia de CC y CP en la falta de confiabilidad de un año de
un sistema de almacenamiento con N = 10
falta de fiabilidad Esto se ilustra en la Tabla 34.7, que brinda
los límites obtenidos para la falta de confiabilidad de un año,
asumiendo que inicialmente todos los subsistemas RAID están
en su estado completamente operativo, para valores crecientes
de K y N = 8. La Tabla 34.8 brinda los tamaños de los
subsistemas inferiores y modelos CTMC agregados de límite
superior para K = 4 y varios valores de N. Ambos modelos son
muy pequeños para cualquier N.
Como ilustración del uso de los modelos de falta de
confiabilidad agregados delimitadores, la Figura 34.8 analiza el
impacto de las coberturas CC y CP en la falta de confiabilidad
de un año de un sistema de almacenamiento con N = 10,
asumiendo que inicialmente todos los subsistemas RAID están
en su estado completamente operativo. estado. Todos los
resultados se obtuvieron usando K = 4, lo que dio límites muy
ajustados en todos los casos.
34.7 Conclusiones
Los modelos CTMC recompensados son un formalismo de
modelado flexible para evaluar medidas de confiabilidad/
rendimiento para sistemas tolerantes a fallas. Sin embargo, el
uso eficiente de ese formalismo requiere la disponibilidad de
potentes metodologías de especificación de modelos y solución
de modelos.
Aunque se han realizado avances considerables en ambas
direcciones, queda mucho trabajo por hacer. Esto se debe a
que la creciente complejidad
de sistemas tolerantes a fallas da como resultado modelos
CTMC cada vez más grandes, que son difíciles de especificar
y costosos de resolver. Esto último es particularmente cierto
para medidas que requieren el cálculo de probabilidades
transitorias y, aún más, para medidas con estructura
probabilística compleja como la medida CRD(t, s). Deben
desarrollarse métodos numéricos más eficientes para el cálculo
de esas medidas. Los enfoques actualmente disponibles para
abordar el problema de la amplitud hacen factible el análisis
numérico de modelos de sistemas bastante complejos, como
ha ilustrado el estudio de caso, pero se requiere más trabajo.
0.01 Además, debe continuar el desarrollo de métodos eficientes
para clases y medidas de modelos particulares pero importantes,
por ejemplo , Suñé y Carrasco [70].
Los métodos combinatorios también deben ampliarse para
tratar de manera eficiente con clases más amplias de modelos
y medidas.
Referencias
[1] Iyer RK, Tang D. Análisis experimental de la confiabilidad del
sistema informático. En: Pradhan DK, editor. Diseño de sistemas
informáticos tolerantes a fallos. Englewood Cliffs, Nueva Jersey:
Prentice-Hall; 1995. págs. 282–392.
[2] Laprie JC, Costes A. Confiabilidad: un concepto unificador para la
computación confiable. Proc 12th IEEE Int Symp sobre
computación tolerante a fallas (FTCS-12); 1982. págs. 18–21.
[3] Meyer JF. Sobre la evaluación de la capacidad de ejecución de
los sistemas informáticos degradables. IEEE Trans Comput
1980;C 29(8):720–31.
[4] Meyer JF. Ejecución de un algoritmo para el control de admisión
de conexiones. IEEE Trans Comput 2001;50(7):724–
33.
[5] Abraham JA. Un algoritmo mejorado para la confiabilidad de la red.
IEEE Trans Reliab 1979;R-28:58–61.
[6] Aggarwal KB, Misra KB, Gupta JS. Un algoritmo rápido para la
evaluación de la confiabilidad. IEEE Trans Reliab 1975;R-24:83–5.
[7] Amari SV, Dugan JB, Misra RB. Un método separable para
incorporar cobertura de falla imperfecta en modelos combinatorios.
IEEE Trans Reliab 1999;48(3):267–74.
[8] Doyle SA, Dugan JB, Patterson-Hine FA. Un enfoque combinatorio
para modelar la cobertura imperfecta. IEEE Trans Reliab
1995;44(1):87–94.
[9] Dugan JB. Árboles de fallas y cobertura imperfecta. IEEE Trans
Reliab 1989;38(2):177–85.
[10] Sahner RA, Trivedi KS. Modelado de confiabilidad usando
SHARPE. IEEE Trans Reliab 1987;R-36(2):186–93.
[11] Neuts MF. Soluciones matriciales-geométricas en modelos
estocásticos. Un enfoque algorítmico. Publicaciones de Dover
Inc; 1994.
Machine Translated by Google
Modelado markoviano de confiabilidad/rendimiento de sistemas tolerantes a fallas
[12] Bobbio A, Telek M. Un punto de referencia para algoritmos de
estimación de PH: resultados para PH acíclico. Modelos Stat-Stochast
comunes 1994; 10 (3): 661–77.
[13] Beaudry MD. Medidas de confiabilidad relacionadas con el rendimiento
para sistemas informáticos. IEEE Trans Comput 1978;C 27(6):540–7.
[14] Blakemore A. El costo de eliminar las marcas que desaparecen de las
redes de Petri estocásticas generalizadas. Proc 3rd IEEE Int
Workshop on Petri Nets and Performance Models (PNPM89); 1989.
págs. 85–92.
[15] Goyal A, Carter WC, de Souza y Silva E, Lavenberg SS. El estimador
de disponibilidad del sistema. Proc 16th IEEE Int Symp sobre
computación tolerante a fallas (FTCS-16); 1986. págs. 84–9.
[16] Lindemann C. DSPNexpress: un paquete de software para la solución
eficiente de redes de Petri determinísticas y estocásticas. Realizar
Eval 1995;22(1):3–21.
[17] Chiola G, Franceschinis G, Gaeta R, Ribaudo M. GreatSPN 1.7: editor
gráfico y analizador para redes de Petri cronometradas y estocásticas.
Realizar Eval 1995;24(1/2):47–68.
[18] Ciardo G, Muppala J, Trivedi K. SPNP: paquete de red de Petri
estocástico. Proc 3rd IEEE Int Workshop on Petri Nets and
Performance Models (PNPM89); 1989. págs. 142–51.
[19] Béounes C, Aguéra M, Arlat J, Bachmann S, Bour deau C, Doucet JE,
Kanoun K, Laprie JC, Metze S, Moreira de Souza J, Powel D,
Spiesser P. SURF-2: a program for evaluación de confiabilidad de
sistemas complejos de hardware y software. Proc 23rd IEEE Int Symp
sobre computación tolerante a fallas (FTCS-23); 1993. págs. 142–50.
[20] German R, Kelling C, Zimmerman A, Hommel G.
TimeNET: un conjunto de herramientas para evaluar redes de Petri
estocásticas no markovianas. Realizar Eval 1995;24(1/2):69–87.
[21] Sanders WH, Obal II WD, Qureshi MA, Widjanarko FK.
El entorno de modelado de UltraSAN. Realizar Eval 1995;24(1/2):89–
115.
[22] Gilmore S, Hillston J. The PEPA Workbench: una herramienta para
apoyar un enfoque basado en el álgebra de procesos para el
modelado del rendimiento. Proc 7th Int Conf sobre técnicas y
herramientas de modelado para la evaluación del rendimiento de la computadora; 1994.
Lecture Notes in Computer Science 794. Berlín: Springer Verlag.
págs. 353–68.
[23] Hermanns H, Herzog U, Klehmet U, Mertsiotakis V, Siegle M.
Composicional performance modeling with the TIPtool. Realice Eval
2000;39(1–4):5–35.
[24] Berson S, de Souza y Silva E, Muntz RR. Una metodología para la
especificación y generación de modelos de Markov.
En: Stewart WJ, editor. Solución numérica de cadenas de Markov.
Nueva York: Marcel Dekker; 1991. págs. 11–36.
[25] Stewart WJ. Introducción a la solución numérica de cadenas de Markov.
Princeton, Nueva Jersey: Princeton University Press; 1994.
[26] Barker GP, PlemmonsRJ. Iteraciones convergentes para calcular
distribuciones estacionarias de cadenas de Markov.
SIAM J Alg Discr Meth 1986;7(3):390–8.
[27] Berman A, Plemmons RJ. Matrices no negativas en las ciencias
matemáticas. SIAM; 1994.
[28] Suñé V, Domingo JL, Carrasco JA. Métodos iterativos numéricos para
modelos de confiabilidad y capacidad de ejecución de Markovian:
nuevos resultados y una comparación. Realice Eval 2000;39(1–4):99–
125.
641
[29] Joven DM. Solución iterativa de grandes sistemas lineales.
Nueva York: Prensa Académica; 1971.
[30] Heidelberger P, Muppala JK, Trivedi KS. Aceleración de los cálculos
del tiempo medio hasta el fallo. Realizar Eval 1996;27/28:627–45.
[31] Malhotra M, Muppala JK, Trivedi KS. Métodos tolerantes a la rigidez
para el análisis transitorio de cadenas de Markov rígidas.
Microelectron Reliab 1994;34(11):1825–41.
[32] Malhotra M. Una técnica computacionalmente eficiente para el análisis
transitorio de sistemas markovianos reparables.
Realizar Eval 1995;24(1/2):311–31.
[33] Reibman A, Trivedi KS. Análisis transitorio numérico de modelos de
Markov. Comput Operat Res 1988;15(1):19–36.
[34] Procesos de Kijima M. Markov para el modelado estocástico.
Londres: Chapman and Hall; 1997.
[35] Bowerman PN, Nolty RG, Schener EM. Cálculo de la función de
distribución acumulada de Poisson. IEEE Trans Reliab 1990;39(2):158–
61.
[36] Fox BL, Glynn PW. Cálculo de probabilidades de Poisson.
Común ACM 1988;31(4):440–5.
[37] Knüsel L. Cálculo de la distribución chi-cuadrado y Poisson. SIAM J Sci
Stat Comput 1986;7(3):1022–36. [38] van Moorsel AP, Sanders WH.
Solución transitoria de modelos de Markov combinando uniformización
adaptativa y estándar. IEEE Trans Reliab 1997;46(3):430–40.
[39] Carrasco JA. Cálculo de límites para medidas transitorias de grandes
modelos de Markov recompensados usando aleatorización
regenerativa. Informe técnico DMSD_99_4.
Universidad Politécnica de Cataluña; 1999. Available at ftp://ftp-
eel.upc.es/techreports. To appear in Comput Operat Nada.
[40] Miller DR. Cálculo de confiabilidad usando aleatorización para sistemas
informáticos tolerantes a fallas Markovianos. Proc 13th IEEE Int Symp
sobre computación tolerante a fallas (FTCS 13); 1983. págs. 284–9.
[41] Melamed B, Yadin M. Procedimientos de aleatorización en el cálculo
de distribuciones de tiempo acumulativo sobre procesos de Markov
de estado discreto. Operat Res 1984;32(4): 926–44.
[42] van Moorsel APA, Sanders WH. Uniformización adaptativa.
Modelos Stat-Stochast comunes 1994;10(3):619–48.
[43] Sericola B. Análisis de disponibilidad de sistemas informáticos
reparables y detección de estacionariedad. IEEE Trans Comput
1999;48(11):1166–72.
[44] Carrasco JA. Análisis transitorio de grandes modelos de Markov con
estados absorbentes usando aleatorización regenerativa. Informe
técnico DMSD_99_2. Universitat Politècnica de Catalunya; 1999.
Disponible en ftp://ftp eel.upc.es/techreports [45] Carrasco JA. Límites
computacionalmente eficientes y numéricamente estables para
sistemas tolerantes a fallas reparables. IEEE Trans Comput 2002;51(3):254–
68.
[46] Donatiello L, Grassi V. Sobre la evaluación de la distribución del
rendimiento acumulativo de los sistemas informáticos tolerantes a
fallos. IEEE Trans Comput 1991;40(11):1301–7.
[47] Islam SMR, Ammar HH. Performance del hipercubo.
IEEE Trans Reliab 1989;38(5):518–26.
[48] Nabli H, Sericola B. Análisis de rendimiento: un nuevo algoritmo. IEEE
Trans Comput 1996;45(4):491–4.
Machine Translated by Google
642 Prácticas y aplicaciones emergentes
[49] Pattipati KR, Li Y, Blom HAP. Un marco unificado para la evaluación de la
capacidad de ejecución de los sistemas informáticos tolerantes a fallos.
IEEE Trans Comput 1993;42(3):312–26.
[50] Qureshi MA, Sanders WH. Métodos de solución del modelo de recompensa
con recompensas de impulso y tasa: un algoritmo y resultados numéricos.
Realizar Eval 1994;20:413–36.
[51] Qureshi MA, Sanders WH. Una nueva metodología para calcular
distribuciones de recompensa acumulada durante un intervalo finito. Proc
26th IEEE Int Symp sobre computación tolerante a fallas; 1996. págs.
116–25.
[52] Smith RM, Trivedi KS, Ramesh AV. Análisis de performabilidad: medidas,
un algoritmo y un caso de estudio. IEEE Trans Comput 1988;37(4):406–
17. [53] de Souza y Silva E, Gail HR. Cálculo de medidas de disponibilidad
y rendimiento de sistemas informáticos reparables mediante aleatorización. J
ACM 1989;36(1):171–93.
[54] de Souza e Silva E, Gail HR. Un algoritmo para calcular distribuciones
transitorias de tasa acumulada y recompensa basada en impulsos.
Modelos Stat-Stochast comunes 1998;14(3):509–36.
[55] Goyal A, Tantawi AN. Una medida de disponibilidad garantizada y su
evaluación numérica. IEEE Trans Comput 1988;37(1):25–32.
[56] Rubino G, Sericola B. Cálculo de distribución de disponibilidad de intervalo.
Proc 23rd IEEE Int Symp sobre computación tolerante a fallas (FTCS-23);
1993. págs. 48–55.
[57] Rubino G, Sericola B. Análisis de disponibilidad de intervalos utilizando
procesos de Markov numerables: aplicación a multiprocesador sujeto a
averías y reparación. IEEE Trans Comput 1995;44(2):286–91. [58] de
Souza y Silva E, Gail HR. Cálculo de las distribuciones acumulativas de
tiempo operativo de los sistemas informáticos reparables. IEEE Trans Comput
1986;C-35(4):322–32.
[59] Chiola G, Dutheillet C, Franceschinis G, Haddad S.
Redes coloreadas estocásticas bien formadas y simétricas
aplicaciones de modelado. IEEE Trans Comput 1993; 42 (11):
1343–60.
[60] Sanders WH, Meyer JF. Métodos de construcción de modelos base
reducidos para redes de actividad estocástica. IEEE J Select Areas
Commun 1991;9(1):25–36.
[61] Deavours DD, Sanders WH. Técnicas de solución “sobre la marcha” de
redes de Petri estocásticas y extensiones. IEEE Trans Software Eng
1998;24(10):889–902.
[62] Carrasco JA. Limitación de modelos de disponibilidad de estado estacionario
con distribuciones de reparación de grupo y reparación de tipo de fase.
Realizar Eval 1999;35(3/4):193–214.
[63] Lui JCS, Muntz R. Evaluación de los límites de la disponibilidad en estado
estacionario de sistemas reparables a partir de modelos de Markov.
En: Stewart WJ, editor. Solución numérica de cadenas de Markov. Nueva
York: Marcel Dekker; 1991. págs. 435–53.
[64] Lui JCS, Muntz RR. Cálculo de límites en la disponibilidad de estado estable
de sistemas informáticos reparables. J ACM 1994;41(4):676–707.
[65] Mahévas S, Rubino G. Bound Computing of Dependability and Performance
Measures. IEEE Trans Comput 2001;50(5):399–413.
[66] Muntz RR, de Souza e Silva E, Goyal A. Limitación de la disponibilidad de
sistemas informáticos reparables. IEEE Trans Comput 1989;38(12):1714–
23.
[67] Semal P. Límites refinables para grandes cadenas de Markov. IEEE Trans
Comput 1995;44(10):1216–22. [68] de Souza e Silva E, Ochoa PM.
Exploración del espacio de estados en modelos de Markov. Realizar Eval Rev
1992;20(1):152–66.
[69] Ross SM. Procesos estocásticos. Nueva York: John Wiley & Sons; 1983.
[70] Suñé V, Carrasco JA. Un método basado en la distancia de falla para limitar
la confiabilidad de los sistemas tolerantes a fallas no reparables sin el
conocimiento de cortes mínimos. IEEE Trans Reliab 2001;50(1):60–74.
Machine Translated by Google

Disponibilidad de solicitud aleatoria

Kang W Lee

35.1 Descripción
Introducción
y
matemática
definición
para la disponibilidad
del sistema 35.2
de Expresión
solicitud
35.3.3 Expresiones
aleatoria 35.3
matemáticas
35.3.1 Notación
Ejemplos35.3.2
numéricos
Suposiciones
35.4 Resultados
matemáticas
de
simulación 35.5 35.6 Aproximación 35.7 Observaciones finales

35.1 Introducción • disponibilidad de misión, disponibilidad de misión de trabajo,

Al permitir la reparación de un sistema averiado, no tiene sentido
hablar de la fiabilidad del sistema.
La dificultad radica en el hecho de que la confiabilidad del
sistema no permite considerar las reparaciones del sistema.
En consecuencia, dado que debería ser una ventaja para
nosotros reparar los sistemas defectuosos lo más rápido posible,
especialmente si su operación es crítica para algún objetivo
deseado, necesitamos alguna medida adicional del rendimiento
del sistema que considere los efectos de la reparación. Para tal
medida, la “disponibilidad” se ha propuesto como una cantidad
fundamental de interés. Es una medida más apropiada que la
confiabilidad para medir la efectividad de los sistemas
mantenidos porque incluye tanto la confiabilidad como la
mantenibilidad. mentira et al. [1] examinó y clasificó
sistemáticamente la literatura relevante para la disponibilidad.
Tres medidas diferentes de disponibilidad ampliamente
utilizadas son: disponibilidad de punto, disponibilidad de intervalo
y disponibilidad de estado estable. Sus definiciones pueden
verse en diversas publicaciones [2–4]. Esas medidas representan
bien una fracción de tiempo que un sistema está en un estado
operativo. Además de estas disponibilidades tradicionales,
existen otros tipos de disponibilidades, como:
y disponibilidad conjunta [5]; •
disponibilidad de cálculo [6]; •
disponibilidad equivalente [7].
Estas medidas especiales se han propuesto para representar
adecuadamente las disponibilidades para sistemas de aplicación
específicos.
Lee [8] ha propuesto otra medida de disponibilidad especial,
llamada disponibilidad de solicitud aleatoria. Se considera un
sistema reparable, que requiere la realización de varias tareas
que llegan aleatoriamente durante la duración fija de la misión.
Ejemplos incluyen:
• un mecanismo de tolerancia a fallas que se requiere para
manejar los errores resultantes de errores transitorios
(llamados perturbaciones de un solo evento) y fallas
permanentes de los componentes del sistema; • un sistema
de medición de información que opera continuamente y
entrega información sobre la demanda del usuario solo en
algunos momentos aleatorios de tiempo.
El modelo estocástico ya ha sido desarrollado [8], proporcionando
expresiones matemáticas de forma cerrada para la disponibilidad
de solicitudes aleatorias. Dado que la disponibilidad conjunta da
la probabilidad solo en dos momentos distintos, la medida
propuesta de Lee

643
Machine Translated by Google
644 Prácticas y aplicaciones emergentes
puede considerarse como una extensión útil de la disponibilidad
conjunta. También es general en el sentido de que la disponibilidad
de intervalo convencional puede representarse como un caso
especial.
La característica importante de la disponibilidad de solicitudes
aleatorias es introducir la llegada de tareas aleatorias en la medida
de disponibilidad. La tasa de llegada de la tarea puede ser constante
o una función dependiente del tiempo. Considere un sistema de red
de conmutación de paquetes, que tiene períodos de operación y
reparación que forman un proceso alterno.
La tasa de llegada de los paquetes entrantes puede no ser constante.
Durante la hora pico, el sistema puede tener una mayor tasa de
llegada de paquetes. La disponibilidad de solicitudes aleatorias debe
tener valores diferentes según la tasa de llegada de tareas promedio
y los patrones de tasa de llegada. Por lo tanto, es necesario investigar
el efecto del elemento "llegada de la tarea" en el valor de disponibilidad
de la solicitud aleatoria. Debido a la complejidad computacional, se
utiliza un método de simulación utilizando el lenguaje de simulación
ARENA para obtener una solución. Se sugiere el método de
aproximación simple basado en la disponibilidad de intervalos.
Su precisión resulta variar según los requisitos operativos del
sistema, la tasa promedio de llegada de tareas y el número promedio
de ciclos de encendido y apagado durante el tiempo de la misión.
En la Sección 35.2 se describen los tres elementos del sistema
para el modelo estocástico y se define la disponibilidad de solicitudes
aleatorias. Las secciones 35.3 y 35.4 presentan expresiones
matemáticas para la disponibilidad de solicitudes aleatorias y
ejemplos numéricos, respectivamente. En la Sección 35.5, varias
propiedades de la disponibilidad de solicitudes aleatorias se derivan
de los resultados de la simulación. La sección 35.6 presenta el
método de aproximación simple y analiza su precisión. La sección
35.7 contiene observaciones finales.
35.2 Descripción y definición
del sistema
El modelo estocástico de Lee [8] es interesante y potencialmente
importante porque proporciona expresiones matemáticas de forma
cerrada para la disponibilidad de solicitudes aleatorias en las que
múltiples sistemas
Se pueden incorporar factores. Los tres elementos del sistema en
torno al cual se desarrolla este modelo son los siguientes.
1. Llegadas aleatorias de tareas. Se presenta un sistema con un
flujo de tareas que llegan de acuerdo con algún proceso aleatorio.
Los ejemplos incluyen un sistema de control de tráfico aéreo que
tiene que lidiar con los aviones que llegan y un sistema de tanques
que se enfrenta a un enemigo que debe participar en la batalla. Dado
que la velocidad a la que llegan las tareas y el patrón de la tasa de
llegada afectan la eficacia general del sistema, el proceso de llegada
de tareas se incluye como un elemento del modelo.
2. Estado del sistema. En cada hora de llegada de la tarea, el
sistema puede estar en uno de dos estados: encendido o apagado.
Si el sistema está encendido, está funcionando; de lo contrario, el
sistema está inactivo (en reparación). El sistema está en servicio
durante un tiempo aleatorio Ton, hasta que falla. Cuando falla, se
apaga por un tiempo aleatorio Toff. Repite el ciclo de estar encendido
por un tiempo aleatorio y estar apagado por otro tiempo aleatorio.
Los tiempos sucesivos en el estado encendido y en el estado
apagado son estadísticamente independientes.
3. Requerimientos Operativos del Sistema.
Para el éxito de la misión, puede que no sea necesario completar
todas las tareas que llegan al azar durante el tiempo de la misión, es
decir , completar partes de las tareas que llegan puede llevar al éxito
de la misión.
Para los requisitos operativos del sistema, se introducen tres
sistemas: (a) sistema perfecto, (b) sistema r(k)-out-of-k y (c) sistema
de puntuación.
La disponibilidad de solicitud aleatoria se define para cada uno
de los siguientes tres sistemas. una. El Sistema Perfecto. El sistema
debe estar en estado activado en cada hora de llegada de la
tarea.
La disponibilidad de solicitud aleatoria se define como la probabilidad
de que el sistema esté encendido en cada hora de llegada de la
tarea. b. El sistema r(k)-out-of-k. El sistema debe estar en estado
activado en el momento de la llegada de al menos algunas
tareas. El número mínimo, denotado por r(k), depende del número
de llegadas de tareas, k.
La disponibilidad de solicitud aleatoria se define como la probabilidad
de que el sistema esté encendido en los momentos de al menos “r(k)
de k” llegadas de tareas.
C. El sistema de puntuación. Si el sistema está en el estado
encendido en j (j ÿ k) de k tiempos de llegada de la tarea, una puntuación
Machine Translated by Google

Disponibilidad de solicitud aleatoria 645

35.3.2 Suposiciones Matemáticas

35.3.3 Expresiones Matemáticas

35.3 Expresión matemática ÿ

para la disponibilidad de
k=1
(0ÿt1<t2<··<tkÿT )
solicitud aleatoria k

35.3.1 Notación yo=1

Sj,kj=0 k
( l=1 il=j )
Machine Translated by Google
Machine Translated by Google
Por ejemplo, dado k = 2, r(2) = 1 y Sj,2 = j/2, A(t1, t2) se puede
expresar como se muestra en la tabla 35.1.
35.4 Ejemplos numéricos
Suponga que los parámetros del sistema se dan como en la Tabla
35.2.
Se dan dos ejemplos. El primero supone que el sistema está
en estado encendido en el momento 0. En el segundo ejemplo,
se supone que el estado del sistema está apagado en el momento
0. Las tablas 35.3 y 35.4 resumen los resultados. Todas las
integraciones se realizan utilizando el software “Mathematica”.
35.5 Resultados de la simulación
En esta sección, queremos mostrar algunas propiedades de la
disponibilidad de solicitudes aleatorias. La característica
importante de la disponibilidad de solicitudes aleatorias es que la
llegada de tareas aleatorias se incluye en el modelo como uno de
los elementos del sistema.
Por lo tanto, es necesario investigar el efecto del elemento
"llegada de tareas" sobre la disponibilidad de solicitudes aleatorias.
Si el número medio de llegadas de tareas es grande, la
complejidad computacional es alta.
Incluso si la misión tiene un promedio de dos llegadas de tareas
bajo el supuesto de llegada de Poisson, se requiere el séptimo
orden de integral múltiple para obtener una solución con límite de
error menor que 10ÿ2.
Por lo tanto, se utiliza un método de simulación que utiliza el
lenguaje de simulación ARENA para obtener una solución.
Los resultados de la simulación para el primer ejemplo de la
Sección 35.4 se comparan con el análisis
0.16
mt 1( )
0.08 metro 2( )
mt 3( )
10
Figura 35.1. Tasa de llegada de tareas
Disponibilidad de solicitud aleatoria 647
de la tabla 35.5. Los resultados de la simulación son los
promedio de 107 carreras después de algunos períodos de calentamiento.
Podemos ver que las diferencias entre dos resultados son
menores a 10ÿ3.
Variando la tasa promedio de llegadas de tareas (1, 5 y 10),
el tipo de tasa de llegada de tareas (constante, creciente y
decreciente) y la duración de los tiempos de permanencia
promedio en los estados activado y desactivado ([0.1, 0.02], [ 1,
0.2] y [50/6, 10/6]), la disponibilidad de solicitudes aleatorias se
obtiene para cada uno de los siguientes tres sistemas: perfecto,
r(k)-out-of-k y de puntuación. Los demás parámetros del sistema
son los mismos que los de la Tabla 35.2.
La Tabla 35.6 resume los resultados, que muestran los siguientes
hechos.
1. Se puede ver que la disponibilidad de solicitudes aleatorias
tiene diferentes valores dependiendo de la tasa promedio de
llegada de tareas. También podemos ver que el efecto de la tasa
de llegada de tareas es diferente según los requisitos operativos
del sistema.
Para el sistema perfecto, una tasa de llegada de tareas promedio
más alta da un valor más bajo de disponibilidad y viceversa. A
medida que aumenta la tasa promedio de llegadas, los valores
de r(k)-out-of-k y los sistemas de puntuación pueden aumentar,
disminuir o incluso ser constantes según el valor r(k) respectivo y
la puntuación Sj,k para un dado k.
2. La disponibilidad de solicitudes aleatorias tiene diferentes
valores según los patrones de la tasa de llegada de tareas, incluso
si las misiones tienen el mismo promedio de llegadas de tareas
durante el tiempo de la misión. Para que el sistema esté encendido
en el momento 0, m3(t) y m1(t) proporcionan las disponibilidades
de solicitud aleatoria más alta y más baja, respectivamente. Si el
sistema está apagado en el tiempo 0, m1(t) produce un valor de
disponibilidad de solicitud aleatoria más alto que m2(t) y m3(t).
Estas propiedades provienen directamente del hecho de que
m3(t) da una mayor tasa de llegada de tareas al comienzo de la
misión que en la última parte y m1(t) da una mayor tasa de llegada
de tareas en la última parte de la misión.
3. La propiedad 2 anterior se puede ver más claramente
cuando el número promedio de ciclos de encendido y apagado
(M) durante el tiempo de la misión tiene un valor pequeño,
tiempos de permanencia relativamente largos en los estados de
encendido y/o apagado en comparación con el tiempo de la
Tiempo
misión. Es decir, para los sistemas que tienen una M pequeña,
las disponibilidades de solicitudes aleatorias tienen valores
significativamente diferentes de acuerdo con los patrones de tasa de llegada d
Machine Translated by Google

648 Prácticas y aplicaciones emergentes

Tabla 35.3. Ejemplo 1: resultados

Sistema Tasa de llegada de tareas

m1(t) = 0,016t m2(t) = 0,08 m3(t) = 0,16 ÿ 0,016t

Perfecto 0,776 r(k)-out-of-k 0,779 0.782

0,876 Puntuación 0,833 0,879 0.880
0,836 0.838

Tabla 35.4. Ejemplo 2: resultados

Sistema Tasa de llegada de tareas

m1(t) = 0,016t m2(t) = 0,08 m3(t) = 0,16 ÿ 0,016t

Perfecto 0,775 r(k)-out-of-k 0,758 0.742

0,875 Puntuación 0,833 0,865 0.857
0,819 0.806

Tabla 35.5. Comparación de la simulación y los resultados analíticos

Sistema Tasa de llegada de tareas

m1(t ) = 0,016t m2(t ) = 0,08 Simulación analítica m3(t) = 0,16 ÿ 0,016t

Simulación analítica Simulación analítica

Perfecto 0,776 r(k)-out-of-k 0,777 0,779 0,779 0,782 0.782

0,876 Puntuación 0,833 0,876 0,879 0,879 0,880 0.880
0,833 0,836 0,837 0,838 0.838

aunque hay el mismo número promedio de tareas respectivamente de acuerdo con la tasa de llegada de la tarea
llegadas durante el tiempo de la misión. Todo el tiempo, el patrones, m1(t), m2(t) y m3(t). Estos valores son
disponibilidades de solicitud aleatoria para sistemas que tienen solo disponibilidades de intervalos convencionales, que pueden
grandes M tienen casi los mismos valores independientemente calcularse como:
de los patrones de tasa de llegada si las misiones tienen la
10 monte)
misma tarea promedio de llegadas durante la misión
Pr[z(t) = 1] dt
tiempo. 20 M(T)
4. Los resultados de la simulación muestran que la 1 10 5 1
ÿ ÿ36 t
disponibilidad de solicitudes aleatorias tiene el valor más bajo bajo + Exp dt
10 2 0 66 50
el sistema perfecto y el valor más alto bajo
los sistemas r(k)-out-of-k. De la tabla 35.6, = 0,841, para m(t) = m1(t)
también puede ver que el efecto del patrón de tasa de llegada 1 10 5 1
en el valor de disponibilidad de solicitud aleatoria es más + Exp
ÿ36 t t dt
50 2 0 66 50
significativo en el sistema perfecto que en el r(k)- =
out-of-k y sistemas de puntuación. ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ = 0,857, para m(t) = m2(t)
5. Como se mencionó antes, la solicitud aleatoria
1 10 5 1 ÿ36 t
disponibilidad del sistema de puntuación con Sj,k = + Exp
j/k es solo una disponibilidad de intervalo convencional. 50 2 0 66 50
Por ejemplo, en la Tabla 35.6, la solicitud aleatoria
×(10 ÿ t) dt
disponibilidades del sistema de puntuación con ÿ =
6/50 y ÿ = 6/10 son 0,841, 0,857 y 0,874, ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
= 0,874, para m(t) = m3(t)
Machine Translated by Google
Machine Translated by Google
Machine Translated by Google

Disponibilidad de solicitud aleatoria 651

Tabla 35.8. Promedio máximo de llegadas de tareas que satisfacen el requisito de precisión

Sistema Promedio de tiempos de permanencia en los estados encendido y apagado Máximo promedio de llegadas de tareas

satisfacer el requisito de precisión (|

resultado de la simulación ÿ resultado de
la aproximación| ÿ 10ÿ2)

Perfecto ÿ = 10, ÿ = 50 (M = 83,33) ÿ = 1, ÿ

ÿ = 5 (M = 8,33) ÿ = 6/50, ÿ = 2
6/10 (M = 1) 0,5

r(k)-fuera-de-k ÿ = 10, ÿ = 50 (M = 83,33) ÿ = 1, ÿ

ÿ = 5 (M = 8,33) ÿ = 6/50, ÿ = 10
6/10 (M = 1) 1

ÿ
Puntuación (Sj,k = (j/k)2) ÿ = 10, ÿ = 50 (M = 83,33) ÿ = 1, ÿ = 5
(M = 8,33) ÿ = 6/50, ÿ = 6/10 (M ÿ

= 1) 2

ÿ k
En la Tabla 35.6, podemos ver que estos valores varían k
jkÿj
A˜s(T ) = {A )} {1ÿA(T )}
según el patrón de la tasa de llegada de tareas, pero no la k=1 j=0
j
tasa promedio de llegada de tareas.
× Sj, k Pr[N(T ) = k]

35.6 Aproximación Parece ser × (1 ÿ Pr[N(T ) = 0])

ÿ1
(35.6)
difícil obtener métodos de aproximación robustos.
Incluso si Finkelstein proporcionara una fórmula de
aproximación heurística [9], solo es buena para el Utilizando las Ecuaciones 35.4–35.6, los valores de

sistema perfecto. Y su precisión está garantizada aproximación para las disponibilidades de solicitudes
aleatorias
solo dentro de un rango limitado de parámetros del sistema. se obtienen bajo varios valores de parámetros del sistema.

Un método sencillo e intuitivo es utilizar la Los resultados aproximados se comparan con los de
disponibilidad de intervalo convencional. Teniendo en simulación en la Tabla 35.7. A menos que se especifique
lo
cuenta la tasa de llegada de tareas, se puede expresar como: contrario, los parámetros del sistema son los mismos
que los de la Tabla 35.2.
T
monte) Para el sistema perfecto, la imprecisión de la
Pr[z(t) = 1] dt (35.3)
A(T) = 2 0 M(T) aproximación crece rápidamente a medida que M se
vuelve pequeño y aumenta la tasa de llegada de tareas.
Los valores aproximados para los sistemas perfecto,
Los resultados de la aproximación para los sistemas
r(k)-out-of-k y de puntuación se pueden expresar
r(k)-out-of-k y de puntuación son más precisos que los
respectivamente de la siguiente manera:
del sistema perfecto. Muestran una mejor precisión para
ÿ
k=1{A(T )}k Pr[N(T ) = k] M más grandes y una tasa de llegada de tareas más
A˜p(T ) = (35.4)
1 ÿ Pr[N(T ) = 0] baja. Dado el valor de M, tratamos de encontrar el
ÿ k promedio máximo de llegadas de tareas que satisfaga
k
j
A˜r(T ) = {A )} el requisito de precisión, |resultado de la simulación ÿ
k=1 j=r(k)
j resultado de la aproximación| ÿ 10ÿ2. La Tabla 35.8
muestra los resultados. Se supone que las tasas de
kÿj
× {1 ÿ A(T)} Pr[N(T ) = k] llegada de tareas para todos los sistemas son una
ÿ1 función decreciente. Por ejemplo, la tasa de tasa de
× (1 ÿ Pr[N(T ) = 0]) (35.5)
llegada de tareas correspondiente a la llegada promedio de una ta
Machine Translated by Google
652 Prácticas y aplicaciones emergentes
En la tabla 35.8, podemos ver que los sistemas r(k)-out-
of-k y de puntuación pueden satisfacer el requisito de
precisión de la aproximación con una tasa promedio de
llegada de tareas más alta que el sistema perfecto.
Para los sistemas r(k)-out-of-k y de puntuación, la
precisión de la aproximación también depende del valor
r(k) respectivo y de la puntuación Sj,k para una k dada.
Podemos ver una baja precisión en el sistema perfecto,
que es el caso más estricto del sistema r(k)-fuera de k
(r(k) = k para todo k) o el sistema de puntuación (Sj,k =
1 para j = k, y 0 en caso contrario).
Por lo tanto, cuanto más estricto sea el requisito
operativo, menor será la precisión de la aproximación
para el sistema de puntuación r(k)-out-of-k y viceversa.
35.7 Observaciones finales
Para el sistema requerido para realizar tareas que
llegan aleatoriamente durante una duración fija de la
misión, se ha propuesto una medida de disponibilidad
denominada disponibilidad de solicitud aleatoria. El
modelo estocástico proporciona expresiones matemáticas
de forma cerrada, que incorporan tres elementos básicos:
las llegadas de tareas aleatorias, el estado del sistema
y los requisitos operativos del sistema.
La característica de la disponibilidad de solicitud
aleatoria es que la llegada de la tarea aleatoria se
incluye como uno de los elementos del sistema.
Utilizando un método de simulación, se investigó el
efecto del elemento “llegada de tareas” en la
disponibilidad de solicitudes aleatorias.
Si el número medio de llegadas de tareas crece, la
complejidad computacional para derivar la disponibilidad
de solicitudes aleatorias se vuelve extremadamente alta.
Se sugiere un método de aproximación simple basado
en la disponibilidad de intervalo convencional.
Su precisión varía según los requisitos operativos del
sistema, la tasa promedio de llegada de tareas y el
número promedio de ciclos de encendido y apagado (M)
durante el tiempo de la misión.
Agradecimientos Este
trabajo fue apoyado por el fondo de investigación de la
Universidad Nacional de Tecnología de Seúl.
Referencias
[1] Lie CH, Hwang CL, Tillman FA. Disponibilidad del sistema mantenido:
una encuesta del estado del arte. AIIE Trans 1977;3:247–
59.
[2] Lewis EE. Introducción a la ingeniería de confiabilidad. Nuevo
York: John Wiley & Sons; 1987.
[3] Kapur KC, Lamberson LR. Confiabilidad en el diseño de ingeniería.
Nueva York: John Wiley & Sons; 1987.
[4] Rau JG. Optimización y probabilidad en ingeniería de sistemas.
Ámsterdam: Van Nostrand Reinhold; 1970.
[5] Birolini A. Calidad y confiabilidad de los sistemas técnicos.
Berlín: Springer; 1988.
[6] Reibman AL. Modelización del efecto de la fiabilidad en el rendimiento.
IEEE Trans Reliab 1990;3:314–20.
[7] Lazaroiu DF, Staicut E. Relación entre congestión, fiabilidad y
disponibilidad en redes informáticas de conmutación de paquetes.
IEEE Trans Reliab 1983;4:354–7.
[8] Lee KW. Modelos estocásticos para disponibilidad de solicitudes
aleatorias. IEEE Trans Reliab 2000;1:80–4.
[9] MS de Finkelstein. Múltiples disponibilidades sobre demanda
estocástica. IEEE Trans Reliab 1999;1:19–24.
Machine Translated by Google
Índice
Un conocimiento a priori 225
modelo de tiempo de falla acelerado 485–6 prueba
de vida acelerada (ALT) 415–28, 457 diseño de
planes 416–17 descripción general 415–16, 430–
1 planificación de un estrés escalonado simple
446–8 estrés escalonado planificación 445–50
cargas de tensión 416 tipos de tensión 416–17
modelos de prueba de vida acelerada (ALT) 417–
25, 429–39
Birnbaum-Saunders formulario 431–5
procedimientos de inferencia 435–7 no
paramétrico 424–5
factor de aceleración (AF), establecimiento de un objetivo
447 función de aceleración 436 votación de aceptación 588
energía de activación 422 modelos de daños aditivos 433–
4 modelo de Gauss-Weibull aditivo 435 distribución de
fuerza de Gauss-Weibull aditivo 434 modo de reparación
dependiente de la edad 338 modelos de reemplazo de edad
354–6 política de reemplazo de edad 368–70 CTMC agregado
639–40 clases de envejecimiento de 171 conceptos de 165 fallo
de bloqueo/bloqueo 247 nociones de 167, 181
Prueba de Ahmad 193–5
Criterio de información de Akaike (AIC) 282 algoritmos
57, 572
Familia Ali–Mikhail–Haq 150
Instituto Americano de Investigación (AIR) 535
AND gate 532
lenguaje de programación orientado a aplicaciones 574 documento
de diseño arquitectónico 572
Modelo de Arrhenius 422–4
Análisis asintótico 41 Disponibilidad
promedio asintótica 406, 408 Desviaciones estándar
asintóticas (ASD) 438
Comisión de Energía Atómica (AEC) 535, 544–5 medidas de
disponibilidad 643
Índice de Disponibilidad de Servicio Promedio (ASAI) 514, 520
Índice promedio de indisponibilidad del servicio (ASUI) 514
disponibilidad promedio del software 238–40
653
B
antecedentes 216 índices de
fallas en la bañera 169–70 intensidad
tipo bañera 327–8
Fórmulas de reestimación de Baum-Welch 272
Método de reestimación de Baum-Welch 271, 282
Fórmula de Bayes 278
Estimación bayesiana del número esperado de fallas 343
Estimación bayesiana de los parámetros del modelo 342
Procedimiento bayesiano 225
Sistema de ventana plegable b 52
Planta de Big Rock Point 546
Modelos binarios k de n 4 Teoría de
la confiabilidad binaria 3–4 Sistema
binario 3 Modelos binomiales 226
Birnbaum importancia 44–5
Distribución de Birnbaum-Saunders 431, 436
envejecimiento bivariado, pruebas de 177 distribución
bivariada de Block y de Basu 149–50 distribución exponencial
bivariada 148
de Sarmanov 150
distribución normal bivariada, función de densidad 150 distribución
bivariada de Pareto 148–9
dependencia positiva bivariada más fuerte que la condición dependiente del
cuadrante positivo 152–3 clases de confiabilidad bivariada 173 modelado
de caja negra
temas actuales 225–32
depuración imperfecta 225–6 modelos
de confiabilidad de software de caja negra 215–22 reemplazo
de bloques 370–1 modelos de reemplazo de bloques 350–4
procesos de intensidad acotada (BIP) 326–7 método de
ramificación y acotación 96–8, 111
Laboratorio Nacional de Brookhaven 550, 551
Brown–Proschan imperfecto reparación modelo 399–400
Índice de reducción de energía de energía a granel 519
Índice de interrupción de energía masiva 519
Reducción de MW promedio de suministro de energía a granel 519
Perturbaciones en el suministro de energía a granel 519
Calibración C 223–5
Gráfico de llamada 222
Machine Translated by Google

654 Índice

Canadian Electricity Association (CEA) 513 base de datos supuestos básicos 38

522–3 base de datos del sistema de información de sistemas conectados consecutivamente 57
confiabilidad del equipo 523–5 bloque de recuperación de consenso 588
Estadísticas de continuidad del servicio canadiense 515 impacto de reparación constante 339 mejora
Modelo de madurez de capacidad para software (CMM) 570 continua en la gestión de calidad total
requisitos de capacidad 568 métodos de captura y recuperación 493– (TQM) 581–2
510 estudios ecológicos 508 ejemplos 504–5 formulación del modelos continuos 343, 344–5 enfoques
problema 495–503 de relajación continua 94 modelo de espacio de
estado continuo para software a gran escala 274–80 modelos de confiabilidad
del sistema de estado continuo 8 cadena de Markov de tiempo continuo ver
modelos de captura-recaptura 215, 232 datos CTMC modelo de tiempo continuo 357–8 correctivo mantenimiento 305, 309–10,
censurados 480–3 397, 398
Centro de Dispositivos y Salud Radiológica (CDRH) 537
Estimador de Chang-Rao 188–9 y garantía 311–12
Modelos de punto de cambio 157–63 reparaciones correctivas, intercaladas con mantenimiento preventivo
Supuestos 158–9 Tipos específicos sin supuestos restrictivos 342–3
159–60 Problema de punto de corrección 569
cambio 157 Estadísticas de interruptores análisis de costos, garantía 308–9
automáticos 525 Sistema circular modelado de costos 295–300
ponderado k consecutivo de n 47–8 Método de sala limpia 575 falla en optimización de costos 21–2 intensidad
modo cerrado 19, 80–2 ejemplos de sistemas de clústeres 255–7 condicional de conteo 218 proceso de
rejuvenecimiento basado en predicciones 256 conteo 215
enfoque dinámico 231
intensidad estocástica 228
estadísticas de conteo, proceso de punto autoexcitante 218
COCOMO 576, 579–80 sistema covariables 228, 231
coherente 3, 230 optimización Modelo de Cox 424–5
de confiabilidad combinatoria 91–114 enfoques de relajación Método delta de Cramer 436
continua 93–4 enfoques heurísticos 93 restricciones de CTMC 247, 615
opción múltiple 107–13 estructura no en serie 102–7 irreductible 616
enfoques de solución óptima 93 estructuras en serie 95– problema de grandeza 630–2
102 combinatoria métodos de solución 615 modelo solución modelo 625–30
combinado, reparaciones mínimas 359–61 fallas comunes especificación del modelo 622–5
(CF) 590–1, 600–1 fallas comunes 590–1 reglas de producción 634
recompensado 615–19, 640
diagrama de transición de estado 248, 626, 632
terminología 616 modelos de daño acumulativo
432–5, 438 daño acumulativo modelo de shock 403
COMPASS 518 acumulativo parámetros de la curva de demanda 78,
función de intensidad completa (CIF) 319–21, 331–5, 337, 339, 87 curvas de demanda acumulada 70 funciones de
341–3 distribución acumulada (CDF) 429, 431, 438 modelos de
política de mantenimiento complejo 335–43 exposición acumulada 443–5, 457–9, 463 función de riesgo acumulada
sistema multiestado complejo usando operadores de composición, función 481 distribución de recompensa acumulada (CRD) 621–2, 630–1
u de 67–8 distribución de recompensas acumuladas durante la estadía (CRDDS)
importancia de los componentes 43–7 620–1 distribución de recompensas acumuladas hasta la salida (CRDTE)
problema de reemplazo de componentes 43–7 619–20
dígrafo de componentes 616, 617 operadores de
composición 67–8 modelo de rendimiento de Índice de duración promedio de interrupción del cliente
cómputo 241–2 disponibilidad de software de cómputo (CAIDI) 514, 520
241 ingeniería de software asistida por computadora Índice de frecuencia de interrupción promedio del cliente
(CASE) 575 (CAFI) 514, 515
COMREL 518–20
Función de tasa de falla concatenada 216
Expectativa condicional 136 Verosimilitud
condicional 503, 508 Estimadores de verosimilitud
condicional 509 Intervalos de confianza 224, 437, D
460–2, 607–10 Sistemas de k:G consecutivos 38 K-de-n
Modelado de dominio de datos 588–
consecutivos :F sistema 37 variaciones y generalizaciones 9 Estructuras de datos 572 Prueba
38 sistema de k consecutivos de n 53, 54 sistemas de k de datos 602–10 Modelo de proceso
consecutivos 37–59 de muerte 266–71 Tasa de falla
decreciente (DFR) 147, 169 Tasa de falla
decreciente promedio (DFRA) Distribución 182
Machine Translated by Google
disminuyendo inicialmente, luego aumentando la vida residual media
(DIMRL) 171
distribución de vida residual media decreciente (DMRL) 182 gestión de
confiabilidad ver medidas de confiabilidad de gestión de confiabilidad
total (TDM) 614 métricas de confiabilidad 229 dependencia,
concepto de 141–2 modelo de dependencia 57 concepto determinista
554 técnicas deterministas 511 residuos de desviación 490 diferencias
ecuaciones diferenciales 253–4 modelos discretos 8, 343, 345–6
modelos discretos de reemplazo 374–5 cadena de Markov de tiempo
discreto (DTMC) 629
con tres estados 252 modelo
de tiempo discreto 358–9 algoritmo
de programación dinámica basado en secuencias dominantes 105
sistema dominante 13
con imagen binaria 15
Proceso de Poisson doblemente estocástico (DSPP) 217, 222
Relación dual entre k de n Sistemas G y F 7–8
Distribución de Durling-Pareto 148–50 enfoque
dinámico de los procesos de conteo 231 modelos dinámicos
205–7, 215 clase general 205–6 programación dinámica 98
algoritmo de programación dinámica 100, 105
Y
Ebrahimi-Habibullah prueba 192 ecología
508
Evaluación de la confiabilidad del sistema de energía eléctrica (EPSRA) 513,
515
sistemas de energía eléctrica 511–28
consumidor, utilidad y costo total en función de la confiabilidad del
sistema 526 recopilación de datos 513 evaluación de
confiabilidad del sistema de distribución 519–20 zonas funcionales
512
guía para estudios adicionales 527
niveles jerárquicos 512 análisis del
sistema 515–16 datos de
confiabilidad del sistema 521–5
desempeño de la confiabilidad del sistema 512–15
predicción de la confiabilidad del sistema 515–21
valor de la confiabilidad del sistema 525–7
tensiones eléctricas 416–17 equipo electrónico,
clasificación 537
ELOC (líneas de código efectivas) 576 riesgo
de ingeniería 549–50 factores ambientales
227–8, 289–93 estimación de parámetros 292
riesgo ambiental 549–50 estrés
ambiental 417 confiabilidad del
equipo 320
Sistema de información de confiabilidad del equipo (ERIS) 513, 523,
524
Índice 655
errores de inicialización de modelos 579
ESA 571, 573, 574, 582
proyecto ESPRIT 571, 582
tiempo acumulado estimado de detección de fallas 275
número medio estimado de casos de prueba consumidos 270 tiempo
estimado hasta el agotamiento 258 método de estimación de
parámetros desconocidos 268–9, 272–3,
277–9
Premio Europeo a la Calidad 560 tasa
de recompensa promedio esperada (EARR) 619, 630–1
recompensa acumulada esperada durante la estadía (ECRDS) 618–19,
621
recompensa acumulada esperada hasta la salida (ECRTE) 618, 621, 632
energía esperada no suministrada (EENS) 516 tasa de recompensa de
estado estable esperada (ESSRR) 617–18, 621, 624, 625, 632 tasa de
recompensa transitoria esperada (ETRR) 619, 621, 630–1 distribución
exponencial 166 modelo exponencial 419–20 fórmula de exponenciación 214
red extendida de k consecutivos de n:F 55 estructuras de recompensa
extendidas 621–2
F f -confiabilidad del flujo
56 f -dentro de k consecutivos de n sistema 49–51 modos
de falla 77–83 sistemas ponderados 34–5
análisis de modos y efectos de falla (FMEA) 538 procesos
de falla 222 tasa de falla 172, 401–2 modelado 117–39
características de falla/restauración 237 tiempos
de falla 215, 494
Farlie-Gumbel-Morgenstern (FGM) bivariada
distribución 148
Farlie–Gumbel–Morgenstern (FGM) copolas 151–2 falla por fatiga
431, 437 densidad de fallas, observada y pronosticada 204
detección de fallas 493 detección de fallas constante de fase 203
función de intensidad de fallas 291 función de tasa de intensidad
de fallas 291 enmascaramiento de fallas 613 sistemas tolerantes a
fallas 32– 4 modelado 614 confiabilidad 614 tolerancia a fallas 585–
611, 613, 614, 643 técnicas híbridas 587–8 metodologías 586–8
árbol de fallas, símbolos 532–4
Manual del árbol de fallas 547
Método del árbol de fallas 532–4, 538
Fibonacci numeros 45 archivo
tabla tamaño 258
matriz de formación de Fisher 447
sistema de transmisión de flujo 81
distribución de rendimiento acumulado 82, 83 soluciones
obtenidas para 82 lavado de tablas kernel del sistema
operativo 246
Machine Translated by Google
656 Índice
FMECA 561, 562, 564
Administración de Alimentos y Medicamentos (FDA) 536, 537
FORTRAN 293, 324
tiempo de espera hacia adelante
320 garantía de reemplazo gratuito (FRW) 307, 311
procedimientos frecuentistas 223–5 función de la
demanda, MSS 71 requisitos funcionales 568
G distribución gamma 174
recolección de basura 246
Método de Gauss-Seidel 628
estructura general 92 optimización
general del sistema 106–7 sistemas multiestado
generalizados k-out-of-n, equivalencia y dualidad en 15–17 sistemas
generalizados multiestado k-out-of-n:G modelo 11 propiedades de
13–15
modelo de proceso de Poisson no homogéneo generalizado 289 proceso
de renovación generalizado 219 modelos de costos de riesgo generalizados
295–6 algoritmos genéticos (GA) 62, 73–5 estimador de media geométrica
188–9
Lema de Glivenko-Cantelli 250 Método
de la métrica de preguntas y objetivos (GQM) 582
Prueba de bondad de ajuste 282 Modelo gráfico 57
Distribución exponencial bivariada de Gumbel 153
Fallas graves 247
reinicio de hardware 246
redundancia de hardware 613
modelo de sistema de codiseño de software de hardware
242–3 función de riesgo 353, 428 tasa de riesgo 214,
226, 237, 240 modelo heterogéneo 507 caso no
paramétrico 499–501 caso paramétrico 501–3 heurística
algoritmo 94, 100 enfoque de solución heurística 99–
102 modelado de Markov oculto 271–2
Reactor de haz de alto flujo 550
Teoría U-estática de Hoeffding 192
Prueba de Hollander-Park-Proschan (HPP) 190–2, 223 modelo
homogéneo con recuperación 496–8 proceso de Poisson
homogéneo (HPP) 217, 323
Estimador de Horvitz-Thompson 503, 508
estándares de ingeniería humana 529 error humano
530–1 tipos 531 confiabilidad humana 529–41
métodos de análisis 531–5
estrés humano-eficacia del desempeño 530–1 falta de
confiabilidad humana fuentes de datos 535, 536
I depuración imperfecta 225–6
modelo de depuración imperfecta, diagrama de transición de
estado 271 probabilidad de depuración imperfecta 271–4
ilustración numérica 273-4 mantenimiento imperfecto 318,
398 investigación futura 411–12 modelos 405–8 resultados 404–
11 métodos de tratamiento 399–404 preventivo imperfecto
mantenimiento 340-2, 381–4 con probabilidad 383 reparación
imperfecta 330–5, 398
intercalado con un perfecto mantenimiento preventivo 339–40
medidas de importancia, sistemas multiestado 68–72 factor de
mejora 401 parámetro de mejora 331 distribución promedio de
la tasa de falla creciente (IFRA) 182 tasas de falla creciente
(IFR) 147, 166, 169, 249, 410 vida residual media creciente y luego
decreciente (IDMRL) 170 vidas independientes e idénticamente
distribuidas (iid) 483 pares de fallas independientes 599 Índice de confiabilidad
(IOR) 514 Programa de examen de planta individual 554 desigualdad sin
suposición de envejecimiento 147 sistema de medición de información 643
redundancia de información 613, 614 procesos gamma no homogéneos 331–
3 teorema de innovación 501 inspección modelos 361–3 políticas de
inspección 367, 385–90 inspección estándar 386–7 sistema de almacenamiento
388–90 con mantenimiento preventivo 387–8 tasa instantánea de ocurrencia
de fallas (ROCOF) 319,
343
disponibilidad instantánea de software 238–40 enfoque
de programación entera 94 función de intensidad 267,
269, 324, 345, 502 requisitos de interfaz 568 tiempo
entre fallas 215
Asociación Internacional para la Evaluación y Gestión Probabilística de la
Seguridad 543
Comisión Electrotécnica Internacional (IEC) 560
estándares de confiabilidad 559
interrelaciones, resumen de 145 disponibilidad
de intervalo 643 estimación de intervalo 224
confiabilidad de intervalo 379–80 sistemas
invariantes consecutivos 41 sistemas
invariantes de 2 consecutivos 41–2 sistemas
invariantes de k consecutivos 42–3 sistemas
invariantes de k consecutivos 43
ISO 9000 569
ISO 9001 569, 571, 581–2
ISO 9003 569
ISO 9004-2 569
ventanas aisladas 52
Machine Translated by Google

Índice 657

j Gestión de control de pérdidas (LCM) 564 función

JAVA 282–3 de pérdida 225 expectativa de pérdida de energía
Modelo de deeutrofización de Jelinski-Moranda 219 aplicación (LOEE) 516, 518, 527 expectativa de pérdida de carga (LOLE)
161-2 con un punto de cambio 159-60 516, 518, 527 límites de confianza inferiores (LCB) 437

METRO

K k-de-n sistemas 27–32 LO SIENTO 548

mantenimiento imperfecto óptimo 409– Modelo 577 de McCall
11 k-de-n:F sistemas 6–8 k-de-n:G MACCS código 549
sistemas 5–8 k-ventana 48
subsistema de producción principal (MPS) 83, 85–7
mantenibilidad 569
Estimador de Kaplan-Meier (KME) 195, 425, 450, 480–2
mantenimiento
Gama bivariada 150 de Kibble
y política óptima 367–95 y garantía
Prueba de Kolmogorov-Smirnov 261
305–16
Kolmogrov distancia 162
investigación futura 314–15
revisión de la literatura 310
descripción general 309–10
tasa de costo de mantenimiento
L 405 factor de mantenimiento 238
LA prueba 328 modelos de mantenimiento 317–48
Transformada de Laplace 503 problema de programación de mantenimiento 401
Lawless–Thiagarajah modelos 333–4 Distribución Makeham 174, 191
LCEM 450–1 Premio Nacional de Calidad Malcolm Baldrige 560 Distribución
definición 444 marginal de toda la vida 463–6
método de mínimos cuadrados 224 Cadena de Markov 6, 40–1, 49, 50, 54, 55
Clases de distribución Sistemas empotrables de cadena de Markov 6
de vida del Informe Lewis 545 Método de Markov 534–5, 538–9
caracterizado por vida útil residual media (MRL) 170–1 propiedades Markov modelo 222, 592
de conservación de 185 modelo de distribución de vida 57 distribuciones Proceso de Poisson modulado por Markov (MMPP) 222, 228 Intensidad
de vida 166, 181–2 aplicaciones 172–3 ordenamiento parcial de 171–3 estocástica 223
funciones de probabilidad 160, 161, 218, 224, 268, 278, 446, 452, Proceso regenerativo de Markov (MRGP) 252
Red de Petri estocástica regenerativa de Markov modelo 247
Mars Climate Orbiter 201 residuales
martingala 490 proximidad máxima
459, 502, 503 del rendimiento esperado del sistema 80 disponibilidad máxima del
razón de probabilidad 459 sistema 80 maximización de la efectividad del sistema 92 maximización
política de límite de costo individual y total (LITC) 312 política de de ganancias 26–7 estimación de máxima verosimilitud (MLE) 160–1,
límite de costo individual (LIC) 311–12 política de límite de costo 224, 225,
total (LTC) 311 algoritmo de reemplazo de componentes lineales 46
sistema de red lineal de 2 consecutivos 53–4 Sistema de red lineal 230–1, 269, 278, 292, 330, 332, 334–6, 340–2, 346, 431, 435–8,
de k consecutivos 54–7 Distribución lineal de la tasa de fallas 174, 447, 451, 502, 508, 602, 606–7 tensión máxima 437
191 Sistema lineal de k consecutivos ponderados de n 47 Sistemas
conectados linealmente 6 número medio de fallos de software restantes/casos de prueba 268 vida residual
media (MRL), clases de vida caracterizadas por 170–1 error cuadrático medio
(MSE) 438 tiempo medio entre fallos (MTBF), acumulativo e instantáneo
Littlewood modelo 502 con un 279–80 tiempo medio entre fallos de software (MTBSF) 235 tiempo medio hasta
punto de cambio 160 carga-acarreo- el fallo (MTTF) 214, 218–19, 421, 425, 442, 446, 614, 618 tiempo medio hasta
descarga LHD17 máquina 327 el error humano (MTTHE) 534–5 función de valor medio (MVF) 290,
LOC (número de líneas de código) 576 log- 599–600 , 604, 605, 607, 608 fiabilidad mecánica 317–48 esfuerzos mecánicos
verosimilitud 435 función log-verosimilitud 160, 416
161, 224, 278, 292, 447, 608 estadísticas de relación log-verosimilitud
338 intensidad log-lineal 333 proceso log-lineal (LLP) 325– 6, 345
renovación log-lineal de Weibull (LLWR) 333-4 razón de verosimilitud
precuencial logarítmica 162

Enmiendas de dispositivos médicos (1976) 536, 537

LOLP 518 categorías de dispositivos médicos IIII 537 retiradas de
costo de mantenimiento esperado a largo plazo por unidad de tiempo 405–8 dispositivos médicos y clasificación de equipos 536–7
Machine Translated by Google
658 Índice
confiabilidad de dispositivos médicos 529–
41 herramientas de aseguramiento
537–9 fuentes de datos 539 pautas
para ingenieros 539–40 hechos y cifras
relacionados 535–6 confiabilidad de
equipos médicos, método general 538 MELCOR 548
METFAC-2.1 615, 616, 622, 623 métricas con respecto a primer
fallo 214–15 datos de resistencia del microcompuesto 437–8
Microsoft Excel 453–4 MIL-HDBK-217E 614 MIL-STD 721B 398
conjunto de corte mínimo 4, 5–6 vector de corte mínimo 4
mantenimiento mínimo 318, 398 conjunto de recorrido mínimo
4 , 5–6 vector de ruta mínimo 4 reparación mínima 321–30, 398
modelo combinado 359–61 intercalado con mantenimiento
preventivo imperfecto 340 intercalado con mantenimiento
preventivo perfecto 338–9 sin mantenimiento preventivo 336–8
estado mínimo autómata 51 minimización del costo del sistema
29– 32, 92 optimización de sistemas paralelos de series mixtas
102–6 tasa de falla de la mezcla, que tiende asintóticamente a
cero 134 modelización de la tasa de falla de la mezcla modelo
aditivo 133 definiciones y características condicionales 132–
3 ejemplos 135–6 problema inverso 136–8 multiplicativo modelo 133–5
mezclas de tasa de falla decreciente (DFR) 132 selección de modelo
491 modificabilidad 569 Índice de restricción de energía de potencia a
granel modificado 519 algoritmo de reemplazo de componente circular
modificado 47 política de mantenimiento preventivo modificada 384–5
probabilidad logarítmica de dos parámetros modificada 335 proceso
gamma modulado 332 PLP modulado (MPLP) 332–3 módulo, concepto
de 222 tendencia monótona con tiempo de operación 323–7 Métodos de
la cadena de Markov de Monte Carlo (MCMC) 225 Simulación de Monte
Carlo 62, 505, 527 Distribución exponencial bivariada de Moran–
Downton 149 problemas multidimensionales 111 –13 modelos multitarifa
57 sistema coherente multiestado 13, 14 sistemas k-out-of-n multiestado
3–17 sistema k-out-of-n:F multiestado 15 teoría de la fiabilidad
multiestado, pertinente conceptos 8–10 sistema multiestado (MSS) basado
en la capacidad 76, 80 definición 62 función de la demanda 71 importancia
del análisis de sensibilidad 68–72 OPD 65, 67 optimización, problemas
varios 87–9 análisis de confiabilidad y optimización 61–90 índices de
confiabilidad 63, 68
evaluación de índices de confiabilidad basada en la función generadora
universal (UGF) 64–7 medidas de confiabilidad 63–4 índices de
sensibilidad 70, 71 problemas de optimización de estructuras 72–89
medidas de desempeño del sistema 69 con requisitos de recursos fijos
y fuentes no confiables,
optimización de la estructura 83
con dos modos de falla, optimización de estructura 77–83 precisión
de disponibilidad múltiple de aproximación de reparación rápida 126–7
no más de N demandas no atendidas 129–30 disponibilidad múltiple
ordinaria 125–6 enunciado del problema 124–5 redundancia de
tiempo 130–1 dos no -demandas atendidas fila 127–9
Restricciones de opción múltiple 107–13
Modos de falla múltiples 19–36 Regla múltiple
(p, q) 404 Prueba de vida acelerada de
esfuerzo escalonado de pasos múltiples 441–55 Modelos de daño
multiplicativo 434–5 Prueba de vida acelerada de esfuerzo
escalonado monitoreada continuamente, censurada por
multiplicación 450–1 concepto de reparación imperfecta
multivariante 403–4
Musa–Okumoto modelo 221
norte
Redundancia modular N (RMN) 32
Programación de versión N (NVP) 585, 586
correlación de fallas 590–1 modelado 588–94
Modelo NHPP 595–602
suposiciones 597–9
estimación de parámetros 602
análisis y modelado de confiabilidad 591–4
modificaciones de confiabilidad para 604–6
crecimiento de la confiabilidad del software 602–
10 aplicaciones de modelos 602–10
fiabilidad del sistema 601–2
NAFIRS 513
NBU-t0 alternativas
pruebas con datos completos 189–90
pruebas con datos incompletos 195–6
Elementos de contorno NBU-t0 182–4
NBU-t0 distribución de vida 181–97
caracterización de 182–6 estimación
186–9
propiedades de conservación bajo operaciones de confiabilidad 184–6
pruebas para 189–96
NCLOC (solo líneas no comentadas) 576 política de
inspección casi óptima de Kaio y Osaki (política
K&O) 362 de Munford y Shahani (política M&S)
363 de Nakagawa y Yasui (política N&Y) 363
envejecimiento negativo 165 dependencia de cuadrante
negativo 153
Estimador de Nelson-Alschuler (NA) 481
sistemas de red 53–7 redes neuronales (NN)
229 nuevo mejor que usado (NBU) 181
Machine Translated by Google

Índice 659

nuevo mejor que usado en expectativa (NBUE) 181
nuevo mejor que peor que usado en expectativa
171
Nuevo Acuerdo Comercial de Energía (NETA) 518
nuevo peor que mejor que usado en expectativa
(NWBUE) 171
Algoritmo de Newton-Raphson 338
Método de Newton-Raphson 425
NHCTMC, diagrama de transición de estado 253
NHP 336, 337, 338, 340
NHPP modelo 297
Programación en versión N (NVP), suposiciones 597–9 curva
en forma de s 226
Formulaciones del modelo NHPP 599–601
Modelos NHPP 219, 224, 274, 289
evaluación 293–4
NHPP (proceso de Poisson no homogéneo) 579
Modelos de confiabilidad del software NHPP
596 Modelo de proceso de Poisson no homogéneo 220–
1 Proceso de Poisson no homogéneo (NHPP) 218, 324, 325, 327,
329, 331, 593 Incorporación de información de covariables
329 Formulación de modelos de proceso de Poisson no
homogéneo (NHPP) 594 –5
Programación en versión N (NVP) 595–602
Estimadores no paramétricos, ejemplos 481–3
Modelos no paramétricos 417, 480 Modelos de
riesgos no proporcionales 490–1 Problema de
minimización de costos (NCP) no en serie 93
Maximización de la confiabilidad del sistema no en serie problema
(PRN) 92–3
Consejo de Fiabilidad Eléctrica de América del Norte (NERC) 513
NQD 147
Comisión Reguladora Nuclear (NRC) 549, 555
NUREG-1150 547
NUREG-2300 553
NUREG/CR-2815 553
NVP SRGM
dependiente 603–10
independiente 603
Miembros
de contorno NWU-t0 182–4
distribución de vida, propiedades de conservación bajo
operaciones de confiabilidad 184–6
óptimo bajo 448
programa óptimo de rejuvenecimiento de software 250,
251 enfoques de solución óptima 95 problema de
optimización 24–5 técnica de optimización 73–5 plan de
prueba óptimo 463, 467–8
OR gate 532
pedir modelos 356–61
distribución de rendimiento de salida (OPD) 65, 67, 85–7
P
redundancia en paralelo 146
sistema en serie en paralelo 22–5
reducción en etapas en paralelo 103
sistema en paralelo 21–2 dependencia
positiva 146–7 unidades en paralelo
92 parámetros de elementos disponibles
81 modelos paramétricos 417 modelos
paramétricos basados en estadísticas 418–19
parcial Importancia de Birnbaum 45 parcial método de
enumeración 95–6 ordenamiento parcial de las
distribuciones de vida 171–3 vector de ruta 4
PDF 431, 434
mantenimiento perfecto 318, 320–1, 398
mantenimiento preventivo perfecto 338–40
reparación perfecta 398
sin mantenimiento preventivo 336–8
sistema perfecto 644
fórmula de aproximación 651
concepto basado en el desempeño
554 degradación del desempeño 247
reemplazo periódico 371–modelo
basado en 3 fases, Gaffney y Davis 203 modelos
basados en física experimental 417 modelos
basados en física estadística 417
método PIM 292
Eficiencias relativas asintóticas de Pitman de Tk 192–
Disponibilidad de 3 puntos 643 estimación de punto 224
proceso de punto 215 véase también proceso de punto
autoexcitante (SEPP)

Veneno modelo 205

Proceso de Poisson 321
O
precio de entrada del pool (PIP)
diseño orientado a objetos, herramienta de administración de 518 población 267 portabilidad
confiabilidad de software 281–2 lenguajes de programación
568 envejecimiento positivo
orientados a objetos 574 165 dependencia positiva 142–
ODA 628–9 5 condiciones básicas 143
problemas unidimensionales 108–11 órdenes 153–4 sistema
OOA/OOD 573 paralelo 146–7 cuestiones
falla en modo abierto 19–21, 80, 81, 83 relacionadas 152–3 rigor
requisitos operativos 644 estados relativo de las condiciones
opuestos 7 reemplazo óptimo de básicas 143–4
componentes 45–7 tiempo de retención dependencia de cuadrante positivo (PQD) 145–7
óptimo con estrés bajo 448 mantenimiento aplicaciones 146 distribuciones bivariadas 146–
imperfecto óptimo sistemas k de n 409–11 52 con estructuras más complicadas 149 con
modelos 397–414 estructuras simples 148–9
Machine Translated by Google

660 Índice

dependencia del cuadrante positivo (PQD)–cont. R

distribuciones uniformes bivariadas 150–2 definición
145 en expectativa (PQDE) 144 estimador sesgado
positivamente 188 distribuciones correlacionadas
positivamente 145 distribución posterior 225 pérdida
esperada posterior 225 ley de potencia modelo acelerado
de Birnbaum-Saunders 432 proceso de ley de potencia
(PLP) 324–5, 333 , 337, 344–5 ley de potencia–
renovación de Weibull (PL–WR) 333–4 modelo de ciclo de vida de
desarrollo predictivo, Dalal y Ho 203–5 concepto prescriptivo 554
propiedades de conservación de clases de distribución de vida 185
mantenimiento preventivo 310, 342–3, 397, 398
RAID 622–5, 632–5, 638 entornos
de campo aleatorio 296–300 disponibilidad de
solicitud aleatoria 643–52 aproximación 650–2
definición 644–5 suposiciones matemáticas
645 expresión matemática 645–7 resultados
de simulación 647–51 descripción del sistema
644–5 sistema parámetros 647 tareas
aleatorias llegadas 644 variables aleatorias
144–5, 224, 237, 478–9 tasa de ocurrencia de
fallas (ROCOF) 215, 319, 343, 492 relación
de riesgo 171

y garantía 312–13 modelos RBTS 515–16

de mantenimiento preventivo 349–66 políticas de índices de adecuación del punto de carga
mantenimiento preventivo 367, 378–85 confiabilidad de 519 índices de confiabilidad del punto de
intervalo 379–80 sistema de una unidad 378–80 sistema carga 522 índices de adecuación del bus anuales
de dos unidades 380–1 modificados 521 datos de carga de siete pasos 518
diagrama de una sola línea 516, 517 índices del sistema
Ley Price-Anderson 544 garantías para sistemas de distribución 520
prorrateadas (PRW) 307, 311, 312, 313 concepto probabilístico Estudio de seguridad del reactor 544,
554 métodos probabilísticos 511 evaluación probabilística del 545 memoria real libre 258 aplicación
desempeño (PPA) 550 evaluación probabilística del riesgo del sistema de control en tiempo real
(PRA) 543–57 aplicaciones 553–4 comentarios históricos 544 289 datos 286

sistema de monitoreo en tiempo real, aplicación 292–3

enfoque de recaptura ver métodos de captura-recaptura bloque de
Nivel 1 546–8 recuperación (RB) 585–7 algoritmos recursivos 6 enfoque de
Nivel 2 547, 548, 553 ecuación recursiva 39–40 mantenimiento de edad reducida 383–4
Nivel 3 547–9 método de reducción 404 gráfico de orden de reducción 104
metodología 546–9 modelo de redundancia 57 optimización de redundancia 34
perspectiva 555 descripción unidades redundantes 92 coeficientes de regresión 228 reinicializar
general 543–4 impacto estructuras de datos internas 246
público 550–3 medidas de
riesgo 550–3 función de
densidad de probabilidad 459 método del
árbol de probabilidad 531 variables de
probabilidad 478–9 tamaño de la tabla de
proceso 258 problema de maximización de RELACS 518
ganancias 23–4 edad proporcional reducción envejecimiento relativo
(PAR) modelos 330–1, 334, 335, 172 condición de relevancia 4
339 confiabilidad, cálculo de 39–41
modelo de riesgos proporcionales (PHM) 228, 289, 424, 480, 486–8 extensiones Mantenimiento centrado en la confiabilidad (RCM) 564
426–8 clases de confiabilidad, definiciones 167–9 datos de
parcelas residuales 489–90 confiabilidad 475–8 análisis de datos de confiabilidad 475–
modelo de intensidad proporcional (PIM) 291, 330 proceso 92 evaluación de confiabilidad 33–4 funciones de
de Poisson de intensidad proporcional 329 modelo de confiabilidad 228, 422, 424, 427, 481, 483, 488 crecimiento
variación de intensidad proporcional 334 creación de de la confiabilidad 343–6 suposiciones de modelos de crecimiento de
prototipos 574 confiabilidad 206 precaución al usar 207 para pruebas y uso operativo
205–7 cuándo dejar de probar 208–9 con covariables 207–8
programas de mejora de confiabilidad 579 medida de confiabilidad
429, 614 requisitos de confiabilidad 568 estudios de eliminación
509

Garantía de calidad Q 582

Despliegue de la función de calidad (QFD) 562, 564, 582
Quality House 562, 564 aspectos
de medición de la calidad 577 método
cuasi-Bayes 344 proceso de cuasi-
renovación 404–8
Reneau–Semaniego estimator 186–8
Machine Translated by Google

Índice 661

densidad de renovación SHARPE 261, 615

405 función de renovación 405,
406 proceso de renovación 320
teoría de la recompensa de
renovación 407 acción de reparación
309–10 impacto específico de la
reparación 339 políticas de reemplazo
367–95 reemplazos con descuento 373–4
subsistemas generadores de recursos (RGS) 83, 85, 97 fuga
de recursos 245 tasa de restauración 237 recompensado CTMC
615–19, 640
Sistema RGS-MPS 84
Conjunto de esquina derecha creciente (RCSI)
145 Análisis de riesgo 562
Regulación informada sobre el riesgo y basada en el desempeño 549,
553 percepción del riesgo 555 empresa relacionada con el riesgo 555
sistema r(k)-out-of-k 644, 651 aproximación 652
regresión robusta ponderada localmente 258
política de reemplazo del modelo de choque 376–
7 falla de modo corto 19, 20 modelo simple
multiestado k-out-of-n:G 10 estudios de simulación
505–8
Desigualdad de Slepian 150
estimaciones de pendientes
26 suavizado 258
Herramienta de monitoreo de recursos distribuidos basada en SNMP 257,
260 fallas leves 247 antigüedad del software 245 medidas de disponibilidad
del software, suposiciones 236–9 modelado de disponibilidad del software
dos tipos de fallas 239–40 dos tipos de restauración 240 teoría de la
disponibilidad del software 235–44
Modelo de madurez de capacidad de software (CMM) 202, 581–2
Gestión de configuración de software 582 Modelos de depuración de
software 592–3 Velocidad de depuración de software, características
no lineales 277 Ciclo de vida de desarrollo de software 297 Proceso de
desarrollo de software 574–5 Gestión de ingeniería de software 567–84
Modelos de esfuerzo y costo 579 –80 práctica de ingeniería de software
571–7 falla de software 201f falla de software, dos tipos 239–40 tasa de
falla de software por falla 579 tolerancia a fallas de software ver

S modelo de ganancia de software de tolerancia a fallas 298 ciclo de vida

de software 288, 571–4 fases 288 gestión del ciclo de vida de software
Ley de Dispositivos Médicos Seguros (SMDA)
(SLIM) modelo 580 medidas de software 575–7 métricas de software
536 gestión de seguridad 559, 560 requisitos
227
de seguridad 569 investigación de seguridad
555 estimador de cobertura de muestra 506,
507
SAS PROC PHREG 425
AHORRE 622
Residuos de Schoenfeld 489
sistemas de puntuación 644–5, 651
aproximación 652 prueba de
Kendall estacional 358 requisitos Evaluación de productos de software: características de calidad y
Directrices para su uso 577 plan de
de seguridad 568 enfoque de falla
sembrada 495, 506 sin recuperación gestión de proyectos de software (SPMP) 582 calidad del
498–9 software 567–9 aseguramiento de la calidad del software
569–71 modelos de calidad del software 577–80 programa
proceso de punto de autoexcitación (SEPP) 214, 216–19
de calidad del software 569 redundancia del software 613
Memoria 0 218–19 Memoria 1 219, 221 Memoria 2 221
rejuvenecimiento del software 245–63 suposiciones 248
Estadísticas de conteo 218 Redundancia de autopurga
modelo de cadena de Markov de tiempo continuo 246
32 Modelo de recompensa semi-Markov 260, 261
modelo detallado 247 intervalo 248 estimación basada en
Procesos de recompensa semi-Markov 247 modelos
mediciones 257–62 modelado, aplicaciones de facturación
semiparamétricos 480 análisis de sensibilidad, sistemas
de telecomunicaciones 247–51 estimación basada en
multiestado 68–72 índices de sensibilidad, MSS 70, 71
procedimiento secuencial 495, 504, 507, 508 serie–paralelo modelos 246–57 estimación basada en tiempo y carga
de trabajo 258, 260–2 sistema de software basado en
MSS 70, 76 estructura del sistema de conmutación en
transacciones 251–4 uso de término 246 confiabilidad del
serie–paralelo 79 sistema en serie–paralelo 25–7, 92 con
software 572
medida de desempeño basada en capacidad, optimización
de estructura de estructuras de serie 75–7, optimización de
confiabilidad combinatoria 95–102 sistema de serie 20–1,
92 problema de minimización de costos (SCP) 93 problema
de maximización de confiabilidad (SRP) 92 contratos de
servicio 313–14
medidas de evaluación 279–80
definición 202 predicción temprana
226–7 ingeniería de confiabilidad del
software (SRE) 285–302, 577–9 enfoque básico 578 introducción a
una organización 578 selección de modelo 579
Machine Translated by Google
662 Índice
ingeniería de confiabilidad del software (SRE)–cont.
descripción general 213 actividades de investigación
285 crecimiento de la confiabilidad del software 271–2
programación de versión N (NVP) 602–10 modelos de
crecimiento de la confiabilidad del software (SRGM)
235, 237, 593 administración de la confiabilidad del software 265–84
herramienta de administración de la confiabilidad del software 280–3
definición de requisitos de especificación 280–1 diseño
orientado a objetos 281–2 estructura 281
modelos/modelado de confiabilidad del software 201–11, 213–34, 288–9,
578–9
desafíos 209–10
clasificación 219–22 seguridad
del software, definición 243 estructura del
software 577 herramienta de gestión de
pruebas de software 282–3 evaluación del progreso de
las pruebas de software 269–70 ilustraciones numéricas 270
distribución del tiempo de permanencia 261, 271–2
reducción del espacio de solución 112 exclusión de partes
específicas ( política SPE) 311
ESPECIA 571
S-PLP 327–8
errores estándar 483
redundancia en espera 32
unidades en espera 92 distribución
de estado 9 probabilidades de
ocupación de estado 237 espacio de estado
239–41, 243 diagrama de espacio de estado
535 diagrama de transición de estado 237–8,
240, 253, 617
CTMC 248, 626, 632 modelo
de depuración imperfecta 271
NHCTMC 253
modelado de disponibilidad de software 238
con rendimiento de cálculo 242 con dos tipos de
falla 239 con dos tipos de restauración 241
modelos estáticos 203–5, 215 análisis de datos
estadísticos 468 métodos estadísticos, principios 479–
80 modelos basados en estadísticas 417, 418
disponibilidad de estado estacionario 643 sistema de
estado estacionario disponibilidad 252 modelos de
intensidad de paso 343 prueba de vida acelerada de
tensión de paso (SSALT) 441, 457–69 análisis 444
análisis de datos 450–3 cuatro pasos 450 literatura que
trata el problema de planificación 442 m-paso 448–9 pasos múltiples
443, 449 , 450, 453 diseño óptimo 443, 446 lectura de datos 451–3
forma más simple 442 patrón de estrés 442 tres pasos 442, 448,
449 dos pasos 442, 446, 448, 452 prueba de vida útil de esfuerzo
con cambio de esfuerzo constante 457–63
con tiempos de cambio de estrés aleatorios 463–8
patrón de estrés escalonado (SSP) 441 iteración paso a
paso 101–2, 107 envejecimiento estocástico 165–80
pruebas de 173–7
dependencia estocástica 141–56 conceptos
de 142
intensidad estocástica 216, 217, 223 proceso
de conteo 228 modelado estocástico 92
conceptos básicos 214–15 procesos de
puntos estocásticos 318–20 modelo de
recompensa neta estocástica (SRN) 255 tiempo
de parada frente al nivel de precisión deseado 506
sistema de almacenamiento, políticas de inspección 388–90
cargas de tensión 416 –17 funciones de estructura 3, 14, 230
método de suma de producto disjunto (SDP) 5 datos de falla de
transmisión de superred 328–9 supervivencia en el proceso de
tasa de falla de plano 121–2 obstáculos fijos 119–21 obstáculos
móviles 122–4 unidimensional caso 118-19
Premio Sueco a la Calidad 560
Conjunto de datos SYS1 161
Índice de duración promedio de interrupción del sistema (SAIDI) 514,
520
Índice de frecuencia de interrupción promedio del sistema (SAIFI) 514,
520
elementos del sistema, parámetros de 70 precio
marginal del sistema (SMP) 518 minutos del
sistema (SM) 516, 519 optimización del sistema
1–118 confiabilidad del sistema 1–118
Programación de versión N (NVP) 601–2 versus
confiabilidad de versión 589 estado del sistema 644
prueba del sistema 573 sistemas con dos modos de falla
(STFM) 77–83
T
Tasa de llegada de tareas
647 Aplicaciones de facturación de telecomunicaciones, modelado de
rejuvenecimiento de software 247–51 Estrés de temperatura 425
10 CFR 50.44 553 10 CFR 50.46 553 10 CFR 50 553
programas de prueba, análisis y reparación (TAAF) 343–5
factor de aceleración térmica 422
Accidente de Three Mile Island 545–6
desempate (TB) 592 función dependiente del
tiempo 227 enfoque de dominio de tiempo 286
modelado de dominio de tiempo 589
redundancia de tiempo 130–1, 613 tiempo
hasta falla 430 administración de confiabilidad
total (TDM) 559–65 antecedentes 559– 60
Machine Translated by Google

Índice 663

elección e implementación de herramientas 563 selección de variables 491 matriz

componentes 561–4 valores fundamentales, metodologías de varianza 608

y herramientas 561 potencial de apoyo mutuo entre valores Prueba de Vaurio 328

fundamentales y metodologías 562 gestión de confiabilidad total (TQM), verificación 582

concepto de 560–1 gestión de calidad total (TQM) confiabilidad de la versión versus confiabilidad del sistema 589
método de edad virtual 402 tensiones de tensión 425

mejora continua en 581–2

Teoría de Deming 580–1 Sistema
de software basado en transacciones, esquema de rejuvenecimiento de software
251–4 En
estadísticas de bancos de transformadores
garantía y
525 eventos transitorios 545 fallas transitorias mantenimiento correctivo 311–12 y mantenimiento
245–6 probabilidad de transición 237 función 305–16
de densidad de probabilidad de transición investigación futura 314–15
276 función de distribución de probabilidad de transición 276– y mantenimiento preventivo 312–13 análisis de
7 costos 308–9 ampliado 307, 313–14 problemas
tasas de transición 638
tratados 308 revisión de la literatura 309 políticas
estadísticas de líneas de transmisión 525 306–8 categorías de productos 306 función y
atrapamiento 616, 617, 618, 627 redundancia concepto 306 servicio 309 productos usados 308
modular triple (TMR) 32 fuga de tritio 550 distribución costos de servicio de garantía 305
normal trivariada (TVN) 436 sistema bidimensional 57
procedimiento de dos pasos 506, 507 dos dentro de
consecutivos -k-out-of-n system 51–2 error de diseño tipo I
27 falla tipo I 336 falla tipo II 336

LAVADO 544

Estudio WASH-1400 547

Punto de cambio Weibull modelo 160
Distribución de Weibull 174, 423 estimación
de parámetros 451
Weibull modelo 420–2

Diagrama de probabilidad de Weibull 423

U Función u 65–8, 80
Modelo de regresión de Weibull 483, 484–6 sistema
Técnica de transformación u 76
k-de-n ponderado-consecutivo 47–8 sistemas ponderados con
Estadísticas de continuidad del servicio del Reino
tres modos de falla 34–5 enfoque de caja blanca 214 modelado de
Unido 515 incertidumbre 554
caja blanca 222–3, 229–30 sistemas de ventana 48–53
Departamento de Defensa de los Estados Unidos 535
unidades por millón (UPM) 516, 519 envejecimiento
univariante, pruebas en 175–7 clases de confiabilidad
Transformación Wong-Zakai 276 peor reparación
univariante, conceptos básicos 167–9 función generadora universal
o mantenimiento 318, 330–5, 398 peor reparación o
(UGF) 62, 72
mantenimiento 398
evaluación de índices de confiabilidad del sistema multiestado (MSS)
basada en 64–7

Sistema operativo UNIX 246, 257–8 parámetros

desconocidos, método de estimación de 268–9, 272–3,
277–9
X
Diagrama de transición de la máquina de rayos X 538
espacio de intercambio usado 258

V DE

validación 575, 582 De la prueba 328

valor de carga perdida (VOLL) 518