Fleet Assets

What this chapter covers

A mission is carried by physical things a fleet owns and driven by the person at the wheel: the vehicle that provides power, telemetry, and a driver seat; the trailer that often carries the actual cargo; the tracker and SIM wired into the truck that make the whole platform possible; and the driver assigned to run it. This chapter describes those assets as an owner manages them — how a vehicle is registered, how a trailer is described and linked to a tractor, how the device layer (a tracker plus its SIM, installed in a vehicle, sometimes swapped) is understood from the owner's side, and how a driver record is created — and it is the register the mission plan draws its vehicle, trailer, tracker, and driver from.

Through this part we follow one concrete job: a tanker that loads fuel at the Douala port and runs the 2,000 km trunk to N'Djamena. It starts here as three assets and the person who will run them — the truck, the tanker trailer hitched to it, the tracker wired into the cab, and the driver assigned to the haul — and the following chapters plan, drive, and measure the run they make.

The picture

Three asset kinds relate in a simple shape: a trailer is hitched to at most one vehicle, a tracker is installed in at most one vehicle, and a SIM lives inside at most one tracker. Missions record which trailer they used as durable history.

The vehicle is the hub: the trailer hangs off it, the tracker sits inside it, and the tracker's SIM sits inside the tracker. Only the vehicle produces position.

Vehicles — the powered asset

A vehicle is a registered truck (or a pickup or a van). It carries the facts an owner needs to identify and manage it: a registration number unique within the fleet, a type, and make, model, and year. Each vehicle also carries an asset status and can be archived, so a sold or written-off truck leaves the working lists without erasing the history attached to it.

The vehicle is the only asset that streams telemetry, and it does so through the tracker installed in it — never through a phone. Everything the platform knows about where a truck is, whether it is moving, and how much fuel is in its tank is anchored to the vehicle's own hardware, which is why the vehicle is the anchor every trip, stop, mission, and alert hangs from.

Beyond the identity fields, the vehicle row is also where the engine keeps each truck's live state — its last known position, ignition, battery, signal, and fuel — refreshed at the end of every telemetry batch so the live map and fleet overview read one fast row. That live-state machinery is the subject of Part 2 — Telemetry and Part 3 — The fleet engine; here the point is simply that identity and live state share the one vehicle record.

Trailers — the passive asset

A trailer is a first-class fleet asset in its own right, distinct from the vehicle it's hitched to. On the corridor a trailer is frequently the commercial unit — it holds the cargo — while the truck provides the power, the driver, and the tracker. A trailer has no tracker and no position stream of its own, so its whereabouts and availability are inferred from the truck it is hitched to and from the missions that used it.

A trailer records the operational description an owner needs:

• a registration number, unique within the fleet;
• a type — one of flatbed, container, tanker, tipper, reefer, or other;
• physical specs — axle count, wheel count, length, maximum payload, and tare weight;
• make, model, and year;
• a technical inspection expiry date;
• an asset status.

The specs are recorded for operations and future compatibility checks; today mission creation does not hard-enforce payload, axle, or inspection compatibility as a domain rule — the numbers inform the operator rather than block the dispatch.

Linking a trailer to a tractor

The current physical association between a trailer and a truck is a direct link. The rule is one-to-one on both sides: a trailer is hitched to at most one vehicle, and a vehicle pulls at most one trailer. Linking is an owner action — Korido does not try to detect a hitch automatically — and it can be updated whenever a trailer is physically moved in the yard.

Because a trailer can only be on one truck and a truck can only pull one trailer, linking a trailer that is already committed elsewhere is a swap, handled in one clean step:

The swap frees both sides first so the one-per-vehicle rule is never violated, even momentarily. Changing a trailer's status to retired, breakdown, or maintenance also unhitches it — an asset that is off the road should not appear hitched to a working truck.

A trailer on a mission is history

When a mission is created with a trailer, two things happen together: the trailer is recorded on the mission, and it is hitched to the mission's vehicle in the same step. That mission record is durable history — the mission keeps its trailer reference even after the trailer is later unhitched, retired, or archived. The present hitch answers "what is on this truck right now"; the mission rows answer "which trailer ran which job," and the two are kept separate on purpose so neither erases the other.

A trailer's detail view leans on that history: it shows the missions the trailer served, with their count, distance, and tonnage, giving a passive asset a legible operating record built entirely from the missions it ran.

The device layer, as owners see it

Under every tracked truck sits a small stack of hardware: a tracker wired into the cab, a SIM inside the tracker that carries its data, and optional components such as a fuel probe or a CAN reader. Korido's platform team procures and owns this hardware; an owner meets it as the thing installed in my truck that makes tracking work.

From the owner's side, the device is identified by its hardware identity (its IMEI) and its model, and the connection is what matters day to day: an owner sees that a tracker is installed, how fresh its signal is, and whether it has gone quiet. Each device can also carry a per-device silence expectation — how long this particular unit may stay quiet before it counts as offline — which sits at the top of the offline-detection chain described in Part 2 — Telemetry. The deeper inventory — SIM cost, supplier, procurement batch — is platform bookkeeping, kept in the admin portal rather than the owner's view.

A tracker's lifecycle, and swaps

A tracker moves through a clear set of states — from in stock, to assigned to a fleet, to installed in a specific truck, and eventually to a terminal state when it is faulty, returned, decommissioned, or lost. An installed tracker is always tied to a vehicle; a tracker in stock belongs to no fleet and no truck.

