capítulo 61 tÉcnicas de inyecciÓn de fallas

Capítulo 61

TÉCNICAS DE INYECCIÓN DE FALLAS

1 Este trabajo ha sido financiado por la Comisión Europea a travez del proyecto ALFA TOSCA. Los documentos producidos en este proyecto tienen como objetivo permitir a los nuevos investigadores latinoamericanos la posibilidad de profundizar sus conocimientos en el area del test de sistemas digitales.

2 Capítulo 6TP PT

1. INTRODUCCIÓN

Se han propuesto muchas aproximaciones para realizar inyección de fallas, estas pueden ser definidas como la inserción deliberada de daños en un sistema funcionanate y observar su respuesta. [1]. La inyección de fallas se puede agrupar en técnicas de simulación [2], técnicas implementadas por software [3][4][5][6], y finalmente las técnicas hibridas, donde se implementan contemporaneamente aproximaciones hardware y software para optimizar el proceso de inyección.[7][8].

No son objetivo de este capítuo la enumeración ni la descripción de las aproximaciones, se trata en cambio de presenter una mirada sintética de las posibles aproximaciónes a la inyección de fallas. Por tal razón hemos decidido presentar solo una aproximación de cada una de las enunciadas en el párrafo anterior.

Antes de pasar a la descripción de las técnicas de inyección de fallas (en la sección 4) presentaremos algunos conceptos preliminares en la sección 2, y algunas suposiciones en la sección 3.

2. EL MODELO FARM

En este libro nos referimos a la inyección de fallas como un medio para validar las medidas de dependability de un sistema bajo estudio (también referido como sistema objetivo), tal sistema está constituido por una architectura de hardware y una aplicación de software.

Una buena aproximación para caracterizar la inyección de fallas es la clasificación FARM propuesta en [6]. Los atributos de la FARM son los siguientes: • F: el conjunto de fallas que serán introducidas deliberadamente en el

sistema. • A: el conjunto de trayectorias de activación que especifican el dominio

utilizado para poner el funcionamiento el sistema. • R: el conjunto de salidas que corresponden al comportamiento del

sistema. • M: el conjunto de medidas correspondientes a la dependability, obtenidas

a través de la inyección de fallas.

6TP PT. TÉCNICAS DE INYECCIÓN DE FALLAS 3

El modelo FARM puede ser mejorado incluyendo también el conjunto de cargas de trabajo (workloads) W.

Las medidas M se pueden obtener experimentalmente usando una secuencia de casos de estudio. Una campaña de inyección está compuesta por inyecciónes elementales, llamadas experimentos. Durante una campaña de inyección de fallas el dominio de entrada corresponde al conjunto de fallas F y al conjunto de activaciones A, mientras que el dominio de la salida corresponde a las lecturas R y al conjuntode medidas M.

Cada experimento se caracteriza por una falla f seleccionada del conjunto F y una trayectoria de activación a proveniente de A en una carga de trabajo w de W. Se observa el comportamiento del sistema y con base en tal observación se obtiene el resultado r. El experimento se caracteriza mediante la tripleta <f, a, r>. El conjunto de medidas M se obtiene en durante una campaña de inyección trabajando sobre los resultados R producidos por las cargas de trabajo W.

2.1 Requisitos para la inyección de fallas

El modelo FARM se puede considerer como un modelo abstracto que describe los atributos que hacen parte de una campaña de inyección de fallas, pero no tiene en cuenta el ambiente de tal campaña, (es decir, de la técnica adoptada para realizar los experimentos). El mismo modelo FARM puede ser aplicado a diferentes ténicas de inyección de fallas. Antes de presentar las técnicas descritas en este capítulo nos centraremos en los parámetros que deberían ser considerados cuando se define un ambiente de inyección de fallas: intromisión, velocidad, y costo.

2.2 Intromisión

La intromision es la diferencia entre el comportamiento del sistema objetivo y el comportamiento del mismo sistema cuando es sometido a una campaña de inyección de fallas. La intromisión puede ser causada por: • La introducción de instrucciones o módulos para soportar la inyección de

fallas: como resultado, la secuencia de los módulos e instrucciones ejecutados es diferente con respecto a aquellos del sistema objetivo cuando se aplican las mismas trayectorias de activacións a las entradas.

• Cambios en las definiciones eléctricas o lógicas del sistema objetivo, que dan como resultado una disminución en la velocidad del sistema o de algunos de sus components, esto signfica que durante la campaña de inyección de fallas el sistema muestra un comportamiento diferente desde el punto de vista temporal, llamaremos este fenómeno intromisión temporal

4 Capítulo 6TP PT

• Diferencias con respecto a la imagen de la memoria del sistema objetivo, modificada a veces introduciendo nuevo código y datos para soportar la campaña de inyección de fallas. Resulta obvio que un buen ambiente de inyección de fallas debería

minimizar la intromission, garantizando que los resultados calculados puedan ser realmente extendidos al sistema objetivo.

2.3 Velocidad

Una campaña de inyección de fallas corresponde por lo general a la repetición de una gran cantidad de experimentos de inyección, cada uno centrado en una falla y se require la ejecución de la aplicación objetivo en presencia de esa falla inyectada. Por tanto, el tiempo requerido por la campaña entera depende del número de fallas, y del tiempo requerido por cada experimento. Se adiciona también, el tiempo necesario para definir el experimento y aquel necesario para la ejecución de la aplicación en presencia de la falla.

Se puede mejorar la velocidad de una campaña de datos usando una o ambas opciones descritas a continuación:

2.3.1 Acelerando cada uno de los experimentos de inyección de fallas

La velocidad de un experimento de inyección de fallas se calcula considerando la relación entre el tiempo en medio de ejecución normal (sin inyección de fallas) y el tiempo medio transcurrido para la ejecución de un solo experimento de inyección de fallas. El incremento del tiempo transcurrido se debe a las operaciones requeridas para iniciar el experimento, al tiempo necesario para observar las salidas, para inyectar las fallas y para actualizar las medidas

2.3.2 Reduciendo el tamaño de la lista fallas

Dentro de un cierto intervalo de tiempo, el número de experimentos posibles tiene un límite, por tanto, resulta crucial el cálculo de las lista de fallas que serán consideradas durante la previsión del ambiente de inyección de fallas. Un reto es reducir el espacio de fallas asociado a los sistemas de altamente integrados, mejorando las técnicas de muestreo, y los modelos que representan a un nivel alto de abstracción, los efectos de las fallas de bajo nivel.

La lista de fallas debe representar suficientemente todo el conjunto de fallas que pueden afectar al sistema, de modo que la validez de los resultados


obtenidos no se limite únicamnete a las fallas de la lista. Desafortunadamente, incrementar el tamaño de la lista es una solución raramente viable debido a las exigencias de tiempo que limitan la duración máxima de los experimentos. En general, la meta del proceso de generación de la lista de fallas es la selección de un subconjunto representativo de fallas, cuya inyección pueda proveer la mayor cantidad de información acerca del comportamiento del sistema, al tiempo que reduce la duración de los experimentos de inyección a valores aceptables.

