Apoyo al desarrollo de firmware embebido y pruebas para dispositivos conectados e implantables

El firmware de un dispositivo médico conectado o implantable se somete a un estándar distinto al del firmware de un producto de consumo, por una razón simple: el comportamiento impredecible puede traducirse directamente en daño al paciente. Eso es lo que la verificación debe confirmar: el determinismo —la misma entrada y la misma falla producen siempre el mismo comportamiento, predecible— y la degradación controlada, en la que una falla lleva al dispositivo a un estado seguro conocido en lugar de uno indefinido. El manejo de interrupciones, las garantías de temporización y el uso de memoria deben probarse frente a los límites definidos en el diseño, porque «funcionó en el banco» no es evidencia de verificación.

Casi ningún dispositivo médico embebido se construye desde cero: un RTOS, una pila BLE, una biblioteca de criptografía, un controlador de un fabricante de chips. IEC 62304 tiene una categoría específica para exactamente esto: SOUP (Software of Unknown Provenance, software de procedencia desconocida), es decir, software que no fue desarrollado con el propósito específico de incorporarse al dispositivo médico, o del que no existen registros de desarrollo adecuados. Los elementos SOUP deben identificarse explícitamente, documentar sus anomalías y limitaciones conocidas y evaluar su riesgo para el sistema: una pila BLE o un RTOS no puede simplemente incorporarse y darse por seguro porque se use mucho en otros lugares. Ayudamos a los equipos a realizar esa evaluación y a documentarla como parte del registro de verificación.

Los dispositivos wearables e implantables agregan restricciones que no aparecen en equipos conectados a la red eléctrica: una vida de batería medida en meses o años, memoria persistente que debe sobrevivir a una pérdida de energía sin corromperse y ningún técnico cerca para reiniciar un dispositivo colgado. Eso es lo que las pruebas deben apuntar específicamente:

• Confirmar que los temporizadores watchdog detectan correctamente un sistema colgado y fuerzan la recuperación a un estado conocido.
• Verificar escrituras en flash/EEPROM con nivelado de desgaste y tolerantes a cortes de energía, bajo pérdida de energía simulada.
• Ejercitar las máquinas de estados frente a cada camino de falla, no solo el camino feliz: en un dispositivo implantable un cuelgue no es una molestia, es un peligro.

La verificación del firmware sigue la misma lógica de clasificación de IEC 62304 que el resto del software: cuanto mayor la clase de seguridad, más rigurosa debe ser la verificación. Para C/C++ embebido en particular, eso implica pruebas unitarias con el hardware abstraído mediante mocks —usamos Ceedling/CMock para esto— de modo que la lógica pueda verificarse sin necesitar hardware físico en cada ejecución de pruebas, y VectorCAST cuando la clasificación de un proyecto o la cadena de herramientas existente del cliente lo requieren.

Para el software de Clase B y C, esa verificación se vincula con los requisitos documentados y produce la evidencia de cobertura y trazabilidad que exige la clasificación; para la Clase A se usa la misma infraestructura de pruebas, sin la carga documental que exigiría una clase mayor. Vea cómo la clasificación determina la profundidad de la verificación.