Fleet Management Software for Military Vehicles: Architecture and Requirements

Military fleet management is a fundamentally different problem from commercial fleet management. A commercial logistics company tracks trucks on highways with continuous cellular connectivity. A military formation tracks armored vehicles, fuel tankers, and engineering equipment across terrain with intermittent or no connectivity, under electromagnetic emission control (EMCON) constraints, with adversaries actively attempting to locate and target the very data infrastructure that makes tracking possible.

The software architecture for military fleet management must accommodate these constraints from the ground up — not as afterthoughts bolted onto a commercial platform. This article covers vehicle tracking in contested environments, maintenance and readiness management, fuel consumption monitoring, integration with logistics chains, and the offline-first architecture that makes the system work when communications fail.

Vehicle Tracking Under EMCON

Position reporting is the foundation of fleet management, but military vehicle tracking cannot simply transmit continuous GPS fixes. EMCON (Emission Control) procedures restrict radio transmissions to prevent the enemy from locating vehicles by their radio emissions. A fleet management system that requires frequent transmissions to maintain position accuracy would force commanders to choose between situational awareness and force protection.

The architectural solution is store-and-forward reporting with variable reporting intervals. Each vehicle carries an onboard unit (OBU) — typically a ruggedized computer with GPS, inertial navigation, and a tactical radio interface — that logs position, speed, heading, and vehicle telemetry continuously. Transmission occurs on a schedule or on command: every 15 minutes during normal operations, every 5 minutes during active movement, or suppressed entirely under strict EMCON. When transmission occurs, the OBU sends a compressed position history rather than a single current fix, giving the backend a complete movement track for the reporting period.

The position data format matters. Military fleet tracking systems encode position using MGRS (Military Grid Reference System) or WGS-84 with appropriate precision for the operational scale. Position reports typically follow the NFFI (NATO Federation Framework Interface) track format or CoT (Cursor on Target) XML for interoperability with C2 systems that display vehicle icons on the common operational picture.

Onboard Unit Architecture

The OBU runs a local database (typically SQLite) that stores the position log, vehicle maintenance record, fuel consumption data, and cargo manifest. All data is logged locally first; transmission to the fleet management server is secondary. This offline-first design means the OBU continues to function as a vehicle-level record even if the fleet management server is unreachable for days.

When connectivity is restored — via radio, satellite modem, or physical data transfer at a maintenance depot — the OBU synchronizes with the fleet management server using a conflict-free replication strategy. The OBU is authoritative for its own vehicle's data; the server aggregates data from all OBUs in the formation. Conflict resolution uses the OBU timestamp as the authoritative source for position and telemetry, with the server's master maintenance record taking precedence for maintenance status updates initiated by maintenance personnel.

OBU hardware must meet MIL-STD-810 environmental requirements for shock, vibration, temperature range, and humidity — conditions that commercial vehicle telematics hardware does not survive. Processing power is typically an ARM Cortex-A or x86 embedded SoC running a hardened Linux distribution. Storage uses industrial-grade eMMC or an M.2 SSD rated for extended temperature operation, not consumer-grade NAND flash.

Maintenance and Readiness Tracking

Vehicle readiness — whether a vehicle is available for operations, in scheduled maintenance, awaiting parts, or deadlined (non-operational) — is the metric that commands most care about. A battalion commander needs to know not just how many vehicles are in the formation, but how many are mission-capable at any given moment.

Maintenance tracking in military fleet software follows the Army Maintenance Management System (TAMMS) data model or its NATO equivalent. Each vehicle has a maintenance record comprising: scheduled service intervals (based on kilometer or hour meters), fault history (technician-recorded faults and corrective actions), current operational status (FMC — fully mission-capable, PMC — partially mission-capable, or NMC — non-mission-capable), and parts on order.

The fleet management software presents maintenance status as a readiness dashboard — a real-time view of the entire fleet's FMC/PMC/NMC breakdown, with drill-down to individual vehicles, fault history, and pending maintenance actions. Predictive maintenance capabilities analyze OBU telemetry — engine temperature, transmission fluid pressure, brake system wear indicators — to flag vehicles approaching maintenance thresholds before they fail.

Fuel Consumption Monitoring

Fuel is the most consumed military supply. A mechanized battalion conducting sustained operations burns thousands of liters of diesel per day across its vehicle fleet. Tracking fuel consumption per vehicle, reconciling against fuel issues from supply points, and projecting future fuel requirements are core fleet management functions.

OBU fuel monitoring integrates with the vehicle's J1939 CAN bus, which exposes engine parameters including fuel consumption rate, total fuel consumed since last service, and fuel tank level. These parameters are logged at configurable intervals. The fleet management backend aggregates per-vehicle fuel consumption to compute formation-level consumption rates, reconcile against supply records, and project resupply requirements.

Fuel issue transactions — recording when a vehicle was refueled, by what amount, from which supply point — are recorded via the fleet management application on a mobile device at the fuel point. These records sync to the fleet management server and are matched against OBU consumption telemetry for discrepancy detection. Large discrepancies between reported fuel issues and telemetry consumption indicate either a fuel accountability problem or a vehicle fault.

Integration with Supply Chain Systems

Fleet management software does not operate in isolation. It must exchange data with the broader logistics chain: the supply system that issues spare parts, the maintenance ordering system that initiates work orders, and the higher-echelon logistics C2 system that allocates maintenance teams and recovery vehicles across the formation.

Integration uses standard military logistics data formats where available — DLMS (Defense Logistics Management Standards) transactions for parts requests and receipts, NFFI logistics messages for vehicle status reporting to higher echelon. Where standard formats are not available, integration uses REST APIs with JSON payloads, with the fleet management server acting as the integration hub.

Parts availability integration is particularly valuable: when a technician records a fault requiring a specific part, the fleet management system can query the supply system for parts availability at nearby supply points, generate a requisition automatically, and track the requisition status. This closes the loop between fault identification and parts delivery, reducing the time vehicles spend NMC waiting for parts.