2.4 Costo

Un requisito general para cualquier sistema objetivo es la máxima reducción del costo del ambiente de inyección de fallas, para lograr un valor despreciable con respecto al costo del sistema que se desea validar.

Podemos considerar como costos: • El equipo de hardware y el software involucrado en el ambiente de

inyección de fallas. • El tiempo que se necesita para definir el ambiente de inyección de fallas

y adaptarlo al sistema objetivo. El primer item se relaciona estrictamente con la técnica de inyección de

fallas escogida, mientras que el segundo, implica definir un sistema tan flexible que pueda ser modificado a medida que el sistema cambia, y pueda ser usado fácilmente por los ingenieros involucrados en los experimetos.

3. SUPOSICIONES

En esta sección presentaremos las suposiciones en téminos del modelo FARM, y las opciones resaltando la organización del ambiente de inyecciónd de fallas.

3.1 Conjunto F

Es el conjunto de fallas inyectadas durante una campaña. Primero que todo, se debe seleccionar el modelo de falla, Esta opción se selecciona por lo general tomando en cuenta, por un lado la necesidad de un modelo cercano a las fallas reales y por otra lado la practicidad de uso y manejo del modelo seleccionado. Basados en estas restricciones, seleccionamos el modelo SEU/SET (ver Capítulo 1 para más detalles).

Cada falla se caracteriza por la siguiente información:

6 Capítulo 6TP PT

• Momento de la inyeccion de falla: Es el instante en el cual la falla es inyectada por primera vez en el sistema. Depende de la metodología de inyección y se puede expresar usando diferentes unidades de medida.: • Nanosegundos, en caso de inyecciones basadas en simulación. • Número de instrucciones, en caso de inyección de fallas

implementadas por software. • Número de ciclos de reloj, en caso de inyección de fallas de tipo

híbrido. • Localizacion de fallas: es el componente del sistema afectado por la falla.

Puede ser expresado como la dirección de memoria o el registro donde la SEU, o la compuerta donde la SET deben ser inyectadas.

• Máscara de falla: si el componente afectado se trata de un registro de n bits, la mascara de falla es la mascara que elige cuales bits serán afectados por la SEU. Como primer paso se efectúa un experimento libre de fallas y se utiliza

como referencia para la generación de la lista de fallas y su reducción. Este experimento se puede obtener asumiendo un ambiente determinístico, cuyo comportamiento puede ser definido cuando se le dan los estímulos de entrada.

El tamaño de la lista de fallas es un parámetro crucial para cualquier clase de experimento de inyección de fallas, porque afecta dramáticamente la confiabilidad y significado de todo el experimento. Por esta razón, la técnica presentada incluye un módulo para la restricción de la lista de fallas, que se basa en las técnicas presentadas en [9][10]. Las técnicas utilizadas para reducir la lista de fallas no afectan la precision de los resultados obtenidos durante los experimentos de inyección de fallas, simplemente busca evitar la inyección de fallas cuyo comportamiento puede ser previsto. La validez de la lista reducida está asociada al ambiente específico de inyección de fallas que sera utilizado y al conjunto de estímulos que el sistema objetivo recibirá.

Al momento de condiderar SEUs en un sistema basado en procesador, se puede remover una falla de la lista de fallas cuando esta puede ser clasificada dentro de una de las siguientes clases: • La falla afecta el código operativo de una instrucción y se convierte en

una instrucción illegal; disparando un mecanísmo de detección de error cuando se ejecuta la instrucción (mecanísmo incluido en el procesador preferiblemente).

• La falla afecta el código de una instrucción justo después de ser ejecutada por última vez, de tal modo que nunca afectará el comportamiento del sistema.

• La falla afecta una posición de memoria que contiene los datos del programa o los registros del procesador antes de un acceso de escritura o


de el último acceso de lectura; esto garantiza que no genera ningún efecto en el comportamiento del programa.

• La falla cambia repetidas veces el mismo bit del código de una instrucción.

• La falla cambia varias veces el valor de un mismo bit dentro del área de memoria de datos o de uno de los registros durante el mismo período en medio de dos accesos consecutivos a la misma posición de memoria afectada por otra falla. Las dos fallas pertenecen entonces a la misma clase equivalente y por tanto pueden ser reunidas en una falla única. Resultados obtenidos a partir de algunos programas de benchmark

muestran que se tiene una reducción promedio de la lista de fallas aplicando las tecnicas de recucción propuestas de cerca el 40% [9], considerando que la lista inicial de fallas esta compuesta por una distribución aleatoria de fallas en la memoria de datos, en la memoria de código y en los registros del procesador.

Cuando una SET afecta un componente combinatorio, o a la parte combinatoria de un componente secuencial, se puede remover el daño de la lista de fallas si el tiempo de inyección y la ubicación de la falla son tales que sus efectos no puedan alcanzar las salidas del circuito en el momento en el cual serán muestreadas.

Supongamos que T BHB sea el momento en el cual una SET se produce como efecto de una del impacto de una partícula, δ sera el peor caso de duración la duración de la SET para el tipo de particular considerado, T BS B es el momento en el que se muestrean la salidas del circuito. (determinado por un ciclo de reloj del sistema) y ∏ es el conjunto de retardos de propagación asociados a los caminos de propagación sensibles desde la salida de la compuerta afectada hasta la salida del sistema, por ejemplo, todos los caminos que, dada la configuración de ingreso del circuito, dejan un cambio en la salida de la compuerta afectada que se transmitirá a las salidas del circuito. Se considera una SET inocua, es decir cuando sus efectos no pueden alcanzar las salidas del circuito , bajo la siguiente condición:

T BH B+ δ + t < T BS B ∀ t ∈ ∏ (1)

Si la ecuación 1 se cumple significa que apenas el efecto de la SET cesa, y el valor esperado se fija en la salida de la compuerta afectada, el valor correcto tiene suficieinte tiempo para alcanzar las salidas del sistema, y será tal valor correcto a ser muestreado. Extendiendo esta ecuación se observa en [10] una tasa de compactación que varía del 83% al 95%.

8 Capítulo 6TP PT

3.2 Conjunto A

Hay dos hechos importantes relacionados con este punto. Por una parte es importante entender como determinar una trayectoria de ingreso para ser aplicada al sistema bajo estudio durante cada experimento de inyección de fallas. Se han hecho muchas propuestas para resolver este problema. En este libro no trataremos este problema, nos limitaremos a las técnicas para realizar una campaña de inyección de fallas, una vez conocida tal trayectoria. Por otra parte tenemos el problema de cómo aplicar prácticamente la trayectoria al sistema. Este hecho es particularmente crítico cuando se consideran systemas embedded dado que usualmente poseen un número alto de ingresos de diferente tipo (digital, análogo, baja frecuencia, alta frecuencia, etc.).

