Tire tracking: one identity from the production batch to the fleet

01 / FIELD NOTE

Keep the decision tied to the operating context.

A tire is two different things in sequence, and the identity has to survive the change. It begins as a manufactured product with a batch, a size, a model and a production date, all of which belong to the plant that built it. It then becomes a long-life asset installed on a vehicle, whose history belongs to whoever operates that vehicle. Between those two states it is counted in stacks, shipped in bulk, matched to a model at a dealer, mounted, rotated, repaired, and eventually either retreaded or retired. Most tire records break at one of those transitions rather than at any single step, which is why the question worth asking first is not which tag to use but what the record is supposed to survive.

The tag decision is different here because the substrate is different. A tire is rubber with steel belts and bead wire inside it, and both materials act on a tag in ways that a cardboard carton or a plastic tote does not. Rubber absorbs radio energy, so a tag lying flat against it loses read range; steel reflects it, so a tag near the belts can be detuned or shielded entirely. A read distance quoted from a catalogue is measured in open air, and open air is the one condition a tire never provides.

There are two places a tag can go, and they are decided by different people at different times. A tag embedded during manufacture is placed inside the rubber before the tire is cured, so it sees the heat and pressure of that process and then cannot be reached, replaced or repositioned for the rest of the tire’s life. That makes it a manufacturing engineering decision taken once, in the plant, with no remedy available later. A tag applied to the surface afterwards is reachable and replaceable, but it lives on the outside of an object that flexes, rubs against its neighbours in a stack, and collects dirt — and the flexing is what eventually breaks the attachment or the inlay.

Reading a stack is the case that most projects underestimate. Tires are stored in tall piles with tags at arbitrary orientations, buried under other tires, and read through a great deal of rubber and steel. The read that has to work is not the one performed on a single tire held in the hand; it is the one performed from the aisle against a stack whose geometry nobody controlled. That read is a function of how the tires were stacked as much as of the tag, which means the storage method is part of the read design.

The record has to keep its identity across four handovers: plant to warehouse, warehouse to dealer, dealer to vehicle, and vehicle to whichever party retreads or retires it. Each handover is a place where an identity can be re-issued rather than carried, and re-issuing is what destroys the point of the exercise. If the warehouse gives the tire a location identifier, the dealer gives it a shipment identifier, and the fleet gives it an installation identifier, then no single record answers where this carcass has been — and that question is the only reason to tag it at all.

Which fields survive the handover is a design decision rather than a technical constraint. The batch and the production date belong to the plant and never change. The installation and the distance travelled belong to the operator and change repeatedly. The retread count and the retirement status accumulate. Deciding which of these are carried on the tag itself and which are held in a system that the tag merely points at is the difference between an identity that survives a decade and one that has to be re-established whenever the software changes.

The installation event is the weakest joint in the record. A tire does not stay on one vehicle, and on a vehicle it does not stay in one position — rotation is routine. A record that says only which vehicle a tire is fitted to cannot answer which wheel position it occupies, and without the position the rotation cannot be tracked and the wear history is incomplete. The position is a property of the installation rather than of the tire, which is why it has to be recorded as a separate event with a start and an end.

Retread is where the identity either pays for itself or is thrown away. A retreaded tire is the same carcass with new tread bonded to it. Whether that object is the same asset continuing or a new asset beginning is a decision, not a fact, and it has to be made before the first retread rather than at it. Carry the history forward and the carcass accumulates a service life that informs the next retread decision. Start a new record and the casing’s history is lost precisely at the point where knowing it would be most useful.

The end of the life is where a serial that survived everything earns its keep. A batch problem — a manufacturing defect, a warranty claim, a safety notice — is answered by finding every tire from that batch, and that search runs against the identity record rather than against a stack. A record that has been re-issued at four handovers cannot answer it. This is also the point at which the tag has to be readable on a tire that is worn, dirty and possibly no longer fitted to anything.

There is a case where none of this is worth doing. If the only requirement is a label that identifies a shipment once, applied at dispatch and read at receipt, then a printed label does that job and an RFID tag does not improve it. The test is whether the record is expected to outlive the shipment it was applied to. Where it is not, the tag is a cost with no beneficiary, and recognising that early is part of specifying the project honestly.

Two limits are worth stating. The first is that a tag which works on one tire model is not evidence that it works on another: sidewall thickness, belt construction and the amount of rubber between the tag and the air all differ between a passenger tire and a truck tire, and so does the read. The second is that testing has to happen on real tires in real stacks, because a test that reads a single tire on a bench measures the tag rather than the installation, and the installation is what the project depends on.