Fichas de requisitos

DRN-01 — Definición de BOM

Estado: 🟡 borrador · Prioridad: critica · Tipo: hardware

Campo	Valor
Subsistema	scout
Version baseline	—
Origen	Cronograma HIVE2-RoadMap — D1 (Definición de BOM)
Depende de	—

Descripcion. Definir la lista de materiales (BOM) del Scout: componentes, cantidades y proveedores.

Objetivo. BOM del Scout definida y documentada.

Verificacion (inspeccion). Inspección: existe una BOM completa del Scout revisada.

DRN-02 — Compra del BOM

Estado: 🟡 borrador · Prioridad: alta · Tipo: hardware

Campo	Valor
Subsistema	scout
Version baseline	—
Origen	Cronograma HIVE2-RoadMap — D2 (Compra del BOM)
Depende de	`DRN-01`

Descripcion. Adquirir los componentes de la BOM del Scout.

Objetivo. Componentes de la BOM comprados y recibidos.

Verificacion (inspeccion). Inspección: los componentes de la BOM están adquiridos y disponibles.

DRN-03 — Diseño final del dron

Estado: 🟡 borrador · Prioridad: critica · Tipo: mixto

Campo	Valor
Subsistema	scout
Version baseline	—
Origen	Cronograma HIVE2-RoadMap — D3 (Diseño final de drone)
Depende de	`DRN-01`

Descripcion. Realizar el diseño final del Scout (estructura, integración de electrónica y aviónica, disposición de sensores).

Objetivo. Diseño final del Scout completado y validado para fabricación.

Verificacion (analisis). Análisis: el diseño final del dron está documentado y validado (estructural y de integración).

DRN-04 — Prueba de materiales

Estado: 🟡 borrador · Prioridad: media · Tipo: hardware

Campo	Valor
Subsistema	scout
Version baseline	—
Origen	Cronograma HIVE2-RoadMap — D4 (Prueba de materiales)
Depende de	`DRN-02`

Descripcion. Probar los materiales candidatos del Scout para validar su idoneidad (resistencia, peso, comportamiento).

Objetivo. Materiales del Scout validados mediante ensayo.

Verificacion (test). Prueba: los materiales seleccionados superan los ensayos de idoneidad.

DRN-05 — Construcción del dron sin RTK ni sistema de carga

Estado: 🟡 borrador · Prioridad: alta · Tipo: hardware

Campo	Valor
Subsistema	scout
Version baseline	—
Origen	Cronograma HIVE2-RoadMap — D5 (Construcción de drone sin RTK ni sistema de carga)
Depende de	`DRN-01`

Descripcion. Construir una primera versión del Scout sin RTK ni sistema de carga, para pruebas tempranas de vuelo.

Objetivo. Un Scout básico (sin RTK ni carga) construido y apto para volar en pruebas.

Verificacion (demostracion). Demostración: el dron básico se construye y realiza un vuelo de prueba.

DRN-06 — Construcción de one-off 1

Estado: 🟡 borrador · Prioridad: alta · Tipo: hardware

Campo	Valor
Subsistema	scout
Version baseline	—
Origen	Cronograma HIVE2-RoadMap — D6 (Construcción de one-off 1)
Depende de	`DRN-03`

Descripcion. Construir la primera unidad one-off del Scout con el diseño final.

Objetivo. Primera unidad one-off del Scout construida.

Verificacion (inspeccion). Inspección: la unidad one-off 1 está construida conforme al diseño final.

DRN-07 — Construcción de one-off 2

Estado: 🟡 borrador · Prioridad: alta · Tipo: hardware

Campo	Valor
Subsistema	scout
Version baseline	—
Origen	Cronograma HIVE2-RoadMap — D7 (Construcción de one-off 2)
Depende de	`DRN-03`

Descripcion. Construir la segunda unidad one-off del Scout con el diseño final.

Objetivo. Segunda unidad one-off del Scout construida.

Verificacion (inspeccion). Inspección: la unidad one-off 2 está construida conforme al diseño final.

INT-01 — Pruebas de vuelo con gamepad

Estado: 🟡 borrador · Prioridad: critica · Tipo: mixto

Campo	Valor
Subsistema	sistema
Version baseline	—
Origen	Cronograma HIVE2-RoadMap — I1 (Pruebas de vuelo con gamepad; dep. S6, D5)
Depende de	`SW-06`, `DRN-05`

Descripcion. Realizar pruebas de vuelo real del Scout pilotado con gamepad (integra el vuelo con gamepad en simulador y el dron básico construido).

Objetivo. Vuelo real del Scout pilotado con gamepad realizado con éxito.

Verificacion (demostracion). Demostración: el Scout vuela pilotado con gamepad en un ensayo real.

INT-02 — Pruebas de vuelo con dock

Estado: 🟡 borrador · Prioridad: critica · Tipo: mixto

Campo	Valor
Subsistema	sistema
Version baseline	—
Origen	Cronograma HIVE2-RoadMap — I2 (Pruebas de vuelo con dock; dep. S*, D8-9)
Depende de	`DRN-06`, `DRN-07`, `VTP-06`

Descripcion. Realizar pruebas de vuelo del Scout operando desde el dock/vertipuerto (despegue, misión y regreso al dock).

Objetivo. El Scout despega desde el dock, realiza misión y regresa al dock en pruebas.

Verificacion (demostracion). Demostración: ciclo completo dock→misión→dock ejecutado en pruebas.

INT-03 — Pruebas de vuelo con LORA

Estado: 🟡 borrador · Prioridad: critica · Tipo: mixto

Campo	Valor
Subsistema	sistema
Version baseline	—
Origen	Cronograma HIVE2-RoadMap — I3 (Pruebas de vuelo con LORA; dep. S, D)
Depende de	`SW-11`, `VTP-05`

Descripcion. Realizar pruebas de vuelo del Scout usando el enlace de control por LORA.

Objetivo. El Scout vuela controlado por enlace LORA en pruebas.

Verificacion (demostracion). Demostración: vuelo del Scout controlado por LORA en un ensayo real.

INT-04 — Pruebas finales de integración

Estado: 🟡 borrador · Prioridad: critica · Tipo: mixto

Campo	Valor
Subsistema	sistema
Version baseline	—
Origen	Cronograma HIVE2-RoadMap — I4 (Pruebas finales; dep. S, D, V*)
Depende de	`INT-01`, `INT-02`, `INT-03`

Descripcion. Realizar las pruebas finales de integración extremo a extremo del sistema GUARDIAN (Scout + vertipuerto + software).

Objetivo. Sistema GUARDIAN validado extremo a extremo en las pruebas finales.

Verificacion (demostracion). Demostración: prueba final end-to-end (misión completa con Scout, vertipuerto y GCS) superada.

INT-05 — Arquitectura de sistema: malla de nodos, telemetría y distribución de datos

Estado: 🟢 aprobado · Prioridad: critica · Tipo: software ⚑ IP-CORE

Campo	Valor
Subsistema	sistema
Version baseline	—
Origen	HIVE2 — docs/ARCHITECTURE.md, 15_data_sync_and_audit.md, services/hive-sync, hive-endpoint, hive-deploy/nodeRegistry
Depende de	—

Descripcion. GUARDIAN es un sistema C2 distribuido en una malla jerárquica de nodos (no una estación única), portando la arquitectura de HIVE2. Define: (1) la topología de nodos y sus roles (HQ de mando que agrega su subárbol, Edge de campo que es el único que conecta con los drones, Mirror hot-standby); (2) el bus MQTT del sistema con dos clases de mensaje: telemetría por dron (alta frecuencia, en tiempo real desde el Edge) y eventos de dominio (cambios de estado —nueva misión, plan de vuelo modificado, etc.— que se publican para que los clientes conectados se refresquen en vivo); (3) la sincronización de datos operacionales entre nodos (replicación upstream edge→HQ→raíz vía relay MQTT, con cola offline, resolución de conflictos por versión y persistencia diferenciada por rol), incluido el relay de la telemetría hacia el HQ para monitorizar la flota desde el mando; (4) el stack autocontenido de un nodo (MongoDB, MQTT/Mosquitto, Vault, API, frontend, sync) desplegable por Docker; y (5) el modelo de usuarios, roles y permisos (incluida la federación de identidad entre nodos). Es la base arquitectónica de la que dependen la consola de despliegue (SW-17) y el resto del software.

