AutoID
| Document | OPC 30010 |
|---|---|
| Version | 1.01 |
| Published | 2020-06-18 |
| Namespace | http://opcfoundation.org/UA/AutoID/ |
| Sector | Traceability |
OPC UA for AutoID standardises identification devices: RFID readers, barcode and 2D code scanners, OCR readers and RTLS locating systems. It models the device, its scan settings, and a common scan result structure with the code, its type and timestamps, so traceability code does not have to be rewritten per reader.
Where it sits in the stack
AutoID is built on DI, so every reader arrives with the DeviceType identification nameplate before anything AutoID-specific appears. It is a device model, not a production model, and it is genuinely reusable: the scan result structure is the same shape whether the code came from an RFID tag, a barcode or OCR, which is why AutoID is the one companion spec that reliably pays for itself in a traceability project. AUTOID is a registered server capability code, so readers can be found by capability. Pair it with Machinery Jobs or ISA-95 Job Control for the order context that gives a scanned code meaning.
The types that matter
| Type | What it carries |
|---|---|
AutoIdDeviceType | The abstract base for every identification device, derived from the DI DeviceType. It carries the scan and configuration structure that the concrete reader types share. |
RfidReaderDeviceType | An RFID reader, with the tag-level operations that only RFID has: reading and writing tag memory, locking and killing tags, and the antenna and sighting information. |
OpticalReaderDeviceType | A barcode or 2D code reader. The result carries the decoded string plus the code type, which is the field most integrations forget they need. |
OcrReaderDeviceType | An OCR reader, where the result also carries a quality or confidence figure because the read is probabilistic rather than exact. |
RtlsLocationDeviceType | A real-time locating system, which reports positions of tagged assets rather than discrete scan events. |
ScanData | The identifier itself, modelled as a union so the same field can carry a byte string, a plain string or an EPC-style structure without the client having to guess. |
ScanResult | The base scan result: the ScanData, its code type, a status and a timestamp. Subscribe to this rather than reconstructing scans from device tags. |
RfidScanResult | The RFID-specific result, adding the sightings that produced the read so you can tell which antenna saw the tag and how strongly. |
RfidSighting | One antenna observation of a tag, with strength and timestamp. Multiple sightings for one tag are normal and are how you filter out reads from the neighbouring station. |
ScanSettings | The scan configuration: duration, cycles and the data to include. Getting these right in the device rather than in your client is what stops duplicate reads. |
Using it on a real machine
- Find readers by capability, then by typeLook for the AUTOID capability code, then check NamespaceArray for http://opcfoundation.org/UA/AutoID/ and browse for instances typed on the concrete reader types. On a gateway serving many readers this is much faster than walking the tree.
- Read the DI nameplate before the scan dataSerial number, manufacturer and software revision come from the inherited DI identification. Capture them once per reader so a swapped device is visible in your data rather than silently changing behaviour.
- Subscribe to scan events, do not poll the last resultReading the last scan result on a timer loses reads whenever two parts pass within one interval. Use the scan event so every read arrives with its own timestamp, and set a queue size greater than one so bursts are not discarded.
- Always store the code type with the codeThe same digits can be a different identifier under a different code type, and ScanData is a union. Persist the code type and the union discriminator alongside the decoded value, or your traceability records will collide eventually.
- Filter sightings, not eventsFor RFID, tune the read power and the scan settings on the device and use the sighting strength to reject stray reads. Filtering duplicates downstream is possible but you lose the ability to distinguish a genuine re-read from a neighbouring antenna.
What it gives you for OEE
Little directly. AutoID has no state machine, no availability model and no cycle counter, so it contributes nothing to availability and nothing to performance on its own. What it does contribute is part-level attribution, which is what makes quality figures defensible: a scanned code lets a reject at the end of a line be tied back to the part, the lot and the order rather than counted anonymously. In practice AutoID becomes an OEE input indirectly, as the genealogy layer that lets you split scrap by material lot or by upstream station. Availability and counts still come from Machinery, PackML or the machine's own tags.
Gotchas
- ScanData is a union. Clients that treat it as a string work until the first reader that returns a byte string or an EPC structure, then fail at decode time rather than at design time.
- Version 1.01 dates from June 2020 and the model has been stable since. That is fine for stability, but it means AutoID has none of the newer Machinery conveniences and no result linkage to Machinery Result.
- Vendor implementations differ most in the methods. Tag write, lock and kill operations are commonly absent or disabled even where the read path is complete, so confirm what is executable rather than what is browsable.
- One physical reader can appear as several devices behind a gateway, or several antennas can appear as one device. Establish which before you map reads to stations.
Once the machine speaks a companion spec, the OEE mapping is portable across vendors, which is the point at which analytics stops being a per-machine project.
See Jemba →Last verified 7 September 2026 against OPC UA 1.05.07. Version and publication date read from the released nodeset. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.