Hardware moves. A tracker that fails is swapped for a replacement; a truck that changes tracker gets a new unit installed. Every one of these moves is written to a durable install history — who fitted or removed a unit, when, and why (an initial install, a faulty swap, a reinstall) — so the full story of which tracker was in which truck at which time is always recoverable, and a swap records the unit it replaced. The SIM inside a tracker is tracked the same way: swapping a SIM writes its own history row rather than overwriting the last one. Nothing about a device or SIM change is destructive — the current install is one row in a chain that keeps every prior fitting.

Drivers — the people who run the assets

The assets above are inert until a driver takes the wheel — the one part of the register that is a person. A driver record does double duty: it is the login identity that lets someone into the driver app, and it is the assignee a mission is dispatched to. Creating one is therefore the prerequisite for both: sending a truck on a mission requires a driver named on it, and reaching the driver app requires a driver record to sign in as.

A driver record carries a name, an email, a phone number, and a language — French or Arabic — for the copy they receive. The phone is the key fact: it is the login identity, the number a driver enters to receive a one-time code and sign in, and for that reason it is set when the record is created and not edited afterward from this screen — "le téléphone est l'identifiant de connexion." The driver app never carries a password; the phone plus a one-time code is the whole of it, which is why a driver must exist in the register before they can log in at all.

Once created, a driver is what a mission is assigned to and what a truck records as its current driver, and their detail view gathers the trucks they are assigned to and their recent missions. A driver holds at most one active mission at a time — dispatch turns away an attempt to give a driver a second mission while their first is still running, because one person cannot drive two trucks at once. Deactivating a driver — "Désactiver" — detaches them from their trucks and hides them from the assignment pickers, but preserves the mission history they built: "l'historique des missions est conservé." Like a retired vehicle or trailer, a driver leaves the working fleet without erasing the record of the work they did.

Asset status and availability

Vehicles and trailers share one asset status vocabulary, and it answers a single question: is this asset available for work?

• active — available.
• in_mission — committed to a mission in progress.
• maintenance — deliberately off the road for service.
• breakdown — failed and unavailable.
• retired — permanently out of the fleet.

The status is an availability marker. maintenance and breakdown tell operators an asset is off the road and remove it from the pool of things that look ready to dispatch, capturing availability alone — what broke, what it cost, what parts were used, and how long the downtime ran live outside the status field. A trailer's technical inspection expiry is treated the same way — it is tracked and surfaced, and the fleet can count how many inspections have lapsed, so an owner can see compliance at a glance without the platform pretending to run the workshop.

Edge cases

• A trailer with no truck. A trailer can exist unhitched — sitting in the yard, waiting for a job. It stays a full asset with its own status and history; it simply has no current vehicle.
• A trailer that changes trucks. Re-hitching is a swap: the previous truck is unhitched and any trailer already on the new truck is freed, so the one-per-vehicle rule holds without a manual unlink first.
• A retired trailer's past missions stay readable. Archiving or retiring a trailer unhitches it from its truck but never rewrites the missions it ran — the mission history survives the asset leaving the working fleet.
• A tracker swapped between trucks. The install history keeps both fittings, so a truck's telemetry record is never confused about which unit was reporting when, and the replaced unit is named on the new install.
• A device in stock. A tracker not yet assigned belongs to no fleet and no truck; its heartbeat can still be seen at the platform level, but no fleet-scoped data is written for it until it is installed in a vehicle.
• Specs that inform but do not block. A trailer's payload and axle figures guide an operator picking a trailer for a load, but they are not a hard dispatch guard today, so a mission is never silently blocked by a spec mismatch the operator did not see.
• A deactivated driver's missions stay readable. Deactivating a driver detaches them from their trucks and removes them from the assignment pickers, but the missions they ran keep their driver reference — the operating record survives the person leaving the working fleet, exactly as a retired trailer's missions do.

What's ahead

• A maintenance module. Today an asset's status carries availability — maintenance and breakdown take a truck or trailer out of the dispatch pool, and a trailer's technical-inspection expiry is tracked and counted — but the platform stops short of running the workshop. The direction is a full maintenance module: maintenance events for vehicles and trailers alike, a preventive, corrective, and incident lifecycle, parts and line items, photo attachments, capture from the driver app where it helps, and inspection-expiry warnings wired into a workflow rather than surfaced as a bare count. The truck-versus-itself trends of Part 6 — efficiency or dwell quietly degrading over time — are the early-warning signals such a module is built to act on.

How it connects

• Creating missions — how a vehicle, driver, and trailer are chosen for a mission, and how picking one can fill in the others.
• The mission lifecycle — where the chosen vehicle and trailer do their work, and the one-active-mission-per-vehicle rule.
• Segments and traversals — where the trailer and vehicle become context stamped onto every measured leg.
• Part 2 — Telemetry — how the installed tracker's signal becomes the vehicle's live position, and the silence expectation behind offline detection.
• The admin portal — where the platform team procures, assigns, installs, and retires the hardware an owner sees fitted to a truck.
• The fleet app — the owner surface where vehicles, trailers, and drivers are registered, linked, and managed.
• The driver app — the surface a driver record is the login identity for, entered by phone and a one-time code.
• Clients — the register's counterpart: who the work is done for.