La escalera de validación
Ninguna prueba demuestra por sí sola una controladora de vuelo. Los equipos ganan confianza paso a paso, pasando de pruebas rápidas, baratas y seguras a otras lentas, caras y arriesgadas:
| Etapa | Qué prueba | Qué no cubre |
|---|---|---|
| Pruebas unitarias y de módulo | Funciones, filtros y máquinas de estado individuales | Interacciones, temporización y hardware |
| Software-in-the-loop (SIL) | Todo el código de vuelo frente a un vehículo simulado en un PC | Temporización real del procesador, sensores y E/S reales |
| Hardware-in-the-loop (HITL) | La placa real de la controladora con un vehículo simulado | Los sensores reales y su montaje |
| Banco de pruebas de actitud | Sensores reales y control de actitud bajo rotación física | Traslación, aerodinámica y condiciones exteriores |
| Vuelo cautivo y pruebas de vuelo | Todo a la vez | Nada, pero cada prueba cuesta tiempo y conlleva riesgo |
Software-in-the-loop: pruebe cada cambio
ArduPilot y PX4 incluyen simuladores software-in-the-loop (SITL) que ejecutan el código de vuelo real en un PC frente a un modelo del vehículo, con Gazebo y otros motores físicos disponibles. Como SIL no necesita hardware, puede ejecutarse automáticamente en cada cambio de código: misiones, failsafes, cambios de parámetros y casos límite que serían peligrosos en el aire.
Su punto ciego es todo lo físico: carga y temporización del procesador, ruido de los sensores, cableado y la interacción entre el chasis y el controlador.
Hardware-in-the-loop: la placa real en un mundo simulado
En HITL el código de vuelo se ejecuta en la placa real de la controladora. El simulador sustituye los sensores por datos simulados y lee las salidas de los motores, de modo que se ponen a prueba el procesador, el planificador y los enlaces de comunicación reales. PX4 ofrece un modo HITL para ello, y los bancos HIL a medida hacen lo mismo con E/S dedicadas.
HITL encuentra desbordamientos de tiempo, errores de interfaz y fallos de configuración que SIL no puede ver. Aun así, sigue sin pasar por los sensores físicos, y ahí entra una plataforma de movimiento. La guía de pruebas HIL explica cómo se construyen estos bancos.
Bancos de actitud: sensores reales, movimiento real
En un banco de 3 ejes el vehículo completo, o la controladora en su montaje real, gira en alabeo, cabeceo y guiñada pero no puede trasladarse. Sus propios giróscopos y acelerómetros perciben un movimiento real, de modo que la alineación de los sensores, la vibración, el filtrado y el estimador de actitud se prueban juntos, y los encoders de los ejes aportan una referencia independiente para la estimación.
Una plataforma motorizada puede repetir el mismo perfil en cada ejecución, lo que convierte la prueba de actitud en una prueba de regresión. Con un modelo del vehículo en el lazo, la plataforma puede seguir la actitud que el modelo calcula a partir de las salidas del controlador: HIL físico. INFINITE-HIL X1 está pensado para esta etapa, y la guía del banco de pruebas 3-DOF repasa los tipos de banco y los criterios de selección.
Casos de prueba que conviene automatizar
- Escalones y barridos en frecuencia en cada eje, para comparar la respuesta de actitud entre versiones de firmware. La guía de ajuste PID explica qué observar.
- Rechazo de perturbaciones: ráfagas o pares de perturbación introducidos a través del modelo o de la plataforma.
- Fallos de sensores: un giróscopo congelado, un acelerómetro con sesgo, pérdida de GNSS o interferencia en el magnetómetro, y el failsafe que debería seguir.
- Fallos de actuadores: un motor débil o averiado y la reacción del controlador.
- Precisión del estimador: la estimación de actitud frente a la referencia medida durante movimientos largos y combinados.
- Temporización y carga: frecuencias de lazo y carga del procesador con el registro, la telemetría y el software de carga útil en marcha.
Conviértalo en una prueba de regresión
- Congele el escenario. Guarde perfiles, versiones de modelos y parámetros junto con la versión de firmware que prueban.
- Defina criterios de aceptación. Sobreoscilación, tiempo de establecimiento, error de estimación o tiempo de respuesta del failsafe, con límites acordados antes de probar.
- Ejecute en cada versión. SIL en cada cambio de código; HITL y pruebas en banco en cada versión candidata.
- Compare los registros. Mantenga consignas, estimaciones y referencias medidas en una misma base de tiempo para poder superponer las ejecuciones.
- Cierre el lazo con datos de vuelo. Cuando un vuelo revele un problema, añada un caso de prueba que lo reproduzca en tierra.
Lo que solo las pruebas de vuelo pueden demostrar
La aerodinámica, la dinámica de traslación, el viento real, el comportamiento del GNSS y el entorno operativo completo solo pueden validarse en el aire. Las etapas anteriores no sustituyen a las pruebas de vuelo; permiten llegar a ellas con menos incógnitas, con campañas más cortas, menos accidentes y vuelos que confirman en lugar de descubrir.
Para el software aeronáutico certificado, normas como DO-178C definen las evidencias de verificación necesarias, y un enfoque por etapas como este ayuda a generarlas. Si quiere hablar de un montaje de prueba para su controladora de vuelo, contacte con nosotros.