WebSphere brand IBM WebSphere Premises Server, Version 6.1.x

Enhanced dock door receiving example usage scenario

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

  1. An attendant moves the pallet toward the portal.
  2. 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.
  3. 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.
  4. 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.
  5. 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
  6. 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.
  7. The PortalControllerAgent issues a message to stop the reader and tells the aggregation agent to terminate the cycle.
  8. 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.

  1. The portal read cycle starts when the sensor detects motion.
  2. 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.
  3. 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.
  4. 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.)
  5. The PortalControllerAgent receives a sensor topic and reacts on it.
  6. Back to the scenario, Motion = On starts the reader and the aggregation cycle begins.
  7. Tags might be read.
  8. The reader publishes a reader tag read topic to the filter agent and the aggregation agent.
  9. The reader agent filters out duplicates and all tags except SSCC tags (pallet tags).
  10. For new SSCC tags, the reader agent publishes a tag read event to the WebSphere Premises Server.
  11. The reader agent puts the tag reads in a list, indexed by EPC code.
  12. During the aggregation cycle, the motion sensor might go off, but the reader continues reading tags.
  13. 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.
  14. 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.
  15. The PortalControllerAgent turns off the reader and terminates the aggregation cycle.
  16. 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.
  17. The WebSphere Premises Server sends each single tag read event and the aggregated list to the Integration Domain.
  18. The back end responds with "Accept," "Reject," or "Acked" and sends these responses back to the Data Capture and Delivery controller.
  19. 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:
  1. In a normal health check situation, the reader is up and no sensor error messages are received.
  2. Initially, the HealthCheckAgent assumes that application ping is up and that the ApplicationPingAgent pings the WebSphere Premises Server periodically to identify connectivity problems.
  3. The HealthCheckAgent listens to sensor error messages, reader up and down messages, and application ping up and down messages.
  4. 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."
  5. Sensor agents signal an error condition if the sensor is active for too long. The error condition is cleared with a sensor state change.
  6. 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.
  7. When all errors are cleared for this portal, the HealthCheckAgent sends a message that the portal health status is "up" again.

Library | Support | Terms of use

(c) Copyright IBM Corporation 2004, 2008. All rights reserved.
U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.