Objetivo. Está definida y documentada la arquitectura de nodos de GUARDIAN: roles y topología, el esquema de topics MQTT (telemetría y eventos de dominio), el relay de telemetría hacia el HQ, el mecanismo de sincronización entre nodos, la composición del stack de un nodo, y el modelo de usuarios/roles; de modo que un nodo Edge publica telemetría de un dron y esta se distribuye y muestra según el rol de cada nodo, y un cambio de dominio en un cliente refresca a los demás en vivo.

Verificacion (demostracion). Demostración de extremo a extremo: dos nodos (un Edge y un HQ) desplegados; un dron (o simulador) publica telemetría en el Edge, que se muestra en tiempo real y se relaya hasta el HQ; un cambio de dominio (p.ej. nueva misión) publicado como evento MQTT refresca a otro cliente conectado; y un cambio de datos operacionales en el Edge se replica al HQ (upstream). Roles y permisos de usuario aplicados.

Pendiente

TODO(historia telemetria): fijar el esquema exacto de topics. Direccion acordada: jerarquico con nodo
TODO(historia usuarios/roles): definir el modelo de roles de GUARDIAN. Punto de partida: los 4 de HIVE

INT-06 — Geofencing y contención del volumen de operación

Estado: 🟢 aprobado · Prioridad: critica · Tipo: software

Campo	Valor
Subsistema	sistema
Version baseline	—
Origen	Definición de misiones GUARDIAN — sesión 24-07-2026. Ampliado en la sesión 11-08-2026 con la capa de protección activa del pilotaje manual (margen predictivo por tiempo al impacto y limitación proporcional de la autoridad del mando). Rediseñado en la sesión 13-08-2026: asistencia opcional por niveles (0 instrumentos / 1 aviso reforzado / 2 muro con deslizamiento), máquina de estados recorte → toma de control por eje → devolución con histéresis en sustitución de la acción terminal configurable, RTL/Land relegados a la fence de a bordo (solo sin enlace C2), protocolo de actuación repartido entre modelo de dron / teatro / operador, y política de pérdida de GPS que conserva el mando del piloto.
Depende de	`SW-06`

Descripcion. Contención del dron en un volumen de operación 3D, en tres capas. La geofence rica se define y compila a nivel de teatro (SW-21): raster de altura permitida en cotas MSL —motor de consulta O(1) por celda para dentro/cerca-del-borde en planimetría y altimetría, con NoData = zona prohibida— derivado de un DEM más una envolvente global y reglas vectoriales (exclusiones y alturas locales). Capa principal — GUARDIAN: impone esa geofence desde la GCS con zona de aviso al aproximarse (margen predictivo, un anillo de celdas alrededor); ningún comando ni plan puede sacar al dron del volumen, y si el límite se alcanza pese a todo (deriva, viento, glitch), la respuesta es hold más retorno comandado al interior: el dron queda en hover dentro del volumen, avisando, y el operador decide. Nunca RTL ni aterrizaje desde esta capa: abortar el vuelo no es decisión de la geofence mientras el enlace C2 está vivo. Capa de protección activa del pilotaje manual: mientras el operador tiene el control con gamepad (SW-06) el límite no lo cruza un plan sino la mano del piloto. La asistencia es OPCIONAL Y POR NIVELES, seleccionable en vuelo: nivel 0 solo instrumentos (el radar SW-26 y sus alertas), nivel 1 aviso reforzado (añade háptica en el propio mando), nivel 2 muro con deslizamiento. En el nivel 2 el margen es PREDICTIVO POR TIEMPO AL IMPACTO —proyección del vector velocidad contra la geofence: un obstáculo a 100 m es inocuo a 2 m/s y crítico a 20 m/s— y la respuesta es una máquina de tres estados sin mezcla de autoridades: (1) RECORTE progresivo de la componente del mando que acerca al límite —la normal al muro se atenúa hasta anularse en el margen de seguridad, la tangencial se respeta íntegra (deslizamiento) y el mando hacia el interior del volumen nunca se recorta—; (2) si el margen se invade pese a todo (ladera que sube con throttle neutro, ráfaga, inercia), TOMA DE CONTROL del eje afectado: el sistema ignora el mando de ese eje e inyecta el suyo —throttle positivo huyendo del suelo, negativo huyendo del techo, retroceso en horizontal— mientras el operador conserva los demás ejes, con aviso sonoro, panel en rojo y registro; (3) recuperado el margen más una histéresis, DEVOLUCIÓN del mando, anunciada. La asistencia no cambia la ley de control activa: en asistido (LOITER) la garantía de contención es plena; en directo (ALT_HOLD) la protección vertical es equivalente y la horizontal degrada a inclinación contraria proporcional sin garantía de parada — el instrumental lo declara honestamente como protección degradada. La autoridad es del nodo edge (calcula márgenes y autoridad permitida) aplicada en el puente (actúa a la cadencia del repetidor RC); el navegador solo muestra. El nivel elegido y toda intervención quedan registrados como eventos de la ejecución. Protocolo de actuación — tres familias de parámetros con tres dueños: los umbrales por tiempo son LOS MISMOS del radar SW-26 (lo que el operador ve colorearse es exactamente lo que actúa); el margen de seguridad en metros (por eje: horizontal y vertical, este mayor por la peor precisión vertical de los sensores), la histéresis de devolución y la deceleración máxima de la ley de frenado viven en el MODELO DE DRON; el nivel de asistencia es preferencia del operador en vuelo. Capa de salvaguarda — autopiloto: se carga además una fence de contención simplificada (envolvente 2D + techo/suelo globales, límite de ArduPilot), derivada de los vectores originales del teatro, cuyo valor es contener al dron ante pérdida del enlace C2, cuando GUARDIAN no puede actuar. Solo esta capa puede abortar el vuelo: acción «RTL, y si no puede, Land», con la altura de retorno derivada del teatro (bajo el techo global) al cargar la fence, no una constante del dron. La pérdida de GPS con enlace C2 vivo NO aterriza el dron: el failsafe de navegación se configura (en el modelo de dron) para caer a la ley directo (ALT_HOLD), de modo que el operador conserva el mando y puede traerlo manualmente; sin GPS ninguna capa de geofence puede actuar y el instrumental lo declara. Redacción alineada con los requisitos de contención de las clases EASA C5/C6 (límites programables verificables en tiempo real).

Objetivo. El dron no puede salir del volumen de operación: GUARDIAN avisa, frena la mano del piloto con una asistencia opcional por niveles y, si el margen se invade, toma el control del eje afectado hasta recuperarlo y lo devuelve — nunca aborta el vuelo con el enlace vivo; la fence de a bordo lo contiene (RTL, y Land solo como último recurso) únicamente si se pierde el enlace C2.

Verificacion (test). Ensayo en simulador: al aproximarse al límite el sistema avisa; alcanzado el límite en vuelo automático, el dron queda en hold dentro del volumen tras el retorno comandado (nunca RTL ni Land). Pilotando en manual con nivel 2, contra una exclusión y contra el techo a dos velocidades distintas: el recorte empieza antes y es más fuerte a más velocidad, la componente tangencial se conserva (deslizamiento) y el dron no rebasa el margen con el stick a fondo; invadido el margen (ladera ascendente con throttle neutro), el sistema toma el control del eje vertical, recupera el margen y devuelve el mando con histéresis, sin oscilación; con nivel 0/1 la limitación no se aplica y el aviso persiste; en directo la protección vertical actúa y el panel declara la horizontal degradada; toda intervención queda registrada. Con el enlace C2 cortado, la fence del autopiloto contiene el dron y ejecuta RTL (Land solo sin posición). Con GPS perdido y C2 vivo, el dron cae a ALT_HOLD y el operador conserva el mando.

