ATAK y CoT: análisis técnico detallado del núcleo de los sistemas modernos de conciencia situacional

Introducción

El Android Team Awareness Kit (ATAK) es una plataforma de software para Android orientada a la conciencia situacional geoespacial y la colaboración. Se desarrolló originalmente con fines militares (entonces como «Android Tactical Assault Kit») y ahora también está disponible en una versión civil (CivTAK). ATAK permite la visualización de datos geográficos en tiempo real, por ejemplo, posiciones de equipos de respuesta, zonas de peligro y objetivos de misión, sobre mapas digitales, y ayuda a los usuarios a navegar, planificar operaciones y comunicarse. Entre sus características principales se encuentran la visualización de mapas de alto rendimiento (2D/3D) con mapas en línea y sin conexión, el uso compartido de objetos (puntos, rutas y zonas), así como funciones de comunicación integradas, como chat de texto, intercambio de archivos, video en vivo y seguimiento. También destaca la arquitectura extensible de complementos de ATAK, que permite integrar funciones adicionales para operaciones específicas. CivTAK (ATAK-CIV) se puso a disposición del público en 2020 y pasó a llamarse «Android Team Awareness Kit». A continuación se presenta un análisis técnico de ATAK y CivTAK centrado en la arquitectura del sistema, las API e interfaces, el desarrollo de complementos, los mecanismos de seguridad, el protocolo Cursor-on-Target (CoT), las diferencias entre las versiones militar y civil, y los recursos y SDK de código abierto disponibles para desarrolladores. Los ejemplos y fragmentos de código ilustran los conceptos principales.

Arquitectura del sistema

ATAK está diseñado como un sistema cliente-servidor modular. El cliente principal es una aplicación Android; el componente de servidor TAK (opcional) puede funcionar como backend central para coordinar varios clientes. La arquitectura de la aplicación Android se organiza en varios componentes principales, resumidos en la siguiente tabla:

Funcionamiento: Durante la operación, el cliente ATAK obtiene su posición del GPS interno y muestra el entorno al usuario en el mapa. Datos de eventos (posiciones, íconos y mensajes) se intercambian mediante CoT con otros clientes conectados, ya sea directamente en una red ad hoc (mediante multidifusión o difusión) o a través de un servidor TAK central. Así, todos los participantes conectados reciben actualizaciones en tiempo real y comparten una visión común de la situación. El servidor TAK actúa como instancia central para la sincronización y el almacenamiento de datos: recibe mensajes CoT de todos los clientes y los reenvía a los demás. El servidor también ofrece servicios como gestión de usuarios, persistencia (base de datos de misiones) y, en su caso, interfaces con otros sistemas. ATAK se ejecuta en Android (Java/Kotlin), con componentes críticos para el rendimiento en C/C++ (motor de renderizado). La modularidad de los complementos deja la arquitectura abierta a numerosas ampliaciones; por ejemplo, los complementos de comunicación pueden incorporar medios de transmisión alternativos (p. ej., un módem acústico por radio), mientras que los complementos de datos pueden leer fuentes externas (p. ej., un rastreador aéreo ADS-B o telemetría de drones). Este diseño abierto permite adaptar ATAK a distintas operaciones (militares, servicios de seguridad y emergencia, actividades al aire libre, etc.), ya que se pueden añadir funciones específicas como complementos sin modificar el núcleo. Las versiones militar y civil de la aplicación son prácticamente idénticas en su arquitectura y plenamente compatibles entre sí; las diferencias se encuentran sobre todo en complementos o configuraciones adicionales para uso militar (véase la sección Diferencias entre ATAK y CivTAK).

API e interfaces

ATAK/CivTAK ofrece varias interfaces para desarrolladores que permiten introducir y recuperar datos o ampliar la aplicación. En esencia, existen dos enfoques: (1) Uso del protocolo CoT para integrar datos externos y (2) Desarrollo de complementos dentro de la aplicación ATAK mediante la API disponible.

