IoT & Device Integration

RFID in Manufacturing: What a Tag Read Proves – and When Barcodes Are Enough

In manufacturing, RFID can capture material identifiers without a deliberate handheld scan and may read several identifiers in a single pass. That alone does not establish whether a container was actually transferred, staged at a workstation, or used in a production step. What matters is the selected read point, how observations are filtered, and what additional evidence supports the operational conclusion. Where a manual scan is already coupled with a required confirmation, a barcode or Data Matrix code may remain the simpler and more economical choice.

Author:
Schematic example: RFID read point on a material path with reusable containers; beside it, a card: three reads, two transfers – container B-752 was read but not transferred.

Three containers at a read point: What does a tag read establish?

On their way to a production workstation, two tagged reusable containers pass through an RFID read zone. BOX-731 and BOX-746 are intended to be captured at LP-42, and both identifiers appear in the raw read data. BOX-752 is standing nearby. Its tag is also within range and is read even though the container has not passed through the transfer point. In this fictional example, BOX-731 is subsequently taken for order PO-208, while BOX-746 is set aside.

The three identifiers in the read data initially answer a limited question: Which tags did the reader detect under the prevailing reading conditions? They do not prove that all three containers passed through the transfer point, or that any of them was consumed for the order. This remains true if the reader recorded the same identifier repeatedly and a downstream component removed those repetitions.

Stray reads are not merely theoretical. In a peer-reviewed study of a warehouse exit gate, Alfian and coauthors explicitly describe tags that are within the reader's range but do not pass through the gate.[1] This example is useful when evaluating the design of read points. However, neither the test conditions nor the reported error rates can be assumed to apply to a manufacturing environment without measurement.

The operational question is therefore not simply whether an identifier was read. It is: What action can the organization reasonably infer from that observation, and what additional information is needed to support that inference?

Deliberate scanning versus automatic reading: What changes in the workflow?

Barcodes and Data Matrix codes are read optically. The code must be accessible and within a suitable line of sight of the scanner. RFID can detect appropriately equipped tags without a direct line of sight; depending on the solution, multiple tags may be read during a single pass.[2] This creates an opportunity to eliminate repetitive handheld scans at material transfer points.

Changing the capture method also changes the nature of the evidence in the production process. A person who deliberately selects and scans a code performs a specific input action. An automatic RFID read, by contrast, may occur without anyone touching or transferring the container in question. Automation may eliminate an input step, but it does not automatically establish that an operational action took place.

Question in the production workflow Deliberate optical scan Automatic RFID read
Which identifier is captured? The identifier encoded in the selected, scanned code Identifiers detected within the radio-frequency read zone
What does capture establish? The code was read The tag was detected under the prevailing reading conditions
What still needs to be established? Whether selection, transfer, or use was correctly attributed Which tagged objects were actually moved, transferred, or used
What makes the recorded action reliable? The relevant order or work step and any required confirmation The relevant read point, context checked for plausibility, and any required confirmation

Whether an identifier denotes a material type, a batch, or an individual container depends on its level of identification, not on whether it was read optically or by radio. RFID changes when and without whose direct action an identifier is captured; it does not change what that identifier denotes.

When RFID pays off – and when a barcode or Data Matrix code is sufficient

RFID is not economically justified simply because several identifiers can be read automatically. The relevant question is how much work is actually eliminated from the operational workflow. GS1 does not describe RFID as universally superior, but as an application-dependent alternative. Optical codes may be less costly and can also serve as a fallback.[3][4]

If an operator must pick up a container anyway, check that it is assigned correctly, and explicitly confirm its removal, RFID may eliminate only the handheld scan. The work step, the responsibility, and any required operational check remain. At frequently used transfer points involving large numbers of reusable load carriers, however, automatic capture may eliminate a meaningful amount of repetitive manual work.

Each proposed read point therefore requires a comparison between the current workflow and a trial RFID workflow:

What to measure during the trial Why it matters
Number of movements and handheld scans per week, and the time required for each capture Establishes how much manual work can actually be saved
Required confirmations or inspection actions Shows what must remain in place despite RFID
Number of tags, durability, and reuse cycles Affects cost per use
Readers, installation, integration, and validation where required Count toward total cost, not just the tag price
Stray reads, missed reads, investigation time, and rework May consume the time savings
Fallback procedure when a read fails or is ambiguous Determines the real operational effort

Stop criterion: If investigating exceptions consumes the scan time saved, or if the required confirmation remains unchanged and scanning already takes very little time, RFID offers no convincing additional benefit at that read point. This is not a general verdict on RFID; it is a decision about a particular material transfer.

Read zones and raw reads: Stray reads, bulk reads, and missed reads

An RFID read zone is, first and foremost, an area in which tags can be detected. It does not, by itself, define a reliable physical boundary for a material transfer. A reader may observe several nearby tags. That does not establish whether those tags followed the same physical path.

Three failure modes need to be distinguished during a trial:

  • Stray read: An identifier is captured even though the corresponding container did not pass through the intended transfer point. In the example, this is BOX-752. The literature describes this failure mode for a studied warehouse gate.[1]
  • Bulk read: Multiple identifiers appear within a single read window. This may be intentional when load carriers move together, but further context is needed before assigning every identifier to the same order or transfer.
  • Missed read: An expected tag is absent from the read report. That does not necessarily mean the container was absent. Actual absence must first be distinguished from a gap in capture.

The radio environment and the way a tag is attached can influence reading behavior. Specific claims about metals, liquids, antenna positioning, or read ranges should therefore be based on the intended application and reliable tests. No general detection-success rate is asserted here.

