Pruebas de fiabilidad de circuitos integrados y software: una guía práctica para la inyección de fallos

Autor: Johnny Liu, director ejecutivo de Dowway Vehicle

Publicado: 21 de julio de 2026

Categoría: Sistemas embebidos, seguridad automotriz, ingeniería de hardware, cumplimiento normativo

Como director ejecutivo de Dowway Vehicle, donde fabricamos sistemas de seguridad críticos para automóviles, sé que la fiabilidad no es solo un requisito formal. En nuestro sector, un fallo de chip no detectado o un breve error de software pueden provocar graves problemas de seguridad.

La inyección de fallos es la forma más fiable de probar la capacidad de un sistema para gestionar errores. Esta guía analiza los métodos principales de inyección de fallos, ayudándole a diseñar sistemas que gestionen los fallos de forma controlada y cumplan con estándares como el IEC 61508.

1. Por qué debemos inyectar fallos

A mediados de la década de 1970, las misiones espaciales fueron las primeras en reportar comportamientos extraños en los sistemas causados ​​por errores en los chips. Desde entonces, los diseñadores y fabricantes de chips se han centrado en la fiabilidad. Hoy en día, debemos analizar cómo se comportan los circuitos digitales en aviones, automóviles y otros sistemas críticos cuando se producen errores. Las pruebas de inyección de fallos son una de las mejores maneras de evaluar esta fiabilidad. De hecho, las normas de seguridad funcional como la IEC 61508 recomiendan encarecidamente inyectar fallos en cada fase del ciclo de desarrollo.

Cuando los sistemas fallan, suelen sufrir caídas graves que destruyen datos de estado valiosos. Los errores también pueden permanecer ocultos durante mucho tiempo antes de causar un problema visible. Esto dificulta enormemente la identificación de la causa raíz de un fallo en un sistema en funcionamiento. En configuraciones grandes y complejas, reproducir estas condiciones de fallo, poco frecuentes, resulta prácticamente imposible.

La inyección de fallos soluciona esto. Permite probar qué tan bien funciona un sistema:

• Detecta fallos.
• Aísla las fallas para evitar que se propaguen.
• Se reconfigura automáticamente para seguir funcionando de forma segura.
• Vuelve a un estado normal.

2. Dentro de un entorno de inyección de fallos

Un sistema profesional de inyección de fallos es un ecosistema estructurado. Utiliza nueve componentes principales para ejecutar pruebas sin dañar el sistema objetivo:

1. Sistema objetivo: El hardware o software que está probando.
2. Inyector defectuoso: La herramienta (hardware o software) que introduce el error.
3. Biblioteca de fallos: Una base de datos independiente almacena los parámetros de las pruebas, como los tipos de fallos, su ubicación, la temporización y las reglas de hardware o software. Mantener esta biblioteca independiente hace que todo el sistema sea muy flexible y fácil de integrar en otros proyectos.
4. Generador de carga de trabajo: Una herramienta que envía comandos operativos al sistema objetivo. Estos comandos pueden ser aplicaciones reales, pruebas de rendimiento estandarizadas o tareas sintetizadas.
5. Biblioteca de cargas de trabajo: Una colección de cargas de trabajo y casos de prueba predefinidos.
6. Controlador: El programa que ejecuta todo el experimento. Puede ejecutarse en el propio sistema objetivo o en un ordenador anfitrión independiente.
7. Monitor: Una herramienta que monitoriza la ejecución del sistema en tiempo real para detectar cuándo se ejecutan los comandos y cuándo se producen anomalías.
8. Recopilador de datos: Una herramienta que registra los datos del sistema en tiempo real cuando se activa mediante el monitor.
9. Analizador de datos: Una herramienta sin conexión que procesa y revisa los datos recopilados para medir la fiabilidad.

3. Inyección de fallos de hardware frente a inyección de fallos de software

