RFID Pre-Installation Guide: What to Prove Before Deployment

Most RFID installation problems can be traced to decisions that were made before the first reader was mounted. A tag was selected before it was tested on the actual object. A doorway was chosen because it was convenient for wiring rather than because it represented a meaningful process transition. Network access was assumed. The ERP integration was left for later. Or a pilot began without anyone agreeing on what would count as success.

The pre-installation phase exists to remove those assumptions while they are still inexpensive. Its purpose is not to produce a thicker project plan. It is to determine whether the proposed read points, tags, infrastructure and data flow can support the operating process the business actually wants.

Define the event before surveying the site

An RFID site survey is much more useful when the team can state the event it is trying to observe. “Track WIP” is too broad. “Confirm when this traveler leaves machining and enters inspection without requiring an operator scan” is specific enough to design around.

The event definition should include what object carries the tag, where the movement occurs, what nearby tagged material must not be mistaken for that event, and what system state should change afterward. It should also identify exceptions: what happens if an expected tag is not seen, if two items move together, or if the item moves through a different path.

This is the same discipline used later in implementation, but doing it before installation changes the survey from a general RF exercise into a process-specific feasibility test.

Survey the actual operating environment

RFID performance is shaped by the physical environment around the read point. Metal reflects RF energy, liquids absorb it, dense storage creates multipath behavior, and seemingly small differences in tag orientation can materially change the read margin. That makes a drawing or photograph useful for planning, but insufficient for final design.

We prefer to test with the real object, the real tag location and the real movement whenever possible. If the application involves a metal fixture, test the metal fixture. If pallets are wrapped and stacked, test them that way. If forklifts pass the read point at speed, include that in the pilot. The objective is to expose the inconvenient conditions before installation rather than after.

For passive UHF systems, GS1 EPC UHF Gen2 defines the reader/tag air interface. That standardization is important for interoperability, but it does not substitute for testing the application itself.

Choose the read point before choosing the reader

The most important hardware decision is often where the system should observe the process. Chokepoints such as dock doors, conveyors, cell entrances and tool-crib boundaries are attractive because movement is constrained and has an obvious process meaning. Open areas are harder because a read does not necessarily tell you whether an item moved or merely remained nearby.

More range is not automatically better. The goal is enough RF margin to capture the intended population while avoiding fringe reads that would create false events. Antenna pattern, mounting height, polarization, power and the surrounding structure all contribute to that result.

Where the problem is ad hoc search rather than automatic transition capture, a handheld may be the right answer. Where the requirement is repeated zone-level presence across a wide area, an active technology may fit better. The RFID and RTLS guide explains how those architectures differ and why the required location behavior should drive the choice.

Test tags as part of the object, not as a catalog item

RFID tag selection should account for the material, mounting method, available surface area, expected life, temperature, cleaning, abrasion and whether the identifier must be printed or encoded during an existing label process. For reusable assets, durability may dominate unit cost. For disposable packaging, conversion and encoding may matter more.

Testing multiple tag candidates is usually inexpensive compared with trying to recover from a poor tag choice after thousands of items have been labeled. We also want to see performance margin rather than a binary read/no-read result. A tag that only works at the edge of the required read distance may not survive normal variation in orientation or surrounding material.

Confirm network, power and physical access early

A technically sound read point can still become an installation problem if the infrastructure was assumed rather than inspected. Fixed RFID readers may require PoE or local power, network drops, enclosure space, cable routes, mounting hardware and access for future service. Some environments add restrictions around drilling, conduit, cleanroom penetration, hazardous locations or network segmentation.

IT and facilities should therefore be involved before the installation date is set. The objective is not merely to confirm that the reader can reach the network. It is to define addressing, firewall rules, certificates, outbound connectivity, device-management expectations and who can support the equipment after commissioning.

Lock down the identity and integration model

The tag identifier has to resolve to something the business already understands. That might be an asset ID, serial number, work order, container, pallet or another enterprise identifier. The mapping should be defined before the first production data is generated.

The same is true for event flow. Which system is authoritative for the object? What transaction is created when the RFID event occurs? Does the event update the ERP automatically, propose an action for approval or merely create an exception? Our integration guide covers these choices in detail.

Where interoperability across applications matters, GS1 EPCIS provides one established model for visibility events. Even when EPCIS is not used, separating the raw observation from the business event is a useful design principle.

Build a pilot around acceptance criteria

A pilot should answer the uncertainties that would otherwise make a full deployment risky. If an existing system is already producing inconsistent results, the RFID failure-diagnosis guide helps separate tag, RF, event-logic, identity and integration causes before the pilot scope expands. Those uncertainties may be RF performance, tag durability, fringe reads, operator behavior, network reliability, integration latency or the economic value of the process change.

Acceptance criteria should therefore be specific to the use case. The team may require that a tagged container crossing a portal be assigned the correct location while containers staged beside the portal are ignored. A handheld search pilot may measure time-to-locate. A WIP pilot may measure whether each transition is captured and whether the ERP state follows correctly.

The important point is to define those tests in advance. Otherwise a pilot can produce a great deal of interesting data without giving the organization a clear reason to proceed or stop.

Plan for security and support before go-live

RFID readers are networked devices and should be treated as part of the normal security architecture. Credentials, network segmentation, software access, logging, certificates and patching responsibilities should be decided before production use. NIST SP 800-98 provides a useful platform-independent overview of RFID security and privacy considerations.

Support ownership matters just as much. When an antenna is moved, a switch is replaced or a certificate expires, the plant should know which team owns the first response. The more the RFID system becomes part of daily operations, the less acceptable it is for every issue to require rediscovering how the original deployment worked.

Pre-installation is where the project earns the right to scale

A well-run pre-installation process should leave the team with fewer unknowns: the use case is measurable, the tag is proven, the read point has adequate margin, infrastructure is ready, the event model is agreed, integration has an owner and the pilot has acceptance criteria.

At that point, installation becomes execution rather than experimentation. If the pre-installation work reveals that the original concept will not work reliably, that is also a useful result. Discovering the problem before hardware is spread across the plant is exactly what this phase is supposed to accomplish.

FactorySense deployments show why this work matters. In the Honeywell WIP deployment, the useful result was not simply replacing one RFID technology with another. The project redesigned physical read points and event logic around the production process so the resulting WIP data could be trusted.

Once feasibility is proven, the broader RFID implementation guide covers how to move from a validated pilot into a repeatable production deployment.