1. Protocolo CoT como interfaz externa: Dado que ATAK transporta toda la información situacional en forma de eventos Cursor-on-Target (CoT), un sistema externo puede incorporarse a la distribución de datos mediante el envío o la recepción de mensajes CoT. Por ejemplo, un sensor u otro programa puede enviar por UDP/TCP un mensaje CoT con un evento determinado (p. ej., la posición de un vehículo o una alerta) a los clientes ATAK o al servidor TAK. Todos los participantes que reciban ese mensaje mostrarán el objeto correspondiente en sus mapas. De esta manera, ATAK puede integrarse con relativa facilidad en sistemas externos mediante la generación de mensajes CoT en el formato XML/Proto esperado. A la inversa, también pueden capturarse datos CoT de ATAK para reutilizarlos en otras aplicaciones (p. ej., transmitir la visión de la situación a un software propio). Caso de uso: Un flujo sencillo de Node-RED o un script de Python podría generar periódicamente XML CoT con las coordenadas GPS de un rastreador para mostrarlo como «participante virtual» en la red ATAK. Como CoT está documentado y estandarizado, existen bibliotecas para distintos lenguajes (p. ej., node-cot en JavaScript o takproto en Python) para serializar y deserializar mensajes CoT. Además, algunos servidores TAK (especialmente el proyecto de código abierto FreeTAKServer) implementan una REST-API que permite a aplicaciones de terceros añadir nuevos objetivos o mensajes, por ejemplo. Se ofrece como alternativa más fácil de usar que la inyección directa de CoT mediante UDP/TCP. Sin embargo, CoT sigue siendo la vía habitual: la API REST del servidor también convierte finalmente las solicitudes en eventos CoT para los clientes.

2. API de complementos de ATAK: Para una integración más profunda y para ampliar el propio ATAK, la plataforma ofrece una API interna en el SDK de complementos. Un complemento se ejecuta dentro de la aplicación ATAK y puede acceder a las funciones y eventos de su núcleo. Técnicamente, ATAK utiliza un patrón similar a un bus de eventos y clases de interfaz definidas. Entre las clases principales se encuentran ToolDropDownReceiver (o, de forma abreviada, DropDownReceiver) y MapComponent, de las cuales derivan las clases del complemento. El MapComponent sirve como punto de entrada: se inicializa al cargar el complemento y puede registrar componentes de interfaz, como herramientas y capas. El DropDownReceiver está implementado como receptor de difusión y recibe eventos de difusión específicos de ATAK (p. ej., acciones del usuario o eventos del sistema). Mediante su método onReceive, el complemento los procesa y puede responder. La API de ATAK también proporciona numerosos servicios, como dibujar sobre el mapa, añadir marcadores, acceder al modelo de datos interno (eventos CoT) o enviar mensajes de red. Así, por ejemplo, un complemento puede crear un objeto por programación y publicarlo en el mapa al introducir un evento CoT mediante el despachador de eventos interno. El fragmento 1 muestra un ejemplo simplificado de código (Kotlin/Java) de un complemento que crea un marcador CoT y lo añade localmente a la aplicación ATAK:

// Innerhalb eines ATAK-Plugins: Erstellen eines CoT-Events und Dispatch im lokalen Client
CotEvent cot = new CotEvent();
cot.uid   = "Demo-1";                        // eindeutige ID
cot.type  = "a-f-G-U-C";                     // CoT-Typ (hier z.B. "friendly Ground Unit, Unit, Civilian")
cot.time  = new CoordinatedTime();           // aktuelle Zeitstempel
cot.start = cot.time;
cot.stale = cot.time.addMinutes(5);          // Gültigkeit 5 Minuten
cot.how   = "m-g";                           // how = Methode der Positionsbestimmung (z.B. m-g = GPS)
cot.setPoint(new CotPoint(50.775, 6.083, 0.0, 50.0, 50.0));  // Position (lat, lon, hae, ce, le)
CotMapComponent.getInternalDispatcher().dispatch(cot);       // Event intern verteilen (auf Karte anzeigen)

El código utiliza clases de ATAK (CotEvent, CotPoint, CotMapComponent) del SDK. Primero crea un evento nuevo, establece varios atributos (véase el protocolo CoT) y después lo publica mediante el despachador de eventos interno. Como resultado, el cliente ATAK muestra inmediatamente el evento en el mapa (en este caso, por ejemplo, como símbolo de una «unidad amiga» según el código de tipo). Si es necesario, ATAK también lo reenviará a pares o servidores conectados, siempre que no se haya marcado como exclusivamente local. Este ejemplo muestra cómo los complementos pueden usar las funciones de ATAK por programación, por ejemplo, para integrar fuentes de datos externas (telemetría de drones o sensores IoT) o implementar nuevas herramientas. Un complemento comunitario, por ejemplo, integró el control de drones MAVLink al introducir sus posiciones como CoT y ofrecer interfaces de control.

Además de las interfaces CoT y de complementos, ATAK también admite interfaces de archivos convencionales: mediante Overlay Manager, los usuarios pueden importar archivos KML, KMZ o GPX, mientras que los llamados Data Packages permiten agrupar capas, archivos de claves o datos de misión en un paquete para distribuirlo a otros (p. ej., mediante un archivo o servidor). Sin embargo, estos mecanismos están pensados más para usuarios finales e intercambio de datos que como API para desarrolladores; se mencionan aquí para completar el panorama. En resumen, las principales interfaces disponibles para desarrolladores son CoT (para conectar sistemas externos de forma flexible) y el ATAK Plugin SDK (para una integración estrecha con acceso a todas las funciones).