La elección entre métodos de hardware y software depende del tipo de fallos que se quieran probar y del esfuerzo necesario para configurarlos.

Tipo/modelo de falla	Inyección de fallos de hardware	Inyección de fallos de software
Circuito abierto	Sí	No
Puentes	Sí	No
Inversión de bits	Sí	Sí
Corriente espuria	Sí	No
Sobretensión	Sí	No
Atascado en	Sí (ideal para el control de ubicación)	Difícil / Costos generales elevados
Corrupción de datos almacenados (memoria, registros, disco)	Casi nunca	Sí
Corrupción de datos de comunicación (bus, red)	Casi nunca	Sí
Manifestación de defectos de software (a nivel de máquina y superior)	No	Sí

Si desea probar fallas permanentes (donde una línea física se ve obligada a permanecer en un 1 o 0), un inyector de hardware es la mejor opción, ya que permite controlar el punto físico exacto. Simular fallas permanentes mediante software es extremadamente lento o completamente imposible.

Si su objetivo es detectar la corrupción de datos, las herramientas de software suelen ser suficientes. Algunos errores, como un cambio de bit en una celda de memoria, pueden reproducirse tanto con hardware como con software. En estos casos, la elección debe basarse en el coste, la precisión, la interferencia de la herramienta con el sistema y la facilidad para repetir la prueba.

4. Inyección de fallos implementada por hardware

Los métodos de hardware utilizan equipo físico adicional para introducir errores directamente en el hardware objetivo. Dividimos estos métodos en dos grupos principales: de contacto y sin contacto.

Inyección de hardware por contacto (a nivel de pines)

Este es el método de inyección de hardware más común. Requiere contacto físico directo con los pines del chip objetivo.

• Sondas activas: Las sondas se conectan directamente a los pines para inyectar corriente. Esto cambia el estado de los pines. Se utiliza principalmente para detectar fallos permanentes, aunque también se pueden puentear dos pines. Tenga cuidado: inyectar demasiada corriente con sondas activas puede dañar el chip.
• Inserción del casquillo: Se coloca un zócalo personalizado entre el chip objetivo y su placa de circuito impreso. Este zócalo aplica niveles de voltaje analógico específicos a los pines para simular errores lógicos complejos, como bloqueos, circuitos abiertos o fallos de estado. Puede invertir las señales de los pines, realizar operaciones AND u OR con pines adyacentes, o incluso combinar la señal actual con señales anteriores en el mismo pin.

Estos métodos de contacto ofrecen un gran control sobre la sincronización y la ubicación de la falla. Además, prácticamente no interfieren con el software que se ejecuta en el dispositivo. Sin embargo, dado que estas fallas ocurren a nivel de pin, no son exactamente iguales a las fallas internas permanentes o de cortocircuito que se producen en el interior del silicio. Aun así, son excelentes para probar circuitos de detección de errores. También se pueden conectar sondas activas a la línea de alimentación para inyectar fluctuaciones en la fuente de alimentación, aunque esto conlleva un alto riesgo de dañar el dispositivo.

Inyección de hardware sin contacto

El inyector no entra en contacto con el sistema. En cambio, utiliza fuerzas físicas externas para provocar problemas dentro del chip.

• Radiación de iones pesados: Los iones atraviesan las regiones de agotamiento de los chips, creando corrientes eléctricas transitorias.
• Campos electromagnéticos: Colocar el hardware dentro o cerca de campos electromagnéticos fuertes imita la interferencia física natural.

Estos métodos sin contacto son excelentes para probar prototipos de diseño iniciales, especialmente cuando se necesita un seguimiento de hardware de alta velocidad (como medir el tiempo que tarda una CPU en reaccionar a un error) o cuando se necesita acceder a zonas internas inaccesibles para las sondas físicas. Los sistemas de hardware pueden detectar y activar estos errores a alta velocidad y con muy poca interferencia en el sistema, a menudo utilizando temporizadores de hardware o esperando un evento específico (como la aparición de una dirección en el bus).