INT-07 — Fail-safes de energía y enlace (retorno por batería y pérdida de C2)

Estado: 🟢 aprobado · Prioridad: critica · Tipo: software

Campo	Valor
Subsistema	sistema
Version baseline	—
Origen	Definición de misiones GUARDIAN — sesión 24-07-2026
Depende de	—

Descripcion. Comportamientos de salvaguarda configurables por misión, no globales. Retorno por batería: al alcanzar el porcentaje configurado (o el umbral calculado dinámicamente según distancia al punto de retorno, el mayor de los dos) el dron inicia la vuelta con uno de dos perfiles: preset (ascender a la altura segura configurada y volver) o direct (volver a la altura actual); si la ruta de retorno sale del margen de seguridad, se calculan los waypoints necesarios para volver dentro de él. Pérdida de enlace C2: acción configurable — continuar misión (por defecto en misiones autónomas, la misión va a bordo) o RTH (por defecto en vuelo manual/gamepad). Todo disparo de un fail-safe queda registrado como evento de la ejecución.

Objetivo. Un dron con batería justa o sin enlace siempre acaba en un estado seguro y predecible, según la política configurada para esa misión.

Verificacion (test). Ensayo en simulador: al cruzar el umbral de batería el dron ejecuta el perfil de retorno configurado, recalculando waypoints si la vuelta sale del margen de seguridad; ante corte del enlace, la misión autónoma continúa y el vuelo manual hace RTH.

SW-01 — Definición de software y objetivos

Estado: 🟢 aprobado · Prioridad: critica · Tipo: software

Campo	Valor
Subsistema	sistema
Version baseline	—
Origen	Cronograma HIVE2-RoadMap — S1 (Definición de software y objetivos)
Depende de	—

Descripcion. Definir el alcance funcional del software de GUARDIAN y los objetivos que debe cumplir el frente software a lo largo del cronograma.

Objetivo. Documento de alcance y objetivos de software aprobado, que sirva de base para el resto de tareas SW.

Verificacion (inspeccion). Revisión documental: existe un documento de definición de software y objetivos revisado y aprobado por el responsable.

SW-02 — Revisión de gestión de flotas

Estado: 🟢 aprobado · Prioridad: alta · Tipo: software

Campo	Valor
Subsistema	gcs
Version baseline	—
Origen	Cronograma HIVE2-RoadMap — S2 (Revisión de Gestión de Flotas)
Depende de	`SW-16`

Descripcion. Revisar y actualizar el subsistema de gestión de flotas de Scouts (alta, estado, asignación y monitorización de múltiples drones desde la GCS).

Objetivo. La gestión de flotas revisada permite dar de alta, monitorizar y asignar misiones a varios Scouts desde la GCS.

Verificacion (demostracion). Demostración: desde la GCS se listan y monitorizan varios Scouts y se les asignan misiones.

SW-03 — Definición y codificación de misiones

Estado: 🟢 aprobado · Prioridad: critica · Tipo: software ⚑ IP-CORE

Campo	Valor
Subsistema	gcs
Version baseline	—
Origen	Cronograma HIVE2-RoadMap — S3 (Definición y codificación de misiones)
Depende de	`INT-06`, `INT-07`

Descripcion. Definir el modelo de misión de GUARDIAN separando plan (reutilizable: tipo + geometría + parámetros) de ejecución (instancia con dron, vertipuerto, resultado y registro), con un flujo de definición común por hitos sobre el mapa. Tipos soportados: fotogramétrica (grid con solape frontal/lateral, GSD/altitud AGL y subzonas, adaptada de HIVE2), SAR (patrón de búsqueda con menor solape y objetivo por reconocimiento IA — clase a detectar, cámara visible/térmica, acción al detectar: loiter y espera de instrucción con timeout configurable y acción al expirar) y target (aproximación a un objetivo con los patrones heredados del modo attack de HIVE2 pero manteniéndose a distancia y altura de standoff configurables, sin contacto). El vuelo manual (gamepad) no es un tipo de misión sino un modo de vuelo: no se define, se pilota, y su sesión queda registrada como una ejecución. Toda misión se ejecuta dentro de la geofence y bajo los fail-safes de energía y enlace del sistema.

Objetivo. Se puede definir cualquiera de los tres tipos de misión con un flujo común por hitos y ejecutarla de forma autónoma desde la GCS.

Verificacion (demostracion). Demostración: una misión de cada tipo (fotogramétrica, SAR, target) se define con el flujo por hitos y se ejecuta (en simulador o vuelo real) siguiendo el plan definido; una sesión de vuelo manual queda registrada como ejecución.

SW-04 — Redefinición de web corporativa

Estado: 🟢 aprobado · Prioridad: baja · Tipo: software

Campo	Valor
Subsistema	sistema
Version baseline	—
Origen	Cronograma HIVE2-RoadMap — S4 (Redefinición de Web corporativa)
Depende de	—

Descripcion. Rediseñar y actualizar la web corporativa de LeftCape/GUARDIAN.

Objetivo. Web corporativa redefinida y publicada.

Verificacion (inspeccion). Inspección: la nueva web corporativa está publicada y accesible.

SW-05 — Revisión de ejecución de vuelo en simulador

Estado: 🟡 borrador · Prioridad: alta · Tipo: software

Campo	Valor
Subsistema	gcs
Version baseline	—
Origen	Cronograma HIVE2-RoadMap — S5 (Revisión de Ejecución de vuelo en simulador)
Depende de	—

Descripcion. Revisar y validar la ejecución de vuelo del Scout en el simulador con el nuevo software.

Objetivo. El vuelo se ejecuta correctamente en el simulador con el software actualizado.

Verificacion (demostracion). Demostración en simulador: un vuelo se ejecuta de principio a fin sin fallos con el software revisado.

SW-06 — Pilotado manual asistido con gamepad

Estado: 🟢 aprobado · Prioridad: alta · Tipo: software

Campo	Valor
Subsistema	gcs
Version baseline	—
Origen	Cronograma HIVE2-RoadMap — S6 (Vuelo con gamepad en simulador); redefinido en la sesión 05-08-2026 como pilotado asistido multirrotor sobre simulación avanzada, adaptando el sistema joystick de HIVE2 (hive-ground / C2_V1). Ampliado en la sesión 11-08-2026 con las dos leyes de control elegibles por el operador: el texto anterior fijaba LOITER como único modo, pero la sesión de vuelo del 09-08 con mando físico mostró que en LOITER el stick no manda intensidad (lo satura el controlador de posición en LOIT_SPEED) — deuda que dejó anotada la historia SW-06.3 al implementar el modo directo. Se apunta además la red de seguridad del modo directo, que es INT-06, no el autopiloto.
Depende de	`SW-02`, `SW-22`, `SW-24`

Descripcion. Modo de pilotado manual desde la C2 con un gamepad (Gamepad API del navegador), limitado a drones de modelo multirrotor: el operador toma y suelta el control de forma gobernada (enable/disable vía API + despachador, con ACK confirmado por telemetría, patrón SW-18.5), y elige la LEY DE CONTROL con la que pilota, cambiable en pleno vuelo sin soltar el mando: asistido (LOITER: el stick pide velocidad, soltarlo mantiene posición y altitud) por defecto, o directo (ALT_HOLD: el stick manda ángulo, la respuesta es proporcional a la deflexión pero el dron no frena solo). Son dos leyes con un trade-off real entre seguridad y autoridad de mando, y la decisión es del operador: la interfaz nombra cada una en términos de lo que hace el dron —no con la nomenclatura del autopiloto— y explica el trade-off. La red de seguridad del modo directo no es el autopiloto sino la protección activa de la geofence (INT-06), que frena proporcionalmente la autoridad del mando al agotarse el margen, con el radar de proximidad (SW-26) como instrumento de referencia del piloto. El stream de ejes viaja del navegador al puente del dron por MQTT en un paquete binario compacto a ~20 Hz con heartbeat (adaptación del protocolo joystick de HIVE2: hive-ground + useGamepad), y el puente lo convierte en RC override MAVLink con deadzone y filtro paso bajo. Seguridad: watchdog en el puente que libera el RC override si el stream o el heartbeat se cortan; ARM/DISARM jamás desde el mando; el modo respeta los gates de la C2 (solo-lectura del HQ, REAL_FLIGHT_ENABLED para drones reales). Incluye configuración del mapeo de ejes y botones del gamepad (calibración/asignación) persistida en el puesto del operador. Se verifica en simulación avanzada (SW-24); el mismo camino sirve para el dron real.

