Capítulo 61 TÉCNICAS DE INYECCIÓN DE FALLAS

Capítulo 6
1
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
1.
Capítulo 6TP PT
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
6TP PT. TÉCNICAS DE INYECCIÓN DE FALLAS
5
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
6TP PT. TÉCNICAS DE INYECCIÓN DE FALLAS
7
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 TH 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, TS 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:
B
B
B
TH + δ + t < TS
B
B
B
B
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
3.2
Capítulo 6TP PT
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.
6TP PT. TÉCNICAS DE INYECCIÓN DE FALLAS
9
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,
6TP PT. TÉCNICAS DE INYECCIÓN DE FALLAS
11
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. 61. 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.
T
T
12
Capítulo 6TP PT
Modelo del
Sistema
Objetivo
Simulador
VHDL
Solicitud
de comandos
Respuestas
Administrador
de Inyección
de Fallas
Figura 6TP PT-1. Un ejemplo de inyección de daños basada en simulación
T
T
• 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
6TP PT. TÉCNICAS DE INYECCIÓN DE FALLAS
13
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
6TP PT. TÉCNICAS DE INYECCIÓN DE FALLAS
15
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. 6-2.
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.
T
T
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);
}
Figura 6TP PT-2. Procedimiento de Inyección de Fallas
T
4.1.4
T
Optimizaciones basadas en Checkpoint
T
El raciocinio sobre el cual se basa esta aproximación se presenta en Fig.
6-3, 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 TSF, se representa
como Tsetup 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 TS almacena los datos necesarios para
reiniciar la simulación desde el momento TS.
T
B
P
B
P
P
P
P
PB
B
6TP PT. TÉCNICAS DE INYECCIÓN DE FALLAS
17
fault f
TS
F
system time
simulator CPU time
Tsetup
checkpoints
fault f
TS
C1
C0
F
system time
C2
T”
simulator CPU time
setup
Figura 6TP PT-3. Optimización dependiente del Simulador
T
T
Cuando se debe inyectar la falla f, reiniciamos el simulador desde el
primer checkpoint anterior a TSF (checkpoint C2 en el ejemplo de Fig. 6-3);
therefore, the CPU time spent to reach injection time becomes T’’setup.
Sea TR 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:
PB
P
B
B
B
T
P
B
PB
T
B
B
"
Tsetup
+ TR < Tsetup
(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. 6-4.
T
T
18
Capítulo 6TP PT
Target System
Host Computer
Comm. line
Communic.
support
Injector
Observer
Fault List
Manager
Fault Injection
Manager
Scheduler
Result
Analyzer
Time-Out
User
Figura 6TP PT-4. Ambiente de inyección de daños FlexFI
T
T
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
6TP PT. TÉCNICAS DE INYECCIÓN DE FALLAS
19
comportamiento del sistema, recuperándolo de cualquier falla posible (por
ejemplo, excepciones generadas por el hardware). Presentamos el
pseudocódigo del FIM en Fig. 6-5.
T
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();
}
Figura 6TP PT-5. Pseudocódigo del Administrador de Inyección de Fallas
T
T
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. 6-6. 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.
T
T
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());
}
Figura 6TP PT-6. Pseudo-código del.Módulo Organizador
T
T
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
6TP PT. TÉCNICAS DE INYECCIÓN DE FALLAS
21
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. 6-7. 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.
T
T
6TP PT. TÉCNICAS DE INYECCIÓN DE FALLAS
23
RT-level Model
Instrumentation
architectures
Workload
Fault List
Manager
Fault Injection
Manager
Instrumenter
Instrumented
RT-level Model
Synthesis Tool
Output
Fault List
Emulated
system
Result
Analyzer
Instrumented
Gate-level Model
Fault Injection
Interface
FPGA board
Fault
Classification
Figura 6TP PT-7. Diagrama de flujo de FIFA
T
T
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. 6-8, 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
T
T
6TP PT. TÉCNICAS DE INYECCIÓN DE FALLAS
25
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.
External Bus
Bus Stub logic
Processor Core
Control Registers
Internal Registers
Masking logic
Masking logic
Memory Stub logic
Memory Stub logic
I-cache
D-cache
Memory Stub logic
Fault Injection Bus
Register
File
Figura 6TP PT-8. Procesador típico enriquecido con los módulos de Inyección de Fallas
T
4.3.3
T
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. 6-9. 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.
T
T
Address
Functiona signals
M
U
X
Fault Injection bus
Data
Memory
Array
Read
Write
mode
Figura 6TP PT-9.Lógica Stub de Memoria
T
T
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.
6TP PT. TÉCNICAS DE INYECCIÓN DE FALLAS
4.3.4
27
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.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
REFERENCIAS
J. Clark, D. Pradhan, Fault Injection: A method for Validating Computer-System
Dependability, IEEE Computer, June 1995, pp. 47-56
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
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
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
T. Lovric, Processor Fault Simulation with ProFI, European Simulation Symposium
ESS95, 1995, pp. 353-357
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
L. T. Young, R. Iyer, K. K. Goswami, A Hybrid Monitor Assisted Fault injection
Experiment, Proc. DCCA-3, 1993, pp. 163-174
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
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
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
TetraMAX, www.synopsys.com
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
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
6TP PT. TÉCNICAS DE INYECCIÓN DE FALLAS
29
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