The distinction from a duplicate optical scan matters: the problem is not only repeated capture of the same identifier, but also the incidental reading of a different identifier that does not belong to the operation. The capture technology alone cannot always make that operational distinction.

From raw reads to operational events: Keeping ALE and EPCIS distinct

Several processing steps may occur between an RFID reader and an operational record. The GS1 Application Level Events (ALE) 1.1.1 specification describes an interface through which reads can be collected and filtered in event cycles. Repeated observations of the same tag identifier within an event cycle are represented as a set without duplicate entries. ALE also supports reports of the current set of observed identifiers (CURRENT), identifiers newly observed relative to a preceding cycle (ADDITIONS), and identifiers no longer observed (DELETIONS).[5]

This consolidates a stream of raw reads; it does not establish that a material movement occurred. If BOX-752 remains beside LP-42 and is observed for the first time, its identifier may appear as an addition in the relevant report. “Newly seen” does not mean “newly transferred.”

GS1 EPCIS provides an event model for placing observations in an operational context. An observation must be distinguished from a claim that something was processed:

  • An ObjectEvent can record that identified objects were observed. The OBSERVE action denotes observation, not material transfer. Business meaning arises only from the contextual information that the capturing application assigns to the event and its business step.[6][7]
  • readPoint identifies where the event was captured. bizLocation, by contrast, indicates where the relevant objects are assumed to be after the event. That latter information is determined by the capturing application; it is not an independently measured value from the RFID reader.[6][7]
  • A TransformationEvent records that input objects or quantities were consumed and output objects or quantities were produced. The capturing application thereby makes an operational assertion about a transformation. A read at a gate, on its own, does not substantiate that assertion.[6][8]

For manufacturing, the distinction can be expressed as a sequence:

Raw read → filtered observation → event interpreted in operational context → confirmed action, where supported by additional evidence.

This sequence is an editorial explanatory model, not a mandatory technical pipeline. An RFID-based capture system needs explicit rules establishing when progression from one type of assertion to the next is justified.

Even a filtered identifier must then be associated with the relevant source, object, and active work step. Whether the material was later actually used in a batch is something the radio read cannot show.

Trial a read point before expanding automatic capture

Before RFID is deployed widely in manufacturing, one clearly defined production transfer should be tested. At LP-42, for example, the physical passage, the read zone, and the later operational record must be treated as distinct. The aim is not to capture as many identifiers as possible, but to produce the correct operational assertions with an exception-handling process that can be managed reliably.

The trial should cover both intended movements and counterexamples: two containers passing together, a nearby container that does not pass through, a missed read, and a passage whose identifier is confirmed only later. For each scenario, the record should show which raw reads occurred, which identifiers were reported after filtering, what operational record was eventually created, and why that record was justified.

Three results determine whether to expand the deployment. How many of the handheld scans required today are actually eliminated? How often does capture remain ambiguous, and how long does resolving each case take? Are the confirmations, controls, and fallback workflows needed by the operation still available? Only when these questions can be answered satisfactorily for the actual workflow is it reasonable to add more read points.

A trial may legitimately result in a decision not to use RFID. That is a useful operational outcome if barcodes or Data Matrix codes provide the required evidence in the same workflow at lower total cost.

Architecture example: Connecting capture and decisions within production

In one possible process architecture, the identifier at the read point, the technical observation, and the operational record are stored separately or linked while remaining distinguishable. For example, an application could record a raw read of BOX-731 at LP-42, check its association with PO-208, and record a transfer as an operational event only after the required confirmation. For BOX-752, it should remain visible that a radio read occurred but no transfer was confirmed.

This separation makes discrepancies traceable. What was observed technically? Which rules governed the interpretation? Who – or which approved process – confirmed an action? Which information was changed in a later correction? The evidential value of the result does not depend on the number of tags captured, but on whether the transitions between these levels are justified.

Primary sources and further reading

  1. Alfian, G.; Syafrudin, M.; Yoon, B.; Rhee, J. (2019): False Positive RFID Detection Using Classification Models, Applied Sciences 9(6), 1154. DOI: Publisher edition. Study context: a warehouse exit gate; detection rates must not be transferred to manufacturing without verification. ↩
  2. GS1, GS1 System Architecture Document 9.0, Section 5.4.2 on RAIN RFID and optical data carriers. Original standard. ↩
  3. GS1 FAQ, What are the benefits of RAIN RFID technology? Original source. ↩
  4. GS1 FAQ, Will RAIN RFID replace barcode technology? Original source. GS1's position on cost, alternatives, and fallback use. ↩
  5. EPCglobal/GS1, Application Level Events (ALE) 1.1.1, March 13, 2009, Section 5.2 (printed pp. 31–33) and Section 8.2.6 (printed pp. 95–96). Standards page; accessible PDF mirror. Latest published edition according to GS1's version listing; not a regulatory requirement. ↩
  6. GS1, EPCIS Standard. The retrieved document identifies itself as Release 2.0, ratified June 2022: Section 7.3.5 (readPoint and bizLocation), Section 7.4.2 (ObjectEvent), Section 7.4.5 (TransformationEvent). The current edition is EPCIS 2.0.1, dated July 1, 2025. Version archive. The section references given here refer to the inspected Release 2.0 text. ↩
  7. GS1, EPCIS/CBV Implementation Guideline and GS1 EPCIS vocabulary fields (readPoint, bizLocation, action). Vocabulary source; implementation guideline. ↩
  8. GS1, EPCIS Linked Data Model, TransformationEvent. Original source. ↩