Objetivo. Un operador pilota un multirrotor con gamepad desde la GCS con la ley de control que elija: toma el control cuando lo necesita, la cambia en vuelo sin soltar el mando, y lo suelta (o lo pierde por watchdog) quedando el dron siempre en un modo estabilizado seguro.

Verificacion (demostracion). Demostración en simulación avanzada (ArduPilot SITL, multirrotor): el operador habilita el modo gamepad sobre un dron en vuelo, lo pilota de forma estable en modo asistido (los cuatro ejes responden; sticks sueltos = mantiene posición), cambia a directo en pleno vuelo sin perder el mando y comprueba que la respuesta es proporcional a la deflexión del stick, vuelve a asistido, lo deshabilita y el dron queda en modo estabilizado; al cortar el stream, el watchdog libera el RC override solo y queda registrado; un intento sobre un dron no multirrotor (o sin gamepad conectado) se rechaza con motivo; el mapeo de botones/ejes es configurable y persiste.

SW-07 — Integración de vídeo y telemetría con el nuevo sistema

Estado: 🟡 borrador · Prioridad: critica · Tipo: software

Campo	Valor
Subsistema	gcs
Version baseline	—
Origen	Cronograma HIVE2-RoadMap — S7 (Pruebas de integración de vídeo y telemetría con nuevo sistema)
Depende de	—

Descripcion. Integrar la recepción de vídeo y telemetría del Scout en el nuevo sistema y validarla end-to-end.

Objetivo. Vídeo y telemetría del Scout se reciben y muestran en la GCS con el nuevo sistema.

Verificacion (test). Prueba de integración: vídeo y telemetría llegan a la GCS de forma sincronizada y estable con el nuevo sistema.

SW-08 — Georreferenciación de vídeo

Estado: 🟡 borrador · Prioridad: alta · Tipo: software ⚑ IP-CORE

Campo	Valor
Subsistema	gcs
Version baseline	—
Origen	Cronograma HIVE2-RoadMap — S8 (Georreferenciación de vídeo)
Depende de	`SW-07`

Descripcion. Georreferenciar el vídeo del Scout: asociar cada fotograma a coordenadas geográficas usando telemetría de posición y actitud.

Objetivo. El vídeo se muestra georreferenciado sobre el mapa en la GCS.

Verificacion (demostracion). Demostración: el vídeo aparece correctamente georreferenciado sobre cartografía en la GCS.

SW-09 — Generación de cartografía en near/real-time

Estado: 🟡 borrador · Prioridad: alta · Tipo: software ⚑ IP-CORE

Campo	Valor
Subsistema	gcs
Version baseline	—
Origen	Cronograma HIVE2-RoadMap — S9 (Generación de cartografía en near/realtime)
Depende de	`SW-08`

Descripcion. Generar cartografía (mosaico/ortofoto) del área vigilada en tiempo casi real a partir del vídeo georreferenciado.

Objetivo. Se genera cartografía del área vigilada en near-realtime durante la misión.

Verificacion (demostracion). Demostración: durante una misión se genera cartografía del área en tiempo casi real.

SW-10 — Definición de especificaciones LORA con SysTech

Estado: 🟡 borrador · Prioridad: media · Tipo: mixto

Campo	Valor
Subsistema	gcs
Version baseline	—
Origen	Cronograma HIVE2-RoadMap — S10 (Definición de especificaciones LORA con SysTech)
Depende de	—

Descripcion. Definir con SysTech las especificaciones del enlace LORA para el sistema (bandas, alcance, throughput, protocolo).

Objetivo. Especificaciones LORA acordadas con SysTech y documentadas.

Verificacion (inspeccion). Inspección: documento de especificaciones LORA acordado con SysTech.

SW-11 — Adaptación de LORA a la GCS

Estado: 🟡 borrador · Prioridad: alta · Tipo: software

Campo	Valor
Subsistema	gcs
Version baseline	—
Origen	Cronograma HIVE2-RoadMap — S11 (Adaptación de LORA a la GCS)
Depende de	`SW-10`

Descripcion. Integrar el enlace LORA en el software de la GCS según las especificaciones definidas con SysTech.

Objetivo. La GCS gestiona el enlace LORA (envío/recepción) según las especificaciones.

Verificacion (test). Prueba: la GCS establece y usa el enlace LORA conforme a las especificaciones acordadas.

SW-12 — Detección y alertas por IA/CV

Estado: 🟡 borrador · Prioridad: critica · Tipo: software ⚑ IP-CORE

Campo	Valor
Subsistema	gcs
Version baseline	—
Origen	Cronograma HIVE2-RoadMap — S12 (Detección y alertas por IA/CV, resp. Manuel)
Depende de	—

Descripcion. Detectar objetos/eventos de interés en el vídeo mediante IA/visión por computador y generar alertas.

Objetivo. El sistema detecta objetos de interés en el vídeo y genera alertas en la GCS.

Verificacion (demostracion). Demostración: sobre vídeo real o grabado, el sistema detecta objetos de interés y emite alertas.

SW-13 — Tracking de objetivos con IA/CV — preparación del entorno de simulación

Estado: 🟡 borrador · Prioridad: alta · Tipo: software

Campo	Valor
Subsistema	gcs
Version baseline	—
Origen	Cronograma HIVE2-RoadMap — S13 (Tracking de objetivos IA/CV — preparación entorno simulación, resp. Iván)
Depende de	—

Descripcion. Preparar el entorno de simulación para desarrollar y validar el tracking de objetivos por IA/CV.

Objetivo. Entorno de simulación listo para desarrollar y probar el tracking de objetivos.

Verificacion (inspeccion). Inspección: el entorno de simulación de tracking está montado y operativo.

SW-14 — Tracking de objetivos con IA/CV — implementación

Estado: 🟡 borrador · Prioridad: critica · Tipo: software ⚑ IP-CORE

Campo	Valor
Subsistema	gcs
Version baseline	—
Origen	Cronograma HIVE2-RoadMap — S14 (Tracking de objetivos IA/CV — implementación en entorno de simulación)
Depende de	`SW-12`, `SW-13`

Descripcion. Implementar el seguimiento (tracking) de objetivos detectados mediante IA/CV en el entorno de simulación.

Objetivo. El sistema mantiene el tracking de un objetivo detectado a lo largo del vídeo.

Verificacion (demostracion). Demostración: un objetivo detectado es seguido de forma continua por el sistema de tracking.

SW-15 — Definición del sistema de gestión de eventos

Estado: 🟡 borrador · Prioridad: alta · Tipo: software

Campo	Valor
Subsistema	gcs
Version baseline	—
Origen	Cronograma HIVE2-RoadMap — S15 (Definición de sistema de gestión de eventos, resp. Luis/Iván)
Depende de	`SW-12`

Descripcion. Definir el sistema de gestión de eventos: cómo se generan, priorizan y presentan al operador los eventos (detecciones, alertas, incidencias).

Objetivo. Modelo de gestión de eventos definido: los eventos de la misión se registran, priorizan y muestran al operador.

Verificacion (inspeccion). Inspección: existe una definición del sistema de gestión de eventos revisada.

