Fleet Management for Smart Cities

The defining technical problem in a smart city deployment is that each department bought independently, so the estate is mixed by construction rather than by accident.

A hardware-agnostic layer ingests devices from multiple vendors into one view, which is faster and cheaper than standardising hardware across departments that have separate budgets and procurement cycles.

The alternative, replacing everything to unify it, is what stalls these projects. See the AI control tower.

Public transport vehicles under AIS-140 must transmit to a state-designated backend. That obligation is separate from whatever the city command centre displays.

Both streams come from the same device, and a vehicle can appear correctly on the city dashboard while being non-compliant on the state record, because those are different systems.

Getting this wrong surfaces at permit and fitness renewal rather than in operations. See the VLTD backend.

Internal fleet data can be approximate. Arrival information shown to the public cannot, because inaccurate predictions erode trust faster than absent ones build it.

That means reporting frequency and data quality matter more for public-facing use than for internal reporting, and the constraint should be set by the public use case.

It also means being explicit about what is not known. An honest gap is better than a confident wrong estimate.

Each department needs its own vehicles and a central function needs everything, which is a role-based access design rather than separate deployments.

Confirm hosting, backup, and connected-service locations against the procurement requirements before activation.

The audit trail matters for the same reasons it does in any government fleet: public vehicles, public fuel, and a record that has to withstand review.