3.3 Conjunto R

Este conjunto de información se obtiene observando el comportamiento del sistema durante cada experimento de inyección de fallas, observando el comportamiento del sistema e identificando las diferencias con respecto al comportamiento libre de fallas. Notar, que las operaciones relacionadas con la tarea de observación deberían ser mínimamente invasivas.

3.4 Conjunto M

Al final de la campaña de inyección, una herramienta adecuada debería construir un reporte relacionado con las medidas de dependability y el cubrimiento de fallas calculado sobre toda la lista de fallas. El cubrimiento de fallas se define con respecto a los posibles efectos de las fallas que fueron introducidos en el Capítulo 2 y con respecto a lo que se presenta aquí en beneficio de la integridad de los resultados. En este capítulo nos referiremos a la siguiente clasficación.

1. Falla sin efectos. La falla no se propaga ni como un error ni como un malfuncionamiento. En este caso la falla aparece en el sistema y permanece pasiva durante un cierto tiempo, luego del cual se remueve del sistema. Como ejemplo podemos considerar una falla que afecta a la variable x utilizada por un programa. Si la primera operación que realiza el programa sobre x luego de que x ha sido afectada por una falla, es una operación de escritura, entonces se sobreescribe un valor correcto de tal modo que el sistema vuelve el estado libre de fallas.

2. Malfuncionamiento. La falla fue capaz de propagarse a través del sistema hasta alcanzar la salida.


3. Falla detectada. La falla produjo una error que fue identifcado y señalado al usuario del sistema. En este caso se informa al usuario que la tarea que desempeña el sistema ha sido afectada por una falla y por tanto el usuario puede tomar las medidas necesarias para restaurar el correcto funcionamiento del sistema. En sistemas capaces de tolerar la presencia de fallas, las medidas se podrían activar automáticamente. Los errores se detectan usando mecanísmos de detección de error, integrados al sistema y cuyo propósito es el de monitorear el comportamiento del sistema, y reportar situaciones anómalas. Cuando consideramos un sistema basado en procesador, los mecanísmos de detección de error se pueden encontrar en el procesador, o en general en los componentes de hardware que hacen parte del sistema, así como también en el software que se ejecuta. El primer caso se conoce como mecanismo de detección de errores de tipo hardware, mientras que el segundo se conoce como mecanismo de detección de errores de tipo software. Como ejemplo de mecanismo de detección de errors de tipo hardware podemos considerar la trampa para instrucción ilegal (illegal instruction trap) que se ejecuta normalmente cuando una el procesador intenta decodificar un arreglo binario desconocido proveniente de la memoria de código. Este arreglo binario desconocido puede ser el resultado de un daño que ha transformado una instrucción válida en una no válida. Como ejemplo de mecanismo de detección de errores de tipo software podemos considerar un fragmento de código que los diseñadores insertan en el programa para realizar una validación de los datos ingresados por el usuario al sistema para reportar una alerta en caso de que tales se encuentren fuera del intervalo permitido. Para refinar aún más nuestro análisis es possible identificar tres tipos de detección de error:

• Falla detectada por software. Un componente de software identificó la presencia de un error/falla y lo señaló al usuario. Como ejemplo podemos considerar un subprograma que verifica la validez de los resultados producidos por otro subprograma almacenados en la variable x con base en cierto intervalo de referencia. Si el valor de x está fuera del intervalo de referencia, el subprograma de control levanta una exepción.

• Falla detectada por Hardware. Un componente de hardware identificó la presencia error/falla y lo señaló al usuario Como ejemplo podemos considerar un controlador de paridad que hace parte de los elementos de memoria de un procesador. Si un daño cambia el contenido de uno de los elementos de memoria, el controlador identifica la violación de paridad y levanta una exepción.

10 Capítulo 6TP PT

• Falla detectado por time-out. La falla obliga al sistema a entrar en un ciclo infinito, durante el cual no vienen generados datos de salida. Como ejemplo, la ocurrencia de esta falla, puede ser detectada usando un temporizador watchdog que comienza a trabajar apenas inician las operaciones del sistema, el temporizador expira antes de que el sistema pueda producir algún resultado.

4. Falla latente. La falla puede permanecer pasiva en el sistema o puede volverse activa, pero no alcanza jamás las salidas del sistema, por tanto es imposible provocar malfuncionamientos. Como ejemplo podemos considerar un daño que modifica una variable x luego de haberla utilizado. En este caso x contiene un valor errado, pero dado que el programa no usará más la variable x, el daño es incapaz de volverse activo y de alcanzar las salidas del sistema.

5. Fallas corregidas. La falla produce un error que el sistema es capaz de identificar y corregir sin la interverción del usuario..

4. LOS AMBIENTES DE INYECCIÓN DE FALLAS

Esta sección describe tres ambientes de inyección de fallas que desarrollamos en años anteriores. En la sección 4.1 describimos el ambiente basado en simulación, en la sección 4.2 un ambiente de inyección de fallas implementado por software, y en la sección 4.3 resumimos un ambiente híbrido.

4.1 Ambiente de inyección de fallas basado en simulación

Este tipo de inyección de fallas consiste en la evaluación del comportamiento del sistema, el cual es codificado en un lenguaje de descripción, a través de instrumentos de simulación. La inyección de fallas se puede implementar de tres maneras distintas: • La herramienta de simulación está enriquecida no solo con algoritmos

que permiten la evaluación del sistema libre de fallas, como sucede normalmente los simuladores en VHDL o Verilog, sino también permite evaluar el comportamiento con fallas. Esta solución es muy popular cuando se consideran algunos modelos, por ejemplo, existen herramientas comerciales que permiten la evaluación de daños permanentes como los “atascos” o los retardos [11]. En contraste, no es muy amplio el soporte para modelos de daño como las SET o las SEU,


por tanto los diseñadores se basan en herramientas de prototipo construidas por sí mismos o provistas por las universidades.

• El modelo de los sistemas analizados se enriquece con tipos especiales de datos o de componentes, que se hacen cargo de soportar la inyección de daños. Esta aproximación es bastante popular, dado que ofrece una solución simple para la inyección de fallas que requiere poco esfuerzo de implementación, existen muchas herramientas disponibles para tal fin [12][13][14][15]. Esta solución es también popular porque permite la implementación de la inyección de fallas sin necesidad de modificar el simulador utilizado para evaluar el comportamiento del sistema. En cambio se modifica el modelo del sistema para soportar la inyección de daños.

• Se dejan intactos ambos, el modelo del sistema y la herramienta de simulación, mientras que la inyección de fallas se realiza usando comandos de simulación. Hoy en dia es común encontrar dentro del conjunto de instrucciones del simulador, commandos para forzar valores dentro del modelo [16]. Aprovechando esta caractarística es possible soportar las SEUs y las SETs, así como otro tipo de modelos. Como ejemplo de un sistema de inyección de fallas describimos la

