{"id":23890,"date":"2026-10-26T15:30:55","date_gmt":"2026-10-26T14:30:55","guid":{"rendered":"https:\/\/premiumpsu.com\/?p=23890"},"modified":"2026-10-26T15:30:55","modified_gmt":"2026-10-26T14:30:55","slug":"verificacion-validacion-tdd-firmware","status":"publish","type":"post","link":"https:\/\/premiumpsu.com\/es\/resources-news\/verificacion-validacion-tdd-firmware\/","title":{"rendered":"Verificaci\u00f3n, validaci\u00f3n y TDD en firmware cr\u00edtico"},"content":{"rendered":"
Engineering Insight \u00b7 V&V de software<\/div>

Verificaci\u00f3n, validaci\u00f3n y TDD en firmware cr\u00edtico de convertidores<\/h1>

Por qu\u00e9 el firmware de un convertidor de potencia es un componente cr\u00edtico de fiabilidad \u2014 y c\u00f3mo lo trata Premium SA<\/p> <\/header>

1981<\/div>
A\u00f1o en que Boehm formul\u00f3 la distinci\u00f3n V&V<\/div> <\/td>
Modelo en V<\/div>
Marco metodol\u00f3gico de EN 50128 para firmware ferroviario<\/div> <\/td>
MC\/DC<\/div>
Cobertura m\u00ednima exigida en SSIL 4<\/div> <\/td>
143<\/div>
Reglas MISRA C:2012 (16 obligatorias)<\/div> <\/td> <\/tr> <\/tbody> <\/table> <\/div>

Resumen ejecutivo<\/h2>

Un convertidor de electr\u00f3nica de potencia moderno es hoy tanto software como hardware. El firmware del controlador ejecuta los lazos de regulaci\u00f3n, las protecciones, la calibraci\u00f3n digital, la gesti\u00f3n t\u00e9rmica activa, la telemetr\u00eda y, en un n\u00famero creciente de casos, funciones de seguridad funcional certificadas seg\u00fan SSIL ferroviario o ASIL de automoci\u00f3n. Cualquier defecto en ese firmware es indistinguible \u2014desde el punto de vista del operador final\u2014 de un defecto de hardware: el equipo no funciona, no cumple su misi\u00f3n, genera penalizaciones contractuales. La diferencia es que el firmware no envejece f\u00edsicamente, pero s\u00ed se degrada en t\u00e9rminos de confianza si no se somete a un proceso disciplinado de verificaci\u00f3n y validaci\u00f3n.<\/p>

Este art\u00edculo repasa los fundamentos del aseguramiento de la calidad del software aplicados al firmware embebido de electr\u00f3nica de potencia: la distinci\u00f3n cr\u00edtica de Boehm entre verificaci\u00f3n y validaci\u00f3n, la disciplina del Test-Driven Development, el modelo en V de la EN 50128, la pir\u00e1mide de pruebas MiL \u2192 SiL \u2192 PiL \u2192 HiL \u2192 SYSiL, las t\u00e9cnicas de caja negra y caja blanca, y el \u00abpantano terminol\u00f3gico\u00bb que persiste en la industria. La tesis es directa: el firmware cr\u00edtico se dise\u00f1a con la misma disciplina con la que dise\u00f1amos un m\u00f3dulo de potencia \u2014perfil de misi\u00f3n, derating, FMEA, V&V\u2014 porque comparte el mismo cliente y los mismos compromisos contractuales.<\/p>

1. El firmware como componente cr\u00edtico: por qu\u00e9 importa la disciplina<\/h2>

Un convertidor t\u00edpico de Premium SA de hace quince a\u00f1os llevaba un firmware m\u00ednimo: una m\u00e1quina de estados elemental, unos pocos lazos PI implementados en aritm\u00e9tica de coma fija y protecciones hardware reforzadas con un par de comprobaciones por software. La complejidad del c\u00f3digo embebido cab\u00eda en unos pocos kilobytes y un experto pod\u00eda revisarla l\u00ednea a l\u00ednea en una tarde. Esa \u00e9poca ha terminado.<\/p>

El convertidor moderno \u2014que integra calibraci\u00f3n digital, gesti\u00f3n t\u00e9rmica activa, control predictivo del rizado del bus DC, comunicaci\u00f3n CAN\/Ethernet\/Modbus con el supervisor del operador, telemetr\u00eda PHM con estimaci\u00f3n de RUL, actualizaci\u00f3n de firmware OTA con firma criptogr\u00e1fica y, posiblemente, funciones de seguridad activa certificadas seg\u00fan SSIL ferroviario\u2014 contiene decenas de miles de l\u00edneas de c\u00f3digo C, organizadas en arquitecturas modulares con HAL, RTOS, tareas con prioridades y librer\u00edas de comunicaciones. La probabilidad de que ese c\u00f3digo sea perfectamente correcto en su primera escritura es, sencillamente, cero.<\/p>

El firmware como componente con una tasa de fallos gestionable.<\/strong> Desde el punto de vista de la fiabilidad RAMS, el firmware es un componente m\u00e1s del sistema. Tiene su propia tasa de fallos, dominada \u2014a diferencia de los componentes f\u00edsicos\u2014 por defectos sistem\u00e1ticos (errores de programaci\u00f3n o de especificaci\u00f3n) y no por defectos aleatorios. La buena noticia es que esos defectos sistem\u00e1ticos pueden atacarse con metodolog\u00eda: un proceso disciplinado de verificaci\u00f3n y validaci\u00f3n los reduce de forma cuantificable. La mala noticia es sim\u00e9trica: sin disciplina, esos defectos permanecen latentes en el c\u00f3digo y afloran \u2014siempre\u2014 en el momento m\u00e1s costoso. Un fallo de firmware detectado en flota tiene exactamente la misma estructura econ\u00f3mica que un fallo de hardware: penalizaci\u00f3n, retirada, FRACAS, propagaci\u00f3n de la correcci\u00f3n a la poblaci\u00f3n instalada. Por eso, en Premium SA, el firmware se trata con la misma seriedad metodol\u00f3gica que el m\u00f3dulo de potencia: D2W \u2192 D2F \u2192 D4R \u2192 D4Co aplicado al software.<\/div>

2. Verificaci\u00f3n y validaci\u00f3n: la distinci\u00f3n de Boehm<\/h2>

La distinci\u00f3n m\u00e1s clarificadora del aseguramiento de la calidad del software la formul\u00f3 Barry Boehm en 1981 mediante dos preguntas aparentemente similares, pero metodol\u00f3gicamente distintas:<\/p>

Las dos preguntas de Boehm.<\/strong> Verificaci\u00f3n: \u00ab\u00bfEstamos construyendo el producto correctamente?\u00bb. Validaci\u00f3n: \u00ab\u00bfEstamos construyendo el producto correcto?\u00bb. La primera pregunta mira hacia dentro: \u00bfrespeta el c\u00f3digo la especificaci\u00f3n t\u00e9cnica? \u00bfCumple cada fase de desarrollo las condiciones fijadas al inicio de esa fase? La segunda mira hacia fuera: \u00bfhace el sistema final lo que el cliente realmente necesita en su entorno de operaci\u00f3n? Ambas son necesarias. Ninguna es suficiente por s\u00ed sola.<\/div>

2.1 Las diferencias pr\u00e1cticas<\/h3>
Dimensi\u00f3n<\/th> Verificaci\u00f3n<\/th> Validaci\u00f3n<\/th> <\/tr> <\/thead>
Pregunta<\/td> \u00bfConstruimos el producto correctamente?<\/td> \u00bfConstruimos el producto correcto?<\/td> <\/tr>
Orientaci\u00f3n<\/td> Al proceso t\u00e9cnico interno<\/td> Al cliente y al uso real<\/td> <\/tr>
Referencia<\/td> Especificaci\u00f3n t\u00e9cnica<\/td> Necesidades del usuario<\/td> <\/tr>
Momento<\/td> Continuo, fase a fase<\/td> Al final del desarrollo o de la integraci\u00f3n<\/td> <\/tr>
T\u00e9cnicas dominantes<\/td> An\u00e1lisis est\u00e1tico, revisiones, pruebas unitarias, MISRA, MC\/DC<\/td> Pruebas de sistema, pruebas de aceptaci\u00f3n, HIL completo<\/td> <\/tr>
Granularidad<\/td> Pruebas \u00aba peque\u00f1a escala\u00bb<\/td> Pruebas \u00aba gran escala\u00bb<\/td> <\/tr>
Qui\u00e9n decide<\/td> El equipo t\u00e9cnico<\/td> El cliente \/ usuario final<\/td> <\/tr>
Automatizable<\/td> Mayoritariamente s\u00ed<\/td> Parcialmente: la \u00faltima palabra es humana<\/td> <\/tr>
Tipo de error que detecta<\/td> Errores de implementaci\u00f3n frente a la especificaci\u00f3n<\/td> Errores de la especificaci\u00f3n frente al mundo real<\/td> <\/tr> <\/tbody> <\/table> <\/div>

2.2 Por qu\u00e9 ambas son necesarias<\/h3>

Una verificaci\u00f3n impecable sin validaci\u00f3n produce c\u00f3digo t\u00e9cnicamente correcto que satisface una especificaci\u00f3n que ya era defectuosa: el equipo cumple sus obligaciones y el cliente recibe un producto que no resuelve su problema. Una validaci\u00f3n vigorosa sin verificaci\u00f3n produce c\u00f3digo que \u00abfunciona en la demo\u00bb, pero esconde defectos estructurales que afloran en condiciones de operaci\u00f3n no contempladas en la prueba de aceptaci\u00f3n. Las dos disciplinas son complementarias y atacan clases de error distintas, y ninguna estrategia seria de ingenier\u00eda del software puede prescindir de ninguna de ellas.<\/p>

3. El pantano terminol\u00f3gico: error, defecto, fallo, incidente<\/h2>

Cualquier discusi\u00f3n seria sobre la calidad del software arrastra el problema hist\u00f3rico del vocabulario. M\u00faltiples t\u00e9rminos clave \u2014verificaci\u00f3n, validaci\u00f3n, prueba, error, defecto, falta, fallo\u2014 est\u00e1n sobrecargados de significados contradictorios en la literatura. Un equipo que usa estos t\u00e9rminos de forma intercambiable comete, sin saberlo, errores de razonamiento que se traducen en errores de proceso. Conviene anclar el vocabulario a la norma IEEE.<\/p>

T\u00e9rmino<\/th> Definici\u00f3n precisa<\/th> Ejemplo en un convertidor de potencia<\/th> <\/tr> <\/thead>
Error<\/strong><\/td> Acci\u00f3n humana incorrecta. Equivocaci\u00f3n en la especificaci\u00f3n, el dise\u00f1o o la codificaci\u00f3n<\/td> Un ingeniero asume que el sensor de corriente es bipolar cuando es unipolar<\/td> <\/tr>
Defecto \/ falta \/ bug<\/strong><\/td> Manifestaci\u00f3n interna del error. Estado incorrecto incrustado en el c\u00f3digo<\/td> Una rama del c\u00e1lculo de la protecci\u00f3n OCP que nunca se ejecuta porque la condici\u00f3n es imposible<\/td> <\/tr>
Fallo<\/strong><\/td> Incapacidad observable del sistema para cumplir su funci\u00f3n: el s\u00edntoma visible<\/td> El convertidor no dispara la protecci\u00f3n OCP cuando la corriente supera el umbral<\/td> <\/tr>
Incidente<\/strong><\/td> Evento an\u00f3malo durante la ejecuci\u00f3n que merece registro y an\u00e1lisis<\/td> El operador informa de una parada inesperada que no coincide con ninguna causa conocida<\/td> <\/tr> <\/tbody> <\/table> <\/div>
Por qu\u00e9 importa la cadena causal.<\/strong> Una persona comete un error \u2192 el error introduce un defecto en el c\u00f3digo \u2192 el defecto puede manifestarse o no como fallo al ejecutarse. Un defecto puede vivir en el c\u00f3digo durante a\u00f1os sin causar nunca un fallo, simplemente porque a\u00fan no se han dado las condiciones concretas que lo activan. Este matiz explica por qu\u00e9 las pruebas exhaustivas son imposibles y por qu\u00e9 importa el dise\u00f1o deliberado de los casos de prueba. La estrategia no es probarlo todo (imposible), sino probar bien: las condiciones con m\u00e1s probabilidad de activar defectos latentes.<\/div>

4. El modelo en V: verificaci\u00f3n en cada nivel<\/h2>

El marco metodol\u00f3gico que articula la verificaci\u00f3n a lo largo del ciclo de vida del software es el modelo en V. Su propuesta es estructural: a cada nivel de especificaci\u00f3n le corresponde un nivel sim\u00e9trico de verificaci\u00f3n. La rama izquierda desciende de los requisitos al c\u00f3digo; la rama derecha asciende de la verificaci\u00f3n unitaria a la aceptaci\u00f3n final. El modelo en V es la columna vertebral de la EN 50128 (ferrocarril), la IEC 61508 (gen\u00e9rica), la ISO 26262 (automoci\u00f3n) y la DO-178C (avi\u00f3nica).<\/p>

4.1 Las correspondencias de la V<\/h3>
Nivel de especificaci\u00f3n (rama izquierda)<\/th> Nivel de verificaci\u00f3n (rama derecha)<\/th> Pregunta que responde<\/th> <\/tr> <\/thead>
Requisitos del sistema (SyRS)<\/td> Pruebas de aceptaci\u00f3n \/ validaci\u00f3n del sistema<\/td> \u00bfCumple el sistema las necesidades del usuario?<\/td> <\/tr>
Requisitos del software (SRS)<\/td> Pruebas de sistema sobre el firmware<\/td> \u00bfSatisface el firmware su especificaci\u00f3n funcional?<\/td> <\/tr>
Dise\u00f1o de arquitectura<\/td> Pruebas de integraci\u00f3n entre m\u00f3dulos<\/td> \u00bfColaboran los m\u00f3dulos seg\u00fan lo dise\u00f1ado?<\/td> <\/tr>
Dise\u00f1o de m\u00f3dulos<\/td> Pruebas unitarias por m\u00f3dulo<\/td> \u00bfHace cada m\u00f3dulo lo que dice su contrato?<\/td> <\/tr>
C\u00f3digo fuente<\/td> An\u00e1lisis est\u00e1tico + inspecci\u00f3n<\/td> \u00bfEst\u00e1 el c\u00f3digo libre de patrones peligrosos?<\/td> <\/tr> <\/tbody> <\/table> <\/div>

4.2 SSIL: niveles de integridad de seguridad del software<\/h3>

La EN 50128 define cinco niveles de integridad del software: Basic Integrity y SSIL 1 a SSIL 4. Cada nivel impone t\u00e9cnicas de V&V obligatorias, cuyo rigor aumenta con la criticidad de la funci\u00f3n. Premium SA asigna sus aplicaciones a estos niveles seg\u00fan la responsabilidad de cada bloque de firmware:<\/p>

Nivel SSIL<\/th> Aplicaci\u00f3n t\u00edpica en convertidores de Premium SA<\/th> T\u00e9cnicas obligatorias EN 50128<\/th> <\/tr> <\/thead>
Basic Integrity<\/td> Funciones no relacionadas con la seguridad: telemetr\u00eda, registro, interfaz de usuario<\/td> Revisi\u00f3n de c\u00f3digo, pruebas funcionales<\/td> <\/tr>
SSIL 1-2<\/td> Auxiliares de cabina, protecciones est\u00e1ndar OVP\/OCP\/OTP<\/td> An\u00e1lisis est\u00e1tico MISRA C, pruebas unitarias con cobertura de E\/S<\/td> <\/tr>
SSIL 3<\/td> Convertidores de tracci\u00f3n no cr\u00edticos para el freno, BMS de veh\u00edculo el\u00e9ctrico<\/td> MISRA + cobertura de decisiones + an\u00e1lisis del tiempo de respuesta<\/td> <\/tr>
SSIL 4<\/td> Funciones de seguridad activa (inhibici\u00f3n del freno regenerativo)<\/td> MC\/DC + modelos formales + redundancia diversa<\/td> <\/tr> <\/tbody> <\/table> <\/div>

5. Test-Driven Development: las pruebas como decisi\u00f3n de dise\u00f1o<\/h2>

El Test-Driven Development (TDD, desarrollo guiado por pruebas) surgi\u00f3 a principios de los a\u00f1os 2000 como uno de los pilares de Extreme Programming y representa una inversi\u00f3n radical del flujo de trabajo tradicional. En el orden cl\u00e1sico, el programador escribe primero la funcionalidad y despu\u00e9s \u2014si hay tiempo\u2014 a\u00f1ade pruebas para verificarla. En TDD el orden se invierte: la prueba se escribe primero, antes de que exista la funcionalidad.<\/p>

5.1 El ciclo Red-Green-Refactor<\/h3>
Fase<\/th> Acci\u00f3n del desarrollador<\/th> Estado del c\u00f3digo<\/th> <\/tr> <\/thead>
Red<\/strong><\/td> Escribir una prueba unitaria para una funcionalidad que a\u00fan no existe<\/td> La prueba falla: confirma que mide algo real<\/td> <\/tr>
Green<\/strong><\/td> Escribir el c\u00f3digo m\u00ednimo para que la prueba pase<\/td> La prueba pasa: el comportamiento m\u00ednimo est\u00e1 implementado<\/td> <\/tr>
Refactor<\/strong><\/td> Reestructurar el c\u00f3digo para eliminar duplicidades y mejorar el dise\u00f1o, sin alterar el comportamiento<\/td> Las pruebas siguen pasando: el comportamiento se conserva<\/td> <\/tr> <\/tbody> <\/table> <\/div>

El ciclo se repite en incrementos peque\u00f1os: minutos, no horas. Tras una sesi\u00f3n de TDD, el desarrollador ha producido tanto el c\u00f3digo de producci\u00f3n como su bater\u00eda de pruebas, y cada l\u00ednea del primero est\u00e1 respaldada por al menos una de las segundas. La consecuencia metodol\u00f3gica m\u00e1s profunda no es tener pruebas, sino el orden invertido: pensar la prueba antes que la implementaci\u00f3n obliga al desarrollador a entender exactamente qu\u00e9 significa el \u00e9xito o el fallo de la funcionalidad. Eso es, en \u00faltima instancia, un acto de dise\u00f1o.<\/p>

5.2 El TDD como sustituto parcial del dise\u00f1o tradicional<\/h3>
El TDD es m\u00e1s dise\u00f1o que pruebas.<\/strong> Las fuentes acad\u00e9micas y la experiencia industrial convergen en una observaci\u00f3n contraintuitiva: el TDD no es principalmente una t\u00e9cnica de pruebas, sino de dise\u00f1o. El esfuerzo de pensar la prueba antes que el c\u00f3digo obliga al desarrollador a aclarar el contrato de cada funci\u00f3n: qu\u00e9 entradas acepta, qu\u00e9 salidas produce, qu\u00e9 efectos secundarios tiene, qu\u00e9 condiciones de error contempla. Gran parte del trabajo que tradicionalmente se hace en \u00aban\u00e1lisis y dise\u00f1o\u00bb queda absorbido en el ciclo Red-Green-Refactor. Los beneficios documentados son consistentes: c\u00f3digo mejor dise\u00f1ado y m\u00e1s limpio, mayor escalabilidad, menor tasa de defectos y una reducci\u00f3n dr\u00e1stica del tiempo de regresi\u00f3n gracias a las pruebas automatizadas. El precio es una curva de aprendizaje significativa: el TDD exige una capacidad de pensamiento de orden superior para aplicarlo bajo presi\u00f3n, y los estudios pedag\u00f3gicos sugieren que su dominio solo se interioriza con un equilibrio del 80 % de pr\u00e1ctica y el 20 % de teor\u00eda.<\/div>

5.3 TDD, BDD y ATDD: la evoluci\u00f3n hacia el comportamiento<\/h3>

El TDD puro es eficaz, pero tiene un l\u00edmite: es puramente t\u00e9cnico. Un equipo que solo usa TDD puede producir c\u00f3digo que supera todas las pruebas unitarias y, aun as\u00ed, resulta incoherente con las necesidades reales de las partes interesadas. Han surgido dos variantes para cerrar esta brecha. El BDD (Behavior-Driven Development) ampl\u00eda el TDD centr\u00e1ndose en el comportamiento esperado del sistema, expresado en un lenguaje ubicuo (Given-When-Then) que tanto desarrolladores como clientes pueden entender: la especificaci\u00f3n no se traduce a pruebas, la especificaci\u00f3n es la prueba. El ATDD (Acceptance Test-Driven Development) combina la especificaci\u00f3n de requisitos con pruebas de aceptaci\u00f3n automatizadas escritas antes del c\u00f3digo. Las tres pr\u00e1cticas son complementarias: el TDD garantiza que cada funci\u00f3n est\u00e9 bien dise\u00f1ada t\u00e9cnicamente; el ATDD, que el sistema completo cumpla su prop\u00f3sito de negocio; y el BDD aporta el puente ling\u00fc\u00edstico entre ambos.<\/p>

6. Fundamentos de las pruebas: qu\u00e9 probamos y c\u00f3mo<\/h2>

Como se\u00f1al\u00f3 Edsger Dijkstra, las pruebas pueden ser muy eficaces para demostrar la presencia de errores, pero son irremediablemente insuficientes para demostrar su ausencia. Esta limitaci\u00f3n es estructural: el dominio de entradas de cualquier programa no trivial es tan grande que probar exhaustivamente todas las combinaciones es, en la pr\u00e1ctica, 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\u00edsticas cr\u00edticas del sistema.<\/p>

6.1 El caso de prueba y el or\u00e1culo<\/h3>

La unidad b\u00e1sica 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\u00edcita o expl\u00edcitamente, un or\u00e1culo: el \u00e1rbitro que decide si el resultado obtenido es correcto. En sistemas sencillos, el or\u00e1culo es la propia especificaci\u00f3n. En sistemas complejos sin especificaci\u00f3n cerrada, el or\u00e1culo es un experto humano: el responsable de pruebas que decide si el comportamiento observado coincide con el esperado.<\/p>

6.2 Caja negra, caja blanca y la distinci\u00f3n cr\u00edtica<\/h3>
Aspecto<\/th> Caja negra (pruebas funcionales)<\/th> Caja blanca (pruebas estructurales)<\/th> <\/tr> <\/thead>
Conocimiento del c\u00f3digo<\/td> Ninguno: solo se conoce la especificaci\u00f3n<\/td> Total: incluye la implementaci\u00f3n interna<\/td> <\/tr>
Dise\u00f1o de casos<\/td> A partir de entradas\/salidas esperadas<\/td> A partir de los caminos del flujo de control<\/td> <\/tr>
M\u00e9tricas de cobertura<\/td> Cobertura de requisitos \/ clases de equivalencia<\/td> Cobertura de sentencias, ramas, MC\/DC, caminos<\/td> <\/tr>
Detecta<\/td> Discrepancias frente a la especificaci\u00f3n funcional<\/td> Defectos estructurales, c\u00f3digo muerto, ramas no probadas<\/td> <\/tr>
Ejemplo en firmware de Premium SA<\/td> El convertidor regula la tensi\u00f3n de salida con un error < 2 % con perfiles de carga est\u00e1ndar<\/td> Cada rama de la rutina de interrupci\u00f3n del ADC se ejecuta al menos una vez<\/td> <\/tr>
Limitaci\u00f3n<\/td> No detecta defectos en c\u00f3digo no especificado<\/td> No detecta requisitos ausentes<\/td> <\/tr> <\/tbody> <\/table> <\/div>
El cambio de mentalidad que m\u00e1s cuesta.<\/strong> El principio fundacional de las pruebas modernas \u2014y el m\u00e1s dif\u00edcil de interiorizar para un equipo joven\u2014 es que la prueba no es una demostraci\u00f3n de que el programa funciona, sino un proceso deliberadamente destructivo dise\u00f1ado para encontrar sus errores. Un ciclo de pruebas verdaderamente exitoso es aquel que consigue hacer fallar el sistema y saca a la luz defectos latentes. Un ciclo en el que todo pasa al primer intento no es bueno: es sospechoso. Esta inversi\u00f3n de actitud cambia incluso qui\u00e9n hace las pruebas. En proyectos cr\u00edticos, las pruebas las dise\u00f1a \u2014siempre que sea posible\u2014 alguien distinto del autor del c\u00f3digo, porque el sesgo de confirmaci\u00f3n del autor es uno de los mayores enemigos de unas buenas pruebas. En Premium SA, las pruebas de SSIL \u2265 2 las revisa un Validador independiente del Dise\u00f1ador.<\/div>

7. La pir\u00e1mide MiL \u2192 SiL \u2192 PiL \u2192 HiL \u2192 SYSiL<\/h2>

En el firmware embebido \u2014donde el c\u00f3digo se ejecuta en un microcontrolador acoplado a un sistema f\u00edsico real\u2014, la disciplina de pruebas a\u00f1ade una capa de complejidad que no existe en el software de aplicaci\u00f3n cl\u00e1sico. Las pruebas no pueden limitarse a entradas y salidas digitales; deben cerrar el lazo con el comportamiento f\u00edsico del convertidor. La metodolog\u00eda X-in-the-Loop estructura este reto en cinco niveles progresivos:<\/p>

Nivel<\/th> Qu\u00e9 se prueba<\/th> Plataforma de pruebas<\/th> <\/tr> <\/thead>
MiL<\/strong> \u2014 Model-in-the-Loop<\/td> Modelo del sistema (Simulink, Stateflow)<\/td> Simulaci\u00f3n pura en PC; todav\u00eda no hay c\u00f3digo C<\/td> <\/tr>
SiL<\/strong> \u2014 Software-in-the-Loop<\/td> C\u00f3digo C compilado para PC<\/td> Ejecuci\u00f3n en el host; las E\/S se simulan<\/td> <\/tr>
PiL<\/strong> \u2014 Processor-in-the-Loop<\/td> C\u00f3digo binario en un emulador del procesador objetivo<\/td> Verifica la correcci\u00f3n del c\u00f3digo objeto sin hardware f\u00edsico<\/td> <\/tr>
HiL<\/strong> \u2014 Hardware-in-the-Loop<\/td> C\u00f3digo binario en el microcontrolador real<\/td> El firmware se ejecuta en el HW objetivo; la planta se simula en tiempo real<\/td> <\/tr>
SYSiL<\/strong> \u2014 System-in-the-Loop<\/td> Sistema embebido f\u00edsico completo<\/td> Validaci\u00f3n final en banco con hardware real y planta real<\/td> <\/tr> <\/tbody> <\/table> <\/div>

Cada nivel resuelve una clase de defectos antes de a\u00f1adir una capa adicional de complejidad. El MiL captura errores de modelado y del algoritmo de control. El SiL, errores de traducci\u00f3n del modelo al c\u00f3digo. El PiL, errores espec\u00edficos del compilador del procesador objetivo, optimizaciones agresivas y problemas de aritm\u00e9tica finita. El HiL, defectos de integraci\u00f3n firmware-hardware: temporizaci\u00f3n, interrupciones, condiciones de carrera, perif\u00e9ricos. El SYSiL es la validaci\u00f3n final con la planta real.<\/p>

Por qu\u00e9 el HIL es la herramienta m\u00e1s potente del firmware embebido.<\/strong> El HIL cierra el lazo de verificaci\u00f3n del firmware con una potencia operativa dif\u00edcil de exagerar. El microcontrolador real ejecuta el firmware compilado y enlazado exactamente como entrar\u00e1 en producci\u00f3n. Las se\u00f1ales de entrada (sensores de tensi\u00f3n, corriente y temperatura) se sintetizan en tiempo real desde un simulador que emula el comportamiento del bus DC, el transformador, el motor o la carga. El firmware no sabe que las se\u00f1ales son sint\u00e9ticas: para \u00e9l, el sistema es real. Esto permite ejecutar miles de escenarios \u2014incluidos fallos de sensores, transitorios de red, cortocircuitos y sobretensiones\u2014 sin riesgo f\u00edsico para el equipo ni para el banco de pruebas. Un programa HIL bien dise\u00f1ado descubre defectos de integraci\u00f3n hardware\/software que ninguna prueba unitaria podr\u00eda capturar: p\u00e9rdidas de muestras del ADC en interrupciones de alta frecuencia, condiciones de carrera entre tareas del RTOS, condiciones de protecci\u00f3n que se disparan incorrectamente por unos pocos microsegundos. En Premium SA, ning\u00fan firmware cr\u00edtico llega a SYSiL sin haber superado antes un programa HIL exhaustivo.<\/div>

8. El proceso D4Co-SW de Premium SA<\/h2>

Premium SA aplica al firmware el mismo marco metodol\u00f3gico que al hardware: las puertas secuenciales D2W \u2192 D2F \u2192 D4R \u2192 D4Co, adaptadas a las t\u00e9cnicas y entregables propios del software.<\/p>

Puerta<\/th> Significado para el firmware<\/th> Criterios de salida<\/th> <\/tr> <\/thead>
D2W<\/strong> \u2014 Design to Work<\/td> El firmware ejecuta las funciones nominales<\/td> SRS firmada, arquitectura modular definida, prototipo MiL\/SiL en ejecuci\u00f3n<\/td> <\/tr>
D2F<\/strong> \u2014 Design to Function<\/td> El firmware cumple toda la especificaci\u00f3n funcional<\/td> Pruebas unitarias con cobertura de ramas \u2265 90 %, integraci\u00f3n HIL superada<\/td> <\/tr>
D4R<\/strong> \u2014 Design for Reliability<\/td> El firmware mantiene su comportamiento en condiciones adversas<\/td> Inyecci\u00f3n de fallos superada, an\u00e1lisis de tiempos, pruebas de estr\u00e9s del RTOS<\/td> <\/tr>
D4Co<\/strong> \u2014 Design for Compliance<\/td> El firmware cumple la normativa y es mantenible durante 30 a\u00f1os<\/td> Dossier SSIL seg\u00fan EN 50128, MISRA C sin desviaciones, FRACAS activo<\/td> <\/tr> <\/tbody> <\/table> <\/div>

8.1 T\u00e9cnicas innegociables: MISRA, MC\/DC, HIL<\/h3>