Desarrollo de complementos

El desarrollo de complementos propios para ATAK/CivTAK es una vía importante para ampliar la plataforma y adaptarla a necesidades específicas. ATAK proporciona para ello un Plugin Development Kit (SDK) oficial y plantillas con las que los desarrolladores pueden crear extensiones relativamente rápido. A continuación se describen los pasos y aspectos principales:

• SDK y entorno de desarrollo: El código fuente de ATAK-CIV está disponible libremente en GitHub. El TAK Product Center también proporciona un Plugins SDK. Los desarrolladores descargan el proyecto ATAK-CIV o el paquete SDK, que contiene complementos de ejemplo (como HelloWorld ) y las bibliotecas necesarias. Se recomienda usar Android Studio como entorno de desarrollo. Tras configurar el proyecto (importar la plantilla del complemento como módulo y señalar el SDK de ATAK en local.properties), se pueden compilar los complementos de ejemplo y probarlos en un dispositivo Android. Importante: para desarrollar, conviene utilizar una compilación de depuración específica de ATAK (incluida en el SDK o disponible en civTAK.org), porque la versión de Play Store puede exigir complementos firmados.
• Estructura de un proyecto de complemento: En esencia, un complemento ATAK es una aplicación Android independiente (APK) que no tiene una interfaz propia en el iniciador, sino que ATAK carga. La plantilla suele contener dos clases principales, por ejemplo, PluginTemplateDropDownReceiver y PluginTemplateMapComponent (los nombres varían según la plantilla). Heredan de las clases base de ATAK y el núcleo las reconoce por las entradas en el AndroidManifest.xml del complemento. Cuando el usuario activa el complemento en ATAK (normalmente detectado automáticamente, p. ej., por el nombre del paquete o el manifiesto), ATAK crea una instancia de su MapComponent. En ella, el complemento registra, por ejemplo, nuevas opciones de menú (botones desplegables en la barra de herramientas de ATAK) o capas. El DropDownReceiver recibe los clics en esos elementos de interfaz y puede ejecutar la lógica correspondiente. Los complementos también pueden usar servicios en segundo plano o iniciar actividades propias que aparecen como ventanas integradas en ATAK.
• Uso de la API de ATAK: Dentro del complemento se puede acceder a numerosas funciones de la aplicación principal mediante las clases de gestión y auxiliares que proporciona el núcleo de ATAK (incluidas en el SDK como archivos JAR o dependencias Maven). Ejemplos: acceso a MapView para dibujar gráficos; MissionPackageUtils para crear paquetes de datos; el servicio GeoChat para enviar mensajes al chat por programación; o el uso directo de las clases CoT, como se muestra en el fragmento 1. La guía de desarrollo de complementos (PDF incluido en el SDK) explica las clases principales y los puntos de enlace del ciclo de vida. Dado que ATAK se basa en Android, muchos patrones habituales de desarrollo Android (ciclo de vida de actividades, permisos, etc.) también se aplican, con ciertas limitaciones, a los complementos. Sin embargo, estos se ejecutan en el contexto de la aplicación ATAK y no como aplicaciones plenamente independientes. Por ejemplo, los desarrolladores deben realizar las acciones de interfaz en el hilo y contexto de interfaz adecuados (interfaz del mapa frente al contexto del complemento).
• Herramientas y depuración: Para desarrollar resulta útil observar los registros de ATAK. ATAK registra numerosos eventos, incluidos los de los complementos, mediante Logcat de Android. El documento del SDK indica filtros para mostrar los registros relevantes (p. ej., todas las etiquetas atak). Como los complementos se ejecutan junto con ATAK, se pueden adjuntar al depurador de Android Studio una vez que ATAK se inicia con el complemento.
• Ejemplos y plantillas: El SDK oficial incluye un complemento HelloWorld que muestra de forma mínima cómo añadir un botón y presentar una notificación Toast. A partir de ahí, los desarrolladores pueden incorporar funciones más complejas. Hay tutoriales comunitarios, como una serie de talleres de RIIS, que explican el desarrollo con ejemplos (p. ej., la integración de datos de drones MAVLink). Además, la comunidad de código abierto publica complementos cuyo código puede servir como referencia, como complemento SOOTHSAYER de CloudRF para ATAK en GitHub o el complemento LoRa atak-forwarder.
• Distribución e instalación: Los complementos terminados pueden distribuirse como archivos APK normales. Los usuarios de CivTAK pueden añadir un complemento instalando el archivo APK; ATAK lo reconoce y lo muestra en la lista de complementos. Algunos complementos para uso civil incluso se ofrecen en Google Play Store, por ejemplo, el complemento WASP (Wide Area Search Planning) o HAMMER (un complemento de módem acústico para radios). Los complementos de uso militar suelen distribuirse mediante la plataforma oficial TAK.gov (solo para usuarios autorizados). Al desarrollar conviene tener presente que la compatibilidad con futuras versiones de ATAK es importante: la API de complementos puede cambiar y, por ello, suelen recompilarse cuando se publica una nueva versión de ATAK (aunque el TAK Product Center procura mantener la compatibilidad con versiones anteriores).