SW-16 — Plataforma software base de GUARDIAN (patrón HIVE2)

Estado: 🟢 aprobado · Prioridad: critica · Tipo: software

Campo	Valor
Subsistema	gcs
Version baseline	—
Origen	HIVE2 (hive-hmi + services/hive-endpoint) — plataforma software reutilizada para GUARDIAN
Depende de	—

Descripcion. Plataforma sobre la que se construye todo el software de operador de GUARDIAN, portada del patrón HIVE2: front React + Vite + Tailwind con un contrato único de entidades (tipo collections.js) del que se derivan grids y formularios CRUD; configurador de vistas en runtime (qué campos se ven en listados y formularios, orden, búsqueda); sistema de temas y accesibilidad (tamaño de fuente y densidad configurables); landing con login y Home de módulos; y el design system Palantir 'Obsidian Sentinel'. Backend FastAPI + MongoEngine con patrón de entidad uniforme. Es la base de la que dependen los casos de uso concretos (gestión de flotas, misiones, etc.).

Objetivo. Existe una plataforma funcional en la que dar de alta una entidad nueva (definiendo sus campos) genera su CRUD de front (grid + formulario) con vistas configurables y estilo Obsidian Sentinel, tras login desde el Home de módulos.

Verificacion (demostracion). Demostración: tras login se accede al Home de módulos; una entidad definida por su contrato de campos muestra listado y formulario CRUD funcionales; el configurador de vistas permite elegir campos/orden/búsqueda en runtime; y el tamaño de fuente es ajustable, todo con el design system Obsidian Sentinel.

Pendiente

TODO(Luis): confirmar alcance del portado HIVE2->GUARDIAN (qué módulos se traen y cuáles no)
TODO(Luis): fijar versión de React/Vite/Tailwind objetivo y estrategia de fork vs copia

SW-17 — Consola de despliegue de GUARDIAN (patrón hive-deploy)

Estado: 🟢 aprobado · Prioridad: alta · Tipo: software

Campo	Valor
Subsistema	sistema
Version baseline	—
Origen	HIVE2/hive-deploy — consola de despliegue reutilizada (esqueleto) para GUARDIAN
Depende de	`INT-05`

Descripcion. Capacidad de despliegue integrada en el propio GUARDIAN para registrar, configurar, desplegar y monitorizar los nodos y servicios compartidos de la malla, portando de la consola HIVE2 (hive-deploy) el motor y el editor de topología, vaciados de su dominio. Con la auto-federación (INT-05.1) no es una app aparte: el backend es un servicio del nodo (guardian-deploy, server Express con persistencia en ficheros JSON) y la UI es un workspace del frontend de guardian, con streaming de logs de despliegue por WebSocket y despliegue local o remoto (SSH). Despliega nodos completos (stack de INT-05.2) y servicios compartidos sueltos (GIS/VPN/DNS, INT-05.11), gobernado por el cupo de licencias en cascada (INT-05.1).

Objetivo. Desde la interfaz de un nodo no-edge se puede dar de alta un nodo hijo o un servicio compartido, lanzar su despliegue (local o SSH) viendo los logs en vivo, y consultar su estado; el despliegue se bloquea sin cupo de licencias.

Verificacion (demostracion). Demostración: la consola levanta front y server; se registra un nodo, se lanza un despliegue de prueba con logs en streaming por WebSocket, y su estado se muestra en el panel.

Pendiente

TODO(Luis): decidir persistencia definitiva (JSON como hive-deploy vs. BD) y estrategia de auth

SW-18 — Programación de misiones (scheduling recurrente)

Estado: 🟢 aprobado · Prioridad: alta · Tipo: software

Campo	Valor
Subsistema	gcs
Version baseline	—
Origen	Definición de misiones GUARDIAN — sesión 24-07-2026; revisado y aprobado por Luis en la sesión de planificación del 29-07-2026
Depende de	`SW-02`, `SW-03`

Descripcion. Planificador persistente de misiones recurrentes por SUB-MISIÓN (SW-03.11/SW-03.12: la subdivisión con su dron ya asignado): recurrencia diaria, por días de semana o cada N semanas, con varias horas de salida al día y ventana de validez; cada ocurrencia crea la ejecución correspondiente. El tiempo máximo en el aire planificable se estima con la velocidad media (parámetro de la planificación) y la autonomía del modelo, descontando la reserva de RTH: el retorno se dispara por PORCENTAJE DEL VOLTAJE TOTAL (p. ej. RTH al llegar al 20%), no por tiempo — el umbral por defecto y el perfil de retorno (preset/direct, INT-07) vienen del modelo del dron y la misión puede sobreescribirlos. El intervalo mínimo entre misiones es una restricción del sistema: max(valor configurado, tiempo de misión + tiempo de recarga del modelo del dron), validada al crear el calendario y en runtime (se aplaza la salida si la batería no alcanza el umbral de despegue). Cola con prioridades: una misión a demanda desplaza a la programada sin cancelarla, y toda misión saltada o aplazada queda registrada con su motivo. Un calendario puede quedar suspendido con causa (p. ej. incidencia en una ejecución previa) hasta revisión manual.

Objetivo. Los drones salen a volar solos según el calendario de cada sub-misión, sin violar nunca el intervalo mínimo de recuperación ni la reserva de voltaje del RTH.

Verificacion (demostracion). Demostración: un calendario recurrente sobre una sub-misión lanza sus ejecuciones automáticamente en sus horas; el sistema rechaza un calendario que viole el intervalo mínimo o cuya duración estimada (velocidad media + autonomía) invada la reserva de voltaje del RTH; y aplaza en runtime una salida con batería insuficiente, registrando el motivo.

SW-19 — Registro de vuelo y replay (telemetría, vídeo y eventos en la nube)

Estado: 🟡 borrador · Prioridad: alta · Tipo: software

Campo	Valor
Subsistema	sistema
Version baseline	—
Origen	Definición de misiones GUARDIAN — sesión 24-07-2026
Depende de	`SW-07`

Descripcion. Registro completo de cada misión — telemetría con timestamp por muestra, vídeo y eventos — con subida a la nube GUARDIAN activable por misión y en dos fases: telemetría y eventos al aterrizar (ligeros, inmediatos), vídeo en diferido con cola y reintentos (nunca bloquea la disponibilidad del log). Cada segmento de vídeo registra su instante de inicio y cortes en el mismo reloj que la telemetría para poder sincronizarlos. Replay del vuelo con línea de tiempo única que sincroniza mapa (posición/actitud), telemetría y vídeo, con seek y control de velocidad. El estado de la misión distingue 'telemetría disponible' de 'media completa'.

Objetivo. Cualquier vuelo registrado se puede reproducir después: mapa, telemetría y vídeo sincronizados en una sola línea de tiempo.

Verificacion (demostracion). Demostración: tras una misión con registro activado, telemetría y eventos están en la nube al aterrizar y el vídeo sube en diferido; el replay reproduce el vuelo sincronizado con seek y control de velocidad.

SW-20 — Gestión de enlaces vertipuerto–dron y multi-dron por edge

Estado: 🟡 borrador · Prioridad: alta · Tipo: software

Campo	Valor
Subsistema	sistema
Version baseline	—
Origen	Definición de misiones GUARDIAN — sesión 24-07-2026 (debate enjambre y comunicaciones)
Depende de	`INT-05`

