Caso · sistemas embarcados
Vídeo en directo desde barcos que pierden el enlace
Una empresa de control industrial necesitaba ver desde tierra las cámaras de embarcaciones de pesca que faenan a cientos de kilómetros de la costa. El problema no era el vídeo: era el enlace, que se cae varias veces al día. Este es el recorrido de la señal y por qué está montado así.
Por qué este caso no tiene capturas de pantalla
El sistema vive en un PC industrial a bordo, en un enlace por satélite y en un servidor en tierra. Una captura de la pantalla del operador enseñaría un reproductor de vídeo, que es justo la parte fácil. Lo que se puede enseñar de verdad es el recorrido de la señal: qué habla con qué, con qué protocolo y qué pasa cuando el barco se queda sin enlace.
El diagrama se dibuja solo, en seis capítulos. Fíjate en el momento en que el trazo del enlace se corta en rojo: eso pasa de verdad, y explica casi todas las decisiones técnicas del proyecto.
Desliza el diagrama a los lados para verlo entero.
- vídeo
- control y telemetría
- datos en disco
-
1 · La cámara no habla solo un idioma
Las cámaras a bordo dan vídeo por RTSP, pero para capturas y eventos hace falta el SDK nativo del fabricante, que es una biblioteca en C. El agente la invoca desde Python con ctypes. ONVIF sirve para descubrirlas y configurarlas.
-
2 · El agente decide qué sale y cuándo
Un proceso en el PC industrial de la embarcación, escrito en Python y con una versión en Go. Guarda estado en SQLite local porque el barco pasa horas sin enlace: lo que no se pudo enviar espera ahí en vez de perderse.
-
3 · El problema real: el enlace se cae
Entre el barco y la costa hay satélite o 4G intermitente, con pérdida de paquetes y latencia alta. Ahí un protocolo sobre TCP se atasca. Por eso el vídeo sale con SRT, que va sobre UDP y recupera lo perdido sin bloquear el resto. El agente lo empuja con FFmpeg en modo emisor.
-
4 · En tierra, traducir para el navegador
El servidor SLATE escucha en modo receptor, recoge el flujo y lo transcodifica a HLS: segmentos y una lista de reproducción que cualquier navegador entiende sin complementos. Ahí también se guardan las capturas.
-
5 · El control viaja por otro camino
Órdenes y telemetría no van con el vídeo: usan MQTT sobre Mosquitto, con temas por dispositivo y cámara. Es ligero y sobrevive a las desconexiones. El núcleo es una API con arquitectura hexagonal, con el dominio sin una sola importación de infraestructura, y PostgreSQL para la flota.
-
6 · Y solo entonces, la pantalla
El operador abre el navegador y ve la cámara de un barco que está a cientos de kilómetros. Todo lo anterior existe para que ese último paso parezca trivial.
Las cuatro decisiones que lo sostienen
-
Transporte
SRT en vez de TCP
En un enlace con pérdida, un transporte que reintenta en orden se atasca y la imagen se congela. SRT va sobre UDP y recupera lo perdido sin bloquear lo que ya viene detrás: se degrada la calidad, no la sesión.
-
Sin cobertura
Una cola dentro del barco
El barco pasa horas sin enlace. Lo que no se pudo enviar espera en una base SQLite a bordo y sale cuando vuelve la señal, en vez de perderse o de bloquear al agente.
-
Dos caminos
El control no viaja con el vídeo
Las órdenes y la telemetría van por MQTT, con un tema por dispositivo y cámara. Si el vídeo cae, el barco sigue respondiendo; y una orden pesa unos bytes, no unos megas.
-
Núcleo
El dominio no sabe de cámaras
La API es hexagonal: el dominio no importa infraestructura. Cambiar de broker, de base o de fabricante de cámara toca los adaptadores, no las reglas del negocio.
Una flota entera no cabe en un servidor
El vídeo no se transcodifica solo: cada servidor en tierra aguanta un número acotado de grabaciones a la vez, y pasado ese número se queda sin máquina. Por eso el crecimiento no es comprar un servidor más grande, sino añadir un servidor esclavo por cada lote de grabaciones, cada uno con su grupo de embarcaciones asignado.
Esa es la vía por la que el sistema pasa de vigilar unos cuantos barcos a vigilar la flota completa: sumar barcos es sumar servidores, con el mismo núcleo, el mismo broker y la misma pantalla para el operador. Todo lo demás del recorrido —el agente a bordo, SRT, la cola local, MQTT— ya está pensado para eso: cada barco habla con su servidor y no con todos.
De dónde sale cada pieza del diagrama
El recorrido no es una idealización: cada elemento del dibujo está sacado del código del sistema, no de cómo debería ser.
| RTSP y ONVIF hacia las cámaras | direcciones y cliente del agente de dispositivo |
|---|---|
SDK nativo por ctypes | las cabeceras en C de la biblioteca del fabricante |
| Cola local en SQLite | la capa de persistencia del agente |
| Salida por SRT con FFmpeg | srt://host:puerto?mode=caller en el agente |
| Escucha en tierra | srt://0.0.0.0:puerto?mode=listener en el servidor de vídeo |
| Transcodificación a HLS | parámetros hls_time, hls_list_size y hls_flags |
| Temas de MQTT | streaming/device/{id}/camera/{uuid}/… |
| API hexagonal | las carpetas domain, application e infrastructure |
¿Tienes un sistema que vive lejos del teclado?
Dispositivos en campo, enlaces que se caen, datos que no pueden perderse y alguien que necesita verlo desde una pantalla. Es el trabajo que más me gusta.
Hablemos →