En resumen, la arquitectura de complementos permite desarrollar extensiones a medida para ATAK/CivTAK: desde integrar hardware de comunicaciones especializado y bases de datos propietarias hasta implementar funciones de interfaz completamente nuevas. El SDK disponible y la comunidad activa facilitan los primeros pasos, por lo que ATAK cuenta ya con una amplia gama de complementos en distintos ámbitos (muchos de código abierto o disponibles como referencia).

Mecanismos de seguridad

ATAK/CivTAK se utiliza con frecuencia en entornos donde la seguridad es crítica. Por ello, los mecanismos de seguridad intervienen en varios niveles: (a) protección de las comunicaciones (cifrado de red y autenticación), (b) control de acceso y roles, y (c) protección de los datos almacenados localmente en el dispositivo.

Cifrado y seguridad de la red: De forma predeterminada, ATAK envía los mensajes CoT en texto claro por redes IP (UDP/TCP); por tanto, el protocolo en sí no ofrece inicialmente cifrado de extremo a extremo. La seguridad de la transmisión depende en gran medida del medio de transporte utilizado. En entornos militares, ATAK suele funcionar sobre redes de radio ya protegidas o túneles VPN. Para usuarios civiles se recomienda, por ejemplo, configurar una ZeroTier-VPN para cifrar el envío de datos CoT por internet entre miembros del equipo.

A partir de ATAK CIV 4.0 se añadió un cifrado de extremo a extremo integrado para redes ad hoc o en malla. Los usuarios pueden generar opcionalmente una clave AES-256 y compartirla con el equipo para intercambiar datos CoT cifrados en la red local () (). Una vez que todos los dispositivos participantes cargan la misma clave, solo aceptan mensajes CoT cifrados entre sí; los dispositivos sin clave quedan excluidos () (). Este cifrado AES para redes en malla evita que puedan leerse en texto claro posiciones, chats y otros datos incluso en un canal de radio inseguro (p. ej., una MANET sin VPN). Se configura en los ajustes de ATAK, en Configure AES-256 Mesh Encryption, donde se genera una clave (archivo de clave) que después se distribuye a todos los dispositivos mediante un paquete de datos o por anticipado (). Para conexiones entre los clientes ATAK y un servidor TAK central, normalmente se utiliza TLS/SSL. El servidor TAK oficial admite conexiones WebSocket/SSL cifradas. Según la documentación, el servidor TAK implementa «transmisión cifrada de datos» y control de acceso, lo que en la práctica implica TLS (para datos en tránsito) y autenticación. El servidor puede configurarse para que solo los clientes con certificados o tokens de acceso válidos se conecten (autenticación del cliente). Además, las soluciones VPN o de APN privados de los organismos públicos pueden aislar aún más el tráfico TAK. Es importante destacar que ATAK solo cifra los datos CoT si se configura para ello o se utiliza un medio de transporte seguro: CivTAK envía sin cifrar en la red local de forma predeterminada, pero permite activar medidas de seguridad.

Autenticación y control de acceso: En un entorno puramente entre pares, ATAK no cuenta con autenticación de usuarios: cualquiera que entre en la red en malla (y disponga de la clave AES, si se configuró) puede ver todos los datos. En configuraciones basadas en servidor, en cambio, cada usuario inicia sesión en el servidor TAK con una cuenta. El servidor administra cuentas de usuario, grupos y roles. Así se puede controlar qué información puede ver o enviar cada usuario (control de acceso basado en roles). Por ejemplo, ciertos eventos CoT podrían marcarse para que solo los responsables los vean. TAK Server 5.x admite estos roles y reglas de filtrado. El servidor también registra los accesos, lo que crea un historial de auditoría de quién envió o recibió cada dato y cuándo.

Protección de datos locales: Al iniciar CivTAK por primera vez, la aplicación genera automáticamente una frase de contraseña de cifrado para proteger los archivos locales (). Esta frase, que el usuario puede cambiar, se utiliza para almacenar cifrados en el dispositivo los mapas en caché, los datos de misión guardados o los ajustes, por ejemplo. Así se busca impedir que, si se pierde el dispositivo, se pueda acceder a datos operativos sensibles. El mecanismo funciona de forma transparente en segundo plano. ATAK también permite, mediante Wipe o Clear Data todos los contenidos almacenados con rapidez.