aproximación presentada en [16], Cuya arquitectura se presenta en la Fig. T6-1 T. Los componentes principales de la aproximación son: • El modelo del sistema evaluado (codificado en VHDL) que describe las

funciones que implemanta el sistema bajo estudio. Para facilitar la descripción del sistema de inyección de fallas, se acepta cualquier nivel de abstracción (sistema, transferencia de registros, y compuertas) y cualquier dominio de representación (comportamental o estructural). Sin embargo el modelo del sistama evaluado debe incluir suficientes detalles para permitir un análisis completo y válido. Po ejemplo, si el usuario está interesado en evaluar los efectos de las SEUs (ver Capítulo 1), el modelo del sistema estudiado debería describir los elementos de memoria del sistema.

12 Capítulo 6TP PT

SimuladorVHDL

Administradorde Inyección

de Fallas

Solicitudde comandos

Respuestas

Modelo del Sistema Objetivo

TFigura 6TP PT-1. T Un ejemplo de inyección de daños basada en simulación

• El simulador VHDL que se utiliza para evaluar el comportamiento del sistema objetivo. Con este propósito sirve cualquier herramienta de simulación que soporte el lenguaje VHDL, así como también el conjunto de commandos que permiten el monitoreo/cambio de los valores de las señales y las variables durante la simulación.

• El Administrador de Inyección de Fallas, quien entrega commandos al simulador VHDL para ejecutar el análisis del sistema objetivo así como también la inyección de fallas. Dependiendo de la complejidad del modelo del sistema objetivo, de la

eficiencia del simulador VHDL adoptado, de la workstation utilizada para realizar los experimentos, así como del número de daños que deban ser inyectados, los experimentos de inyección de fallas basados en simulación pueden requeriri una gran cantidad de tiempo (muchas horas o por qué no días) para su ejecución. Con el fin de superar esta limitación, la aproximación presentada en [16] adopta muchas técnicas para minimizar el tiempo empleado en la inyección de fallas.

La aproximación está compuesta por tres pasos: • Ejecución libre de daños (Golden-run execution): Se simula el sistema

objetivo sin inyectar daños y se obtiene un archivo guia, reuniendo información del comportamiento del sistema y del estado del simulador.

• Análisis estático de los daños: Partiendo de una lista inicial de daños (Lista de Fallas) que será inyectada, y aprovechando la información


obtenida durante la Ejecución libre de daños, podemos identificar las fallas cuyos efectos sobre el sistema pueden ser determinados a priori, y las removemos de la lista de fallas. Dado que la inyección de cada falla recarga la simulación del sistema; reduciendo el número de daños inyectados se puede reducir el tiempo necesario para realizar todo el experimento.

• Análisis dinámico de fallas: Durante la inyección de fallas se compara periódicamente el estado del sistema con la ejecución libre de daños en el instate de tiempo correspondiente. La simulación se detiene en el momento en el cual el efecto de la fallas sobre el sistema se hace conocido, por ejemplo, el daño desencadena algún mecanísmo de detección, la falla desaparece del sistema o se manifiesta a sí mismo como un malfuncionamiento (ver Capítulo 1 para la clasificación de los posibles efectos de las fallas). Aunque las operaciones necesarias para comparar el estado del sistema objetivo con el de la ejecución libre de fallas representa un costo considerable, los beneficios que tal operación representa sobre el tiempo de ejecución de todo el experimento son significativos. En general, un falla tiende a manifestarse (o a desaparecer) al poco tiempo de haber sido inyectada. Como resultado, monitoreando la evolución de la falla durante algunos pocos ciclos de simulación, podríamos ser capaces de detener la ejecución de la simulación antes de finalizar el entero experimento, ahorrando cantidades significativas de tiempo. De igual modo, si la falla sigue latente luego de algunos ciclos de simulación, ella tiende a permanecer latente o a manifestarse, hasta el completamiento del experimento. En este caso, el estado del sistema objetivo y el de la ejecución libre de fallas se comparan solo hasta el final del experimeto, ahorrando tiempo de ejecución. En la siguiente sección daremos más detalles acerca de la aproximación

introducida en [16].

4.1.1 Ejecución libre de daños

El propósito de esta sección es recopilar información relacionada con el comportamiento del sistema objetivo libre de fallas. Dado un conjunto de estímulos de ingreso (la workload del sistema) que permanecerá constante durante el resto de los experimentos de inyección de daños, se reunen dos conjuntos de información, uno para realizar el análisis estático y uno para realizar el análisis dinámico de los daños.

Es análisis estático require el trace (trazado) completo de: • Accesos a los datos: cada vez que se hace un acceso a los datos se

registran, el tiempo, el tipo de acceso (lectura o escritura) y la dirección del acceso.

14 Capítulo 6TP PT

• Accesos a los registros: cada vez que se accede a un registro se registran, el nombre del registro, el tipo de acceso.

• Accesos al código: Para cada fetch de una instrucción se registra la dirección de la instrucción sobre la cual se hizo fetch. Reunimos la información necesaria en módulos adecuados escritos en

VHDL, llamados vigilantes de código/datos, insertados en el modelo. Esta aproximación no es invasiva, dado que los vigilantes de código/datos trabajan en paralelo con el sistema y no afectan su comportamiento.

Por el contrario, para realizar un análisis dinámico, detenemos periódicamente la simulación y registramos una “imagen” del estado de su estado. La imagen Está compuesta por el contenido de los registros del procesador y los datos de la memoria de datos en el momento de la simulación en el cual se registra tal imagen.

Esta aproximación es efectiva porque permite reunir información del sistema sin interferir con él. Por otra parte, direccionar un sistema muy grande, puede requerir la disponibilidad de grandes cantidades de ambos tipos de memoria y de espacio en disco, por tanto se debe definir cuidadosamente el número de imagines que serán tomadas.

4.1.2 Análisis estático de fallas

Se remueven los fallas de la lista de acuerdo a un conjuno de reglas, que se aplican analizando la información que se recopiló durante la ejecución libre de daños.

Eliminamos de la lista de fallas, aquellas que afectan a los datos si se verifica al menos una de las siguientes condiciones: • Dada una falla f que debe ser inyectada en el tiempo T en la dirección A,

se remueve f de la lista de fallas si A no se lee de nuevo después del tiempo T; esta regla permite eliminar daños que no afectan el comportamiento del sistema.

• Dada una falla f que debe ser inyectada en el tiempo T en la dirección A, se remueve f de la lista de fallas si la primera operación que involucra a A pasado el tiempo T es una operación de escritura. Por el contrario, se elimina un falla que afecta al código si se verifica la

siguiente condición: dado una falla f que debe ser inyectada en el tiempo T, y la dirección A corresponde a una instrucción sobre la cual nunca se hará fetch y por tanto su inyección es inútil.

