Visualización y consolidación de datos de sistemas anti-dron

Trabajo Fin de GradoIngeniería Electrónica, Robótica y MecatrónicaVisualización y consolidación de datos de sistemasanti-dronAutor: Alejandro Perea BonillaTutor: Jesús Iván Maza AlcañizDpto. de Ingeniería de Sistemas y AutomáticaEscuela Técnica Superior de IngenieríaUniversidad de SevillaSevilla, 2025 Trabajo Fin de GradoIngeniería Electrónica, Robótica y MecatrónicaVisualización y consolidación de datos desistemas anti-dronAutor:Alejandro Perea BonillaTutor:Jesús Iván Maza AlcañizProfesor TitularDpto. de Ingeniería de Sistemas y AutomáticaEscuela Técnica Superior de IngenieríaUniversidad de SevillaSevilla, 2025 Trabajo Fin de Grado:Visualización y consolidación de datos de sistemas anti-dronAutor: Alejandro Perea BonillaTutor: Jesús Iván Maza AlcañizEl tribunal nombrado para juzgar el trabajo arriba indicado, compuesto por los siguientes profesores:Presidente:Vocal/es:Secretario:Acuerdan otorgarle la calificación de:El Secretario del Tribunal:Fecha: ÍndiceÍndiceIResumenIIIAbstractVAgradecimientosVII1.Introducción21.1.Objetivos21.2.Contribuciones22.Formato de datos para C-UAS de COURAGEOUS42.1.Contexto42.2.Descripción52.3.Planteamiento y Desarrollo52.4.Visualizador92.5.Página web102.5.1.Descripción102.5.2.Desarrollo102.6.Guía de Uso132.7.Conclusión143.Desarrollo de la herramienta software de visualización163.1.Interfaz163.2.Desarrollo203.3.Funcionamiento interno203.3.1.Librería de conversión (track2kml)213.3.2.Librería de CLI (track2kml-cli)233.3.3.Ejecutable (track2kml)243.4.Proceso de compilación243.5.Conclusiones254.Tratamiento de datos de loggers GPS264.1.Geodesia264.2.Especificaciones de los loggers GPS usados284.2.1.Funcionamiento externo284.2.2.Hardware interno294.2.3.Información del archivo NMEA294.2.4.Información del módulo GPS304.2.5.Información de sensores internos314.2.6.Información de los ficheros CSV314.2.7.Funcionamiento del conversor a CSV de Aaronia314.2.8.Opciones de generación de datos324.2.9.Aceleración33VII IIÍndice4.3.Software creado con esta información334.3.1.Media de datos posicionales (gpsavg)334.3.2.Conversión a formato COURAGEOUS (aag2courageous)354.4.Conclusión365.Pruebas de campo con sistemas C-UAS en el centro experimental de vuelo ATLAS385.1.Objetivo385.2.Organización395.2.1.Servidor NAS405.2.2.Servidor NTP405.3.Sistemas observados en las pruebas435.4.Pruebas realizadas465.5.Tareas realizadas476.Conclusiones486.1.Desarrollos futuros48Anexo50Índice de Figuras52Glosario54Bibliografía56 ResumenEste Trabajo de Fin de Grado desarrolla herramientas para visualizar y procesar datos del proyectoeuropeo COURAGEOUS, que establece una metodología estandarizada para evaluar sistemasanti-dron, también denominados Counter-Unmanned Aerial Systems (C-UAS) [1], a través de campañas depruebas con empresas del sector.Ante la ausencia de formatos estandarizados para almacenar datos generados por sistemas C-UAS,se ha diseñado e implementado el «formato COURAGEOUS», especializado para facilitar el análisis yvisualización posteriores. Este formato se ha desarrollado con el objetivo de ser lo más genérico posible,siendo compatible con todo tipo de C-UAS, incluyendo sistemas portables y de detección por cuadrantes.Su especificación se basa en un schema JSON, lo que permite generar automáticamente la documentacióndesde código y simplificar la verificación de archivos proporcionados por las empresas. Para facilitar suadopción, se ha elaborado una guía de uso, desarrollado un visualizador de schema y creado una páginaweb en el dominio de GRVC para la difusión de versiones y actualizaciones.Para detectar fallos temporales o geométricos durante las pruebas, se ha desarrollado una CommandLine Interface (CLI) que convierte archivos de diversos formatos, incluyendo el formato COURAGEOUS,a Keyhole Markup Language (KML) para su visualización en Google Earth Pro. Esta herramienta escompatible con todos los tipos de C-UAS que admite el formato, expone librerías reutilizables, funciona enWindows y Linux, e incluye scripts de compilación multiplataforma.Además, se ha investigado el funcionamiento de los receptores GPS utilizados en las pruebas C-UAS de laOTAN (C-UAS Technical Interoperability Exercise, [2]) para garantizar su uso correcto en COURAGEOUS.Se han desarrollado herramientas específicas: una para el cálculo de posiciones promedio y otra para laconversión de datos GPS al formato COURAGEOUS. Estas herramientas han sido esenciales para determinarla posición de los sistemas C-UAS y la trayectoria de los Unmanned Aerial Vehicles (UAVs) respectivamente.Finalmente, se ha participado presencialmente en las pruebas realizadas en el centro ATLAS de Jaén,validando en condiciones reales todas las herramientas y scripts desarrollados.IX 1.2. Contribuciones3•Una especificación del formato para verificar automáticamente que los archivos de datos proporcio-nados por las empresas siguieran la estructura y reglas impuestas•Documentación completa y guía de implementación•Una página web [10] para difusión de cambios y documentación•Una herramienta de visualización de esquemas JavaScript Object Notation (JSON) para facilitar sucomprensión2.track2kml (Capítulo3): Herramienta de conversión diseñada para simplificar la visualización y detec-ción de errores de datos C-UAS, permitiendo transformar distintos formatos de detección y rastreo dedrones a un archivo compatible con Google Earth.3.Herramientas de conversión y manejo de datos GPS (Capítulo4): Conjunto de utilidades paraobtener los datos de trayectoria de los drones usados en las pruebas, incluyendo herramientas deconversión y manejo de datos de posición GPS.4.Participación presencial en pruebas (Capítulo5): Asistencia a las empresas durante una de laspruebas, realizada en el Centro de Vuelo ATLAS.Todo el trabajo ha sido desarrollado y validado progresivamente en tres eventos oficiales del proyectoeuropeo, realizados en:•La academia policial de Markopoulo Mesogaias (Grecia)•La base militar de Lombardsijde (Bélgica)•El centro ATLAS de Jaén (España)En los siguientes capítulos se entrará en detalle en cada una de estas contribuciones, explicando lasdecisiones tomadas y metodología empleada. Debido a la presencia de terminología específica a formatosde datos y sistemas aéreos no tripulados, se recomienda que el lector revise el glosario antes de proceder.track2kml-extExpansión de track2kml con soportepara formatos propios de empresastrack2kmlConversión de archivosCOURAGEOUS a KMLaag2courageousConversión de archivos detrayectoria de receptores GPSa formato COURAGEOUSformatFormato definido por nosotroscomún entre todas las empresasjson-schema-visualizerVisualización de la especificacióndel formato COURAGEOUSgpsavgObtención de coordenadas dedesplegue de sistemas C-UASformat-websiteAlojamiento de información delformato COURAGEOUS ydescargas de track2kmlLeyendaRustVueHTML5DependenciaFigura 1.1Diagrama de dependencia de los repositorios creados a lo largo del trabajo. 2Formato de datos para C-UAS de COURAGEOUSAl comienzo del proyecto COURAGEOUS, no existía ningún formato de datos común entre las empresasdel consorcio. Esta heterogeneidad inicial implicó la necesidad de procesar múltiples formatos de datosdurante las dos primeras pruebas experimentales realizadas en Grecia y Bélgica. Adicionalmente, algunasde las empresas cambiaban su formato o se unían a las pruebas durante su trascurso, dificultando la laborde análisis y detección de errores.Por ello, se decidió establecer un formato común que todas las empresas participantes debían utilizar,simplificando así las tareas de soporte, desarrollo y tratamiento de datos. La estructura de este formatosurgió naturalmente a través del desarrollo de la herramienta de conversión a KML descrita en el Capítulo3,ya que los datos a leer de los distintos sistemas se unificaban a una estructura común que luego se pasabaal conversor a KML. Esta estructura fue evolucionando hasta convertirse en el formato COURAGEOUS.2.1ContextoAunque ya existían algunos formatos relacionados con el intercambio de datos entre sistemas de defensa,tales como Link 16 (popular en la escena de los UAV) [11], ASTERIX (relacionado con la navegación aérea)[12] y SAPIENT (del mundo de la fusión sensorial) [13], ninguno de ellos estaba estandarizado en el sectorde sistemas C-UAS. Asimismo, mayoría de empresas con las que se trabajó en el proyecto usaban protocolospropietarios, por lo que establecer un protocolo común de la índole de SAPIENT no habría sido viable enel tiempo asignado debido a las implicaciones de implementarlo.Hasta la introducción del formato propuesto, la mayoría de compañías habían usado archivos CSV(Valores separados por comas, por sus siglas en inglés) o GPX [14] para representar datos de deteccionesy rastreo de drones en los ensayos. Sin embargo, ambos de estos formatos presentaban limitaciones signi-ficativas. Por ejemplo, en el caso de CSV:1.La distinción entre datos de detección y rastreo resultaba problemática: o bien se requería un archivoindependiente para cada tipo de dato, o ambos debían coexistir en un mismo archivo diferenciadosmediante una columna adicional, complicando así su interpretación y procesamiento.2.La naturaleza plana (no jerárquica) de los archivos CSV dificultaba la gestión de información condiferentes niveles de especificidad. Los datos únicos por documento, como la posición del sistema C-UAS,o aquellos comunes a un conjunto de detecciones, como el número de serie de un UAV específico, debíanalmacenarse externamente o repetirse en cada fila relevante, introduciendo redundancia y potencialesinconsistencias en los datos.En el caso de los archivos GPX, aunque estos presentan un formato XML estandarizado para el intercambiode datos geoespaciales, también presentaban sus problemas; Por ejemplo, estos no están preparados para elcaso de sistemas C-UAS que no obtengan posiciones GPS, tales como aquellos que funcionan por cámarasvisuales o termográficas y no obtienen distancia al sujeto.Dadas estas circunstancias, se optó por crear un formato sencillo, de fácil escritura, con la visión a largoplazo no de estandarizarse en el sector, sino de facilitar la colaboración entre las empresas participantes enel proyecto COURAGEOUS. La creación de un formato propio también permitía decidir todos sus detalles,como por ejemplo forzar la escritura de la posición del C-UAS en todos los archivos creados.Para facilitar la adopción del formato, se creó una guía de uso [15], disponible en una página web [10]creada para hospedar las distintas versiones de este. La guía contiene un resumen de los conceptos básicosdel formato, ejemplos, una sección destinada a aquellas empresas que sean capaces de interceptar la señalde los UAS, y un capítulo con un pequeño tutorial de la herramienta de conversión a KML descrita en elCapítulo3.17 2.3. Planteamiento y Desarrollo 52.2DescripciónEl formato usa diferentes estructuras para organizar y distinguir datos:•Un record representa toda la información relacionada con una entidad física en un tiempo dado y un puntodel espacio, si aplica. Estos contienen metadatos como su la identificación del objeto (texto arbitrario, porejemplo un identificador o un número de modelo) o la clasificación de este, que varía entre UAV, GroundControl Station (GCS), otro o desconocido.•Los record sets son conjuntos de records referidos a un único UAS (Combinación de GCS + UAV). Ademásde una lista de records, también contienen un ID de UAS (uas_id) único en el documento, y opcionalmenteun nombre (name) arbitrario. Estos campos son usados para identificar y distinguir los record sets dentrodel archivo.Existen dos listas de record sets: Una de detección, que consta de datos sueltos sin correlacionar, y otra derastreo (tracking), que indica datos que han sido correlacionados y que el C-UAS puede identificar con latrayectoria de un único elemento.El formato no sólo incluye records, sino también propiedades globales al documento tales como la versióndel formato (version) o la posición donde se ha establecido el sistema C-UAS (static_cuas_location).2.3Planteamiento y DesarrolloLa experiencia de trabajo con las empresas participantes en las pruebas de Grecia proporcionó unacomprensión clara de las necesidades y características que debía incorporar el nuevo formato común. Parael nuevo formato, se decidió que se basara en uno ya existente para poder aprovechar todo su entorno,tales como librerías de lectura/escritura, herramientas de validación y visualización o resaltado de sintaxisy soporte en editores de texto.Tras contemplar múltiples opciones, se escogió JSON como base del formato por tres razones principales:su naturaleza estructurada, que permite organizar la información en múltiples niveles jerárquicos; sucarácter autodescriptivo, que facilita la interpretación de los datos sin documentación adicional; y su ampliapopularidad, con soporte nativo o a través de librerías en lenguajes como C#, C++, Javascript o Java.Para especificar el formato, se decidió usar un schema JSON [16]. Este consiste en un archivo tambiénJSON que indica la estructura del documento, los miembros que son requeridos, sus tipos y documentacióncomo descripciones y ejemplos de valores posibles. Al usar este estándar, era posible aplicar herramientasexistentes para visualizar o verificar documentos que debían seguir la plantilla.Dicho esto, la creación de un schema a mano no es trivial, ya que consta de una complejidad que implicaque no sea fácilmente legible ni editable por una persona. Por ello, se decidió hacer uso de un generador deschemas denominado schemars [17] que permitía especificar el formato a través de estructuras y enume-raciones escritas en Rust (Código 2.1). De esta forma, se proporcionaría una Application ProgrammingInterface (API) del formato que podría usarse para otros proyectos como el descrito en el Capítulo3.Este enfoque demostró ser extremadamente eficiente: a partir de solo 268 líneas de código Rust se generaautomáticamente un schema JSON de más de 500 líneas. Esta metodología ofreció dos ventajas adicionalescruciales: mantener perfectamente sincronizadas la especificación del formato y la interfaz de programacióndisponible, y permitir la reutilización directa de la documentación de la API dentro del propio schema.El repositorio del formato se encuentra en [18]. Este contiene un sólo breve archivo de código para definirla estructura del formato, partiendo de un struct Document. Los miembros de esta estructura, así como sussubmiembros, son especificados en el schema JSON que schemars genera.La generación del schema se hace a través de un ejemplo, definido dentro de la carpeta examples. Se hizode esta manera ya que se pensó que sería la manera más sencilla de crear un binario ejecutable dentro delmismo proyecto que la librería manteniendo sus dependencias separadas. El ejecutable simplemente guardael resultado del macro schemars::schema_for!(Document) en un archivo.Se muestra un extracto del schema en el Código 2.3 y un archivo que lo sigue en el Código 2.4. 6Capítulo 2. Formato de datos para C-UAS de COURAGEOUSCódigo 2.1Ejemplo de la librería schemars aplicada en una estructura MyStruct que genera el schema de lasiguiente figura.use schemars::{schema_for, JsonSchema}; use std::fs::File; use std::io::Write; #[derive(JsonSchema)] pub struct MyStruct { /// Ejemplo de documentación de este miembro pub my_int: i32, pub my_bool: bool, pub my_string: String, } fn main() -> Result<(), Box<dyn std::error::Error>> { let schema = schema_for!(MyStruct); let mut output_file = File::create("example-schema.json")?; write!(output_file, "{}", serde_json::to_string_pretty(&schema)?)?; Ok(()) } Código 2.2Schema resultante al ejecutar el código de la figura previa (example-schema.json){ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "MyStruct", "type": "object", "properties": { "my_bool": { "type": "boolean" }, "my_int": { "description": "Ejemplo de documentación de este miembro", "type": "integer", "format": "int32" }, "my_string": { "type": "string" } }, "required": [ "my_int", "my_bool", "my_string" ] } 2.3. Planteamiento y Desarrollo 7Código 2.3Extracto del schema del formato COURAGEOUS.{ "$schema": "http://json-schema.org/draft-07/schema#", "title": "Document", "type": "object", "required": [ "detection", "static_cuas_location", "system_name", "tracks", "vendor_name", "version" ], "properties": { "static_cuas_location": { "description": "The 3D GPS location of the CUAS. Can be overriden per Record, but even if overriden this value must exist and be a valid position.", "allOf": [ { "$ref": "#/definitions/Position3d" } ] }, "system_name": { "type": "string" }, "tracks": { "description": "A list containing the tracks present in the document.\n\nTracks should be used when the CUAS has locked on a target and is actively tracking its position. Their records describe the trajectory of a specific target.", "type": "array", "items": { "$ref": "#/definitions/Track" } }, "vendor_name": { "type": "string" }, "version": { "$ref": "#/definitions/Version" } }, "definitions": { "Alarm": { "description": "An Alarm is defined as the function of a CUAS system alerting an Operator via the HMI and the generation of associated data in the UAS Activity Log, as a result of Declared UAS activity.", "type": "object", "required": [ "active", "certainty" ], "properties": { "active": { "description": "Whether the alarm function of the CUAS system is active or not.", "type": "boolean" }, "certainty": { "description": "How certain is the system of an active alarm, as a value from 0 (Least likely) to 1 (Most likely).", "type": "number", "format": "double", "maximum": 1.0, "minimum": 0.0 } } }, "Classification": { "type": "string", "enum": [ "Unknown", "UAV", "GCS", "Other" ] }, /* ... */ } } 8Capítulo 2. Formato de datos para C-UAS de COURAGEOUSCódigo 2.4Archivo COURAGEOUS de ejemplo.{ "detection": [ { "records": [ { "alarm": { "active": true, "certainty": 1 }, "classification": "Unknown", "location": { "$type": "BearingElevation", "bearing": 43.563024999999996, "elevation": 2.211875 }, "record_number": 4, "time": 1696255068480 }, // ... ] } ], "static_cuas_location": { "height_amsl": 11.4, "lat": 51.156888, "lon": 2.738243 }, "tracks": [ { "name": "Track name", "records": [ { "classification": "UAV", "identification": "UAV description", "alarm": { "active": false, "certainty": 0.55 }, "location": { "$type": "Position3d", "height_amsl": 47.15314324164956, "lat": 51.158929232973726, "lon": 2.7414165702140973 }, "record_number": 0, "time": 1696421411207, "velocity": { "east": -2.14297, "north": 1.69235, "up": -0.86349 } }, // ... ], "uas_id": 1 } ], "vendor_name": "Company Name", "system_name": "CUAS system name", "version": "0.4.1" } 2.4. Visualizador 92.4VisualizadorUna de las principales necesidades a la hora de trabajar con un formato es poder visualizar su estructura deforma clara y concisa. En su momento existían múltiples herramientas de visualización de schemas JSONonline, tales como:•https://schemavisualizer.org/, que presenta la información del schema en forma de grafo. Aunque puedeser útil para formatos simples, en formatos más complejos como COURAGEOUS, la información se vuelvedifícil de seguir.•https://www.schemavisualizer.dev/, que al principio parece presentar una interfaz más completa, sinembargo requiere una cuenta para usarse, realmente visualiza archivos JSON y no los descritos porschemas y no permite la visualización de archivos grandes de forma gratuita.Al principio no se encontró ninguna que se ajustase a nuestras necesidades. Por tanto, se decidió partir deun proyecto existente, json-schema-visualizer [19], que presentaba una interfaz sencilla y tenía la mayorparte de las funcionalidades necesitadas. Se realizaron algunos cambios, como permitir cargar archivos deschema remotos a partir de un URL, esconder información innecesaria, y mejorar el soporte para objetoscon diferentes variantes, como era el caso de los records del formato. El código fuente de la versión derivadasigue disponible en [20].El visualizador, como se muestra en el Figura 2.1, facilita la comprensión de la estructura del formatoCOURAGEOUS para aquellos que no estén familiarizados con él. Sus funcionalidades incluyen:•Expansión y contracción de los objetos del schema.•Distinción entre elementos requeridos y opcionales.•Visualización del tipo de cada elemento y cualquier restricción asociada (por ejemplo, valores mínimos omáximos).•Carga de schemas desde la web mediante editor de texto, una URL externa o texto codificado en la propiaURL del visualizador.•Configuración del nivel de profundidad de expansión de objetos por defecto a través de la URL delvisualizador.El visualizador se encuentra en la página web del formato, descrita a continuación. Para cada versión deeste se muestra un botón con la etiqueta Reference para abrir el schema correspondiente en el visualizador.Figura 2.1json-schema-visualizer con el schema del formato COURAGEOUS 0.4.1. 10Capítulo 2. Formato de datos para C-UAS de COURAGEOUS2.5Página webPara facilitar a las empresas el acceso a la última versión del formato COURAGEOUS y sus actualizaciones,se creó una página web. Esta página permite ver y descargar la versión del schema más reciente, así comoconsultar los cambios realizados en cada una de las versiones publicadas. Posteriormente, se añadieron otrosútiles como un visualizador gráfico del schema, una guía de uso del formato, descargas de la herramientadescrita en el Capítulo3, etcétera.La página web se encuentra alojada en el servidor del Grupo de Robótica, Visión y Control del departa-mento de Ingeniería de Sistemas y Automática, y aún se mantiene pública [10].2.5.1DescripciónLa página web (mostrada en el Figura 2.2) consta de tres secciones: Una breve introducción, una secciónpara el formato con una lista de versiones y otra para la herramienta de conversión del Capítulo3 tambiéncon otra lista de versiones.Cada una de las versiones del formato consta de un botón de descarga, otro que abre el visualizador(Sección2.4) con el schema seleccionado y otro de información que expande un changelog e indica lasversiones de track2kml con soporte para él, tal como se puede observar en el Figura 2.4.2.5.2DesarrolloPara crear la página web, se recurrieron a las tecnologías más simples disponibles: HyperText MarkupLanguage (HTML), Cascading Style Sheets (CSS) y JavaScript «vanilla», sin un framework que lo englobara.La página se compone de una serie de elementos estáticos y dos listas de versiones que se rellenan coninformación obtenida dinámicamente a través de peticiones a archivos de listado que se encuentran en elmismo servidor que hospeda la página web. Estos archivos contienen metadatos de las versiones publicadas,tales como su número, fecha de publicación o si son borradores (Código 2.5). A cada archivo descargabletambién le acompaña un historial de cambios escrito en HTML, que contiene los cambios realizados encada versión (Figura 2.3). Estos archivos son leídos e insertados directamente en la página al expandir lainformación de la versión.Código 2.5Metadatos sobre track2kml guardados en el archivo list.json.[ { "name": "v2.4.0", "date": "28/2/2024", "draft": false }, { "name": "v2.3.1", "date": "30/11/2023", "draft": false }, { "name": "v2.3.0", "date": "23/10/2023", "draft": false }, // ... ] 2.5. Página web 11Figura 2.2Captura de la página web del formato y track2kml. 12Capítulo 2. Formato de datos para C-UAS de COURAGEOUSFigura 2.3Contenidos de la carpeta track2kml de la página web.Figura 2.4Ejemplo del changelog mostrado en la página web de una versión del formato. 3.1. Interfaz 19Tabla 3.1Tipos de geometrías de relevancia en la visualización de datos C-UAS.ArcoCuadranteRumboRumbo + Elevación Esquema NESW Definido por Ángulo mínimo y má-ximo horario desde elnorte verdaderoNorte, sur, este u oesteÁngulo horario desdeel norte verdaderoÁngulo horario desdeel norte verdadero yángulo sobre el hori-zonte Ejemplo Sistemas de RF o acús-ticosSistemas de RF o acús-ticos por lóbulosSistemas de RF o acús-ticosSistemas con cámarasvisuales o termográfi-cas Geometría usada en KML Polígono con la for-ma de una sección decírculoPolígono con la for-ma de una sección decírculoSegmento de línea pro-yectada sobre el te-rrenoSegmento de línea pro-yectada en el terreno,de longitud configura-ble en la interfazRumbo + Elevación + DistanciaPunto 2DPunto 3D EsquemaDefinido por Ángulo horario desde el norteverdadero, ángulo sobre el ho-rizonte y distancia desde el C-UASLatitud y longitud sobre el elip-soide definido por WGS84Latitud y longitud sobre elelipsoide definido por WGS84,y elevación sobre el geoideEGM96 Ejemplo Sistemas de radarSistemas de intercepciónSistemas radar o de intercep-ción Geometría usada en KML Segmento de línea 3D, de longi-tud configurable en la interfazPunto proyectado en el terrenopara puntos sueltos o un trackde Google Earth en el caso deque sea un trackPunto 3D para puntos sueltos oun track de Google Earth en elcaso de que sea un track 20Capítulo 3. Desarrollo de la herramienta software de visualización3.2DesarrolloAl decidir el lenguaje y herramientas que se usarían en este proyecto, se tuvo especial cuidado en seleccionarun entorno que fuera fácilmente extensible, modular y adecuado para su aplicación en el máximo númeroposible de proyectos relacionados (tales como documentación, posible interfaz gráfica, etc). Por ello, seutilizó el lenguaje de programación multidisciplinario Rust [22], que previamente ya había sido aplicado enotras asignaturas de la carrera y proyectos tales como [23].Para coordinar el trabajo y mantener un historial de cambios se creó un repositorio de Git, hospedadoen GitHub, que finalmente se acabó moviendo a una organización específica para COURAGEOUS [24]. Serecurrió a GitHub debido a la familiaridad con su interfaz y la posibilidad de establecer integración continua(CI) para automatizar la ejecución de pruebas al integrar nuevos cambios.Aunque inicialmente se realizó todo el trabajo dentro de un repositorio privado, esta decisión conllevabael problema de que el código no fuera accessible por las empresas participantes ni cualquier ente externointeresado. Aunque nos habría gustado mantener la totalidad del código visible y accessible, este conteníainformación confidencial sobre las empresas participantes en las pruebas en forma de archivos de prueba ydetalles sobre la información que recogen.Finalmente, se decidió dividir el repositorio en una parte pública (track2kml) y una privada (track2kml--ext).: track2kml-ext y track2kml. track2kml-ext es privado y contiene el código específico de empresas,mientras que el repositorio de track2kml contiene el código genérico de conversión a KML. De esta forma,se pudo mantener la mayor parte del código de track2kml público y abierto, dejando el código relacionadocon los formatos de empresa como confidencial. La organización tomada se detalla en la Figura 3.3 y elrepositorio público se encuentra en [25].3.3Funcionamiento internoEl programa internamente se divide en tres partes: Una librería de conversión a KML, una pequeña libreríagenérica a los formatos soportados que genera la interfaz por línea de comandos y un ejecutable que usaestas librerías y sólo admite el formato COURAGEOUS. En el Figura 3.4 se muestra un esquema de estoscomponentes y la relación entre ellos, y en el Figura 3.5 el procesamiento realizado por cada una de laspartes.track2kml_extended_cliCLI con soporte para for-matos de empresa ademásde formato COURAGEO-UStrack2kml (ejecutable)CLI con sólo soporte paraformato COURAGEOUStrack2kml-cliLibrería común que con-tiene la lógica del CLItrack2kml (librería)Librería de conversión deficheros COURAGEOUS aKMLtrack-formatsLibrería con parsers de losformatos de empresacourageous-formatLibrería que define el for-mato COURAGEOUS yprovee una interfaz deRust para trabajar con élLeyendaEjecutableLibrería (crate)En repositorio de códi-go abiertoEn repositorio de códi-go cerradoDependenciaFigura 3.3Diagrama de dependencia de los componentes de track2kml. 3.3. Funcionamiento interno 21Esta separación en ejecutable y librería de CLI puede aparentar compleja e innecesaria, aunque se debetener en cuenta que al comenzar el desarrollo de track2kml no existía el formato COURAGEOUS. Por lotanto, se debía trabajar con los formatos que las empresas proporcionaran y permitir que la aplicaciónpudiera ser compilada con soporte para más de un formato.El ejecutable y la librería de conversión de KML son los elementos más importantes del conjunto, porlo que mantienen cada uno un archivo de historial de cambios denominado CHANGELOG.md que se actualizacada vez que hay algún cambio notable o de interfaz. En el caso de la librería de conversión de KML, sedetallan los cambios de la API y se usa SemVer [26] para versionar la librería, teniendo cuidado con posiblescambios que pueden romper la interfaz de programación.3.3.1Librería de conversión (track2kml)Esta librería fue creada para separar la labor de crear la interfaz de usuario y hacer la conversión a KML.Esta separación conlleva además la posibilidad de usar la conversión a KML en otros proyectos, lo cualpodría haber sido útil si hubiéramos finalmente decidido hacer una versión gráfica de track2kml, o podríaser útil en el futuro para otro proyecto.La principal función de esta librería (llamada también track2kml) es write_as_kml, que tiene la formamostrada en el Código 3.2. Esta función es la encargada de convertir los datos de entrada a KML, escribiendoel resultado al elemento grabable dado. Es por ello que esta librería es la más importante de todo el proyecto,quedando el resto como meras envolturas para su uso.•Database es un alias al contenido estructurado del formato COURAGEOUS.•WriteAsKmlOptions se trata de una estructura que contiene las opciones de exportación a KML, talescomo si deshabilitar o no los iconos de tracks.Código 3.2Declaración de track2kml::write_as_kml.pub fn write_as_kml( database: Database, writer: impl std::io::Write, options: WriteAsKmlOptions, ) -> anyhow::Result<()> { ... } track2kml (ejecutable)CLI con sólo sopor-te para el formatoCOURAGEOUStrack2kml-cliLibrería común, genéri-ca a formatos soportados,que contiene la lógica delCLItrack2kml (librería)Librería de conversión deficheros COURAGEOUS aKMLcourageous-formatLibrería que define el for-mato COURAGEOUS yprovee una interfaz deRust para trabajar con él.Descrito en el Capítulo2.LeyendaEjecutableLibrería (crate)DependenciaFigura 3.4Diagrama de dependencia de los componentes de track2kml.track2kml-cli::FormatParser::parse_file track2kml::write_as_kml Datos en formato de empresa 1Datos en formato de empresa 2Datos en formato de empresa 3…Datos en formato COURAGEOUSDatos en formato COURAGEOUSDatos KMLFigura 3.5Diagrama de procesamiento realizado por track2kml. 22Capítulo 3. Desarrollo de la herramienta software de visualización•writer es un objeto que implementa la interfaz de escritura de Rust, como un búfer en memoria o unarchivo del sistema, y es el destino de la salida de la conversión.En su momento se comprobó la existencia de una librería de KML que se pudiese usar para facilitar latarea, aunque no se encontró ninguna que se ajustase a nuestras necesidades. Sin embargo, esto no fuegran problema ya que KML está basado en eXtensible Markup Language (XML), que se trata de un formatoautodescriptivo bastante extendido que se usa por ejemplo en HTML, Really Simple Syndication (RSS) ymuchos archivos de configuración. Por ello, se decidió implementar la conversión usando una librería deXML genérica.Para realizar esta transformación se partió de la propia documentación de Google sobre el formato [27],[28], [29]. La representación de los datos de detección usa geometrías tales como Point para posicionesde UAS dadas por latitud-longitud-altura, latitud-longitud o rango-dirección-elevación, LineString pararepresentar rayos (datos de sólo dirección-elevación, Figura 3.7) y Polygon para representar arcos (ángulomínimo y máximo de detección, Figura 3.6). Los tracks además se contienen individualmente dentro de unelemento también llamado track que se comporta como un LineString pero permite la visualización deeste a lo largo del tiempo de la prueba usando un deslizador.Figura 3.6Ejemplo de representación de un arco en KML usando Polygon.Figura 3.7Ejemplo de representación de un rayo en KML usando LineString. 3.3. Funcionamiento interno 233.3.2Librería de CLI (track2kml-cli)Al comenzar el desarrollo de track2kml, no existía el formato COURAGEOUS, y en su lugar se debíanimportar los datos de cada empresa con formatos arbitrarios. Además, más tarde surgió la idea de propor-cionar una versión de track2kml compatible únicamente con los formatos de cada empresa C-UAS. Para ello,era necesario compilar diferentes versiones de track2kml, cada una con un soporte de formatos distinto.Para simplificar este proceso lo máximo posible, se creó una librería, llamada track2kml-cli, que exponela misma lógica de CLI y conversión a KML de forma genérica a los formatos soportados. De esta manerase pudo mantener una interfaz de usuario consistente entre distintas versiones del programa y se simplificóla labor de desarrollarlas, únicamente teniendo que especificar los parsers de formato a usar en cada una.La librería de CLI proporciona una interfaz sencilla para crear y configurar cualquier versión de la interfazde track2kml. Expone principalmente una función, run, que es la encargada de procesar los argumentos delínea de comandos y de llamar a la librería de conversión de KML. Se muestra en el Código 3.3.Código 3.3Función principal run de la librería track2kml-cli.pub fn run( formats: &HashMap<&'static str, Format>, allow_to_courageous_option: bool ) -> ExitCode { ... } La función sólo presenta dos parámetros: formats, que indica los formatos admitidos (identificados cadauno por un nombre) y allow_to_courageous_option, que al especificarse añade al CLI una opción -- to_courageous que cambia la exportación al formato COURAGEOUS en vez de a KML.Esta exportación a un archivo COURAGEOUS resultó gratuita de implementar gracias al funcionamientodel conversor. Internamente, la librería de track2kml-cli requiere que todos los archivos a leer tengan unaestructura común, para que la conversión a KML pueda realizarse usando un único método (ya mencionadoantes en la librería de conversión, write_as_kml). Esta estructura común no es nada más y nada menos quela estructura del documento definido por el formato COURAGEOUS.¹ Por ello, la exportación a COURA-GEOUS simplemente consiste en pasar esta representación común en memoria a un archivo.Por tanto, para que un lector de formato sea compatible con la librería de CLI sólo necesita definir lainterfaz mostrada en el Código 3.4.Código 3.4Interfaz que debe definir cualquier parser de un formato para que sea compatible con track2kml.pub trait FormatParser { fn parse_file(&mut self, file: &mut BufReader<File>) -> Result<Document, anyhow::Error>; } Esta interfaz consiste en leer un archivo (file) y a partir de él obtener un archivo con el formato COURA-GEOUS (Document).Para identificar cada formato para el que la librería tiene soporte, se especifica su nombre (principalmentepara mostrarlo en mensajes de error), extensión de archivo (para automáticamente determinar qué archivosdebería cargar) y un objeto que determine el FormatParser a usar a partir de la información pasada porCLI, tal como se muestra en el Código 3.5.¹De hecho, fue de esta manera como surgió este formato: Al leer archivos de distintas empresas necesitábamos representarlasen memoria de una forma común para que se pudiese usar el mismo método de exportación a KML. 24Capítulo 3. Desarrollo de la herramienta software de visualizaciónCódigo 3.5Interfaz que debe presentar un formato para que pueda leerse desde el CLI de track2kml.pub struct Format { initializer: Box<dyn CliFormatInitializer>, file_ext: &'static OsStr, name: &'static str, } /// Describes any object that can initialize a format parser via @cli parameters /// (The clap command and the argument matches). Object-safe by design. pub trait CliFormatInitializer { fn init_from_cli( &self, cmd: &Command, args: &ArgMatches, ) -> Result<Box<dyn FormatParser>, anyhow::Error>; } 3.3.3Ejecutable (track2kml)El ejecutable, también denominado track2kml, usa la librería clap [30] para presentar una interfaz de usuariocompleta y colorida. Si existe algún error en la conversión o lectura de los datos, se presenta un error lomás informativo posible al usuario (Código 3.6).Código 3.6Algunos de los errores que se puede presentar track2kml al usuario.[aleok@aleok-laptop testing]$ track2kml nonexistent.json Error: No such file or directory (os error 2) [aleok@aleok-laptop testing]$ track2kml empty_json.json Error: Could not load input file. Tried loading it as a COURAGEOUS (v0.4) file, but got the following error: missing field `static_cuas_location` at line 1 column 2 [aleok@aleok-laptop testing]$ track2kml eof.json Error: Could not load input file. Tried loading it as a COURAGEOUS (v0.4) file, but got the following error: EOF while parsing an object at line 88 column 11 [aleok@aleok-laptop testing]$ track2kml invalid_classification.json Error: Could not load input file. Tried loading it as a COURAGEOUS (v0.4) file, but got the following error: unknown variant `Bird`, expected one of `Unknown`, `UAV`, `GCS`, `Other` at line 13 column 44 3.4Proceso de compilaciónPara cada versión del software, se debían compilar diferentes variaciones de este: Unas para las compañíascon soporte sólo para su formato, otras para uso interno que tuvieran soporte para todos los formatosimplementados y otras con sólo el formato COURAGEOUS para subirlas a la página web. Además, paramaximizar la compatibilidad con sistemas, debían ser compiladas para Windows y Linux.Para ello, se creó un pequeño script de Bash que automatiza el proceso de lanzamiento de versionesnuevas. En el Código 3.7 se muestra un extracto de este script con la compilación para una de las empresasde radar C-UAS. 3.5. Conclusiones 25Código 3.7Extracto de generate_release_extract.sh, que automatiza el proceso de compilación detrack2kml.rm -r release/ART mkdir release mkdir release/ART mkdir release/ART/examples cp track-formats/test_data/ART*.log release/ART/examples/ cp cli/README.md release/ART cargo build --target x86_64-unknown-linux-musl --release --features art && mv target/ x86_64-unknown-linux-musl/release/track2kml release/ART/track2kml cargo build --release --target x86_64-pc-windows-gnu --features art && mv target/ x86_64-pc-windows-gnu/release/track2kml.exe release/ART/track2kml.exe release/ART/track2kml release/ART/examples/ART_detection_test.log --origin 4.3341194,51.4507167,15 version=$(release/COURAGEOUS/track2kml --version | grep -oE "[^ ]+$") zip -ur "release/ART-${version}.zip" release/ART El script guarda todos los resultados de compilación como pequeños paquetes comprimidos con un nombredescriptivo que incluye a quién va dirigido y la versión del software, dinámicamente obtenida a partirdel ejecutable compilado sólo con soporte para COURAGEOUS. Estos comprimidos incluyen track2kmlcompilado para Linux y Windows y el resultado de conversión de algunos archivos de ejemplo (en esteejemplo sólo 1).Para seleccionar los formatos a incluir, se han usado features (banderas de compilación) definidas en elarchivo de proyecto (Cargo.toml), que habilitan o deshabilitan los formatos correspondientes a tiempo decompilación. En el Código 3.7, se muestra cómo se activa el feature art para habilitar el parser correspon-diente a esta compañía en la compilación de track2kml.3.5ConclusionesGracias a este programa fue posible detectar inconsistencias con los datos exportados de las empresasrápidamente, tales como fallos de la referencia de altitud usada y de sincronización temporal.La idea de separar el repositorio en dos y seguir manteniendo soporte para una versión de la aplicacióncapaz de convertir archivos que no fueran del formato COURAGEOUS tuvo su mérito, pero sin embargofue desaprovechada por las empresas, por lo que el repositorio privado se dejó de mantener actualizadodespués de la versión 2.3.1, y a partir de ese momento sólo se mantuvo soporte para el repositorio públicoque únicamente admitía formato COURAGEOUS.Debido a este poco interés por parte de las empresas, se decidió también simplificar la metodología detrack2kml-cli, eliminando el soporte para múltiples formatos. No obstante, estos cambios nunca fueronpublicados en la página web del formato, aunque sí usados en las últimas pruebas en ATLAS (Jaén).Estos cambios simplificaron el trabajo al tener sólo un repositorio, lo que facilitó los cambios puntuales atrack2kml y ahorró tiempo para otras tareas.Esta versión, aparte de tener estas simplificaciones, también fue desarrollada durante las pruebas paraañadir funcionalidad que hacía falta en el momento, como la posibilidad de especificar a dónde guardar elarchivo de salida y no incluir la posición del C-UAS en el KML.En cualquier caso, track2kml fue una herramienta de gran utilidad en las pruebas y estable externamenteentre versiones gracias al uso de Git, mantenimiento de historial de cambios, y minucioso cuidado con loscambios realizados. 4Tratamiento de datos de loggers GPSAunque el propósito de este Trabajo de Fin de Grado nunca consistió en analizar los datos proporcio-nados por las empresas, seguía siendo fundamental mantener la integridad de estos y proveer unareferencia válida con la que compararlos. Siempre se tuvo disponible la telemetría de los UAVs usados en laspruebas, pero al usar múltiples modelos distintos, era posible que estos tuvieran características diferentes oque algunos de ellos no precisaran de telemetría y fuesen controlados manualmente. Por ello, era necesarioproveer una referencia externa, fiable y consistente. Para ello se escogieron GPS loggers de la empresaalemana Aaronia AG, con 1.8 metros de precisión horizontal y 20 cm de precisión vertical según su hojade datos [31], que son los mismos que usa la OTAN en sus pruebas de C-UAS (Technical InteroperabilityExercise, [2]).Los datos obtenidos de los GPS debían ser procesados y convertidos al formato común, es decir, el formatoCOURAGEOUS, para su posterior comparación con datos de empresas. En este capítulo se detallará estetratamiento de datos, desde su obtención hasta su conversión al formato COURAGEOUS.4.1GeodesiaAntes de tratar con datos geoposicionales, es importante aclarar qué significan y respecto a qué referenciasy sistemas vienen dados para minimizar las imprecisiones al representarlos.Reproducir una ubicación en la Tierra no es nada sencillo. Al estar esta continuamente girando sobre símisma y a su vez alrededor del sol, sin mencionar el movimiento propio de la vía láctea y del universo, esimperativo usar un sistema relativo y no absoluto. Por ello, los sistemas de ubicación son geocéntricos, esdecir, respecto al centro de la Tierra.Los receptores GPS como el de Aaronia usan señales enviadas por satélites estadounidenses (En contrastecon p. ej. satélites europeos usados por GLONASS) para determinar su posición respecto a estos. Estasseñales incluyen valores de tiempo altamente precisos e información precisa de la órbita que cursa, tambiénFigura 4.1Visualización de la ondulación del geoide EGM-96 representada sobre la Tierra [32]39 4.1. Geodesia 27denominada su efemérides. Estos valores pueden ser usados para ubicar el satélite respecto al centro demasa de la Tierra. Por otra parte, es también posible estimar la distancia a la que el dispositivo se encuentraal satélite calculando el tiempo que tarda en llegar la luz desde la órbita a nuestro planeta. Ambos datos sonusados para trilaterar (o multilaterar) la ubicación del dispositivo GPS. Las coordenadas de la efeméridesusan el sistema geodésico de coordenadas geográficas WGS-84, que es geocéntrico (centrado y fijo en elcentro de la Tierra) y cartesiano (Tres ejes: X, Y, Z), por lo que las coordenadas del propio receptor usan elmismo sistema de referencia [33]; el mismo que se muestra en la Figura 4.2.Figura 4.2Sistema de coordenadas geocéntricas definido por WGS-84. [34]Estas coordenadas cartesianas pueden transformarse a un sistema geodésico de latitud, longitud y alturaelipsoidal, usando el elipsoide WGS-84 para aproximar la forma de la Tierra [35]. Mientras que latitud ylongitud resultan inmediatamente interpretables para ubicaciones terrestres, la altura elipsoidal presentalimitaciones prácticas. Para aplicaciones cotidianas y científicas, resulta más relevante expresar la alturarespecto al nivel medio del mar, lo que requiere una transformación adicional que compense la diferenciaentre el elipsoide de referencia y el nivel medio del mar.Este nivel medio puede definirse mediante un modelo gravitatorio equipotencial llamado geoide. Estegeoide normalmente es expresado como una serie de alturas muestreadas sobre toda la superficie terrestrerespecto a un elipsoide de referencia (p.ej. WGS84), tal como se muestra en la Figura 4.1. La diferencia entreel elipsoide y el geoide se muestra en la Figura 4.3.Al ser el geoide una corrección aplicada a los datos respecto al elipsoide, este es independiente de lossatélites y la comunicación con estos, siendo por lo tanto programados en los receptores y no los satélites.En algunos modelos, es incluso posible reprogramarlos con modelos más precisos. Sin embargo, en el casodel receptor de Aaronia, el geoide no es especificado y se trata como un detalle de implementación.Figura 4.3La Tierra y dos posibles representaciones, un elipsoide y un geoide [36] 28Capítulo 4. Tratamiento de datos de loggers GPSAunque es cierto que en el logger de Aaronia no se especifica el geoide usado, en el fichero resultante decada grabación se incluye la distancia entre el geoide y el elipsoide para todos los puntos de medida. Por ello,si se quisiera la máxima exactitud posible al comparar los valores del receptor a las coordenadas proporcio-nadas por los C-UAS, podrían compararse las posiciones respecto al elipsoide WGS-84. No obstante, porsimplicidad y motivos de coordinación, finalmente se decidió simplemente comparar las posiciones respectoal geoide y asumir que no habría discrepancias significantes entre los modelos usados por los C-UAS y elde Aaronia. Se podría objetar que de esta forma se pierde precisión, pero si se tiene en cuenta la propiaimprecisión de la constelación GPS o del receptor, la diferencia de alturas de los modelos de geoide pierderelevancia.4.2Especificaciones de los loggers GPS usadosPara asegurar que nuestra referencia (El GPS de Aaronia) fuera fiable y consistente en las pruebas y nose malinterpretaran los datos obtenidos, era necesaria la mayor cantidad de información posible sobre eldispositivo. Para ello, se buscó toda la información disponible en Internet, se contactó con el soporte deAaronia e incluso se abrió y analizó uno de los GPS para comprobar que las especificaciones dadas porAaronia coincidían con las de los módulos y chips internos. Gracias a esto se pudo obtener informaciónmás detallada sobre los sensores internos, el módulo GPS usado y el procesamiento que realiza a los datosproporcionados por el módulo. A continuación se muestran los datos obtenidos.4.2.1Funcionamiento externoEl logger GPS de Aaronia AAG es un dispositivo que permite grabar la información de posición y otrossensores en una tarjeta microSD. Este consta de un puerto USB que permite cargar su batería y opcional-mente conectarlo a un ordenador para usarlo a tiempo real (streaming) a través de un software cerradoproporcionado por la empresa, mostrado en la Figura 4.4. Independientemente del método usado, el dispo-sitivo graba a la tarjeta SD o envía la información vía USB usando el formato especificado por el estándarNMEA 0183, aunque esta información puede convertirse usando el software dado a un archivo CSV quepuede importarse en programas de hojas de cálculo como Microsoft Excel.Figura 4.4Captura de pantalla del software de Aaronia para visualización y exportación de archivosgrabados con sus loggers. 4.3. Software creado con esta información 35El histograma simplemente divide el espacio de valores por cada eje (obtenido a través de la media ydesviación típica multiplicado por un número arbitrario) en sectores y cuenta el número de valores porsector.4.3.2Conversión a formato COURAGEOUS (aag2courageous)El software de Aaronia incluye una herramienta para convertir los archivos raw que graba el receptor GPSdirectamente a KML, tal como se muestra en la Figura 4.8. Sin embargo, su uso no era susceptible a automa-tización y no permitía mucho control sobre la salida. Además, exportarla en el formato COURAGEOUSpermitiría que los datos fueran directamente comparables con los de las empresas participantes.Figura 4.8Diálogo de exportación a KML parte del software de Aaronia.Por estas razones, se desarrolló una pequeña herramienta CLI de conversión denominada aag2courageous[45] que, como dice su nombre, es capaz de convertir estos archivos directamente a COURAGEOUS (y porlo tanto pueden ser posteriormente transformados a KML usando track2kml). Se muestra su interfaz en elCódigo 4.5.Su funcionamiento es relativamente sencillo: Lee el archivo de entrada de línea a línea, empareja lassentencias RMC y GGA, y extrae de cada par un record de un sólo track.Código 4.5Listado de ayuda de la última versión disponible de aag2courageous.[aleok@aleok-laptop aag2courageous]$ aag2courageous --help aag2courageous 0.2.2 - Alejandro Perea ([email protected]) Commandline application to convert Aaronia GPS log files to COURAGEOUS files Usage: aag2courageous [OPTIONS] <INPUT_PATH> <STATIC_CUAS_LOCATION> Arguments: <INPUT_PATH> Path to the file to convert <STATIC_CUAS_LOCATION> The location of the C-UAS surveilling the UAS whose position is being logged Options: -o <OUTPUT_PATH> Path of the resulting file. [default: {input_path}.json] --prettyprint Pretty-print the resulting JSON --system-name <SYSTEM_NAME> The system name specified in the resulting COURAGEOUS file [default: Unknown] --vendor-name <VENDOR_NAME> The vendor name specified in the resulting COURAGEOUS file [default: Unknown] -h, --help Print help -V, --version Print version 36Capítulo 4. Tratamiento de datos de loggers GPS4.4ConclusiónLa información interna recolectada sobre los receptores y funcionamiento del software de Aaronia fue útilpara determinar que usar el software cerrado no habría sido apropiado, y nos proporcionó los medios paraleer y analizar la información NMEA nosotros mismos.Estos datos fueron usados para obtener las trayectorias de los UAV de las pruebas y determinar la posiciónfija de cada sistema C-UAS. Utilizar los loggers de Aaronia permitió obtener la trayectoria de cada UAVutilizado en las pruebas de manera consistente. 5Pruebas de campo con sistemas C-UAS en el centroexperimental de vuelo ATLASUno de los ensayos con sistemas C-UAS de empresas que se hicieron para COURAGEOUS fue realizadaen el Centro de Vuelo ATLAS, Jaén, desde el 22 al 26 de Abril de 2024. En este evento de una semana sepudo validar todo el trabajo desarrollado previamente, desde track2kml (Capítulo3) y el formato COURA-GEOUS (Capítulo2) a scripts más pequeños como gpsavg (Sección4.3.1) y aag2courageous (Sección4.3.2).5.1ObjetivoLas pruebas de campo tenían como objetivo mejorar la metodología de ensayo propuesta por el proyectoCOURAGEOUS, que trata de comprobar la validez de las especificaciones y características otorgadas porlos comerciantes de los sistemas C-UAS usando escenarios de prueba estandarizados [1]. Estos escenarios,basados en situaciones de riesgo como drones traficando contrabando a prisiones o perturbando el despeguey aterrizaje de aviones (Figura 5.1), especifican características como la luminosidad del ambiente, la meteo-rología, el entorno (rural, urbano, …), las dimensiones del UAV, etcétera.A través de pruebas de campo como la realizada en el centro de ATLAS es posible generar métricas apartir de los datos de C-UAS e información presentada en el Human Machine Interface (HMI), obteniendoasí puntuaciones comparables de sistema a sistema. [1] (Figura 5.2)La estandarización de estos escenarios es fundamental para poder comparar los resultados de maneraobjetiva; las pruebas en ATLAS constituyeron un paso más hacia este objetivo.Figura 5.1Situaciones de riesgo en las que se basan los escenarios estándar del proyecto COURAGEOUS. [1]51 5.2. Organización39Figura 5.2Obtención de puntuaciones para clasificación de sistemas C-UAS usando la metodología presen-tada por COURAGEOUS. [1]5.2OrganizaciónCada jornada comenzaba con un briefing en la nave principal donde se presentaba la agenda del día (Figura5.3), los planes de vuelo y otras indicaciones o recordatorios. El evento se organizó con diversos grupos detrabajo, cada uno con funciones específicas:•COURAGEOUS End Users: Principalmente miembros de la Policía Nacional y Guardia Civil, son losencargados de evaluar los sistemas C-UAS. Documentan sus observaciones mediante informes estanda-rizados (Figura 5.6, Figura 5.7), valorando las capacidades y limitaciones de cada sistema y HMI.•Compañías C-UAS: Responsables de la operación de sus sistemas, grabación de datos para el servidorNAS compartido y demostración de sus interfaces a los usuarios finales.•Red Team: Formado mayoritariamente por miembros de GRVC, se encargaba del pilotaje y manteni-miento de los UAVs utilizados en las pruebas.•WAT (Universidad Tecnológica de Varsovia, https://eng.pw.edu.pl/): Socios del proyecto responsables degrabar datos meteorológicos, realizar análisis espectrales de radiofrecuencia y mediciones de visibilidad,con las estaciones de la Figura 5.4 y la Figura 5.5.•SPP (Servicio de Guardia y Protección de Rumanía, https://www.spp.ro/#/): Socios encargados de laconfiguración y mantenimiento de los servidores NTP y NAS utilizados por todos los participantes.Figura 5.3Agenda del día 22 de abril durante los ensayos en Jaén. 40Capítulo 5. Pruebas de campo con sistemas C-UAS en el centro experimental de vuelo ATLAS•USE (Universidad de Sevilla): Equipo al que pertenece el autor del presente Trabajo de Fin de Grado,encargado del manejo y visualización de datos de los UAS y C-UAS y medida de posiciones de cada unode los sistemas C-UAS usando un receptor GPS y el software gpsavg (Sección4.3.1).5.2.1Servidor NASPara compartir datos entre los distintos grupos, los miembros de SPP establecieron un servidor NAS(Network Attached Storage) con una estructura escalonada de acceso, tal como se describe en la Figura5.8. Este estuvo disponible en la red local y se usó, entre otras funciones, para almacenar la plantilla de losinformes de los usuarios de COURAGEOUS, compartir los datos de los sistemas C-UAS y la posición deestos, medida con un receptor GPS de Aaronia cada mañana.Tras el evento, la información del servidor fue volcada a un servidor de TNO (https://www.tno.nl/nl/),miembro de COURAGEOUS, para su posterior análisis y disponibilidad al resto del consorcio.5.2.2Servidor NTPFue fundamental garantizar que el tiempo de todos los sistemas fuera correcto y sincronizado entre sí paraque errores de reloj no se confundieran con posibles retrasos de detección. Para asegurar esta sincronizaciónlos miembros de SPP pusieron a disposición de las empresas y consorcio un servidor NTP (Network TimeProtocol) que proporcionaba una fuente de tiempo precisa.Figura 5.4Estación meteorológica usada en las prue-bas.Figura 5.5Analizador de espectro de radiofrecuenciay medidor de visibilidad usado en las pruebas. 5.2. Organización41Figura 5.6Informe rellenado por los usuarios de COURAGEOUS durante las pruebas de ATLAS (Página 1) 42Capítulo 5. Pruebas de campo con sistemas C-UAS en el centro experimental de vuelo ATLASFigura 5.7Informe rellenado por los usuarios de COURAGEOUS durante las pruebas de ATLAS (Página 2)AlmacenamientoConsorcioIndustriaPúblicoPrivadoConsorcioPúblicoConsorcioPrivadoIndustriaPúblicoIndustriaAdmin.servidorUsuarioconsorcioUsuarioindustriaFigura 5.8Organización del servidor NAS de las pruebas de ATLAS. 5.3. Sistemas observados en las pruebas 435.3Sistemas observados en las pruebasLas compañías presentaron productos basados en diversas tecnologías como las previamente mencionadasen [4], tales como sistemas basados en cámaras de espectro visible o infrarrojos (Figura 5.10), en tecnologíaradar (Figura 5.11) o intercepción de radiofrecuencia (Figura 5.12).Cada compañía presentaba los resultados con su propio HMI, pero algunas eran capaces de usar fusiónde datos entre sí gracias a usar arquitecturas como SAPIENT, como el de la Figura 5.9.Figura 5.9HMI de una de las empresas presentes en las pruebas, con fusión de datos entre datos de variossistemas.Figura 5.10Diferentes tipos de sistemas C-UAS basados en cámaras usados en las pruebas de ATLAS. 44Capítulo 5. Pruebas de campo con sistemas C-UAS en el centro experimental de vuelo ATLASFigura 5.11Diferentes sistemas C-UAS basados en radares usados en las pruebas de ATLAS. Índice de Figuras1.2.Figura 1.1Diagrama de dependencia de los repositorios creados a lo largo del trabajo.22.4.Figura 2.1json-schema-visualizer con el schema del formato COURAGEOUS 0.4.1.92.5.2.Figura 2.2Captura de la página web del formato y track2kml.112.5.2.Figura 2.3Contenidos de la carpeta track2kml de la página web.122.5.2.Figura 2.4Ejemplo del changelog mostrado en la página web de una versión del formato.122.6.Figura 2.5Captura de pantalla de la guía del formato COURAGEOUS.132.7.Figura 2.6Interfaz de https://json-schema.app/ con la estructura Detection del schema 0.4.1 abierta.143.1.Figura 3.1Archivo de una empresa pasado a través de track2kml y visualizado con Google Earth Pro.163.1.Figura 3.2Propiedades de un punto de un track en un archivo de datos C-UAS de ejemplo.183.2.Figura 3.3Diagrama de dependencia de los componentes de track2kml.203.3.Figura 3.4Diagrama de dependencia de los componentes de track2kml.213.3.Figura 3.5Diagrama de procesamiento realizado por track2kml.213.3.1.Figura 3.6Ejemplo de representación de un arco en KML usando Polygon.223.3.1.Figura 3.7Ejemplo de representación de un rayo en KML usando LineString.224.1.Figura 4.1Visualización de la ondulación del geoide EGM-96 representada sobre la Tierra [32]264.1.Figura 4.2Sistema de coordenadas geocéntricas definido por WGS-84. [34]274.1.Figura 4.3La Tierra y dos posibles representaciones, un elipsoide y un geoide [36]274.2.1.Figura 4.4Captura de pantalla del software de Aaronia para visualización y exportación de archivosgrabados con sus loggers.294.2.2.Figura 4.5Parte posterior del PCB del receptor GPS de Aaronia.294.2.4.Figura 4.6Formato de un mensaje NMEA. [39]304.2.6.Figura 4.7Diálogo de conversión de NMEA a CSV en el software propietario de Aaronia.314.3.2.Figura 4.8Diálogo de exportación a KML parte del software de Aaronia.355.1.Figura 5.1Situaciones de riesgo en las que se basan los escenarios estándar del proyecto COURA-GEOUS. [1]385.1.Figura 5.2Obtención de puntuaciones para clasificación de sistemas C-UAS usando la metodologíapresentada por COURAGEOUS. [1]395.2.Figura 5.3Agenda del día 22 de abril durante los ensayos en Jaén.395.2.2.Figura 5.4Estación meteorológica usada en las pruebas.405.2.2.Figura 5.5Analizador de espectro de radiofrecuencia y medidor de visibilidad usado en las pruebas.405.2.2.Figura 5.6Informe rellenado por los usuarios de COURAGEOUS durante las pruebas de ATLAS(Página 1)415.2.2.Figura 5.7Informe rellenado por los usuarios de COURAGEOUS durante las pruebas de ATLAS(Página 2)425.2.2.Figura 5.8Organización del servidor NAS de las pruebas de ATLAS.435.3.Figura 5.9HMI de una de las empresas presentes en las pruebas, con fusión de datos entre datos devarios sistemas.435.3.Figura 5.10Diferentes tipos de sistemas C-UAS basados en cámaras usados en las pruebas de ATLAS.435.3.Figura 5.11Diferentes sistemas C-UAS basados en radares usados en las pruebas de ATLAS.445.3.Figura 5.12Diferentes sistemas C-UAS basados en intercepción de datos por radiofrecuencia usadosen las pruebas de ATLAS.4565 53Índice de Figuras5.4.Figura 5.13Diferentes tipos de UAV de ala fija usadas en las pruebas en ATLAS.465.4.Figura 5.14UAV multirotor DJI-M300 usado en las pruebas en ATLAS.465.5.Figura 5.15Plan de vuelo de los UAS en la prueba 4 del día 2 de los trials en ATLAS.475.5.Figura 5.16Nave de ATLAS durante un día de las pruebas.473.1.Tabla 3.1Tipos de geometrías de relevancia en la visualización de datos C-UAS.194.2.2.Tabla 4.1Sensores y periféricos del receptor GPS de Aaronia.294.2.8.Tabla 4.2Extracto de un fichero CSV generado con el software Aaronia con la opción one set persecond.324.2.8.Tabla 4.3Extracto de un fichero CSV generado con el software Aaronia con la opción export all data.332.3.Código 2.1Ejemplo de la librería schemars aplicada en una estructura MyStruct que genera elschema de la siguiente figura.62.3.Código 2.2Schema resultante al ejecutar el código de la figura previa (example-schema.json)62.3.Código 2.3Extracto del schema del formato COURAGEOUS.72.3.Código 2.4Archivo COURAGEOUS de ejemplo.82.5.2.Código 2.5Metadatos sobre track2kml guardados en el archivo list.json.102.6.Código 2.6Fuente Markdown del capítulo 1 de la guía de uso del formato COURAGEOUS.133.1.Código 3.1Información de uso de la última versión publicada de track2kml (2.4.0).183.3.1.Código 3.2Declaración de track2kml::write_as_kml.213.3.2.Código 3.3Función principal run de la librería track2kml-cli.233.3.2.Código 3.4Interfaz que debe definir cualquier parser de un formato para que sea compatible contrack2kml.233.3.2.Código 3.5Interfaz que debe presentar un formato para que pueda leerse desde el CLI de track2kml.243.3.3.Código 3.6Algunos de los errores que se puede presentar track2kml al usuario.243.4.Código 3.7Extracto de generate_release_extract.sh, que automatiza el proceso de compilaciónde track2kml.254.2.4.Código 4.1Ejemplo de serie de mensajes enviados por el módulo GPS PAM-7Q en un segundo dado.304.2.5.Código 4.2Secuencia típica de datos del fichero «raw» del logger GPS.314.3.1.Código 4.3Mensaje de ayuda de la última versión de gpsavg.344.3.1.Código 4.4Resultado de ejecución de gpsavg en un fichero de ejemplo.344.3.2.Código 4.5Listado de ayuda de la última versión disponible de aag2courageous.35 GlosarioNMEA. NMEA 0183. Combinación de especificación eléctrica y de datos usado en muchos contextos, pero queen este TFG es relevante como protocolo de transmisión de información GPS.FormatosCSS. Cascading Style Sheets. Lenguaje de presentación y estilado común en páginas web.CSV. Comma-Separated Values. Formato de archivo que almacena datos tabulares en texto plano.HTML. HyperText Markup Language. Lenguaje usado para describir el contenido y la estructura de páginas web.JSON. JavaScript Object Notation. Formato de intercambio de datos textual, estructurado y autodescriptivo.KML. Keyhole Markup Language. Formato desarrollado para usarse con Google Earth para visualización yanotación en mapas bidimensionales y tridimensionales terráqueos.RSS. Really Simple Syndication. Formato de archivo basado en XML usado para sindicación (redifusión) decontenido web.Schema JSON. Archivo JSON que contiene la descripción de la estructura de un tipo de formato basado en JSON.Permite la validación de archivos y la generación automática de ejemplos del formato. [16]XML. eXtensible Markup Language. Lenguaje de marcado extensible usado para definir documentos con unaestructura jerárquica.OtrosAPI. Application Programming Interface. Interfaz de programación de una aplicación.CLI. Command Line Interface. Interfaz de línea de comandos.GUI. Graphical User Interface. Interfaz gráfica de usuario.ProgramasGoogle Earth. Software de Google que representa el globo terráqueo junto con información de superficieproporcionada por satélite.Términos relacionados con dronesC-UAS. Counter-Unmanned Aerial System. Sistemas que tienen como objetivo la detección, rastreo o neutrali-zación de sistemas aéreos no tripulados.67 55GlosarioGCS. Ground Control Station. Estación de control (de UAVs) terrestre. Para UAVs más pequeños, puede referirseal control remoto.HMI. Human Machine Interface. En este contexto, se refiere al software otorgado por las compañías de los C-UAS usado por los operadores de los sistemas.UAS. Unmanned Aerial System. Sistema aéreo no tripulado. Hace referencia a la combinación del UAV y GCS.UAV. Unmanned Aerial Vehicle. Vehículo aéreo no tripulado, tal como un dron. Bibliografía[1]G. De Cubber etal., «Standardized Evaluation of Counter-Drone Systems: Methods, Technologies, andPerformance Metrics», Drones, vol. 9, n.º 5, 2025, doi: 10.3390/drones9050354.[2]«NATO tests counter drone technology during interoperability exercise». Accedido: 20 de junio de2025. [En línea]. Disponible en: https://www.ncia.nato.int/about-us/newsroom/nato-tests-counter--drone-technology-during-interoperability-exercise[3]«Ucrania lanza un ataque a gran escala y bombardea 4 aeródromos rusos en el norte del país».Accedido: 4 de junio de 2025. [En línea]. Disponible en: https://www.bbc.com/mundo/articles/c331jz5kj82o[4]J. Wang, Y. Liu, y H. Song, «Counter-Unmanned Aircraft System(s) (C-UAS): State of the Art,Challenges, and Future Trends», IEEE Aerospace and Electronic Systems Magazine, vol. 36, n.º 3, pp.4-29, 2021, doi: 10.1109/MAES.2020.3015537.[5]J. Kim, C. Park, J. Ahn, Y. Ko, J. Park, y J. C. Gallagher, «Real-time UAV sound detection andanalysis system», SAS 2017 - 2017 IEEE Sensors Applications Symposium, Proceedings, 2017, doi: 10.1109/SAS.2017.7894058.[6]F. Christnacher etal., «Optical and acoustical UAV detection», https://doi.org/10.1117/12.2240752, vol.9988, pp. 83-95, 2016, doi: 10.1117/12.2240752.[7]I. Bisio, C. Garibotto, F. Lavagetto, A. Sciarrone, y S. Zappatore, «Unauthorized Amateur UAV Detec-tion Based on WiFi Statistical Fingerprint Analysis», IEEE Communications Magazine, vol. 56, n.º 4,pp. 106-111, 2018, doi: 10.1109/MCOM.2018.1700340.[8]M. E. Rovkin etal., «Radar detection of small-size UAVs», Proceedings - 2018 Ural Symposium onBiomedical Engineering, Radioelectronics and Information Technology, USBEREIT 2018, pp. 371-374,2018, doi: 10.1109/USBEREIT.2018.8384626.[9]J. Sander, A. Kuwertz, D. Mühlenberg, y W. Müller, «High-level data fusion component for droneclassification and decision support in counter UAV», https://doi.org/10.1117/12.2306148, vol. 10651, pp.87-96, 2018, doi: 10.1117/12.2306148.[10]«Data Format for the COURAGEOUS Trials». [En línea]. Disponible en: https://grvc.us.es/courageous/[11]«Link 16 Format». Accedido: 20 de junio de 2025. [En línea]. Disponible en: https://en.wikipedia.org/wiki/Link_16[12]«All-purpose structured EUROCONTROL surveillance information exchange». Accedido: 20 de juniode 2025. [En línea]. Disponible en: https://www.eurocontrol.int/asterix[13]«Página oficial sobre el estándar SAPIENT (BSI Flex 335)». Accedido: 14 de mayo de 2025. [En línea].Disponible en: https://www.gov.uk/guidance/sapient-autonomous-sensor-system[14]«GPX: the GPS Exchange Format». Accedido: 20 de junio de 2025. [En línea]. Disponible en: https://www.topografix.com/gpx.asp[15]«COURAGEOUS Data Format Guide». Accedido: 14 de mayo de 2025. [En línea]. Disponible en:https://grvc.us.es/courageous/schemas/docs/v0.4.1[16]«JSON Schema». [En línea]. Disponible en: https://json-schema.org/[17]«Generate JSON Schema documents from Rust code». Accedido: 14 de mayo de 2025. [En línea].Disponible en: https://docs.rs/schemars[18]«COURAGEOUS data format». Accedido: 14 de mayo de 2025. [En línea]. Disponible en: https://github.com/COURAGEOUS-isf/format[19]B. E. Kabakcı, «A Visualizer for JSON Schema». [En línea]. Disponible en: https://github.com/buremba/json-schema-visualizer69 57Bibliografía[20]B. E. Kabakcı y A. Perea, «Visualizador de schemas JSON». [En línea]. Disponible en: https://github.com/aleokdev/json-schema-visualizer[21]«mdBook Documentation». Accedido: 9 de junio de 2025. [En línea]. Disponible en: https://rust-lang.github.io/mdBook/[22]«Rust Programming Language». Accedido: 14 de mayo de 2025. [En línea]. Disponible en: https://www.rust-lang.org/[23]A. Perea, «Simplez interpreter & assembler that works in the Web». [En línea]. Disponible en: https://github.com/aleokdev/simplez_asm[24]«COURAGEOUS Github organization». Accedido: 14 de mayo de 2025. [En línea]. Disponible en:https://github.com/COURAGEOUS-isf[25]«A CLI tool and Rust crate to convert from the COURAGEOUS data format to KML.». Accedido: 14de mayo de 2025. [En línea]. Disponible en: https://github.com/COURAGEOUS-isf/track2kml[26]«Semantic Versioning 2.0.0». [En línea]. Disponible en: https://semver.org/[27]«KML Reference». Accedido: 14 de mayo de 2025. [En línea]. Disponible en: https://developers.google.com/kml/documentation/kmlreference[28]«KML Tutorial». Accedido: 14 de mayo de 2025. [En línea]. Disponible en: https://developers.google.com/kml/documentation/kml_tut[29]«KML Developer's Guide». Accedido: 14 de mayo de 2025. [En línea]. Disponible en: https://developers.google.com/kml/documentation/topicsinkml[30]«A simple to use, efficient, and full-featured Command Line Argument Parser». Accedido: 14 de mayode 2025. [En línea]. Disponible en: https://docs.rs/clap/[31]«Aaronia GPS Logger Datasheet». [En línea]. Disponible en: https://downloads.aaronia.com/datasheets/solutions/gps/Aaronia_GPS_Logger.pdf[32]«Visualization of Gravity Field Models and their Differences». [En línea]. Disponible en: https://icgem.gfz-potsdam.de/vis3d/longtime[33]J. S. Subirana, J. J. Zornoza, y M. Hernández-Pajares, «Reference Frames in GNSS», [En línea]. Dispo-nible en: https://gssc.esa.int/navipedia/index.php/Reference_Frames_in_GNSS[34]L. Sandino, «Modeling and control techniques of autonomous helicopters for landing on movingplatforms», 2016.[35]J. S. Subirana, J. J. Zornoza, y M. Hernández-Pajares, «Ellipsoidal and Cartesian Coordinates Con-version», [En línea]. Disponible en: https://gssc.esa.int/navipedia/index.php?title=Ellipsoidal_and_Cartesian_Coordinates_Conversion[36]R. Knippers, «Spatial referencing». [En línea]. Disponible en: https://unstats.un.org/unsd/geoinfo/ungegn/docs/_data_ICAcourses/_HtmlModules/_Documents/D06/documents/D06-03_KnippersPPTeaching.pdf[37]«ATMega128A Datasheet». Accedido: 14 de junio de 2025. [En línea]. Disponible en: https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-8151-8-bit-AVR-ATmega128A_Datasheet.pdf[38]«PAM-7Q Data Sheet». Accedido: 14 de junio de 2025. [En línea]. Disponible en: https://content.u--blox.com/sites/default/files/PAM-7Q_DataSheet_%28UBX-13002455%29.pdf[39]«u-blox 7 Receiver Description». [En línea]. Disponible en: https://content.u-blox.com/sites/default/files/products/documents/u-blox7-V14_ReceiverDescriptionProtocolSpec_%28GPS.G7-SW-12001%29_Public.pdf[40]«ITG-3200 Product Specification». Accedido: 14 de junio de 2025. [En línea]. Disponibleen: https://product.tdk.com/system/files/dam/doc/product/sensor/mortion-inertial/gyro/data_sheet/itg-3200-datasheet.pdf[41]«FT2232D USB UART/FIFO IC Datasheet». Accedido: 14 de junio de 2025. [En línea]. Disponible en:https://ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT2232D.pdf[42]«3-Axis Digital Compass IC HMC5883L». Accedido: 14 de junio de 2025. [En línea]. Disponible en:https://www.farnell.com/datasheets/1683374.pdf[43]«LPS331AP - MEMS pressure sensor: 260-1260 mbar absolute digital output barometer». Accedido:14 de junio de 2025. [En línea]. Disponible en: https://www.iot-lab.info/assets/misc/docs/iot-lab-m3/LPS331AP.pdf[44]«Aaronia GPS Logger Programming Guide». [En línea]. Disponible en: https://dev.aaronia-shop.com/downloads/gps/manuals/gps_logger_programming_guide_en.pdf[45]«Repositorio del conversor de archivos del logger de Aaronia a COURAGEOUS». [En línea]. Dispo-nible en: https://github.com/COURAGEOUS-isf/aag2courageous 58Bibliografía[46]«Unmanned aircraft systems - Counter UAS - Testing methodology», CEN Workshop Agreement, n.º18150.[47]«Project COURAGEOUS 2 - Assisting the European Commission in countering potential threatsposed by drones through standardized testing methodologies for counter-drone systems.». [En línea].Disponible en: https://projectcourageous2.com/