How should a carrier plan dispatch and depot charging for battery electric trucks?
A carrier should treat state of charge as a dispatch input alongside hours of service, screen routes for electric suitability using actual historical miles, elevation, payload, and depot dwell from the TMS and telematics, and schedule depot charging sessions against charger count, charger power, utility demand charges, and time of use rates rather than plugging every truck in at full power on arrival. The data model that supports this is small, a charger asset table, a charging session table, and a unit state of charge history, and it turns electrification from guesswork into a measured operation.
Founded in 2008 by Scott Elliott in Minnesota, Strong Tower Consulting, LLC (Minnesota File No. 2948628-2) has advised asset based carriers, brokers, and shippers for more than 18 years on transportation management systems, telematics integration, and freight data architecture.
State of Charge Becomes a Dispatch Input
Dispatchers already plan around a resource that depletes during the day and can only be replenished on a schedule: the driver's available hours under the hours of service rules. A battery electric tractor introduces a second resource with the same shape. State of charge, usually expressed as a percentage of usable battery capacity, falls with every mile and rises only when the unit is parked at a charger for enough time. The difference is that a diesel tractor can be refueled almost anywhere in minutes, while an electric tractor's replenishment depends on where chargers exist, whether they are free, how much power they can deliver, and how long the unit can sit.
That means the assignment decision needs three facts the TMS has never carried before: the unit's current state of charge, the energy the proposed route is expected to consume, and the next realistic charging opportunity with its expected duration. If any of the three is missing, the dispatcher is guessing. The design goal is to put those three facts on the same screen as hours of service and equipment availability, color them against a margin the carrier sets, and block an assignment that would strand the unit unless a supervisor overrides it with a reason code. None of this requires the dispatcher to understand battery chemistry. It requires the same discipline that already applies to hours: know the number, know the burn rate, know where the next reset happens.
A note on figures. This page does not quote range, battery capacity, or energy consumption numbers because those vary by manufacturer, configuration, payload, terrain, temperature, and driver behavior. Carriers should take planning figures from the manufacturer's published specifications for the exact configuration under consideration, and should consult the U.S. Department of Energy Alternative Fuels Data Center and the Energy Information Administration for neutral reference material on vehicles, charging infrastructure, and electricity pricing. The moment the fleet has its own telematics data from a pilot unit, measured consumption per mile on the fleet's own routes replaces every published figure.
Route Suitability Screening From Your Own History
The question is not whether an electric tractor can do the job in general. The question is which of this fleet's routes it can do reliably, every day, including the bad days. The TMS and telematics archive already contain the evidence. For each route or driver domicile, pull the actual miles driven per shift over a long enough history to include seasonal peaks, not the planned miles. Pull stop count and dwell time, because stops with lift gate or reefer operation consume energy without adding miles. Pull trailer weight or payload where the TMS captures it. Pull the elevation profile for the route from a mapping service, because sustained grades change energy use materially in both directions. And pull the return to depot pattern: does the unit come home every shift, how long does it sit, and does it ever stay out overnight.
With those columns in one table, screening becomes a ranking exercise. Compute, for each route day, the estimated energy requirement using the manufacturer figure at first and the fleet's measured consumption later, apply the carrier's chosen safety margin, and compare the result to the usable capacity of the unit being evaluated. A route whose worst recorded day fits comfortably is a candidate. A route whose typical day fits but whose peak days do not is a candidate only if an en route charging opportunity exists or if dispatch is willing to swap equipment on those days. A route that never fits is excluded for now and revisited when equipment or infrastructure changes. A SQL data mining engagement is usually the fastest way to build that table from dispatch and telematics history, because the raw data exists and the work is joining and cleaning it.
| Screening input | Source | Why it matters |
|---|---|---|
| Actual miles per shift, with peaks | Telematics odometer, TMS trip | Planned miles understate real days |
| Stop count and dwell | TMS stop records, geofence events | Auxiliary loads consume energy while parked |
| Payload or trailer weight | TMS order, scale tickets | Heavier loads raise consumption per mile |
| Elevation profile | Mapping service along the route | Grades change consumption in both directions |
| Return to depot pattern and dwell | Telematics, driver logs | Defines the charging window available |
| Temperature by season | Weather history for the lane | Cabin and battery conditioning affect consumption |
Depot Charger Scheduling: Count, Power, and Dwell Windows
Depot charging is a scheduling problem with three resources: the number of chargers or charging ports, the power each can deliver, and the time each unit sits at the depot between shifts. The TMS should hold all three as data entered by the carrier, not as assumptions. Charger power in kilowatts comes from the installed equipment and the electrical service behind it, and some systems share a power cabinet among several ports so the available power per port drops when neighbors are active. Dwell windows come from the shift schedule and the telematics record of actual arrival and departure times.
Consider an illustration. For example, a depot with 20 chargers and 30 electric units returning across an evening shift change cannot charge every unit simultaneously, so the schedule must decide which units plug in first based on tomorrow's assignments and each unit's current state of charge. The energy a unit receives is simply power multiplied by time, so a unit with a short dwell and a long route tomorrow needs a high power port early, while a unit with a long dwell and a short route can accept a lower power port or a later start. The TMS, or a charger management system integrated with it, should assign ports and start times from tomorrow's dispatch plan, and the dispatcher should be able to see which units will not reach their target state of charge by departure so they can swap assignments the night before rather than at the gate.
Demand Charges and Time of Use Rates
Commercial electricity tariffs commonly contain two kinds of charges. Energy charges bill the kilowatt hours consumed, often at different prices by time of day and season. Demand charges bill the highest power drawn during the billing period, typically measured over a short interval defined in the tariff, and that peak is charged whether it lasted an hour or the whole month. The Energy Information Administration and the carrier's own utility publish the applicable rate structures. The practical consequence for a depot is that the charging schedule, not just the total energy, determines the bill.
If every unit plugs in at full power the moment it returns, the depot sets a high peak during the first hour and pays for that peak all month. If the same energy is delivered across the full dwell window, staggered and throttled so total depot draw stays under a planned ceiling, the peak falls and the energy can be shifted toward hours where the tariff price is lower. The TMS should therefore carry the utility's time of use periods and the depot's planned demand ceiling as configuration, and the scheduling logic should respect both while still getting every unit to its target state of charge before departure. Where the two goals conflict, dispatch readiness wins and the exception is logged, because a missed delivery costs more than one hour of peak demand.
Telematics State of Charge Feeds
None of this works without a trustworthy state of charge signal reaching the TMS. Most electric tractor manufacturers and third party telematics providers can deliver state of charge, charging status, estimated energy consumption, and location through an API at a defined interval. The integration contract should specify the fields, the interval, the time zone, the unit identifier mapping, and what happens when the feed is interrupted. Store every reading with its source timestamp and its received timestamp, so a stale reading is visible as stale rather than mistaken for current.
The feed should also deliver charging session events: plug in, charging started, charging stopped, unplug, and fault, with the energy delivered where the charger or vehicle reports it. Matching vehicle side session data to charger side session data catches problems neither side reports alone, such as a unit that was plugged in but never started charging because of a handshake fault. Our ELD and EDI integration practice treats these feeds the same way it treats ELD position and status data: one mapping per provider, a raw archive of everything received, and validation at ingestion rather than at reporting time.
The Data Model: Charger Assets, Sessions, and SOC History
Three tables carry the core of the design. The charger asset table holds one row per charging port with depot, port identifier, rated power in kilowatts, shared power cabinet group, connector type, installation date, status, and the management system identifier. The charging session table holds one row per session with port, unit, driver if applicable, plug in time, charging start, charging stop, unplug time, energy delivered, starting and ending state of charge, fault codes, and the utility time of use period in which the energy fell. The unit state of charge history table holds one row per telematics reading with unit, source timestamp, received timestamp, state of charge, odometer, location, and charging status.
From those three tables, plus the existing TMS trip and stop tables, every report on this page can be built. Consumption per mile by route, by driver, by season, and by payload comes from joining state of charge history to trips. Charger utilization and fault rates come from sessions. Demand peaks by interval come from summing session power across the depot. Keep the session and history rows immutable, and treat corrections as adjustments with a reason, because these records will eventually support utility bill disputes, warranty conversations, and grant reporting where the carrier participates in a public program. Our TMS implementation work adds these tables and the dispatch screen fields inside the carrier's current system where the platform permits it, so dispatch does not have to learn a second application.
Dispatcher Workflow and Exception Alerts
On the assignment screen, the dispatcher should see each electric unit's current state of charge, the estimated energy requirement of the proposed route with the margin applied, the resulting projected state of charge at return, and the unit's scheduled charging window tonight. Green means the assignment fits with margin, amber means it fits without margin or depends on an en route charge, red means it does not fit. Overrides require a reason code and are reported weekly.
During the day, the exception dashboard should raise alerts when a unit's measured consumption is running ahead of plan such that projected return state of charge drops below the floor, when a unit has been stationary at a charger location without a charging start event, when a charger reports a fault with a unit scheduled on it tonight, when tonight's schedule cannot bring a unit to its target by departure, and when the depot is projected to exceed its planned demand ceiling. Each alert should link to the unit, the route, and the recommended action, such as swap to a diesel unit, reassign to a higher power port, or shift a departure. A dashboard that explains its reasoning gets used; one that only flashes colors gets ignored.
- Know the number - Current state of charge with the age of the reading visible.
- Know the burn - Route energy estimate from measured fleet consumption, not brochure figures.
- Know the reset - Tonight's port, start time, and projected state of charge at departure.
- Record the override - Reason code and approver on any red assignment.
Designing the Pilot
A pilot should answer specific questions, not demonstrate enthusiasm. Choose a small number of units and a small set of routes that passed screening with the widest margin. Instrument everything before the first revenue trip: telematics feed into the TMS, charger sessions into the TMS, and the dispatch screen fields live. Run the pilot across at least one seasonal change, because consumption in cold weather and consumption in summer with air conditioning differ, and a pilot that only sees mild months will mislead the fleet plan. Measure consumption per mile by route, charging energy per session, charger availability, depot demand peaks, and the number of times dispatch had to swap a unit for energy reasons.
Write down the pass criteria before the pilot starts. For example, a carrier might decide the pilot passes if the measured worst day consumption on each pilot route still fits inside usable capacity with the chosen margin, if no revenue trip was cut short for energy reasons, and if the depot stayed under its planned demand ceiling on all but a stated number of nights. Those are the carrier's own thresholds, set in advance, so the pilot review is a comparison against a plan rather than an argument about impressions. A business process optimization review can define the pilot runbook, the roles, and the review cadence.
KPIs That Tell the Truth
The measures that matter are the ones that come straight from the three tables. Energy consumption per mile by route, season, and payload, measured from telematics, is the foundation of every future route screening. Dispatch readiness is the share of electric units that reached their target state of charge by scheduled departure. Energy caused swaps count the assignments moved to a diesel unit for energy reasons, with cause codes. Charger utilization is the share of available port hours actually delivering energy, and charger fault rate is the share of sessions that ended in a fault. Depot peak demand per billing interval, compared to the planned ceiling, shows whether the schedule is protecting the bill. Cost per mile for energy, including demand charges allocated across the month's miles, is the number management will ask for and the one most easily distorted if demand charges are left out.
Report these weekly during the pilot and monthly afterward, by depot and by route. Do not quote fleet wide averages until the data covers a full year, and never publish a figure from a manufacturer or a trade article as though it were the fleet's own result. The credibility of the electrification plan depends on the carrier being able to say exactly where each number came from.
What to Ask Vendors
Three vendor categories touch this design: the vehicle manufacturer or its telematics provider, the charger hardware and charger management system supplier, and the TMS provider. Ask the vehicle side whether state of charge, charging status, energy consumption, and location are available through a documented API at a defined interval, whether historical data can be exported in bulk, and who owns the data when the subscription ends. Ask the charger side whether the management system supports the Open Charge Point Protocol or an equivalent documented interface, whether session data and power throttling commands are available to an external scheduler, how shared power cabinets allocate power among ports, how faults are reported, and how firmware updates are scheduled so they do not interrupt an overnight charging window.
Ask the TMS provider whether unit level numeric attributes such as state of charge can be stored and displayed on the assignment screen, whether an external feed can update them, whether assignment validation rules can reference them, and whether the reporting layer can join trip data to custom tables. Where the answer is no, ask what the integration path is and what it costs. A fractional freight CIO engagement often runs this vendor diligence on the carrier's behalf so the purchase decisions, the utility conversation, and the TMS changes stay coordinated rather than arriving as three separate surprises.
Related practice areas for this work include TMS Implementation ELD and EDI Integration SQL Data Mining Fractional Freight CIO. Each practice page describes scope, deliverables, and how an engagement starts with a short discovery call.
How Strong Tower Consulting Helps
Strong Tower Consulting helps carriers approach electrification as a data and dispatch problem rather than a purchasing event. The work begins with route suitability screening from the carrier's own TMS and telematics history, moves to the charger, session, and state of charge data model and the dispatch screen changes, and then supports a measured pilot with pass criteria written in advance and KPIs reported from the fleet's own records. Strong Tower Consulting, LLC and Exspeedite LLC are separately organized sister companies under common ownership. That separation keeps consulting advice vendor neutral and focused on the carrier operation.
To discuss your routes, your depot, and your current systems, call 763-244-1373 and ask for Scott Elliott. A short call is enough to identify which routes are worth screening first, what data you already have, and what the TMS and telematics need to carry before the first electric unit arrives.
Frequently Asked Questions
How does a battery electric tractor change the dispatcher's job?
State of charge becomes a dispatch input in the same way hours of service already is. Before assigning a load, the dispatcher must know the unit's current state of charge, the energy the route is expected to consume based on the fleet's own measured history, and when and where the unit can charge next. The TMS should surface those three facts on the assignment screen rather than leaving them to memory.
Where should a carrier get range and battery figures for planning?
Use the manufacturer's published specifications for the specific configuration being considered, then replace those figures with the fleet's own measured energy consumption per mile from telematics as soon as pilot data exists. The U.S. Department of Energy Alternative Fuels Data Center and the Energy Information Administration publish neutral reference material on vehicles, charging infrastructure, and electricity pricing that carriers can consult without relying on sales literature.
Why does the charging schedule affect the electric bill so much?
Many commercial utility tariffs include a demand charge based on the highest power drawn during a billing period, often measured over a short interval, in addition to energy charges that may vary by time of day. Starting every charger at full power the moment trucks return can set a high peak that is billed for the whole month. Staggering and throttling charging sessions across the available dwell window lowers that peak and shifts energy use into lower priced hours where the tariff allows.
What data does the TMS need to screen routes for electric suitability?
The TMS and telematics already hold most of it: actual historical route miles by day, stop count and dwell, payload or trailer weight, elevation profile along the route, return to depot pattern, and the time the unit sits at the depot between shifts. Screening ranks routes by how reliably their energy requirement fits inside the unit's usable battery with a safety margin the carrier chooses.
What should a carrier ask charging and telematics vendors before buying?
Ask whether the charger management system exposes session data and power throttling through a documented API or the Open Charge Point Protocol, whether the telematics provider delivers state of charge and charging status at a defined interval through an API the TMS can consume, how the vendor handles charger faults and firmware updates, and what the data ownership and export terms are when the contract ends.
Corporate Affiliation Notice: Strong Tower Consulting, LLC and Exspeedite LLC are separately organized sister companies under common ownership.
Strong Tower Consulting, LLC, Minnesota File No. 2948628-2, founded in 2008. Direct inquiries: 763-244-1373.