Otras medidas: ATAK se ejecuta como una aplicación Android normal, por lo que también se beneficia de las funciones de seguridad del sistema operativo (aislamiento y permisos). Por ejemplo, los complementos deben estar firmados o la aplicación debe autorizar expresamente la carga de complementos sin firma (una medida contra la inyección de código no autorizado). En general, el ecosistema TAK adopta un enfoque en el que la seguridad del transporte suele aplicarse a nivel de red (VPN y TLS), y la seguridad del contenido puede reforzarse opcionalmente mediante cifrado a nivel de aplicación. Para maximizar la protección, las buenas prácticas de TAK recomiendan combinar canales de red seguros (p. ej., VPN), autenticación sólida de usuarios, cifrado AES activado para CoT y protección física de los dispositivos. La versión militar de ATAK puede incluir además módulos de cifrado certificados (criptografía Type 1) que no están presentes en CivTAK. Sin embargo, hay poca información pública al respecto porque estos componentes están sujetos a ITAR y otras restricciones.

Protocolo Cursor-on-Target (CoT)

El protocolo Cursor-on-Target (CoT) constituye la columna vertebral de la comunicación de datos en el ecosistema TAK. Es un formato de mensajes basado en XML desarrollado originalmente por MITRE, que crea un «lenguaje» común para intercambiar objetivos y datos de posición sensibles al tiempo entre sistemas (Cursor on Target: Research for a Sensor Network – PMC). ATAK y los demás clientes TAK (WinTAK, iTAK, etc.) utilizan CoT para codificar y compartir de forma estandarizada información como ubicación, dirección de movimiento, tipo de evento y mensajes.

Estructura del mensaje: Un mensaje CoT suele consistir en un único elemento XML <event> con diversos atributos y subelementos. En el fragmento 2 se muestra un ejemplo muy simplificado de evento CoT:

<event version="2.0" uid="UID12345" type="a-f-G-U-C" time="2025-02-26T17:30:00Z" start="2025-02-26T17:30:00Z" stale="2025-02-26T17:35:00Z" how="m-g">
    <point lat="50.7762" lon="6.0838" hae="123.0" ce="5.0" le="10.0"/>
    <detail>
        <contact callsign="Alpha1"/>
        <usericon iconsetpath="apps://icons/alpha.png"/>
    </detail>
</event>

Ejemplo de mensaje XML CoT (unidad amiga «Alpha1» con posición)

Cada elemento event tiene atributos obligatorios:

• uid: identificador único del evento (p. ej., número de serie del dispositivo o indicativo de llamada). Permite reconocer actualizaciones de objetos existentes.
• type: Tipo de evento codificado como cadena jerárquica. El primer carácter indica la categoría (p. ej., a = «Atom» para objetos físicos). Después siguen abreviaturas separadas por guiones que indican enemigo o amigo, dominio y, en su caso, otros subtipos. En el ejemplo anterior, a-f-G-U-C significa atom-friend-Ground-Unit-Civilian (unidad terrestre amiga, civil). Muchos de estos códigos de tipo se basan en el estándar militar MIL-STD-2525 (símbolos de la OTAN), lo que permite una representación uniforme en el mapa (FTS Documentation).
• time, start, stale: Marcas de tiempo. time es la hora de creación del evento; start marca el inicio de su validez (a menudo coincide con time), y stale indica cuándo caduca, es decir, cuándo el sistema puede considerarlo obsoleto y eliminarlo. Así, cada objeto tiene una duración definida, algo importante para eventos temporales (p. ej., la posición de un objetivo móvil que, tras X segundos sin actualización, se marca como «ya no confiable»).
• how: (opcional) Indica cómo se obtuvo la información, por ejemplo, m-g para «GPS militar» o h-e para «introducido manualmente» (human-entered). Puede indicar la confiabilidad o la fuente.

Subelementos:

• : Contiene la posición geográfica y la precisión. Sus atributos son lat (latitud), lon (longitud), hae (altura sobre el elipsoide, en metros), ce (radio de error circular, en m: precisión horizontal) y le (error lineal, en m: imprecisión vertical). En el ejemplo, Alpha1 tiene una altitud de 123 m y una precisión de posición de 5 m en horizontal y 10 m en vertical.
• : Aquí pueden incluirse detalles adicionales como subelementos estructurados. Es un campo flexible que puede contener información distinta según el tipo de evento. En eventos de posición e identificación son habituales los siguientes elementos de detalle: <contact> con atributos como callsign (indicativo de llamada o nombre del usuario), <remarks> para comentarios de texto libre, <group> para pertenencia a un equipo, <status> (p. ej., confirmación o rechazo, estado de actividad) y otros. En el ejemplo, el detalle contiene el contacto «Alpha1» y una entrada usericon que indica la ruta de un ícono específico (para símbolos personalizados). El elemento detail es ampliable: los mensajes de chat, las transmisiones de video y las mediciones de sensores también se especifican en ese bloque, a menudo mediante espacios de nombres XML propios según el tipo de dato.