Descripcion. Gestor de enlaces en el nodo edge que modela cada enlace de comunicación con el dron como un recurso con capacidades declaradas: OpenHD (punto a punto, exclusivo — un dron a la vez —, C2 completo y vídeo), LoRa (multi-dron, ancho de banda mínimo, solo set básico de comandos: RTL/LAND/LOITER, sin vídeo) y 5G/IP (multi-dron simultáneo, C2 completo y vídeo). Cada comando del sistema declara su clase mínima de enlace; el edge enruta cada comando por el mejor enlace disponible para ese dron o lo rechaza con motivo visible. La atención de un enlace exclusivo es un recurso conmutable: el switch entre drones es una operación explícita con estado visible en la GCS. Regla de arquitectura (dos planos): a un dron siempre se le comanda a través de su nodo edge, dueño de sus enlaces; la coordinación entre vertipuertos (enjambre multi-nodo, fase B) viaja por la malla de nodos y el Testigo C2 (INT-05), nunca por radio directa a drones de otro nodo. Los enlaces hacia los drones son distintos del backhaul del vertipuerto (salida al exterior por ethernet o 4/5G hacia la malla de nodos): el gestor administra los primeros; el backhaul es conectividad del nodo (INT-05). Qué interfaces existen en cada vertipuerto lo declara su entidad (SW-02.3); este gestor las opera en runtime. Soporta el prototipo de vertipuerto con dos drones: vuelo secuencial de relevo por OpenHD (cobertura temporal) y comandado básico simultáneo por LoRa.

Objetivo. Un edge con varios drones y enlaces heterogéneos comanda cada dron por el enlace adecuado, conmuta la atención de forma explícita y rechaza con motivo lo que el enlace activo no soporta.

Verificacion (demostracion). Demostración con dos drones (simulados) en un edge: vuelo secuencial de relevo con switch de atención OpenHD, RTL simultáneo a ambos por el canal básico, y rechazo con motivo de una subida de waypoints por un enlace que no la soporta.

SW-21 — Herramienta de teatros de operaciones con geofence (definición y compilación)

Estado: 🟢 aprobado · Prioridad: alta · Tipo: software ⚑ IP-CORE

Campo	Valor
Subsistema	gcs
Version baseline	—
Origen	Definición de teatros con geofence — sesión 25-07-2026 (brainstorming con Luis: raster compilado desde DEM + envolvente + reglas vectoriales)
Depende de	`SW-03`, `SW-16`, `INT-06`

Descripcion. Editor específico del teatro de operaciones que lo eleva de simple encuadre (punto + zoom, SW-03.1) a zona de operación con geofence propia. Proceso por pasos sobre el mapa: (1) encuadre (nombre, punto, zoom); (2) fuente de datos pedida al geotile-server, elegible (DEM del SRTM en disco o del IGN — MDT/MDS —, e imagen de fondo PNOA/satélite); (3) envolvente global de vuelo, dos alturas AGL para todo el teatro (mínima y máxima); (4) reglas locales opcionales dibujadas como polígonos vectoriales tipificados (zonas de exclusión; zonas con altura mínima propia); (5) compilación en el nodo edge de un raster de geofence en cotas MSL (terreno + envolvente ya resueltos; las exclusiones se rasterizan como NoData), con resolución configurable (bajable) y previsualización sobre el mapa; (6) persistencia en el servidor de las tres representaciones: raster compilado, vectores originales y parámetros (la receta). El raster es el motor de consulta en tiempo real (dentro/cerca del borde por planimetría y altimetría, coste O(1) por celda); los vectores originales se conservan para poder derivar la envolvente simplificada que se carga en el autopiloto (capa 2 de INT-06). Las misiones del teatro heredan su geofence: dejan de definirla por misión. Es la materialización de la capa 1 de INT-06 (GUARDIAN define e impone la geofence rica).

Objetivo. Se puede crear un teatro de operaciones con su geofence completa (envolvente + exclusiones + alturas locales) compilada a raster y previsualizada, y las misiones que cuelgan de él heredan ese marco sin redefinirlo.

Verificacion (demostracion). Demostración: se define un teatro con DEM del geotile-server, envolvente min/max y una zona de exclusión; se compila el raster de geofence y se previsualiza sobre el mapa; una misión creada en ese teatro hereda la geofence sin volver a definirla.

SW-22 — Panel de operaciones: estado y control de las misiones en vivo

Estado: 🟢 aprobado · Prioridad: alta · Tipo: software

Campo	Valor
Subsistema	gcs
Version baseline	—
Origen	Análisis de activación de la ejecución de misiones — sesión 30-07-2026; inspirado en el panel Command & Control de HIVE2 (CommandControlWorkspace)
Depende de	`SW-02`, `SW-03`, `SW-18`

Descripcion. Panel de operaciones (C2) de la GCS que agrega el estado en vivo de TODAS las ejecuciones de misión del nodo: tablero de ejecuciones (planned|running|paused|completed|aborted) alimentado por eventos en tiempo real, con filtros por teatro/dron/estado y distintivo simulador/real; monitor de la bitácora del planificador (mission_dispatch_log: por qué una salida se lanzó, aplazó, desplazó, saltó o suspendió); y vista C2 de la ejecución seleccionada — mapa con trayectoria planificada vs posición real, instrumentos de vuelo por telemetría y los mandos de ejecución de SW-03 (lanzar, pausar, reanudar, abortar). En el HQ el mismo tablero opera sobre las ejecuciones replicadas de su subárbol en solo lectura; los mandos exigen el testigo C2 (INT-05). Separa definición de operación: el flujo por hitos (SW-03) define la misión y hace el go/no-go; el vuelo se sigue y gobierna desde este panel.

Objetivo. Un operador ve de un vistazo el estado de todas las misiones (en vuelo, programadas, aplazadas y terminadas, con su porqué) y gobierna cualquier ejecución en vivo desde un único panel.

Verificacion (demostracion). Demostración con el simulador: con varias ejecuciones simultáneas (una en vuelo, una programada, una aplazada por batería y una abortada), el tablero refleja cada estado y su motivo en tiempo real; la vista C2 de la ejecución en vuelo muestra posición, progreso e instrumentos y responde a pausar/reanudar/abortar; el HQ muestra el mismo estado replicado en solo lectura.

SW-23 — Navegación temporal de la programación (proyección y ensayo)

Estado: 🟢 aprobado · Prioridad: media · Tipo: software

Campo	Valor
Subsistema	gcs
Version baseline	—
Origen	Tormenta de ideas de Luis sobre control temporal tipo Cesium — sesión 04-08-2026; reformulada en dos niveles (proyección/ensayo) para no tocar el reloj operacional. Revisado y aprobado por Luis en la misma sesión (04-08-2026).
Depende de	`SW-03`, `SW-18`

Descripcion. Control temporal sobre la programación de misiones, en dos niveles que NO tocan el reloj del sistema operacional. (1) NAVEGADOR TEMPORAL: la ventana del calendario de programación (SW-18.4) se puede mover libremente por año/mes/día/hora (scrub) con un marcador de 'ahora'; es solo lectura y vale igual para misiones sim y reales, porque solo expande calendarios a ocurrencias — un instante que cae en mitad de un vuelo se pinta como vuelo en curso, sin efecto alguno. (2) PROYECCIÓN DE DESPACHO: un motor discreto puro aplica hacia delante las MISMAS reglas del lanzador y la planificación (ventana de gracia y aplazada/desplazada/saltada de SW-18.2; intervalo mínimo, reserva RTH y recarga de SW-18.3; suspensiones) y pinta el dispatch log PREVISTO de la ventana apuntada. Control tipo scrub/play/stop SIN multiplicadores de velocidad: el avance es por eventos discretos (siguiente salida/aterrizaje/recarga); mover el tiempo a mano pone stop automáticamente; play anima la proyección desde el instante apuntado; stop descarta y vuelve al ahora real (no hay pause: la proyección se recalcula, no se conserva). Las misiones cuya salida cae antes del instante apuntado heredan la semántica de gracia existente: dentro de la ventana se lanzan en ese momento, fuera quedan saltadas con motivo. ENGANCHE FUTURO (no en este alcance): modo ensayo con reloj de nodo desplazado (core/clock.py) para volar drones sim una jornada futura, restringido a nodo sandbox y nunca con drones reales (salvaguarda tipo REAL_FLIGHT_ENABLED, SW-03.16).

