Concepts and Fundementals

Filtering and Collection

TagNet Event Subscription Model

Filtering & Collection (F&C) is the key module that brokers Tag event data from Physical Readers to enterprise Systems. While the Reader Management Module builds the core definitions of Physical & Logical Readers, F&C enables enterprise applications to subscribe to Tag Events that are of importance to their day-to-day processing.

F&C is actually a series of key functions that enables the scheduling, monitoring, logging, and subscription rules that bring specific tag data to nominated enterprise applications. F&C supports a number of integration models from real time to batch integration depending on the importance of the EPC information. Figure F1 below portrays that architecture.

Figure F1. Filtering & Collection Architecture

The key functions of F&C as shown in Figure 1 are described below:

Tag Event Subscription Components

This enables a user to define ‘Schedules’ dictating what time periods a reader portal or Read zone should be active and listening for Tag events. A reader typically has no awareness of ‘time’ and this schedule tells it when to wake up, when to report data, and when to shut down. Attached to a specific Reader schedule are ‘Bindings’ that determine what business logic to apply to the tag events at the reader location. This also determines how a subscribing application should be notified of a tag event (file format + transport method) as well as what optional filters should be applied. Examples of such are:

❖RFID portal (Logical Reader) where tag event occurred

❖Range of Time tag event occurred

❖The type of tag number (SGTIN, SSCC, UID, etc.)

❖The type of tag Object type (Case, Pallet, etc.)

❖Other Object Master values

All of these values can be filtered using Boolean logic. Essentially this is a Publication/Subscription model (or pub/sub) where schedules ‘publish’ tag information and various systems ‘subscribe’ to that.

Event Monitor

Logical Reader Schedules are managed by an Event Monitor that brokers those tag reads to the tag event logging database that happens real-time as those events occur. Based on the reporting duration specified in the Reader Schedule profile, the event monitor then searches through the subscription bindings for that Reader location looking for patterns matching that logged tag data. . If matches are found, then the tag data is sent to the subscribing application in the format and transport method specified in the Binding definition. This completes the loop. Note: It is quite conceivable that many subscriptions could exist requesting the same data or different elements of that data

Integration Models

Listed below are various integration levels supported by F&C from very simple to complex and some use cases that will help you decide which approach your installation wants to take:

From an integration perspective there are two types of subscribers, synchronous and asynchronous. A synchronous binding is the one that has priority of the read event cycle controlling both business logic as well as the resultant GPIO at the read source (bi-directional traffic). Asynchronous bindings only receive event data at given intervals and have no control of the read cycle (data is unidirectional). There can only be ONE synchronous Binding per Reader Schedule, however there can be unlimited asynchronous Bindings. See Event Bindings for more info

Near Real Time Batch (Asynchronous)

If it is not critical that the tag data be reported immediately, use this method. Such examples would be every hour or at end-of-day. Tag data could in fact be reported within minutes of the event occurrence however this may cause heavy resource usage based on a factor of the number of subscriptions for a given reader multiplied by the duration of reporting periods.

Use Cases

❖Order Shipping History

❖Inventory Movements within a Plant or Whse

❖Time & Attendance at a worker entranceway

Real Time (Synchronous)

If the tag data is important to update mission critical systems immediately (as the event happens) then this method should be used.

Use Cases

❖Inventory Transactions such as issue WIP, VMI or Kanban

❖Asset management to notify when assets enter / leave key areas (and by whom)

Real Time with response (Synchronous)

If the tag event requires instantaneous enterprise response to validate the event via signal lights (good/bad/caution) or PEV, then this method should be used.

Use Cases

❖Ship / Verify – validating that specific tags are destined for a given dock door that is associated with a given customer Order. Note: requires that ERP/WMS has associative portal ID/Order# intelligence to validate tag movement on a given dock door.

❖Inbound ASN verification - ensures that material received from receiving dock door matches ASN by means of tag association.

❖Moving QC controlled tags from one location to another (for example from to shipping area). If tag Lot number is on hold, then notify lift-truck operator immediately via stack lights

❖Access Control – either on a jobsite or building entranceway validating the credentials of the given individual as they enter.

❖VIP notification – mostly in hospitality industry to notify floor staff of person arriving as well as identifying targeted customers via their loyalty cards as they enter establishment. Intent is to greet them personally based on event information provided by TagNet notification.