EV fleet management for micro-mobility

Micro-mobility operators tend to discover the hard way that a scooter is not a phone with wheels. It is a battery, a motor controller, a modem, a GPS, and a lock, sharing one small enclosure that vibrates for eight hours a day and gets rained on. Every one of those components has firmware, and every firmware has opinions about power, latency, and failure modes.

That is the real engineering problem behind ev fleet management at scale. Not the dashboard. Not the pricing engine. The embedded layer that has to keep 10,000 vehicles reporting accurate state of charge, responding to unlock commands in under a second, and not bricking themselves when a cell drifts out of balance.

Why generic fleet software falls short

Most ev fleet management platforms on the market were built for delivery vans or corporate car fleets. They assume a vehicle with an OBD-II port, a driver, and a route. Micro-mobility breaks every one of those assumptions.

A shared e-scooter has no driver logged in, no standardised diagnostic protocol, and no route until a rider swipes. Its telematics unit is usually a custom PCB running a stripped-down Linux or an RTOS on an ARM Cortex-M. Its battery management system (BMS) speaks CAN or a proprietary UART protocol, and its charging behaviour depends on whether it is docked, swapped, or plugged into a warehouse rack overnight.

Generic software abstracts all of that away. That abstraction is exactly what costs operators money, because the useful signals live in the layer that got hidden.

The three subsystems that define an ev fleet management system

An ev fleet management system for micro-mobility rests on three tightly coupled subsystems. Get any one of them wrong and the other two start lying to you.

Battery management

The BMS is the source of truth for range, safety, and vehicle lifetime. It measures cell voltages, temperatures, current draw, and internal resistance, then decides when to throttle, when to disconnect, and when to raise an alarm.

What matters at the fleet level is not the raw telemetry but the derived signals: state of health trend, thermal events per charge cycle, and cell imbalance drift. Those signals predict which vehicles will fail in the next 30 days, and they only exist if your embedded team designed the BMS firmware to expose them.

Charging infrastructure

Charging is where fleet economics live or die. Swappable batteries, docked charging, and warehouse rack charging each have different failure modes and different data models. A rack charger with 40 slots needs to report per-slot state, detect stuck contactors, and negotiate current across a shared circuit without tripping a breaker.

OCPP is a starting point, not a solution. Most micro-mobility charging hardware runs custom protocols because OCPP was written for cars. Your ev fleet management software needs adapters for each, plus a canonical internal model so the operations team sees one view.

Real-time telematics

Telematics is the connective tissue. Position updates, lock state, ride state, and BMS summaries flow over cellular to a broker, usually MQTT, and land in a stream processor that maintains vehicle state.

The hard part is not the happy path. It is handling 15% of the fleet on flaky 4G in a tunnel, deduplicating messages when a modem reconnects, and keeping the write path idempotent so a delayed unlock command does not open a scooter an hour after the rider walked away.

A framework for building it

After working across IoT fleet management at scale and adjacent embedded domains, a pattern holds up. Use it as a decision framework when you scope the next release.

1. Define the canonical vehicle state model before writing firmware. Every subsystem, BMS, motor controller, modem, must map to this model. If it cannot, the model is wrong or the hardware choice is wrong.
2. Push derived signals to the edge. State of health, anomaly flags, and rider-facing range estimates should be computed on the vehicle, not in the cloud. Bandwidth costs money and latency costs trust.
3. Version everything, over the air. Firmware, config, ML models for anomaly detection. If you cannot roll back a bad release to 5,000 vehicles in under an hour, you do not have an ev fleet management system, you have a liability.
4. Instrument the charging layer as aggressively as the vehicle layer. Chargers fail silently and take revenue with them.
5. Treat the backend as a stream processor, not a CRUD app. Vehicle state is a fold over an event log, not a row in a table.

Where senior embedded engineers actually earn their keep

The framework above is easy to write and hard to execute, because it crosses hardware, firmware, protocol design, distributed systems, and data engineering. That mix is rare, and the engineers who have it usually did their time in automotive, aerospace, or industrial IoT.

This is where a remote development team of senior engineers changes the math. Devspace draws from a network of 500+ pre-vetted senior engineers across Europe, matched on stack and domain rather than pulled off a bench. For a micro-mobility operator, that usually means embedded engineers with real BMS experience, a backend lead who has run MQTT at fleet scale, and a data engineer who can build the health scoring pipeline. They embed in your sprint, your repo, your standups, typically within two to four weeks.

The alternative, which we see often, is a generalist team learning embedded on your dime while your fleet grows faster than the software can keep up.

The information vacuum problem

A final note on operational reality. When something goes wrong with a physical fleet, the information vacuum is brutal. A recent CBC report on Summerland wildfire evacuees described residents turning to social media because official channels stayed silent (CBC News, 2024). The same dynamic hits fleet operations. When 200 scooters go dark in a neighbourhood, if your ops team cannot see why within minutes, riders, city officials, and press will fill the gap with their own narrative.

The fix is not more dashboards. It is observability designed into the embedded layer from day one, with vehicle-side logging, edge summarisation, and alerting that catches degradation before it becomes an outage. That is an architectural decision, made early, by engineers who have lived through the alternative.

Takeaway

Ev fleet management for micro-mobility is an embedded systems problem wearing a SaaS costume. Build the canonical state model first, push intelligence to the edge, instrument the charging layer, and staff the work with engineers who have shipped firmware before. The dashboards will follow.

Photo by Ernest Ojeh on Unsplash