La principal desventaja es que los métodos sin contacto son difíciles de activar con precisión en cuanto a la sincronización o la ubicación, ya que no se puede controlar perfectamente cuándo se emite un ion pesado o cuándo una onda electromagnética incide sobre un transistor específico.

5. Inyección de fallos implementada por software (SFI)

Las herramientas de inyección de fallos basadas en software son muy populares. La principal razón es el coste: no es necesario comprar equipos de laboratorio costosos. Además, la inyección de fallos permite probar aplicaciones y sistemas operativos directamente, algo muy difícil de hacer con hardware.

Si quieres probar una aplicación, debes colocar el inyector dentro de la propia aplicación o entre la aplicación y el sistema operativo. Si quieres probar el sistema operativo, debes colocar el inyector dentro del código del sistema operativo, ya que añadir una capa adicional entre el hardware y el sistema operativo es extremadamente difícil.

A pesar de su flexibilidad, SFI tiene tres inconvenientes principales:

1. Límites de acceso: No puede acceder a áreas a las que el software no puede acceder (como las compuertas lógicas físicas).
2. Interferencia del sistema: El código del inyector puede ralentizar el sistema objetivo o incluso modificar la estructura original del software.
3. Baja resolución temporal: Esto puede distorsionar la precisión de la prueba. SFI funciona bien para fallos de desarrollo lento (como problemas de memoria). Pero para fallos ultrarrápidos (como fallos de sincronización de la CPU o del bus), el software podría no detectar cómo se propaga el error por el sistema.

El enfoque híbrido

Para solucionar estos problemas de sincronización, los ingenieros a veces utilizan un método híbrido. Este combina la flexibilidad de la inyección de software con la velocidad y precisión del seguimiento por hardware. Es ideal para medir pequeños retrasos. Sin embargo, añadir herramientas de seguimiento por hardware aumentará los costes y limitará la flexibilidad de las pruebas debido a las limitaciones de almacenamiento físico de datos.

6. Inyección de software en tiempo de compilación frente a inyección en tiempo de ejecución

La inyección de fallos de software se divide según el momento en que se introduce el fallo: en tiempo de compilación o en tiempo de ejecución.

SFI en tiempo de compilación

Se modifican las instrucciones del programa antes de cargarlo o ejecutarlo. En lugar de cambiar el hardware físico, se modifica el código fuente o el código ensamblador para simular errores de hardware, software o transitorios. Esto crea una imagen del programa modificada y defectuosa. Cuando el sistema ejecuta esta imagen, se activa el fallo.

Esto no requiere software adicional durante la ejecución y no provoca ninguna ralentización del rendimiento. Dado que el error se escribe permanentemente en el código, es perfecto para simular fallos de hardware permanentes. La desventaja es que no se pueden inyectar fallos dinámicamente mientras el programa se está ejecutando.

SFI de tiempo de ejecución

Necesitas una forma de provocar fallos mientras el programa se está ejecutando. Hay tres formas comunes de hacerlo:

• Tiempos de espera: Un temporizador (ya sea de hardware o software) activa una interrupción tras un tiempo determinado, llamando al inyector de fallos. Esto no requiere modificaciones en el código de la aplicación. Sin embargo, dado que se activa en función del tiempo y no de la actividad del programa, los resultados pueden ser impredecibles. Es ideal para simular fallos de hardware transitorios o temporales.
• Excepciones y trampas: Una excepción de hardware o una instrucción de interrupción de software (como un punto de interrupción) transfiere el control al inyector. A diferencia de los tiempos de espera, esto permite inyectar fallos justo cuando se produce un evento o condición específicos (por ejemplo, cuando el programa intenta acceder a una ubicación de memoria específica). Ambos deben conectarse directamente a los controladores de interrupción del sistema.
• Inserción de código: Se añaden nuevas instrucciones al programa que se ejecutan justo antes del código objetivo. Esto es similar a modificar código, pero ocurre en tiempo de ejecución y añade nuevas instrucciones en lugar de cambiar las existentes. A diferencia de las trampas, el inyector puede ejecutarse completamente en modo usuario en lugar de en modo sistema, por lo que no necesita privilegios de administrador del sistema operativo.

