Enterprise motor carriers operating 250+ power units face increasing pressure to extract maximum utilization from assets while maintaining service levels. This installment of the Applied AI for Enterprise Motor Carriers Systems Playbook examines the integration of real-time telematics ingestion, mixed-integer linear programming (MILP) for dispatch optimization, and automated straight-through processing pipelines for billing. These three technical pillars form the foundation of modern carrier operations platforms.
Strong Tower Consulting has guided numerous asset-based carriers through the architectural decisions required to move from legacy TMS platforms (Truckmate, McLeod, TMW) to systems that treat data as a real-time operational asset rather than a post-event record. Founded in Minnesota in 2008 by Scott Elliott, Strong Tower Consulting, LLC remains an independent advisor focused exclusively on systems architecture and process optimization for the trucking industry.
Real-Time Telematics Ingestion Architecture
The first requirement for any AI-augmented dispatch system is a robust, fault-tolerant ingestion layer capable of handling ELD, GPS, and engine data streams. Modern carriers typically receive 4-12 messages per truck per minute during active operation.
A production-grade architecture uses Apache Kafka or AWS Kinesis to decouple producers (telematics providers) from consumers (optimization engines and billing systems). Raw messages are persisted to cold storage (S3 or Azure Blob) in original format while normalized events are written to a time-series database optimized for fleet telemetry (InfluxDB or TimescaleDB).
Key SQL schema considerations for the normalized position table include:
CREATE TABLE telematics_position (
event_id UUID PRIMARY KEY,
truck_id VARCHAR(20) NOT NULL,
driver_id VARCHAR(20),
event_ts TIMESTAMPTZ NOT NULL,
latitude NUMERIC(9,6),
longitude NUMERIC(9,6),
speed_mph SMALLINT,
heading SMALLINT,
odometer NUMERIC(12,1),
fuel_gallons NUMERIC(8,3),
engine_hours NUMERIC(10,2),
source_system VARCHAR(20),
processed_ts TIMESTAMPTZ DEFAULT NOW()
);
CREATE INDEX idx_telematics_truck_time ON telematics_position (truck_id, event_ts DESC);
Mixed-Integer Linear Programming for Dispatch Optimization
Static dispatch boards have been replaced by optimization engines that solve the vehicle routing problem with time windows (VRPTW) under live constraints. The mathematical formulation used by leading carriers is a MILP model solved with commercial solvers (Gurobi, CPLEX) or open-source alternatives (HiGHS, SCIP).
Core decision variables include:
- xijt = 1 if truck i serves load j departing at time t
- yik = 1 if truck i is assigned to driver k
- zjl = 1 if load j is covered by lane rate l
Objective function minimizes total cost = (fuel + driver wages + maintenance + opportunity cost) while satisfying hard constraints for hours-of-service, equipment type, and delivery windows. Real-time telematics updates trigger incremental re-optimization every 4-12 minutes.
| Approach | Loaded Miles % | Deadhead % | Driver HOS Utilization | Compute Time (sec) |
|---|---|---|---|---|
| Manual Dispatch (McLeod/TMW) | 71.4% | 18.2% | 64% | N/A |
| Rule-Based Heuristic | 79.8% | 12.6% | 73% | 3.2 |
| MILP + Column Generation | 87.3% | 7.9% | 81% | 41 |
| MILP + Real-time Replan | 89.1% | 6.4% | 84% | 18 |
Straight-Through Billing and Settlement Pipelines
Once optimization and execution are complete, the final link is an event-driven billing pipeline that processes EDI 214 status updates, calculates accessorials (detention, fuel surcharge, lumper fees), and generates EDI 210 invoices without human intervention.
The pipeline subscribes to the same Kafka topic used by the telematics layer. When a delivery is confirmed (EDI 214 with status "X1" or equivalent), the system joins shipment data from the TMS (Truckmate, McLeod, or TMW), rate matrix, fuel surcharge tables, and driver settlement rules to produce both the customer invoice and driver pay record in a single transaction.
Critical integration points include:
- EDI 204 load tender acceptance/rejection logic
- Real-time fuel surcharge calculation using EIA weekly averages or carrier-specific tables
- Automated detention billing based on telematics-derived arrival and departure timestamps
- Driver escrow and settlement engine that respects per-load and weekly advance rules
Exception Management and Human-in-the-Loop Design
No optimization system is perfect. The most successful carriers implement exception thresholds that route only high-impact deviations to human planners. Typical thresholds include loads more than 45 minutes outside delivery windows, equipment type mismatches, or revenue opportunities exceeding $450 in margin variance.
These exceptions are surfaced through a purpose-built React dashboard that displays the MILP-generated recommendation alongside the constraint that triggered the exception, allowing planners to accept, modify constraints, or override with full audit trail.
Implementation Roadmap for Enterprise Carriers
Carriers currently running McLeod, TMW, or Truckmate should follow this phased approach:
- Establish unified telematics ingestion layer (8-10 weeks)
- Build operational data store with SQL data mining capabilities (6 weeks)
- Implement MILP optimization service with initial static model (12 weeks)
- Add real-time re-optimization and exception workflow (10 weeks)
- Deploy straight-through EDI 210/214/204 processing (8 weeks)
Frequently Asked Questions
How long does it typically take to achieve positive ROI on a MILP dispatch optimization project?
Most carriers see measurable improvements in loaded-mile percentage within 90 days of production deployment. Full payback on the systems integration investment generally occurs between 7 and 11 months for fleets operating 300+ trucks, driven primarily by deadhead reduction and improved driver utilization.
Can this architecture work with our existing McLeod or Truckmate TMS?
Yes. The architecture is deliberately TMS-agnostic. We extract necessary data via SQL views or API, run the optimization, then write optimized dispatch recommendations back into the TMS dispatch board through its native interface or database procedures. No core TMS replacement is required.
What telematics providers are supported in the ingestion layer?
The reference architecture currently supports Samsara, Geotab, Omnitracs, PeopleNet, and Motive through native connectors. Additional providers can be added through a generic JSON-to-Kafka adapter within 2-3 weeks.
How are fuel surcharges and detention handled in the straight-through billing pipeline?
Both are calculated automatically using carrier-specific rate matrices stored in PostgreSQL. Fuel surcharges reference either a weekly EIA index table or a custom carrier table keyed by region and fuel type. Detention logic uses actual in/out timestamps from telematics to calculate billable hours above free time, then applies the appropriate accessorial rate.
Strong Tower Consulting, LLC and Exspeedite LLC are separately organized sister companies under common ownership. Carriers never have to buy our software. Our only product is better decisions.