Cuando he oído hablar de CIL utilizado en el contexto de la programación integrada, por lo general significa que las pruebas automáticas se realizan en un sistema simulado, en lugar de simulación.
Una forma de probar un microcontrolador incorporado se ejecutaría en un simulador, se burlaría de las rutinas de E / S o usando los registros generados por el simulador. Entonces, su prueba está "bajo el estímulo X, los datos Y deben enviarse a la periferia Z dentro de t ciclos de reloj". Esto es bueno si puede hacerlo porque puede ejecutarse completamente en software. Esto facilita la automatización con un sistema de compilación y hace muchas, muchas corridas. También puede ser más fácil inyectar fallas o hacer una inspección interna como las transiciones de la máquina en el estado del monitor.
Este enfoque también tiene algunas limitaciones. En primer lugar, es simplemente difícil de hacer. Los sistemas integrados están diseñados para "hablar con el mundo" constantemente, y generar un entorno de simulación que capture lo suficientemente bien puede ser difícil. En segundo lugar, las pruebas no reflejan necesariamente las verdaderas restricciones; digamos que la periferia Z de arriba es un chip de bus CAN o SPI. Lo que realmente te importa es que el periférico hace lo que se supone que debe hacer. Si su prueba no captura los requisitos de tiempo de ese periférico, entonces su prueba no detectará ese tipo de error.
Entonces, una prueba HWIL significaría que cuando construyes el programa, lo transfieres a una plataforma de "prueba", luego realizas las pruebas en hardware real y, por ejemplo, registras los resultados con un analizador lógico o un osciloscopio. Si su prueba es que "si el acelerómetro supera algún valor, dispare la bolsa de aire", en realidad está probando el pulso que iría al inflador de la bolsa de aire, en lugar de simplemente llamar a la rutina de E / S correcta en el microprocesador.