Estrategia: Nube Táctica Resiliente (NTR)
Informe divulgativo para el equipo técnico. De las 33 propuestas del pipeline a una única línea de negocio. Explicado con vocabulario de arquitectura de software.
Puntuación 4,75 / 5 · segundo clasificado 3,45 / 5 · consolida 7 de las 33 propuestas · 4 módulos software
Importante: esto es un marco estratégico de negocio, no un proyecto en desarrollo. No hay tareas, sprints ni trabajo asignado. Es contexto para entender la jerga y las decisiones.
1. ¿De qué va esto y por qué lo analizamos?
La casa lleva años haciendo, en proyectos como HIGEAI, FEDER-RAD y APEX, algo que en el sector de defensa y seguridad se paga bien: llevar el procesamiento y los datos al extremo de la red (edge) y que todo siga funcionando cuando la conectividad se cae. Se hizo para incendios forestales, para incidentes radiológicos y para monitorización de infraestructuras. Resulta que ese mismo problema es hoy la obsesión del sector defensa. De ahí este estudio de mercado automatizado, que produjo 33 propuestas de producto.
El problema informático de fondo es uno solo, y os va a resultar familiar: casi todos los sistemas del sector están construidos con mentalidad cloud-first. Backend centralizado, base de datos única, cliente que consulta por HTTP asumiendo que hay red. Eso funciona en una oficina con fibra. En un vehículo, un dron o un destacamento aislado la red es intermitente, con latencias de segundos, pérdida alta de paquetes y cortes de horas o días. Y ahí el patrón cloud-first no se degrada: se cae en seco. Hay sistemas de gestión logística que al perder red dejan de funcionar por completo — el equivalente a que tu ERP muestre una pantalla en blanco porque no alcanza al servidor.
Lo que el mercado busca es el giro a local-first / offline-first: el nodo local es la fuente de verdad mientras está aislado, funciona al 100 % de su función local, y cuando la red vuelve reconverge solo, sin que nadie resuelva conflictos a mano. Es el mismo problema que resuelven Git, CouchDB, Automerge o una app móvil bien hecha. Cambia el contexto y el nivel de exigencia, no la naturaleza técnica.
| Situación | Sistema cloud-first (hoy) | Sistema local-first (lo que se busca) |
|---|---|---|
| Red disponible | Funciona correctamente | Funciona correctamente y sincroniza |
| Red degradada (poco ancho de banda, latencia alta) | Timeouts, la interfaz se queda colgada | Prioriza lo crítico y sincroniza solo los cambios (deltas) |
| Sin red durante horas o días | Deja de funcionar por completo | Sigue operando al 100 % en local; encola los cambios |
| Vuelve la red | Sobrescritura silenciosa o conflictos que alguien debe resolver a mano | Convergencia automática garantizada, sin intervención humana |
| Actualizar el software del nodo | Hay que ir físicamente y conectar un cable | Despliegue declarativo por deltas firmados, sin internet |
2. Diccionario de jerga
Para que no os pille en una reunión: la columna de la derecha es lo que realmente significa.
| Lo que oiréis | Lo que significa en informático |
|---|---|
| DDIL | Denied, Disrupted, Intermittent, Limited. Conectividad intermitente o inexistente: cortes, latencia extrema, ancho de banda mínimo. Es decir: offline-first obligatorio. |
| Edge / borde / nodo táctico | Procesamiento local en el dispositivo o en un servidor pequeño in situ, en lugar del datacenter. |
| C2 (Mando y Control) / BMS / puesto de mando | Un dashboard de gestión y monitorización. Una app web que muestra estado y alertas y permite operar. |
| COP (Common Operational Picture) | Vista compartida y sincronizada del estado entre varios usuarios u organizaciones. Un dashboard multi-tenant consistente. |
| SWaP (Size, Weight and Power) | Restricciones de recursos: poca CPU, poca RAM, presupuesto térmico y eléctrico limitado. Pensad en una Raspberry Pi o un SoC ARM industrial. |
| COTS (Commercial Off-The-Shelf) | Hardware comercial estándar, no diseñado a medida. |
| Vetrónica | La electrónica embebida de un vehículo. Buses tipo CAN o MIL-STD-1553: el equivalente militar del CAN bus de tu coche. |
| Reach-back | Llamar al backend remoto. Cuando «falla el reach-back», te has quedado sin API. |
| ISR | Captura y análisis de datos de sensores: vídeo, cámaras térmicas, radar, LiDAR. Ingesta de streams + visión por computador. |
| Sostenimiento / PHM / CBM / RUL | Mantenimiento predictivo: telemetría IoT + modelos que estiman la vida útil restante de una pieza. |
| Tractora / Prime | El gran integrador multinacional que gana el contrato principal (Airbus, Indra, Thales, Amper…). Nosotros aspiramos a ser su subcontratista especializado. |
| TRL 4 / TRL 6 | Nivel de madurez. TRL 4 ≈ prototipo funcionando en laboratorio. TRL 6 ≈ piloto validado en entorno real. Es el «de PoC a producción» del sector. |
| Uso dual | Que la misma tecnología sirve para defensa y para el mercado civil (emergencias, protección civil, infraestructura crítica). |
3. Los 7 clústeres
Las 33 propuestas eran, en buena medida, el mismo problema descrito siete veces con distinta envoltura. Agrupadas por patrón arquitectónico salen 7 clústeres (más 1 propuesta que el propio pipeline descartó por falta de evidencia).
Un detalle que dice mucho: el pipeline clasificó 32 de 33 como «avanzar con condiciones» y alineación «Alta». Cuando todo puntúa igual de bien, la métrica no discrimina. La priorización se rehizo a mano penalizando lo que el pipeline ignora: ¿necesitamos hardware que no tenemos?, ¿datos o especificaciones que nadie nos va a dar?, ¿una especialidad de ingeniería que no está en la casa?
C1 · Nube Táctica Resiliente y sincronización offline
- Qué es en informático
- Un stack para que aplicaciones distribuidas funcionen offline-first sobre nodos de pocos recursos: base de datos replicada que converge sin conflictos, despliegue de microservicios sin acceso a internet y reparto de carga de cómputo entre nodos vecinos. Es plataforma e infraestructura, no aplicación final.
- Stack / tecnologías
- Kubernetes ligero (K3s), contenedores OCI, GitOps, CRDTs (Automerge, Yjs), relojes vectoriales, NoSQL con replicación multi-maestro (CouchDB, MongoDB), transporte tolerante a cortes (MQTT, Zenoh, store-and-forward, sincronización por deltas), firma criptográfica de artefactos.
- Veredicto de negocio
- Se elige, y no por poco. Es software puro: no hace falta fabricar hardware, ni certificar aviónica, ni que un fabricante nos abra sus especificaciones propietarias — las tres cosas que hunden a casi todos los demás clústeres. Además ya lo hemos hecho (HIGEAI, FEDER-RAD), validado en emergencias reales y no en simulación. Es el suelo sobre el que se apoyan C3 y C4, tiene time-to-market corto con stack abierto, y es dual sin esfuerzo extra.
- Framework de sincronización distribuida de configuraciones y modelos de IANTR-Orch + NTR-Trustcross_platform_edge_model_updates · P-01
Repartir nuevas versiones de software y de modelos de IA a nodos desplegados que no tienen conexión con el centro. Envía solo los cambios (deltas) para no agotar el enlace, y un registro compartido e inmutable dice qué versión debe estar corriendo en cada sitio. Sin esto, un dispositivo desplegado ejecuta el modelo con el que salió de fábrica.
- Plataforma de Orquestación de Capacidades Digitales (DCOP)NTR-Orchcross_platform_edge_model_updates · P-02
El hardware de una plataforma dura décadas y el software cambia cada mes: hoy un programa de adquisición tarda de media 12 años en entregar. La idea es desacoplar el software de la plataforma con contenedores, estándares abiertos y DevSecOps, para poder actualizar sin rediseñar el vehículo entero.
- D-Orch — orquestación distribuida en entornos desconectadosNTR-Orchcross_platform_edge_model_updates · P-03
Hoy, para actualizar el software de un dron desplegado, hay que recuperarlo físicamente y conectarle un cable. La propuesta es un agente K3s con un repositorio GitOps local que despliega, reconcilia y auto-recupera servicios sin acceso a internet ni a ningún registry público.
- Sincronización resiliente de datos de mantenimiento en DDILNTR-Synccross_platform_edge_model_updates · P-04
Dos copias del registro de mantenimiento se editan por separado mientras no hay red; al reconectar, una sobrescribe a la otra y el histórico queda corrupto. Con CRDTs y relojes vectoriales las réplicas convergen solas y nadie tiene que resolver conflictos a mano. Es el caso de uso que mejor demuestra el diferenciador.
- Arquitectura de inferencia distribuida en el borde (vehículos)NTR-Fabricterrestrial_onboard_inference_ddil · P-01
El vehículo depende del datacenter remoto para ejecutar sus modelos de IA, así que cuando cae el enlace se queda ciego. Se convierte en nodo autónomo con modelos cuantizados y podados, y puede delegar cómputo a los vehículos vecinos por red mesh cuando no le da la CPU.
El giro explícito de cloud-first a local-first: la lógica de negocio y el almacenamiento bajan de la nube central a un servidor local, con NoSQL de replicación nativa, caché predictivo y sincronización oportunista cuando aparece enlace.
- Nodo táctico edge para resiliencia logísticaNTR-Sync + NTR-Orchterrestrial_maintenance_logistics_actionability · P-03
El caso más ilustrativo del problema: el sistema de gestión logística del cliente deja de funcionar por completo al perder red. Un nodo local espejado mantiene operativos el inventario y las órdenes de trabajo, y sincroniza por deltas cuando la conectividad vuelve.
Fijaos en el patrón: las siete describen el mismo problema —el sistema asume conexión y no la tiene— aplicado a contextos distintos. De ahí que se traten como una única plataforma de cuatro módulos y no como siete productos.
C2 · Interoperabilidad, middleware y arquitectura abierta
- Qué es en informático
- Un traductor universal de formatos: cada fabricante emite sus datos con su esquema propietario y su reloj, y nadie se entiende. Un middleware normaliza todo a un modelo de datos común y sincroniza relojes. Problema clásico de ESB / capa de integración / anti-corruption layer.
- Stack / tecnologías
- DDS (bus pub/sub de tiempo real), PTP (sincronización de relojes a nivel de microsegundos), Protocol Buffers / FlatBuffers, estándares del sector (GVA/STANAG 4754, STANAG 4609 para vídeo), ontologías y diccionarios de datos.
- Veredicto de negocio
- Posicionamiento comercial excelente («somos el traductor neutral, no competimos con nadie»), pero para escribir el adaptador de un formato propietario necesitas la especificación del fabricante, y el fabricante vive de que no la tengas. Además nos falta experiencia real en DDS y buses embebidos, y los ciclos de estandarización son de años. Es nuestro plan B si el demostrador de C1 falla.
C3 · Inteligencia sobre sensores en el borde (Edge-ISR)
- Qué es en informático
- Un dispositivo con cámaras y sensores genera gigabytes de vídeo, pero el enlace de subida da para kilobytes. La idea: no subir los píxeles, subir el resultado. Correr visión por computador en el propio dispositivo y transmitir solo metadatos, alertas o el recorte relevante de la imagen. Pasar de streamear 4K a enviar un JSON con «objeto detectado aquí» más un recorte de 40 KB.
- Stack / tecnologías
- Modelos cuantizados y podados (INT8/FP16, pruning, distillation), TinyML, aceleradores embebidos (NPU, Jetson, FPGA con Vitis AI), WebAssembly y contenedores mínimos, detección de cambios y segmentación semántica, QoS dinámico, Delay Tolerant Networking.
- Veredicto de negocio
- Es el que suena mejor y el que más propuestas duplicadas generó — seis variantes del mismo concepto, que ya es señal de idea obvia. Y las ideas obvias tienen mucha competencia: el sector está saturado de «Edge-ISR». Además no controlamos la entrada (necesitamos flujos brutos de sensores reales que no tenemos) e invade el territorio del gran integrador, que vive de los sensores: nos convierte en competidor en vez de socio. Parte de las propuestas pedían firmware de FPGA y optimización a nivel de silicio; eso no es esta casa.
C4 · Mantenimiento predictivo y orquestación logística
- Qué es en informático
- El clúster más poblado. Es IoT + series temporales + reglas de negocio: recoges telemetría de vehículos o drones (leer el CAN bus, básicamente), estimas cuánto le queda a cada componente, y —la parte que nadie ha resuelto— conviertes esa alerta en una acción: una orden de trabajo, un pedido de repuesto. El problema documentado no es detectar el fallo; es que la alerta muere en un dashboard que nadie acciona.
- Stack / tecnologías
- Ingesta de telemetría, bases de datos de series temporales, regresión y detección de anomalías, cálculo de vida útil remanente (RUL), motores de reglas (BRMS) y automatización de flujos, integración con ERP, observabilidad y BI causal, gemelos digitales.
- Veredicto de negocio
- Tiene el ROI más fácil de explicar (menos vehículos parados = dinero) y es donde los integradores tienen más apetito. Pero exige modelos de degradación física de materiales (ingeniería mecánica, no software) y integrarse con el ERP logístico del cliente, sin cuyas APIs y años de histórico no hay modelo que entrenar. Lo interesante: casi todas estas propuestas asumen o piden sincronización offline, o sea que necesitan C1 para existir. Primero el suelo, después el vertical.
C7 · Factor humano y carga cognitiva
- Qué es en informático
- El usuario recibe más información de la que puede procesar y empieza a cometer errores. La solución es una UI adaptativa: un filtro entre la fuente de datos y la pantalla que prioriza por contexto y muestra solo lo relevante. Es diseño de UX y arquitectura de front-end orientada a la atención.
- Stack / tecnologías
- Motor de priorización contextual, interfaces adaptativas y —la parte complicada— monitorización biométrica o conductual del usuario para alimentar el bucle de realimentación.
- Veredicto de negocio
- Problema real y bien planteado, pero la interfaz final suele ser territorio del integrador principal, y la parte de biometría y factores humanos es una especialidad que no tenemos. No hay palanca de entrada.
C6 · Confianza digital e identidad distribuida
- Qué es en informático
- Autenticación mutua entre nodos de organizaciones distintas sin un servidor central de identidad, porque ese servidor no es alcanzable. En lugar de un OAuth contra un IdP, cada nodo lleva credenciales verificables criptográficamente y valida a sus pares en local. Traducido: zero-trust que funciona sin conexión al proveedor de identidad.
- Stack / tecnologías
- SSI (Self-Sovereign Identity) y DIDs (estándar W3C), credenciales verificables, DLT/blockchain ligera, enclaves seguros (Intel SGX, ARM TrustZone), control de acceso por atributos (ABAC).
- Veredicto de negocio
- La barrera aquí no es técnica, es política y regulatoria: que varios países acepten credenciales comunes exige consenso institucional, y desplegar cualquier cosa exige acreditación de seguridad nacional o de la Alianza. Ese muro es infranqueable para una pyme que lo aborde como negocio autónomo. La parte aprovechable —firma y trazabilidad de artefactos— se integra como el módulo NTR-Trust del clúster ganador.
C5 · Gestión de recursos SWaP, térmica y energética
- Qué es en informático
- Un planificador que reparte carga según el presupuesto térmico y energético disponible para evitar el thermal throttling. Cuando el chip se acerca al límite, en vez de que el hardware baje la frecuencia de golpe y meta latencias impredecibles, el software apaga ordenadamente los servicios no críticos: graceful degradation a nivel de planificador. Caso típico: un chasis sellado sin ventilación con un SoC dentro y un modelo de IA pidiendo el 100 % de CPU.
- Stack / tecnologías
- RTOS (sistemas operativos de tiempo real), hipervisores de tiempo real, DVFS (control dinámico de voltaje y frecuencia), telemetría térmica a nivel de hardware, planificadores por prioridad y criticidad, WebAssembly.
- Veredicto de negocio
- Descartado con claridad — 2,0 sobre 5. El problema es real e interesante, pero es programación de sistemas a muy bajo nivel: RTOS, hipervisores, control de silicio. No está en la casa ni en su trayectoria. Requiere telemetría térmica que solo tiene quien fabrica el hardware — y precisamente por eso lo va a hacer el fabricante de la electrónica, no un proveedor de software. No hay hueco para nosotros.
La investigación incorporada después de la línea base identifica una oportunidad concreta sobre vehículos blindados y UAV tácticos: integrar cámaras diurnas y térmicas, visión 360°, telemetría y datos parciales entre plataformas para reducir fragmentación visual y carga cognitiva.
Estratégicamente, el caso se sitúa sobre tres capacidades del NTR: NTR-Fabric para procesar datos en el borde, NTR-Sync para intercambiar información parcial en DDIL y C2/middleware para normalizar fuentes heterogéneas. La aportación de SIXTEMA sería software de fusión, priorización de eventos operacionales y visor; quedan fuera el sensor físico, la plataforma y cualquier función de selección de blancos o empleo de armamento.
Ver P-01 — Sistema de Fusión de Sensores · La evidencia y la decisión requieren validación humana.
4. Matriz de evaluación
Escala 1–5. Ponderación: encaje técnico 35 %, factibilidad para una pyme 25 %, atractivo para grandes integradores 25 %, time-to-market 15 %.
| # | Clúster | Props. | Encaje técnico (35 %) | Factibilidad pyme (25 %) | Atractivo integradores (25 %) | Time-to-market (15 %) | Total |
|---|---|---|---|---|---|---|---|
| 1 | C1 · Nube Táctica Resiliente | 7 | 5 | 5 | 4 | 5 | 4,75 |
| 2 | C2 · Interoperabilidad / middleware | 3 | 4 | 3 | 4 | 2 | 3,45 |
| 3 | C3 · Edge-ISR (sensores) | 6 | 4 | 3 | 3 | 3 | 3,35 |
| 4 | C4 · Mantenimiento predictivo | 11 | 3 | 3 | 4 | 3 | 3,25 |
| 5 | C7 · Factor humano | 1 | 3 | 3 | 3 | 3 | 3,00 |
| 6 | C6 · Confianza digital | 1 | 3 | 2 | 3 | 2 | 2,60 |
| 7 | C5 · SWaP / térmica | 3 | 2 | 2 | 2 | 2 | 2,00 |
Falta 1 propuesta para las 33: fue descartada por el propio pipeline por evidencia insuficiente.
El patrón que explica el ranking, en una frase: ganan las líneas que son software puro sobre hardware ajeno y estándar, y pierden las que exigen hardware propio, especificaciones que nadie nos dará, o especialidades de ingeniería que no están en la casa.
5. Los 4 módulos del NTR
NTR es una plataforma modular de software que se despliega sobre hardware comercial de pocos recursos y convierte cualquier nodo aislado en algo que funciona desconectado por diseño. Cuatro módulos, y los cuatro tienen equivalente directo en herramientas que ya conocéis.
NTR-Sync — «Google Docs para datos operativos»
- El problema
- Dos nodos se quedan sin red y ambos siguen escribiendo en su copia local. Cuando la red vuelve, ¿qué versión gana? El patrón habitual es last-write-wins (pierdes datos en silencio) o una cola de conflictos que alguien debe resolver a mano — y nadie lo hace, así que el dato deja de ser fiable.
- La solución
- CRDTs (Conflict-free Replicated Data Types): estructuras de datos con la propiedad matemática de que, sin importar el orden en que lleguen las modificaciones, todas las réplicas convergen al mismo estado final sin intervención humana. Es la tecnología detrás de la edición colaborativa de Google Docs o Figma: dos personas escriben a la vez en el mismo párrafo y no hay pantalla de «resuelve el conflicto». Se añaden relojes vectoriales para preservar la causalidad sin reloj global fiable, y sincronización por deltas, porque el ancho de banda es un lujo.
- La analogía
- Un
git pullque hace merge automático y nunca te deja un conflicto encima de la mesa. - Por qué importa
- Es el diferenciador: la alternativa real en el mercado es una hoja de Excel y una llamada por radio.
NTR-Orch — «GitOps sin internet»
- El problema
- Tienes un servicio corriendo en un dispositivo desplegado y quieres actualizarlo. Hoy, en muchos casos, hay que ir físicamente hasta el dispositivo y conectar un cable. Como eso es caro y lento, el dispositivo acaba ejecutando código de hace dos años.
- La solución
- K3s (Kubernetes ligero, capaz de correr en un SoC con poca RAM) más GitOps: un repositorio local es la fuente de verdad del estado deseado, un agente reconcilia continuamente y el nodo se auto-recupera. Las actualizaciones viajan como deltas binarios comprimidos y firmados, porque no hay ancho de banda para bajar una imagen de 800 MB. Y todo debe funcionar air-gapped: sin Docker Hub, sin registry público, sin
apt update. - La analogía
- ArgoCD o Flux, pero con el registry espejado en local y una tubería de datos de 9600 baudios.
NTR-Fabric — «un cluster de cómputo con los nodos que tengas cerca»
- El problema
- Un nodo se ahoga ejecutando un modelo mientras otro, a 200 metros, está al 5 % de CPU. Cada dispositivo es un silo de cómputo.
- La solución
- Una red mesh donde cada nodo es a la vez enlace y unidad de proceso, con un orquestador federado que delega trabajos a los vecinos según capacidad disponible y estado de la red. Efectivamente: montar un cluster efímero con lo que haya al alcance, sin coordinador central — porque el coordinador central es justo el punto único de fallo que queremos eliminar.
- La analogía
- Un scheduler distribuido peer-to-peer sobre una topología de red que cambia sola, sin nodo maestro.
NTR-Trust — «firma de artefactos y log inmutable»
- El problema
- Si acepto una actualización de software o un registro de datos que llega por una malla sin autoridad central, ¿cómo sé que nadie lo ha manipulado? Y a posteriori, ¿cómo audito qué versión corría dónde y quién cambió qué?
- La solución
- Firma criptográfica y atestación de todo artefacto que se despliega, más un registro distribuido ligero e inmutable para la trazabilidad de versiones y cambios de estado. En la casa ya hay experiencia en trazabilidad con blockchain y validación de señal con Galileo OSNMA, procedente de APEX y FEDER-RAD.
- La analogía
- Sigstore / cosign para firmar imágenes, más un append-only log para auditoría — todo verificable en local, sin llamar a ninguna CA remota.
El principio que une los cuatro: local-first con degradación elegante
Es la filosofía de una app móvil bien construida, llevada a un entorno donde el «modo avión» dura tres días y donde perder un dato tiene consecuencias serias.
Una advertencia honesta
El stack base —K3s, CRDTs, GitOps, Zenoh, cosign— es todo open source y está al alcance de cualquiera. Nadie va a comprar «una integración de componentes open source»; eso se convierte en commodity en dos años. Lo que se vende es la experiencia de haberlo hecho funcionar en denegación real, el conocimiento del dominio, la acreditación de seguridad y la relación de confianza en consorcio. El valor está en el conocimiento acumulado y en la posición, no en las librerías. Conviene tenerlo claro desde el principio.
6. Qué significa para el equipo
Esto es, por ahora, un marco estratégico de negocio, no un proyecto. Nada de lo descrito está en desarrollo y no hay trabajo asignado.
Su función es posicionarnos: cuando un gran integrador prepare una oferta para un programa europeo o nacional y necesite la pieza de «datos que sobreviven a la pérdida de red», queremos ser el nombre que le venga a la cabeza. Nuestra baza no es tamaño ni catálogo — es ser la pyme especializada, ágil y de bajo riesgo que ya ha hecho exactamente eso en incendios forestales y en emergencias radiológicas, con financiación pública y resultados verificables. Un integrador no subcontrata una promesa: subcontrata un antecedente.
Lo que sí conviene que quede de esta lectura:
- Nada de esto es tecnología exótica. Es arquitectura distribuida, consistencia eventual, orquestación de contenedores y firma de artefactos. Los problemas duros son los de siempre: consistencia, particiones de red y recursos escasos.
- Lo que en HIGEAI, FEDER-RAD y APEX se resolvió por necesidad técnica es hoy un activo comercial. El trabajo ya hecho es la credencial.
- La decisión de negocio fue, sobre todo, un ejercicio de honestidad. Se descartaron las líneas que exigían hardware a medida, certificación aeronáutica, física de materiales o programación de silicio — no porque no sean interesantes, sino porque no somos esa empresa. Y se eligió aquello en lo que ya somos buenos.
Si en algún momento esto se activa, llegará con especificación y planificación propias. Hasta entonces, esto es solo el mapa del terreno. Documentos de origen: docs/informe_divulgativo_ntr_equipo.md y docs/propuesta_comite_defensa.md.