Container tracking: milestone events on a metal box that never stops moving

01 / FIELD NOTE

Keep the decision tied to the operating context.

A container is close to the least convenient object to track by radio. It is a large steel box, which reflects rather than passes energy; it is stacked with other steel boxes, so any tag on it is surrounded by metal; it spends its life in motion between facilities that belong to different organisations; and it crosses borders where the equipment reading it may not be the same equipment that read it last.

The first useful decision is therefore not which technology but which question is being asked. Knowing where a container is at every moment is not achievable and would not be worth its cost. Knowing that it passed a defined milestone — loaded at origin, discharged at the destination port, cleared the gate, returned empty — is achievable, and is what the commercial and operational decisions actually depend on.

That reframing turns the problem from positioning into event capture at fixed points. A port gate, a terminal entry, a rail interchange and a yard crane are all places where a container is briefly in a known position, and a reader at that point turns a continuous unknown into a dated event. The engineering problem becomes making those points reliable rather than making the container continuously visible.

Container identification is standardised, which is what makes tracking across organisations possible at all. The container has an owner code and a serial number under the ISO 6346 convention, and that identity is the common key between carriers, terminals and customs systems. Any electronic identity has to be associated with that number, because a system that invents its own identifier cannot interoperate with the parties who only know the box number.

The tag has to survive the journey rather than merely start it. A container is handled by cranes, exposed to weather and salt, and may pass through many hands over years. A tag mounted on a door or a corner casting is exposed to impact, and a tag that fails silently is worse than a tag that was never fitted, because the record will keep reporting the last milestone it heard without indicating that nothing has been heard since.

Mounting position is a real trade-off. A tag on the door is accessible and reads well at a gate, and is also the part of the container most exposed to damage. A tag recessed into a corner casting is protected and harder to read. A tag on the roof reads well from a crane-mounted reader and is unreachable for maintenance. The choice follows from which reading points matter most, which is why it should be made after the milestone list rather than before it.

The stacked case is where naive designs fail. A yard or a vessel deck presents hundreds of containers in close proximity, all metal, with the tag on one often shielded by the container stacked against it. Reading that population reliably requires a reader positioned where the target container is exposed, or a power and antenna arrangement designed for the geometry, and usually both. Assuming a portal at the yard entrance will read a stack is how a project discovers the problem late.

A seal is a different requirement that is often bundled with tracking. A container seal exists to show whether the doors have been opened since it was applied, and an electronic seal adds an identity and a record to that function. The value is in the tamper evidence and its audit trail, not in the tracking, and conflating the two leads to a specification that does neither well.

The handovers between organisations are where the record is most likely to break. Each party may operate its own reading infrastructure, its own software and its own definition of a milestone, and a container that passes between them can leave one system and enter another with no event marking the transition. A shared milestone definition and a shared identity are what allow the gap to be closed, and they are governance problems before they are technical ones.

What the data is used for should shape what is captured. If the purpose is to answer questions about dwell time at a terminal, then the events needed are arrival and departure with accurate timestamps rather than position. If it is to support a claim about condition, then temperature or shock recording is the requirement. If it is asset utilisation, then the milestone that matters is the empty return. Each of these needs different events, and specifying the events from the questions prevents collecting data nobody uses.

The accuracy of a milestone is worth more than the quantity of data. An event that reliably fires when a container passes a gate, with a trustworthy timestamp and a confirmed identity, supports a decision. A stream of approximate positions with gaps and duplicates does not, and the effort of reconciling it usually exceeds the value of the questions it was meant to answer. Fewer, dependable events are the better design.

The realistic promise is therefore a chain of confirmed milestones with visible gaps, not a live map. A container journey with an event at loading, discharge and gate passage — and a clear indication of where no event was received — gives the operations team something to act on and the commercial team evidence to rely on. A system that claims more than that will be found out at the first exception, and the exceptions are where a container tracking system is actually judged.