Aug 30, 2024

ATAK Plugins 2: The TAK Server

he article explores the Android Team Awareness Kit (ATAK) and TAK Server, detailing its architecture, features, and setup using SitX and Node-RED.

The Android Team Awareness Kit (ATAK) ecosystem has revolutionized situational awareness for military and first responder operations. At the heart of this ecosystem lies the TAK Server, a powerful tool that facilitates communication and data sharing between multiple TAK clients, including ATAK, WinTAK, and iTAK.

In this month’s edition Drone Software Meetup, Godfrey Nolan, President, RIIS LLC. tackled demystifying the TAK Server. Feel free to watch the meetup video or follow the tutorial for a deep dive into the workings of TAK Server, its key features, and a demonstration of a basic messaging pipeline using Node-RED.

Our Goals

First, we’re going to send a message to TAK, evaluate the message to see what’s under the hood, and then get that message to display on multiple ATAKs. That’s it! BUT it’s deceptively simple in theory and much more nuanced in practice. There’s a lot of background to cover first, so get ready for a crash course.

💡 We’re going to be working on Windows via WSL for this tutorial.

Key Features of TAK Server

So what is TAK Server and what are its benefits? Glad you asked! Here’s a bulleted list with all the features:

Centralized Data Management: TAK Server provides a centralized storage solution for mission data, ensuring that all connected clients have access to the most up-to-date information.
Real-time Updates and Synchronization: As new data is received or changes are made, TAK Server instantly broadcasts these updates to all connected clients, maintaining a consistent operational picture.
Versatile Data Sources: TAK Server can receive and distribute data from various sources, including ATAK clients, IoT sensors, and other integrated systems.
Communication and Collaboration: The server facilitates text, voice, and video communications between different TAK clients, enhancing team coordination.
Security and Access Control: TAK Server implements robust security measures, including encrypted data transmission and role-based access control, ensuring that sensitive information remains protected.

TAK Server Architecture

The TAK Server architecture consists of several components working together to provide a seamless experience for users:

Databases: Store mission data, user information, and other relevant details.
APIs: Enable integration with external systems and custom applications.
Plugins: Extend the server’s functionality to meet specific operational requirements.

TAK Server supports various deployment models, including cloud-based, on-premises, and federated server configurations. This flexibility allows organizations to choose the most suitable setup based on their specific needs and security requirements.

Setting Up a Basic TAK Server Environment

For this demonstration, we’ll use SitX (Situational Awareness Tool) by PAR Government, which provides a cloud-based TAK Server solution. While setting up a full-fledged TAK Server from scratch can be complex, SitX offers a straightforward way to get started.

Example of Sit(X) server

Configuring ATAK Clients Using SitX

To connect ATAK clients to our SitX server:

Install the ATAK app from Google Play.
Install the SitX app from Google Play.
Log into the SitX app using your credentials.
Download the Android configuration file from the SitX content folder.
Import the configuration file into the ATAK app.

Then you will be automatically connected to the SitX server. This process is way more streamlined than setting up the server yourself, but just be aware you have the option to build it from the ground up yourself.

Creating a Message Pipeline with Node-RED

Our basic message pipeline will consist of several key nodes. First, the Inject node is used to manually trigger our JSON message. Following this, the TAK node converts our JSON into CoT XML format. Finally, the SitX Bridge Adapter node sends the message to our TAK Server.

Now that we understand the flow, let’s start installing all the required software so we start building that message pipeline!

Installing Node-RED and Required Modules

Crack your knuckles and get ready to do a lot of command line installs :)

$sudo apt update
$sudo apt-get update
$sudo apt install nodejs npm
$sudo npm install -g n
$sudo n latest
$sudo apt-get install python3.6
$sudo apt install python3-pip
$sudo apt install openjdk-8-jdk
$sudo apt install maven
$sudo npm install -g –unsafe-perm  node-red
$ mkdir NodeRedProject
$ cd NodeRedPorject
$ git clone https://github.com/PAR-Government/node_red_sitx_bridge_adapter.git
$ npm install --no-audit --no-update-notifier --no-fund --save --save-prefix=`pwd` --production --engine-strict ./node_red_sitx_bridge_adapter
$vim

That last command should open up a new settings.js file. Copy the following JSON into the file and change userDir to your directory:

module.exports = {
    credentialSecret: false,
    flowFile: "current_iot_flow.json",
    flowFilePretty: true,
    userDir: <”/home/admin/RIIS/NodeRedProject”>,
    uiPort: process.env.PORT || 1880,
     logging: {
         console: {
             /** Level of logging to be recorded. Options are:
              * fatal - only those errors which make the application unusable should be recorded
              * error - record errors which are deemed fatal for a particular request + fatal errors
              * warn - record problems which are non fatal + errors + fatal errors
              * info - record information about the general running of the application + warn + error + fatal errors
              * debug - record information which is more verbose than info + info + warn + error + fatal errors
              * trace - record very detailed logging + debug + info + warn + error + fatal errors
              * off - turn off all logging (doesn't affect metrics or audit)
              */
             level: "trace",
             metrics: false,
             audit: false
         }
     },
     exportGlobalContextKeys: false,
     externalModules: {
     },
    editorTheme: {
        palette: {
        },
        projects: {
            enabled: false,
            workflow: {
                mode: "manual"
            }
        },
        codeEditor: {
            lib: "ace",
            options: {
                theme: "vs",
            }
        }
    },
    functionExternalModules: true,

    functionGlobalContext: {
    },
    debugMaxLength: 1000,
    mqttReconnectTime: 15000,
    serialReconnectTime: 15000,
}

Okay, deep breath, save that and we’ve got some more command line. First, we’re going to create a current_iot_flow.json file

$touch

And then finally:

$sudo npm install .
$node-red -s settings.js
$sudo npm install /<ProjectDirectory>

💡 If you ever want to restart and void everything you have, just delete the contents of current_iot_flow.json

Configuring the SitX Bridge Adapter

To connect Node-RED to our SitX server, we need to configure the SitX Bridge Adapter. In your Node-RED flow, add a SitX Bridge Adapter node and configure it with the following information:

Name: A descriptive name for your node
GroupURI: The URL of your SitX group
AccessKey: Your SitX Bridge Adapter Access Key ID
SecretKey: Your SitX Bridge Adapter Secret Key

Here’s a simple JSON message we can use to test our pipeline:

{  "event": {    
			"_attributes": {      
					"version": "2.0",      
					"uid": "11111112",      
					"type": "b-m-p-s-m",      
					"how": "m-g",      
					"time": "2024-08-23T18:25:43.511Z",      
					"start": "2024-08-23T18:25:43.511Z",      
					"stale": "2024-08-23T18:26:43.511Z"    
					},    
					"point": {      
							"_attributes": {        
									"lat": 42.483599,        
									"lon": -83.174248,        
									"ce": "9999999",        
									"hae": "9999999",        
									"le": "9999999"      
									}    
							},    
							"detail": {      
									"usericon": {
					        "_attributes": {          
							        "iconsetpath": "iconsetpath"        
							    }      
							},      
							"color": {        
									"_attributes": {          
									"argb": -16744448        
									}      
							}    
					}  
			}
	}

This message represents a simple marker with location and styling information. When sent through our pipeline, it will appear on the ATAK clients connected to our TAK Server.

Implementing the Pipeline in Node-RED

Before we even get started on our pipeline make sure you have the following nodes installed:

Now we can get started building the pipeline.

Add an Inject node to your Node-RED flow.
Add a Function node and paste the JSON message into it, wrapping it with msg.payload = [JSON object]; from above.
Add a TAK node from the node-red-contrib-tak package.
Add a SitX Bridge Adapter node configured with your SitX server details.
1. Now, you can use the Access Key ID, the Secret Key, and the Group URL.
2. Once you have that you can click on the node and configure it.
Connect the nodes in the order: Inject -> Function -> TAK -> SitX Bridge Adapter.

When you deploy this flow and trigger the Inject node, the message will be converted to CoT XML and sent to your SitX server, which will then distribute it to connected ATAK clients.

Anatomy of a COT Message

Now, we can send COT messages to the server, but what is a COT message anyway? It stands for Cursor-on-Target message and you can find our more about it in this PDF file from MITRE. For brevity let’s break one down here.

event: This is the root element of a CoT message and contains all the information about the event being communicated. It includes various attributes like:
1. version: The schema version of the event instance.
2. uid: A globally unique identifier for the event.
3. type: A hierarchically organized string that provides a hint about the event type.
4. time: The timestamp when the event was generated.
5. start: The start time when the event should be considered valid.
6. stale: The time after which the event should no longer be considered valid.
detail: This is an optional element used to hold additional information or sub-schema data. The detail field can include various extensions to the basic CoT schema, allowing more specific data to be captured.
point: This element contains geographic information about the event:
1. lat: Latitude of the event location.
2. lon: Longitude of the event location.
3. hae: Height above the ellipsoid, representing elevation in meters.
4. ce: Circular error, which represents the uncertainty in the latitude and longitude coordinates.
5. le: Linear error, representing the uncertainty in the altitude.

Time to Test the Server

Let’s test our pipeline. Hit the inject button and if everything worked as intended we should see something like the following on the TAK devices.

Take note of the id 111111112

You can see between callsign BATEY and callsign BANDWAGON both have the 111111112 id in their separate TAK displays.

Conclusion

You have completed an essential step in your journey to mastering ATAK and the TAK Server. You've explored how the TAK Server centralizes data management, provides real-time updates, and facilitates secure communication among TAK clients. The tutorial walked you through setting up a basic TAK Server environment using SitX, configuring ATAK clients, and creating a messaging pipeline with Node-RED. You also delved into best practices for deploying a TAK Server, ensuring security, scalability, and redundancy. By understanding the structure of Cursor-on-Target (CoT) messages and their role in operational coordination, you are now well-equipped to deploy and utilize the TAK Server effectively, ensuring improved team coordination and mission success. Great job!