What connected transport asks of the infrastructure underneath it
Connected transport is usually discussed at the application layer. The harder questions sit underneath it: what the field can send, what happens when links drop, and who acts on the result.
Most conversations about smart mobility begin with what the system will show: a control-room view, a travel-time estimate, a signal plan that adapts to demand. Those are reasonable places to start a conversation and poor places to start a design. By the time a project reaches the screen, the decisions that determine whether it works have already been made several layers down.
This is a view of those layers, and of the questions we think are worth settling before anyone agrees what the dashboard looks like.
The layers, and why the unglamorous ones decide the outcome
It helps to be explicit about what a connected transport system is made of. Not a product architecture — just the honest division of a system into the parts that fail independently.
Each layer has its own failure behaviour, its own maintenance cost, and usually its own owner. That last point matters more than it sounds. A system whose four layers answer to four different organisations is not a technical problem with a governance footnote; it is a governance problem with a technical footnote.
The dashboard is the easiest part of the system to change and the hardest part to argue about. The layers underneath are the reverse.
Data that arrives late is a different kind of data
A reading that is thirty seconds old and a reading that is thirty minutes old are not the same measurement with different freshness. They support different decisions, and confusing them is one of the more expensive mistakes available in this field.
Some functions tolerate delay well. Understanding how demand shifts across a month, planning maintenance, reporting on a corridor — all of these work with data that arrives when it arrives. Others do not tolerate it at all. Anything that changes what a driver sees, or what a signal does, inherits a hard deadline from the physical world.
The practical consequence is that “real time” should be treated as a suspicious phrase in a requirement document. It is worth replacing with a number and a consequence: how stale can this be before it is wrong, and what happens if it is.
Choosing how the field talks back
Connectivity is where the design meets the budget. There is no general answer, because the question is not which technology is best but which constraint binds first — power, coverage, message size, or the cost of visiting the device.
| Constraint that binds first | What it tends to favour | The trade-off it brings |
|---|---|---|
| No mains power at the device | Low-power wide-area links, long duty cycles | Small, infrequent messages; slow response |
| Continuous video or rich telemetry | Wired or high-capacity cellular | Higher recurring cost; more civil works |
| Devices spread thinly over distance | Wide-area coverage, carrier-operated | Less control over the network itself |
| Devices clustered at one site | Local network with a single uplink | One uplink becomes a single point of failure |
| Site is expensive to reach | Whatever maximises device lifetime | Conservative features; less on-device compute |
Read the table as a set of trade-offs to make deliberately, not as a recommendation. The reason to write it down early is that connectivity choices quietly set the ceiling on everything above them. A link that carries a short message every fifteen minutes has already decided that certain applications are not going to happen, whatever the platform is capable of.
What a reading actually needs to carry
A surprising amount of trouble later comes from message payloads defined in a hurry. Our preference is to settle a small number of fields early and treat them as non-negotiable, because retrofitting them means touching every device already in the field.
At minimum, a reading should be able to answer: what device, what time, what value, and how much to trust it.
{
"deviceId": "sc-0412",
"observedAt": "2026-07-21T08:14:22Z",
"receivedAt": "2026-07-21T08:14:29Z",
"metric": "queue_length_m",
"value": 38.5,
"quality": "ok",
"firmware": "2.3.1"
}Two of those fields do more work than the rest. Separating observedAt from receivedAt is what
makes late data legible instead of misleading — without it, a batch of buffered readings arriving
after an outage looks like a sudden event. And a quality field gives a device a way to say
“this reading exists but do not act on it”, which is otherwise expressed as silence and
indistinguishable from a device that has stopped reporting.
Where these projects tend to get stuck
From our perspective, the recurring difficulties are rarely the ones anticipated in the procurement documents. In rough order of how often we expect to meet them:
- Integration with systems that already exist. New equipment is straightforward. Making it coexist with installed controllers, existing management software and established procedures is where the schedule goes.
- Ownership of the operational data. Who may see it, who may act on it, how long it is kept, and what happens to it at the end of a contract. Left unsettled, this surfaces at the worst possible moment.
- Maintenance access. A device that needs a lane closure to service has a maintenance cost that does not appear in its purchase price.
- The operations team’s actual working day. A system that requires attention nobody has spare will be worked around, and the workaround becomes the real system.
How we approach it
We would rather start narrow. A single corridor, a single junction, or a single class of device, instrumented properly and run long enough to see how it behaves in bad weather and during an outage, teaches more than a broad deployment that has never been stressed.
That preference is not caution for its own sake. It is that the questions above — latency per function, the binding constraint on connectivity, the shape of a reading, who owns the data — are all much cheaper to answer wrongly at small scale.
Where this touches something you are planning, we are happy to go through it in specifics rather than in general terms.