Replacing a damaged RFID tag is not complete when a reader detects the new tag. First establish which physical asset is being serviced, agree how the replacement will identify that asset, and confirm the approved relationship in the application. A successful read is useful evidence, but it does not by itself prove that the correct asset record or maintenance history will be opened.
This guide is for integrators and project buyers planning an RFID asset workflow. It concerns replacement decisions and evidence, not a universal tag-writing procedure. The required reader functions, tag memory access and application changes must be confirmed for the actual configuration.
Start with the asset, not the unreadable label
Consider a reusable equipment case whose RFID label has been damaged. The operator can still see a case serial number, but the application no longer receives an expected RFID result. Another similar case is nearby. This is an editorial example, not a customer deployment or an AIDC GO test.
The first question is whether the case in front of the operator has been reliably matched to the intended asset record. A maintenance ticket, durable serial marking, existing barcode or controlled equipment register may provide corroborating evidence. A photograph or location can help, but the application owner must decide which combination is sufficient. Similar-looking equipment or a remembered storage position should not silently become proof of identity.
If the available identifiers disagree, hold the replacement for resolution instead of guessing the record. Record what could and could not be checked. An unreadable RFID label does not prove that the asset record is missing, and a tag absent from one reading position is not necessarily damaged. Use the existing UHF RFID read-range guide when the initial problem may be detection conditions rather than replacement.
Separate the asset identifier, EPC and TID
The asset record is an application-level record about the equipment. An identifier is a value used to refer to it. The RFID tag is a physical data carrier. These are related, but replacing the carrier does not automatically require creating a new asset or deleting its history.
Where a GS1 identification scheme is used, the key should suit the object being identified. For example, GS1 describes GIAI for individual transport assets and GRAI for returnable assets in its asset identification guidance. This is not a requirement that every internal equipment register adopt those keys.
For RAIN RFID, EPC memory and TID memory serve different purposes. EPC memory carries the Electronic Product Code, which can encode an object identifier. TID contains tag-chip identification information; the fields available depend on the tag and protocol generation. GS1 states that Gen2v3 tags with the E2 allocation class support a serialised TID. Do not assume that every older or unspecified tag provides the same serialised fields. See GS1's tag memory explanation.
Ask the application team which value it actually stores and compares: decoded EPC identity, a raw EPC representation, TID, an internal asset number, or a documented combination. Capturing TID does not itself establish an asset association. Nor does copying an EPC prove that all dependent records have moved to the replacement tag.
Agree the replacement relationship before encoding
Two projects may legitimately make different choices. One may retain the same object identifier in a replacement carrier after controlling the old carrier. Another may assign a new tag-facing identifier and update a mapping to the unchanged asset record. The identifier scheme, collision controls and application contract determine whether either approach is suitable. Neither is a default instruction to copy or generate a value.
If the EPC is retained, decide how to prevent the old and replacement carriers from being used simultaneously as two apparent instances of the same asset. If a new identifier is assigned, define how a later read of the old identifier is handled and how historical records remain interpretable. A damaged tag might later become readable; the old relationship must not be forgotten simply because today's read failed.
Name the responsible roles. The asset owner approves the physical-asset match and replacement. An authorised provisioning role supplies or encodes the agreed identifier. The application team controls mapping changes and old-identifier handling. The operator records the physical installation and the agreed checks. These roles may be combined in a small team, but their decisions still need to be explicit.
The following table is a proposed handover record for the example case. It is not a standard-mandated sequence or evidence of an executed test.
| Decision point | Evidence to record | Limit of that evidence |
|---|---|---|
| Physical asset match | The asset record and the independent serial, barcode or other approved evidence used to identify the case. | Does not establish identity if the physical marking and record disagree. |
| Replacement identifier | The approved EPC or other tag-facing value, its format, and TID when applicable and available. | Does not establish that the application mapping has been saved. |
| Mapping change | The old-to-new relationship, unchanged asset reference, responsible role and application confirmation. | Does not establish that the intended tag is attached to the asset. |
| On-asset read | The installed replacement, device configuration, reading position and identifier received. | Does not establish that the application opens the correct asset record. |
| Workflow acceptance | The resulting asset view, relevant history and outcome of the agreed task. | Does not establish performance in untested locations or configurations. |
Confirm who can prepare and install the replacement
Check whether the replacement arrives pre-encoded or requires on-site encoding. Request the tag model, memory layout, identifier format, relevant lock state and the intended preparation method. Reading EPC memory is not proof that the proposed handheld can write that memory, access another bank or perform the required lock operation.
GS1's memory access and locking guidance explains that protection differs by memory bank and that lock status can be permanent. A readable EPC may therefore be protected against rewriting. Confirm access arrangements through the authorised technical team; do not put passwords in a general project brief or assume that a locked tag can be repurposed.
For hardware discussions, compare the available RFID mobile computer direction with an RFID sled for an existing host. Ask about the exact model, regional configuration, host application and required operations. These category links are not a claim that an RX or SX configuration supports tag writing or every memory command.
The replacement also has a physical job. Ask the tag supplier to confirm the intended asset surface, mounting method, environment and orientation. Replacing a label with a visually similar one does not establish equivalent behaviour. The tag and reader selection basics cover that broader choice; this article concentrates on keeping the correct asset relationship through the change.
Retain the removed tag or its evidence according to the project's procedure until the responsible team has accepted the replacement. Physically removing a label, marking an identifier inactive in software and issuing a tag command are different actions. Do not assume one performs the others, or apply an irreversible command as a routine workaround.
Verify the result in the application, not just the reader
For the equipment case, an agreed verification might start by recording the identifier from the installed replacement while controlling nearby tags. The operator then opens the asset in the intended application and compares the displayed asset number and distinguishing details with the case. Where relevant, confirm that maintenance history and outstanding work remain associated with that asset.
Follow this with a representative authorised task, such as a location confirmation or inspection record, using an agreed test arrangement. The application owner defines the acceptable result and whether any production record may be changed. A demonstration should not create an unapproved live transaction merely to show that a tag reads.
The distinction between observation and business meaning is reflected in the GS1 EPCIS standard: raw RFID observations and application-level events occupy different roles. That distinction is useful even when a project does not implement EPCIS. It does not imply that AIDC GO supplies an EPCIS repository or asset-mapping software.
Include the exceptions that matter for this replacement policy: an old tag later being read, a replacement identifier already assigned elsewhere, a mapping update not confirmed, or a readable tag attached to the wrong case. Specify the expected application response and who resolves each exception. A read failure and an unconfirmed mapping update require different investigation; do not repeat encoding blindly when the saved relationship is unknown.
Keep the evidence connected: asset reference, old identifier if known, replacement identifier, tag and reader configuration, mapping-change reference, operator, time and approval. Choose retention and access rules with the responsible organisation. This is a proposed evidence set, not a promise that the device or application records it automatically.
Send a replacement requirement that can be evaluated
Bring a sample of the actual tag and asset surface, the identification fields your application uses, the intended replacement policy and a redacted example of the asset screen. State whether you need identification only, reading of additional fields, pre-encoded tags or an authorised writing workflow. Separate requirements from functions already demonstrated.
Use Integration and Support to frame model, interface and document-version questions. Ask for the specific reader configuration and available technical material relevant to those operations. The customer application team remains responsible for the mapping contract, record changes and acceptance rules unless a separate documented agreement assigns them elsewhere.
When you contact AIDC GO about the hardware configuration, include the deployment region, current reader or host, tag specification, working positions and the evidence you need to obtain. The useful purchasing question is not simply whether a new tag can be read. It is whether the proposed configuration supports its assigned part of a replacement process that your project can verify.