Un evento CoT mínimo puede prescindir por completo del elemento detail, como muestra el ejemplo de un punto simple de MITRE. Los complementos ATAK suelen usarlo para incluir cargas útiles o indicadores propietarios, siempre que todos los clientes puedan interpretarlos.

Distribución y transporte: En ATAK, los mensajes CoT se envían mediante UDP-Broadcast/Multicast (para la comunicación directa del equipo en una red en malla) o TCP/SSL a un servidor, que los redistribuye a los demás. Las primeras versiones de ATAK solo utilizaban XML; las más recientes también admiten una variante binaria de CoT basada en Google Protocol Buffers, llamada TAK Proto o CoT Proto) (TAK Protocol Description – Encode and Decode TAK data with Python). En ella, los mismos campos se representan en un formato binario compacto que ahorra ancho de banda y acelera el análisis. ATAK 4.0+ envía, por ejemplo, mensajes CoT como Protobuf con una cabecera fija (191 bytes) en el modo «Mesh SA» predeterminado, mientras que el modo de flujo al servidor utiliza una cabecera de longitud variable. Para los desarrolladores, esto significa que la integración puede usar el formato XML (fácil de probar y leer) o el formato Proto (más eficiente, pero requiere el esquema.proto). Ambos son interoperables y tienen el mismo contenido.

Casos de uso: CoT se diseñó para representar eventos muy diversos. Además de puntos de posición, puede modelar áreas (polígonos), rutas (polilíneas), trazas de sensores u órdenes de misión como eventos CoT (normalmente con bloques detail más complejos o referencias a archivos externos). ATAK no solo usa CoT para el seguimiento: también lo emplea para enviar mensajes de chat (en cuyo bloque detail aparece, por ejemplo, <chat> con contenido de texto) o activar alarmas. Gracias a la conexión flexible mediante CoT, otros sistemas que hablen el protocolo pueden sumarse a la red sin un complemento ATAK. Por ejemplo, existen plataformas de sensores IoT que publican directamente eventos, como la detección de disparos, en formato CoT para que aparezcan en ATAK.

En resumen, Cursor-on-Target ofrece un formato de datos uniforme basado en eventos para la interoperabilidad en tiempo real entre dispositivos y aplicaciones muy diversos. Su estandarización (existe un esquema XML) y su amplio uso militar y civil en servicios de seguridad y emergencia convierten a CoT en un protocolo clave para sistemas de información situacional. ATAK ha contribuido mucho a popularizar CoT al demostrar la utilidad de un esquema común para intercambiar datos entre todos los participantes.

Diferencias entre ATAK y CivTAK

La versión militar de ATAK y la versión civil de CivTAK se basan en el mismo código y son en gran parte idénticas en funciones. CivTAK se separó de ATAK para ofrecer una versión de distribución libre que organismos civiles, organizaciones y particulares pudieran utilizar sin restricciones de exportación. Técnicamente, solo hay diferencias menores:

• Funciones y complementos disponibles: Algunas funciones específicamente militares no están presentes en CivTAK o vienen desactivadas de forma predeterminada. ATAK (Mil) podría incluir, por ejemplo, complementos adicionales para efectos de armas, sensores militares o radios cifradas que no están disponibles en CivTAK. Según los desarrolladores, la versión militar solo incorpora «pequeños complementos específicos del ámbito militar». Podría tratarse de conjuntos de símbolos o integraciones particulares que no son relevantes para usuarios civiles. Un indicio es que el código público de ATAK-CIV contiene algunas funciones que todavía no son accesibles desde la interfaz (The TAK Ecosystem: Military Coordination Goes Open Source | Hackaday), posiblemente porque solo son relevantes para uso militar. Las funciones principales, como mapas, navegación, CoT e interfaz de complementos, son idénticas.
• Módulos de seguridad: Como se mencionó, CivTAK utiliza únicamente criptografía comercial o permitida públicamente (AES-256 y TLS). No incluye los módulos de cifrado altamente clasificados de la versión militar (p. ej., para proteger información secreta de la OTAN). En CivTAK se recurre a AES y VPN, suficientes para la mayoría de las aplicaciones. ATAK-Mil también podría conectarse a hardware especializado (chips criptográficos y radios seguras); esas interfaces no son útiles en CivTAK y, por ello, se omiten.
• Nombres y simbología: En la comunicación externa, la versión militar de ATAK suele llamarse «Assault Kit», mientras que CivTAK se presenta como «Team Awareness Kit». Dentro de la aplicación, sin embargo, los términos y símbolos son en gran medida iguales. Las unidades militares se representan en CivTAK con los mismos símbolos MIL-STD-2525, aunque la aplicación evita denominaciones relacionadas con el combate. Por tanto, CivTAK no se percibe como una versión «reducida»: es ATAK, oficialmente autorizado para uso civil.
• Versiones y publicación: ATAK (militar) se distribuye a usuarios autorizados mediante TAK Product Center (a través de TAK.gov); CivTAK, en cambio, está disponible abiertamente (descarga en civtak.org, Google Play Store y GitHub). Desde 2020, las versiones de CivTAK suelen aparecer poco después de las de TAK.gov, por lo que ambas siguen ciclos similares. Por ejemplo, ATAK-CIV 4.3 se hizo público poco después de ATAK-Mil 4.3. La publicación como código abierto de ATAK-CIV permite incorporar contribuciones de la comunidad, aunque el TAK Program Office decide qué cambios se incluyen en la compilación oficial.
• Soporte y uso: ATAK-Mil se utiliza sobre todo en ejercicios y operaciones por fuerzas armadas estadounidenses y aliadas. CivTAK tiene una base creciente de usuarios en organismos públicos estadounidenses (bomberos, policía y protección civil) y entre particulares (p. ej., cazadores y excursionistas). Ambas versiones pueden comunicarse entre sí: un equipo de bomberos que usa CivTAK puede compartir una visión de la situación mediante servidores CoT con soldados que usan ATAK (Mil), siempre que empleen las mismas claves de red y certificados.

En conclusión, ATAK y CivTAK son casi equivalentes desde el punto de vista técnico. Por ello, los desarrolladores podrían usar en ATAK militar, con cambios mínimos, complementos creados para CivTAK. La mayor diferencia reside en la distribución y las licencias: CivTAK es de código abierto (en parte de dominio público), mientras que la versión militar de ATAK es Government-off-the-shelf (GOTS) y solo puede utilizarse con autorización. CivTAK basta para la mayoría de los proyectos de desarrollo. Si un complemento debe interactuar con hardware militar muy especializado, habría que colaborar con los desarrolladores de la versión militar.

Recursos de código abierto y SDK

La apertura de ATAK-CIV ha impulsado una comunidad activa de desarrolladores. Existen numerosos recursos de código abierto, SDK y proyectos comunitarios que facilitan los primeros pasos y amplían las posibilidades:

