RFID Read-Point Acceptance Tests for Real Loads

Define the decision and the unit of measurement

Start with a specific read point and workflow: a warehouse receipt, tool issue, location check or dispatch. State what the system is expected to record and when a transaction begins and ends. A tag observed repeatedly during one passage is not necessarily several items, and an item observed near a doorway has not necessarily crossed it.

Use two denominators. Tag capture uses the number of unique expected identities physically present in the test load. Business-event correctness uses the number of expected events established independently for that run. Agree the event granularity first: one event per item movement, for example, or one event per accepted batch. Do not change that definition after seeing the results.

The GS1 EPCIS event model distinguishes event context including business steps, read points and business locations. It supports the conceptual separation used here; this worksheet is a project acceptance method, not a statement that an installation conforms to that standard.

Download the worksheet and establish the reference

Download the RFID read-point acceptance CSV. Copy its template rows for each condition and repeat. Keep the configuration version, independent reference list and raw observation export with each run. The CSV contains an illustrative calculation row, clearly labelled as hypothetical, plus blank rows for real tests. It does not contain customer results or preset passing thresholds.

The reference list must come from physically checked items, not from the same reader under test. Verify the item-to-tag association and identify any item that has no working tag. Such an item can be excluded from a deliberately defined RF capture test, but it must remain visible as an onboarding or operational failure when assessing the complete workflow.

Have the customer witness approve the expected events before running the test. Record the origin, destination, action, reference and expected item or batch identity. If the system produces the right identifier with the wrong action or location, that is not a correct business event. Preserve the comparison evidence so another reviewer can reproduce the classification.

Build a matrix from actual materials and handling

Use conditions that the operation actually encounters. Record how speed or dwell time was measured rather than labelling a pass merely “fast”. Repeat the important conditions enough to expose instability, with the number of repeats agreed before testing. A single successful pass should not become a universal read-rate claim.

Keep the installed configuration fixed within a comparable run series. If antenna position, reader power, software filtering or tag placement changes, assign a new version and rerun the affected cases. This makes an improvement traceable and prevents a final average from mixing incompatible configurations without explanation.

Count capture, misses and stray reads separately

For each run, let E be the unique expected tag identities and C the subset of those identities captured. Tag capture rate is C divided by E. Missed identities equal E minus C. If E is zero, report capture as not applicable; the run can still be useful as a negative test for stray observations or false events.

Count unique stray identities separately: tags detected that are outside the expected load or zone. Do not add them to C. Keep repeated observations of the same identity separate from the unique count as well. Repeated raw reads may be normal reader behaviour; the question is whether the software handles them correctly for the intended transaction.

For a hypothetical run with 100 expected identities and 98 captured, capture is 98%. If seven neighbouring identities are also detected, report seven stray identities alongside that result. The capture percentage remains 98%; it does not prove the zone was correctly controlled. These numbers illustrate the calculation only and are not a target or measured project outcome.

Evaluate the resulting business events

Let B be the independently expected events and K the events that match the required identity, action, location and transaction context. Correct business-event rate is K divided by B. Match each expected event at most once. Record missing or incorrect expected events separately from extra false events emitted by the system.

Continuing the hypothetical example, suppose there were 100 expected item movements but only 94 were recorded correctly. The correct business-event rate is 94%, even though tag capture was 98%. If three extra movements were posted for neighbouring items, record those three false events separately. A single percentage should not hide extra transactions that could change stock or custody incorrectly.

Inspect the failure details. A missed event may result from a missed identity, a rejected mapping or a transaction rule. An incorrect event might have the right tool but the wrong borrower. Fixing those causes requires different changes, so retain the raw observation and final application record rather than reducing the entire trial to a reader score.

Test direction, duplication and exceptions deliberately

Send a load through the read point, pause, reverse it and present it again under an agreed script. Establish whether each movement should create a new event or remain part of the same transaction. Include a valid later return so filtering repeated reads does not accidentally suppress real work.

Place known tagged objects just outside the intended zone. Check both the raw detections and the final transaction. A system can detect a neighbouring tag yet correctly exclude it from the business event; document how that exclusion is achieved. Then test whether the same rule rejects an item that genuinely enters the zone.

Where supported, test interrupted connectivity and retry behaviour without disrupting live stock records. Use a controlled test destination or clearly segregated transactions. Verify the acknowledged result in the receiving application, not just the reader screen. Record which activities cannot continue during the interruption and how staff should maintain an accountable fallback.

Set acceptance criteria and sign off the operating envelope

Agree limits for capture, stray observations, missing or incorrect events, false events and exception workload before the trial. The limits depend on the consequence of error and the available review process. A bulk count with manual reconciliation and an automatic dispatch posting may require different acceptance rules.

Review each material and movement condition as well as the combined results. An overall average can obscure a failure concentrated in metal tools or a tightly loaded container. Retain failed runs, the corrective action and the retest reference. The final decision should identify accepted conditions, exclusions and unresolved issues with named owners.

The signoff pack should include the reference lists, configuration, observation exports, event comparisons and operating instruction. Customer operations accepts the workflow, the software owner confirms destination records, and the supplier records the technical configuration. Retest affected conditions after a material change to tags, layout, mounting or filtering rules.

Apply the result to a scoped deployment

For RFID tool-crib control, include borrower, return condition and authoritative service status in event acceptance. For warehouse inventory verification, include the count boundary, location evidence and approved ERP adjustment. These are different applications of the same separation between observation and business result.

The asset-tagging and selection guide helps prepare representative samples. The asset-tracking service and logistics industry page provide the wider delivery context. Send the item types and movement layout to define a trial whose results support the actual operating decision.

Frequently asked questions