4.1.3 Análisi dinámico de fallas

El análisis dinámico se basa en la idea de identificar lo más temprano possible los efectos de una falla inyectada durante su similación. Tan pronto


como el efecto de la falla se hace evidente, detenemos la simulación, ahorrando de manera potencial cantidades importantes de tiempo. El procedimiento de inyección que aprovechamos para implementer esta idea se describe en Fig. T6-2 T.

El proceso de inyección de fallas inicia definiendo un conjunto de breakpoints en el código VHDL del sistem para capturar las siguientes situaciones: • Complemtamiento del programa: se ubica un breakpoint de modo tal que

la simulación se detiene justo después de la de la última instrucción del programa que se ejecuta en el sistema. Este mecanísmo sirve para detener la simulación ante fallas que pueden finalizar prematuramente la simulación de la aplicación.

• Interrupción: con el fin de detectar eventos asíncronos, se colocan breakpoints dentro de las intrucciones VHDL para implementer la activación de los mecanísmos de interrupción, esto se usa seguido para implementar Mecanísmos de Detección de Error de tipo hardware y de tipo software.

• Time-out: Se inicia la simulación con un tiempo de simulación mucho mayor al tiempo requerido para la entera simulación libre de errores. Se detecta una condición de time-out si la simulación termina y se alcanza alguno de los breakpoints. Luego de definir apropiadamente todos los breakpoints, simulamos el

sistema hasta el momento de la inyección. La inyección se hace aprovechando los commandos del simulador para modificar las señales o variables de la fuente VHDL. Luego de la inyección, se simula el sistema hasta el momento que corresponde a la primera “imagen” luego del momento de la inyección. Finalmente, se compara el sistema con la ejecución libre de daños y se consideran las siguientes situaciones: • Ausencia de falla: el estado del sistema objetivo es igual al de la

ejecución libre de daños, se tienen dos alternativas posibles: 1. Cuando se inyeccta en el area de datos esto implica que los efectos del

daño desaparecen del sistema y que el daño no tiene efectos sobre el comportamiento del sistema, de modo tal que se puede detener la simulación.

2. Cuando se inyecta en el area de código, si nunca se hace fetch de nuevo sobre la instrucción errada, tenemos que los efectos del daño sobre la simunalción desaparecen y se puede detener la simulación.

• El estado del sistema objetivo no coincide con aquel observado durante la ejecución libre de daños,en este caso se consideran dos altenativas posibles: 1. Malfuncionamiento: La falla ha afectado las salidas del sistema

(causando un malfuncionamiento) y se puede detener la simulación.

16 Capítulo 6TP PT

2. Falla latente: La falla se encuentra presente en el sistema pero no afecta las salidas: se necesitarán entonces más simulaciones.

result Inject( SAMPLE *L, fault F) { set_breakpoints(); Simulate( F->time ); FlipBit( F->loc ); P = get_snapshot( L, F->time ); do { Simulate( P->time ); res = Compare( P->regs, P->mem); if( res == MATCH && F->area == DATA ) return(NO_FAILURE); if( res == MATCH && F->area == CODE ) if( F->loc is never fetched again ) return(NO_FAILURE); if( res == FAILURE ) return(FAILURE); /* res is LATENT */ P = P->next; } while( P != end ); return(LATENT); }

TFigura 6TP PT-2. T Procedimiento de Inyección de Fallas

4.1.4 Optimizaciones basadas en Checkpoint

El raciocinio sobre el cual se basa esta aproximación se presenta en Fig. T6-3 T, donde el eje horizontal presenta el tiempo de simulación del sistema, mientras que la parte inferior muestra el tiempo empleado por la CPU para ejecutar la simulación VHDL.

Dada un falla f que debe ser inyectada en el tiempo T P

SPBFB, se representa

como T Bsetup B al tiempo empleado por una herramienta de inyección de fallas sin optimizar para alcanzar el tiempo de inyección. Para minimizar el tiempo de simulación, periódicamente almacenamos el contenido de las estructuras de datos del simulador en un elenco de archivos de checkpoint. El archivo de checkpoint tomado en el instante T P

SP almacena los datos necesarios para

reiniciar la simulación desde el momento T P

SP.


fault f

system timeTS

F

fault f

system time

C0 C2C1

checkpoints

simulator CPU time

simulator CPU time

TSF

Tsetup

T”setup

TFigura 6TP PT-3. T Optimización dependiente del Simulador

Cuando se debe inyectar la falla f, reiniciamos el simulador desde el primer checkpoint anterior a T P

SPBFB (checkpoint C B2 B en el ejemplo de Fig. T6-3 T);

therefore, the CPU time spent to reach injection time becomes T P

’’PBsetup B.

Sea T BRB el tiempo de carga del contenido del archive checkpoint y del reinicio de las estructuras de datos del simulador, la siguiente desigualdad se debe mantener para que la aproximación sea válida:

setupRsetup TTT <+" (2)

El número de checkpoints debe ser tal que minimice la Eq. 2 y para que mantenga el tamaño de los archivos de checkpoint dentro de la disponibilidad de espacio de disco.

4.2 Inyección de fallas implementada por software

Como ejemplo de ambiente de inyección de fallas implementado por software describiremos el sistema FlexFI, presentado en [17], y cuya arquitectura se presenta en Fig. T6-4 T.

18 Capítulo 6TP PT

Target System Host Computer

Injector

Observer

Time-Out

Scheduler

Fault ListManager

Fault InjectionManager

ResultAnalyzer

Communic.support

Comm. line

User

TFigura 6TP PT-4. T Ambiente de inyección de daños FlexFI El sistema está compuesto a nivel lógico por los siguientes módulos:

• El Administrados de la lista de Fallas quien genera la lista de fallas que serán inyectados al sistema objetivo.

• El Administrador de Inyección de Fallas que inyecta fallas al sistema objetivo;

• El Analizador de Resultados que analiza los resultados y produce un reporte que involucra la entera campaña de inyección. Para minimizar la intromisión en el sistema objetivo, el sistema FlexFI

usa un computador host. Las tareas de inyección de fallas que no sean estrictamente necesarias para ejecutar el sistema objetivo se ubican en el computador host, quien también almacena todas las estructuras de datos (por ejemplo, la lista de daños y las estadísticas de salida) necesarias para la campaña de inyección de daños. El computador host se comunica con el sistema objetivo a través de las herramientas de depuración disponibles en muchos sistemas (por ejemplo, la linea serial manejada por un monitor ROM que permite la depuración de muchos microprocesadores).

4.2.1 Administrador de Inyección de Fallas

El administrados de Inyección de Fallas (Fault Injection Manager FIM) es la parte más importante de todo el ambiente de inyección de fallas. De hecho, es tarea del FIM iniciar la ejecución de la aplicación objetivo para cada daño de la lista generada por el Administrados de la Lista de Daños, inyectar el daño en el momento y posición requeridos y observar el


