Tag Streamer User's Guide 1.1

From RifidiWiki

Jump to: navigation, search

Quick Start Vdieo

A quick start video is available at http://rifidi.org/videos/streamer/streamer.swf

Purpose

Tag Streamer is a load testing tool for edge servers. It allows the user to create multiple virtual readers, chain them together in some way, and add batches of tags to the readers based on patterns. Furthermore, because the readers can exist on different physical hosts, Tag Streamer can distribute its load among several machines. The Tag Streamer UI allows users to rapidly construct the necessary xml files for a test suite. In addition, it allows the user to easily run test suites.

Getting Started

This section will help you get started running Tag Streamer 1.1

Requirements

  • Microsoft Windows 2000/XP/2003 or Linux (Ubuntu, Red Hat, SuSe)
  • Sun Java Runtime Environment 1.6 update 4 (32 bit only) or greater (Tag Streamer 1.1 will not work with previous versions of the JRE)

Installation

There are two ways to run Tag Streamer:

  • Download the release from sourceforge (http://sourceforge.net/project/showfiles.php?group_id=170933)
    • Double click on the installer and click next until it is installed
    • Double click on the executable to run Tag Streamer
  • Download the latest code from our external svn
    • Once the code is downloaded into eclipse, right click on the Tag Streamer product file and select Run As->Eclipse Application

Tag Streamer Concepts

Test Suite

A Test Suite is a collection of four elements that define a particular simulation run of Tag Streamer. Conceptually, a Test Suite represents a particular configuration of readers and tag load that the user would like simulate. For example, a test suite could represent the receiving dock doors at a distribution center; the distribution center has four dock doors that are independent; tags seen by reader at dock door 1 will not be seen by the reader at dock door 2. In addition tags are seen in bursts, as workers unload the trucks with fork lifts. All this information is captured within a Test Suite.

A Test Suite can be completely created within Tag Streamer and saved as an XML. In addition, a user can load a previously saved Test Suite, edit it and save it again.

Components

Components are the emulated devices in a test suite simulation. At this time the only components are virtual RFID readers, but in the future there could be other kinds of components that could act in the simulation, such as electric eyes, barriers, or push arms. the important thing about components are that they represent a physical configuration for the objec; the component defines configuration information for the reader such as its IP, port, number of antennas and GPI/O ports, etc. It does not contain any information about how the reader is used.

Scenarios

Scenarios define a linear flow path of components. For example a scenario having two readers in it could represent an assembly line with two readers where tags seen by reader 1 will be seen by reader 2 at some later time. Scenarios are made up of path items, where each path item has a component (i.e. reader) and also a travel time to the next component in the scenario. This allows us to specify the number of milliseconds that it would tags to travel from reader 1 to reader 2.

Batches

Batches are a sequence of patterns of actions that happen on a reader. For example, a batch cause 20 C1G2 tags to be shown to a reader for 500 milliseconds, then wait for 5 seconds, then cause a GPI port to go high for 5 seconds. The important thing to note about batches is that they define a pattern that can be applied to any reader. In other words, batches do not define on which reader they are applied. This information is left up the the Test Unit. There are three basic units called actions

Tag Action
The tag action defines a pattern of tags that is shown to a reader. For example, 10 Gen 1 tags are placed in the reader's field of view for 5 seconds. Currently, every time that a tag action executes, the tags are regenerated according to the defined pattern. This means that if Reader1 and Reader2 both see a particular tag action, they will see different tags (i.e. the ids will be different).
GPI Action
The GPI action will set a certain GPI port either high or low for a certain amount of time. For example a GPI Action might be to set GPI port 3 high for 10 seconds.
Wait Action
A wait Action is simply a wait time between actions.

The other important aspect about batches is that they are sequences of actions. That is, a particular batch can have an arbitrary number of actions inside of it that are executed in order. For example, a batch can have a GPI action followed by a tag action followed by another GPI action.

Test Unit

The Test Unit combines the previous three elements into a runnable simulation. It short, it simply makes the connection between scenarios and batches. Each batch-scenario pair is run in parallel. For example, if a user defines two scenarios and two batches, the Test Unit associates a batch with a scenario. Then, when this test unit is run, it will start both batch-scenario pairs at the same time.

In addition the Test Unit defines the number of iterations that batches should execute on a scenario. For example, a batch may run on the scenario just once; in this case the simulation would be finished when the last action in the batch executes on the final reader in the scenario. In another case, the user may set the number of runs to infinity, so that the batch keeps executing on the scenario.

Interaction between elements

//TODO: insert a diagram depicting how the four elements work together

Using Tag Streamer

This section will give step-by-step instructions on how to use Tag Streamer.

Components

Components are the descriptions of physical readers. It gives information such as IP, number of antennas, etc.

Create

  1. Click the "New Item" icon (AddItem.gif).
  2. Select "new Component Wizard"
  3. Select a type of reader and an unused Component ID in the New Component Wizard
  4. Finish creating the reader
Select new component wizard
Select a type of reader
select properties for the reader

Edit

To edit existing components:

  1. Select the component you wish to edit on the tree on the left.
  2. Change the settings in the right pane
Edit Components

Scenarios

Scenarios are paths of components along which batches flow. For example, if we have three readers (reader_A, reader_B, and reader_C), we can define a scenario as

 reader_C -> reader_A -> reader_B

which means that tags will be initially seen by reader_C, then by reader_A, and finally by reader_B.

Create

  1. Click the "New Item" icon (AddItem.gif).
  2. Select "new Scenario Wizard"
  3. Add Components to the scenario
    1. The component ID is the ID number of the component you wish to add
    2. The travel time is the amount of time after the batch items have finished executing on the reader before they appear on the next reader
    3. The Antenna is the antenna number that tags should be added to when they enter this component
Select new scenario wizard
Add components to the scenario

Edit

To edit existing scenarios:

  1. Select the scenario you wish to edit on the tree on the left.
  2. Change the settings in the right pane
Edit Scenario

Batches

A batch is a pattern of actions that will act on a component. The available pattern types are:

  1. Tag Patterns, called Tag Actions
  2. GPI Patterns, called GPI Actions
  3. Wait Patterns, called Wait Actoin

Create

  1. Click the "New Item" icon (AddItem.gif).
  2. Select "new Batch Wizard"
  3. Add Actions to the Batch (at least one Tag, GPI, or Wait action is required)
  4. If you are adding a new Tag Action, you must add at least on pattern


Select new batch wizard
Add tag actions to the batch
Add GPI actions to the batch
Add wait actions to the batch

Edit

To edit existing batches

  1. Select the batch you wish to edit on the tree on the left.
  2. Change the settings in the right pane
  3. Make sure to click the save button after you finish editing
Edit Batches

Test Unit

Test Units match up scenarios to batches and are the "executable" part of a Tag Streamer file.

Create

  1. Click the "New Item" icon (AddItem.gif).
  2. Select "new Test Unit Wizard"
  3. Add at least one batch-scenario pair
  4. Optionally add wait actions so that the batch will pause before moving on to the next batch-scenario pair
  5. Select the number of repetitions (anywhere from 1 to infinity)
  6. If you want wait times before or after the test unit begins execution, fill in the pre and post wait times.
Select new test unit wizard
Add a batch-scenario pair

Edit

To edit existing Test Units:

  1. Select the test unit you wish to edit on the tree on the left.
  2. Change the settings in the right pane
  3. Make sure to click the save button after you change settings
Edit Test Unit

Save

If you wish to save the test suite that you made for future use:

  1. Click File->Save Test Suite
  2. Choose a file name and a directory

Load

If you wish to load a previously saved Test Suite:

  1. Click File->Load
  2. Select the test suite file (xml) that you wish to load

Run Test Suite

To run a test suite:

  1. Highlight the test unit that you wish to run in the tree on the right
  2. Click the run button() at the top (Ts-Start.png)
Start Test Unit

Run a TestSuite from command line

Since version 1.1 of Rifidi TagStreamer it is also possible to run a previously created TestSuite File (XML) via command line. There are two arguments you need to specify for the execution these are the TestSuite save file and the ID of the TestSuite you want to execute.

For Windows:

TagStreamer.exe [Filename] [#ID of TestUnit]

for example

TagStreamer.exe C:/temp/streamer.xml 1

Sample Test Suites

Assembly Line

Dock Door

This is an example configuration for a Rifidi Tag Streamer test suite. For this scenario, imagine that a warehouse has two dock doors, each with their own readers. Boxes come through the dock doors in parallel (at the same time). To model this, we have two components defined: DockDoor-1 and DockDoor-2 (both Alien Reader). We also have two batches defined: batch1 with 4 tags in it, and batch2 with 5 tags in it. In order to make the batches run in parallel on the readers, we define two scenarios, each with one pathItem that contains the reader. The testSuite defines two batchActions: The first batchAction matches scenario1 to batch1, and the second batchAction matches scenario2 to batch2. These two batchActions then run in parallel.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<metaFile>
    <batchSuite>
        <batch id="1">
            <tagAction>
                <execDuration>1000</execDuration>
                <regenerate>true</regenerate>
                <tagCreationPattern>
                    <accessPass>AAAAAA==</accessPass>
                    <lockPass>AAAAAA==</lockPass>
                    <numberOfTags>4</numberOfTags>
                    <prefix></prefix>
                    <tagGeneration>GEN2</tagGeneration>
                    <tagType>DoD96</tagType>
                </tagCreationPattern>
            </tagAction>
        </batch>
        <batch id="2">
            <tagAction>
                <execDuration>1000</execDuration>
                <regenerate>true</regenerate>
                <tagCreationPattern>
                    <accessPass>AAAAAA==</accessPass>
                    <lockPass>AAAAAA==</lockPass>
                    <numberOfTags>5</numberOfTags>
                    <prefix>FFF</prefix>
                    <tagGeneration>GEN2</tagGeneration>
                    <tagType>CustomEPC96</tagType>
                </tagCreationPattern>
            </tagAction>
        </batch>
    </batchSuite>
    <componentSuite>
        <readerComponents id="1">
            <reader>
                <numAntennas>1</numAntennas>
                <numGPIs>0</numGPIs>
                <numGPOs>0</numGPOs>
                <propertiesMap>
                    <entry>
                        <key>heartbeat_port</key>
                        <value>3989</value>
                    </entry>
                    <entry>
                        <key>heartbeat_power</key>
                        <value>false</value>
                    </entry>
                    <entry>
                        <key>inet_address</key>
                        <value>127.0.0.1:20000</value>
                    </entry>
                    <entry>
                        <key>heartbeat_address</key>
                        <value>255.255.255.255:3988</value>
                    </entry>
                </propertiesMap>
                <readerClassName>org.rifidi.emulator.reader.alien.module.AlienReaderModule</readerClassName>
                <readerName>DockDoor-1</readerName>
            </reader>
        </readerComponents>
        <readerComponents id="2">
            <reader>
                <numAntennas>1</numAntennas>
                <numGPIs>0</numGPIs>
                <numGPOs>0</numGPOs>
                <propertiesMap>
                    <entry>
                        <key>heartbeat_port</key>
                        <value>3989</value>
                    </entry>
                    <entry>
                        <key>heartbeat_power</key>
                        <value>false</value>
                    </entry>
                    <entry>
                        <key>inet_address</key>
                        <value>127.0.0.1:20001</value>
                    </entry>
                    <entry>
                        <key>heartbeat_address</key>
                        <value>255.255.255.255:3988</value>
                    </entry>
                </propertiesMap>
                <readerClassName>org.rifidi.emulator.reader.alien.module.AlienReaderModule</readerClassName>
                <readerName>DockDoor-2</readerName>
            </reader>
        </readerComponents>
    </componentSuite>
    <scenarioSuite>
        <scenario id="1">
            <pathItem>
                <antennaNum>0</antennaNum>
                <readerID>1</readerID>
                <travelTime>0</travelTime>
            </pathItem>
        </scenario>
        <scenario id="2">
            <pathItem>
                <antennaNum>0</antennaNum>
                <readerID>2</readerID>
                <travelTime>0</travelTime>
            </pathItem>
        </scenario>
    </scenarioSuite>
    <testUnitSuite>
        <testUnits iterations="-1" id="1">
            <batchAction>
                <batchID>1</batchID>
                <scenarioID>1</scenarioID>
            </batchAction>
            <batchAction>
                <batchID>2</batchID>
                <scenarioID>2</scenarioID>
            </batchAction>
            <waitAction>
                <maxWaitTime>1000</maxWaitTime>
                <minWaitTime>1000</minWaitTime>
                <random>false</random>
            </waitAction>
            <postWait>0</postWait>
            <preWait>0</preWait>
        </testUnits>
    </testUnitSuite>
</metaFile>
Personal tools