Objetivo. Un planificador ve qué saldrá a volar en cualquier fecha futura — y qué se aplazará o saltará y por qué — sin arriesgar el sistema operacional ni mover ningún reloj de verdad.

Verificacion (demostracion). Demostración: la ventana del calendario se mueve a una fecha futura arbitraria (año/mes/día/hora) y muestra las salidas proyectadas de calendarios sim y reales con el marcador de ahora; la proyección de despacho sobre un escenario con batería/recarga justas predice lanzada/aplazada/saltada con el MISMO resultado que produce el lanzador real al reproducir ese escenario con el simulador; mover el tiempo a mano pone stop, play anima la proyección evento a evento desde el instante apuntado y stop devuelve la vista al ahora real sin dejar rastro en ejecuciones ni dispatch log.

SW-24 — Entornos de ejecución: simulación avanzada con ArduPilot SITL

Estado: 🟢 aprobado · Prioridad: alta · Tipo: software

Campo	Valor
Subsistema	gcs
Version baseline	—
Origen	Hito de pilotado con gamepad — sesión 05-08-2026: el modo asistido exige el autopiloto real (RC override), que el sim-lite no implementa
Depende de	`SW-02`, `SW-03`, `SW-16`

Descripcion. Tres canales de control por dron, explícitos y auditables (patrón SW-03.16): 'sim' (guardian-sim-lite, física ligera), 'sim_advanced' (ArduPilot SITL real — el autopiloto de verdad corriendo en SITL, con un puente MAVLink↔MQTT que conserva EXACTAMENTE el mismo contrato de topics y mensajes que el sim-lite, de modo que despachador, C2, telemetría y fail-safes funcionan idénticos sin tocarse) y 'real' (dron físico). La ejecución hereda el environment del canal del dron y la UI lo distingue. La simulación avanzada solo admite drones cuyo modelo sea de tipología multirrotor: el arranque del puente y la validación lo rechazan con motivo para otras tipologías. Es la base de verificación de los modos de vuelo que exigen el autopiloto real (pilotado asistido SW-06).

Objetivo. Poder verificar comportamiento real del autopiloto (modos de vuelo, RC, fail-safes) sin dron físico: un dron 'sim_advanced' opera en GUARDIAN exactamente igual que uno 'sim', pero con ArduPilot de verdad debajo.

Verificacion (demostracion). Demostración: un dron multirrotor en canal 'sim_advanced' ejecuta una misión completa E2E (despacho, telemetría en la C2, pausar/reanudar/abortar/aterrizar) contra ArduPilot SITL con el mismo contrato que el sim-lite; un dron de modelo no multirrotor en 'sim_advanced' es rechazado con motivo explícito; el tablero distingue sim, sim avanzada y real.

SW-25 — Entorno virtual 3D: escenario de terreno real para pilotaje y conciencia situacional en C2

Estado: 🟢 aprobado · Prioridad: media · Tipo: software

Campo	Valor
Subsistema	gcs
Version baseline	—
Origen	Reto de cliente 3D personalizado de mando y control — sesión 06-08-2026. Materializa la 'mejora futura' anotada en la historia SW-22.8 (FPV sintética 2.5D): 3D con terreno real. Motor reutilizado del prototipo hive-gis-client/test/3d-scenariosV4 (Three.js quadtree LOD).
Depende de	`SW-06`, `SW-22`, `SW-24`

Descripcion. Entorno virtual 3D de la C2: un escenario de terreno real renderizado en Three.js (quadtree LOD estilo Cesium sobre teselas del geotile del nodo — ortofoto + DEM Terrain-RGB, con cámara de libertad total y objetos 3D arbitrarios) que se abre a pantalla completa desde la vista C2 sobre la ejecución y el dron ya seleccionados. Nace de la limitación de MapLibre/deck.gl (sin giro libre de cámara ni objetos 3D) y de Cesium (formato de MDT propio); reutiliza el motor del prototipo 3d-scenariosV4. El entorno NO reinventa el mando y control: consume la MISMA telemetría MQTT (guardian/telemetry/{nodo}/{dron}, MAVLink→JSON) para animar el dron 3D con su pose y actitud en vivo; incorpora los MISMOS instrumentos de vuelo (horizonte/altímetro/velocidad), la FPV, el perfil de altitud y los mandos de ejecución por REST (lanzar/pausar/reanudar/abortar/aterrizar, SW-22) que la C2 2D; y permite pilotar reutilizando INTACTO el canal de pilotado asistido con gamepad y su gobierno (SW-06: stream binario a guardian/joystick, watchdog del puente, gates de la C2). El backend (despachador y puente) no cambia: el contrato de topics y endpoints es agnóstico del cliente. Todos los parámetros del escenario (fuentes de teselas, refinamiento SSE, presupuestos de memoria, sol/cielo/niebla, presets de cámara del dron, minimapa) se configuran y persisten desde una pestaña de Configuración dedicada. En el HQ el entorno opera en solo lectura (display, sin mandos ni pilotaje), como el resto de la C2.

Objetivo. Un operador abre a pantalla completa un escenario 3D de terreno real desde la C2, ve su dron volar en él con telemetría en vivo e instrumentos, y lo pilota con gamepad de forma gobernada — todo sobre el mismo canal de mando y control que la C2 2D, sin cambios en el backend.

Verificacion (demostracion). Demostración en simulación avanzada (ArduPilot SITL, multirrotor ADV-001): desde la vista C2 de una ejecución en vuelo se abre el entorno virtual 3D a pantalla completa; el terreno real se renderiza sobre las teselas del geotile del nodo con cámara de libertad total; el dron aparece en su posición y actitud reales y se mueve con la telemetría en vivo; los instrumentos, la FPV y el perfil reflejan el mismo estado que la C2 2D; el operador habilita el modo gamepad, pilota el dron de forma estable dentro del escenario y lo deshabilita (mismo gobierno que SW-06); los parámetros del escenario se ajustan desde la pestaña de configuración y persisten entre sesiones; en un nodo HQ el entorno es solo-lectura.

SW-26 — Radar de proximidad a la geofence para pilotaje manual

Estado: 🟢 aprobado · Prioridad: alta · Tipo: software ⚑ IP-CORE

Campo	Valor
Subsistema	gcs
Version baseline	—
Origen	Sesión 11-08-2026 con Luis (boceto a mano de la envolvente orientada al rumbo): en pilotaje manual el perfil y los waypoints dejan de servir; hace falta un instrumento de proximidad al volumen de operación. Consume el raster de geofence compilado en SW-21.3 y releva en pantalla al perfil de altitud de SW-22.7.
Depende de	`SW-06`, `SW-21`, `SW-22`, `INT-06`

Descripcion. Instrumento de conciencia de proximidad que releva al perfil de altitud y la tira de waypoints en la vista C2 mientras el operador tiene el control manual tomado (SW-06), y vuelve a ceder su sitio al soltarlo: en pilotaje manual no hay plan que seguir, sino márgenes que no rebasar. Presenta el vecindario inmediato del dron como una envolvente en planta ORIENTADA AL RUMBO y ANISÓTROPA por velocidad: el semieje mayor apunta a proa y crece con el horizonte temporal (v·tau, tau configurable), el semieje menor es fijo, y el dron NO va centrado sino desplazado hacia popa (más look-ahead que look-behind, mismo criterio que el perfil de altitud de SW-22.7); parado, la envolvente degenera a círculo porque el riesgo deja de tener dirección preferente. Lo que se colorea NO es el MDT crudo sino el MARGEN A LA VIOLACIÓN de la geofence compilada del teatro (SW-21) celda a celda —distancia a NoData en planimetría, y las holguras alt−suelo y techo−alt en altimetría—, con una rampa verde (lejano/seguro) a rojo (inminente), de modo que un relieve alto solo se pinta caliente si de verdad recorta el margen a la altitud a la que se vuela. La componente vertical, que una planta no puede representar, se lee en un indicador propio de márgenes a techo y suelo con el mismo código de color. El cálculo de los márgenes es del NODO EDGE, nunca del navegador: el edge muestrea el raster de geofence alrededor de la posición y sirve la rejilla a cadencia configurable; el cliente solo pinta e interpola entre muestras. Incluye un display de alertas con nivel y causa legible (qué margen, cuánto queda, en qué dirección), y una pestaña de configuración propia (semiejes en píxeles, escala metros/píxel automática por velocidad u override manual, horizonte tau, umbrales de nivel, cadencia y rampa) persistida en el puesto del operador. Es display y aviso: la autoridad para actuar sobre el vuelo es de INT-06, no de este instrumento.