comportamiento del sistema, recuperándolo de cualquier falla posible (por ejemplo, excepciones generadas por el hardware). Presentamos el pseudocódigo del FIM en Fig. T6-5 T.

void fault_injection_manager() { campaign_initialization(); for (every fault fi in the fault list) { experiment_initialization(fi); spawn(target_application); spawn(F_I_scheduler); wait for experiment completion; update_fault_record(fi); } return(); }

TFigura 6TP PT-5. T Pseudocódigo del Administrador de Inyección de Fallas

Durante la ejecución de la aplicación objetivo, un Organizador de Inyección de Fallas monitorea el progreso del programa, disparando otros módulos encargados de inyectar la falla (Módulo Inyector), observando las variables con el fin de clasificar el comportamiento errático (Módulos Observador), o deteniendo la aplicación objetivo cuando se alcanza una condición de time-out (Módulo de Time-out).

El pseudocódigo del módulo organizador de inyección de fallas se presenta en Fig. T6-6 T. Se debe resaltar el hecho de que el Módulo Observador se refiere a una estructura de datos, que contiene la lista de puntos de observación, para cada punto, esta estructura contiene: el nombre de la variable, el momento en el cual debe se debe observar, y por supuesto el valor que debe tener en dicho instanate. La lista debe ser creada por el programador de la aplicación basado en el conocimiento que posee de la aplicación.

20 Capítulo 6TP PT

void F_I_scheduler() { instr_counter++; if (instr_counter==fault.time) trigger(injector()); for (i=0; i<num_of_observation_points; i++) if (instr_counter==observation_time[i]) trigger(observer(observed_variable[i], value[i])); if (instr_counter>max_time) trigger(time_out()); }

TFigura 6TP PT-6. T Pseudo-código del.Módulo Organizador

Con el fin de permitir al FIM el mantenimiento del control sobre la campaña de inyección, se debe prever e implementar un mecanísmo para manipular el caso en el cual se active una excepción de hardware y se interrumpa la aplicación objetivo. Los procedimientos de manejo de Exepción del sistema objetivo se deben modificar de acuerdo con este propósito, de modo tal que ellos comuniquen inicialmente al FIM el tipo de expción y le entreguen el control (en vez de a la instrucción interrumpida).

Es importante subrayar la importancia de la fase de inicialización del experimento: los efectos de un daño inyectado durante un experimento no deberían afectar el comportamiento de la aplicación objetivo cuando se realiza el siguiente experimento; por tal razón, el sistema de inyección de fallas debe restaurar el ambiente de ejecución de la aplicación objetivo como fase preliminar de cada experimento. Un modo seguro (pero lento) es restaurar la imagen completa de la memoria de la aplicación (código y datos) y los valores de las variables de sistema relevantes. El factor más importante es limitar al máximo la duración de la restauración con el fin de reducir el tiempo requerido para la campaña global de iyección.

En las siguientes secciones presentaremos diferentes técnicas para implementar estos módulos en un sistema embedded.

4.2.2 Puntos importates de la implementación

Esta solución aprovecha el modo de seguimiento (trace) disponible en muchos microprocesadores, para implementer el administrador de inyección de fallas: gracias al mecanísmo de trace, se puede activar un pequeño procedimiento (correspondiente al administrador de inyección de fallas) después de la ejecución de cada instrucción ensamblador de la aplicación con la menor intromisión en el comportamiento del sistema (aparte de la disminución de velocidad en el desempeño). La aproximación propuesta es


similar a la heramienta ProFI [5], con la gran diferencia que el experimeto de inyección de fallas se ejecuta completamente por el microprocesador sin ninguna simulación.

El procedimiento de administración de inyección de daños se encarga de contar el número de instrucciónes ejecutadas y de verificar si los módulos de inyección alcanzan o no su punto de activación. Cuando resulta apropiado, el procedimiento activa uno de los siguientes módulos, cada uno correspondiente a un procedimiento de software almacenado en el sistema objetivo: • El modulo Inyector, que se activa cuando se llega al momento de la

inyección. • El modulo Time-out, se activa cuando se alcanza el umbral predefinido

en terminos del número de instrucciones ejecutadas y detiene la aplicación objetivo, devolviendo el control al FIM ubicado en el host.

• El módulo Observador, se encarga de observar el valor de las variables de interés de la aplicación objetivo, y de revisar si la aplicación se está comportando o no en modo libre de fallas. Cuando se observan fallas, éstan son comunicadas al FIM a través de una interfase serial. El módulo observador se activa en momentos apropiados dependiendo de las características de la aplicación objetivo. Nosotros implementamos una versión software del FlexFI para una

tarjeta comercial de Motorola, la M68KIDP. Esta tarjeta usa un microprocesador M68040 con frecuencia de reloj de 25Mhz, 2 Mbytes de memoria RAM, 2 canales I/O seriales RS-232, un puerto paralelo para impresora, y un bus compatible Ethernet. Para garantizar el comportamiento determinístico se desabilitó la cache interna durante la campaña de inyección.

El Administrador de Inyección de Fallas esá compuesto por: el procedimiento organizador que alcanza al rededor de 50 líneas de código, la rutina de manipulación de Excepciones que necesita al rededor de 10 líneas de código ensamblador más que la original, y finalmente el procedimiento de inicialización que se escribre una parte en ISO-C y otra parte en lenguaje ensamblador y que globalmente alcanza 200 líneas de código. Debido a la gran modularidad del código FIM, resulta sencilla la tarea de adaptarlo a una nueva aplicación.

Cuando se ejecuta una aplicación benchmark, esta vesión de FlexFI presenta una disminución de velocidad debido a la inyección de fallas de al rededor de 25 veces.

La versión software del FlexFI es la más generál (la aproximación se puede implementar virtualmente en cualquier sistema) y no requiere ningún hardware particular, cosa que la hace muy económica.

Por otra parte esta aplicación tiene algunas desventajas:

22 Capítulo 6TP PT

• Algo de intromisión en el código, debido a la necesidad de almacenar en la memoria del sistema objetivo los procesos de organización, así como también los procedimientos Inyector, Observador, y Time-out

• Algo de intromisión en los datos, debido a que algunas estructuras de datos, tal como la de almacenamiento de información relacionada con el daño actual y los puntos de observación, deben ser almacenados en la memoria del sistema objetivo.

• El hecho de forzar al sistema objetivo a trabajar en modo trace produce una notoria degradación en la velocidad de ejecución del programa de la aplicación objetivo; cosa que desincentiva el uso de esta aproximación en sistemas embedded de tiempo real.

4.3 Inyección de daños híbrida

Presentamos el sistema FIFA como ejemplo de ambiente híbrido de inyección de daños, este se introduce en [ATS’01], y su flujo se presenta en Fig. T6-7 T. FIFA sirve para soportar las inyección de fallas en sistemas basados en procesador, es modelado completamente en lenguaje de descripción de hardware (de modo parecido al ambiente basado en simulación). La principal novedad de FIFA es la adopción de una tarjeta basada en FPGA para emular el sistema, mientras que un computador maneja las operaciones de la tarjeta.

