T13-F01 · Sistema de Orquestación Logística en el Borde (Edge Logistics Orchestrator - ELO)
Código original: P-01
Condiciones: Validación obligatoria de la fidelidad de los datos de telemetría para modelos predictivos y confirmación de compatibilidad SWaP en hardware objetivo.
1. Identificación de la propuesta
- Código
P-01
- Nombre de la propuesta
Sistema de Orquestación Logística en el Borde (Edge Logistics Orchestrator - ELO)
- Origen
Otro origen
- Línea estratégica
Arquitecturas Edge-to-Cloud y procesamiento distribuido
- Dominio
Terrestre
- Tipo de uso
Defensa
- Fecha de análisis
22/05/2024
- Responsable de la ficha
Pipeline automático - pendiente de asignación
- Estado
En análisis
2. Problema concreto
- Descripción
Existe una incapacidad técnica para transformar alertas de diagnóstico y prognóstico (predicción de fallos) en acciones logísticas concretas cuando las fuerzas terrestres operan en entornos con conectividad degradada. La dependencia actual de sistemas centrales impide que los datos de sensores de vehículos blindados se conviertan localmente en órdenes de trabajo o gestión de repuestos [ev_0004, ev_0006].
- Consecuencia principal
Inmovilización imprevista de vehículos y degradación de la prontitud operativa de la flota debido a que el ciclo de mantenimiento se rompe en entornos DDIL (comunicaciones denegadas, degradadas, intermitentes o limitadas) [ev_0004, ev_0007].
- Usuario afectado
Operador
- Criticidad
Alta
- Frecuencia estimada
Continua
- Entorno de aparición
Degradado
3. Ejemplo operativo y evidencia
- Escenario
En el marco de una misión en OIB (operaciones operativamente independientes, donde las unidades actúan con autonomía prolongada por aislamiento), una unidad de vehículos blindados se despliega en un terreno con alta interferencia enemiga o jamming (interferencia intencionada para bloquear comunicaciones) [ev_0004, ev_0006]. Durante el avance, los sensores embebidos de un vehículo detectan una anomalía técnica que indica una degradación acelerada de un componente crítico. En la arquitectura actual, este dato debe viajar hasta un centro de procesamiento remoto para ser traducido en una necesidad logística; sin embargo, debido al entorno DDIL (comunicaciones denegadas, degradadas, intermitentes o limitadas), el enlace falla [ev_0004, ev_0024]. Como resultado, el mecánico táctico no recibe una recomendación accionable y el comandante pierde la visibilidad sobre la salud del activo. El vehículo termina sufriendo una avería crítica que lo deja inmovilizado en zona de peligro, ya que no se pudo generar una pre-orden de trabajo ni solicitar repuestos Class IX (piezas de recambio) de forma autónoma antes del fallo [ev_0007].
- Activos implicados
Vehículos blindados, sensores embebidos, sistemas de comunicaciones tácticas
- Información disponible
Telemetría de sensores (CAN bus), manuales técnicos digitales y catálogos de piezas Class IX
- Limitación actual
Ausencia de capacidad de edge computing (procesamiento de datos cerca de donde se generan) para traducir alertas técnicas en órdenes logísticas sin depender de la nube o servidores centrales [ev_0004, ev_0024].
- Consecuencia operacional
Aumento de la inmovilización imprevista y cuellos de botella en el suministro de repuestos por dependencia de redes intermitentes [ev_0006, ev_0007].
- Fuente de evidencia
ev_0004, ev_0006, ev_0007
- Tipo caso
Necesidad comunicada
4. Solución propuesta
- Descripción de la solución
Implementar un Sistema de Orquestación Logística en el Borde (ELO) que desplace la lógica de decisión al vehículo. El sistema consumirá datos de sensores y, mediante modelos predictivos locales, generará recomendaciones de mantenimiento y solicitudes de repuestos sin requerir conexión externa.
- Datos de entrada
Telemetría del vehículo vía CAN bus, catálogos de piezas Class IX y manuales técnicos digitales.
- Procesamiento principal
Detección de anomalías y cálculo de RUL (Remaining Useful Life o vida útil remanente) mediante un motor de inferencia ligero; traducción de la alerta técnica a tarea de mantenimiento consultando bases de datos locales NoSQL.
- Resultado / salida
Alerta al operador, generación de pre-orden de trabajo priorizada y sincronización asíncrona con la FSC (Forward Support Company o compañía de apoyo avanzado) mediante store-and-forward.
- Sistema, arquitectura e integración
Capa de software embebida en el vehículo, integrada con el BMS (sistema de mando y control de combate) y sistemas logísticos centrales.
- Funcionamiento resumido
1. Ingesta local de telemetría -> 2. Análisis de salud y cálculo de RUL -> 3. Traducción a requerimiento logístico Class IX -> 4. Notificación al BMS y sincronización diferida con la FSC.
- Componentes funcionales
- Motor de inferencia ligero (TinyML)
- Base de datos NoSQL embebida
- Módulo de sincronización asíncrona store-and-forward
5. Aportaciones concretas de SIXTEMA
- Qué asumiría SIXTEMA
Desarrollo de la capa de inteligencia y orquestación en el borde, incluyendo el motor de inferencia para detección de anomalías y la arquitectura de resiliencia de datos.
- Qué entregaría
Componente software
- Tipo de entregable
Componente software
- Qué queda fuera de alcance
Hardware físico del vehículo, sensores embebidos y gestión física de los repuestos Class IX.
- Qué aportarían los socios
Integración en la plataforma física del vehículo y provisión de los catálogos técnicos/logísticos oficiales.
- Modalidad de ejecución
Consorcio
- Socios necesarios
Grandes integradores de plataformas terrestres (Ej. Airbus, Indra)
6. Capacidades reales que respaldan la propuesta
- Capacidad real
IA y Soporte a la Decisión
- Proyecto / experiencia
Capacidades actuales de IA
- Qué demuestra
Experiencia en detección de anomalías, identificación de patrones y generación de alertas automatizadas, base necesaria para el motor de inferencia del ELO
- Nivel evidencia
Alta
- Capacidad real
Arquitecturas Escalables Cloud-Native
- Proyecto / experiencia
Habilitadores de Nube Táctica
- Qué demuestra
Capacidad para desplegar servicios operativos en entornos distribuidos e intercambio seguro de datos
- Nivel evidencia
Alta
7. Capacidades futuras o en evolución
- Capacidad futura
Arquitecturas Edge-Cloud Federadas en entornos denegados
- Proyecto / iniciativa
Desarrollo de Nube Táctica
- Estado
En curso
- Resultado esperado
Procesamiento en el extremo de la red (Edge) con resiliencia ante comunicaciones degradadas o jamming, eliminando la dependencia del núcleo central para la inteligencia logística
- Capacidad futura
Fusión Avanzada de Datos Multifuente
- Proyecto / iniciativa
Extensión estratégica de fusión de datos
- Estado
En curso
- Resultado esperado
Integración de telemetría y sensores avanzados desde vehículos terrestres para alimentar los modelos predictivos de salud del activo
8. Tecnología involucrada
- Capa / función
Procesamiento en el Borde
- Tecnología / patrón
Edge Computing optimizado para SWaP (limitaciones de tamaño, peso y consumo eléctrico)
- Situación en SIXTEMA
Disponible parcialmente
- Responsable / socio
Equipo interno
- Capa / función
Almacenamiento Local
- Tecnología / patrón
Bases de datos NoSQL embebidas
- Situación en SIXTEMA
Por incorporar
- Responsable / socio
Equipo interno / Socio
- Capa / función
Análisis Predictivo Ligero
- Tecnología / patrón
TinyML (Machine Learning optimizado para microcontroladores)
- Situación en SIXTEMA
Pendiente de validar
- Responsable / socio
Equipo interno
- Capa / función
Resiliencia de Comunicaciones
- Tecnología / patrón
Protocolos Store-and-Forward (almacenamiento y reenvío)
- Situación en SIXTEMA
Dominada
- Responsable / socio
Equipo interno
9. Encaje con programas y marcos europeos
- Programa europeo
EDF
- Convocatoria / topic
Pendiente de búsqueda
- Marco / estándar prioritario
Nube Táctica, Inteligencia de Datos y Superioridad de la Información
- Valoración del encaje
Alto
- Justificación
El proyecto se alinea directamente con las prioridades del EDF en cuanto a nube táctica e inteligencia de datos aplicada a la autonomía operativa.
- Fuente de referencia
financiacion.md (Propuesta)
10. Diferenciación aportada
- Diferenciador
Combinación de IA predictiva con arquitecturas Edge-Cloud federadas
- Por qué es relevante
Permite que el vehículo sea autónomo en su diagnóstico sin depender de la nube, resolviendo el problema en entornos DDIL (comunicaciones denegadas, degradadas, intermitentes o limitadas)
- Evidencia
Capacidades actuales de IA + Desarrollo de arquitecturas Edge-Cloud federadas
- Diferenciador
Experiencia probada en consorcios con grandes integradores
- Por qué es relevante
Facilita la integración del software ELO en las plataformas físicas (blindados) gestionadas por primes
- Evidencia
Relaciones existentes con Airbus y Amper
11. Actores objetivo y vías de entrada
- Actor identificado
Airbus Defence and Space
- Necesidad / interés
Digitalización de sus plataformas terrestres y mejora del sostenimiento en el borde
- Vía de entrada
Consorcio
- Relación actual
Existente
- Actor identificado
Indra
- Necesidad / interés
Capacidades de inteligencia de datos y C2 para sus sistemas de mando terrestres
- Vía de entrada
Consorcio
- Relación actual
Incipiente
- Actor identificado
Ministerio de Defensa (DGAM)
- Necesidad / interés
Aumento de la prontitud operativa y reducción de inmovilizaciones imprevistas en flotas blindadas
- Vía de entrada
Convocatoria
- Relación actual
Sin relación
12. Brechas y dependencias
- Brecha / dependencia
Fidelidad y calidad de los datos de telemetría (CAN bus) actuales
- Impacto
Afecta la viabilidad de los modelos predictivos locales; datos insuficientes generarían una tasa inaceptable de falsos positivos.
- Cómo cubrirla
Acceso a datasets reales de sensores de vehículos blindados para validar la capacidad de predicción (RUL).
- Responsable potencial
Ministerio de Defensa (DGAM) o integrador de plataforma
- Brecha / dependencia
Compatibilidad con hardware legacy en plataformas blindadas
- Impacto
Restricciones de SWaP (tamaño, peso y consumo eléctrico) podrían impedir la ejecución del motor de inferencia local.
- Cómo cubrirla
Análisis técnico de las capacidades de cómputo embarcado actuales y optimización mediante TinyML.
- Responsable potencial
Equipo interno de arquitectura / Socio integrador (Airbus, Indra)
- Brecha / dependencia
Acceso a catálogos logísticos Class IX y manuales técnicos digitales
- Impacto
Sin estos datos, el sistema no puede traducir una alerta técnica en una pieza de recambio o tarea concreta.
- Cómo cubrirla
Acuerdos de transferencia de datos con el usuario institucional o el fabricante del vehículo.
- Responsable potencial
Socio integrador / Usuario final
13. Valoración final por criterios
| Criterio | Valoración | Justificación |
|---|---|---|
| Relevancia del problema | Alta | Crítico para la operatividad en entornos DDIL (comunicaciones denegadas, degradadas, intermitentes o limitadas). |
| Calidad de la evidencia | Media | Sólida en el problema operativo, pero carece de métricas cuantitativas y datos técnicos de sensores. |
| Encaje con SIXTEMA | Alta | Alineado con capacidades de IA, soporte a la decisión y arquitecturas Edge-Cloud federadas. |
| Capacidades reales disponibles | Alta | Posee frameworks de detección de anomalías y resiliencia ante jamming reutilizables. |
| Diferenciación | Media | El valor reside en la orquestación local autónoma frente a soluciones centralizadas tradicionales. |
| Encaje europeo | Alta | Alineado con prioridades de Nube Táctica e Inteligencia de Datos del EDF (European Defence Fund). |
| Actor o vía de entrada identificada | Media | Identificados integradores como Airbus/Indra, pero requiere validación de relación actual. |
| Potencial dual | Alta | Aplicable a cualquier flota de vehículos pesados en entornos remotos (minería, energía). |
| Madurez preliminar | Media | Nivel Prototype (TRL 4-5) estimado para la solución primaria. |
| Cobertura brecha tecnológica | Alta | Resuelve el cuello de botella entre detección técnica y ejecución logística en el borde. |
| Autonomía respecto a socios | Baja | Dependencia total de un integrador para el acceso al hardware del vehículo y datos CAN bus. |
| Viabilidad preliminar | Media | Técnicamente plausible, condicionada a la calidad de los datos y limitaciones de SWaP. |
14. Decisión y conclusión final
- Resultado
Avanzar con condiciones
- Condiciones para avanzar
Validación obligatoria de la fidelidad de los datos de telemetría para modelos predictivos y confirmación de compatibilidad SWaP en hardware objetivo.
- Validaciones pendientes
Contrastar tasa de falsos positivos aceptable para el operador y verificar disponibilidad de manuales técnicos digitales Class IX.
- Próximo hito
Búsqueda de datasets de telemetría reales o contacto con integrador para validación de hardware embarcado.
- Síntesis
Solución de alta relevancia que dota de autonomía logística a vehículos blindados en entornos DDIL mediante Edge Computing. Encaja perfectamente con la estrategia de IA y Nube Táctica de SIXTEMA. El diferenciador es el desplazamiento de la lógica CBM+ al borde, aunque depende críticamente de la calidad de los datos de sensores y del hardware legacy.
15. Fuentes y trazabilidad
Sin referencias registradas.Evidencias del clúster: ev_0004, ev_0006, ev_0007