The company commander waiting on ammunition at a forward patrol base does not know whether her resupply convoy left the brigade support area twenty minutes ago or is still loading. JLOGSTAT shows the stock on hand at brigade level. GCSS-Army has the requisition in the system. But the physical position of the truck carrying her ammunition — and whether it was actually loaded — is unknown until someone gets on the radio. This is the military logistics visibility gap, and it has killed soldiers and failed missions for as long as there have been armies.
A military logistics visibility platform closes this gap by instrumenting every node in the supply chain — depots, staging areas, forward logistics elements, individual vehicles, and containers — with sensors that report asset location and status continuously. The result is a common logistics picture that commanders and S4 staff can query in real time, without waiting for the next radio report or batch database sync.
This article describes the architecture of such a platform, from the sensor layer at the forward line to the enterprise integration layer connecting it to existing military ERPs.
The logistics visibility gap: why JLOGSTAT and GCSS-Army data is stale
JLOGSTAT (Joint Logistics Status and Total Asset Visibility) and GCSS-Army (Global Combat Support System — Army) were designed to provide supply chain visibility, and within their design constraints they do. The problem is that their data models assume a world where logistics events are entered by humans at fixed computer terminals at echelon support areas. A pallet arriving at the brigade support area gets a goods receipt posted when a clerk scans it and confirms receipt. That transaction may happen at the time of physical receipt or it may happen hours later when the clerk catches up with the day's paperwork.
Between the brigade support area and the company, there is often no formal scanning infrastructure at all. The company XO signs a hand receipt. The S4 sergeant enters the transaction the next morning. By the time the data appears in GCSS-Army, the ammunition has already been consumed, the food eaten, and the vehicles refuelled — from a logistics information perspective, the event occurred hours after it happened physically.
The deeper problem is architectural: both systems are batch-oriented. Data flows upward through the logistics reporting chain on scheduled cycles, not in real time. A record that changes at company level must pass through battalion, brigade, and division nodes before it becomes visible at the joint logistics command. At each node, a scheduled job aggregates and uploads. The practical result is that aggregate data at higher echelons is typically 4–12 hours stale, and individual item-level data below brigade support area level may not exist in the system at all.
A military logistics visibility platform does not replace these systems — replacing legacy military ERPs is a decade-long programme of record. Instead, it runs alongside them, providing near-real-time tracking through a separate sensor and data layer, and feeding transactions back into the ERP when an asset reaches a formal scan point.
Sensor layer: RFID passive/active, GPS trackers, BLE beacons
Three sensor technologies cover the range of military logistics tracking requirements, and each has a distinct use case.
Passive RFID (EPC Gen2, ISO 18000-6C) is the workhorse of fixed-point logistics tracking. A passive tag — a paper-thin label costing a few cents — contains a unique 96-bit or 128-bit EPC identifier. When a pallet carrying these tags passes through a portal reader at a depot gate or staging area, the reader energises the tags and collects their identifiers within milliseconds. Portal reads at 3–5 metres range with near-100% read rates on properly tagged pallets are achievable. The tags require no maintenance, no battery, and survive field conditions including dust, moisture, and temperature extremes. The limitation is range: passive RFID cannot track assets in transit between fixed read points.
Active RFID (433 MHz or 2.4 GHz) solves the in-transit tracking problem for medium-range scenarios. An active tag carries its own power source and periodically broadcasts its identifier. Vehicle-mounted readers in convoys can interrogate active tags on all loads within 100–300 metres, providing a running manifest of the convoy's cargo without requiring physical inspection. Active tags suited to defense use cost USD 20–80 each, making them economical for high-value equipment but impractical for consumable supplies. Battery life spans 2–5 years depending on transmission interval.
GPS/satellite trackers provide absolute position anywhere with sky visibility. A hardened GPS tracker mounted under a vehicle hood or on a shipping container reports its position, speed, and heading over cellular, satellite (Iridium/Inmarsat), or tactical radio to the visibility platform backend. The key selection criteria are: backhaul channel availability in the area of operations, battery or vehicle power availability, environmental protection rating (MIL-STD-810), and whether the tracker must function while moving through GPS-contested areas (GNSS anti-jam capability). Tracker selection must balance update cadence against backhaul bandwidth — a tracker reporting every 30 seconds over a 9.6 kbps tactical radio link is too chatty; one reporting every 5 minutes provides adequate resolution for convoy tracking.
BLE (Bluetooth Low Energy) beacons fill the gap where RFID and GPS do not reach: indoor tracking within warehouses, vehicles, and shelters; cold-chain temperature monitoring on individual packages; and high-density item tracking at the platoon level where soldiers carry individual equipment. BLE tags cost USD 3–15, have 1–3 year battery life, and can be read by any smartphone or tablet running the logistics app within 30–50 metre range. For temperature monitoring, integrated sensor tags transmit both identifier and temperature reading, enabling cold-chain visibility without separate sensor infrastructure.
Data aggregation: edge gateway, MANET relay, satellite upload cadence
The forward edge of the supply chain is communications-contested. Cellular coverage may be absent or jammed. Satellite terminals are shared across multiple functions and have limited bandwidth. The data aggregation architecture must handle intermittent and constrained connectivity without losing sensor events.
The forward logistics element (FLE) edge gateway is the first aggregation point for sensor data. It is a rugged compute unit — typically a fanless industrial PC or an embedded system in a transit case — co-located with the FLE or combat trains. It runs RFID readers, receives BLE beacon data from nearby units, and accepts GPS position reports from vehicles in the immediate area. All events are stored locally in a time-series buffer. The gateway maintains a persistent outbound queue: when connectivity is available, it uploads events in chronological order; when connectivity is absent, it continues recording.
Within the tactical area, a MANET (Mobile Ad-hoc Network) provides event relay between gateways and vehicles without requiring a fixed infrastructure backbone. MANET radios — TrellisWare TSM, Silvus StreamCaster, or Persistent Systems Wave Relay — form a self-healing mesh where any node with a path to the backhaul can forward data for nodes that do not. A vehicle with line-of-sight to a gateway relays events from vehicles behind terrain. The visibility platform's relay agent runs on each MANET node, forwarding sensor events toward the nearest upload point using a store-and-forward model that tolerates link interruptions of minutes to hours.
Satellite upload cadence must be configured per operational context. In a high-tempo operation with bandwidth to spare, uploading sensor events every 60 seconds provides near-real-time visibility. In a bandwidth-constrained environment sharing a single VSAT terminal across the formation, batch uploads every 15–30 minutes are more realistic. The platform must handle both modes gracefully, presenting dashboards with clear data-age indicators so operators know whether they are looking at 2-minute-old data or 25-minute-old data.
Platform architecture: ingest, time-series, geospatial, dashboard
The server-side platform follows a layered architecture with distinct components for each function.
The ingest API accepts events from edge gateways via MQTT (preferred for constrained links — compact binary, broker-managed reconnection) and HTTP/REST (for gateways with stable connectivity and existing HTTP toolchains). MQTT topics are structured hierarchically: logistics/{theater}/{echelon}/{unit}/{asset_id}/position for GPS tracks, logistics/{theater}/{echelon}/{unit}/rfid/gate/{gate_id} for RFID portal reads. The ingest layer validates event schemas, deduplicates by event UUID, and writes to the time-series store. Rate limiting per gateway prevents a malfunctioning tracker from flooding the ingest pipeline.
The time-series database stores position tracks and sensor readings. InfluxDB and TimescaleDB are both viable; TimescaleDB is preferred for deployments requiring complex JOINs between sensor events and relational asset registry data — it is a PostgreSQL extension and supports full SQL. Retention policies automatically downsample old data: full-resolution data (one record per event) is kept for 30 days, then downsampled to one record per 5 minutes for 6 months, then to one per hour thereafter. This keeps storage costs manageable while preserving operational records for after-action analysis.
The geospatial layer runs on PostGIS. It stores logistics installation geometries (depot boundaries, staging area polygons, forward operating base perimeters), route networks, and geofence definitions. The geofence engine evaluates incoming GPS positions against these geometries and fires events when an asset enters or exits a zone — "convoy entered the brigade support area perimeter" triggers an automatic goods receipt in the ERP without requiring a clerk to scan individual tags. PostGIS spatial functions also power the "find all assets within X km of this grid" queries that S4 staff use for ad-hoc logistics planning.
The web dashboard presents the logistics common operating picture. It combines a MapLibre GL map layer (showing asset positions, convoy routes, and logistics node overlays) with tabular views for supply status, days-of-supply calculations, and pending resupply requests. Role-based access control ensures company S4 staff see only their unit's assets while brigade G4 sees the full formation picture. The dashboard is designed to function on low-bandwidth connections — vector map tiles instead of raster imagery, server-side pagination for large asset lists, and delta updates rather than full page refreshes.
TAK integration: logistics tracks on the tactical COP
One of the most operationally impactful integrations is pushing logistics asset tracks into ATAK (Android Team Awareness Kit) and CloudTAK, placing supply vehicles and containers on the same common operational picture that tactical commanders use for friendly force tracking.
The integration uses the CoT (Cursor on Target) protocol. The visibility platform runs a CoT publisher that queries asset positions from the time-series database and publishes them as CoT XML events to the TAK server. Each logistics vehicle becomes a CoT entity with a unique UID, a type code indicating its logistics role (the MIL-STD-2525 type hierarchy includes dedicated codes for supply, fuel, and maintenance vehicles), and detail fields containing load status, destination, and estimated time of arrival.
Configuration considerations: logistics tracks should be published to a separate TAK data package or map layer so tactical operators can toggle logistics visibility without cluttering the display with supply vehicles during a contact. Stale tracks — assets that have not reported a position update within the configured threshold — should be automatically removed from the COP rather than persisting at their last known location indefinitely, which creates false situational awareness.
For units using ATAK on Android tablets in vehicles, the logistics app and the ATAK CoT feed can run simultaneously on the same device, providing the driver with both turn-by-turn route navigation from the logistics platform and full tactical COP awareness from ATAK.
Predictive logistics: consumption modelling and automated resupply triggers
A visibility platform that only shows where assets are is useful. One that predicts when they will run out and automatically initiates resupply is transformative.
Consumption rate modelling works from issue transaction history. Every time a logistics event records a unit receiving fuel, ammunition, rations, or other Class of Supply, the platform updates that unit's consumption rate rolling average. The simplest model uses a 72-hour rolling window: if 3rd Platoon has consumed 180 litres of fuel in the past 72 hours, their consumption rate is 60 litres per day. With 120 litres remaining on hand, their days-of-supply estimate is 2 days.
More sophisticated models ingest operational tempo data to improve prediction accuracy. Vehicle kilometres driven is a strong predictor of fuel consumption. Number of personnel at the position predicts ration consumption. Rounds-fired data from the fire control system predicts ammunition resupply requirements. Where these data sources are available via API, the visibility platform can correlate them against actual consumption data to calibrate unit-specific consumption models.
Automated resupply triggers fire when days-of-supply estimates fall below commander-set thresholds. A trigger configured at "2 days of Class III (fuel)" automatically generates a pre-filled resupply request in the ERP system and sends an alert to the S4 duty officer. The request includes the requesting unit, required quantity, delivery location (from the unit's last known GPS position), and urgency classification. The S4 can approve and release the request with a single action, or modify it before release. The goal is to replace the reactive "we're out of fuel, send a truck now" call with a proactive "you will be out of fuel in 48 hours, here is a pre-staged resupply request" workflow.
Route optimization under threat integrates threat overlays from the tactical COP — enemy activity reports, no-go areas, known IED threat routes — into convoy route planning. The platform's routing engine uses a modified Dijkstra algorithm with threat-weighted edge costs to propose routes that balance speed against risk exposure, subject to hard constraints (no-go zones, bridge weight limits, vehicle clearance restrictions). Proposed routes are presented to the convoy commander for approval rather than being executed automatically — human authority over route selection is preserved.
Cold chain and sensitive items: temperature monitoring and chain of custody
Certain supply categories require tracking beyond simple location: medical consumables, vaccines, blood products, and some munitions have temperature sensitivity requirements, and sensitive items (cryptographic equipment, certain weapons systems, classified materiel) require unbroken chain of custody records.
For cold-chain monitoring, BLE temperature sensor tags attached to refrigerated containers or individual package groups transmit temperature readings every 5–15 minutes to the nearest BLE-capable gateway. The platform applies configurable alert thresholds per item category: plasma products alert if stored above 6°C for more than 10 minutes; certain vaccines alert if the temperature drops below 2°C (freeze damage). Excursion events are logged with precise timestamp and GPS location, and the affected items are flagged in the logistics dashboard for inspection before issue. This data is preserved for chain-of-custody audit and regulatory compliance.
For sensitive item tracking, the platform enforces dual-custody verification at every transfer point. A transfer event requires NFC or RFID scan of both the item and the receiving individual's ID credential, plus biometric or PIN confirmation if the platform is configured for high-assurance custody. The resulting custody record — item UID, transferring custodian, receiving custodian, timestamp, GPS location, and witness confirmation — is cryptographically signed and stored in an append-only audit log. Attempts to modify or delete custody records are rejected. The audit log can be exported in formats accepted by CID (Criminal Investigation Division) and Inspector General investigations.
Integration with military ERP: GCSS-Army, ILMS-USMC, SAP Defense
The visibility platform's value multiplies when it feeds real-time event data back into the authoritative ERP systems that the logistics enterprise depends on for requisitioning, financing, and end-of-year accountability.
The integration architecture uses a bidirectional API bridge that runs as a microservice between the visibility platform and the ERP. It maintains a mapping table between visibility platform asset identifiers and ERP object numbers, handles authentication to both systems, and translates between the visibility platform's event model and the ERP's transaction model.
GCSS-Army exposes a web services interface (SOAP and increasingly REST) through which transactions can be submitted programmatically. The bridge maps geofence entry events (asset arrived at BSA) to goods receipts, geofence exit events (convoy departed FOB) to goods issues, and RFID portal reads to transfer orders between storage locations. Errors from GCSS-Army (duplicate transaction, unknown material number) are routed back to the visibility platform dashboard for human resolution rather than being silently dropped.
ILMS-USMC (Integrated Logistics Management System for the Marine Corps) uses a similar transaction-based API. The bridge configuration differs in transaction codes and field mappings but the integration pattern is identical.
SAP Defense (the commercial ERP used by several NATO allies) exposes logistics transactions via BAPI (Business Application Programming Interface) function modules for synchronous operations and via IDocs (Intermediate Documents) for asynchronous bulk transfers. The bridge uses BAPIs for time-sensitive transactions (goods receipts on convoy arrival) and IDocs for batch reconciliation at end of day. SAP's OData API layer, available in S/4HANA, simplifies newer integrations considerably.
In all three cases, the integration philosophy is the same: the visibility platform is the system of engagement — it captures real-world logistics events in near real time — while the ERP remains the system of record — it holds the authoritative inventory, financial, and accountability data. The bridge keeps both in sync, eliminating the manual re-entry that currently causes most of the data quality problems in military logistics information systems.
Key insight: The highest-value capability of a military logistics visibility platform is not tracking — it is the time saved by eliminating manual data entry at transfer points. A brigade that processes 200 logistics transactions per day, each requiring 3 minutes of clerk time, recovers 10 person-hours daily. Over a 180-day deployment, that is 1,800 person-hours of S4 clerk time redirected to higher-value work.