De acuedo con el diagrama de flujo de FIFA, se utiliza una herramieta de software para implementar el modelo del sistema analizado de acuerdo con los mecanísmos que describiremos en la siguientes secciones. El modelo obtenido se sintetiza y se mapea en la tarjeta FPGA.

Se usan dos plataformas de hardware: un computador host y una tarjeta FPGA. El primero actua como maestro y se encarga de manejar las campañas de inyección de daños. El segundo actúa como esclavo y se usa para emular el sistema estudiado. En particular, FIFA aprovecha la tarjeta FPGA donde se implementan dos módulos: el sistema emulado y la interfase de inyección de daños, que le permite al computador host controlar el comportamiento del sistema emulado.


RT-level Model

Instrumenter

Synthesis Tool

Instrumented Gate-level Model

Instrumentationarchitectures

Instrumented RT-level Model

Fault List Manager

Fault InjectionManager

Emulated system

Fault InjectionInterface

FPGA board

Fault List

Workload

Output

ResultAnalyzer

Fault Classification

TFigura 6TP PT-7. T Diagrama de flujo de FIFA

Tres módulos funcionantes en el computador host se encargan de realizar las operaciones típicas del ambiente de Iyección de Daños: • Administrador de la lista de Fallas: genera la lista de daños que serán

inyectados al sistema. • Administrador de Inyección de Fallas: coordina la selección de un nuevo

daño, su inyección en el sistema y el análisis del compotamiento errado. • Analizador de Resultados: analiza el comportamiento del sistema durante

cada inyección de fallas, clasifica las fallas de acuerdo a sus efectos y produce información estadística.

4.3.1 La Interfase de Inyección de Fallas

La Interfase de Inyección de Fallas ejecuta los commandos entregados por el Administrador de Inyección de Fallas, funciona en el computador host con el fin de controlar el comportamiento del sistema emulado.

24 Capítulo 6TP PT

Para efectos de este documento, el sistema emulado es el core de un procesardor que ejecuta un programa software. La Interfase de Inyección de Fallas reconoce los siguientes comandos: • Step: Fuerza al procesador emulado a ejecutar una instrucción. • Run: Fuerza al procesador emulado a ejecutar un número dado de

instrucciones. • Evaluación: envía al computador host el contenido de un elemento de

almacenamiento del procesador. • Inyección: modifica el contenido de un elemento de almacenamiento del

procesador. • Tick: permite al procesador emulado avanzar durante un ciclo de reloj.

Los commandos Step y Run implementan una estrategia de sincronización a nivel instrucción, permitiendo tomar el control del procesador emulado luego de la ejecución de una instrucción. Por ejemplo, hasta cuando se recibe una instrucción step, la Interfase de Inyección de Fallas obliga al procesador emulado a ejecutar una instrucción y luego a esperar el siguiente comando desde el computador host. Por el contrario, el comando tick implementa una estrategia de sincronización a nivel de reloj, que permite analizar/modificar el comportamiento del procesador durante la ejecución de una instrucción.

Los commandos de Evaluación e Inyección se usan para analizar el estado del sistema y para Inyectar Fallas como se describe a continuación.

4.3.2 Inyección de Fallas

La arquitectura de un procesador incluye típicamente los siguientes módulos: un core que comprende las unidades aritméticas/lógicas y de control con los registros internos y los de control, un archivo de registros de propósito general, cache de instrucciones y datos y un Bus Externo utilizado por el core del procesador para comunicarse con sus periféricos.

Con el fin de realizar la inyección de fallas nosotros dispusimos el modelo del core del procesador como se muestra en Fig. T6-8 T, adicionando los siguientes módulos: • Lógica Stub (freno,detención) de memoria: cuando se requiere, puede

aislar la memoria del resto del sistema y verificar su funcionamiento. • Lógica Stub de bus: como en el caso anterior, este modulo se usa para

tomar el control del bus Externo del procesador, con el fin de inyectar las fallas, aplicar estímulos y observar los resultados. En particular, un registro M, con el mismo número de bits del Bus Externo, se usa para capturar el contenido del Bus Externo y enviarlo al computador host a través del Bus de Inyección de Daños. Además se usa para enmascarar el


valor del bus adicionado. En el momento de la inyección, al asignar 1 al valor de todos los bits de M se fuerza el complemento del valor del bus.

• Lógica de Enmascaramiento: Cada registro en el modulo del procesador que sea importante para el análisis de la dependability se conecta a una lógica especial de Enmascaramiento. Ella se encarga de inyectar fallas y realizar el análisis de estas. Se pueden encontrar detalles de la Lógica de Enmascaramiento en [8].

• Bus de Inyección de Daños: conecta toda la lógica de enmascaramiento. Incluye todas las señales de control para acceder a la lógica de enmascaramiento y a los módulos stub así como también las señales de datos para transportar datos desde y hacia ellos. Cada módulo de Enmascaramiento de lógica o Stub puede ser direccionado, leído y escrito a través de el Bus de Inyección de Fallas.

Processor Core

Control Registers Internal Registers

Masking logicMasking logic Masking logic

I-cache

Memory Stub logic

D-cache

Memory Stub logic

RegisterFile

Mem

ory

Stub

logi

cFault Injection Bus

Bus Stub logic

External Bus

TFigura 6TP PT-8. T Procesador típico enriquecido con los módulos de Inyección de Fallas

4.3.3 Bloques de Memoria

Los diseñadores del core adoptan usualmente una aproximación jerárquica: un módulo de memoria se describe inicialmente como una entidad aislada, acudiendo ya sea a la descripción comportamental o a

26 Capítulo 6TP PT

aquella structural, la memoria es iniciada donde se necesite. Se pueden encontrar muchos ejemplos de este estilo de diseño de Core, tal como en el PicoJava, y en el Intel 8051. La característica común entre estos módulos de memoria es la presencia de buses de datos y dirección, así como también la presencia de señales de control de lectura y escritura. Manejando estas señales podemos acceder y posiblemente alterar el contenido de la memoria.

Nosotros usamos un modulo llamado Lógiga Stub de memoria, para aislar o controlar los módulos de memoria que hacen parte del core, como se presenta en Fig. T6-9 T. A través del Bus de Inyección de Fallas, podemos tomar el control de la interfaz con la memoria y fácilmente leer y alterar su contenido.

MemoryArray

MUX

Address

Data

Read

Write

Functiona signals

Fault Injection bus

mode

TFigura 6TP PT-9.Lógica Stub de TMemoria

La inyección de fallas en los módulos de memoria se hace de acuerdo al

siguiente procedimiento: • El Administrador de Inyección de Fallas porta al sistema emulado al

instante de inyección entregando a través de la Interfaz de Inyección el número necesario de commandos de sincronización (Run/Step/Tick).