7. Resumen de las diferencias

Veamos cómo se comparan los dos enfoques principales:

• Puntos objetivo: El hardware se dirige a los pines del encapsulado y a los componentes internos físicos. El software se dirige a la memoria activa, los registros de la CPU y el estado general del software.
• Interferencia: El hardware prácticamente no provoca retrasos. El software introduce una sobrecarga de rendimiento porque se debe ejecutar código adicional.
• Costo: El hardware es caro y requiere un laboratorio especializado. El software se basa en código y su implementación es económica.
• Resolución de tiempo: El hardware es muy preciso (nanosegundos). El software tiene una resolución más baja (microsegundos o milisegundos).
• Enfoque de las pruebas: El hardware evalúa la detección y protección contra errores de bajo nivel. El software prueba los programas de recuperación de alto nivel, los sistemas operativos y las aplicaciones.

8. Preguntas frecuentes

¿Cuál es la principal diferencia entre la inyección de fallos de hardware y la de software?

La inyección de hardware se dirige a los pines y circuitos físicos, mientras que la inyección de software se dirige a la memoria, los registros y el código. Los métodos de hardware utilizan herramientas físicas como sondas o radiación para probar reacciones de circuitos de bajo nivel. Los métodos de software modifican el código o la memoria del sistema para probar cómo las aplicaciones y los sistemas operativos manejan los errores.

¿Puede la inyección de fallos de software simular fallos permanentes de hardware?

Sí, mediante la inyección en tiempo de compilación para modificar permanentemente el código de los programas. Al alterar las instrucciones de código fuente o de ensamblaje antes de la ejecución, se crea una imagen del programa con un defecto permanente. Esto simula un fallo físico permanente sin provocar ningún retraso en el rendimiento durante la ejecución.

¿Por qué es más seguro insertar un conector en el zócalo que usar sondas activas para realizar pruebas a nivel de pines?

La inserción en el zócalo utiliza una manipulación controlada de la señal, mientras que las sondas activas inyectan corrientes externas que pueden quemar el chip. Las sondas activas fuerzan la corriente directamente sobre los pines físicos, lo que puede provocar un sobrecalentamiento del silicio. Los conectores de derivación interceptan los pines de forma segura y utilizan puertas lógicas (AND, OR, inversión) para simular fallos sin riesgo eléctrico.

Consideraciones finales para arquitectos de sistemas

En Dowway Vehicle, seguimos una regla sencilla: Si no ha probado la respuesta de su sistema ante un fallo, debe asumir que su sistema fallará cuando se produzca dicho fallo. No se limite a un solo método de prueba. Utilice la inyección de software al inicio del desarrollo para probar las máquinas de estados a nivel de aplicación y las rutinas de recuperación del sistema operativo. Posteriormente, utilice la inyección de hardware en prototipos físicos para asegurarse de que los sistemas de vigilancia de hardware, los sistemas de protección de memoria y las fallas en los pines físicos no provoquen un desastre generalizado del sistema.

Referencias

• [1] Técnicas y herramientas de inyección de fallos (Encuesta académica exhaustiva)
• [2] Un entorno de inyección de fallos basado en la verificación funcional (Simposio IEEE sobre fiabilidad y mantenibilidad)
• [3] ISO 26262-11:2018 – Directrices sobre la aplicación de semiconductores para la seguridad funcional en la industria automotriz.
• [4] IEC 61508 – Seguridad funcional de sistemas eléctricos/electrónicos/electrónicos programables relacionados con la seguridad.