Como ya comentamos en anteriores entradas del blog, estamos rodeados de sistemas empotrados por todas partes. En algunas ocasiones son cosas más evidentes, como en los equipos médicos o industriales. En otras no tanto. Puede llegar a sorprender que podamos encontrarlos hasta en nuestra lavadora o microondas, pero estos sistemas de propósito específico llevan tiempo entre nosotros y están aquí para quedarse.
Algunos de estos sistemas pueden ser sistemas críticos, aquellos cuyo fallo tiene consecuencias catastróficas en vidas humanas o en pérdidas económicas; pueden ser sistemas de tiempo real, donde el tiempo de respuesta debe estar acotado para que su ejecución se considere correcta; o pueden ser una combinación de ambos. En cualquiera de los casos, comprobar y demostrar su correcto comportamiento antes de su salida al mercado es de suma importancia. A ninguno le gustaría que el sistema de airbag de su vehículo fallara en el momento en el que más lo necesitáramos, por ejemplo. Esta tarea no es sencilla, sobre todo porque en estos sistemas que están en contacto con su entorno, no es fácil crear situaciones controladas, donde todas las variables sean perfectamente reproducibles al más mínimo detalle en cada prueba.
Una técnica que resulta altamente beneficiosa en el desarrollo de sistemas críticos es el software-in-the-loop (SIL). Las pruebas basadas en SIL consisten en integrar el software real del sistema empotrado dentro de un entorno simulado que representa el comportamiento real del mundo físico, generalmente obtenido mediante un modelo matemático. Esto permite a los ingenieros probar el sistema de forma aislada sin la necesidad de disponer del entorno real y llevar a cabo las modificaciones pertinentes de forma iterativa. ¡Esto hasta nos permite probar el software en condiciones de entorno extremas o incluso mientras el hardware está aún en las fases más tempranas de diseño y prototipado! De esta manera podemos avanzar en el desarrollo de nuestra aplicación mientras la plataforma sobre la que se va a ejecutar está siendo diseñada en paralelo, consiguiendo así reducir potencialmente el tiempo necesario para completar un nuevo sistema.
Además, facilitar la detección de errores o fallos en el código mediante la simulación de su entorno, también puede conllevar el ahorro de posibles pérdidas económicas, o incluso evitar la pérdida de vidas humanas, cuando estamos tratando con sistemas especialmente críticos. Sirva como ejemplo ilustrativo el caso del Ariane 5, un cohete diseñado para el lanzamiento de satélites en órbita geoestacionaria. Su diseño comenzó en 1984 por encargo de la Agencia Espacial Europea (ESA). El primer vuelo de prueba del Ariane 5 el 4 de junio de 1996 fue un fracaso, ya que el cohete se autodestruyó pasados 37 segundos desde el lanzamiento debido a un fallo en el software de control del mismo. Se había decidido reutilizar parte del sistema de referencia inercial que se había utilizado en el Ariane 4 y que no había dado problemas previos. No obstante, los sistemas de computación del Ariane 5 eran más potentes y el software reutilizado no se comportó como se esperaba. Técnicamente, la conversión de unos datos en formato de coma flotante de 64 bits a enteros con signo de 16 bits hizo que se desbordaran las variables. Esto se tradujo en la transmisión de informaciones erróneas al ordenador central que a su vez dio orden de corregir una desviación en la trayectoria que no existía. El resultado ya lo conocemos. Mediante la aplicación de las pruebas de SIL sobre la misma plataforma de ejecución del Ariane 5 es probable que se hubiera podido detectar este fallo mucho antes de la prueba de lanzamiento real, con el consecuente ahorro económico y material que supuso la perdida de uno de los cohetes Ariane.
El grupo CPS de ITI ha estado trabajando en el uso de SIL como mecanismo para la verificación del correcto comportamiento del software de sistemas empotrados críticos. Por ejemplo, en el proyecto europeo AQUAS (Aggregated Quality Assurance for Systems) se implementó un SIL para verificar un dispositivo de transmisión neuromuscular (NMT) desarrollado por la empresa RGB Medical Devices. Este dispositivo utiliza una tecnología muy innovadora para ayudar al anestesiólogo a controlar la relajación muscular durante una intervención en el quirófano mediante la infusión automática de fármacos al paciente. Obviamente la realización de pruebas con pacientes es algo inviable. Para salvar este obstáculo, el grupo CPS de ITI implementó en la herramienta art2kitekt una serie de servicios en los que realizar estas pruebas de forma segura. Estos servicios permiten ejecutar los trabajos de test coordinados por el entorno art2kitekt, así como definir toda la información necesaria para ellos: tiempo de ejecución, modelos de paciente, dosis de fármacos, etc. De igual manera, se facilita la interpretación de los resultados obtenidos durante la ejecución de estas pruebas. Mediante el uso del modelo de paciente virtual, la herramienta permite comprobar que el comportamiento de este dispositivo NMT es el esperado.
Como ha quedado patente por los ejemplos referidos en esta entrada del blog, la correcta evaluación de los sistemas críticos de tiempo real es una tarea necesaria y que se debe abordar minuciosamente durante el proceso de diseño del propio sistema. Por esa razón, dentro del marco del proyecto CUSTOMER 2, se está extendiendo el entorno art2kitekt para que sea capaz de modelar, analizar y simular sistemas formados por componentes distribuidos. Los vehículos actuales son un ejemplo de un sistema formado por un conjunto de componentes (e.g. sistema ABS, airbags, sistema de asistencia para el aparcamiento, etc.), cada uno con su funcionalidad particular, pero con la capacidad de comunicarse entre sí mediante un intercambio de mensajes. La complejidad añadida de este tipo de sistemas se corresponde con modelar y analizar el impacto que tienen las redes de comunicaciones que interconectan los distintos componentes. Estas redes pueden ser muy variadas tanto en su topología como en su tecnología (ej. bus CAN, canal Ethernet, transmisión inalámbrica Wi-Fi, etc.). Con esta ampliación pretendemos aumentar el abanico de sistemas que se pueden evaluar utilizando este entorno.
