Resumen ejecutivo

Un convertidor de electrónica de potencia moderno es hoy tanto software como hardware. El firmware del controlador ejecuta los lazos de regulación, las protecciones, la calibración digital, la gestión térmica activa, la telemetría y, en un número creciente de casos, funciones de seguridad funcional certificadas según SSIL ferroviario o ASIL de automoción. Cualquier defecto en ese firmware es indistinguible —desde el punto de vista del operador final— de un defecto de hardware: el equipo no funciona, no cumple su misión, genera penalizaciones contractuales. La diferencia es que el firmware no envejece físicamente, pero sí se degrada en términos de confianza si no se somete a un proceso disciplinado de verificación y validación.

Este artículo repasa los fundamentos del aseguramiento de la calidad del software aplicados al firmware embebido de electrónica de potencia: la distinción crítica de Boehm entre verificación y validación, la disciplina del Test-Driven Development, el modelo en V de la EN 50128, la pirámide de pruebas MiL → SiL → PiL → HiL → SYSiL, las técnicas de caja negra y caja blanca, y el «pantano terminológico» que persiste en la industria. La tesis es directa: el firmware crítico se diseña con la misma disciplina con la que diseñamos un módulo de potencia —perfil de misión, derating, FMEA, V&V— porque comparte el mismo cliente y los mismos compromisos contractuales.

1. El firmware como componente crítico: por qué importa la disciplina

Un convertidor típico de Premium SA de hace quince años llevaba un firmware mínimo: una máquina de estados elemental, unos pocos lazos PI implementados en aritmética de coma fija y protecciones hardware reforzadas con un par de comprobaciones por software. La complejidad del código embebido cabía en unos pocos kilobytes y un experto podía revisarla línea a línea en una tarde. Esa época ha terminado.

El convertidor moderno —que integra calibración digital, gestión térmica activa, control predictivo del rizado del bus DC, comunicación CAN/Ethernet/Modbus con el supervisor del operador, telemetría PHM con estimación de RUL, actualización de firmware OTA con firma criptográfica y, posiblemente, funciones de seguridad activa certificadas según SSIL ferroviario— contiene decenas de miles de líneas de código C, organizadas en arquitecturas modulares con HAL, RTOS, tareas con prioridades y librerías de comunicaciones. La probabilidad de que ese código sea perfectamente correcto en su primera escritura es, sencillamente, cero.

2. Verificación y validación: la distinción de Boehm

La distinción más clarificadora del aseguramiento de la calidad del software la formuló Barry Boehm en 1981 mediante dos preguntas aparentemente similares, pero metodológicamente distintas:

2.1 Las diferencias prácticas

2.2 Por qué ambas son necesarias

Una verificación impecable sin validación produce código técnicamente correcto que satisface una especificación que ya era defectuosa: el equipo cumple sus obligaciones y el cliente recibe un producto que no resuelve su problema. Una validación vigorosa sin verificación produce código que «funciona en la demo», pero esconde defectos estructurales que afloran en condiciones de operación no contempladas en la prueba de aceptación. Las dos disciplinas son complementarias y atacan clases de error distintas, y ninguna estrategia seria de ingeniería del software puede prescindir de ninguna de ellas.

3. El pantano terminológico: error, defecto, fallo, incidente

Cualquier discusión seria sobre la calidad del software arrastra el problema histórico del vocabulario. Múltiples términos clave —verificación, validación, prueba, error, defecto, falta, fallo— están sobrecargados de significados contradictorios en la literatura. Un equipo que usa estos términos de forma intercambiable comete, sin saberlo, errores de razonamiento que se traducen en errores de proceso. Conviene anclar el vocabulario a la norma IEEE.

4. El modelo en V: verificación en cada nivel

El marco metodológico que articula la verificación a lo largo del ciclo de vida del software es el modelo en V. Su propuesta es estructural: a cada nivel de especificación le corresponde un nivel simétrico de verificación. La rama izquierda desciende de los requisitos al código; la rama derecha asciende de la verificación unitaria a la aceptación final. El modelo en V es la columna vertebral de la EN 50128 (ferrocarril), la IEC 61508 (genérica), la ISO 26262 (automoción) y la DO-178C (aviónica).

4.1 Las correspondencias de la V

4.2 SSIL: niveles de integridad de seguridad del software

La EN 50128 define cinco niveles de integridad del software: Basic Integrity y SSIL 1 a SSIL 4. Cada nivel impone técnicas de V&V obligatorias, cuyo rigor aumenta con la criticidad de la función. Premium SA asigna sus aplicaciones a estos niveles según la responsabilidad de cada bloque de firmware:

5. Test-Driven Development: las pruebas como decisión de diseño

El Test-Driven Development (TDD, desarrollo guiado por pruebas) surgió a principios de los años 2000 como uno de los pilares de Extreme Programming y representa una inversión radical del flujo de trabajo tradicional. En el orden clásico, el programador escribe primero la funcionalidad y después —si hay tiempo— añade pruebas para verificarla. En TDD el orden se invierte: la prueba se escribe primero, antes de que exista la funcionalidad.

5.1 El ciclo Red-Green-Refactor

El ciclo se repite en incrementos pequeños: minutos, no horas. Tras una sesión de TDD, el desarrollador ha producido tanto el código de producción como su batería de pruebas, y cada línea del primero está respaldada por al menos una de las segundas. La consecuencia metodológica más profunda no es tener pruebas, sino el orden invertido: pensar la prueba antes que la implementación obliga al desarrollador a entender exactamente qué significa el éxito o el fallo de la funcionalidad. Eso es, en última instancia, un acto de diseño.

