|
RFID PacketTester is a general purpose Conformance and Stress Tester platform for quickly developing RFID protocol test suites. The platform itself is protocol independent. The test scripts are protocol dependent but the actual runtime environment is same for all protocols. This platform has been used for WiMAX and WiFi testing as well.
PacketTester will help developers debug their software and hardware by generating and sending a known sequence of packets based on some predefined triggers. The user can specify the sequence of packets comprising a test and the test can be run repeatedly until the problem is fixed. There are some predefined test scripts (event sequences) for the basic tests but user has the ability to define and write new tests.
|
| |
PacketTester Structure
One of the key emphases of PacketTester is Test Automation. This is done by grouping diversified tests and running them completely in unattended mode. This reduces the engineering time to complete the QA cycle.
The RFID PacketTester is customized for RFID protocols using the generic PacketTester as the baseline. It will help the user to recreate a customer problem at the development lab. Although it was originally built to test Readers and the Middleware servers, Client or Host Application can also be tested with this. It is worth noting that the RFIDness is localized in the PacketBuilder part of the software only and the TestEngine and Test Scripting are independent of RFID. The TestEngine is the runtime software, which runs the individual tests and the test groups.
Another supporting utility is the RFID Miniscope Decoder. The PacketTester can be configured to forward the received/transmitted packets to the Miniscope Decoder, Miniscope will show both the received and transmitted packets with protocol specific decodes.
RFID PacketTester has four modules:
The correlations between these modules are illustrated in the supporting figure.
|
 |