Objetivo. Un operador que pilota en manual ve en todo momento hacia dónde se le acaba el volumen de vuelo —adelante, a los lados, arriba y abajo— y recibe el aviso con causa y margen antes de rebasarlo, sin leer números sueltos ni interpretar un mapa.

Verificacion (demostracion). Demostración en simulación avanzada (ArduPilot SITL, multirrotor) sobre un teatro con geofence compilada que incluya una zona de exclusión: al tomar el control manual el panel inferior de la C2 conmuta del perfil de altitud al radar y vuelve al soltarlo; volando hacia la exclusión la envolvente se orienta al rumbo, se alarga al acelerar, degenera a círculo al detenerse, y las celdas de proa viran de verde a rojo conforme se recorta el margen; ascendiendo contra el techo permitido el indicador vertical vira igual y el display de alertas nombra la causa y el margen restante; los parámetros de la pestaña de configuración se ajustan y persisten entre sesiones.

SW-27 — Interfaz multiidioma: toda la UI y todo mensaje al usuario via tabla de traducciones

Estado: 🟢 aprobado · Prioridad: alta · Tipo: software

Campo	Valor
Subsistema	gcs
Version baseline	—
Origen	Sesión 12-08-2026 con Luis: la UI mezcla términos en inglés y español; decisión de internacionalizar con tabla de claves por idioma, selector en configuración y detección del idioma del navegador, para poder añadir idiomas traduciendo un solo fichero.
Depende de	—

Descripcion. La interfaz del GCS es multiidioma (español e inglés de partida) y AMPLIABLE: añadir un idioma se reduce a traducir un fichero de tabla y darlo de alta, sin tocar código. Todo texto presentado al usuario —etiquetas, menús, botones, tooltips, mensajes de estado, alertas, errores de validación y los mensajes originados en el backend— se resuelve a través de una tabla de traducciones con claves semánticas agrupadas por área (nunca la frase como clave), un fichero por idioma. El idioma se elige en la configuración del puesto del operador y persiste; por defecto se usa el del navegador, con inglés como respaldo si el idioma detectado no está soportado o falta una clave. El cambio de idioma es en caliente, sin recargar. El backend NUNCA envía prosa destinada al usuario: envía código + parámetros y el cliente los traduce con la misma tabla, de modo que el multiidioma no se rompa por la puerta de atrás con cada funcionalidad nueva. Fechas y números se formatean con la API Intl según el locale activo, no van en la tabla. La garantía de futuro es mecánica, no documental: una regla de lint en CI prohíbe literales de texto de usuario en el código de la UI, de modo que toda funcionalidad nueva nace multiidioma. Este requisito es transversal: toda historia futura con UI lo hereda como criterio de aceptación.

Objetivo. Un operador elige idioma en configuración (o hereda el del navegador) y toda la interfaz y todos los mensajes —incluidos los originados en el backend— se presentan en ese idioma sin textos sin traducir; añadir un idioma nuevo se reduce a traducir un fichero.

Verificacion (inspeccion). La regla de lint anti-literales pasa en verde sobre todo el frontend; recorrido completo de la UI en español y en inglés sin ningún texto sin traducir ni clave a la vista; el cambio de idioma en configuración surte efecto en caliente y persiste entre sesiones; con el navegador en un idioma no soportado la UI sale en inglés; un mensaje emitido por el backend (error de API o evento de dominio) se muestra traducido en el idioma activo.

VTP-01 — Definición de funcionalidades del vertipuerto

Estado: 🟡 borrador · Prioridad: critica · Tipo: mixto

Campo	Valor
Subsistema	vertiport
Version baseline	—
Origen	Cronograma HIVE2-RoadMap — V1 (Definición de funcionalidades, resp. Javi/Luis)
Depende de	—

Descripcion. Definir las funcionalidades del vertipuerto (base de despliegue, aterrizaje, resguardo y recarga del Scout).

Objetivo. Funcionalidades del vertipuerto definidas y documentadas.

Verificacion (inspeccion). Inspección: existe un documento de funcionalidades del vertipuerto revisado.

VTP-02 — Diseño de estructura y componentes mecánicos

Estado: 🟡 borrador · Prioridad: alta · Tipo: hardware

Campo	Valor
Subsistema	vertiport
Version baseline	—
Origen	Cronograma HIVE2-RoadMap — V2 (Diseño de estructura y componentes mecánicos, resp. Javi)
Depende de	`VTP-01`

Descripcion. Diseñar la estructura y los componentes mecánicos del vertipuerto.

Objetivo. Diseño mecánico del vertipuerto completado y listo para fabricación.

Verificacion (analisis). Análisis: el diseño de estructura y componentes mecánicos está documentado y validado.

VTP-03 — Fabricación de estructura y componentes mecánicos

Estado: 🟡 borrador · Prioridad: alta · Tipo: hardware

Campo	Valor
Subsistema	vertiport
Version baseline	—
Origen	Cronograma HIVE2-RoadMap — V3 (Fabricación de estructura y componentes mecánicos, resp. ext)
Depende de	`VTP-02`

Descripcion. Fabricar la estructura y los componentes mecánicos del vertipuerto (externalizado).

Objetivo. Estructura y componentes mecánicos del vertipuerto fabricados.

Verificacion (inspeccion). Inspección: la estructura y componentes mecánicos están fabricados conforme al diseño.

VTP-04 — Integración en PME

Estado: 🟡 borrador · Prioridad: alta · Tipo: mixto

Campo	Valor
Subsistema	vertiport
Version baseline	—
Origen	Cronograma HIVE2-RoadMap — V4 (Integración en PME, resp. ext)
Depende de	`VTP-03`

Descripcion. Integrar el vertipuerto en la Plataforma Móvil de Emplazamiento (PME).

Objetivo. Vertipuerto integrado en la PME.

Verificacion (demostracion). Demostración: el vertipuerto queda integrado y operativo sobre la PME.

VTP-05 — Electrónica de GCS, 5G, LORA y comunicación con el dron

Estado: 🟡 borrador · Prioridad: critica · Tipo: electronica

Campo	Valor
Subsistema	gcs
Version baseline	—
Origen	Cronograma HIVE2-RoadMap — V5 (Electrónica de GCS, 5G, LORA y comunicación con Drone, resp. Luis)
Depende de	`SW-11`

Descripcion. Desarrollar e integrar la electrónica de la GCS del nodo: 5G, LORA y comunicación con el Scout.

Objetivo. La electrónica del nodo comunica con el Scout por 5G y LORA desde la GCS.

Verificacion (test). Prueba: la electrónica de GCS establece comunicación con el dron por 5G y LORA.

VTP-06 — Sistema de carga eléctrica e integración con la electrónica

Estado: 🟡 borrador · Prioridad: critica · Tipo: electronica ⚑ IP-CORE

Campo	Valor
Subsistema	vertiport
Version baseline	—
Origen	Cronograma HIVE2-RoadMap — V6 (Sistema de carga eléctrica e integración con electrónica, resp. Javi/Luis)
Depende de	`VTP-04`

Descripcion. Desarrollar el sistema de carga eléctrica del Scout e integrarlo con la electrónica del vertipuerto.

Objetivo. El vertipuerto recarga el Scout de forma automática e integrada con su electrónica.

Verificacion (demostracion). Demostración: el Scout se recarga en el vertipuerto de forma automática.