5.2 El TDD como sustituto parcial del diseño tradicional

5.3 TDD, BDD y ATDD: la evolución hacia el comportamiento

El TDD puro es eficaz, pero tiene un límite: es puramente técnico. Un equipo que solo usa TDD puede producir código que supera todas las pruebas unitarias y, aun así, resulta incoherente con las necesidades reales de las partes interesadas. Han surgido dos variantes para cerrar esta brecha. El BDD (Behavior-Driven Development) amplía el TDD centrándose en el comportamiento esperado del sistema, expresado en un lenguaje ubicuo (Given-When-Then) que tanto desarrolladores como clientes pueden entender: la especificación no se traduce a pruebas, la especificación es la prueba. El ATDD (Acceptance Test-Driven Development) combina la especificación de requisitos con pruebas de aceptación automatizadas escritas antes del código. Las tres prácticas son complementarias: el TDD garantiza que cada función esté bien diseñada técnicamente; el ATDD, que el sistema completo cumpla su propósito de negocio; y el BDD aporta el puente lingüístico entre ambos.

6. Fundamentos de las pruebas: qué probamos y cómo

Como señaló Edsger Dijkstra, las pruebas pueden ser muy eficaces para demostrar la presencia de errores, pero son irremediablemente insuficientes para demostrar su ausencia. Esta limitación es estructural: el dominio de entradas de cualquier programa no trivial es tan grande que probar exhaustivamente todas las combinaciones es, en la práctica, imposible. La disciplina de las pruebas consiste, por tanto, en seleccionar un subconjunto finito y representativo del dominio que ejercite de forma eficaz las características críticas del sistema.

6.1 El caso de prueba y el oráculo

La unidad básica de las pruebas es el caso de prueba: un conjunto definido de condiciones, datos de entrada y un resultado esperado con el que se ejecuta el software para determinar de forma medible si cumple un requisito. Cada caso de prueba presupone, implícita o explícitamente, un oráculo: el árbitro que decide si el resultado obtenido es correcto. En sistemas sencillos, el oráculo es la propia especificación. En sistemas complejos sin especificación cerrada, el oráculo es un experto humano: el responsable de pruebas que decide si el comportamiento observado coincide con el esperado.

6.2 Caja negra, caja blanca y la distinción crítica

7. La pirámide MiL → SiL → PiL → HiL → SYSiL

En el firmware embebido —donde el código se ejecuta en un microcontrolador acoplado a un sistema físico real—, la disciplina de pruebas añade una capa de complejidad que no existe en el software de aplicación clásico. Las pruebas no pueden limitarse a entradas y salidas digitales; deben cerrar el lazo con el comportamiento físico del convertidor. La metodología X-in-the-Loop estructura este reto en cinco niveles progresivos:

Cada nivel resuelve una clase de defectos antes de añadir una capa adicional de complejidad. El MiL captura errores de modelado y del algoritmo de control. El SiL, errores de traducción del modelo al código. El PiL, errores específicos del compilador del procesador objetivo, optimizaciones agresivas y problemas de aritmética finita. El HiL, defectos de integración firmware-hardware: temporización, interrupciones, condiciones de carrera, periféricos. El SYSiL es la validación final con la planta real.

8. El proceso D4Co-SW de Premium SA

Premium SA aplica al firmware el mismo marco metodológico que al hardware: las puertas secuenciales D2W → D2F → D4R → D4Co, adaptadas a las técnicas y entregables propios del software.

8.1 Técnicas innegociables: MISRA, MC/DC, HIL

• MISRA C:2012: análisis estático con Polyspace, Coverity o PC-lint de todo el código C. Las 16 reglas obligatorias y las 111 requeridas son condiciones de salida de la puerta D2F.
• MC/DC para SSIL ≥ 3: cada decisión booleana se prueba con n+1 casos en los que cada condición individual cambia el resultado mientras las demás permanecen fijas; para SSIL 4 se complementa con análisis formal.
• HIL como criterio de salida: ningún firmware con responsabilidad sobre la seguridad activa cierra la puerta D4Co sin un programa HIL completo que cubra el espacio del perfil de misión.
• Inyección de fallos para SSIL ≥ 2: se simulan fallos de sensores, ruido en señales analógicas, pérdida de comunicación y corrupción de memoria. El sistema debe entrar siempre en estado seguro: PWM desactivado, salida en alta impedancia, alarma activa.

8.2 FRACAS aplicado al software

La metodología FRACAS (Failure Reporting, Analysis and Corrective Action System) que Premium SA aplica al hardware se extiende al firmware. Cualquier defecto detectado en flota se analiza al nivel adecuado (función, módulo, librería compartida), se documenta la causa raíz y la corrección se propaga: a todas las plataformas que comparten el código, mediante actualización OTA firmada criptográficamente, y al proceso de desarrollo, mediante una nueva regla de revisión o un nuevo caso de prueba que impide la reintroducción del defecto. El firmware de la flota mejora con el tiempo, igual que el hardware mejora gracias a las devoluciones de campo.

9. Síntesis: el firmware como producto de ingeniería

El firmware crítico de un convertidor de Premium SA se diseña con la misma disciplina que un módulo de potencia. Los pilares son seis y están encadenados: