This scenario is a behavior enhancement to the standard
dock door receiving example usage scenario.
IBM® WebSphere® Premises Server provides
example code for the following usage scenario. To support other usage
scenarios, you must develop your own agents or modify the example
agents.
Note: The term, portal, here is
used to indicate a dock door and its associated I/O devices. A portal
is the physical installation that enables the reading of information
when pallets move through it. A portal consists of a reader, antennas,
sensor devices, and feedback devices, such as a light tree. In a retail
dock door receiving scenario, the portal is directly behind a dock
door of a retail store or retail distribution center.
Note: The terms edge controller, Data Capture and Delivery, remote Data Capture and Delivery, and local Data Capture and Delivery all
refer to the same functional concept, and can be used interchangeably
most of the time. These terms refer to the portion of the RFID system
that interfaces directly with the physical readers, collecting the
raw data and performing some basic processing. Starting with the WebSphere RFID Premises Server 6.0
release, this functionality can run as part of the WebSphere Premises Server (local Data Capture and Delivery), or on
a separate processor (remote Data Capture and Delivery) to distribute
load. In previous versions of WebSphere RFID Premises Server, this
functionality running on a remote processor was referred to as an
edge controller. For simplicity and compatibility with previous versions
of the product, the term edge controller is still used in the product
documentation.
Overview
Goods tagged with case or pallet
tags are brought through a portal that is controlled by a motion sensor
(an entrance) and a light barrier (the exit). These tags are read
and reported to the back-end system. The back-end system returns a
validation by way of the light tree.
Note: The enhanced
dock door receiving usage scenario behaves differently than the standard
dock door receiving usage scenario. Any error (such as a sensor error,
a reader that is down, or application ping) terminates the current
pallet movement cycle. Regardless of the sensor signals, an aggregated
tag message is sent to WebSphere Premises Server and the
yellow light signals that the portal is no longer active. So when
the error condition is resolved, a motion sensor signal is required
to start a new portal read cycle. In addition, the sequence sensor
signals are different for the enhanced dock door receiving usage scenario.
When the operator is inside the portal, the motion sensor goes off
even when there is movement inside the portal. When the reader reconnects
after a short connection drop, in most cases, the motion sensor status
is "off." The operator must leave the portal, and wait until the yellow
light signals that the portal is active again before moving the next
pallet through.
The HealthCheckAgent checks
the availability of the RFID hardware and software for readiness.
Specifically, the HealthCheckAgent checks
the reader and the status of the sensors, and it checks the availability
of WebSphere Premises Server and
the back-end system. The ApplicationPingAgent is
responsible for checking WebSphere Premises Server and the
back end. The Data Capture and Delivery controller
passes a token item (a message with a timestamp) to WebSphere Premises Server and from
there it might be forwarded to the integration domain (a back-end
system with which WebSphere Premises Server can integrate
through WebSphere MQ,
for example). Then, the integration domain passes the token to the
back-end system. The back-end system returns the token to the integration
domain where it passes the token by way of WebSphere Premises Server back
to the Data Capture and Delivery controller.
The termination outcome is "successful." If the token is not returned
within a configurable time frame (a system malfunction), the ApplicationPingAgent returns
a negative result (the termination outcome is "failure") to all HealthCheckAgents
that are on the Data Capture and Delivery controller.
The HealthCheckAgent informs
the PortalControllerAgent about
changes in the portal health. The PortalControllerAgent might
signal either the portal health or reader activity using the yellow
light on the light tree.
Four additional agents that play an
important role in the enhanced dock door receiving usage scenario
are listed below:
- HealthCheckAgent
- ApplicationPingAgent
- PortalControllerAgent
This usage scenario assumes the following preconditions:
- The system consists of
- a dock door with a RFID reader
- a motion sensor
- a light barrier
- a light tree with red, yellow, and green lights
- an audio device
- a Data Capture and Delivery controller
- WebSphere Premises Server
- a back-end system
- The system is active, and the portal is operable ("healthy") and
working.
- The portal is activated.
- The reader is not reading.
- The red and green lights are off.
- All sensors are inactive.
- A yellow light signals that the portal is operable (“healthy”).
Note: You can configure how the yellow light signals the portal
health status. By default, the light “on” signals that the portal
is operable. The light “off” means that there is a problem with one
of the sensors or the reader, or that the WebSphere Premises Server or back
end is not available. To avoid the yellow light being on throughout
the day, configure the light tree agent to signal error conditions
by the light being on.
Usage Scenario
- An attendant moves the pallet toward the portal.
- A motion sensor connected to the reader, which is connected to
the Data Capture and Delivery controller,
is tripped by the movement of an item through the portal and triggers
the start of the new aggregation cycle.
- The portal controller agent, also subscribed to the motion sensor
topic, registers the event and publishes a message to the reader to
begin reading tags.
- During the aggregation cycle, the Data Capture and Delivery controller
filters duplicates and stores the gathered EPC codes in a list. For
tag read events from pallet tags (containing SSCC codes), the system
immediately converts them into EPC-ID format (configurable) and forwards
the read event to the Integration Domain.
- By way of the Integration Domain, the back-end system validates
each tag-read event with a response code of Accept, Reject, or Acked
(acknowledged). This response appears in the Tag History on WebSphere Premises Server. Depending
on the validation result, the light tree shows:
- green - accept
- red - reject
- no change to the light tree - acked
- When the pallet is inside the portal, the motion sensor goes off,
but the reader is still reading tags. When the pallet leaves the portal,
the light barrier's light beam is, at first, interrupted by the pallet.
The light barrier sensor reports "blocked" to the Data Capture and Delivery controller.
When the pallet completely leaves the portal, the light barrier signals
"unblocked" again. This signal is the trigger that indicates the end
of the aggregation cycle.
- The PortalControllerAgent issues
a message to stop the reader and tells the aggregation agent to terminate
the cycle.
- A list of all tags read is sent to WebSphere Premises Server. The
back end sends a validation response in response to the aggregation
list. If the back end identifies this shipment as incomplete (for
example, a pallet is missing on a stacked pallet), the back end might
return a validation of "Reject" and the light tree would show a red
light. Under normal conditions, the validation would be "Acked" and
nothing changes on the light tree. In any case, this ends the enhanced
dock door receiving usage scenario.
Agent logic
This section describes how the
agents work together in the enhanced dock door receiving usage scenario.
- The portal read cycle starts when the sensor detects motion.
- Because portal sensors are mostly connected to I/O ports of the
reader, the I/O agent processing this signal is usually part of the
reader agent. The I/O agent publishes an I/O event message on the
messaging service inside of the Data Capture and Delivery controller.
- The UniversalSensorAgent has
several instances, such as Motion or Barrier for one portal. These
instances, called sensor agents, are identified by their alias names.
These alias names and the portal ID of the UniversalSensorAgent configuration
make up a unique ID on the messaging service, such as Motion-P1 and
Barrier-P1. The I/O event is received by the corresponding sensor
agent, which performs some processing, such as inverting input to
output, delaying the change to inactivity (inactivity timeout), and
checking for sensor error situations, such as a blocked light barrier.
- After processing, the sensor agent publishes a sensor topic (not
an I/O topic) with a defined meaning of its values "On" and "Off."
(Barrier = On means that the barrier is interrupted and Motion = On
means that motion is detected.)
- The PortalControllerAgent receives
a sensor topic and reacts on it.
- Back to the scenario, Motion = On starts the reader and the aggregation
cycle begins.
- Tags might be read.
- The reader publishes a reader tag read topic to the filter agent
and the aggregation agent.
- The reader agent filters out duplicates and all tags except SSCC
tags (pallet tags).
- For new SSCC tags, the reader agent publishes a tag read event
to the WebSphere Premises Server.
- The reader agent puts the tag reads in a list, indexed by EPC
code.
- During the aggregation cycle, the motion sensor might go off,
but the reader continues reading tags.
- To end an aggregation cycle, motion must be off and the light
barrier must have transitioned from the "unblocked" state to "blocked"
and back to "unblocked" to signal the end of the pallet.
- There might be a delay in the blocked to unblocked transition
by the sensor agent to make sure that every tag at the end of the
pallet has been read.
- The PortalControllerAgent turns
off the reader and terminates the aggregation cycle.
- When the TagAggregatorAgent receives
the "end of aggregation" message from the PortalControllerAgent,
it sends the complete list of received tags to the WebSphere Premises Server, and
then clears the list.
- The WebSphere Premises Server sends
each single tag read event and the aggregated list to the Integration
Domain.
- The back end responds with "Accept," "Reject," or "Acked" and
sends these responses back to the Data Capture and Delivery controller.
- The light tree signals an "accept" message with a green light
and a "reject" message with a red light.
Independent of the portal read cycle, the
Data Capture and Delivery controller
constantly monitors the portal status for error conditions (health)
and actively checks the availability of the
WebSphere Premises Server by way
of the Integration Domain up to the back-end system:
- In a normal health check situation, the reader is up and no sensor
error messages are received.
- Initially, the HealthCheckAgent assumes
that application ping is up and that the ApplicationPingAgent pings
the WebSphere Premises Server periodically
to identify connectivity problems.
- The HealthCheckAgent listens
to sensor error messages, reader up and down messages, and application
ping up and down messages.
- When an error message arrives, the HealthCheckAgent publishes
a message on the messaging service to tell the PortalControllerAgent that
the portal health status is currently "down."
- Sensor agents signal an error condition if the sensor is active
for too long. The error condition is cleared with a sensor state change.
- The ApplicationPingAgent signals
an error when no response to an application ping message is received
within a specified time period (response timeout). Receiving a response
to a ping message (called a pong message), in time, clears the error
condition.
- When all errors are cleared for this portal, the HealthCheckAgent sends
a message that the portal health status is "up" again.