• Código fuente de ATAK-CIV: El código oficial se puede consultar en GitHub (repositorio del Departamento de Defensa) (GitHub – deptofdefense/AndroidTacticalAssaultKit-CIV). Allí también se encuentra un archivo ZIP del SDK de complementos con código de plantilla (GitHub – deptofdefense/AndroidTacticalAssaultKit-CIV). Los archivos README y CONTRIBUTING ofrecen indicaciones sobre el proceso de compilación (GitHub – deptofdefense/AndroidTacticalAssaultKit-CIV). Los desarrolladores pueden estudiar el código para entender funciones poco visibles o detalles de la API. Por ejemplo, hay comentarios sobre TAK Protocol v1 (ProtoBuf) en el código (TAK Protocol Description – Encode and Decode TAK data with Python). Buena parte del código es de dominio público (obra del gobierno estadounidense) o tiene una licencia permisiva, lo que facilita su desarrollo posterior (GitHub – deptofdefense/AndroidTacticalAssaultKit-CIV).
• Servidor TAK (código abierto): El TAK Server también se publicó como código abierto en 2020. El servidor, basado en Java, está disponible en GitHub (The TAK Ecosystem: Military Coordination Goes Open Source | Hackaday) y las organizaciones pueden alojarlo ellas mismas. La comunidad ofrece alternativas más ligeras: FreeTAKServer (FTS), escrito en Python, es un servidor ligero con API REST e instalación sencilla (The TAK Ecosystem: Military Coordination Goes Open Source | Hackaday) (TAK Server open apis: r/ATAK). Taky es otro servidor TAK mínimo (también en Python), por ejemplo para implementaciones en Raspberry Pi (The TAK Ecosystem: Military Coordination Goes Open Source | Hackaday). Estos proyectos son ideales para realizar pruebas o crear integraciones propias mediante API sin depender del gran servidor oficial.
• Documentación y wikis comunitarias: Existen documentos oficiales para usuarios finales, como el manual de ATAK () (), y guías de desarrollo de complementos. La comunidad también mantiene una wiki (CivTAK JumpStart) en Reddit (GitHub – FreeTAKTeam/openTAKpickList: a list of hardware and software to be used in conjunction with ATAK platform) con guías prácticas y preguntas frecuentes. civtak.org incluye una sección de documentación con tutoriales, por ejemplo para crear paquetes de datos (Documentation – CivTAK / ATAK). El equipo FreeTAKTeam (FTS) también publica documentación en su página de GitHub, por ejemplo, sobre el conjunto de símbolos MIL-STD-2525 y los tipos CoT (FTS Documentation) (FTS Documentation), útil para desarrolladores que quieran utilizar símbolos o tipos propios.
• Comunidades de desarrolladores: Hay un intercambio activo en Reddit (r/ATAK) (TAK Server open apis: r/ATAK) y Discord (servidor TAK Community) (Android Team Awareness Kit or ATAK / CivTAK – CivTAK / ATAK), donde los desarrolladores hacen preguntas y comparten soluciones. Desde 2020 también se celebran conferencias anuales OpenTAK (Android Team Awareness Kit or ATAK / CivTAK – CivTAK / ATAK), en las que se presentan nuevos complementos, casos de uso y buenas prácticas.
• Complementos y herramientas de código abierto: Muchos complementos se han publicado con código abierto o se han vuelto a implementar de forma no oficial. Ejemplos: atak-forwarder (GitHub) permite conectar ATAK con módulos de radio LoRa Meshtastic (The TAK Ecosystem: Military Coordination Goes Open Source | Hackaday). HAMMER, el módem acústico para sistemas de radio, se publicó como código para enviar CoT mediante audio (The TAK Ecosystem: Military Coordination Goes Open Source | Hackaday). APRS-TAK conecta ATAK con APRS, el sistema de localización de radioaficionados (The TAK Ecosystem: Military Coordination Goes Open Source | Hackaday). También existen herramientas de visualización y análisis, como TAK Reader para consultar datos CoT sin conexión y TAK Graph para diagnosticar conexiones. La lista openTAK-PickList, mantenida por la comunidad, reúne más de 100 enlaces a recursos, complementos, hardware y tutoriales relacionados con TAK (GitHub – FreeTAKTeam/openTAKpickList: a list of hardware and software to be used in conjunction with ATAK platform) (GitHub – FreeTAKTeam/openTAKpickList: a list of hardware and software to be used in conjunction with ATAK platform). Es un buen punto de partida para obtener una visión general.
• SDK y bibliotecas: Además del SDK oficial de complementos ATAK, existen bibliotecas para procesar datos CoT/TAK en otros entornos. TakProto (Python) permite codificar y decodificar CoT tanto en XML como en formato Proto (dfpc-coe/node-CoT: Javascript Cursor-On-Target Library – GitHub). Node-CoT (JavaScript) ofrece funciones similares para aplicaciones Node.js (About MIL-STD-2525 and CoT – FreeTAKTeam). Para.NET hay analizadores CoT e incluso iniciativas para reproducir partes de las funciones de ATAK (p. ej., WinTAK, una aplicación de Windows proporcionada por el Departamento de Defensa, y una versión comunitaria llamada ITAK (sin relación con iOS), entre otras).
• Mapas y datos: las herramientas de código abierto facilitan la carga de datos geográficos adicionales en ATAK. Por ejemplo, el proyecto ATAK-Maps ofrece una colección de servicios de mapas, entre ellos OpenStreetMap, Google Maps y datos satelitales, que pueden importarse fácilmente como paquete de datos (The TAK Ecosystem: Military Coordination Goes Open Source | Hackaday). OpenElevation también permite incorporar conjuntos de datos (The TAK Ecosystem: Military Coordination Goes Open Source | Hackaday). Esto permite a desarrolladores y usuarios aprovechar todo el potencial del motor de mapas sin depender de datos propietarios.

Con estos recursos, un desarrollador puede trabajar con relativa autonomía en el ecosistema TAK: desde configurar una infraestructura de servidores propia y crear complementos hasta probarlos con otros miembros de la comunidad. La apertura de CivTAK impulsa la innovación: aparecen continuamente nuevos complementos e integraciones que se comparten con la comunidad. Para quienes desean escribir sus propias extensiones, son especialmente valiosos el ATAK Plugin SDK, los ejemplos oficiales y el intercambio con desarrolladores experimentados de complementos. La combinación de una plataforma central estable (ATAK) y la flexibilidad de los complementos de código abierto hace que el sistema sea singular en este ámbito y permite crear aplicaciones complejas de información situacional con relativamente poco esfuerzo.