A digital twin for a trucking fleet: one console for the dispatcher, the driver and the person receiving the freight

The business problem

A long-haul trucking fleet needs information from several places: position comes from a telematics provider, driver files are kept separately, and whoever receives the freight wants to know where it is. When these sources don't meet, the dispatcher learns about an overheating engine or an empty tank only once the truck has stopped.

There are legal rules too. In the US, driving past 11 hours (the FMCSA Hours of Service rule) means a mandatory stop and a risk of fines. On top of that, a driver file holds highly sensitive data, such as the Social Security number (SSN), CDL licence and medical card, which calls for a controlled home and an access log.

To find, together with the client, a solution that brings every truck, driver and delivery into one place, so the dispatcher can act before a problem stops the freight.

• Sensitive dataDriver SSNs can never be stored or sent in plain text, and every reveal must be justified and logged
• Separate rolesThe manager sees the whole fleet; a driver sees only their own truck and trailer, enforced in the database, not just the interface
• Recipient without an accountThe end customer must see position and estimated arrival without signing up and without internal jargon
• US industry rulesDriving-hours limits (FMCSA), CDL licence classes, medical card and TWIC expiry dates
• Existing telematicsA telematics provider's data has no routes, estimated arrival or cargo state; it had to be adapted without invented values

The solution

We started from the dispatcher's working day: what they need at a glance, what should alarm them and what they can ignore. That produced the alert thresholds (engine temperature, fuel, driving hours, delay), a split between a fault and a route event, and three kinds of users, each with their own screen: the manager or dispatcher, the driver, and the person receiving the freight, who has no account.

The data flows one way. Truck readings arrive every two seconds and feed the map, the 3D truck model, the alerts, the driver screen and the public tracking page, so they all see the same data. Position and engine readings come from the telematics provider through a dedicated adapter. Values the provider does not supply, such as the route, estimated arrival or cargo state, are not filled in artificially: they are stored separately, so we never invent data.

Access is decided by the database, not by the interface. The manager sees the whole fleet, the driver sees only the assigned truck and trailer, and the end customer sees only position, estimated arrival and whether the freight is on time or delayed. Manager accounts cannot be created by self-registration, any public sign-up becomes a driver, and the browser cannot write telemetry. Driver SSNs are encrypted, and every reveal requires a reason and is logged.

A few decisions guided the rest. A geofence event is not a fault and is never shown in red, so the dispatcher is not alarmed for nothing. Service is due by mileage, not by calendar date. To check the whole chain, we added test scenarios: inject a fault and watch the alert, the reaction and the recovery.

What the client gained

The client has one console instead of several sources. The dispatcher sees the whole fleet on a map and gets alerts for engine, fuel, driving hours and delays before a problem stops the freight. The person receiving the freight gets a simple public page, with no account and none of the dispatch vocabulary.

Sensitive driver data has one controlled home with an access log, and access rules are enforced by the database. Test scenarios let the team check the whole chain at any time, from fault to alert and back to normal.