Tactical Mission Data Sync for ATAK

Start with the Data Layer

Use MongoDB Enterprise Advanced as the trusted data layer for the application. Store mission entities as BSON documents and organize them into collections that match the operational workflow. MongoDB supports different document shapes in the same database. Store position data, map objects, chat messages, alerts, and files without forcing them into one rigid schema.

Take advantage of this flexible document model to build all your application features on one data platform. Use MongoDB to serve dashboards, APIs, command workflows, and downstream systems. Add new mission entities without redesigning the entire database.

Connect the Edge to MongoDB

Use Ditto, an edge synchronization platform, as the edge synchronization partner. The Ditto ATAK Plugin connects ATAK devices to a local-first peer-to-peer mesh. ATAK constitutes the field application for sharing location, map, chat, and mission data. Ditto synchronizes mission data across nearby devices when network access changes or fails.

Then, connect Ditto to MongoDB with the Ditto MongoDB Connector. The connector synchronizes documents between Ditto and MongoDB and resolves concurrent changes between the two systems.

Build on the Data

Run MongoDB Enterprise Advanced locally at the command center. Use the MongoDB data layer to build the command-center dashboard and other mission applications. With the data and access layers in place, focus on application features instead of building separate storage and synchronization services.

Use this pattern to:

• Store varied mission data as documents.

• Connect applications to MongoDB with standard drivers and APIs.

• Integrate with Ditto for disconnected synchronization.

• Expose one shared data layer to command-center applications.

• Extend the application as new mission workflows emerge.

Tactical Edge

The tactical edge, the layer where field devices create and exchange mission data close to the point of action, includes users and devices operating where connectivity may change or fail.

ATAK provides the field application for sharing location, map, chat, and mission data. The Ditto ATAK Plugin captures that data and synchronizes it across nearby devices through the peer-to-peer mesh. Ditto uses available transports such as Bluetooth Low Energy, Wi-Fi, peer-to-peer Wi-Fi, and MANET-compatible paths. Ditto can also relay data across multiple devices in the mesh.

The edge acts as another source of application data. Ditto keeps that data available and moves it between devices. MongoDB stores the synchronized documents and makes them available to command-center applications.

Command-Center Integration

MongoDB Enterprise Advanced provides the central application data layer. The dashboard reads mission data from MongoDB and presents it through maps, node-status views, and communications feeds.

The Ditto MongoDB Connector listens for changes in Ditto and MongoDB. It applies those changes in the other system and keeps the two data stores aligned.

Applications built on MongoDB query and update mission documents without connecting directly to ATAK devices. Ditto handles delivery to and from disconnected edge devices. This integration lets you build the command-center application against MongoDB instead of directly against ATAK devices.

Why This Design Is Resilient

MongoDB stores the mission data. Ditto keeps field devices synchronized. ATAK provides the field application. The connector links both environments and resolves concurrent changes.

This separation lets each technology focus on one responsibility. MongoDB provides the application data layer, Ditto synchronizes data across the tactical edge, and ATAK provides the field experience.

This design allows you to build application features against MongoDB’s document model without implementing a separate storage model for every device or network condition.

Store Location Data in the track Collection

Use the track collection for position and status data from field actors. Query these documents to display current and stale devices on the command-center map.

{
   "_id": "ANDROID-4486046569cda611", // document identifier
   "_r": false,                       // soft-delete flag
   "c": "MDB Actor 2",                // display name
   "d": "ANDROID-4486046569cda611",   // source device
   "e": "MDB Actor 2",                // actor callsign
   "j": 19.451227,                    // latitude
   "l": -99.139832,                   // longitude
   "o": 1776886448640,                // stale time
   "w": "a-f-G-U-C"                   // CoT type
}

The compact schema keeps the synchronized document close to the data produced by ATAK. MongoDB stores the document without requiring a separate relational mapping layer.

Store Messages in the chat Collection

Use the chat collection for messages exchanged between field users and command workflows. The collection uses a different shape from track, with fields for message text, sender, room, and timestamp.

{
   "_id": "b547f0b4-c371-4aff-ac1d-3bafe110a9e1", // message identifier
   "_r": false,                                   // soft-delete flag
   "authorType": "a-f-G-U-C",                     // sender CoT type
   "b": 1776735193948,                            // message timestamp
   "d": "COMMAND-VEHICLE",                        // source device
   "e": "COMMAND",                                // sender callsign
   "msg": "Command",                              // message text
   "room": "Ditto",                               // room name
   "roomId": "ChatContact-Ditto"                  // room identifier
}

MongoDB lets the application store message documents, alongside track documents without adding empty location fields or forcing both entities into the same structure.

Keep Map Objects in the mapitem Collection

Use the mapitem collection for persistent map graphics and shared mission objects.

Use MongoDB’s document model to store each mission entity in the shape your application needs. Keep track, mapitem, and chat in separate collections because they represent different data and access patterns. This approach lets you build map, status, and communications features without forcing all mission data into one rigid schema.

Use each collection for one mission function, and keep all collections in one MongoDB data layer. Add fields or new mission entities without redesigning the existing collections.

Build Against One Flexible Data Layer

Build dashboards, APIs, and command-center workflows against MongoDB. Query each collection according to its purpose, and preserve the document structure that arrives from the edge.

Use this approach to:

• Reduce data transformation between Ditto and MongoDB.

• Keep each mission entity easy to query.

• Add new fields without redesigning unrelated documents.

• Extend the application without creating a separate storage model for every device or workflow.