Un SDK para módulos de cámara térmica es la capa de software y protocolo que permite a un sistema OEM configurar el detector, adquirir vídeo térmico, leer telemetría, controlar funciones de procesamiento de imagen e integrar el módulo dentro de un producto mayor. En módulos infrarrojos, el diseño del SDK está estrechamente ligado a la interfaz de vídeo, el canal de comandos, los requisitos radiométricos, el comportamiento del obturador o de la corrección de no uniformidad, y la plataforma anfitriona. Un plan de integración fiable debe definir no solo cómo se reciben los fotogramas, sino también cómo se gestionan los estados de ganancia, los datos de temperatura, las tablas de calibración, la sincronización temporal y las actualizaciones de firmware durante todo el ciclo de vida del producto.
Cómo funciona un SDK para módulos de cámara térmica
Un SDK para cámara térmica normalmente encapsula la comunicación de bajo nivel en bibliotecas para el host, aplicaciones de ejemplo, cabeceras y documentación. Puede ofrecer APIs en C, C++, C#, Python o interfaces específicas de plataforma, según el sistema objetivo. En un producto embebido, el SDK suele ejecutarse en Linux, Windows o en un procesador edge basado en ARM, y se comunica con el módulo mediante USB, UART, Ethernet, Camera Link, MIPI CSI-2, LVDS u otra interfaz definida.
El SDK suele separar la adquisición de vídeo del mando y control. El transporte de vídeo lleva el flujo de imagen, mientras que un canal de control independiente configura parámetros como tiempo de integración, frecuencia de imagen, zoom digital, polaridad, corrección de no uniformidad, control automático de ganancia, salida radiométrica y estado de autodiagnóstico. Algunos sistemas multiplexan datos de control en el mismo enlace físico que el vídeo; otros usan un canal serie o de red dedicado para un tratamiento de comandos más determinista.
Un SDK práctico también incluye gestión de búferes. El vídeo infrarrojo puede entregarse como datos de visualización de 8 bits, datos brutos de 14 o 16 bits, o datos radiométricos relacionados con temperatura. La aplicación host debe conocer formato de píxel, orden de bytes, stride, método de sincronización y ubicación de metadatos. En módulos de alta resolución como el SPECTRA L12 1280×1024 LWIR, el tamaño de búfer, el ancho de banda de memoria y el presupuesto de latencia forman parte de la arquitectura de integración, no son detalles menores de implementación.
El SDK no debe tratarse como un simple visor de demostración. En sistemas de producción, lo importante es si proporciona APIs estables para inicialización repetible, gestión determinista de errores, lectura de versiones de firmware, control del estado de calibración y operación prolongada. Los ingenieros OEM deben verificar que el SDK pueda ejecutarse sin interfaz gráfica, que soporte el compilador y las versiones de sistema operativo previstas, y que pueda incorporarse a una infraestructura de pruebas automatizadas.
SDK de cámara térmica vs protocolo de control
El SDK y el protocolo de control están relacionados, pero no son lo mismo. El protocolo de control es el conjunto de comandos orientado al dispositivo: define IDs de comando, mapas de registros, estructuras de paquete, checksums, códigos de respuesta, requisitos temporales y rangos de parámetros. El SDK es la capa de software orientada al host que implementa o abstrae ese protocolo para los desarrolladores de aplicación.
Usar el SDK suele ser más rápido para pruebas de concepto y fases tempranas de desarrollo. Reduce la necesidad de implementar manualmente tramas de paquetes, lógica de reintento y análisis del flujo de vídeo. También ayuda a confirmar el comportamiento esperado mediante herramientas de referencia suministradas por el fabricante. Para muchos equipos OEM, es el punto de partida adecuado mientras las decisiones eléctricas, ópticas y mecánicas aún cambian.
La integración directa del protocolo suele preferirse en sistemas profundamente embebidos, productos certificados o plataformas con políticas estrictas de control de software. Un vehículo, una carga útil UAV, un robot móvil o un sensor de seguridad perimetral puede requerir una pila de control pequeña, sin dependencias externas de ejecución. En estos casos, el OEM puede implementar el protocolo directamente y usar el SDK como referencia durante la validación. La contrapartida es el esfuerzo: trabajar a nivel de protocolo exige más atención a compatibilidad de versiones, secuenciación de comandos y recuperación ante fallos.
El modelo más eficaz a menudo es híbrido. El OEM usa el SDK durante desarrollo, cualificación y utillaje de fábrica, y después implementa un controlador de protocolo compacto en el dispositivo final. Este enfoque funciona bien cuando el proveedor entrega tanto un SDK documentado como un documento estable de control de interfaz. También simplifica la calibración en fabricación: el software de producción puede usar el SDK completo, mientras que el producto desplegado emplea solo los comandos necesarios en operación.
Qué parámetros debe exponer el SDK para integración OEM
Un SDK útil debe exponer parámetros en tres niveles: operación del detector, procesamiento de imagen y gestión del sistema. Los controles del detector incluyen frecuencia de imagen, modo de ganancia, tiempo de integración, windowing, corrección de no uniformidad, sustitución de píxeles defectuosos, control de obturador para módulos LWIR no refrigerados y control del enfriador para módulos MWIR refrigerados. Estos ajustes afectan sensibilidad, estabilidad, tiempo de arranque y comportamiento de imagen dependiente de la escena.
Los controles de procesamiento incluyen control automático de ganancia, mejora de contraste, polaridad, selección de paleta, zoom digital, volteo de imagen, filtrado de ruido, realce de bordes y estadísticas de región de interés. En aplicaciones solo de visualización, estas funciones pueden ajustarse para interpretación del operador. En visión artificial o IA, un realce excesivo puede reducir la repetibilidad algorítmica. El OEM debe definir si el software aguas abajo consume vídeo procesado, datos brutos linealizados o datos radiométricos calibrados.
La telemetría es igual de importante. El SDK debe dar acceso a temperatura del módulo, estado del detector, estado de tensión de alimentación, contadores de fotogramas, marcas temporales, estado de calibración, códigos de error y versiones de firmware. La telemetría permite distinguir entre un evento de escena y un cambio de estado del módulo. Por ejemplo, un desplazamiento temporal de imagen tras una corrección de no uniformidad no debería interpretarse como movimiento de un objetivo por el software de seguimiento.
Los módulos radiométricos requieren parámetros adicionales: emisividad, temperatura aparente reflejada, entradas de corrección atmosférica, distancia, modos de cálculo de temperatura de objeto e identificadores de tablas de calibración. En inspección eléctrica, monitorización de procesos y diagnóstico de equipos, estas variables determinan si el sistema produce solo una imagen útil o una medición de temperatura defendible. Por eso, aplicaciones como Power Inspection deben evaluar pronto el modelo de control radiométrico.
Para productos dual-band y multisensor, el SDK también debe cubrir sincronización y registro. El software OEM puede necesitar parámetros de alineación, timestamps sincronizados, controles de exposición separados y lógica de selección de flujos. Sin soporte claro de API, la fusión de imagen se vuelve frágil cuando cambian frecuencias de imagen, resoluciones o modos de procesamiento.
Ethernet, serial, MIPI, USB o Camera Link para control térmico
La elección de interfaz condiciona tanto la arquitectura del SDK como el protocolo. Ethernet es habitual cuando el módulo térmico o subsistema de imagen se instala lejos del procesador host, cuando varios clientes necesitan acceso o cuando el producto final debe soportar vídeo IP. También facilita configuración remota, diagnóstico y servicio de campo. El coste es mayor complejidad de red, gestión de pérdida de paquetes, revisión de ciberseguridad y, a veces, más latencia extremo a extremo.
El control serie mediante UART, RS-232 o RS-422 sigue siendo común en cargas embebidas porque es simple, determinista y fácil de aislar. Un canal serie puede coexistir con vídeo analógico, LVDS, Camera Link, SDI o MIPI. Suele bastar para parámetros que cambian con baja frecuencia, como modo de ganancia o comandos de calibración. Es menos adecuado cuando deben transferirse grandes archivos de calibración, telemetría frecuente o metadatos complejos.
MIPI CSI-2 es atractivo en plataformas embebidas compactas porque conecta directamente con muchos pipelines de imagen en system-on-chip. Encaja bien en pequeños UAV, equipos portátiles, robots móviles y productos con restricciones de tamaño, peso, consumo y área de placa. El reto es que MIPI es principalmente un transporte de vídeo; el control de comandos, el manejo de metadatos y el soporte de drivers siguen necesitando definición cuidadosa. Para un módulo como el FUSION LV0625A 640×512+2560×1440 MIPI 35mm, el OEM debe confirmar número de lanes, reloj, uso de canales virtuales, sincronización de fotogramas y compatibilidad con el ISP del host.
USB puede acelerar el desarrollo porque está ampliamente soportado en PCs y muchos sistemas embebidos. Funciona bien para evaluación en laboratorio, estaciones de prueba de producción y algunos instrumentos portátiles. Sin embargo, su comportamiento depende del controlador host, la planificación del sistema operativo, la calidad del cable y la gestión de energía. En plataformas OEM de larga vida, conviene validar recuperación tras suspensión, desconexión, sobrecarga y operación a alta temperatura.
Camera Link y otras interfaces industriales siguen siendo relevantes cuando importan el transporte determinista y los ecosistemas de frame grabbers. Es común en defensa, aeroespacial, inspección industrial e imagen científica. Para contexto de caracterización de sistemas IR, normas como ISO 18251-1:2017 describen componentes y características de sistemas de termografía infrarroja, aunque el control del módulo siga dependiendo del protocolo específico del fabricante.
Cómo validar latencia, estabilidad y compatibilidad de versiones
La validación del SDK debe comenzar con una secuencia de inicialización repetible. El host debe alimentar el módulo, detectarlo, consultar identificadores de hardware y firmware, aplicar la configuración requerida, iniciar streaming y verificar consistencia entre vídeo y telemetría. Esta secuencia debe probarse tras arranque en frío, reinicio en caliente, reinicio del host, reset del módulo e interrupción del enlace de comunicación.
La medición de latencia debe separar exposición del sensor, procesamiento interno de imagen, retardo de transporte, búferes del host, renderizado y tiempo de decisión de la aplicación. La latencia de visualización puede ser aceptable para observación humana, pero excesiva para seguimiento, navegación o asistencia de control de tiro. En sistemas con IA como el NEXUS LV0619B AI multi-band Ethernet/SDI, el equipo de integración debe medir tanto la latencia de imagen como la de inferencia con frecuencias de imagen y condiciones de red realistas.
Las pruebas de larga duración son necesarias porque muchos fallos de integración no aparecen en demostraciones cortas. El host debe registrar contadores de fotogramas, fotogramas perdidos, fallos de comando, excursiones de telemetría, crecimiento de memoria, carga de CPU y eventos de recuperación durante horas o días. Las pruebas deben incluir ciclos térmicos, vibración cuando aplique, cambios rápidos de escena, escenas de bajo contraste, escenas de alto rango dinámico y ciclos repetidos de corrección de no uniformidad.
El control de versiones es otro punto práctico. SDK, firmware, archivos de calibración, protocolo de comandos y aplicación host deben tratarse como un conjunto controlado. Un producto debe poder informar exactamente qué firmware de módulo y qué interfaz SDK utiliza. Si el proveedor actualiza firmware para añadir funciones o mejorar calidad de imagen, el OEM debe hacer regresión sobre comportamiento de comandos, valores por defecto, metadatos y compatibilidad de formato de imagen antes del despliegue. Para equipos usados en ensayos no destructivos, ISO 10880:2017 aporta un marco general útil sobre principios de termografía infrarroja.
La revisión de ciberseguridad es obligatoria cuando el control se expone por Ethernet o se integra en un sistema administrado remotamente. Descubrimiento de dispositivo, autenticación, rutas de actualización de firmware, puertos de depuración y servicios de red deben revisarse como parte del producto final, no solo del módulo.
Cuándo usar el control SDK en la selección de un producto OEM
La madurez del SDK y del protocolo debe influir en la selección del módulo tanto como el formato del detector o la compatibilidad de lentes. Un módulo con excelente rendimiento de imagen puede crear riesgo de programa si el host no puede configurarlo, recuperarlo o validar su estado de forma fiable. Durante la evaluación de proveedores, el equipo OEM debe solicitar paquete SDK, documentación del protocolo, código de ejemplo, notas de versión, sistemas operativos soportados, proceso de actualización de firmware y limitaciones conocidas.
El nivel de control requerido depende de la aplicación. Un nodo fijo de ciudad inteligente puede necesitar streaming Ethernet estable, configuración remota y operación desatendida prolongada. Una carga UAV puede priorizar arranque determinista, baja latencia, drivers compactos y metadatos sincronizados. Un sistema vehicular puede requerir recuperación robusta ante ciclos de alimentación, validación de rango térmico e integración con la arquitectura electrónica existente.
También conviene comprobar si el proveedor soporta flujos de producción. Alineación de fábrica, calibración de lente, programación de número de serie, verificación radiométrica y pruebas de fin de línea suelen necesitar hooks de software que no se ven en un visor simple. La separación clara entre herramientas de ingeniería, producción y servicio de campo reduce la carga de soporte después del lanzamiento. Como referencia técnica general, SPIE ofrece recursos sobre detectores térmicos que ayudan a contextualizar cómo los mecanismos físicos del detector afectan sensibilidad, calibración y estabilidad.
FAQ
¿Cuál es la diferencia entre un SDK de cámara térmica y una API?
Un SDK de cámara térmica es el paquete de software completo. Puede incluir APIs, bibliotecas, drivers, aplicaciones de ejemplo, documentación, herramientas de firmware y utilidades de prueba. La API es la interfaz programable que invoca la aplicación host. En la práctica, el OEM evalúa ambas: la API para integración y el SDK completo para desarrollo, pruebas y mantenimiento.
¿Todos los módulos de cámara térmica necesitan un protocolo de control propio?
No siempre. Algunos productos de cámara en red exponen interfaces estandarizadas para streaming o gestión, pero el control del detector a nivel de módulo suele ser específico del fabricante. Parámetros como corrección de no uniformidad, estado de ganancia, operación del enfriador, modo radiométrico y datos de calibración normalmente requieren un SDK o protocolo específico.
¿Conviene usar datos térmicos brutos o vídeo procesado?
Los datos brutos o linealizados son preferibles cuando se necesitan algoritmos, radiometría o analítica repetible. El vídeo procesado suele ser mejor para observación humana, porque el control automático de ganancia y la mejora de contraste facilitan la interpretación visual. Muchos sistemas OEM usan ambos: datos brutos para cálculo y vídeo procesado para el operador.
¿Cómo deben gestionarse las actualizaciones de firmware?
Deben estar controladas, registradas y probadas por regresión junto con la aplicación host. El OEM debe verificar compatibilidad de comandos, arranque, formato de imagen, metadatos, validez de calibración y recuperación tras una actualización fallida o interrumpida. Los equipos en producción deben informar versiones de firmware y SDK para trazabilidad de servicio.
¿Qué revisar antes de elegir un SDK para módulo térmico?
Soporte de sistema operativo, lenguajes disponibles, calidad del código de ejemplo, documentación del protocolo, latencia, acceso a metadatos, controles radiométricos, estabilidad prolongada, herramientas de actualización de firmware y soporte del proveedor para pruebas de producción. Estos factores afectan directamente coste de integración y riesgo de calendario en productos OEM de larga vida.
