The Hardware-Agnostic AI Control Tower

The phrase is used loosely, so it is worth being concrete about what is and is not being claimed.

It means the platform ingests data from trackers it did not sell. A device from another vendor reports into MoboSafe alongside MoboSafe hardware, and both appear in the same list, with the same alerts and the same reports.

It does not mean every feature works on every device. A tracker that reports only position cannot produce fuel data, and no software layer invents it. What you get from a device is bounded by what that device measures.

So the honest framing is: you keep the hardware and the visibility it already produces, and you gain a better layer on top of it. Anything requiring a sensor the device does not have still needs that sensor. See what hardware-agnostic means.

Nobody plans a fragmented estate. It accumulates.

Vehicles are bought in batches years apart and fitted with whatever the vendor supplied at the time. An acquisition brings in another fleet on another platform. A state mandate forces a particular approved vendor for the vehicles registered there. A vendor goes quiet and the next batch goes elsewhere.

The result is three or four portals, each with its own login, its own alert format and its own idea of what a trip is. Dispatchers end up reconciling by hand, which means in practice they stop reconciling at all and watch only the platform with the most vehicles on it.

The cost is not the licences. It is that nobody has a single view, so exceptions on the smaller platforms are found late or not at all.

This is the unglamorous engineering that decides whether a control tower is useful or just another portal.

Devices disagree about almost everything. Reporting intervals differ, so one vehicle produces a point every thirty seconds and another every five minutes. Ignition is reported as a state by some devices and inferred from movement by others. Trip boundaries are drawn differently, so the same journey is one trip on one platform and three on another.

Normalising means deciding one definition and applying it to all of them: what counts as a stop, how long a halt must last before it is a halt, when a trip ends. Without that, a report comparing vehicles across vendors compares nothing.

It also means handling gaps honestly. A device that buffers through a coverage gap and uploads later produces points out of order, and a platform that does not reorder them draws a route through the wrong roads.

Worth stating before a procurement conversation, because the boundary is where most disappointment sits.

The practical test before committing: list what each vehicle class actually reports today, and ask which of your questions that answers. Anything left over needs hardware regardless of platform.

• You keep working hardware, the fitment cost already spent, and the vehicle downtime you would have spent replacing it.
• You keep whatever each device measures: position everywhere, and fuel, temperature or ignition where those sensors exist.
• You cannot add a capability the device lacks. A basic tracker will not start reporting harsh braking because the software improved.
• You cannot fix a device that has stopped transmitting, or one whose vendor has been removed from a state approved list. Those are hardware and compliance problems.

A platform that only ever says keep your devices is selling something too.

Replace when the device is not AIS-140 certified on a vehicle that requires it, because no software layer makes an uncertified unit compliant. See AIS-140 compliance.

Replace when the vendor has come off your state's approved list, when a device has been dark for months and refitting costs less than diagnosing it, or when the capability you actually need is a sensor that is not installed.

Everything else is usually a software problem wearing a hardware costume, and replacing forty working units to solve it is the expensive way round.

That last one matters more than it seems. A platform that unifies your fleet and then holds the history hostage has replaced one lock-in with another.

• Bring your own device list. A demo on the vendor's hardware proves nothing about yours.
• Ask which of your devices are already supported and which need integration work, with timelines.
• Check how trips and halts are defined, then compare one real journey against what your existing portal said about it.
• Ask what happens to buffered points uploaded late.
• Confirm what happens when you leave: whether historical data is exportable and in what format.