• Se lee el contenido de la posición de memoria que se pretende alterar usando el commando Evaluación y enviando tal información al Administrador de Inyección de Fallas.

• El Administrador de Inyección de Fallas calcula el valor errado que será inyectado y lo escribe usando el commando Inyección.


4.3.4 Aplicando estímulos y observando el comportamiento del sistema.

Con el fin de soportar el análisis de sistemas de seguridad crítica basados en procesador, se deberían considerar dos clases de aplicación: • Aplicaciones de cálculo intensiva: son aquellas que emplean la mayor

parte del tiempo de proceso realizando tareas intensivas de cálculo, y entregando el resultado al final del proceso. Por tanto los datos de entrada se deben entregar antes de activar el algoritmo de cálculo y la cantidad de información que debe ser observada para la clasificación de daños se encuentra predominantemente en el contenido del segmento de datos del procesador al final del cálculo.

• Aplicaciones intensivas de Entrada/Salida: ellas emplean la mayor parte del tiempo de ejecución intercambiando datos con el ambiente. Los datos de salida se producen durante la ejecución de la aplicación, por tanto, deben ser almacenados contínuamente con el fin de realizar el análisis de los efectos de los daños. Podemos citar ejemplos de este tipo de sistemas: sistemas de adquisición de datos o protocolos de comunicación. Con el fin de realizar experimentos de inyección de daños de modo

eficiente, se debe equipar la tarjeta FPGA una conexión dedicada de alta velocidad al módulo de memoria para almacenar los datos de cada experimento de inyección de entrada y de salida. Aprovechando esta solución, aceleraremos el desempeño porque que la comunicación entre la tarjeta FPGA y el computador host tiene lugar sólo al final de la Campaña de Inyección (es decir, luego de haber inyectado muchos daños) en lugar de transmitir información después de cada daño.

4.3.5 El proceso de Inyección de Fallas (FI process)

El proceso de inyección de Daños sigue estos pasos: 1. Se construye o instrumenta la descripción del circuito de acuerdo con las

transformaciones descritas precedentemente. 2. Se carga la tarjeta FPGA con la descripción instrumentada de la

descripción del sistema. 3. La RAM de entrada se programa de acuerdo con los datos de entrada que

el sistema analizado requiere. 4. El sistema basado en FPGA se usa para simular el sistema sin fallas y los

valores de salida se almacenan en cada ciclo de reloj. En la RAM de salida: el trace es aquel que será utilizado como referencia para clasificar los efectos de las fallas.

5. Para cada daño de la Lista de Fallas, el Administrados de Inyección de Fallas inicializa la FPGA y realiza el experimento de inyección. El

28 Capítulo 6TP PT

sistema modificado es llevado al momento de inyección usando los métodos descritos en las secciones anteriores. Luego de la inyección el sistema se emula hasta el completamiento del programa.

6. Al final de la entera campaña de inyección (es decir, luego de que muchas fallas han sido inyectadas), se envía el contenido de la RAM de salida al Analizador de Resultados para la clasificación de las fallas.

5. REFERENCIAS

1. J. Clark, D. Pradhan, Fault Injection: A method for Validating Computer-System Dependability, IEEE Computer, June 1995, pp. 47-56

2. T.A. Delong, B.W. Johnson, J.A. Profeta III, A Fault Injection Technique for VHDL Behavioral-Level Models, IEEE Design & Test of Computers, Winter 1996, pp. 24-33

3. J. Carreira, H. Madeira, J. Silva, Xception: Software Fault Injection and Monitoring in Processor Functional Units, DCCA-5, Conference on Dependable Computing for Critical Applications, Urbana-Champaign, USA, September 1995, pp. 135-149

4. G.A. Kanawati, N.A. Kanawati, J.A. Abraham, FERRARI: A Flexible Software-Based Fault and Error Injection System, IEEE Trans. on Computers, Vol 44, N. 2, February 1995, pp. 248-260

5. T. Lovric, Processor Fault Simulation with ProFI, European Simulation Symposium ESS95, 1995, pp. 353-357

6. J. Arlat, M. Aguera, L. Amat, Y. Crouzet, J.C. Fabre, J.-C. Laprie, E. Martins, D. Powell, Fault Injection for Dependability Validation: A Methodology and some Applications, IEEE Transactions on Software Engineering, Vol. 16, No. 2, February 1990, pp. 166-182

7. L. T. Young, R. Iyer, K. K. Goswami, A Hybrid Monitor Assisted Fault injection Experiment, Proc. DCCA-3, 1993, pp. 163-174

8. P. Civera, L. Macchiarulo, M. Rebaudengo, M. Sonza Reorda, M. Violante, “Exploiting Circuit Emulation for Fast Hardness Evaluation”, IEEE Transactions on Nuclear Science, Vol. 48, No. 6, December 2001, pp. 2210-2216

9. A. Benso, M. Rebaudengo, L. Impagliazzo, P. Marmo, “Fault List Collapsing for Fault Injection Experiments”, Annual Reliability and Maintainability Symposium, January 1998, Anaheim, California, USA, pp. 383-388

10. M. Sonza Reorda, M. Violante, “Efficient analysis of single event transients”, Journal of Systems Architecture, Elsevier Science, Amsterdam, Netherland, Vol. 50, No. 5, 2004, pp. 239-246

11. TetraMAX, www.synopsys.com 12. E. Jenn, J. Arlat, M. Rimen, J. Ohlsson, J. Karlsson, “Fault Injection into VHDL

Models: the MEFISTO Tool”, Proc. FTCS-24, 1994, pp. 66-75 13. T.A. Delong, B.W. Johnson, J.A. Profeta III, “A Fault Injection Technique for VHDL

Behavioral-Level Models”, IEEE Design & Test of Computers, Winter 1996, pp. 24-33


14. D. Gil, R. Martinez, J. V. Busquets, J. C. Baraza, P. J. Gil, “Fault Injection into VHDL Models: Experimental Validation of a Fault Tolerant Microcomputer System”, Dependable Computing EDCC-3, September 1999, pp. 191-208

15. J. Boué, P. Pétillon, Y. Crouzet, “MEFISTO-L: A VHDL-Based Fault Injection Tool for the Experimental Assessment of Fault Tolerance”, Proc. FTCS´98, 1998

16. B. Parrotta, M. Rebaudengo, M. Sonza Reorda, M. Violante, “New Techniques for Accelerating Fault Injection in VHDL descriptions”, IEEE International On-Line Test Workshop, 2000, pp. 61-66

17. A. Benso, M. Rebaudengo, M. Sonza Reorda, “Fault Injection for Embedded Microprocessor-based Systems”, Journal of Universal Computer Science (Special Issue on Dependability Evaluation and Validation), Vol. 5, No. 5, pp. 693-711

capítulo 61 tÉcnicas de inyecciÓn de fallas

Documents