Applied AI for Enterprise Motor Carriers: Systems Playbook Part 21 | Strong Tower Consulting

Enterprise motor carriers operating 250+ power units face increasing pressure to move from reactive dispatch models to mathematically optimized, event-driven operations. 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 straight-through processing pipelines for billing. These three pillars form the technical foundation for next-generation carrier operations platforms.

Strong Tower Consulting has spent more than 18 years helping asset-based carriers modernize their technology stacks. 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

Modern fleet systems require sub-second ingestion of ELD, GPS, engine, and sensor data. The reference architecture uses Apache Kafka as the primary event backbone with schema registry enforcement for strict typing of position reports, fault codes, and driver status events.

Raw messages from Samsara, Geotab, or Motive are normalized through a stream processor (typically Flink or Spark Streaming) before landing in both a time-series database (InfluxDB or TimescaleDB) and an operational SQL Server or PostgreSQL instance. The normalized schema includes:

• position - latitude, longitude, speed, heading, odometer, event_timestamp
• engine - fuel_rate, engine_hours, coolant_temp, fault_codes (J1939 DM1)
• driver - driver_id, hos_status, cycle_used, break_remaining

This ingestion layer feeds both the MILP optimizer and the exception management engine. Late or missing data is flagged within 30 seconds using Kafka Streams windowed aggregations and written to an exceptions queue for immediate carrier intervention.

Mixed-Integer Linear Programming for Dispatch Optimization

The core of the dispatch decision engine is a MILP formulation solved with commercial or open-source solvers (Gurobi, CPLEX, or HiGHS). The objective function minimizes total cost while respecting hard constraints on hours-of-service, equipment availability, and customer delivery windows.

A simplified formulation includes:

• Decision variables: x_ij (binary - whether load i is assigned to driver/tractor j), t_ij (continuous - start time)
• Objective: minimize Σ (linehaul_cost + fuel_cost + detention_cost + layover_cost)
• Constraints: driver HOS compliance, trailer type compatibility, delivery time windows, maximum driving distance per shift

The model is re-solved every 5-15 minutes as new telematics events arrive. Incremental solving techniques (warm starts) reduce computation time from minutes to seconds for large fleets.

Straight-Through Billing and Settlement Pipelines

Once a load reaches delivered status (confirmed via telematics geofence crossing and EDI 214), the system triggers an automated billing workflow. The pipeline performs the following steps without human intervention in greater than 87% of transactions:

1. Validate load data against EDI 204 original tender and any change orders
2. Calculate accessorials (detention, fuel surcharge, lumper, tarp) using carrier-specific rate matrices stored in SQL
3. Apply driver settlement rules (percentage of linehaul, fuel bonus, accessorial splits)
4. Generate EDI 210 invoice and internal AR batch
5. Post driver payable to the settlement system (Truckmate, McLeod, or TMW)

The SQL schema for rate application typically joins the load fact table to a carrier_rate_matrix table that supports both mileage and flat-rate tariffs with effective date ranges. Fuel surcharge logic references the weekly DOE national or regional index plus the carrier-specific base and margin.

Exception Management and Human-in-the-Loop Design

Not every load can be fully automated. The exception engine uses rule-based and lightweight ML models to surface only high-impact deviations. Common exception types include:

• HOS critical (less than 30 minutes remaining before violation)
• Geofence breach or significant route deviation
• Detention exceeding 2 hours without customer confirmation
• MILP solution infeasibility requiring manual load rebalancing

These exceptions are routed to carrier-specific work queues built in Microsoft Power Apps or custom React interfaces that display both the optimization recommendation and the raw telematics history.

Integration Patterns with Legacy TMS Platforms

Most enterprise carriers continue to run Truckmate, McLeod, or TMW as the system of record for order entry, driver settlement, and accounting. The AI operations layer operates as an augmentation layer through:

• Real-time SQL Server change data capture (CDC) for new orders
• EDI 204/990/214/210 transaction lifecycle events
• Direct stored procedure calls for driver settlement and fuel tax posting
• Nightly reconciliation of dispatched vs. billed loads

This hybrid architecture allows carriers to adopt advanced optimization without a full TMS rip-and-replace project.

Implementation Roadmap

Carriers should follow a phased approach:

1. Phase 1 (0-3 months): Telematics normalization and real-time data lake
2. Phase 2 (3-6 months): MILP model development and offline testing against historical loads
3. Phase 3 (6-9 months): Exception management dashboard and straight-through billing for simple loads
4. Phase 4 (9-12 months): Production parallel run with shadow dispatch, then full cutover

Frequently Asked Questions

Enterprise carriers ready to move beyond spreadsheet dispatch and manual billing should begin with an independent systems assessment. Strong Tower Consulting, LLC and Exspeedite LLC are separately organized sister companies under common ownership. Our only product is better decisions.