| |
RFID PacketBuilder
The RFID PacketBuilder is a standalone offline software entity. It creates RFID packets based on user inputs. The PacketBuilder runs from a menu driven windows interface to create RFID packets. PacketBuilder builds the packets one at a time and keeps them in a packet repository (illustrated as Packet Library in the above figure). The PacketBuilder module is RFID protocol aware. The packet types depend on the interface selected.
When a packet is created, it is usually associated with a direction parameter also. It can be upstream or it can be downstream. However, there is a generic packet type where the user can specify binary data in hex format. The generic packet format can be used for any packet type and no format checking is performed.
PacketBuilder does not need any configuration. PacketBuilder does not maintain any state variable.
Once the packet type has been chosen, it shows a default packet structure with all fields needed to create that packet type. For each field, default parameters are chosen. The user has the option of modifying some, all or none of the fields with user defined field parameters. Once the packet has been validated for that packet type, it is saved in a file with a packet id inside Packet Library.
The packets so built can be viewed and edited at any time and saved in the packet repository again. The text, binary and XML packet formats are used for building and viewing the packets. The packets so built will be used by TestBuilder to create specific test scripts.
|
| |
| Top |
| |
RFID TestBuilder
The TestBuilder builds individual test cases to test a specific functionality by selecting the packets to be received, packets to be transmitted and adding the trigger conditions in sequencing the packets. It uses constructs like:
If packet id nn is received on interface X, and trigger condition T is satisfied, transmit packet id mm on interface Y, transmit packet id pp on interface Z and wait for packet id kk.
- When packet id 231 is received on interface id 2, then send packet id 45
- When packet id 12 is received on interface id 1, then send packet id 34 on interface 1, packet id22 on interface 2 and packet id 26 on interface 1
- Send packet id 32 in interface 1, expect packet id 22 using a mask (don't care). If the comparison fails, stop the test, mark it failed and end the test. If the comparison passes, mark the test step as passed and go to the next test step
Note: A mask may be used to check the receive condition. In the example above, the user can state that only the command field in the packet Id 231 to be checked to satisfy the receive comparison condition. This implies that other fields in the packet do not need to match. The user can always specify that the whole packet needs an exact match to satisfy the receive comparison condition. The TestEngine just blindly follows the trigger rules without knowing the protocol significance. However, the comparison logic is integrated with TestEngine module, and always triggered by scripts built with TestBuilder.
The comparator works differently for different message formats. The paragraph above describes how it works on text or binary formats. In case of XML message format, same message can be coded quite differently. For XML message format, both expected and received packets are converted to a canonical format and then compared by means of an XML tool.
Note: The TestBuilder is not RFID protocol aware. The TestBuilder saves these test scripts in a file for use at run time. This file can be seen as a test repository (illustrated as Test Library in the above figure).The tests are ordered by classes and categories. The typical classes are:
- Mandatory Tests: A DUT must pass these tests to get EPCglobal certification.
- Optional Tests: These are not required by a DUT to support, but if implemented, the DUT should pass these tests.
- Negative Tests: These will test the robustness of a DUT implementation.
|
| |
| Top |
| |
RFID TestEngine
RFID TestEngine (TE) is the heart of the PacketTester. When TE is started, the user can configure the testing environment such as IP addresses, port numbers, URL, transport binding, message formats etc. It reads the tests and executes the test step sequences based on the associated pass/fail conditions. A typical test step sequence is like: it will send a predefined packet and wait for an expected packet; when a packet is received, it is compared against the expected one.
TE is a passive tool, as it does not generate any traffic by itself. It generates traffic only when a specific trigger condition is met based on the received packet.
It has a main execution thread along with separate execution threads for each of the interface it supports. The execution threads are running concurrently. The test scripts generated by the TestBuilder control the functioning of each thread.
There is a configuration file, which specifies the URL, IP addresses and the ports etc for each of the connection.
As the TE is running, a message test sequence diagram is created and displayed on real time. This diagram is helpful to understand visually what packets types are transmitted to and received from each of the interfaces. The TE screen is divided into three panes: test listing display, runtime activities and sequence diagram. The entire proceedings can be saved to a file for later viewing and analysis. The test can be run one at a time in manual mode or in a group (created by choosing the tests and giving a group name) to automate the running in unattended mode. Generally, there are two types of tests: those, which can be run in unattended mode, and those which need operator intervention. In case of operator intervention, the TE will display a message asking the operator to do certain things (such as removing a tag from the field of the reader), wait for the operator to complete the action and then continue.
The transmitted and received packets can be forwarded to the RFID Miniscope decoder for real-time decode and analysis of the packets on a field by field and on a bit by bit basis. While the packets are being forwarded to the Miniscope, it is also saved in a log file. This log file can be run offline with the Miniscope. |
| |
| Top |
| |
RFID Miniscope Protocol Decoder
The Miniscope is a general-purpose protocol decoder developed by Polaris Networks. This platform has been used past several for other wireless protocols such as WiFi (802.11), WiMAX (802.16) and ZigBee (802.15.4).
In RFID version of Miniscope, all the standard Miniscope features are available and additional RFID and EPCglobal specific enhancements have been made. The look and feel has been kept similar in line with ethereal philosophy.
The RFID Miniscope Decoder/Analyzer is a separate run time executable, which can be run in conjunction with the TestEngine to monitor, decode and analyze the protocol specific payload packets exchanged between the Tester and the Device under Test (DUT).
Miniscope breaks down each packet on a bit/byte level and field level and displays the content in more understandable format using the EPCglobal specification formats. The Miniscope may run remotely over an IP connection or it may be run locally in the same machine where TestEngine is running. The remote running capability allows some one to monitor the testing progress from a remote site.
Executing the Miniscope is optional. If the user so chooses, the Miniscope can be turned off at run time. The exchanged packets are always saved in a file in a Miniscope file format. Miniscope has an option to run the decoder off line using the saved file.
When Miniscope is run in conjunction with the TE, if you double click on a test sequence, it is reflected on the Miniscope screen by highlighting the corresponding data stream. |
| |
Supported RFID protocol interfaces
Following RFID, interfaces are currently supported by the RFID PacketTester platform for Conformance and other categories of testing.
- Reader Protocol 1.1 (RP1.1)
- Application Layer Events 1.0 (ALE1.0)
- Reader management 1.0 (RM1.0)
- Low Level Reader Protocol 1.0 (LLRP1.0)
A detailed specification of the PacketTester platform for every supported interfaces is available in the Products→RFID Test Tools sections of this website. It is further noted that other protocol interfaces will be added on an as needed basis.
|
| |
| Top |
|
|
| |
|
