ARENDG-RM001D-EN-P_Ttlepage 11/30/07 4:08 PM Page 1

Arena®

TEMPLATE DEVELOPER’S GUIDE

PUBLICATION ARENDG-RM001D-EN-P–November 2007
Supersedes Publication ARENDG-RM001C-EN-P
 Contact Rockwell Customer Support Telephone — 1.440.646.3434
Online Support — http://www.rockwellautomation.com/support/

Copyright Notice © 2007 Rockwell Automation Technologies, Inc. All rights reserved. Printed in USA.
This document and any accompanying Rockwell Software products are copyrighted by Rockwell Automation
Technologies, Inc. Any reproduction and/or distribution without prior written consent from Rockwell Automation
Technologies, Inc. is strictly prohibited. Please refer to the license agreement for details.
Trademark Notices Arena, Rockwell Automation, and SIMAN are registered trademarks of Rockwell Automation, Inc.

Other Trademarks ActiveX, Microsoft, Microsoft Access, SQL Server, Visual Basic, Visual C++, Visual SourceSafe, Windows, Windows
ME, Windows NT, Windows 2000, Windows Server 2003, and Windows XP are either registered trademarks or
trademarks of Microsoft Corporation in the United States and/or other countries.
Adobe, Acrobat, and Reader are either registered trademarks or trademarks of Adobe Systems Incorporated in the
United States and/or other countries.
ControlNet is a registered trademark of ControlNet International.
DeviceNet is a trademark of the Open DeviceNet Vendor Association, Inc. (ODVA)
Ethernet is a registered trademark of Digital Equipment Corporation, Intel, and Xerox Corporation
OLE for Process Control (OPC) is a registered trademark of the OPC Foundation.
Oracle, SQL*Net, and SQL*Plus are registered trademarks of Oracle Corporation.
All other trademarks are the property of their respective holders and are hereby acknowledged.
Warranty This product is warranted in accordance with the product license. The product’s performance may be affected by system
configuration, the application being performed, operator control, maintenance and other related factors. Rockwell
Automation is not responsible for these intervening factors. The instructions in this document do not cover all the
details or variations in the equipment, procedure, or process described, nor do they provide directions for meeting every
possible contingency during installation, operation, or maintenance. This product’s implementation may vary among
users.
This document is current as of the time of release of the product; however, the accompanying software may have
changed since the release. Rockwell Automation, Inc. reserves the right to change any information contained in this
document or the software at anytime without prior notice. It is your responsibility to obtain the most current information
available from Rockwell when installing or using this product.

Version: 12.00.00 (CPR9)

Modified: October 8, 2007 12:10 pm

ii
Contents

1 • Welcome 1
What is Arena simulation software? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Intended audience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
About this guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Where can I go for help? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Reference the user’s guides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Explore our examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Get help. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Use the SMARTs library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Access the Arena Symbol Factory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Get phone support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Get Web support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Get training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Get consulting services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Contact us . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 • Arena Template Development Overview 7

Modeling with Arena—An overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Templates and panels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Module definitions and instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Defining a module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Panel icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
User view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Dialog design and operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Elements and properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Arena hierarchy and SIMAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Flowcharts and data modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Use of templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
General modeling tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Industry-oriented environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Application-focused tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Improving modeling productivity and sharing modeling technology . . . . . . . . . 26

iii
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

3 • Module-building Tutorial 29
Module overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Getting started—A new template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Dialog Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
The dialog design window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Adding the module’s dialog operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Adding the module's entry/exit point operands . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Arranging the Dialog form layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
The logic window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Overview of the Printer module logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Receiving entities and seizing the printer—The Queue and Seize modules . . . . 42
Deciding whether to changeover the printer—The Decide module . . . . . . . . . . . 44
Changeover logic—Assign, Process, and Assign modules . . . . . . . . . . . . . . . . . 45
The print logic—Delay and Release modules . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Defining the Printer module elements—Queues and Variables elements . . . . . . 50
User View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Panel Icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
A sample model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Preparing the template for use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Single printer simulation model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4 • The Template Window 65

The template menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Creating a new template window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Loading an existing template panel file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Closing a template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Saving the template panel library file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Creating and editing modules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
The module definitions list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Opening module definition windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Preparing the template panel for use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Checking the template panel for errors and warnings . . . . . . . . . . . . . . . . . . . . . 67
Reviewing errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Template panel file reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Generating the template panel object (.tpo) file . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Other template panel information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Changing the version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Template options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Defining required modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

iv
 • • • • •
CONTENTS

Defining data modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Defining a name operand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Creating copies of module definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Compatibility of existing module instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5 • The Dialog Design Window 77

Dialog Design Window overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
The Operand Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
The Toolbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
The dialog form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
The Design Properties grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Using the Toolbox controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Using the Text control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Using the GroupBox control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Using the Line control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Using the TextBox control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Using the ComboBox control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Using the RadioButtonGroup control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Using the CheckBox control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Using the DialogButton control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Using the RepeatGroupDialog control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Using the RepeatGroupTable control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Using the DateTimePicker control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Using the DatePicker control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Using the TimePicker control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Using the FilePicker control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Using the HiddenOperand control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Using operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Specifying the Name property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Specifying the LogicProperties property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Specifying the Value property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Specifying the DataType property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Specifying the SwitchName property. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Specifying the InUserView property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Hidden operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Using repeat groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Specifying the Name property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Specifying the LogicProperties property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Repeat group definition depth and reference rules . . . . . . . . . . . . . . . . . . . . . . . 104
Accessing the number of tuples and the tuple number . . . . . . . . . . . . . . . . . . . . 105
Combining repeating operand values into a single value . . . . . . . . . . . . . . . . . . 106
Using repeatable modules in the logic window with repeat groups . . . . . . . . . . 107

v
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Using accelerator keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Dialog Design toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

6 • The Logic Window 109

Simulation logic and module design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
The logic window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Differences between logic and model windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Running simulation models (model window) . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Referencing operands (logic window) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Switching module instances (logic window) . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Defining repeatable logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Module connections in the logic window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Attaching template panels while working in a logic window . . . . . . . . . . . . . . 112
Display of animation objects (logic window). . . . . . . . . . . . . . . . . . . . . . . . . . . 113
“Fields” and “operands” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Referencing module data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Referencing operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Special access for check boxes, radio button groups, and combo boxes . . . . . . 120
Switches in logic window module instances . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Defining transfer of entities into and out of a module . . . . . . . . . . . . . . . . . . . . 121
Referencing non-repeating operands from a repeat group . . . . . . . . . . . . . . . . . 125
Referencing repeating operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Defining repeatable exit points in a module . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Repeatable modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Example 1: Parallel logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Example 2: Serial logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Example 3: Defining alternate outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Customized options using radio button and check box controls . . . . . . . . . . . . 141
Module connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Using graphical connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Defining multiple connections from a single exit point . . . . . . . . . . . . . . . . . . . 142
Repeating exit points in the logic window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Switching module instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Attaching and detaching switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Effect of switches in the logic window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Using Arena’s utility modules (from utlarena.tpo) . . . . . . . . . . . . . . . . . . . . . . 150
Defining module trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Logic definition rules and guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

7 • The User View Window 157

Module instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

vi
 • • • • •
CONTENTS

Module-related objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

The module handle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
The Module Text Options dialog box. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Entry and exit points. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Displayed operands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Draw objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Animation objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
User View switch use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

8 • The Switch Window 169

Defining switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Switch names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Switch definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Switch definition rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

9 • The Panel Icon Window 175

Creating the panel icon. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

10 • Elements 177
Defining elements in modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Creating elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Element lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Use of elements and properties in module definitions . . . . . . . . . . . . . . . . . . . . . . . 181
Access to properties in a model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Displaying element lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Defining elements via hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Element operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Defining element operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Sub-lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Defining and referencing elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Property operands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Defining Property operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Defining repeating properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Defining an element/property using a hidden operand. . . . . . . . . . . . . . . . . . . . 192
Switches and elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Special element types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Fixed-length elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Hidden element list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

vii
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Inverted elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

A • Template Design Guidelines 205

Dialog box design (dialog design window) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Dialogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Operand objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Helpful hints for defining objects in the dialog design window. . . . . . . . . . . . . 206
General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Panel icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
User view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Module logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Naming conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Template documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Statistics and reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

B • Tables 211
Elements and properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Standard elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Inverted elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Fixed-length elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Data type definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Connection point data types and SIMAN blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Entry/exit point types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

C • Creating Online Help Files 269

273

Index 273

viii
1 Welcome

1 • Welcome
What is Arena simulation software?
Arena is an advanced simulation system that provides an interactive environment for
building, graphically animating, verifying, and analyzing simulation models. With Arena,
you can design a unique Arena template that is specific to your particular project,
company, or industry. The template development features build on Arena’s natural
hierarchical structure enabling you to create new simulation tools in a graphical, easy-to-
use environment.
Within Arena’s template-building area, you create complete simulation building blocks,
called modules. These modules may be very simple, such as one that counts customers as
they leave a bank. Or you might build a highly complex module that captures all of the
activities at a shipyard dock. In fact, Arena’s hierarchy encourages you to take apart the
systems you study into their critical, basic elements, then combine these basic elements
into the more complex components and subsystems to be simulated.
The modules that you build are collected into libraries, referred to as templates. You may
use these templates in support of your own simulation activities, or you may share these
simulation tools with other modelers.
By encouraging this sharing of technology, Arena offers the opportunity for you, as a
simulation modeler, to create completely customized environments, without writing any
programming code. Novice modelers can access the power of simulation as a decision
support tool by working with terminology, modeling logic, and graphical animation that
are specially developed for their needs. Experienced simulationists can improve their
productivity and share the knowledge they have gained by capturing essential simulation
logic and quickly packaging it into a verified, reusable building block for future models.
As mentioned above, within Arena you have the ability to define new modeling
constructs, called modules, and to store them in libraries, referred to as Application
Solution Templates (AST’s), or templates.
If you are familiar with Arena’s model-building and analysis environment, you will find
that the template development features build on the concepts and interface you already
have learned. When you run Arena, you will simply open a Template Window (instead of
a Model Window). Select the File > New menu option or press the New File toolbar

1
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

button. In the dialog that is displayed, select Template Window and click OK, as shown in
Figure 1.1.

Figure 1.1 Arena’s Template Window selection

This template window serves as a “home base” for the activities involved in building a
template. The windows that you work with to define modules are displayed on the same
desktop as Arena model, input, and output windows. You interact with these windows
using the standard Arena user interface.

Intended audience
Before you begin to access the capabilities of template building, you should already have
developed a good understanding of the basic Arena modeling interface and the either the
SIMAN template or Arena’s Basic Process, Advanced Process, and Advanced Transfer
templates. This guide assumes that you are familiar with Arena modeling concepts and
terminology, which are presented in the Arena User’s Guide and online help.

About this guide

The Arena Template Developer’s Guide is designed to serve as both an instruction manual
for building templates and as a reference guide for the template-building features. We start
by presenting two chapters that familiarize you with the concepts and terminology
employed in Arena and walk you through a simple module-building tutorial. Following
this, we provide a description of the template window, then of each of the five windows
that you employ to build modules. Next we present Elements, the final concept related to
the definition of Arena modules. Appendix B of this book contains reference tables.
To begin your experience with template development, we recommend that you read
Chapter 2, “Arena Template Development Overview,” to become familiar with Arena
concepts and terminology. Then, follow the step-by-step instructions provided in the
module-building tutorial in Chapter 3. While you are building your first module, you may
want to refer to concepts presented in Chapter 2.

2
 • • • • •
1 • WELCOME

Where can I go for help?

Our commitment to your success starts with the suite of learning aids and assistance we

1 • Welcome
provide for Arena. Whether you’re new to simulation or a seasoned veteran putting a new
tool to use, you’ll quickly feel at home with Arena simulation software.

Reference the user’s guides

The documentation set includes this manual, Arena Template Developer’s Guide, which
introduces template creation and module building. In addition, the Arena User’s Guide
and Variables Guide are separate reference manuals providing module information on the
basic of modeling with the Basic Process, Advanced Process, Advanced Transfer, and
Flow Process panels as well as complete descriptions of Arena variables found in the
Arena product templates.

DOCUMENT CONVENTIONS

Throughout the guides, a number of style conventions are used to help identify material.
New terms and concepts may be emphasized by use of italics or bold; file menu paths are
in bold with a (>) separating the entries (e.g., go to Help > Arena Help); text you are
asked to type is shown in Courier Bold (e.g., in this field, type Work Week), and dialog
box and window button names are shown in bold (e.g., click OK).

Explore our examples

Arena is accompanied by a number of sample models that illustrate many of the com-
monly used approaches for capturing the essence of manufacturing processes. Examples
are provided for both job shop and flow shop environments. For a description of and list
of Arena’s examples, go to Help > Arena Help. On the Contents tab, choose Model
Building Basics, and then select Viewing Arena Example Models.

Get help
Online help is always at your fingertips! Arena incorporates the latest in help features,
including What’s This? help that displays a brief description of fields in dialogs, context-
sensitive help on menu and toolbar buttons, and a help button on each of Arena’s modules.
Just refer to the Arena help table of contents and index for a list of all help topics.

Use the SMARTs library

As you craft models of your own manufacturing processes, use our SMARTs library to
explore how to best use Arena. This suite of tutorial models covers topics ranging from
modeling resources to animation techniques. The library is organized into categories to
help you find the right model with ease. When you’re wondering how to take the next step
in your model, browse the SMARTs library for a ready-made solution. For a list of

3
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

categories and their related SMARTS, go to Help > Arena Help. On the Contents tab,
first click Model Building Basics, and then Learning Arena with SMART Files.

Access the Arena Symbol Factory

Arena animations can be enhanced using Arena Symbol Factory’s extensive library of
symbols. These symbols can be used for entity, resource, transporter, or global pictures or
as graphic symbols within a model window. You can copy these symbols directly to the
Arena model window, add them to your own libraries (.plb files), or add them to any of
the Arena picture library files.

Get phone support

Rockwell Automation provides full support for the entire Arena family of products.
Questions concerning installation, how modules work, the use of the model editor, and the
use of the software are handled by technical support.

ARENA TECHNICAL SUPPORT INCLUDES:

„ (for users on active maintenance) a technical support hotline and e-mail address
staffed by full-time, experienced professionals
„ help with installation problems or questions related to the software’s requirements
„ troubleshooting
„ limited support regarding the interaction of Arena with other programs
„ support of the Arena Object Model, which is used in Microsoft Visual Basic for
Applications.
If you call the support line (1.440.646.3434), you should be at your computer and be
prepared to give the following information:
„ the product serial number
„ the product version number
„ the operating system you are using
„ the exact wording of any messages that appeared on your screen
„ a description of what happened and what you were doing when the problem occurred
„ a description of how you tried to solve the problem.

Get Web support

In addition to phone support, the Rockwell Automation Customer Support Center offers
extensive online knowledgebases of tech notes and frequently asked questions for support
of non-urgent issues. These databases are updated daily by our support specialists.
To receive regular e-mail messages with links to the latest tech notes, software updates,
and firmware updates for the products that are of interest to you or to submit an online
support request, register through http://support.rockwellautomation.com/.

4
 • • • • •
1 • WELCOME

And be sure to check the Arena User Zone section of our Web site at www.ArenaSimula-
tion.com. The User Zone links to a peer-to-peer forum on Arena topics and has a link to a

1 • Welcome
download page where you can check for possible software updates (patches). If you can’t
find the answer you need, contact your local representative or Arena technical support.

Get training
Do you need training? Rockwell Automation offers a standard training course comprised
of lecture and hands-on workshops designed to introduce you to the fundamental concepts
of modeling with Arena.
We also offer customized training courses designed to meet your specific needs. These
courses can be held in our offices or yours, and we can accommodate one person or
twenty. You design the course that’s right for you! Simply contact our consulting services
group to discuss how we can help you achieve success in your simulation efforts.

Get consulting services

Rockwell Automation also provides expert consulting and turnkey implementation of the
entire Arena product suite. Please contact our offices for more information.

Contact us
We strive to help all of our customers become successful in their manufacturing improve-
ment efforts. Toward this objective, we invite you to contact your local representative or
Rockwell Automation at any time that we may be of service to you.

Support E-mail: [email protected]

Corporate E-mail: [email protected]
Support phone: 1.440.646.3434
URL: www.ArenaSimulation.com
URL: www.rockwellautomation.com

5
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

6
2 Arena Template Development Overview
In this chapter, we introduce the concepts related to building templates using Arena. As
described in Chapter 1, Arena provides a fully integrated environment for building,
graphically animating, verifying, and analyzing simulation models. It does so by the
creation of reusable modeling components called modules that are collected into libraries,
or templates.
To introduce you to template building, we start by reviewing the model-building process
in Arena.

2 • Overview
Modeling with Arena—An overview
In Arena, simulation models are built by placing modules in a model window, providing
data for these modules, and specifying the flow of entities through modules. A module
defines the underlying logic that is applied when an entity is directed to the module, as
well as the associated graphical animation, to depict the module’s activities during a
simulation run. This section provides a brief overview of model building with Arena. For
information about using Arena to build, animate, and analyze simulation models, refer to
the Arena User’s Guide and online help.
To use a module in an Arena model, a panel containing the module is attached to the
Project Bar. This panel displays all of the modules that may be selected for placement in
the model. To build a model, you select a module from the panel and place it in the model
window. The graphics associated with the module, referred to as its user view, are added to
the model window. This display of the module always contains a module handle (typically
the module name) and may include static drawing objects, animation objects, operand
display values, and connection points, as illustrated in Figure 2.1.

Figure 2.1 Process module user view

7
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

After a module has been placed in the model window, its associated data may be edited by
double-clicking on the module. This action opens the module’s main dialog, which
typically contains one or more changeable values, referred to as operands of the module.
These operands provide the mechanisms for changing the behavior of the module in
different uses within simulation models. For example, using the Process module from the
Basic Process panel, you might seize, delay, and release with a resource named Line D
Labeler. In the same model, you might place another Process module that requires a
resource named Line D Packer for processing. Entities sent to the first module wait for the
Line D Labeler resource. While entities arriving at the second Process module undergo
similar logic (i.e., the logic captured in the Process module), they are waiting for a
different resource (Line D Packer).
To define the flow of entities among modules, either direct connections or station transfers
may be used. A direct connection is formed by placing a connection from a module exit
point to a module entry point. Entities that leave a module through an exit point are
transferred through the connection to the entry point with no time delay. A station transfer
takes place when an entity leaves a module by means of a route, transport, or convey, as
seen in the Leave or Route modules of the Advanced Transfer panel; in these cases, a
station destination is specified and the entity is sent to the module that defines the station,
such as an Enter or Station module (Advanced Transfer panel). These station transfers
often involve time delays and may require a material transfer device (e.g., person, shuttle
car, conveyor) to move the entity to its destination station.
After modules are placed in a model and values are provided for their operands, a
simulation run may be performed. To initiate a run, Arena generates a SIMAN model file
(representing the model logic) and an experiment file (containing data to support the
model) based on the modules that have been placed in the Arena model. Values of module
operands may cause particular sections of the model to be generated or ignored, may
cause the creation of elements in the experiment, and may enable or disable display of
animation components. For example, collecting a count in the Record module causes a
Count block to be included in the SIMAN model file and a Counters element listing the
counter name to be written to the SIMAN experiment file. In this case, no animation
component is included automatically. After the model and experiment have been
generated and the animation graphics (if any) initialized, the simulation commences,
acting on the simulation program (.p) file that results from the model generation phase.

Templates and panels

A template consists of a panel or a set of panels that encompass modeling constructs for a
particular application, system, class of systems, or general target environment. A template
panel contains modules collected into a file and intended to be presented as a self-
contained group. The panels commonly used for standard Arena modeling include: Basic
Process, Advanced Process, and Advanced Transfer. Each panel consists of related

8
 • • • • •
2 • ARENA TEMPLATE DEVELOPMENT OVERVIEW

modeling constructs; together, these are documented and referred to as the Arena
template. Similarly, the SIMAN template contains two panels: Blocks and Elements.
Arena modelers attach template panels to the Project Bar in the application window of the
Arena modeling environment. The Project Bar hosts the primary objects used to build a
model, so the modeler selects modules from the appropriate Project Bar panel and places
them in the model window. The template file that is attached to the Project Bar is called
the template panel object file (or .tpo file). The panel displays a list of the modules
contained in the .tpo file.
When developing your own template, you work with a template panel library file (or .tpl
file). This file contains the definitions of the modules in the template panel. The concepts

2 • Overview
of module definitions and instances are discussed in the next section. To work with a
template panel file, you can create a new file by selecting the File > New menu item in
Arena and choosing the Template Window option; or use the File > Open menu item to
open an existing .tpl file. In either case, you access the module definitions contained in the
template panel via a template window, as shown in Figure 2.2. (See “The Template
Window” on page 65 for additional information.)

Figure 2.2 Sample template window

After you have defined the modules that will be contained in the template panel library,
you can save the module definitions in a .tpl file. To prepare the template panel for use in
a simulation model, a template panel object (.tpo) file is generated, using the Check >
Generate TPO menu item. This step verifies that the module definitions are complete,
then creates a .tpo file that is ready to be attached for use in a model.

9
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Module definitions and instances

A module in Arena is a single construct that may be selected from a template panel and
placed in a model or, as we will see, in the definition of a new module. Each icon in a
template panel represents a single module, such as a Create (to generate entities) or
Process (for simple processing of entities).
The information about a module that is stored in the template panel library (.tpl) file is
referred to as the module definition. In the template panel object (.tpo) file, the
information contained in the module definitions is condensed for use in a simulation
model. When a module is selected from a .tpo file and is placed in a model window, we
refer to the representation of the module in the model window as a module instance.
The module definition defines the structure of the module and provides default data and
visualization of the module. Each time a new instance of the module is created, the new
instance contains the defaults provided by the module definition. However, these defaults
may be modified by the modeler so that each instance carries with it its own characteris-
tics. For example, the default main dialog for the Create module (provided by the Arena
template’s Basic Process panel) displays eight operands that the modeler may edit: the
module Name or label, the Entity Type (Entity 1, by default), information related to the
time between arrivals (the Type, Value, and the number of Units), the number of Entities
per Arrival, the Maximum number of Arrivals, and the time of First Creation. (See Figure
2.3.)

Figure 2.3 Main dialog for Create module

The module definition also specifies the characteristics of the Create module’s dialog,
including the position of the operands, the prompts associated with them, their default
values, etc. When a Create module is placed in a model window, an instance is created.
Many instances of a given type of module may be placed in the model window. For
example, the simulation model may represent a grocery store where different types of

10
 • • • • •
2 • ARENA TEMPLATE DEVELOPMENT OVERVIEW

customers arrive at varying times or rates. First, a Create module is placed in the model
window. The modeler may change the values of the Create module instance’s operands.
For example, the first customer type may utilize the default arrival stream, which is
random (exponential). A second type of customer may arrive at a Constant rate. In that
case, a modeler might change the value in one instance of the Create modules to Constant.
Note that by changing the value in an instance, the modeler does not modify the
definition. In the case of the Create module, the next instance (and all instances, until
edited) will have a default type of arrival stream of Random (from the module definition).
Module instances may be placed in Arena model windows (and later saved in model .doe
files) or in the logic windows of new module definitions (to be saved in .tpl files). For
simplicity’s sake, we usually discuss use of module instances by “the modeler”

2 • Overview
(suggesting placement in model windows) in this guide. As you are reading, however,
keep in mind that instances of the modules you are defining may be used either in a
simulation model or in the definition of a module in another template panel.

Defining a module
A module definition is created by working with five windows: dialog design, logic,
switch, user view, and panel icon. A template window (see Figure 2.2) provides a base
from which the module definition windows are opened. The items in the Window menu
open each of the windows (or the corresponding buttons on the Template Development
toolbar may be used) for the selected Module Definitions list. As is the case throughout
Arena, you may have as many windows open as you desire (for one or more module
definitions). Figure 2.4 shows a template window with the five module definition
windows opened for a single example module (Shipping).

11
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Figure 2.4 Relationship among Arena template and module definition windows

The five buttons used to open module definition windows (from the toolbar shown in
Figure 2.5) are arranged in the order that we find we most often work when initially
building a new module; i.e., first defining the dialog design and logic, then switches to
control turning on and off module options, and finally the user view and panel icon
graphics. However, the five components of a module may be defined in any order. As you
work with a module definition, you often will modify the contents of a few of these
windows.

Figure 2.5 Template Development toolbar

In this chapter, we have chosen to present an overview of each of the five module
definition windows in the order that someone who places an instance of a module will
interact with the module. We start with the icon for the module button that is displayed in

12
 • • • • •
2 • ARENA TEMPLATE DEVELOPMENT OVERVIEW

a template panel; then we describe the user view and the module’s dialog design and
operands, which are the components of a module instance that a modeler can modify
directly. We finish with the underlying module logic and switches, which are not directly
accessible to the user of a module.

Panel icon
Three of the aspects of a module definition are visible to the user of the module: the panel
icon, the user view, and the module’s dialog and operands. First, when the template panel
object (.tpo) file is attached to the Project Bar, the panel icons are displayed. This simply
is a table of small graphics icons representing the modules contained in the template
panel. Figure 2.6 shows the Arena template’s Basic Process panel attached to the Project

2 • Overview
Bar.

Figure 2.6 Basic Process template panel

13
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

While a module’s panel icon is visible to the modeler, it is not changeable; the icon that is
drawn in the module definition will be the same whenever the .tpo file is attached to the
Project Bar. The Panel Icon window that is used to draw the icon in the module definition
is similar to the picture edit window used to draw Arena pictures of resource, entity, etc.
The panel icon for the definition of the Basic Process panel’s Create module is shown in
Figure 2.7.

Figure 2.7 Create module panel icon

User view
After a module has been selected and placed in a window, an instance is formed and the
module’s user view is displayed. This user view contains the module handle (the name of
the module, displayed as a text object within a box that opens the module’s main dialog
when the modeler double-clicks on it), and may contain entry points, exit points, operand
values, static drawing graphics, and/or animation objects. The objects in the user view are
visible to the modeler; most are changeable by the modeler individually in each module
instance. For example, you might place a Process module (from the Basic Process panel)
in a model window. Initially, the user view (in the model window) will appear as shown in
Figure 2.8, containing the module handle (“Process #”), an entry point, an exit point, and
an animated variable representing the work in process (WIP) or number of entities
currently in that model.

Figure 2.8 Process module instance’s default user view

You might place another instance of the Process module in the same model, then add a
resource animation picture for that Process module instance to represent the resource
utilized within the module. Figure 2.9 shows the modified user views of two Process
module instances using pictures from Arena’s people.plb picture library in place of the
default resource pictures.

14
 • • • • •
2 • ARENA TEMPLATE DEVELOPMENT OVERVIEW

Figure 2.9 Modified Process module instances

2 • Overview
The user view for a module definition is created in the User View window. In Figure 2.10,
you can see that the user view window for the Process module contains more objects than
are displayed by default when an instance of the Process module is first placed in a
window. These additional user view objects are not displayed because the values of
operands in the default Process module dialog cause them to be “switched out.” (We
discuss switches later in the chapter.)

Figure 2.10 User view window of the definition of Arena’s Process module

Dialog design and operands

An important part of a module definition is the user interface, the visual part that a
modeler sees when opening a module's dialog or viewing a module's fields in the module
spreadsheet.
Often, the most challenging part of creating a module is selecting which operands are to
be presented to modelers, the default values and display characteristics of these operands,
and their organization into one or more dialogs for the module. A module designer might

15
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

decide to provide only a few operands; modelers using this module have few choices, but
are able to work with a very simple module. Complex modules might present dozens of
operands, allowing a single module to capture a very complicated process that might vary
significantly from system to system or in different cases within a system. Furthermore,
through use of switches, the dialog can be reconfigured to display only the appropriate
operands, based on the values of other operands as supplied by the modeler.
In the Record module from the Basic Process panel, for example, the default dialog that is
opened when an instance is first formed appears as shown in Figure 2.11.

Figure 2.11 Record module default dialog

If the modeler changes the Type field from Count to Time Interval in an instance of the
Record module, a different operand is displayed with the prompt “Attribute Name” in
place of the “Value” operand and the operand “Tally Name” is requested instead of
“Counter Name.” In this case, the modeler will be collecting information on the time
difference between the specified attribute name’s value and the current simulation time,
instead of simply increasing or decreasing a specified count.
In a template panel library (.tpl) file, the Dialog Design window is the interface for
defining the dialog form layout(s) and operands of a module definition. In this window, a
module designer defines dialog sizes, data displayed to and entered by the user, default
and permissible values, and the layout of interface controls.
The dialog design window includes an Operand Explorer section to browse the module
definition's hierarchy of dialogs (many modules contain multiple dialogs), operands, and
repeat groups (for defining repeatable operands or sets of operands, such as the resources
to be utilized in a process). It also includes a Toolbox section to add user interface controls
to the module’s dialog forms and a Design Properties grid to edit the properties of one or
more selected objects.

16
 • • • • •
2 • ARENA TEMPLATE DEVELOPMENT OVERVIEW

Figure 2.12 shows the dialog design window for the definition of the Basic Process
panel’s Batch module, which simply contains a main dialog and a number of operands that
are members of the dialog.

2 • Overview
Figure 2.12 Dialog design window for the Batch module’s definition

A modeler working with a module instance may modify the values of operands, but
cannot change the configuration of dialogs, the default values supplied when a new
instance of a module is placed in a window, or the associations among operands. These
characteristics of a module’s data are part of the module definition; each instance simply
supplies values to the operands provided by the definition.

Logic
The final two aspects of a module are hidden from the modeler: the module logic and the
definition of module switches. The logic underlying an Arena module definition is created
simply by building an Arena “submodel.” The Logic window, which is used to create a
module definition’s logic, is very similar to an Arena model window; you attach panels to
the Project Bar, select and place modules, and edit the module instances you’ve created.

17
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Note that the logic window is the second window in Arena that can contain instances of
modules. As mentioned previously, in this guide we most often discuss placement of
modules in “model windows” by “the modeler.” Remember, as you read, that these
discussions also refer to the creation of module logic unless otherwise noted.
Note that when the logic window is active, the Run toolbar is not available because Arena
module definitions cannot be simulated themselves—only instances in models can be part
of a simulation run. Also, by default, the animation objects in a logic window are not
displayed since they are primarily useful only for depicting the behavior of a running
simulation. You may turn on the display of the animation objects in the window by using
the View > Layers menu item.
An important aspect of defining Arena modules is the tie between the operands and logic.
The operands provide the “external” interface for a modeler; the logic is the “internal”
behavior of the module under the circumstances defined by the values of operands. A
modeler can customize a module’s logic each time a new instance of the module is placed
by providing different values for the module operands.
The mechanism for passing operand values from the module instance’s dialog to the
underlying module logic is through operand references established in the logic window of
the module definition.
To illustrate this, let’s consider a module that represents an admissions clerk at a hospital.
The entities flowing through this module will represent patients or family members who
need to provide admissions information. Modelers using this Admissions Clerk module
will simply provide the name of the clerk and the time to process an admission. In the
underlying logic, we will use the Process module from the Basic Process panel. A sample
dialog for the Admissions Clerk module is shown in Figure 2.13.

Figure 2.13 Dialog for hospital Admissions Clerk module

In each instance of the Admissions Clerk module, different values might be given for the
two module operands (Clerk Name and Time to Admit). To use these values, we will pass
the value of the Clerk Name operand to the Resource name field in the Process module,
and the Time to Admit operand to the Expression field.
To reference an operand of the module from an instance (such as the Process module), you
edit the instance in the logic window; wherever you would like to use the value of a

18
 • • • • •
2 • ARENA TEMPLATE DEVELOPMENT OVERVIEW

module operand, you enclose the name of the operand in back quotes (`). Assuming that
the operands have the same name as the prompts (i.e., Clerk Name and Time to Admit),
the references would be established in the Process module as `Clerk Name` and `Time to
Admit` as shown in Figure 2.14.

2 • Overview
Figure 2.14 Operand references in Process module for Admissions Clerk module

If one instance of the admissions clerk module has values Mary and UNIFORM(10,30)
for the module operands, then effectively a Process module has been placed in the
underlying model logic with values of Mary for the resource to be utilized and
UNIFORM(10,30) for the process time.

19
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Unlike a module instance’s user view and operands, the module’s logic cannot be directly
modified by a modeler. Instead, the module’s operands may be used to specialize an
instance of a module to a particular need by passing data to the logic (i.e., the module
instances in the logic window) and, as we will see, by causing sections of the logic to be
switched in or out.
Note that there may be one or more operands in a logic module instance (in the logic
window) that are not available for the end user. For example, in the Process module
description above, the Type remains the default Standard, Action is Seize Delay Release,
Priority is default of Medium(2), and Delay Type is Expression. These operand values
cannot be changed by a modeler, as they are not accessible via operands in their module.

Switches
In an Arena module definition, individual objects in the user view, dialog design, and
logic windows may be selected to be included in an instance only if a particular condition
is true. For example, an instance of the Record module in the Basic Process panel only
displays the Value operand if the Type is Count or Expression. If the Type is Entity
Statistics, Time Interval, or Time Between, then the Value operand is not displayed;
Instead, other operands relating to those types of statistics are displayed; we refer to this
as being “switched out.” In the underlying module logic, a Count block is included in the
logic (with the appropriate values referenced from the module’s operands) if Type is
Count; a Tally block is used (with varying information) if Type is Entity Statistics, Time
Interval, Time Between, or Expression. And finally, while not used in the Record module,
user view animation may display pertinent information, based on a user’s input values.
To define this behavior, objects called switches are created in the module definition. These
switches are placed in a switch window, as shown in Figure 2.15.

Figure 2.15 Sample switch window

20
 • • • • •
2 • ARENA TEMPLATE DEVELOPMENT OVERVIEW

The definition of a switch is based on conditions involving the values of operands, such as
` Type`== “Count” defining a switch whose value is true whenever the operand Type has
a value equal to Count. (Operands are referenced by enclosing the operand name in back
quotes, as in the logic window; values are enclosed in double quotes.) To use a switch in
the user view or logic windows, the switch is “attached” to the object. In the dialog design
window, a switch is added to an object by specifying the object’s SwitchName property.
The display of an object that has an attached switch is changed to show the switch name
enclosed in square brackets, as shown for a Tally block in the logic window in Figure
2.16.

2 • Overview
Figure 2.16 Tally Block with attached switch in logic window

Use of switches in module definitions can aid users of the module in focusing attention
only on the fields that are relevant given other information they’ve provided (e.g., if a
modeler has indicated that a count type of statistic be collected, there is no reason to
display the Tally Name field). Also, switches used in the logic window can ensure that
efficient models are generated for performing simulation runs. In the case of the Record
module, rather than requiring each entity to query whether or not a count should be
collected, the logic either is written out for all entities to perform, or is omitted from the
model entirely if no count is to be collected. Of course, in some cases, different entities
might undergo different logic, in which case a module such as the Decide module (from
the Basic Process panel) can be placed in the logic window to make the decision. But if a
particular selection is to apply to all entities that are processed through the module,
switches are an effective way to ensure efficient simulation logic.

21
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Elements and properties

The concepts we have presented thus far relate to building modules, where each module
definition is a self-contained unit. When a module is placed in a model, its characteristics
are specific to the instance; a change to the value of an operand or to the appearance of an
object in the user view has no effect on other modules of the same type.
However, there are some constructs in a simulation model that are inherently global in
nature. We refer to these as elements of the model. These elements may be referenced by
more than one module instance, and creation of an element places the name of the element
on a list that is accessible by other module instances.
For example, if you place a Process module in the Arena template, you might specify the
name of the resource to seize and release to be Packer. When you do so, you create a new
resource element named Packer. If you place another Process module and pull down the
list associated with the Resource name field, you will see that Packer appears in the list.
Elements are separated into types such as queues, resources, conveyors, etc. Each of these
types has its own set of characteristics, referred to as properties. A queue has properties
such as a ranking rule; resources have capacities, failures, etc.; and conveyors have
properties such as velocity and type (accumulating or nonaccumulating). (Refer to
Appendix B “Tables” on page 211 for a list of all element types and their properties.)
Each specific element that is defined in a model has its own values for its properties. For
example, one resource element named Clerk might follow a capacity schedule named
Early Day; another resource element named Supervisor might follow a schedule named
Normal Day.
It is important to note that the properties of a particular element, such as the Clerk
resource, are global to the entire simulation model. If the Clerk initially is defined by a
Process module from the Basic Process panel and you edit a Resource module (also from
the Basic Process panel) in the model, the resource Packer will automatically be specified,
with default information, such as type and capacity.
In a module definition, in the dialog design window, you identify particular operands that
will define elements by specifying in the operand’s LogicProperties property that the
operand type is Element. Similarly, an operand that defines a property of an element is
given the type Property. The chapter “Elements” presents a more detailed discussion of
the concept of elements and their properties. Refer to the “The Dialog Design Window”
on page 77 for information about defining element and property operands.

Arena hierarchy and SIMAN

Arena employs a hierarchical architecture for simulation modeling—i.e., modules are
defined utilizing other modules. This approach offers many benefits. Modules that

22
 • • • • •
2 • ARENA TEMPLATE DEVELOPMENT OVERVIEW

represent subsets of a process or set of similar processes may be developed and verified
once, then may be reused to define new, higher-level modules that correspond to a
process; such as a computer CPU, a ticket agent, or a canning line labeler. The component
modules (e.g., select next job to process, enter passenger name, or wrap label) also may be
utilized directly in models to capture accurately the nature of complex systems or of
system elements that have peculiar facets not represented by higher-level modules.
The base modules of Arena’s hierarchy represent the SIMAN simulation language. These
modules form the SIMAN template, which contains two panels: Blocks and Elements.
The Blocks panel consists of modules that generate blocks in a SIMAN model (.mod) file,
such as Delay, Branch, etc. Many of the modules in the Arena template are given the same
name as Blocks modules and perform the same function as their Blocks panel

2 • Overview
counterparts. However, the modules in Arena offer options for the types of information
that is to be placed in an operand (e.g., whether the type of element to be assigned a value
is an attribute, a variable, a picture, etc.), and define both the model logic (i.e., blocks) and
elements (i.e., information to be written to SIMAN’s experiment file).
The Elements panel consists of modules that represent each of the element types in the
SIMAN experiment (.exp) file, such as resources, queues, counters, etc. Many data
modules in the Arena template panels (e.g., resources, queues, conveyors) correspond to
modules in the Elements panel.
When you build a new module definition, one of the steps is to define the logic associated
with the module. In doing this, you attach one or more template panels to the Project Bar
and place instances of modules. If these modules come from the SIMAN template
(Blocks/Elements panels), when a modeler uses your module, the final SIMAN model and
experiment used for a simulation run are generated directly through the modules you
placed. This may be thought of as a module utilizing a single level of hierarchy, as
illustrated in Figure 2.17.

Figure 2.17 Single level of module hierarchy (SIMAN modules in logic window)

A modeler (or template designer) who uses ModuleA does not need to understand about
the underlying structure of the module (i.e., the contents of the logic window). Instead,
you have created a new interface to a DELAY followed by a SIGNAL by defining
ModuleA’s operands and by establishing the references to those operands in the DELAY

23
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

and SIGNAL modules contained in the logic window. As the template designer, you have
complete control over which characteristics of the underlying logic are changeable by
users of the module and which characteristics are fixed at values you have chosen.
To extend the hierarchy concept to another level, you might use an instance of ModuleA
in the logic window of a module (ModuleB) in another template panel file. Here you have
the option of using the underlying components of ModuleA (DELAY and SIGNAL)
directly; or instead you can leverage the effort you already have placed in designing and
verifying ModuleA. Figure 2.18 illustrates the hierarchy of a sample ModuleB’s
definition, including an instance of ModuleA (built hierarchically with Blocks panel
modules at the base) and an instance (COUNT) directly taken from the Blocks panel.

Figure 2.18 Multi-layered hierarchy

While the concept of hierarchy is extremely powerful, it is not necessary for modelers to
understand either that the tool they are using is built hierarchically or what the underlying
hierarchical structure is. For template developers, hierarchy is an opportunity to be
exploited for leveraging effort, reusing verified modeling approaches, and encouraging
consistency of design.

Flowcharts and data modules

Although all modules have many common features, it sometimes is useful in the design of
a template to distinguish between “flowchart” and “data” modules. We use the term
flowchart module to refer to a module that permits entity flow in and/or out, such as the
following modules displayed in Arena’s Basic Process panel: Create, Dispose, Process,
Decide, Batch, Separate, Assign, and Record. These are the fundamental processing
modules that act on entities.
On the other hand, entities do not flow into or out of data modules. These data modules
are placed to supply information about elements of a simulation model. Data modules in
the Basic Process panel include: Entity, Queue, Resource, Variable, Schedule, and Set.

24
 • • • • •
2 • ARENA TEMPLATE DEVELOPMENT OVERVIEW

While flowchart modules are placed in the model window and are connected to form a
flowchart and describe the logic of your system, data modules are not placed in the model
window. Instead, they are edited via a spreadsheet interface. For more information on
defining a module as a data module, see “Defining data modules” on page 73 of “The
“Template Window.”

Use of templates
Introduction
Templates may be developed using Arena to address a wide range of needs. Some
templates will be conceived for use by a large targeted market; others will be intended for

2 • Overview
use simply by the template designer to increase productivity in building simulation
models. In this section, we outline some of the possible uses of Arena template
development features. We are confident that this list represents only the tip of the iceberg.

General modeling tools

The first templates developed in Arena were the SIMAN and Arena templates. The two
panels composing the SIMAN template—Blocks and Elements—provide a graphical
interface to the SIMAN language for modelers and form the base of all Arena modules.
The three panels composing the Arena template—Basic Process, Advanced Process, and
Advanced Transfer—provide modules that capture commonly encountered processes and
system elements using generic terminology (e.g., process, decide, record).
In the manufacturing area, modelers have exploited the powerful capabilities built into
SIMAN and Arena for capturing essential system characteristics, including operational
schedules, process plans, automated material-handling systems, etc. Modelers also have
applied the Arena template to represent systems such as airline operations, health care,
logistics, distribution, and business process reengineering (BPR). And, even within some
organizations, Arena has been used for a wide spectrum of simulation studies, from long-
range planning to analysis of near-term system changes.
The strength of a general modeling tool, used in a single, cohesive environment, is that
modelers are provided with a core set of terms and concepts that can be applied to many
different problems. Knowledge gained in studying one system can readily be applied in
performing the next simulation project.

Industry-oriented environments
Templates also have been developed targeting use in a particular industry, such as wafer
fabrication in the semiconductor industry. Such templates might be developed for
commercial use, or in the case of an organization that provides support to an industry,
templates might be developed and made available to companies in the industry.

25
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

There are two main advantages of industry-focused templates. First, the template can use
the terminology that is appropriate for the industry to minimize the abstraction needed for
a modeler to translate a system into the simulation software tool. More importantly,
through the power afforded by Arena’s hierarchical templates, a template can be built that
is fully customized to represent accurately the elements of systems in the industry, rather
than simply mapping existing modeling functionality provided by a general modeling
tool. The designer of the template has the capabilities at hand to mimic exactly the
behavior of equipment, people, parts, components, etc., providing whatever spectrum of
options is appropriate for the variations of these system elements.

Application-focused tools
Many of the templates that are developed using Arena will aid modelers in representing a
particular system, facility, or process. In building these templates, the template designer
will have a more narrow focus than the developer of a general modeling template or a
template to be used widely in an industry. For example, a template might be built for use
in analyzing engine assembly lines in an automotive company or for representing delivery
of pharmaceuticals in a hospital. The template’s scope is not large enough to encompass a
large subset of problems in a particular industry; rather, the modules contained in the
template are focused on a particular application that might appear in many systems or
facilities.
These application-focused templates benefit from Arena’s hierarchical structure in the
same ways as industry-focused templates: the interface presented to a modeler can be
customized to be very familiar (both in terms of graphical animation and the terminology
used in module dialogs); and parts, processes, etc., in the target application environments
can be represented accurately.
In some cases, a modeler might build a template for his/her own individual use. In other
cases, templates might be created for use among a few modelers in a common group;
many application-focused templates will be shared among different modeling groups in an
organization.

Improving modeling productivity and sharing modeling

technology
For a modeler, Arena affords the opportunity to reuse modeling techniques that are
learned in the process of building models. In the evolution of programming tools, reusable
code was captured in procedures/subroutines/functions. Later, object-oriented tools
allowed the full characteristics of “objects” represented in the software to be defined for
reuse. A module can be thought of as analogous to an object (in object-oriented
software)—the module allows you to capture the complete characteristics of a process that
you want to model in a self-contained package that you may reuse and that may be
customized in each use.

26
 • • • • •
2 • ARENA TEMPLATE DEVELOPMENT OVERVIEW

By permitting you to collect all of the important characteristics of a simulated system

element (i.e., the logic, the animation, and the data) in a single module, Arena encourages
you to both reuse and share what you learn.
For example, in modeling a computer network, you might develop a set of modules that
capture the logic for allocating jobs to a printer. Each time you need to model another
printer, you could copy the logic directly into the model (by selecting and duplicating all
of the modules that represent the logic). Or, using Arena, you could instead create a single
module to represent the printer, embedding the logic in the module’s definition. The
second approach—building a reusable “printer” module—decreases the likelihood that
you might make a mistake in reusing the original printer representation, encourages you to
reuse what you have learned, and makes it much easier for you to share with others the

2 • Overview
modeling approach you have developed.

27
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

28
3 Module-building Tutorial
In this chapter, we will build a small module to illustrate the fundamental concepts of
creating templates in Arena. We present this material with the goal of providing a step-by-
step tutorial that you can follow using the Arena software. If you follow the instructions in
this chapter, at the end of the tutorial you will have built a complete module representing a
high-speed computer printing station, and you will have created a simulation model using
it. While the module you will create is quite simple, it does include the key elements of
module definitions: a dialog with a few operands, simulation logic, a user view with
animation, and a panel icon.
As you build the module outlined in this chapter, it may be helpful to refer to Chapter 2,
“Arena Template Development Overview,” which provides definitions of important terms
and explains critical concepts related to building templates.
We begin by describing the module that is to be built. Following this, we present sections
that document the procedure used in four module definition windows (dialog design,
logic, user view, and panel icon) to create the module. Finally, we use the module to build

3 • Module-building Tutorial
a small simulation model.

Module overview
To illustrate the process of building a module in Arena, we will create a module
representing a high-speed printing station in a computer network. Models that utilize this
Printer module will contain entities representing print jobs.
Our Printer module will be analogous to a server; i.e., it will accept entities to be
processed and will send the entities, after processing, to another module. It does not create
or dispose of entities.
The logic captured by the Printer module includes the concept of a changeover. If the type
of job being printed (represented by an entity attribute) changes from one job to another, a
technician is signaled to perform a changeover activity, such as changing the paper type
feeding the printer.
In designing a module such as the Printer example, one of the important decisions to be
made is what operands will be presented to the modeler. If you present only a few
important operands, modelers will be provided with a simple interface that focuses
attention on the most important characteristics of the process represented by the module.
However, by limiting the number of operands presented, you also place a restriction on
the flexibility a modeler has to tailor the module to represent a particular system
accurately.

29
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

For this tutorial, we will start small and supply only a few operands with the Printer
module. Keep in mind, though, that many additional options could be provided to a
modeler by expanding the operands defined in the module. After you have created the
Printer module described in the tutorial, you can try to expand this example by placing
additional operands to solicit other options from the modeler.
The Printer module dialog is shown in Figure 3.1.

Figure 3.1 Printer module dialog

In the Printer module, we ask the modeler to enter the following information:
„ the Printer Name, which will provide the name of the printer resource as well as the
queue name for those entities waiting for the printer resource,
„ the Technician who performs the changeover, which will define a resource,
„ the Changeover Time (used only during changeovers between job types), and
„ the Print Time (i.e., the time required to print the entire job).
The logic window associated with the completed Printer module is shown in Figure 3.2.
So that you have an understanding of the logic we plan to represent by the Printer module,
we provide a brief description in this section. A combination of modules from the SIMAN
Blocks and Elements panels and Arena’s Basic Process panel is used. Step-by-step
instructions for creating this logic are presented later in the chapter.

30
 • • • • •
3 • MODULE-BUILDING TUTORIAL

Figure 3.2 Printer module logic

3 • Module-building Tutorial
A print job entity arriving at the Printer module begins processing at the Queue module
instance. The print job waits to seize the printer resource, then tests in the Decide module
to determine whether a changeover should occur.
If there is a changeover, the entity follows the changeover logic path (shown from the
True exit to the Assign module). In this case, it changes a variable, `Printer
Name`_Change, to the value of 1 to indicate that a changeover is taking place and
performs the changeover in the Process module. Following the changeover, the print job
entity restores the changeover variable back to 0 and changes a variable that records the
last job type processed on the printer (to the entity’s job type).
If no changeover was required, the entity is sent from the Else (or false) condition of the
Decide module directly to the Delay module to process the print job. (Entities that
underwent a changeover also enter the Delay module after completing the changeover
process.) After the print time delay, the print job entity releases the printer resource.
To create the Printer module logic, you may either build the submodel directly in the logic
window of the module definition or you may prepare an Arena model with the same logic.
If you build the logic first as an Arena model, you have the opportunity to use Arena’s
Run Controller and to view the detailed animation of the module logic by running a
simulation of the logic directly (rather than through an instance of the Printer module).
Using this approach, after you are confident that the logic has been specified as you want,
you can copy the verified logic from the model window to the Printer module’s logic
window via Arena’s clipboard.

31
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

For the purposes of this tutorial, however, we present the Printer module by defining the
logic directly in the module definition’s logic window. In this way, we can concurrently
discuss both the sample problem to be addressed (i.e., the high-speed printer station
module) and the particular aspects relating to creating modules. You may want to create
the logic shown in Figure 3.2 in a model window first in order to develop an
understanding of the module we will be creating in this tutorial.
We will present the Printer module definition windows in the following order: Dialog
Design, Logic, User View, Panel Icon. We do so because we find that it is important to
consider together the module logic and the operands when designing a module. In this
tutorial, we present the dialog design window first because it can be completely defined
and tested without the underlying module logic. The logic, on the other hand, is difficult
to test without operands to provide an interface for defining the data that can change from
instance to instance of the module. When you are developing your own modules, you
probably will find that you move back and forth between defining the module logic and
adding operands in the dialog design window, which we find to be a natural way of
creating a complete module definition.

Getting started—A new template

The Printer module we will develop will be part of a new template panel file. To work
with a new template panel, open a new template window by selecting File > New from the
main menu bar and then choosing Template Window as the new file type. This opens a
template window, as shown in Figure 3.3.

Figure 3.3 New template window

32
 • • • • •
3 • MODULE-BUILDING TUTORIAL

The first step in defining a module is to name it. Click the Add button, type the name of
the module, Printer, and choose OK. As you will see in the completed module, its
name is used for the following:
„ the default text label displayed in the panel icon (only the first four letters are
displayed, but may be edited),
„ the name displayed in a template panel if the display type is text (rather than icon),
„ the default name of the module’s main dialog object (defined in the dialog design
window),
„ the default title of the module’s main dialog, and
„ the default name of the module handle (defined in the user view window).
To open each of the module definition windows, be sure that the Printer module is
selected in the Module Definitions list. To select it, simply click on the module name.
We will return to the template window in “A Sample Model” on page 57 to prepare the
template panel file for use in an Arena model.
Note: If you would like to save the template panel to a template panel library (.tpl) file, select the
File > Save menu item from the main menu bar.

3 • Module-building Tutorial
Dialog Design
The dialog design window
We begin designing the Printer module by defining its dialog design and its operands.
Open the dialog design window by selecting the Printer module (in the template window's
Module Definitions list), then select the Window > Dialog Design menu item or click the
Dialog Design Window toolbar button on the Template Development toolbar. This
opens the dialog design interface for the Printer module, as shown in Figure 3.4.

33
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Figure 3.4 Dialog design window

The dialog design window consists of the following components:

„ Dialog Form—the dialog form layout is displayed in the center of the window.
„ Toolbox—provides an interface for graphically adding controls (e.g., text boxes,
combo boxes, or dialog buttons) and static graphics (e.g., text, lines, or group boxes)
to the dialog form layout(s).
„ Operand Explorer—displays the hierarchical organization of the dialog form,
operand, and repeat group objects that define the dialog structure of the module.
„ Design Properties—provides an interface for viewing and/or editing properties of the
currently selected object(s).
When a module definition’s dialog design window is opened, by default the main dialog
form of the module is displayed in the center of the window. Thus, for our Printer module
definition, we see a dialog form named “Printer.” This is the dialog that will be displayed
when the modeler double-clicks on an instance of a Printer module in a model window.
To specify the dimensions of the dialog form, go to the Design Properties window. This
window should display the properties of the Printer DialogForm object. Edit the Height
and Width property rows and enter a height of 110 and a width of 170.

34
 • • • • •
3 • MODULE-BUILDING TUTORIAL

Figure 3.5 Design properties of the Printer DialogForm object

Note that you can also graphically resize a dialog form. First click anywhere on the form
to make sure that it is selected. Then, click and drag one of the sizing handles that appear
on the border of the form. The sizing handles resemble small black boxes, and the pointer
turns into a double-headed arrow when you point at the handle.

Adding the module’s dialog operands

3 • Module-building Tutorial
The Printer module’s dialog will include four visible operands editable by the user (as
shown previously in Figure 3.1): Printer Name (combo box control), Technician (combo
box control), Changeover Time (text box control), and Print Time (text box control).

PRINTER NAME OPERAND

To add the Printer Name operand to the dialog form layout and module definition,
perform the following steps:
1. Click on the ComboBox control in the Toolbox section. Then, move the pointer to the
location in the dialog form where the “Printer Name” operand is to be placed. Left-
click again to place the combo box on the dialog form layout.
Note: At this point, your dialog form layout may not resemble the form in Figure 3.1. You will
learn how to arrange the operands graphically in “Arranging the Dialog form layout” on
page 39.

2. In the Design Properties window, specify the properties of the selected combo box as
follows:
‡ Specify the Name property as Printer Name. This is the name of the operand.
It will be used in the logic window for operand references (to provide the value
entered by a modeler in an instance of the Printer module to the underlying logic).
The Name property is the automatic default for the Text property, which is the
prompt text that is shown to the user on the dialog form.

35
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

‡ Specify the DataType property as SymbolName. This will ensure that a modeler
using the Printer module can specify only a valid symbol name for the Printer
Name operand.
‡ Specify the Required property as True. This will require that any use of an
instance of the Printer module will have a non-blank value for the Printer Name
operand.
‡ Specify the InUserView property as True. Because the Printer Name is the
primary piece of information related to the Printer module, displaying it in the user
view will help a modeler identify the particular printers represented in a model if
more than one Printer module is used.
3. In the Design Properties window, select the LogicProperties property of the combo
box. This property provides a dialog for specifying characteristics of the operand
related to its purpose in the module’s interface and logic. In this example, we want the
Printer Name operand to also define a resource element, based on the printer name.
Thus, the Logic Properties dialog is completed according to Figure 3.6.

Figure 3.6 Logic properties of the Printer Name ComboBox object

The items that will be displayed and available for selection in a ComboBox operand’s
drop-down list are specified by the List property of the Design Properties grid. By default,
because the Printer Name operand has been specified as an Element operand, the list is the
resource element list.

36
 • • • • •
3 • MODULE-BUILDING TUTORIAL

TECHNICIAN, CHANGEOVER TIME, AND PRINT TIME OPERANDS

The three remaining visible operands—Technician, Changeover Time, and Print Time—
are defined in the same manner as the Printer Name operand.
The Technician operand is added using a ComboBox control. This operand also defines a
name for a resource, and thus in the LogicProperties property the operand’s type is also
specified as Element of type RESOURCES. The operand’s DataType is specified as
SymbolName and its Required property is True.
The Changeover Time and Print Time operands are added using TextBox controls. These
two operands allow more flexible entries and thus their DataType properties are specified
as Expression. They are Basic type operands in the LogicProperties property and do not
require a value to entered by the modeler.

Adding the module's entry/exit point operands

In addition to the four visible operands seen and editable by users in the module’s dialog,
two hidden operands will be added to the module definition. These operands will be used
to define the entry and exit points of the module, thus allowing the user to connect other

3 • Module-building Tutorial
modules into and out of the Printer module for entity flow.
Because the entry label and exit label operand fields are hidden from the user, the user will
not have access to the fields within the dialog box. However, graphical entry and exit
points will be available in the module’s user view to place the module connections.
To add a hidden operand to the module definition, click on the HiddenOperand control in
the Toolbox section. Then, move the pointer to any location in the dialog form and left-
click again to add the hidden operand. The hidden operand will be displayed in a window
section at the bottom of the dialog design (and also in the Operand Explorer tree) as
shown in Figure 3.7.

37
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

HiddenOperand object

Figure 3.7 HiddenOperand object in the dialog design window

After adding two hidden operands to the dialog design and module definition, specify the
Name properties of the two operands as Label and Next Label. In the
LogicProperties property of the operands, specify the operands as entry and exit points per
Figure 3.8 and Figure 3.9.

38
 • • • • •
3 • MODULE-BUILDING TUTORIAL

Figure 3.8 Logic properties of the Label HiddenOperand object

3 • Module-building Tutorial
Figure 3.9 Logic properties of the Next Label HiddenOperand object

Arranging the Dialog form layout

At this point, you have completed the definition of the Printer module’s operands.
Controls that have been placed onto a dialog form’s surface may be graphically selected,
moved, and resized. Arrange the combo box and text box controls on the Printer dialog

39
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

form such that the layout looks like Figure 3.1. The completed dialog design window for
the Printer module should look similar to Figure 3.10 below.

Figure 3.10 Completed dialog design for Printer module

You can close the dialog design window by clicking the Window Close button, or you can
leave the dialog design window open for reference while you define the module logic.

Logic
The logic window
The next step in creating the Printer module is to define the modeling logic that entities
will undergo during a simulation run. This logic is created by designing an Arena
submodel (consisting of instances of modules from other template panels) in the logic
window of the Printer module definition. To open this window, select the Window >
Logic menu item or click on the Logic Window toolbar button in the Template
Development toolbar.
The activities related to building the module logic are fundamentally the same as those
involved in creating an Arena model. For the instructions presented in this tutorial, we
assume that you already are familiar with the basic interactions for building models in
Arena.

40
 • • • • •
3 • MODULE-BUILDING TUTORIAL

Overview of the Printer module logic

When a modeler places an instance of the Printer module, the underlying logic of the
module will be added to the model window. As we described earlier in this chapter, the
Printer module accepts entities at a queue, processes them through logic with resources,
and sends them to the next module to which the Printer module is connected.
The Printer Name operand will be used to establish the name of the queue and the
resource in the underlying module logic so that a modeler can identify different printer
areas by placing multiple instances of the Printer module and supplying different values to
the Printer Name operand. The name of the queue that holds entities prior to processing
will reference the Printer Name operand and will include a “_Q” text string that will be
appended to the printer name so that the queue name will be unique, but related to the
resource name.
To capture the logic necessary for detecting when a changeover is to occur, a simulation
variable is used. Each time an entity performs a changeover, a variable associated with the
printer is assigned the job type of the entity, indicating the type of the last job processed
on the printer. To name this variable, “_LAST” is appended to the Printer Name (similar

3 • Module-building Tutorial
to the naming convention used for the printing queue). This ensures that each printer
placed in a model has a unique variable associated with it to store the last print job
processed.
In the Printer module, an entity attribute named Entity.Type is compared with the variable
storing the last processed print job on the printer to decide whether a changeover should
occur. In designing the module, the attribute name that stores the print job type could have
been added as an operand of the module so that modelers could specify their own attribute
names. Because we chose to build this information into the module logic without allowing
modelers to change the attribute name, it is necessary that a model containing the Printer
module assigns the attribute named Entity.Type before sending entities to the Printer
module. This can be done automatically using either the SIMAN or Arena template’s
Create module and specifying an entity type (which will assign the internal attribute
Entity.Type equal to that type). This aspect of module design—whether to predefine
information or to provide options to modelers—often is more challenging than the process
of building the module itself.
In the following section, we provide a step-by-step description of the process of building
the module logic for the Printer module. Figure 3.11 shows the completed module logic.

41
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

As you create the module, it may be helpful to refer to this figure to ensure that you are
correctly connecting the modules in the logic window.

Figure 3.11 Printer module logic

Receiving entities and seizing the printer—The Queue and

Seize modules
The first module instance in the Printer logic is the Queue module from the SIMAN
template’s Blocks panel. Entities would first be created in another module in the model,
such as a Create module. A graphical connection from a module would then send entities
into the Printer module, where entities will begin processing through the Printer module
logic at this Queue module. In its dialog, shown in Figure 3.12, you specify that the name
of the Queue module is a reference to the Printer Name operand by entering the operand
name enclosed in back quotes (i.e., `Printer Name`). In this case, our queue name will
have the “_Q” appended so that it is different from the resource name. The label field for

42
 • • • • •
3 • MODULE-BUILDING TUTORIAL

the queue, which represents the graphical entry into the Queue module, contains a
reference to the hidden operand `Label`.

3 • Module-building Tutorial
Figure 3.12 Queue module dialog in printer logic

Alternatively, you could have used either the Station or Enter modules from the Advanced
Transfer panel to receive entities into the Printer module. Using stations allows for the
movement (with an optional delay time) between areas, instead of graphical connections
for logic flow.
The print job entities will remain in the queue until the printer resource is available, at
which time they will Seize the printer resource using a SIMAN Seize module. Note that
the printer is seized before a decision is made regarding a changeover. The module is
designed this way so that the printer resource is unavailable to process other print jobs
during a changeover.

43
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

In the Seize module instance, you identify the resource to be seized by inserting a single
resource into the Resources list. Specify the Resource ID field to be `Printer Name`.
Figure 3.13 shows the dialog for the Seize module instance.

Figure 3.13 Seize module dialog in printer logic

Deciding whether to changeover the printer—The Decide

module
The next module encountered by print job entities is a Decide module (from the Basic
Process panel) with two branches (Type is 2-way by Condition). The first branch tests to
see whether the value of the Entity.Type entity attribute differs from the last job type
processed on the printer, stored in a variable named `Printer Name`_LAST. If so, entities
are sent to the changeover logic. The second branch, an Else (or false) condition, sends
entities directly to be processed on the printer.
The dialog for the Decide module instance is shown in Figure 3.14. The dialog is shown
with the test condition for detecting changeovers. To define the Decide module, use a two-
way condition testing the variable `Printer Name`_LAST against the entity attribute

44
 • • • • •
3 • MODULE-BUILDING TUTORIAL

Entity.Type, as shown in Figure 3.14. The Else (or false) condition is generated
automatically with a 2-way by Condition type of decision.

Figure 3.14 Decide module dialog in printer logic

3 • Module-building Tutorial
In the logic window, the connection from the True condition sends entities to the
changeover logic, (described next). The False condition connects directly to the printer
logic (described after the changeover section).
Note: Because different entities in the same model might access either path of logic, the decision
regarding changeover is built into the simulation model logic, rather than controlled by attaching
switches to the modules. Switches determine logic to be included for all entities. In cases where
different types of entities perform different actions, a module such as Decide (N-way by
Condition) or SIMAN Branch block should be used. (Switches are described in the “Arena
Template Development Overview” and “Switch Window” chapters.)

Changeover logic—Assign, Process, and Assign modules

The logic to represent the changeover is captured by three modules. First, an Assign
module (from the Basic Process panel) changes the value of the variable, `Printer
Name`_Change, so that statistics can be collected and the animation can represent
changeovers. Next, a Process module (also from the Basic Process panel) holds the print
job entity until the technician resource specified in the Printer module dialog is available,
delays for the changeover time, and releases the technician. Finally, another Assign
module restores the value of the variable, `Printer Name`_Change, to 0 and changes the
variable that records the last print job type processed on the printer to be the value stored
in the Entity.Type internal attribute of the entity.

45
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

The first Assign module dialog is shown in Figure 3.15. To define this Assign module,
you insert an assignment, keep the default Type as Variable, specify the variable name as
`Printer Name`_Change, and type the new value of 1.

Figure 3.15 Assigning printer changeover variable in printer logic

To define the actual changeover process, you supply the resource name and process time
information to the Process module by referencing the Technician and Changeover Time
operands of the Printer module, as shown in Figure 3.16. Note that you will change the
Action field to Seize Delay Release to specify the logic for seizing and releasing the
specified technician during the changeover. Also, because the changeover time is defined
as an expression, the Delay Type field is changed to Expression so that the `Changeover
Time` operand can be used in the Expression field.

46
 • • • • •
3 • MODULE-BUILDING TUTORIAL

Change the units for the Delay from the default hours to minutes. It is important to
remember to be consistent with time units between various modules, especially if the end
user does not supply the units information.

3 • Module-building Tutorial
Figure 3.16 Process module dialog in printer logic

The final module in the changeover logic is another Assign module with two assignments:
the printer changeover variable and the last job type printed. To supply this information to
the Assign module, insert two assignments. In the first assignment, select the Variable (as
was done in the first Assign module) for the assignment type; then enter `Printer
Name`_Change for the variable name and 0 for the new value. In the second

47
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

assignment, select Variable for the assignment type and enter `Printer Name`_LAST
for the variable name and Entity.Type for the new value, as shown in Figure 3.17.

Figure 3.17 Assigning last job variable in printer logic

The print logic—Delay and Release modules

After a print job entity completes the changeover logic, it next performs the actual print
logic, joining other entities that were not processed through the changeover logic. The
printer resource was seized by the entity (whether changeover occurred or not) earlier in
the Printer module logic. To complete the printing process, the print job simply undergoes
a time delay and releases the printer resource using the Delay and Release modules from
the Blocks panel.
To specify the delay time in the Delay module, simply reference the Print module operand
by typing `Print Time` in the Duration field, as shown in Figure 3.18. Note that the

48
 • • • • •
3 • MODULE-BUILDING TUTORIAL

SIMAN block does not specify a time unit, such as hours or minutes. The default time
units for modules will be set later in this example using the Run > Setup menu.

3 • Module-building Tutorial
Figure 3.18 Delay module dialog in printer logic

The Release module simply needs to release the printer resource. To define this, insert a
single resource in the Release module and define its name to be `Printer Name`, as was
done in the Seize module. Because this is the last module in the logic, the exit point
operand, Next Label, will be referenced in the Next Label field of the Release module.

49
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

This will allow entities to flow from the Printer module to the next module to which it is
graphically connected. Figure 3.19 shows the dialog for the Release module.

Figure 3.19 Release module instance dialog in printer logic

Just as we mentioned earlier that the Enter or Station module could be used to enter into
the module (instead of graphically connecting into the Queue module), we could have
used a Route or Leave module to send entities to another station in the model. In this case,
a Next Activity operand would have been required to specify where to send the entity
instead of graphically connecting from the Release module. Additionally, the Stations
element would need to be generated.

Defining the Printer module elements—Queues and Variables

elements
The final step in defining the logic for the Printer module is to define the Queues and
Variables elements associated with the printer name so that the Printer module completely
defines both the logic and the elements necessary to capture a high-speed printing station.

50
 • • • • •
3 • MODULE-BUILDING TUTORIAL

To create the `Printer Name`_Q queue, place a Queues module instance from the
Elements panel of the SIMAN template. In the Queues module, insert a single queue and
name it `Printer Name`_Q, as shown in Figure 3.20.

3 • Module-building Tutorial
Figure 3.20 Queues module dialog in printer logic

51
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Similarly, the `Printer Name`_Change variable can be generated by placing a Variables

module instance from the Elements panel. Within the module, add a single variable,
named `Printer Name`_Change, as shown in Figure 3.21.

Figure 3.21 Variables module dialog in printer logic

The Entity.Type attribute is automatically generated as one of the internal attributes of all
entities when the entity type is specified with a Create module (from Blocks or Basic
Process panel). Therefore, an Attributes element module is not necessary to define
Entity.Type. However, remember that because this attribute is used to evaluate incoming
entities for changeovers, the entity should have an assigned entity type value before
entering the Printer module. Otherwise, all entities will have an Entity.Type value equal to
0 and no changeovers will occur.

52
 • • • • •
3 • MODULE-BUILDING TUTORIAL

The logic for the Printer module now is complete. You may close the logic window by
selecting the Close option from the logic window menu, or you may leave the window
open while you define the last two parts of the Printer module—the user view and panel
icon.
Note: In this example, we have used the logic window to create two elements associated with the
printer, the queue, and the changeover variable. These elements could have been generated,
instead, by utilizing hidden element-type operands in the dialog design window. Based on the
information you wish to provide the user for a given element, you will need to decide which
method to use for creating specific elements and their properties. Please refer to the chapter
“Elements” for a more in-depth discussion of the various ways to define elements.

User View
The next step is to design the user view for the Printer module. When a modeler places an
instance of the Printer module in a window (e.g., a model window), the objects that are
added to the window are created in the module definition’s user view window.
The user view for the Printer module will contain six objects:

3 • Module-building Tutorial
„ a module handle,
„ a displayed operand (the Printer Name),
„ an entry point to connect logic into the module,
„ an exit point to connect logic out of the module,
„ an animation resource, and
„ an animation global picture.
Arena automatically places the first four objects in the user view window. Every module
is given a module handle that displays the name of the module (by default). In an instance
of the Printer module, a modeler double-clicks on the handle to open the main dialog.
Arena places the displayed operand in the user view window after the Printer Name
operand was defined with the InUserview property specified as True (in the dialog design
window). The entry and exit points are automatically placed when an operand is of type
Entry Point or Exit Point.
To complete the user view, you will add an animation resource to display the state of the
printer during a simulation run and an animation global picture to display a symbol during
the changeover process.

53
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

To open the user view window, select the Window > User View menu item or click on the
User View toolbar button on the Template Development toolbar. The user view for the
Printer module should appear as shown in Figure 3.22.

Figure 3.22 Initial user view window for Printer module

To add an animation resource, place the resource picture (from the Animate toolbar)
above the Printer module handle name and double-click on it to open the Animation
Resource dialog. In this dialog, specify the resource identifier to be `Printer Name`, so
that the name of the animation resource matches the resource defined when a modeler
uses the Printer module.
The Printer module needs two pictures for the resource to represent the Idle and Busy
states. You specify the resource states and draw the pictures just as is done in Arena
models.

54
 • • • • •
3 • MODULE-BUILDING TUTORIAL

Figure 3.23 shows the completed resource picture dialog for the Printer module.

3 • Module-building Tutorial
Figure 3.23 Animation resource picture dialog

Finally, add an animated global picture to the left of the resource by using the Global
button on the Animate toolbar. Specify the expression to be `Printer Name`_Change (the
variable that is assigned to 1 during a changeover). The trigger value for the global should
be 1, so that the picture you place will show up only when the changeover is occurring.
When the value of `Printer Name`_Change variable is set to 0 (after the changeover is

55
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

complete), the global symbol will then disappear, since no picture is specified for a trigger
value of 0. Figure 3.24 shows the completed global picture.

Figure 3.24 Animation global picture dialog

The global picture is used instead of animating the `Technician` resource who performs
the changeover. This is done because the technician may be required to perform
changeovers at many different printer modules in the model. The global symbol will show
the picture of a technician only when the changeover is occurring at that particular printer
module.

Panel Icon
The panel icon for a module is the picture that appears in the panel when a template panel
file is attached to a model window (or to the logic window of another module’s
definition). It is drawn in a window that is similar to the picture edit window used to
create animation resources, entities, etc.

56
 • • • • •
3 • MODULE-BUILDING TUTORIAL

For the Printer module, you can copy the objects from the animation resource Printing
picture (in the user view) to the panel icon window using the clipboard. To do so, edit the
picture associated with the Busy state of the animation resource, select all of the objects,
and copy them to the clipboard. Then, open the panel icon window by selecting the
Window > Panel Icon menu item or clicking the Panel Icon toolbar button in the
Template Development toolbar. The panel icon window contains a single text object, by
default, that displays the module name. To add the graphics from the animation resource
picture, paste them from the clipboard into the panel icon window. The name of the
module, Printer, is initially shown as just the first four letters, “Prin.” Double-click on the
name so you can change this to the whole word “Printer.” This results in a panel icon
shown in Figure 3.25.

3 • Module-building Tutorial
Figure 3.25 Panel icon window for Printer module

A sample model
Preparing the template for use
You now have completed the definition of a module representing a high-speed printer
station. Its operands allow a modeler to customize certain characteristics of the printer, the
underlying module logic captures the critical aspects of printer operations, the user view
provides an animation to aid modelers in understanding the behavior of systems that
include a printer, and the panel icon completes the package.
The Printer module is part of a template panel library. If you have not yet saved your
template panel to a library file, do so now by selecting the File > Save menu item from the

57
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

main menu bar or by clicking the Save button from the Standard toolbar. You might
select a name such as HSPrint.tpl for the file.
The next step is to generate a template panel object (.tpo) file that can be attached to the
Project Bar. Select the Check > Generate TPO menu item from the main menu bar or
click the Generate toolbar button. This initiates a check of the template panel file’s
modules (in this case, just the Printer module) to verify that the operands that are
referenced by objects in the module definition windows are defined in the dialog design
window, the operands referenced in the user view window are defined, etc.
If you correctly followed the instructions for building the Printer module, you should
receive a message that the .tpo file was generated successfully. However, if your module
definition contains an error, an Arena error window will be displayed containing a
description of the error. For example, if you mistyped the operand reference (`Print Time`)
in the logic window’s Delay module as `Printing Time`, the error message “Referenced
operand not defined: `Printing Time`” is displayed in the error window. You can use the
Edit button to correct the error; it opens the appropriate window (in this case, the logic
window) and displays the dialog for the object containing the error (i.e., the Delay module
instance). You can type the correction in the dialog and select OK, then generate the .tpo
file.
Warnings, on the other hand, do not have to be resolved. The .tpo file will generate
successfully regardless of whether you choose to address the warnings. This, of course,
has nothing to do with the correctness of your module definition; the .tpo file will still be
generated successfully.
After you have successfully generated a template panel object file, you can use the Printer
module in a simulation model to test its logic, animation, and so on. In the following
section, we present a simple model containing a single printer.

Single printer simulation model

Our sample simulation model will create two types of print jobs using two Create
modules. The internal attribute Entity.Type will be assigned values of Entity 1 and Entity
2, respectively. The print jobs will be sent to a Printer module to be processed by simply
connecting each Create module to the Printer module. Once jobs complete the printing
process, they are sent graphically to the Dispose module that removes the print job entities
from the system. To help verify that the printer logic is working correctly, we will use
constant values for the interarrival times of entities and for the two delays that can occur
at the printer (the changeover time and the print time). We can calculate the expected
values for statistics such as the percent of time each resource should be in each of its states
(busy and idle), then perform a pilot simulation run and compare the results to the
expected values.

58
 • • • • •
3 • MODULE-BUILDING TUTORIAL

Figure 3.26 shows the completed model; step-by-step instructions for building the model
follow.

3 • Module-building Tutorial
Figure 3.26 Sample simulation model using Printer module

GENERATING PRINT JOB ENTITIES—THE CREATE MODULE

To build the model, begin by opening a new model window. The first two modules to be
placed are Create modules from Arena’s Basic Process panel, which is automatically
attached. Place two Create module instances in the model; the first will generate Entity 1
jobs and the second, Entity 2 jobs.
To define the characteristics of the Entity 1 job arrivals, edit the first Create module.
Name the module Entity 1 Jobs and specify that the time between arrivals is contant
with a value of 1 minute. The second Create module instance requires similar
information. Enter a name, Entity 2 Jobs, the time between arrivals is constant,
arriving every 10 minutes. Change the Entity Type field to Entity 2 and change the

59
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

default first entity creation time from 0.0 to 10 minutes. Figures 3.27 and Figure 3.28
show the Create modules for each entity type.

Figure 3.27 Create module dialog for Entity 1 jobs

Figure 3.28 Create module dialog for Entity 2 jobs

PROCESSING THE PRINT JOBS—THE PRINTER MODULE

To use the Printer module you have defined, you need to attach a second panel—the
template panel object file you generated—to the Project Bar. Attach the panel and select
the .tpo file you named earlier (e.g., HSPrint.tpo).
Note: If the file you created does not appear in the list, you may have forgotten to generate the
.tpo file after correcting errors. Open the template window and click on the Generate toolbar
button to create a template panel object file.

60
 • • • • •
3 • MODULE-BUILDING TUTORIAL

The template panel should contain a single icon, the panel icon you drew to represent the
Printer module, as shown in Figure 3.29.

Figure 3.29 Template panel with Printer module panel icon

Place an instance of the Printer module in the model window and edit it by double-clicking
on the Printer module handle. Figure 3.30 shows the completed Printer module dialog.
In the Printer module, enter the Printer Name as HSPrinter 1. This will automatically
create a resource named HSPrinter 1 and will place it on the list of resources. It will also

3 • Module-building Tutorial
provide the information to the Seize and Release modules in the underlying logic. This
name will provide names for the queue (HSPrinter 1_Q) and variables HSPrinter1_LAST
and HSPrinter_Change.
Enter a name for the Technician field, Changeover Tech. This will also create a
resource and place it on the resource list. The Changeover Tech will be the resource
utilized in the Process module in the underlying logic for performing the changeover.
Finally, specify that the time to conduct a changeover is .2 minutes and the print time
is .5 minutes.

Figure 3.30 Printer module instance dialog

61
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

FINISHED PRINT JOBS—THE DISPOSE MODULE

The last part of the model logic is a Dispose module from the Basic Process panel. Place a
Dispose module, which will dispose of the print job entities (both Entity 1 and Entity 2
jobs).

SIMULATION PROJECT AND RUN LENGTH INFORMATION—THE RUN >

SETUP MENU
Before initiating a simulation run, select the Run > Setup option. The Project Parameters
and Replication Parameters tabs allow you to identify the project information and to
establish a run length. For the pilot run, the length of the simulation run is arbitrary, since
constant times were used for interarrival and delay times; enter a value of 8 for the
Replication Length to simulate an eight-hour workday. Change the Base Time Units field
to minutes, since the entity arrival, changeover and print times are specified in minutes.
Also, because the start of the simulation will include an extra changeover (to initialize the
printer for printing Type 1 jobs), specify a Warm-up Period of 10 minutes. By starting
the collection of statistics at time 10, the simulation run will include predictable cycles of
processing 11 entities in 10-minute cycles (i.e., 10 Entity 1 jobs and one Entity 2 job).
With a changeover time of .2 minutes, we can predict that the changeover tech will be
used 4% of the time. This is calculated by two changeovers (at .2 minutes / changeover)
every 10 minutes (one changeover to Entity 1, another to Entity 2) with a total time of .4
every 10 minutes. With a printing time of .5 minutes, we can predict that the percent of
time that the printer is actually printing should be 55% (i.e., there should be 5.5 minutes—
11*0.5—of printing for every 10 simulation minutes). Remember that the printer resource
is also busy during the changeover (or 4%), so the total Busy time (including printing and
changeover) should be 59%.

VERIFYING THE MODULE LOGIC

To test the logic for the Printer module, it is useful to step through the simulation model
for the first few events (using the Step button on the Run toolbar), just as you might do to
verify a model built using modules from other template panels.
The first event in the simulation run will be an arrival of an Entity 1 job entity. The initial
value for the variable that stores the last job type processed on the printer is 0 (the default
initial value for any general-purpose variable), so as you step through the first entity’s
processing, you should see a changeover event take place (the animation picture for the
global picture should show the Changeover Tech during the changeover) to set up the
printer to process Entity 1 jobs. After the changeover is complete, the job type variable
changes to a value of 1. The resource picture shows busy during both the changeover and
printing time, as it is not available during the changeover time. Figure 3.31 shows the
animation of the Printer module during the first changeover.

62
 • • • • •
3 • MODULE-BUILDING TUTORIAL

Figure 3.31 Animation of Printer module during first changeover

Through the rest of the simulation, you should see a cycle of changeovers to Entity 1,
processing of Entity 1 jobs, changeovers to Entity 2, processing of Entity 2 jobs, etc. At
the end of the simulation, you will be asked if you would like to view the simulation
results. The Category Overview report will be generated to show overview information on

3 • Module-building Tutorial
entities, queues, and resources. These reports may be viewed by using the arrows on the
top of the window. Additional reports can be selected in the Reports panel, including
Entities, Queues and Resources reports.
As expected, the printer resource was busy 59% of the time, which included 4% of the
time for changeovers (i.e., two changeovers of duration .2 minutes for every 10 simulation
minutes); and was idle the remaining 41% of the run. Figure 3.32 shows the first Resource
report showing the Resource Detail Summary from the simulation run.

Figure 3.32 Resources report showing Resource Detail Summary

63
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Summary
You have defined a complete simulation module, the Printer module, that captures the
logic associated with a high-speed printing area and permits a modeler to provide values
that define critical characteristics of a printing process. This module can be used in
building simulation models or, by attaching its template panel object file to the Project Bar
and using it in the logic window of another module’s definition, it may be used to create
new template panels.

64
4 The Template Window
Arena’s template development features center around designing and creating templates
consisting of modules. These modules may be used in simulation models (by placing them
in Arena model windows), or in the definition of other modules (by placing them in the
logic windows of other module definitions).

A template panel simply is a file containing a library of module definitions. The template
window, displayed by creating a new template document or opening an existing one, is a
base window from which new modules are defined. From the Template Development
toolbar, you can then access the five module definition windows—dialog design, logic,
switch, user view, and panel icon—that constitute a module.
The mechanisms used to define modules in a template panel file are described in the
chapters: Dialog Design Window, Logic Window, User View Window, Switch Window,
and Panel Icon Window. This chapter describes the options and actions that are provided
by the template window.

The template menu

Creating a new template window
The first step in building a template panel is to open a new template window by selecting
File > New from the main menu bar and selecting the Template Window option. Opening
a template window causes the Template Development toolbar to appear. A new template
window is shown in Figure 4.1.

4 • The Template Window

Figure 4.1 New template window

65
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Inside the template window are two entries: the template version and the list of modules
contained in the template panel file. The Module Definitions list is used to name new
module definitions and to identify the existing module whose module definition windows
are to be opened.

Loading an existing template panel file

To load an existing template panel file, select the File > Open menu item from the main
menu bar. Specify to list the files of type Template (*.tpl).

Closing a template
If you have finished working with a template panel file, activate the template window and
select the File > Close menu option. If you have made changes to any module definitions
in the template panel since you last saved it, you will be warned in case you first want to
save the changes. When the template window is closed, any module definition windows
that were left open also will be closed.

Saving the template panel library file

To save the .tpl file, choose File > Save from the main menu bar.

Creating and editing modules

The module definitions list
To name a new module definition, simply click the Add button, type the desired name,
and press OK. (See Figure 4.1 for a sample template window.) To rename a module at any
time, highlight the desired module name and click the Edit button. A dialog box will
appear prompting you for the new module name. Two check boxes (Required and Data
Module), a field for Name Operand, and an Expression Builder Defintions button are also
in the module definition dialog box. Please refer to “Template options” on page 71 for
more information on these items.
To delete a module from the template panel file, highlight the module and press the Delete
button. A dialog will appear asking you to confirm the deletion.
To reorder existing module definitions, use the CTRL+Up arrow and CTRL+Down
arrow keystrokes to move the highlighted module up or down in the list, respectively.
Note: The order in which modules will be displayed in a panel (when the template panel is
attached to the Project Bar) is defined by the order in which they appear in the Module Definitions
list.

66
 • • • • •
4 • THE TEMPLATE WINDOW

Opening module definition windows

Each module has five associated module definition windows: dialog design, logic, switch,
user view, and panel icon. To open one of the module definition windows, highlight the
module in the list, then choose the definition window you wish to open from the Window
menu option, or press the toolbar button for the desired window. Figure 4.2 shows the five
toolbar buttons that open module definition windows.

Figure 4.2 Template Development toolbar with Dialog Design, Logic, Switch, User View, and
Panel Icon buttons

For example, to open the logic window of a specific module, highlight the module name
and choose the Window > Logic menu option or press on the Logic Window toolbar
button from the Template Development toolbar.

Preparing the template panel for use

Checking the template panel for errors and warnings
To check the modules in a template panel for possible errors, choose the Check >
Template menu option from the main menu bar or press the Check toolbar button from
the Template Development toolbar. All errors detected in the template panel will appear
in the Error window.
The warnings and errors created by checking template panels are displayed using the same

4 • The Template Window

mechanisms as warnings and errors caused when a model is checked.
Note: The generate .tpo step (described later in this section) automatically checks the template
panel. If errors are found, the procedures described below apply whether they were discovered
during generation of a .tpo file or from a check template selection.

Whenever possible, Arena will help you locate and/or correct the error when you click the
Find and/or Edit buttons in the Error window. If you click the Find button, the module
definition window containing the object that caused the warning or error will be activated,
and the construct will be highlighted. For example, if you have referenced an operand
Order Size in a module’s logic window but did not define the operand, Arena will give an
error message to that effect, as illustrated in Figure 4.3. In this case, you can use the Find
button to open the logic window and to locate the module that referenced Order Size. The
Edit button performs the same function as Find, but in addition to locating the object, it
also opens the dialog of the object that caused the error or warning so that you may
directly correct the error.

67
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Figure 4.3 Template panel Check Error message

Note: If no errors are detected when the template panel is checked, a message to that effect is
displayed. Simply click OK to close the message box.

Reviewing errors
If you wish to review errors that have already been reported in an Error window, choose
the Check > Review Errors menu option from the main menu bar. Note that this function
only retrieves previously generated error messages; it will not recheck the template panel.
If you have made changes to the template panel since the last time it was checked, you
should recheck the template panel before reviewing errors.

Template panel file reports

Arena provides summary reports of the names and positions of objects in the dialog
design window and the definitions of switches for the module definitions in a template
panel file. (Refer to “The Dialog Design Window” and “The Switch Window” chapters
for a description of operands and switches.) These reports can aid you in designing
dialogs and in validating the definition of switches in complex modules. To view these
reports, choose the Check > Report menu option from the main menu bar. The report
dialog is opened, as shown in Figure 4.4.

Figure 4.4 Template panel Report dialog

68
 • • • • •
4 • THE TEMPLATE WINDOW

You may elect to view the operand and/or switch report; you also may show a report for
all modules in the template panel file or for a single module. The requested report(s) is
displayed in a scrollable text window. You may save the contents of the report to a text file
by selecting the File > Save menu item (that appears in the text window), or you may print
the report via the File > Print item.

OPERAND POSITIONS REPORT

The Operand Positions report contains a listing of all operands, repeat groups, and dialogs
in a table providing their display locations in the module dialog. Hidden operands are
designated with (HD) following their names, repeat groups with (RG), and dialogs with
(DB). Figure 4.5 shows a sample Operand Positions report.

4 • The Template Window

Figure 4.5 Sample Operand Positions report

OPERAND PROMPTS REPORT

The Operand Prompts report simply lists the operand names and their associated prompts.
This report should be provided to users of the template for use with the Module Data
Import > Export function.

69
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

SWITCH REPORT

The Switch report simply lists the switch names and definitions, as illustrated in Figure
4.6.

Figure 4.6 Sample Switch report

Generating the template panel object (.tpo) file

Once a template panel file has been saved and checked, you can use its modules to build a
model or to define the logic in the definition of a new module. Before this can occur, you
must generate the template panel object file, which you can attach to the Project Bar for
use in a model or logic window. To create the template panel object (or .tpo) file, choose
the Check > Generate TPO menu option from the main menu bar, or press the Generate
toolbar button. Before creating the .tpo file, this function will check the template panel file
and report any errors encountered. If there are no errors, the .tpo file will be created, and a
message to that effect will be issued.
Note: After a template panel object (.tpo) file has been generated, the .tpl file is not needed to
build models; only the .tpo file is required. If you are going to provide your template panel to
another Arena user, you simply need to distribute the .tpo file.

Other template panel information

Changing the version
The Version entry in the template window is designed to help you record updates that you
may make to the template panels you create.

70
 • • • • •
4 • THE TEMPLATE WINDOW

Template options
A number of additional characteristics of template panels may be changed using the
Template Options dialog. To open it, select the Edit > Template Options menu item from
the main menu bar. The Template Options dialog is opened, as shown in Figure 4.7.

Figure 4.7 Template Options dialog

CHANGING THE TEMPLATE DISPLAY NAME

By default, panels attached to the Project Bar display a label in the panel title bar
corresponding to the file name given to the template panel object (.tpo) file. If you wish,
you may change the name that is displayed on the panel by typing the new label in the

4 • The Template Window

Template Display Name field and choosing OK.
Note: Changing the display name does not modify the name of the .tpl/.tpo files; it simply
provides a new text string to be displayed on the top of the panel.

CREATING “PRIVATE” TEMPLATE PANELS

You may want to create a template panel that is only to be used in the creation of other
templates, not in the creation of simulation models. We refer to this type of template panel
as a “private” panel. To make a template panel private, select the Private option in the
Template Options dialog and choose OK. If you distribute a template panel containing a
module definition that attaches a private panel, note that you must provide the private
template panel’s .tpo file as well. The utlarena.tpo file that is distributed with Arena is a
private panel. It is described in “The Logic Window” chapter.

71
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

CHANGING THE DEFAULT PANEL DISPLAY

The default display of the modules in the template panel may be changed for each
template you create. You may set the default display to be Large Icons, Small Icons, or
Text only. After attaching the template panel to the Project Bar, you may change this
setting by right-clicking while hovering inside the Project Bar and then selecting the
desired option from the shortcut menu that appears. By default, small and large icons
display in two columns and text-only display in a single column. The display may be
altered by dragging the splitter bar between the Project Bar and the model window to a
different width.

CHANGING THE MODULE HELP OPTIONS

This option determines which help topic will be displayed when the user chooses the Help
button and then clicks on the module in the template panel versus editing the module and
clicking on the Help button in the module dialog. If Separate Help Items is selected, the
two actions described above will display two different help topics. This may be desirable
if you wish to give a brief description in one topic and more detailed information in the
other. If, however, Common Help Item is selected, performing either action described
above will display the same single help topic.

EXPORT SORT OPTION

The Export Sort dialog is used to define the order in which modules are written when a
Module Data Export is performed. All modules in the template are contained in the two
lists: unsorted modules and sorted modules. Initially, all modules are in the unsorted list.
To create a sorted list of modules, highlight each module in the unsorted list that you wish
to be sorted and click the Add button to move the module(s) to the sorted list. The
Remove button moves the highlighted module(s) in the sorted list back to the unsorted
list.
In the sorted list, use the Up and Down buttons to move the highlighted module up or
down.
Refer to the online help topics on the Module Data Transfer feature for more information.

Defining required modules

The Add and Edit buttons in the template window activate a dialog that is used to define
a new name for a module, as shown in Figure 4.8. It also indicates whether a module will

72
 • • • • •
4 • THE TEMPLATE WINDOW

be required in any model that uses it. If this Required check box is selected, then the
module is defined as “required.”

Figure 4.8 Module Definition dialog box

If a template panel contains a required module and if any module from the template is
placed in a model, at least one instance of the required module must also be placed in the
model. You might use this option to create a module definition that asks the user for run
parameters or that contains special logic that entities may be sent to perform by other
modules in the template.

Defining data modules

Another option in a module’s Module Definition dialog (displayed when you click the Add

4 • The Template Window

or Edit buttons from the Template window) is the ability to mark the module as a data
module. Unlike other modules (known as “logic” modules), data modules are not placed in
the model window via drag and drop. Instead, they are added only to the spreadsheet by
double-clicking the words in the spreadsheet “Double-click here to add a new row.”
Another feature of data modules is that they may be created automatically by logic
modules. For more information on the Auto-Created feature, see “Auto-Creating
modules” on page 95.

Defining a name operand

Yet another option in a module’s Module Definition dialog is the Name Operand field. If
you choose an operand from a module to be designated as the module’s Name Operand,
Arena will enforce uniqueness for the value of that operand. For example, if a module
called Process defines an operand called Process Name as its Name Operand, a user

73
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

building a model with multiple Process modules must give unique Process Names or an
error will result.)
Although it is available for both logic and data modules, the Name Operand field is
particularly useful for data modules, mainly in conjunction with the Auto-Create option of
another module. If an operand from another module auto-creates a data module, the value
of the operand is passed to the data module’s Name Operand. For example, if a data
module called Resource has a Name Operand called MyName, and another module called
Process has a ResName operand that auto-creates the Resource data module, the value of
the Process module’s ResName will be passed to the Resource module’s MyName
operand.
The operand specified in the Name Operand field must first be defined in the dialog
design window. Also, it must be visible (generally, it is displayed in the spreadsheet) and
is non-repeatable. Dialogs and Repeat groups may not be specified in this field.
Expression Builder Definitions
The Expression Builder Definitions button opens a dialog that allows you to define
expression builder strings for the module definition. The expression strings will then be
available in the Expression Builder tree-view if a module instance is placed in the model.
See the online help topics “The Expression Builder” and “Expression Builder Definitions”
for more information.

Creating copies of module definitions

The clipboard may be used to duplicate a module definition so that a variation of an
existing module can be created quickly. To copy an entire module definition, highlight the
module in the template window and click Edit > Copy or press the Copy toolbar button.
To paste the module into any template window, highlight the desired position in the
Module Definitions list and click the Edit > Paste menu option or click the Paste toolbar
button. The module will be pasted at the currently highlighted position. If a module with
the same name already exists in the template window, the new module will be renamed
with an underscore appended to the name.

Compatibility of existing module instances

If you have existing model (.doe) files or template panel (.tpl) files that contain instances
of modules from a template you are working on, you will be able to load the .doe/.tpl files
even if you make changes to the dialog design or switch windows of module definitions.
For example, if you have a template panel file, bank1.tpl, containing modules named Cus-
tomers, Tellers, ATM, and Manager and a model file, cityhq.doe, containing instances of
the Customers and Tellers modules, you will still be able to load the model file even if you

74
 • • • • •
4 • THE TEMPLATE WINDOW

change the definition of either the Customers or Tellers module (by changing the dialog
design, logic, switch, user view, or panel icon windows).
Examples of changes you may make to existing modules include: adding new operands,
removing obsolete operands, changing operand types from Element to Basic (or from any
type to any other type), changing repeatable data into non-repeatable data (by removing
the repeat group object), and many other. We make every attempt to use the data in exist-
ing operands with the new module structure. However, data in obsolete operands will be
discarded.
When you are creating a module and cycling back and forth between editing the definition
and placing the module in a simulation model (to test it), we recommend that you work
with a new model window whenever you modify the template panel file. Or, if you have
established a model window and want to retain the other modules you have placed, delete
the module instances that are from your template panel and detach the template panel
from the Project Bar using the File > Template Panel > Detach menu item or by right-
clicking on the panel tab and choosing Template Panel >Detach from the shortcut menu
that appears. Then re-attach the .tpo file after you have completed your edits to the tem-
plate panel file.

4 • The Template Window

75
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

76
5 The Dialog Design Window
An important part of a module definition is the user interface, which is the visual part that
a modeler sees when opening a module’s dialog or viewing a module’s fields in the
module spreadsheet.
The dialog design window is Arena’s interface for designing the dialog structure and
dialog form layout(s) of a module. In this window, a module designer defines dialog sizes,
data displayed to and entered by the user, default and permissible values, and interface
controls.
The first part of this chapter gives an overview of the dialog design window interface. The
second part of this chapter describes the user interface controls available to define dialog
form, operand, and repeat group objects in the module definition and get user input and
display output.
The third and fourth parts of this chapter describe topics related to operand and repeat
group objects in more detail.
The fifth and sixth parts of this chapter describe the use of accelerator keys and the Dialog
Design toolbar.

Dialog Design Window overview

The dialog design window is opened by selecting a module (in the template window’s
Module Definitions list), and then selecting the Window > Dialog Design menu item or
clicking the Dialog Design Window button on the Template Development toolbar.
The dialog design window displays the dialog form layouts for the module. Its interface
includes an Operand Explorer section to browse all of the dialog form, operand, and
repeat group objects in the module definition; a Toolbox section to add user interface
controls to dialog forms; and a Design Properties grid to edit the properties of one or more
selected objects.

5 • Dialog Design Window

77
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

The Operand Explorer

The dialog design window’s Operand Explorer (located in the top-right corner of the
window) displays the hierarchical organization of the dialog form, operand, and repeat
group objects that define the dialog structure of the module.

Figure 5.1 The Operand Explorer

The root node of the explorer tree is the module’s main dialog form. This is the dialog that
is first displayed when the modeler double-clicks on an instance of the module in a model
or logic window.
The dialog form, operand, and repeat group objects that define the structure of the
module’s interface are then displayed within the explorer tree according to the specified
hierarchical relationships. The objects are displayed using the string format TabIndex:
ObjectName [SwitchName]. The dialog or repeat group object highlighted in bold
indicates which dialog form layout is currently open in the window.
Within the explorer tree, you may select, delete, cut, copy, and paste objects. Objects may
also be dragged and dropped graphically within the tree to change the hierarchical
relationships. Double-clicking on an object in the tree will automatically open the dialog
form associated with the object and then select the object. You may also click the View
Dialog Form button ( ) to perform this action.

78
 • • • • •
5 • THE DIALOG DESIGN WINDOW

The functions of dialog form, operand, and repeat group objects are described further
below.

DIALOG FORM OBJECTS

A module definition will contain one or more dialog forms to display choices and accept
input from modelers into instances of the module.
By default, every module has a main dialog form. This is the dialog that is first displayed
when the modeler double-clicks on an instance of the module in a model or logic window.
In some cases, there may be too much information to place in a single dialog. You may
add a new secondary dialog form object to “nest” information by placing a DialogButton
control from the Toolbox onto a dialog form’s layout.

OPERAND OBJECTS

An operand object is an object in the module definition that contains a single value and (if
not disabled or hidden) is editable via a user interface control by the template user. For
example, in the Stop module of Arena’s Advanced Transfer panel, there is an operand for
the module’s Name field, and an operand for the module’s Conveyor Name field.
You can add operand objects to a module definition by placing user interface controls
such as a TextBox control or CheckBox control from the Toolbox onto a dialog form’s
layout.
Hidden operands. Note that, in some cases, it may not be desirable for a particular
operand to ever be made visible to the module’s user. The operand exists solely to store a
piece of data for internal logic purposes and thus is always “hidden” from the user. The
HiddenOperand control from the Toolbox is used to add a hidden operand object to a
module definition.

REPEAT GROUP OBJECTS

A module may allow the capability to define a list of multiple (or repeatable) fields. For
example, the Assign module from Arena’s Basic Process panel allows you to assign
values to a list of variables, attributes, etc. The Assignments list box in the Assign module
is known as a repeat group.
You add repeat group objects to a module definition by placing a RepeatGroupDialog or
RepeatGroupTable control from the Toolbox onto a dialog form’s layout. Use the
RepeatGroupDialog control if the repeating data is to be entered using a secondary dialog 5 • Dialog Design Window
form. Use the RepeatGroupTable control if values for a single repeatable field are to be
entered into a table.

79
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

The Toolbox
The dialog design window’s Toolbox (located on the left side of the window) provides an
interface for graphically adding user interface controls (e.g., text boxes, combo boxes, or
dialog buttons) and static graphics (e.g., text, lines, or group boxes) to a dialog form
layout.

Figure 5.2 The Toolbox

To add a control from the Toolbox, first click on the desired control in the Toolbox
section. Then, hover the pointer over the location in the dialog form where the control is
to be placed. The pointer will change to a cross hair with the selected control’s icon
displayed at the top and right of the cross hair.
Controls are placed in the dialog form by one of three methods. Once your control has
been selected, you can simply click on the form to place the control wherever you wish.
Alternatively, you can click and drag to size the control as you place it (the control is
placed when the button is released). The third placement method is to perform a simple
drag-and-drop directly from the Toolbox to the dialog form.

80
 • • • • •
5 • THE DIALOG DESIGN WINDOW

Table 5.1 Summary of Toolbox controls

Control Name Description
Text Used to display a simple text string on a dialog form.
GroupBox Used to draw a box around and thus provide an identifiable grouping for
other controls.
Line Used to draw simple line segments on a dialog form.
TextBox Used to get input from the user or to display text.
ComboBox Used to display and edit data in a drop-down combo box.
RadioButtonGroup Used to present a set of two or more mutually exclusive choices to the
user. The choices are presented in a matrix of buttons.
CheckBox Used to indicate whether a particular condition is enabled. Gives the
user a choice between two values such as “Yes/No,” “True/False,” or
“On/Off.”
DialogButton Used to provide a button that the user clicks to display another dialog
form.
RepeatGroupDialog Used to allow a user to enter values for multiple (or repeatable) sets of
fields via a secondary dialog.
RepeatGroupTable Used to allow a user to enter values for a single repeatable field into a
table.
DateTimePicker Used to provide an interface through which to exchange date and time
information with a user.
DatePicker Used to provide an interface through which to exchange date
information with a user.
TimePicker Used to provide an interface through which to exchange time
information with a user.
FilePicker Used to provide an interface for entering an operating system file name.
HiddenOperand Used to define an operand object that is hidden from the modeler (i.e.,
not displayed in the module dialog).

The dialog form 5 • Dialog Design Window

A dialog form is a rectangular bit of screen real estate that presents information to the user
and accepts input from the user. The user interface of a dialog form is defined by placing
controls from the dialog design window’s Toolbox onto the form’s surface.
When the dialog design window for a module definition is opened, by default the main
dialog form of the module is displayed in the center of the window. This is the dialog that

81
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

is first displayed if the modeler double-clicks on an instance of the module in a model

window.

Figure 5.3 A Dialog Form in the dialog design window

OPENING A DIALOG FORM

A module definition’s dialog design may contain more than one dialog form. For
example, in addition to the main dialog, the interface may include one or more secondary
dialogs accessed via DialogButton and/or RepeatGroupDialog controls.
To open the dialog form associated with or containing a particular object in the module
definition, double-click on that object in the Operand Explorer. Or, alternatively, you may
select an object in the Operand Explorer and use the View > Dialog Form menu item or
click the View Dialog Form button ( ).
Double-clicking on a DialogButton or RepeatGroupDialog control in a dialog form layout
will also automatically open the dialog form associated with that control.

82
 • • • • •
5 • THE DIALOG DESIGN WINDOW

RESIZING A DIALOG FORM

To resize a dialog form graphically, first click anywhere on the form to select it. Then,
click and drag one of the sizing handles that appear on the border of the form. The sizing
handles look like small black boxes, and the pointer turns into a double-headed arrow
when you point at the handle.
You may also enter specific dimension values for a dialog form by selecting the form and
then editing the Height and Width properties in the Design Properties grid.

ARRANGING CONTROLS ON A DIALOG FORM

Controls that have been placed onto a dialog form’s surface may be graphically selected,
moved, and resized.
Multiple controls may be easily layered, aligned, equally sized, or spaced using menu
commands available from the Format menu.
You may also use the View > Grid, View > Snap to Grid, and View > Snap to Objects
menu commands to enable/disable grid and snapping features that help manage control
locations on a form.

LOCKING CONTROLS ON A DIALOG FORM

When designing the user interface on a dialog form, you can lock the controls once they
are positioned correctly so that you do not inadvertently move or resize them.
Use the Format > Lock Controls menu item to lock a dialog form’s controls. Locking
controls prevents them from being dragged to a new size or location on the form’s surface.
However, you can still change the size or location of controls by means of the Design
Properties grid.

The Design Properties grid

The dialog design window’s Design Properties grid (located in the bottom right corner of
the window) provides an interface for viewing and/or editing properties of the currently
selected object(s).

5 • Dialog Design Window

83
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Figure 5.4 The Design Properties grid

At the top of the Design Properties grid is a combo box. This combo box displays a list of
all objects contained in the dialog form that is currently open in the window. The combo
box may be used to change the object selection.
The lower portion of the Design Properties section displays a textual description of the
currently selected grid property.

Using the Toolbox controls

This section describes in more detail each of the user interface controls available in the
dialog design window’s Toolbox.

Using the Text control

A Text control may be used to display a simple static text string on a dialog form. The text
cannot be edited by the user.
In the Design Properties grid, the Text property specifies the text string displayed by the
control. If the text entered exceeds the width of the control, the text wraps to the next line
and is clipped if it exceeds the control’s height.

84
 • • • • •
5 • THE DIALOG DESIGN WINDOW

Using the GroupBox control

A GroupBox control may be used to draw a box around and thus provide an identifiable
grouping for other controls. For example, you can use group box controls to subdivide a
form functionally and separate groups of option button controls.
In the Design Properties grid, the Text property defines the caption of the group box.

Using the Line control

A Line control may be used to draw simple line segments on a dialog form.
To draw a line on a dialog form, first select the Line control in the Toolbox. Then, click in
the form where you want the line to begin. Drag the cross hair to where you want the line
to end and click again.
In the Design Properties grid, the X1 and Y1 design properties set the horizontal and
vertical positions of the starting point of the line segment. The X2 and Y2 design
properties set the horizontal and vertical positions of the end point of the line segment.

Using the TextBox control

A TextBox control adds an operand object to the module definition. The control may be
used to get input from the user or to display text.
A TextBox control has two portions: a prompt label and a box. You may graphically
select, move, and resize the box and prompt label separately on the form using the mouse.
In the Design Properties grid, the Text property defines the prompt label of the text box.
The Value property specifies the default string value for the text box. The data type that
may be entered as a value is specified by the DataType property.
In general, a TextBox control is used for editable text, although you can make a text box
read-only by setting the DisplayOnly property to True.
Within the module definition, operand object values may be referenced (by enclosing the
operand object’s name in back quotes, e.g., `Operand1`) in the Value property of another
operand, in an animation object in the user view window, in a field of a module instance in
the logic window, or in a switch definition string.

Using the ComboBox control

5 • Dialog Design Window
A ComboBox control adds an operand object to the module definition. The control may be
used to display and edit data in a drop-down combo box. The control displays an edit box
with a down arrow at the right side of the box. Clicking on the arrow reveals a drop-down
list from which the user may select an item.

85
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

A ComboBox control has two portions: a prompt label and a combo box. You may
graphically select, move, and resize the prompt label and combo box separately on the
dialog form using the mouse.
In the Design Properties grid, the Text property defines the prompt label of the combo
box. The default string value for the combo box is specified in the Value property. The
data type that may be entered as a value is specified by the DataType property.
The list of items displayed and available for selection in the combo box’s drop-down list
are defined by the List property. Set the PickFromListOnly property to True if you want to
limit a user’s input to what is on the list. Otherwise, a user will be able to type choices not
on the list into the combo box’s edit field.
Within the module definition, operand object values may be referenced (by enclosing the
operand object’s name in back quotes, e.g., `Operand1`) in the Value property of another
operand, in an animation object in the user view window, in a field of a module instance in
the logic window, or in a switch definition string.

Using the RadioButtonGroup control

A RadioButtonGroup control adds an operand object to the module definition. The control
may be used to present a set of two or more mutually exclusive choices to the user. The
choices are presented in a matrix of buttons. Defining a radio button group tells the user
“Here is a set of choices from which you can select one and only one.”
In the Design Properties grid, the button options displayed for the RadioButtonGroup are
defined by the OptionList property. The Text property defines the prompt label for the
button group. The default option value for the RadioButtonGroup is specified in the Value
property.
Set the Boxed property to True if you would like a group box drawn around the prompt
label and radio buttons. The column arrangement of the radio button options may also be
customized using the NumberOfColumns and ColumnWidth properties.
Within the module definition, operand object values may be referenced (by enclosing the
operand object’s name in back quotes, e.g., `Operand1`) in the Value property of another
operand, in an animation object in the user view window, in a field of a module instance in
the logic window, or in a switch definition string.

Using the CheckBox control

A CheckBox control adds an operand object to the module definition. The control may be
used to indicate whether a particular condition is enabled. Use check boxes to give the
user a choice between two values such as “Yes/No,” “True/False,” or “On/Off.”

86
 • • • • •
5 • THE DIALOG DESIGN WINDOW

In the Design Properties grid, the Text property defines the prompt label of the check box.
The default value for the check box (“Yes” or “No”) is specified in the Value property.
Within the module definition, operand object values may be referenced (by enclosing the
operand object’s name in back quotes, e.g., `Operand1`) in the Value property of another
operand, in an animation object in the user view window, in a field of a module instance in
the logic window, or in a switch definition string.

Using the DialogButton control

A DialogButton control adds a secondary dialog form to the module definition, providing
a button that the user clicks to display the form.
In the Design Properties grid, use the Text property to specify the caption text that appears
on a dialog button.
To open the secondary dialog form associated with the DialogButton control, double-click
on the control’s dialog form object in the Operand Explorer. Or, alternatively, you may
select the object in the Operand Explorer and use the View > Dialog Form menu item or
click the View Dialog Form button ( ).
Double-clicking on a DialogButton control in a dialog form layout will also automatically
open the dialog form associated with that control.

Using the RepeatGroupDialog control

A RepeatGroupDialog control adds a repeat group object to the module definition. The
control allows a user to enter values for multiple (or repeatable) sets of fields. Each set of
the repeatable data is entered using a separate, secondary dialog form that is accessed by
selecting the repeat group’s Add or Edit buttons. A data set is deleted from the repeat
group using the Delete button.
In the Design Properties grid, use the Text property to specify the prompt label that
appears at the top of the repeat group.
To open the secondary dialog form associated with the RepeatGroupDialog control,
double-click on the control’s repeat group object in the Operand Explorer. Or,
alternatively, you may select the object in the Operand Explorer and use the View >
Dialog Form menu item or click the View Dialog Form button ( ).
Double-clicking on a RepeatGroupDialog control in a dialog form layout will also 5 • Dialog Design Window
automatically open the dialog form associated with that control.

87
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Using the RepeatGroupTable control

A RepeatGroupTable control adds a repeat group object to the module definition. The
control allows a user to enter values for a single repeatable field into a table.
In the Design Properties grid, use the Text property to specify the prompt label that
appears at the top of the repeat group.
A RepeatGroupTable control may be used only if there is to be exactly one operand field
in the control’s repeat group whose value is editable by users (referred to as the
RepeatGroupTableOperand). The repeat group may contain an unlimited number of
hidden operands.
As an example, repeat group tables are used in the Elements panel for defining Initial
Values for the Attributes and Variables modules and the Expression Values in the
Expressions module.
To view or edit the properties of operand objects contained in a RepeatGroupTable
control’s repeat group, double-click on the control’s repeat group object in the Operand
Explorer. Or alternatively, you may select the object inthe Operand Explorer and use the
View > Dialog Form menu item, or click the View Dialog Form button ( ).
Double-clicking on the RepeatGroupTable control in a dialog form layout will also
automatically open the dialog form associated with that control.

Using the DateTimePicker control

A DateTimePicker control adds an operand object to the module definition. The control
provides a simple and intuitive interface through which to exchange date and time
information with a user.
A DateTimePicker control has two portions: a prompt label and an edit box. You may
graphically select, move, and resize the prompt label and box separately on the dialog
form using the mouse.
The control’s edit box has a down arrow to the right of the box (similar to a ComboBox
control). A click on the arrow displays a calendar with the current date value circled. The
modeler has the ability to change the date portion entered into the control by selecting
either a different day within the current month or by using the calendar arrow keys to
specify a different month.
To edit the time portion of the control, simply click on the hour, minute, second, or
AM/PM text in the edit box. Then type or use the arrow keys to change a value.
In the Design Properties grid, The Text property defines the prompt label for the
DateTimePicker control. The default date and time value for the control is specified in the

88
 • • • • •
5 • THE DIALOG DESIGN WINDOW

Value property. If the Value property is not specified, then the control’s default value will
be the current date/time.
Within the module definition, operand object values may be referenced (by enclosing the
operand object’s name in back quotes, e.g., `Operand1`) in the Value property of another
operand, in an animation object in the user view window, in a field of a module instance in
the logic window, or in a switch definition string.

Using the DatePicker control

A DatePicker control adds an operand object to the module definition. The control
provides a simple and intuitive interface through which to exchange date information with
a user.
A DatePicker control has two portions: a prompt label and an edit box. You may
graphically select, move, and resize the prompt label and box separately on the dialog
form using the mouse.
The control’s edit box has a down arrow to the right of the box (similar to a ComboBox
control). If the arrow is clicked on, a calendar appears with the current date value circled.
The modeler has the ability to change the date by selecting either a different day within
the current month or by using the calendar arrow keys to specify a different month.
In the Design Properties grid, the Text property defines the prompt label of the DatePicker
control. The default date value for the control is specified in the Value property. If the
Value property is not specified, then the control’s default value will be the current date.
Within the module definition, operand object values may be referenced (by enclosing the
operand object’s name in back quotes, e.g., `Operand1`) in the Value property of another
operand, in an animation object in the user view window, in a field of a module instance in
the logic window, or in a switch definition string.

Using the TimePicker control

A TimePicker control adds an operand object to the module definition. The control
provides a simple and intuitive interface through which to exchange time information with
a user.
A TimePicker control has two portions: a prompt label and an edit box. You may
graphically select, move, and resize the prompt label and box separately on the dialog
form using the mouse. 5 • Dialog Design Window

The TimePicker control’s edit box has small up and down arrows to the right of the box.
When the current time value is selected (using a small check box to the left of the time),
the time value may be changed by highlighting the hour, minute, or second and using the
up or down arrows to the right to increase or decrease the time.

89
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

In the Design Properties grid, the Text property defines the prompt label for the
TimePicker control. The default time value for the control is specified in the Value
property. If the Value property is not specified, then the control’s default value will be the
current time.
Within the module definition, operand object values may be referenced (by enclosing the
operand object’s name in back quotes, e.g., `Operand1`) in the Value property of another
operand, in an animation object in the user view window, in a field of a module instance in
the logic window, or in a switch definition string.

Using the FilePicker control

A FilePicker control adds an operand object to the module definition. The control
provides a simple interface for entering an operating system file name.
The FilePicker control displays an edit box with a browser (…) to the right of the box.
Users may enter a valid file name or click on the browser to search for the file.
A FilePicker control has two portions: a prompt label and an edit box. You may
graphically select, move, and resize the prompt label and box separately on the dialog
form using the mouse.
In the Design Properties grid, the Text property defines the prompt label of the FilePicker
control. The default file name for the control is specified in the Value property.
Use the Filter property to specify the file filters to display in the control’s Browse for File
dialog (i.e., the choices in the Files of type drop-down list). Enter a filter string using the
format Description1|Pattern1,Description2|Pattern2, etc.
The following is an example of a filter string: "All Files|*.*,Text Files|*.txt".
You can define several filter patterns for a filter description by separating the file types
with semicolons. For example:
"Image Files(*.BMP;*.JPG;*.GIF)|*.BMP;*.JPG;*.GIF,All Files (*.*)|*.*"
Within the module definition, operand object values may be referenced (by enclosing the
operand object’s name in back quotes, e.g., `Operand1`) in the Value property of another
operand, in an animation object in the user view window, in a field of a module instance in
the logic window, or in a switch definition string.

90
 • • • • •
5 • THE DIALOG DESIGN WINDOW

Using the HiddenOperand control

A HiddenOperand control adds an operand object to the module definition. The control is
used to define an operand object that is hidden from the modeler (i.e., not displayed in the
module dialog).
A hidden operand is normally used to store data that is necessary for the module’s logic,
but which isn’t necessary, desirable, or permissible for the modeler to view.
In the Design Properties grid, the Value property of a hidden operand must be specified
(except entry and exit points); otherwise, there is no way for information to be stored in
the operand.
Within the module definition, operand object values may be referenced (by enclosing the
operand object’s name in back quotes, e.g., `Operand1`) in the Value property of another
operand, in an animation object in the user view window, in a field of a module instance in
the logic window, or in a switch definition string.

Using operands
Many of the user interface controls described in the previous section, such as the TextBox,
ComboBox, and CheckBox controls, represent operands in the module’s dialog design.
An operand is a single value that is important for module display or logic purposes.
This section describes in more detail some operand-related properties and issues.

Specifying the Name property

All operand objects have a Name property available in the Design Properties grid. This
property is a unique identifier string for the operand. The Text property that is displayed
graphically in the dialog form automatically defaults to the Name of the operand.
An operand’s name may be used (by enclosing the name in back quotes, e.g., `Operand1`)
to reference the operand’s value in the Value property of another operand, in an animation
object in the user view window, in a field of a module instance in the logic window, or in
a switch definition string.
The maximum length of a name is 31 characters, and it must be specified using
alphanumeric characters.

5 • Dialog Design Window

91
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Specifying the LogicProperties property

All operand objects have a LogicProperties property available in the Design Properties
grid. This property provides a dialog for specifying characteristics of the operand related
to its purpose in the module’s interface and logic.

Figure 5.5 The Logic Properties dialog for an operand object

In the Logic Properties dialog, the operand’s Type is specified as Basic (the default),
Element, Property, Entry Point, or Exit Point.

BASIC OPERAND

A basic operand does not serve a special purpose and is simply stored with each module
instance. Basic operands are often used to simply pass values to the logic window or the
user view window or to control the display of other operands by being used in switch
definitions.

ELEMENT OPERAND

An element operand defines or references a SIMAN element, such as a station or resource.

If the Type is specified as “Element,” then the following fields are displayed in the Logic
Properties dialog:
Element Type—The type of SIMAN element that the operand will define/reference. Select
the desired type from the list. The operand’s value will then be used as the name of the
element of the selected type (e.g., an operand with value “Operator” will define or
reference a SIMAN element with name “Operator”).

92
 • • • • •
5 • THE DIALOG DESIGN WINDOW

Sub-list—The sub-list partition of elements (by Element Type, such as resource) of which
this operand’s element is to be a member. For example, the element type Resources might
have sub-lists for Operators and Machines.
Define/Reference—Indicator whether the element that is created by this operand should
be defined for the simulation model or whether it only should be referenced. If Referenced
is selected, then some other module must define the element that is referenced by this
module. This typically is used when incomplete property information is definable in a
module.
For more information on the use of elements and their properties, see the chapter
“Elements” on page 177.

PROPERTY OPERAND

An operand may be used to represent the value of a SIMAN element’s property, such as
the capacity type of a resource.
If the Type is specified as “Property,” then the following fields are displayed in the Logic
Properties dialog:
Element Operand—Name of the operand that is defining the SIMAN element in this
module of which this property operand is associated.
Element Type—Type of SIMAN element defined/referenced by the Element Operand.
This field may not be edited; it is provided for information only.
Property Name—Name of the element property that this operand defines, selected from a
list of valid properties associated with the Element Type.
Read Only—This option is available for HiddenOperand controls only. If enabled, the
hidden operand will simply read into its value the current value of the element property
with which it is associated. The element’s property value will NOT be overwritten by the
operand’s default Value entry. The default value defined for the hidden operand will only
be written to the element’s property value if that property has yet to be defined (i.e., the
current value of the property is null).
For more information on the use of elements and their properties, see the chapter
“Elements” on page 177.

ENTRY POINT OPERAND

5 • Dialog Design Window
An entry point operand defines an entry point of entity flow into the module. When you
define an entry point operand, a graphical entry point (box shape) is placed in the
module’s user view for the operand so that the exit point of another module may be
connected to it graphically.

93
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

In most cases, a module will contain only one entry point operand. A module designer
should use caution when using multiple entry points to avoid logic errors. Repeatable
entry points are not permitted. If an operand is defined as an entry point, the operand’s
DataType property is automatically restricted to the Label data type.
The specified Entry Type should match the entry type of the module field that references
the operand from the logic window; e.g., if a queue entry label is referencing this operand,
then the Queue type should be selected.

EXIT POINT OPERAND

An exit point operand defines an exit for entity flow out of the module. When you define
an exit point operand, a graphical exit point (triangle shape) is placed in the user view
window for the operand so that it may be connected graphically to the entry point of
another module.
There may be multiple exit point operands in a module definition. For example, you may
design a module that performs an inspection-type process, in which case, two exit points
may be required, one for entities that pass inspection, and one for entities that do not pass
inspection. Exit points also may be repeatable, as can be seen in the Decide module of the
Basic Process panel. A repeatable exit point (i.e., the exit point operand is associated with
a repeat group object in the module definition) has a different graphical representation in
the user view than a single exit point, as can be seen in Figure 5.6.

Figure 5.6 Decide module with repeatable exit points

The specified Exit Type should match the exit type of the module field that references the
operand from the logic window; e.g., if a queue exit label is referencing this operand, then
the Queue type should be selected.

ENTRY/EXIT POINT VALIDATION AND REFERENCE

A graphical connection between an entry point operand and an exit point operand can be
made only if the connection is valid. Connection validation is done based on the Entry
Type and Exit Type of the operands. The most common entry and exit type used is
Standard. Refer to the Tables appendix topic “Entry/exit point types” on page 267 for

94
 • • • • •
5 • THE DIALOG DESIGN WINDOW

more information on entry and exit types and connection validation. The Tables appendix
also provides information on where various entry and exit types are used.
When a graphical connection is made between modules, Arena automatically creates and
stores unique entry and exit label information. An entry label value, usually an integer
with a dollar sign (e.g., 123$), is created for the module to which the entity is to be sent.
The module from which the entity is sent is given that same exit label value.
Entry and exit point operands may have switches attached to them. If an entry or exit point
has a switch and the operand is switched out, the operand’s field will not appear in the
module’s dialog and the graphical symbol will not appear in the module’s user view.
Entry and exit point operands may also be hidden operands (i.e., added to the module
definition using HiddenOperand controls). In this case, a field corresponding to the
operand is not visible to the modeler in the module’s dialog; however, the graphical
representation of the entry or exit point still appears, offering a way to connect graphically
into and out of the module.
Note: If an entry or exit point is defined as hidden, there is no way to reference that operand if the
module is used hierarchically.

In some of the examples in this guide, we have made the entry and exit points hidden for the
sake of the example and sample dialog box. These example modules then may not be used as
the first or last modules in a logic window, as there is no way to reference the label or next label
field.

AUTO-CREATING MODULES

The Auto-Created Module feature allows a module designer to specify that a new,
separate data module will be added automatically to the model using this operand. When
used, the operand’s value is passed to the data module’s Name Operand. Note that the
auto-creation only takes place for non-blank values of the operand.
For example, if a data module called Resource has a Name operand (specified in the
Module Definition dialog) called Name, and another module called Process has a
Resource Name operand that auto-creates the Resource data module, the value of the
Process module’s Resource Name will be passed to the Resource module’s Name
operand, as long as Resource Name is not blank.
In general, operands that use the Auto-Created feature should be defined as Element-type
5 • Dialog Design Window
operands. This ensures that the data module has at least two references in the model, as
data modules with only one reference are normally purged (i.e., deleted) from the model
(see below). Also, they should be set to use the Reference option, as opposed to the Define
option, as the data module itself should be set to use the Define option.
To use the Auto-Created feature, click the available Settings button for module auto-
creation in the Logic Properties dialog, then specify the Template Name and Module Name

95
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

of the module you wish to create from this operand value. You should avoid hard-coding
path names in the Template Name field.
Note: You must specify the Template Name, even if the module to be auto-created is in the
current template. Also, you should remember to change the Template Name and/or Module
Name fields if you later rename either.

Purging auto-created data modules. Data modules that are auto-created by other
modules are automatically deleted if the following conditions apply: 1) the module that
caused the auto-creation is deleted, 2) the module that caused the auto-creation is edited to
have a blank value for the operand that specified the auto-creation (or the operand is
switched out), or 3) the auto-created module has only one reference in the model. This
automatic deletion occurs only if the data module has not been manually edited by the
user. If any modification has occurred, the module will remain.

Specifying the Value property

All operand objects have a Value property available in the Design Properties grid. This
property specifies the initial, default value of the operand when an instance of the module
is created. Default values may be literal, may reference other operands, or may be a
combination of the two.
The acceptable data type for an operand’s value that may be entered by a user is specified
using the DataType property. The data type property is described in more detail beginning
on page 99.
It is not possible to have a blank value for an operand that has a default value specified in
the dialog design. When editing a module, if a modeler blanks out an operand that has a
default value, the default value will reappear when the user tabs out of this field.

REFERENCING THE VALUE OF ANOTHER OPERAND

The value stored in another operand object may be referenced by entering the operand’s
Name enclosed in back quote characters (`). When a modeler places and edits an instance
of a module containing referenced operands, all operand values are updated dynamically
as editing takes place.
For example, suppose that a module contains operands Server Name and Server Resource,
and the Server Resource operand’s Value property has been specified in the dialog design
as `Server Name`_RES, then any changes to the operand Server Name will be reflected in
the Server Resource field. Thus, if the value of Server Name is specified as “Fred,” the
value of Server Resource will be “Fred_RES.”
If a referenced operand is switched out, then its value is null.

96
 • • • • •
5 • THE DIALOG DESIGN WINDOW

COMBINING REPEATING OPERAND VALUES INTO A SINGLE VALUE

When designing a module, you may define a repeat group object that contains a set of
repeatable operands and then have those repeating operand values combined into a single,
merged value string. The single value will be returned if you enter the repeat group dialog
or repeat group table object name in back quote characters (`) in the Value property of an
operand.
This topic is discussed in more detail in the “Using repeat groups” section on page 102.

SPECIAL REFERENCEABLE FUNCTIONS

A set of special functions is available that will provide, in an operand’s default Value,
information such as the unique identifier of a module instance or the number of repeating
sets of data stored in a repeat group.
A special function is referenced by entering the function name enclosed in carat characters
(^). Table 5.2 summarizes the available special functions.
Note that some of the functions available may be used to access information entered into
the Project Parameters and Replication Parameters tabs of a model’s Run > Setup dialog.
Typically, this might be done in a module designed to overwrite the standard simulation
parameter defaults and reorganize the options for the end user. If a module that writes out
different values for the Project and Replicate elements is placed in a model, those values
will override any settings made in the Run > Setup dialog.

Table 5.2 Special functions

Function Description
^Module_ID( )^ Returns a unique identifier string for the module in the
form Module Definition Name [Instance Number]. For
example, “Create 5.”
^Module_Name( )^ Returns the module definition name of the module. For
example, “Create.”
^Module_Number( )^ Returns the instance number of the module in the model.
For example, “5.”
^TIME_TO_BASE_TIME(TimeValue, Converts a time value of time units into a time value of
TimeUnits)^ base time units (as specified in Run > Setup > Replication
Parameters). 5 • Dialog Design Window
^RATE_TO_BASE_RATE(RateValue, Converts a rate value of time units into a rate value of
TimeUnits)^ base time units (as specified in Run > Setup > Replication
Parameters).

97
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Table 5.2 Special functions

Function Description
^Line_Number()^ Returns the index into the repeating sets of data of the
repeat group.
^Num_Lines(Repeat Group Name)^ Returns the number of repeating sets of data in a repeat
group.
^Project_Title()^ Provides access to the title of the simulation project, as
taken from the Project Parameters page.
^Analyst_Name()^ Provides access to the analyst name for the project, as
taken from the Project Parameters page.
^Use_Costing()^ Provides access to the check box (Yes, No) for turning on
and off costing calculations for the simulation model, as
taken from the Project Parameters page.
^Use_Entities()^ Provides access to the check box (Yes, No) for turning on
and off entity attributes and statistics for the simulation
model, as taken from the Project Parameters page.
^Use_Resources()^ Provides access to the check box (Yes, No) for turning on
and off resource statistics for the simulation model, as
taken from the Project Parameters page.
^Use_Tanks()^ Provides access to the check box (Yes, No) for turning on
and off tank statistics for the simulation model, as taken
from the Project Parameters page.
^Use_Queues()^ Provides access to the check box (Yes, No) for turning on
and off queue statistics for the simulation model, as taken
from the Project Parameters page.
^Use_Transporters()^ Provides access to the check box (Yes, No) for turning on
and off transporter statistics for the simulation model, as
taken from the Project Parameters page.
^Use_Conveyors()^ Provides access to the check box (Yes, No) for turning on
and off conveyor statistics for the simulation model, as
taken from the Project Parameters page.
^Use_Processes()^ Provides access to the check box (Yes, No) for turning on
and off process statistics for the simulation model, as
taken from the Project Parameters page.
^Use_Stations()^ Provides access to the check box (Yes, No) for turning on
and off station statistics for the simulation model, as
taken from the Project Parameters page.

98
 • • • • •
5 • THE DIALOG DESIGN WINDOW

Table 5.2 Special functions

Function Description
^Use_ActivityAreas()^ Provides access to the check box (Yes, No) for turning on
and off activity area statistics for the simulation model, as
taken from the Project Parameters page.
^Number_of_Replications()^ Provides access to the number of replications for a
project, as taken from the Replication Parameters page.
^Replication_Length()^ Provides access to the length of the simulation run, as
taken from the Replication Parameters page.
^Initialize_System()^ Provides access to the check box (Yes, No) for initializing
the system between simulation replications, as taken from
the Replication Parameters page.
^Initialize_Statistics()^ Provides access to the check box (Yes, No) for initializing
the statistics between simulation replications, as taken
from the Replication Parameters page.
^StartDateTime()^ Provides access to the start date and time of the
simulation, as taken from the Replication Parameters
page.
^Warm_up_Period()^ Provides access to the length of time for the warm-up
period, as taken from the Replication Parameters page.
^Terminating_Condition()^ Provides access to the terminating condition that may end
a simulation run, as taken from the Replication
Parameters page.
^Hours_Per_Day()^ Provides access to the number of hours per simulated day,
as taken from the Replication Parameters page.
^Base_Time_Units()^ Provides access to the base time units used for the
simulation clock TNOW and all time conversions, as
taken from the Replication Parameters page.

Specifying the DataType property

All operand objects have a DataType property available in the Design Properties grid.
5 • Dialog Design Window
This property specifies the acceptable data type of the operand’s Value property.
Data types define what a user is permitted to enter for an operand value. When a user
clicks OK in a module’s dialog, the value entered for each field is checked against the
operand’s data type to determine whether the value entered is valid. If the entry isn’t valid,
an error will appear and the pointer will move to the offending operand field.

99
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Depending on the control type, an operand’s data type may or may not be changeable by
the template designer. For example, the data type of a CheckBox control is strictly
“YesOrNo.”
Module designers should ensure that their operands do not define a less restrictive data
type than the logic window fields that reference the operand. For example, if you have a
module in the logic window that only accepts real values for a particular field, then the
operand that is referenced in that field should be either a real data type or one that is more
restrictive (e.g., integer).
The available data types are now described.

STANDARD DATA TYPES

Alphanumeric—Allows any string containing alphabetic and numeric characters as well

as embedded spaces.
AnyCharacter—Allows any string of keyboard characters.
Expression—Allows any valid numeric expression. It can contain combinations of letters,
numbers, and standard arithmetic operators. An expression data type may contain both
mathematical and logical expressions.
Integer—Allows any valid non-negative integer value. Note that if a data type is specified
as Integer or Real, you may specify minimum and maximum limits for the operand.
Label—Allows any alphanumeric characters plus the special characters “@,” “_,” “%,”
and “#.” Must contain at least one special character or letter. (Should not contain only
numeric characters with single “e” or “E,” which could confuse it with a number written
in scientific notation.)
Real—Allows any positive or negative real value. Note that if a data type is specified as
Integer or Real, you may specify minimum and maximum limits for the operand.
SymbolName—Allows any alphanumeric characters plus the special characters “@,” “_,”
“%,” and “#.” Must contain at least one special character or letter. (Should not contain
only numeric characters with single “e” or “E,” which could confuse it with a number
written in scientific notation.)
Note: Symbol names may have an unlimited length, but only the first 255 characters of a symbol
name are actually considered when evaluating an expression.

YesOrNo—Allows the text strings “Yes” or “No.”

SIMAN DATA TYPES

In addition to the standard data types, Arena provides some SIMAN data types. These are
more restrictive than the standard data types, and are generally used when an operand
value can be taken from a fixed set of values.

100
 • • • • •
5 • THE DIALOG DESIGN WINDOW

For example, if you were building a module that defined a conveyor and wanted to define
the conveyor as either accumulating or non-accumulating, you could use the data type
ConvType since it is defined as having two values: Accumulating and Nonaccumulating.
For more information on available SIMAN data types, see “Data Types” on page 257.

Specifying the SwitchName property

All objects have a SwitchName property available in the Design Properties grid. This
property specifies the switch attached to the object. When the switch’s condition is
“False,” the object will be disabled or hidden in the dialog according to the
SwitchedOutAction property.
Switches are defined in the Switch window. See “The Switch Window” on page 169 for
more information on switches.
If a referenced operand is switched out, then its value is null.
A switch may also be attached to or detached from an object by using the Object >
Switch > Attach or Object > Switch > Detach menu commands.

Specifying the InUserView property

All operand objects have an InUserView property available in the Design Properties grid.
This property allows an operand value to be displayed in the module’s user view.
The InUserView property is helpful when you want the modeler to see information about
a module’s operand values without opening the module’s dialog.

Hidden operands
In some cases, it may not be desirable for a particular operand to ever be made visible to
the module user. The operand exists solely to store a piece of data for internal logic
purposes and thus is always “hidden” from the user. The HiddenOperand control from the
Toolbox may be used to add a hidden operand object to a module definition.
Entry and exit point operands can be defined using the HiddenOperand control. In this
case, there will not be a field to specify an entry or exit label in the module’s dialog.
However, a graphical representation of the connection point will still appear in the
module’s user view, allowing users to connect into or out of the module.
5 • Dialog Design Window
In the Design Properties grid, the Value property of a hidden operand must be specified
(except entry and exit points); otherwise, there is no way for information to be stored in
the operand.

101
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Using repeat groups

A module may allow the capability to define a list of multiple (or repeatable) fields. For
example, the Assign module from the Basic Process panel allows you to assign values to a
list of variables, attributes, etc. The Assignments list box in the Assign module is known
as a repeat group.
You add repeat group objects to a module definition by placing RepeatGroupDialog or
RepeatGroupTable controls from the Toolbox onto a dialog form’s layout. A
RepeatGroupDialog control is used if the repeating data is to be entered using a secondary
dialog form. A RepeatGroupTable control is used if values for a single repeatable field are
to be entered into a table.
This section describes in more detail some repeat group-related properties and issues.

Specifying the Name property

All repeat group objects have a Name property available in the Design Properties grid.
This property is a unique identifier string for the repeat group.
The maximum length of a name is 31 characters, and it must be specified using
alphanumeric characters.
A repeat group’s name is referenced when using the Num_Lines function or when
merging repeating operand values into a single value. These uses are discussed in the
“Accessing the number of tuples and the tuple number” on page 105 and “Combining
repeating operand values into a single value” on page 106.

Specifying the LogicProperties property

All repeat group objects have a LogicProperties property available in the Design
Properties grid. This property provides a dialog for specifying characteristics of the repeat
group related to its purpose in the module’s interface and logic.

102
 • • • • •
5 • THE DIALOG DESIGN WINDOW

Figure 5.7 The Logic Properties dialog for a repeat group object

In the Logic Properties dialog, the repeat group’s Type is specified as Basic or Property.

BASIC REPEAT GROUP

A basic repeat group does not serve a special purpose and functions simply as an interface
for the modeler to access a set of repeatable operands.

PROPERTY REPEAT GROUP

A repeat group may also be used to write values to a SIMAN element’s property. The
property must be a repeatable property. For example, a repeat group may be used to write
values to the Members property of a SETS element (as multiple members may be defined
within a set), but not the Capacity or Schedule property of a RESOURCES element.
If the Type is specified as “Property,” then the following fields are displayed in the Logic
Properties dialog:
Element Operand—Name of the operand that is defining the SIMAN element in this
module of which this property repeat group is associated.
Element Type—Type of SIMAN element defined/referenced by the Element Operand.
This field may not be edited; it is provided for information only. 5 • Dialog Design Window

Property Name—Name of the element property that this repeat group defines, selected
from a list of valid repeatable properties associated with the Element Type.
For more information on the use of elements and their properties, see the chapter
“Elements” on page 177.

103
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Repeat group definition depth and reference rules

When using repeat groups, it is important to make sure that fields and referenced operands
maintain the correct level of hierarchy. If no repeat groups are used in the dialog design
window or within modules in the logic window and the operands are not defined as
properties that should be within a repeat group, then there are no rules that need to be
followed.
The following restrictions apply when referencing a repeatable operand (i.e., an operand
contained in a repeat group in the dialog design) in a module field in the logic window:
1. A repeatable operand may not be referenced in a module field in the logic window if
that field is not repeatable. For example, you could not reference a repeatable operand
name in the Delay Time field of an Advanced Process Delay module in the logic
window.
2. A repeatable operand may not be referenced in a module field in the logic window if
the operand is at a deeper level of repeatability than the module field. For example, if
you had an operand object that was two levels of repeatability deep in the dialog
design, this operand could not be referenced in a module field in the logic window that
was only one level of repeatability deep.
3. Fields in the same repeat tuple in a module instance can only reference operand
objects that are connected to the same repeat group. A second tuple can refer to a
different repeatable operand.

Figure 5.8 Hospital module with two repeat groups

For example, Figure 5.8 shows two repeat group objects (Nurses and Number Needed)
with a single operand object connected to each. It would not be permitted to reference

104
 • • • • •
5 • THE DIALOG DESIGN WINDOW

both of these operands from the same repeat group tuple in a module instance in the logic
window, as is shown in Figure 5.9.

Figure 5.9 Hospital module illustrating incorrect use of repeat group referencing

Accessing the number of tuples and the tuple number

As you are building a module, you may find that you will need to know more information
about the repeat group entries that the end user entered. There are two special functions
available for accessing this information.
^Num_Lines(Repeat Group Name)^
This function returns the number of tuples or entries that a modeler has inserted into the
repeat group of name repeat group name. It may be used in the Value property of an
operand object outside of the repeat group, or in a module field in the logic window.
Note that Num_Lines cannot be used directly in a switch definition. However, it can be
entered as the default Value property of an operand object. The operand can then be
5 • Dialog Design Window
referenced in a switch definition.
^Line_Number()^
This function returns the index of the current tuple or entry in the repeat group. It may be
used in the Value property of a repeating operand object that is contained directly within a
repeat group in the module’s dialog design.

105
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

An example of where the Line_Number function has been utilized in the standard Arena
templates is in the Basic Process panel’s Assign module. In the Assignments repeat group,
the Line_Number function has been used to help provide unique default names for the
Attribute Name and Variable Name entries. For those operands, the default Value property
has been specified as “Attribute ^Line_Number()^” and “Variable ^Line_Number()^”.
Thus, default names such as “Attribute 1,” “Variable 2,” and so on, are automatically
provided to the modeler by the module’s dialog.

Combining repeating operand values into a single value

When designing a module, you may define a repeat group object that contains a set of
repeatable operands and then have those repeating operand values combined into a single,
merged value string.
The single value is returned if you enter the repeat group dialog or repeat group table
object name in back quote characters (`) in the Value property of an operand object, in an
animation object in the user view window, in a field of a module instance in the logic
window, or in a switch definition string.
For example, suppose a repeat group dialog object named “Customer Arrivals” has been
added to a “Customers” module definition. Using the Repeat Group dialog, a modeler will
specify the CustomerType and CumulativeProbabiltity.

106 Figure 5.10 Dialog design of Customers module

 • • • • •
5 • THE DIALOG DESIGN WINDOW

In the module logic in the logic window, suppose the template developer wants to have the
string DISCRETE(0,0, CumulativeProb1, CustomerType1, CumulativeProb2,
CustomerType2, …) written into the field of a module instance, where CumulativeProb1
is the first cumulative probability value specified in the repeat group, CustomerType1 is
the first customer type specified in the repeat group, etc.
In the module field in the logic window, the template developer enters the expression
string: “DISCRETE(0,0`Customer Arrivals`)”.
To place separators (i.e., commas) between the probability and value pairs of operands
and between entries of the repeat group, the template developer adds two hidden operands
named PairSeparator and TupleSeparator. Both of these hidden operands have a “,”
character entered into their Value property.
The RepeatGroupIndex property then defines an index for an object’s value with respect
to other object values contained in the same repeat group and is specifically used for
determining value order when combining a repeat group’s repeating operands into a
single, merged value string.
In this example, the operand values should be merged in the following order:
„ TupleSeparator
„ CumulativeProbability
„ PairSeparator
„ CustomerType
So the RepeatGroupIndex of the hidden TupleSeparator operand is specified as 1, the
RepeatGroupIndex of the CumulativeProbability operand is specified as 2, the
RepeatGroupIndex of the hidden PairSeparator operand is specified as 3, and the
RepeatGroupIndex of the CustomerType operand is specified as 4.
Thus, when editing the Customers module, if the modeler enters two sets of entries into
the Customer Arrivals repeat group, such as CumulativeProbability=.3, CustomerType
=1) and (CumulativeProbability=1.0, CustomerType=2), the expression string
“DISCRETE(0,0`Customer Arrivals`)” is written as “DISCRETE(0,0,.3,1,1.0,2)”.

Using repeatable modules in the logic window with repeat

groups

5 • Dialog Design Window

The repeatable module feature allows you to create a new set of logic for each entry or
tuple in a repeat group. A module repeater is placed in the logic window and must be
associated with a repeat group object within the dialog design window. Refer to the
“Repeatable modules” section on page 133 in “The Logic Window” chapter for more
detailed information.

107
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Using accelerator keys

An accelerator or access key allows a user to set focus to a control by pressing the ALT
key and typing a designated letter.
Accelerator keys may be defined in the following places:
„ In the Text property of any object. In the text string, type an ampersand character (&)
immediately in front of the letter you want to be the accelerator key (e.g., “Process
&Name” to set the “N” to be the accelerator key).
„ In the OptionList property of a RadioButtonGroup control. In the alias portion of an
option value, type an ampersand character (&) immediately in front of the letter you
want to be the accelerator key (e.g., “Option 1|Option &1”).
Note that good design practice is to identify unique accelerator keys within any single
dialog.

Dialog Design toolbar

While working in the dialog design window, you might find it useful to display and use
the controls associated with the Dialog Design toolbar. The toolbar contains controls for
formatting and viewing objects placed in the window. The controls are also available from
the View, Format, and Object menus.
To hide or display the Dialog Design toolbar, choose View > Toolbars > Dialog Design
or right-click on any visible toolbar and choose Dialog Design from the list.

108
6 The Logic Window

6 • Logic Window
Simulation logic and module design
The heart of a module is its simulation logic. Entities arriving at a module instance during
a simulation run may undergo a simple activity, such as a time delay, or a series of
complex activities, such as docking at a shipyard or completing a full surgery operation.
The designer of a module has complete control over the scope of the module logic. It is
this aspect of module design that is most challenging and often most interesting.
For example, if your modeling activities are in the area of bulk food manufacturing, you
might create a module that represents the arrival of raw materials from various sources to
your manufacturing facility. To capture the pertinent aspects of this activity, you might
need to represent the trucks that deliver the raw materials, the truck bays in the receiving
area, the forklifts that unload pallets from the trucks, and the personnel who unwrap the
palletized materials and transfer them to a storage area. One approach might be to build a
Raw Material Receiving module that captures all of these activities, from trucks arriving
at the facility to the storage of the raw material for use in manufacturing. Another
approach might separate the receiving operation into three individual modules: Truck
Arrivals, Truck Unloading, and Transfer to Storage. Or you might design modules for
each step in the process, resulting in three individual modules representing the truck
arrival process: Truck Entry, Bay Selection, and Docking.
Note that the decomposition of this activity could naturally be represented using Arena’s
hierarchy. No matter what design you select for the modules, you will need to model each
of the lowest-level activities (e.g., entry of trucks to the facility, selection of a truck bay,
docking at the truck bay). You could first create modules to represent each of these
activities, combine them into the middle-level activities (e.g., truck arrivals), and finally
build the Raw Material Receiving module from the middle-level modules.
By using this approach, a modeler using this template will have the option of using the
high-level module (Raw Material Receiving) or of representing the receiving process
using the medium- or lowest-level modules. The additional work involved in creating
modules at the three levels of decomposition primarily relates to the selection of module
operands—to build a Truck Entry module, you must decide which options will be
changeable (e.g., time between truck arrivals, truck type) by users of the module.

The logic window

A module’s logic window defines a submodel; i.e., the modeling logic and data that will be
generated when an instance of the module is placed in the window. Just as the model
window is used to define the logical representation of a model, the logic window defines
the logical representation of a module. You can think of the logic window as a model

109
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

window in almost all respects; we discuss the differences between these two windows in
the next section of this chapter.
To open a module definition’s logic window, select Window > Logic from the main menu
bar, or click the Logic Window button on the Template Development toolbar. A sample
logic window is shown in Figure 6.1.

Figure 6.1 Sample logic window for an Arriving Customers module

You interact with a logic window in the same way as you work with an Arena model
window. To define the module logic, you attach template panels to the Project Bar, select
modules, place instances of them in the logic window, connect the module instances, and
provide values to their operands.
As you read this chapter, keep in mind that module instances can be placed in simulation
models (i.e., in model windows that will be stored as Arena .doe files) or in module
definitions (i.e., in logic windows of modules that will be stored in .tpl files). For
simplicity, in most places we refer to the “modelers” placing instances of modules in
“simulation models.” However, you should remember that instances may be placed in
logic windows, as well.
The remaining sections of this chapter discuss the use of logic windows to define the
simulation logic associated with a module definition. We do not present a discussion of
the general interface for building Arena models. We assume that you are familiar with the
steps involved in building models using Arena template panels.
The next section of this chapter highlights the major differences between model windows,
which you use to build and run simulation models, and logic windows of module
definitions. Following this, we present three sections that describe the main features of

110
 • • • • •
6 • THE LOGIC WINDOW

logic windows that are specifically related to defining modules: referencing module
operands, connecting modules in the logic window, and switching module instances in the

6 • Logic Window
logic window. The next two sections of the chapter discuss topics of particular interest in
designing module logic: defining module trace and using the modules from the Arena
utility template (utlarena.tpo). We close this chapter by summarizing rules and presenting
guidelines that relate to defining module logic.

Differences between logic and model windows

Running simulation models (model window)
As we have described, the general process of defining a logic window is identical to that
of building an Arena model. Because logic windows are similar to model windows (i.e.,
both contain instances of modules), most of the editing information for working in model
windows also applies to creating and modifying logic windows. Please refer to the Arena
User’s Guide for information on attaching template panels, placing and editing modules,
connecting modules, etc.
One capability that model windows have that is not offered for logic windows is the
ability to conduct a simulation run. If you open a module’s logic window, you will notice
that the Run toolbar is not visible.
To use the logic embedded in a module definition to perform a simulation run, you must
first place an instance of the module in a model, then run the logic by simulating the
model containing the module instance. Or you can test your module logic by first defining
the logic in a model window, then using the clipboard to copy the verified logic to the
module’s logic window. In this way, you have the advantage of using Arena’s Run
Controller to interact with the module logic.

Referencing operands (logic window)

Logic windows have a number of additional capabilities that are not provided by model
windows. First, a module instance in a logic window may obtain values for its operands
by referencing operands that are defined in the module definition’s dialog design window.
For example, a module that represents the unloading activity of a truck might include an
operand defining the time to unload a pallet. This operand might be referenced by a Delay
module instance (from Arena’s Advanced Process panel or from the Blocks panel) in the
logic window to generate the appropriate time delay in the model logic. Each time an
instance of this truck unloading module is placed in a model (or in another module’s logic
window), a new value can be given to the unload time operand generating customized
simulation logic. “Referencing module data” on page 114 describes this topic.

111
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Switching module instances (logic window)

When you are working in a logic window, you may attach switches to module instances. A
switch is simply a construct that has a value of true or false, where the value of the switch
is determined by the values of module operands and/or other module switches. (Refer to
“The Switch Window” on page 169 for a description of how to define switches.)
In the logic window, switches are used to control alternatives for the model logic to be
used when the modeler changes operand values. For example, in a module depicting a
metal stamping machine, you might want to offer the option of counting the number of
times that jams occur. If the modeler indicates that the count should be taken, a Count
module from the Blocks panel would be “switched in” at the appropriate place in the
module’s logic. However, if no count is to be taken, the Count module should not be
included in that particular instance of the stamping machine module (i.e., it is “switched
out”). This is described further in “Switches in logic window module instances” on
page 121.

Defining repeatable logic

Template logic windows have a special object called a Module Repeater that can be
placed in the logic window and used to define modules that should repeat for each item in
a dialog design window repeat group object. The Module Repeater is placed by selecting
it from the Module menu. For more information on the use of this feature, refer to
“Repeatable modules” on page 133.

Module connections in the logic window

The logic window allows two additional methods for connecting modules that are not
permitted in model windows. First, an exit point in the logic window may be connected to
multiple entry points, which is disallowed in the model window. This is permitted in the
logic window to allow switches to select from among alternate logic paths in a module
instance.
Second, the connection of a repeating exit point may be “duplicated” when the module is
used in a model. This allows all of the repeated conditions defined by the modeler to send
entities to the same logic automatically.
These two connection topics are discussed and illustrated in “Module connections” on
page 142.

Attaching template panels while working in a logic window

While within the logic window of a module definition in a given template (i.e., .tpl file),
you may not place any modules that are defined in the current template. For example, if
you are working on a template panel file named foodline.tpl, you may not place any

112
 • • • • •
6 • THE LOGIC WINDOW

modules from foodline.tpo into the logic window of any other module defined in
foodline.tpo.

6 • Logic Window
Related to this, you may not attach a template to itself indirectly by attaching a .tpo file
that itself has the template you are editing attached to the Project Bar. For example, you
might have a template named truckops.tpl representing the truck arrival operations
described previously. If this template contained module instances from foodline.tpo in any
of its module definition logic windows, it would not be permitted to use modules from
truckops.tpo while defining modules in the foodline.tpl template.
If you have a set of modules that form a hierarchy (such as the three levels of modules
described previously related to the raw materials receiving operation), they must be
grouped in separate template files since a particular template can’t contain instances of
modules that are defined in the same template.

Display of animation objects (logic window)

When you place a module in a logic window, a complete instance is formed, just as would
occur if you placed the module in a model window. However, because a logic window
cannot be simulated directly, there is no need for animation in the window. So, Arena’s
logic window, by default, does not display the animation objects that are part of a module
instance.
If you place a module instance in the logic window that contains animation objects in its
user view, these animation objects are placed in the logic window; they simply are not
displayed by default. If you want to view the animation objects, you can use the View >
Layers menu item to turn on the display of the various animation object types (e.g.,
levels, resources). In the logic window, we retain the animation objects that are part of
module instance user views so that a module that is transferred between a model window
and a logic window (via the clipboard) remains complete.

“Fields” and “operands”

In this chapter, we discuss instances of modules in two contexts: the placement of module
instances in a logic window (i.e., to create the logic for a module definition) and the use of
the module that we defined (i.e., the creation of an instance of it in a model or another
module’s logic window). We also have two contexts for the term operand: the item that is
presented in the dialog of a module instance in the logic window and the operand defined
by an object placed in the dialog design window of a module definition.
To remove confusion in this chapter about the term “operand,” we have chosen to use a
different term, “field,” for the first context. So in this chapter, we refer to the items that
appear in a module instance’s dialog as fields. We retain the term operand in its context as
the object that is part of a module definition.

113
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Referencing module data

Referencing operands
The logic window defines the logic that will take place (controlling the creation, flow, and
disposal of entities) when a simulation run is performed by a model containing an instance
of the module. This logic may be very simple or highly complex. When a module is
placed, the number and types of options provided to a user are defined by the dialog(s)
containing the module’s operands.
The tie between the dialog design window and the logic window is established inside the
logic window. In each module instance in the logic window, the values of operands from
dialog(s) of the module being designed may be used in place of specific values. To
establish this link, you simply type the name of the operand that you want to use and
enclose the name between back quote characters (`). We refer to this as referencing an
operand.
Note: Operand names are not case-sensitive. Embedded spaces are permitted.

Operand references also are allowed in the Value property of an operand definition and to
define certain data for animation objects. “The Dialog Design Window” and “The User
View Window” chapters describe the locations in which operand references can take place
for operand default values and animation objects, respectively.
An operand reference dictates that when an instance of the module is created, the actual
value of the field containing the reference is to be obtained from the modeler’s entry in the
module’s dialog. Your selection of a module’s operands and the references to these
operands in the logic window dictate the flexibility provided to a modeler for customizing
the data and behavior of the module as it is used to represent different circumstances.
To illustrate a simple module reference, consider an Order Entry module that contains an
instance of a Create module (from the SIMAN Blocks panel). In this module, you might
want to ask the modeler to define the batch size of the order and the interarrival time for
the orders to enter the system. To do so, you could define two operands in the dialog
design window: Time Between Orders and Order Size. In the Create module instance that
you place in the module definition’s logic window, you would reference the Time
Between Orders operand to obtain the interval for the Create module and the Order Size
operand to obtain the batch size, as depicted in Figure 6.2.
Each time a modeler places an instance of the Order Entry module, new values can be
provided for the Time Between Orders and Order Size operands. For example, one
instance of the Order Entry module might specify a Time Between Orders operand value
of UNIF(5,10) and an Order Size of 10. In the underlying logic, these values would pass

114
 • • • • •
6 • THE LOGIC WINDOW

to the Create module so that the Interval field in the Create module would have a value of
UNIF(5,10) and the Batch Size field would have a value of 10.

6 • Logic Window
Note: If a module containing operand references is pasted into a model (.doe) window, the fields
containing references are restored to their default values.

Figure 6.2 Operand references example

CONCATENATING TEXT TO OPERAND REFERENCES

When referencing an operand, you also may type text before or after the reference. For
example, you may have another module in your template called Order Verification, where
a delay occurs to check orders. In this module, you might want to design the interface
such that a modeler enters the percentage of incomplete orders (i.e., a value in the range 0
to 100) into an operand called Percent Incomplete. If this value is to be used in the
condition of a Branch module (from the Blocks panel), which requires a probability value
(i.e., in the range 0.0 to 1.0), you would need to divide the entry of the modeler by 100. To

115
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

do so, you can combine the operand reference (`Percent Incomplete`) with text (/100), as
shown in Figure 6.3.

Figure 6.3 Concatenating operand references and text

In this case, the value entered by the modeler for the percentage of incomplete orders will
have the text /100 appended before the information is passed to the logic that defines the
Branch module. For example, if a modeler entered a value of 14 for the percentage field in
an instance of the Order Verification module, the actual information supplied to the
Branch module would be 14/100 (through the Order Verification module definition’s logic
window).

COMBINING MULTIPLE OPERAND REFERENCES IN A SINGLE FIELD

Multiple operands may be referenced in the same field of a module instance in the logic
window. In this case, the values of the operands are simply concatenated to form the
complete value for the logic window’s module instance. Also, text may be interspersed
with operand references (as described previously).
For example, in the original module, Order Entry, you might decide to use a uniform
distribution for the interarrival time of orders and simply ask the modeler for the
minimum time and the maximum time. In this case, the Time Between Orders operand

116
 • • • • •
6 • THE LOGIC WINDOW

would be removed from the module. In its place, you could define two operands for your
module: Min and Max. To reference these operands, you would change the operand

6 • Logic Window
reference in the Create module (Interval field) to be UNIF(`Min`,`Max`), as shown in
Figure 6.4.

Figure 6.4 Referencing multiple operands

In an instance of this Order Entry module, the modeler’s entries for the minimum time and
maximum time replace the operand references (`Min` and `Max`, respectively) in the
Create module.
Another case in which it is useful to reference multiple operands in a single field of a
module is when a set of operands is provided to the user, but these operands are controlled
by switches such that only one operand will be switched in for any given set of user
inputs. (Refer to the chapter “The Dialog Design Window” for a description of attaching
switches to operands. See “The Switch Window” for a discussion of switches and their
definitions.) To define the logic window field for this type of reference, simply type each
operand name enclosed in back quotes, one after the other.
In the Order Verification example module, perhaps you would like to design the module to
offer the modeler a choice of specifying the time to check the order as either the name of
an attribute that stores the time or as a particular time. This information will be used in a

117
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Delay module (from the Blocks panel). The module’s dialog might contain a selection for
the Time to Check with options of Time or Attribute. If the modeler selects Time, an
operand named Time is displayed; if the modeler selects Attribute, an Attribute is
displayed.
Figure 6.5 shows the dialog for an instance of the Order Verification module with the
Time to Check selected to be Time. Figure 6.6 shows the same dialog with Attribute
selected.

Figure 6.5 Order Verification module example, Time selection

Figure 6.6 Order Verification module example, Attribute selection

In Figure 6.5, the Time operand is displayed so that the modeler can define the time as a
value (e.g., 2.5). The dialog in Figure 6.6 allows the modeler to define the time to check
an order by selecting (from a drop-down list of attributes) an attribute that stores the
value.
In the logic window for the Order Verification module definition, the Process Time field
of the Delay module would be defined as `Time``Attribute` (with no intervening
spaces). The switched-in operand would supply its value to the Delay module; the

118
 • • • • •
6 • THE LOGIC WINDOW

switched-out operand would have no value (i.e., blank). The dialog for the Delay module
instance in the logic window is shown in Figure 6.7.

6 • Logic Window
Figure 6.7 Combining operand references example

MULTIPLE REFERENCES TO AN OPERAND

When you define a module, you can reference the same operand as many times as is
appropriate. As we mentioned earlier, operand references may be made in three places in a
module definition: in the Value property of an operand object in the dialog design
window, in the logic window (as described in this chapter), and in animation objects in the
module’s user view. The same operand may be referenced from all three windows and/or
from multiple objects within a window.
For example, if a resource is required to perform the order verification process, an
operand Clerk Name would be added to the module. This would provide the name of the
resource in a Process module. (We will discuss adding the Clerk Name to the Process
module in “Referencing non-repeating operands from a repeat group” on page 125.) If a
count is collected in the Order Verification module to record the number of incomplete
orders each clerk detects, the Clerk Name operand in the module might be referenced in
many places. The default value of another module operand that defines the counter name
might reference the Clerk Name to form the base of the counter name (e.g., `Clerk
Name`_Cnt). The Process module instance in the logic window contains the reference to

119
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Clerk Name to define the resource. And in the user view, a resource animation object
could reference Clerk Name for the resource identifier.

Special access for check boxes, radio button groups, and

combo boxes
While all references to module operands are made by enclosing the operand name in back
quotes, a special mechanism is necessary for creating these references in the logic window
when the field is displayed using a RadioButtonGroup or CheckBox control. (Refer to
“The Dialog Design Window” or information about these control types.) CheckBox and
RadioButtonGroup controls do not allow direct typing of values in a module instance’s
dialog. Instead, a value is provided by selecting one of a predefined set of values. In the
case of radio buttons, this is done by selecting a value; in the case of check boxes, the
value is defined by checking the box for a value of Yes or clearing the box for a value of
No.
To reference operands in these fields, Arena provides a special operand reference dialog.
To open this dialog when you are editing a module instance in the logic window, place the
pointer over any of the values in a RadioButtonGroup control or over a CheckBox prompt
and click the right mouse button. The dialog that is opened allows you to type the operand
reference for the radio button group/check box using any of the mechanisms described in
this chapter.
Figure 6.8 shows an instance of a Dispose module from the Basic Process panel. The
check box determines whether the entity statistics are generated. The dialog shown was
opened by right-clicking on the Record Entity Statistics CheckBox control. A new module
with an operand named Entity Statistics will provide the value of Yes or No to the Record
module check box.

Figure 6.8 Operand reference for RadioButtonGroup and CheckBox controls

120
 • • • • •
6 • THE LOGIC WINDOW

Note: After you have established a reference for a radio button group or check box field, if you
later click on one of the options of a radio button group or on the check box, the reference

6 • Logic Window
information is removed and the radio button group/check box is given the value you selected.

Note: To allow template developers to reference an operand in a ComboBox control, the

PickFromListOnly property for combo boxes is ignored in the logic window.

Switches in logic window module instances

As you make changes to the values of fields in a module instance’s dialog in the logic
window, some of the fields might control the display of other fields. For example, in an
instance of a Record module (from the Basic Process panel), if you change the type from
Count to Time Interval, the value and counter name fields are switched out and the
attribute name and tally name fields are switched in.
If you define an operand reference in the field that controls the display of other fields, all
fields that depend upon that value will be switched in. This is because the actual value of
the controlling field (e.g., the Type field) will not be known until the module in which it is
contained is placed in a model and a value is provided to the operand that is referenced.
In the case of the Record module example, this results in all of the operands that are
controlled by the Type value being switched in and overlapping, as shown in Figure 6.9.

Figure 6.9 Record module instance dialog with reference in Type field

Note: We recommend that you establish the values of any fields that might be switched out
before providing a value to the field controlling their display.

Defining transfer of entities into and out of a module

In Arena, entities are transferred among modules in one of two ways: using a route,
transport, or convey between stations (referred to as station transfer); or using a direct
labeled connection (referred to as direct transfer). A module may offer one or both of

121
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

these mechanisms for receiving entities into the module; modules may define only one of
the two mechanisms for any particular place that sends entities out of the module.

STATION TRANSFER

If you want to allow entities to be transferred into your module by a station transfer (i.e.,
route, transport, or convey to a named station), the module’s logic window must contain a
module instance that defines a station, such as the Station module from the Blocks panel.
For example, in the Order Verification module discussed previously, we might want to
design the module to allow entities to be routed to an order verification desk, which is
represented in our module as a station. In the logic window, we could add a Station
module prior to the Process module and reference a new operand, Order Desk, to establish
the name of the station, as shown in Figure 6.10.

Figure 6.10 Station module instance in Order Verification module

Any entities sent to an instance of the Order Verification module by station transfer would
enter at the Station module instance (in the underlying logic) and then proceed to the
Process module.
To specify that entities should be transferred out of your module by a transfer module,
simply place a module instance that permits station transfer (e.g., a Leave or Route
module from the Advanced Transfer panel or Route from the Blocks panel) and reference
the appropriate operands of your module. When a modeler uses an instance of your
module, entities will proceed through the logic you have defined in the logic window.

122
 • • • • •
6 • THE LOGIC WINDOW

When an entity arrives at a module in the logic that has a station transfer, the entity will be
sent to the module instance in the simulation model that defines the destination station.

6 • Logic Window
DIRECT TRANSFERS

In the case of direct transfers, special operand types are used to allow graphical
connection of modules to depict the flow of entities through the model. The mechanism
for defining these entry point and exit point operand types is described in “The Dialog
Design Window” chapter. When an operand is defined to be an entry point or exit point
operand, a symbol is placed in the module’s user view to allow modelers to connect
modules together. The operand also can be displayed in the module dialog (often with a
prompt of Label for entry points or Next Label for exit points).
In the logic window, you identify the module instance that corresponds to an entry point
of your module by placing an operand reference in the appropriate field of the instance.
For example, if you wanted to permit either direct transfer or station transfer into the
Order Verification module, you could define a new entry point type of operand called
Desk Label. In the logic window, this operand would be referenced by the Label field
within the instance of the Station module (from Blocks panel), as shown in Figure 6.11.

Figure 6.11 Reference to entry point operand in logic window module instance

Note in the dialog in Figure 6.11 that both methods of transfer into the Order Verification
are allowed: station transfer and direct transfer. A modeler using an instance of the Order
Verification module has the choice of transferring entities by routing to the station defined

123
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

by the Order Desk operand and/or connecting other module exit points to the entry point
defined by the Desk Label operand.
Note: We recommend that if you have entry and/or exit point operands in a module, you always
display the operands in the module dialog (i.e., do not make them hidden). If you define the entry
or exit point operand to be hidden, it is not possible for an instance of the module to reference
entry point or exit point operands if it is used in the logic window of another module’s definition.

If you utilize the Arena template in the logic window of a module (Basic Process,
Advanced Process, and Advanced Transfer panels), the direct transfer method of entering
into a module is more complicated. The reason for this is that the label/next label fields in
all of these modules are hidden from the user (not available for operand values to
reference), even though the entry/exit points are graphically visible. (Please refer to the
chapter “The Dialog Design Window” on entry/exit points for more information.) In order
for entities to actually enter the module using a label reference, a module with a label
(from the Blocks panel) must be the first module into the model logic.
Typically, the Delay module from Blocks can be used with a duration value of 0.0, as
shown in Figure 6.12.

6.12 Module logic with delay: 0.0 module to access ‘Desk Label‘ entry point label

124
 • • • • •
6 • THE LOGIC WINDOW

Referencing non-repeating operands from a repeat group

6 • Logic Window
The operand references that are made by module instances in a logic window may be
made from within a repeating set of fields; this is treated identically to references from
non-repeating fields. (Refer to the chapter “The Dialog Design Window” beginning on
page 77 for a discussion of repeat groups and related topics.)
We have briefly discussed adding a resource to the Order Verification module and
utilizing the Process module from the Basic Process panel. The Clerk Name operand
(non-repeating) will be utilized within a resource repeat group.
This example will simply create one repeat group tuple with the value entered by the user
for the name of the clerk resource. The resulting logic would have entities waiting to seize
a single capacity unit of the resource defined by the operand Clerk Name (see Figure
6.13).

Figure 6.13 Operand reference from within repeat group

125
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Non-repeating operands may be referenced from multiple tuples of a single repeat group,
as well. For example, you might want to extend the Order Verification module to seize a
supervisor when an entity is identified as an incomplete order and may also require a
worker who is responsible for finding the missing items to come with the supervisor and
pick up the incomplete order. In this case, you might want to ask the modeler for the
names of the supervisor and worker by providing additional module operands, Supervisor
and Worker Name. By referencing each of these operands in another Process module,
your logic is such that entities require both the supervisor and worker resources before
they can continue processing. This logic is defined by adding the operand references in a
Process module to contain two repeat group tuples, the first tuple seizes the resource
defined by the Supervisor operand, and the second tuple seizes the resource defined by the
Worker Name operand. This Process module is shown in Figure 6.14.

Figure 6.14 Multiple repeat group tuples with operand references

126
 • • • • •
6 • THE LOGIC WINDOW

Referencing repeating operands

6 • Logic Window
Thus far, we have discussed how to reference non-repeating operands from module
instances in a logic window. It also is possible to reference repeating operands (i.e.,
operands that have been defined as members of a repeat group in the module’s dialog
design window) from logic window modules. To reference a repeating operand, you
enclose the name of the operand in back quotes, just as is done when referencing non-
repeating operands.
To illustrate this, let’s consider our original Order Entry module. This module will be
expanded to assign initial values to entity attributes and send the entities to the first
activity involved in processing the order.
The dialog for the Order Entry module might be designed as shown in Figure 6.15. This
dialog contains:
„ an operand for the Time Between Orders,
„ an operand for the Order Size,
„ an Attribute Assignments repeat group (with a tuple opened in the figure to show its
operands) containing an Order Attribute operand defining the attribute to be assigned
and a Value operand specifying the assignment value, and
„ a Next Activity operand that determines the activity to which the entity will be sent.

Figure 6.15 Order Entry module dialog

127
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

To define the logic for this module, the Create, Assign, and Route modules from the
Blocks panel can be used. In the Create module instance, the Batch Size and Interval
fields reference the Order Size and Time Between Orders operands, respectively, as seen
originally in Figure 6.2. Similarly, the Destination field in the Route module references
the Next Activity operand of the Order Entry module. These two references are of the type
described previously, where a non-repeating field in a module instance contains a
reference to a non-repeating module operand.
So that modelers using the Order Entry module can define as many attribute assignments
as they would like, the Assign module instance in the logic window must accept all of the
values of the Order Attribute and Value operands that are defined in each instance of the
Order Entry module. To establish this tie between the repeat group in the Assign module
instance and the repeating operands in the Order Entry module, you insert a single repeat
group tuple in the Assign module and reference the Arriving Orders module operands, as
shown in Figure 6.16.

Figure 6.16 Reference from repeat group fields to repeating operands

128
 • • • • •
6 • THE LOGIC WINDOW

Each time a modeler inserts a new repeat group tuple in an instance of the Order Entry
module, a corresponding tuple is inserted in the Assign module instance in the logic

6 • Logic Window
window. Similarly, as a modeler edits the data (e.g., deleting tuples or changing values),
the edits are reflected in the Assign module instance.

MULTIPLE REFERENCES TO REPEATING OPERAND

An extension of this use of repeating operands is to use a single repeating operand in

multiple references within a logic window. In this case, each reference will create a new
tuple in the logic window corresponding to each tuple that the modeler defines.
To illustrate this concept, let’s return to the Order Verification module discussed
previously. In this module, you might want to allow the incomplete order entities to seize
an arbitrary number of operators (rather than two specific resources, as was designed in
Figure 6.14) and to assign a new state to each operator resource after it is seized.
The new Order Verification module contains a repeat group with operands named
Operator Name and New State. In the logic window, an instance of a Seize module is used
to define the logic for seizing the required resources. The operand reference in the Seize
module instance is shown in Figure 6.17.

Figure 6.17 Seize module instance with references

129
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

To assign new state values to the resources after they are seized, an Assign module
instance is placed in the logic window. In the Assign module, since a pair of repeating
operands is to be referenced, the same technique is used to create the operand references.
A single tuple is inserted, and the two module operands (Operator Name and New State)
are referenced, as shown in Figure 6.18.

Figure 6.18 Assign module instance with references

A modeler using an instance of this Order Verification module might insert one tuple with
values Line A Refill Operator and Filling Incomplete Order for the resource and state
operands; a second tuple might have operand values Line A Supervisor and Checking
Order Problem. The resulting contents of the logic window would contain two repeat
group tuples in the Seize module instance (since the Order Verification module has two
tuples), with the names of the two resources filling the Resource fields. Similarly, because
the Assign module in the logic window contains references to repeating operands, two
assignment tuples would be created with the pairs of values for the resource and state to
be assigned.
One limitation is placed on references to repeating operands. If you are referencing a
repeating operand from within a repeating field in a module instance, you cannot
reference a repeating operand that belongs to a different repeat group. This rule applies
both to the particular field containing the reference and to other fields in the same repeat
group of the module instance.

130
 • • • • •
6 • THE LOGIC WINDOW

For example, in the Assign module instance shown in Figure 6.18, the operand references
would be invalid if the Resource Name and New State operands belonged to different

6 • Logic Window
repeat groups in the module definition.

COMBINING REFERENCES TO REPEATING AND NON-REPEATING OPERANDS

It is possible to combine references in a repeat group such that some of the fields obtain
their values from repeating operands and some reference non-repeating operands. In this
case, the repeating operands define how many tuples are to be created in the logic window
module instance’s repeat group, and the value of the non-repeating operand is included in
each tuple.
For example, if you want to modify the Order Verification module to seize an arbitrary
number of resources, but you want to assign all of the resources the same new state value,
you would use the same logic window as described previously (Seize and Assign with the
same operand references). However, the Order Verification module would contain a
repeat group with just the Operator Name operand. The New State operand would be non-
repeating (i.e., in the module’s main dialog).
A modeler using an instance of this Order Verification module might define that two
resources are required (Line A Refill Operator and Line A Supervisor), and might provide
a value of Checking Incomplete Order for the new state field. In the logic window, two
repeat group tuples would be created in each of the Seize and Assign module instances
(because both reference the repeating Operator Name operand). In the Assign module
instance, the state value, Checking Incomplete Order, would be placed in both assignment
tuples.

Defining repeatable exit points in a module

Modules built in Arena often contain one or more entry point or exit point operands that
allow modelers to define direct connections into or out of the module (as opposed to
station transfers, which are defined by specifying a station name to define a station for
routing, transporting, or conveying to a station destination). Some modules allow an
indefinite number of exits, such as the Branch module from the Blocks panel, which
permits one or more entities to leave based on conditions defined by the modeler. If a
module that you place in your logic window has a repeating exit point, you may define a
repeating exit point to your module as well, such that the modeler using your module may
select as many alternatives as are desired for controlling entity flow out of your module.
To define a repeatable exit point, the same approach is used as is provided for defining
repeating basic operands. In the dialog design window, place a TextBox type of operand
within a repeat group dialog form. Change the LogicProperties property of the operand to
be an exit point operand and connect it to a repeat group. In the logic window, you
reference this operand in a repeating field, such as the Send to Label field of the Branch
Types repeat group in the Branch module. Defining a repeating exit point in the dialog

131
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

design window causes a repeatable exit point object to be placed in the user view for your
module, as shown in Figure 6.19.

Figure 6.19 Repeating exit point

For example, if you were creating a Sort Orders module representing an order-sorting
process, you might want to place a Process module in your logic window to represent the
process of examining the order to determine to which filling line it should be sent, then a
Branch module that dispatches orders based on conditions defined by the modeler. The
operand definitions for your module might include operands for the Sorter Name and Sort
Time, as well as a repeating set of operands defining the conditions dictating the selection
of sortation lines—Condition Type (a radio button group with options of If and Else),
Condition, and the Sort Line Label exit point operand. Figure 6.20 shows a sample dialog
containing these operands.

Figure 6.20 Sort Orders module dialog

132
 • • • • •
6 • THE LOGIC WINDOW

In the logic window, the Process module references the Sorter Name and Sort Time
operands. The Branch module’s Branch Types repeat group references the three repeating

6 • Logic Window
operands of the sortation line module—Condition Type (referenced by clicking the right
mouse button on the If/With/Else/Always radio button group field), Condition, and Sort
Line Label. This Branch module dialog is shown in Figure 6.21. Each time a modeler
defines a new tuple in an instance of the Sort Orders module, a new tuple is created in the
underlying Branch module and a new exit point is created both in the Sort Orders module
instance and in the underlying Branch module.

Figure 6.21 Branch module referencing repeating operands including exit point operand

Repeatable modules
The repeatable module feature allows you to create a new set of logic for each entry or
tuple in a repeat group. The interface and basic procedure is described as follows. In the
logic window of a module, place a new box-shaped object (the module repeater) and
associate it with a repeat group object in the dialog design window. Place any modules
that you wish to be repeating inside the module repeater. Connect the module repeater to
other logic as you would any other module.

133
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

To place a module repeater, open the module’s logic window and choose the Object >
Module Repeater menu option. Move the cross-hair pointer into the logic window and
click once to place a corner of the box. Move the pointer and click again to place the
opposite corner of the box.
Once placed, the module repeater has connection points on both the inside and the outside
of the box. The outside connection points are used to connect the box to non-repeatable
logic external to the box, while the inside connection points are used to connect the
repeatable modules inside the box to the module repeater itself.
To use the module repeater, place the modules that you wish to be repeating inside the
box. The box can be resized to allow for adequate space. Connect any modules you place
inside the box just as you would if they were outside the box. Make sure that at least one
of the group of modules inside the box is connected to a connection point inside the box.
Note: If you have trouble connecting modules either to or from the module repeater, go to the
View > Snap menu and turn off the Snap option.

To associate the module repeater with a repeat group in the dialog design window, double-
click on an edge of the module repeater to open the Module Repeater Settings dialog
(shown in Figure 6.22.) Type the name of the associated repeat group or choose it from the
list at the Repeat Group Name prompt.
Next choose the type of repeating logic. There are two basic types: logic that repeats in
parallel, or logic that repeats serially.
Parallel repeating logic specifies that each repeat of the logic is independent and
represents a different logical path. If you wish to define the repeating logic in parallel, you
must connect a repeatable exit point of a module (such as Branch or Duplicate) to the
entry point of the module repeater. Example 1 shows how to define parallel repeating
logic.
Serially repeating logic specifies that each repeat of the logic is connected, one after the
other, in the same logical path. Example 2 shows how to define serially repeating logic.
Finally, choose the Number of Alternate Outputs required. This option is used to provide
additional logic paths out of the module repeater. For example, if a module inside the
module repeater has more than one exit point, you may wish to connect one exit point to
the main logical path that exits the module repeater and another exit point to an alternate
exit point of the module repeater. Example 3 shows how you might use the Number of
Alternate Outputs field.
For the purpose of the next three examples, hidden entry and exit points have been used in
the incoming and outgoing modules so that the module can be connected to other modules
in a model window. Please refer to “The Dialog Design Window” chapter for more
information on entry/exit points and hidden operands. It is typically not recommended
that entry/exit points be hidden, as there is no way to reference them in a hierarchical
module.

134
 • • • • •
6 • THE LOGIC WINDOW

Example 1: Parallel logic

6 • Logic Window
Figure 6.22 shows the logic window with a module repeater connected to a repeatable exit
point of a Branch module (Blocks panel).

Figure 6.22 Logic window with module repeater

The dialog design window’s Operand Explorer in Figure 6.23 reflects the Repeat group
Route Times with operands Type and Route Time.

Figure 6.23 Operand Explorer in the dialog design window with repeat group route times

135
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Figure 6.24 shows the Sample dialog with entry of three different types and route times.

Figure 6.24 Sample dialog with types and route times

The resulting model code is shown in Figure 6.25. Note that the Assign module is
repeated once for each tuple in the Route Times repeat group.

Figure 6.25 Model code

136
 • • • • •
6 • THE LOGIC WINDOW

Example 2: Serial logic

6 • Logic Window
Figure 6.26 shows the serial logic window module repeater with an Assign and Delay
block inside.

Figure 6.26 Logic window with module repeater

In Figure 6.27, the dialog design window’s Operand Explorer reflects repeat group
processes with operands Process Time and Associated State.

Figure 6.27 Operand Explorer in dialog design window with repeat group processes

137
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

The sample dialog in Figure 6.28 shows the entry of three different Process Times and
Associated States.

Figure 6.28 Sample dialog with different Process Times and Associated States

The resulting model code is shown in Figure 6.29. Note that the Assign and Delay blocks
repeat once for each tuple in the repeat group.

Figure 6.29 Model code

138
 • • • • •
6 • THE LOGIC WINDOW

Example 3: Defining alternate outputs

6 • Logic Window
In Figure 6.30, the logic window shows module repeater with Duplicate block inside.
Note that the Number of Alternate Outputs is 1 and an additional connection appears
along the bottom of the module repeater.

Figure 6.30 Logic window with module repeater

The dialog design window’s Operand Explorer in Figure 6.31 shows the repeat group
Types and Quantities with operands Type and Quantity.

Figure 6.31 Operand Explorer in dialog design window with repeat group Types and Quantities

139
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Figure 6.32 shows the sample dialog with entry of two different Types and Quantities.

Figure 6.32 Sample dialog with entry of two different Types and Quantities

The resulting model code is shown in Figure 6.33. Note that the Duplicate block repeats
once for each tuple in the repeat group.

Figure 6.33 Model code

140
 • • • • •
6 • THE LOGIC WINDOW

Customized options using radio button and check box

controls

6 • Logic Window
If you are using a module in the logic window that accepts only a certain set of values
(e.g., a module containing a RadioButtonGroup or CheckBox or a ComboBox control that
has a value list), you may want to provide the same options to modelers using your
module but with a different set of terms. To do this, you can define a set of hidden
operands that contain the values required by the module in your logic window. Each of the
hidden operands is switched in only when the value provided by the user of your module
selects the “matching” customized option you provide. (For a description of switches and
their definitions, see “The Switch Window” chapter.)
For example, you might want to build a Raw Materials Receiving module representing a
receiving area that can be used in systems that move material either by forklifts or by
conveyors. The module’s logic window might contain a Leave module from the Arena
template’s Advanced Transfer panel to transfer product out of the receiving area. In the
Leave module, the options defining the transfer out type include Request Transporter and
Access Conveyor, respectively. However, in your dialog, you may want to define a radio
button group (called Transfer Type) offering the options Use Forklift and Load on
Conveyor.
The RadioButtonGroup control in the dialog is used simply to obtain a selection from the
modeler; it will not be referenced in the module’s logic window. Instead, in order to
provide the necessary value (Request Transporter or Access Conveyor) to the Leave
module, two hidden operands named Request and Access are used, with default values of
“Request Transporter” and “Access Conveyor,” respectively. These operands have
switches controlling which one is used in generating the module logic. The switch
attached to the Request hidden operand is defined to be True when the operand Transfer
Type has a value of “Use Forklift”; similarly, the switch attached to Access is True when
Transfer Type has a value of “Load on Conveyor.”
In the logic window, the Transfer Out field in the Leave module that defines the type of
transfer will reference `Request``Access` so that whichever operand is switched in
provides its value (Request or Access) to the Leave module. Note that in this example, the
Seize Resource and None options in the Leave module cannot occur since the Receiving
module does not provide a way for a modeler to define either Seize Resource or None.

141
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Module connections
Using graphical connections
In a module’s logic window, you place and connect module instances from other template
panels. The interface for creating module connections is the same as that in model
windows—you may draw a graphical connection between the exit point of one module
and the entry point of another module (using the Module > Connect menu or the
Connect toolbar button), or you may type the module label in the dialogs of the two
modules (if using the Blocks panel).
When working in a logic window, the graphical method of connecting modules is
preferable, since Arena generates unique module labels for graphical connections. If you
were to type a specific label for an entry point to a module in the logic window, you
effectively would limit that module to only a single placement within any model (since
module labels must be unique throughout an entire model).
For example, if you are creating a printing operation module, you might place a Delay
module from the Blocks panel in the module’s logic window. If you were to define the
Label field of the Delay module to have a value of BookBinding, the printing operation
module could only be placed once in any model (either directly from your template or
indirectly from any template that has an instance of your printing operation module in its
logic window). If a second instance of the printing operation module was placed in a
model, Arena would generate an error (the label BookBinding is defined more than once),
because the placement of two modules with the same label creates an ambiguity—if an
entity is sent to the BookBinding label, there is no rule to define which of the two modules
is intended. Because of this, we strongly recommend that you do not enter values for
labels to establish connections in the logic window.

Defining multiple connections from a single exit point

One difference between connecting modules graphically in a logic window and connect-
ing modules in a model window is that logic windows allow multiple connections to leave
the same exit point. Model windows restrict each exit point to have exactly one connec-
tion (whether by a graphical connection or by a specified value for the exit label operand).
However, because logic windows permit alternate paths of logic controlled by module
switches, it is necessary to permit multiple connections. (See “Switching module
instances” on page 146 for a discussion of this technique.)
To define multiple graphical connections leaving the same exit point, simply add each
desired connection to the exit point. For example, Figure 6.34 shows a Batch module
instance with two connections emanating from its exit point, one to a Record module and
the other to an Assign module. Be sure that the multiple modules that are connected to a

142
 • • • • •
6 • THE LOGIC WINDOW

single module have switches attached so that logically only one will be generated in the
underlying model.

6 • Logic Window
Figure 6.34 Multiple connections from a single exit point

Repeating exit points in the logic window

Another difference between connections in model and logic windows relates to repeating
exit points. In the logic window, you may create an operand reference for a repeating exit
point (as described in “Referencing module data” on page 114), in which case the modeler
using your module determines where entities are to be sent for each individual exit point.
Or you might graphically connect a single repeating exit point to the entry point of
another module in the logic window so that all entities sent from the module in the logic
window go to the same next module.
The logic window provides an additional option of connecting all of the points created by
a repeating exit point to the same module. To define this type of connection, connect the
repeating exit point (defined by inserting a tuple in a module’s repeat group) to a module’s
entry point in the logic window.
For example, you might be creating a module that represents the final processing step for
corrugated metal production. Some part types that go through this step require a final trim;
in all cases, the parts will be stamped (after trim for those that are trimmed). The dialog
for this module might ask the modeler to list all part types that require trim, the time to

143
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

trim parts (assuming it is the same for all part types), the stamping machine name, and the
stamping time. Figure 6.35 shows this example’s module dialog.

Figure 6.35 Corrugated Metal example dialog

The dialog design window’s Operand Explorer for this module, shown in Figure 6.36,
defines a Trimmed Part Types repeat group containing the single operand defining which
part types are to be trimmed (Part Type). The three operands that complete the dialog
request the time to trim, name of the stamping machine, and time to stamp.

Figure 6.36 Operand Explorer in dialog design window of Corrugated Metal example

In the logic window, a Branch module from the Blocks panel can be used to determine
whether entities should be sent to the trim process (represented by a simple Delay
module). Each time the modeler creates a new tuple in the Trimmed Part Types repeat
group, a new exit point will be created in the Branch module; all of these exit points will

144
 • • • • •
6 • THE LOGIC WINDOW

be connected automatically to the Delay module. To define this in the logic window, the
first tuple inserted into the Branch module’s Branch Types repeat group is defined as

6 • Logic Window
shown in Figure 6.37—the condition type is selected to be If, and the condition compares
the Part Type operand (which is repeating in the corrugated metal module) with the value
of an entity attribute PartType (which may have been initialized at an order entry module).

Figure 6.37 Branch module in Corrugated Metal example logic window

The connection point for the first Branch module tuple is connected to the Delay module
so that all entities that have a value of the PartType attribute equal to one of the part types
defined by the modeler will delay for the trim time; the Delay module is connected to the
stamping process Process module. To complete this module definition, a second tuple is
inserted in the Branch module with a Branch Type equal to Else. This exit point is
connected directly to the Process module representing the stamping process. The
complete logic window is shown in Figure 6.38.

145
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Figure 6.38 Logic window for Corrugated Metal example

This technique—connecting a repeating exit point to a single module—also is often used

in conjunction with the Conditional Assignment module described in “Using Arena’s
utility modules (from utlarena.tpo)” on page 150.

Switching module instances

One of the key aspects of Arena’s templates is the ability to define alternate model logic
that is controlled by the values that a modeler provides for the module’s operands. The
mechanism for defining that certain parts of a module’s logic should be included only
under particular circumstances is to attach a switch to a module in the logic window. The
chapter “The Switch Window” describes how switches are defined.
Switches are particularly important because of the effect that their use can have on the
speed of a simulation run. If a module uses switches to remove unnecessary paths of logic
from the module logic, the resulting simulation model represents the smallest required
logic, given the options the modeler has selected. If switches were not a key feature of
template development, all decisions about what logic should be used would need to be
made during the simulation run by each entity arriving at a module. When you design a
module, it is helpful to plan what alternatives you will provide and to sketch out how these
options might control the logic generated by module instances in the logic window.

Attaching and detaching switches

In the logic window, to attach a switch to a module, you select the module (by clicking on
its handle) and either select the Object > Switch > Attach menu item or click on the
Attach Switch toolbar button on the Template Development toolbar. A dialog is opened
containing a combo box in which the desired switch should be entered (by typing its name

146
 • • • • •
6 • THE LOGIC WINDOW

or selecting it from the drop-down list). The module handle expands to include the name
of the attached switch, enclosed in square brackets (e.g., [SwCount]). Figure 6.39 shows

6 • Logic Window
an example of attaching a switch to a Record module from the Basic Process panel.

Figure 6.39 Attaching a switch to a module instance

To remove a switch that is attached to a module, select the module and select the Detach
option of the Object > Switch menu. If you want to attach the same switch to a number of
modules or detach switches from multiple modules, select the desired set of modules
(either by using SHIFT+Click to select a group of individual modules or by box-selecting
all modules in a region of the window) and click on the Attach Switch toolbar button or
select the appropriate option of the Switch menu.
Note: A module in the logic window may have only a single switch attached to it. If you have
complex conditions involving multiple switches, define a new switch in the switch window with a
definition representing the conditions and attach this switch to the logic window module.

Effect of switches in the logic window

As described earlier in this chapter, working in the logic window of a module definition is
very similar to creating a simulation model in an Arena model window. You attach
template panels to the Project Bar and select, place, edit, and connect module instances. If
you want to define alternate logic paths to be included in or removed from the model
based on values of module operands, you define switches in the switch window and attach
these switches to module instances in the logic window.
When a module is placed or edited in a model window, switches are evaluated to true or
false based on the module’s operand values. If the model is checked for completeness or a

147
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

simulation run is initiated, the module’s logic window is examined; only the module
instances in the logic window that either do not have an attached switch or that have a true
switch are included in the simulation model logic. If a module in the logic window has a
false switch attached to it, the logic window is treated as though the module, as well as
any direct connections into or out of the module, does not exist.
For example, if you are building a module that represents collection points for overnight
package service, the module might be used both for self-serve collection boxes and for
staffed collection offices. In any particular instance in which the module is used, only one
type (self-serve or staffed office) will apply; all entities arriving at the module will be
treated either one way or the other. The dialog design window for this module could
define a selection operand, Collection Type, with options of Self Serve or Staffed Office.
In the switch window, a SwSelf switch is added with a definition of `Collection
Type`==”Self Serve.” A second switch, SwStaffed, has a definition `Collection
Type`==”Staffed.” (Refer to the chapter “The Switch Window” for more information on
defining module switches.)
The logic window of the Package Collection module defines both possible paths of logic.
In the case of self-serve collection points, perhaps you want customers to perform the
logic: Station, Delay, Route. However, for staffed offices, a Process module might be used
to represent the availability of package collection workers, so the customers will perform:
Station, Process, Route. In both cases, the Station and Route modules might contain the
same information, regardless of the collection point type. The SwSelf switch is attached to
the Delay module so that it is included in the model logic only when SwSelf is True;
similarly, SwStaffed is attached to the Process module. The complete logic window might
be defined as shown in Figure 6.40.

Figure 6.40 Logic window with switched modules offering two alternatives

148
 • • • • •
6 • THE LOGIC WINDOW

Note that the Station module has two connections to its exit point. While this is invalid in
a model window (i.e., each exit point in a model window must have exactly one

6 • Logic Window
connection), logic windows permit multiple connections because switches can effectively
delete connections, depending on the values of the module’s operands.
It is incumbent on you as the module designer to ensure that the switches you have
defined and attached to module instances in the logic window will permit exactly one
connection to be active (i.e., not switched out) from each exit point in any possible use of
your module. In modules with switches, it is very helpful to test carefully each alternative
of model logic (based on the variety of possible values for module operands) to ensure
that the logic window is correct.
There are no restrictions on the complexity of modules that are to be switched in a logic
window. The overnight package collection point example simply selects one of two
alternatives, where each alternative includes only a single module. Any alternative might
involve many modules with additional switches that provide additional options. The
definition of modules such as the Leave module (Advanced Transfer panel) might involve
dozens of switches controlling the display of operands in the module dialog and the
module instances in the logic window.
A slight extension of the package collection point example might be to ask the modeler
whether customers arriving at self-serve collection points might balk (i.e., not send the
package at that collection box) based on some condition. The logic to represent this new
option appears in Figure 6.41.

Figure 6.41 Logic window for Package Collection module with customer balking option

149
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

A new logic path has been added emanating from the Station module. In this path, a
Decide module has been placed with two exit points: one connecting to a new Delay
module and one connecting directly to a Route module (for balking customers). Each of
the new modules has a new switch, SwBalk, attached. This switch might be defined based
on a new check box operand, Balk Customers, having a value of Yes. The Balk Customers
operand, in turn, could be switched in only when SwSelf is true, since the module should
ask whether customers are to balk on a condition only for self-serve collection boxes.
To verify that the module is correctly defined, each exit point containing multiple
connections should be traced to ensure that exactly one of the connections will be
switched in for any value of the SwSelf, SwStaffed, and SwBalk module switches. The
only module containing multiple connections to a single exit point is the Station module.
By tracing the switched-in modules for each of the combinations of switch values (on and
off for each of the three switches), you can ensure that your module will generate valid
module logic in any possible use.

Using Arena’s utility modules (from utlarena.tpo)

Arena provides a private utility template panel file, named utlarena.tpo, that contains a set
of modules that are designed exclusively for use in module definition logic windows.
(Refer to the chapter “The Template Window” for information about private templates.)
Because it is a private template, it cannot be attached for use in model windows. The
following sections describe the modules contained in this template panel and illustrate
their use.

HIDDEN MODULE

One module in the utlarena.tpo template panel file, the Hidden module, is designed
specifically to aid in defining logic windows that contain switches on module instances.
This module does not generate any model logic or elements. (See the chapter “Elements”
for information on elements.) It simply contains entry points and exit points to allow other
modules to connect in and out of it.
The hidden module is used for cases where one or more of the alternatives to be switched
in/out in the logic window do not generate any model logic. In these cases, a connection
must be formed to show the desired flow of logic (because you cannot attach a switch to a
connection directly), but there is no module instance to which a switch can be attached to
indicate when the alternate path should be taken.
For example, let’s return to the overnight package-collecting module illustrated in Figure
6.40. We might add an option for the self-serve types of package offices to count the
number of customers who dropped off packages. A switch, SwCount, could be defined to
be true if the modeler indicated that this count should be collected. Another switch,
SwNoCount, could be defined to be true when no count is to be taken.

150
 • • • • •
6 • THE LOGIC WINDOW

The desired logic for this additional option, shown in Figure 6.42, includes an instance of
a Count module after the Delay only when the modeler indicates that the count is to be

6 • Logic Window
collected (i.e., SwCount is True). On the other hand, if no count is to be taken, the second
connection from the Delay module should send entities directly to the Route module.
However, if a connection were added directly from the Delay to the Route module, the
resulting logic would have two valid connections if the modeler chose to count customers
(i.e., the connection to the Count module and the one to the Route module). To prevent
this, the hidden module is added between the Delay and the Route so that any use of this
module can have only a single switched-in connection from the Delay module’s exit point.

Figure 6.42 Logic window using hidden module instance

Note: The Hidden_All_Types module provides the same functionality as the Hidden module with
additional options for the various types of entry and exit points so you can connect it to any other
module.

151
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

THE CONDITIONAL ASSIGNMENT MODULE

The utlarena.tpo template contains another module, the Conditional Assignment module,
which may be used only in logic windows. This module may be thought of as a
combination of a Branch module (Blocks panel) and an Assign module (Basic Process
panel), where each branch leaving the Conditional Assignment module may perform its
own assignment. The module dialog for the Conditional Assignment module is shown in
Figure 6.43.

Figure 6.43 Conditional Assignment module dialog

The Conditional Assignment module can be useful in cases where the system you are
representing has an unknown number of conditions that dictate the values that should
apply for a particular activity.
For example, in the module representing the overnight package office, you might want to
allow modelers to specify different conditions to be tested about self-serve customers and
to define individual delay times based on the condition. To represent this in the logic
window, you could use a Conditional Assignment module that references the condition
operand and assigns an attribute (DelayType) to the delay time specified by the modeler
for each condition. The Conditional Assignment module connects to the Delay module,

152
 • • • • •
6 • THE LOGIC WINDOW

which uses the DelayType attribute (rather than an operand of the module) to specify the
delay time. This logic is shown in Figure 6.44.

6 • Logic Window
Figure 6.44 Use of Conditional Assignment module in logic window

Defining module trace

Arena provides a trace of the logic performed by entities during a simulation run. At the
lowest level, SIMAN block Trace gives detailed, step-by-step information about the
processes undertaken to represent a module’s logic. As a module designer, you do not
need to provide any additional information for this type of trace to be activated. If a
modeler using your template wishes to view block Trace, the Run > Run Control >
Command opens a command window at the bottom of the screen. The Toggle Trace
button can be used to turn SIMAN block trace on or off.
You can define additional, module-specific trace messages by inserting Trace modules
(from the Blocks panel) at any place in the logic window that allows standard entry and
exit connections. (Refer to the Trace block in online help for a description of the module
and its fields.)

153
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

For example, in the package office module described in the previous section, you could
add trace messages indicating when entities leave the module. If the trace messages are to
be different for each type of module (i.e., self-serve or staffed), individual Trace modules
are added with the appropriate switches attached, as shown in Figure 6.45.

Figure 6.45 Module logic window with Trace modules

Logic definition rules and guidelines

The following rules summarize important points concerning the definition of a module’s
logic.
„ Modules cannot contain instances from the same template panel or any template that
has the template being edited attached to it.
„ Entry and exit points of module instances in the logic window should be graphically
connected or should reference a module operand. (The entry point operand for
modules that create entities and queue balk exit points are exceptions; they may be
unconnected in a logic window.)
„ If a module instance in the logic window has any required fields, you must supply
values to them. If a required field contains a simple reference to an operand of your
module, the referenced operand should be defined as required in your module’s dialog
design window. If the required field’s value is defined using multiple operand
references, you should ensure that under any valid combination of values entered by a
modeler (for your module), the field in the module instance cannot be blank.
„ If you reference an operand in a module instance, you should ensure that the data type
of the operand that is referenced matches or is more restrictive than the data type of

154
 • • • • •
6 • THE LOGIC WINDOW

the field in the module. For example, you should not define an operand with an
expression data type for a resource capacity field that accepts only integer values.

6 • Logic Window
„ If a particular entry or exit point is referenced more than once in the logic window,
switches should be attached to those modules containing the references so that it is
only possible for one of the modules to be switched in.

155
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

156
7 The User View Window
The user view of a module is the display that appears when a modeler places the module
in a model window. The user view always contains a module handle. It also may contain
module-related objects (such as entry/exit points or displayed operands) that are created
based on information provided in the dialog design window. You may add draw and
animation objects to the user view as well.
To edit a module definition’s user view, select the module in the template window’s

7 • User View Window

module list, then select Window > User View or click the User View Window button on
the Template Development toolbar. This opens a user view window, as illustrated in
Figure 7.1.

Figure 7.1 User view window

The user view window’s drawing region is identical to a model window’s region; for
example, its home view displays objects in the same size as a model window’s home view.
Other information that relates to object sizes, such as text proportions, grid spacing, etc.,
is also defined in the same world units used in model windows. (Refer to online help for
additional information about model windows.)
Note: If you change the zoom level of the user view, remember to return to home view to ensure
that objects you have placed in the user view are sized as you want them to appear in the default
view in a model window.

Module instances
When a module instance is placed in a model or logic window, the objects that are in the
module definition’s user view window are copied into the “destination” (i.e., model/logic)
window. The location where the modeler clicked to place the module is used to position

157
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

the upper-left corner of the module handle. Other user view objects are arranged around
the handle in the relative sizes and positions defined in the user view window.
After being placed in a model, the objects in the module’s user view may be repositioned
individually by the modeler. Also, the characteristics of draw and animation objects may
be changed; these objects can be cut, copied, pasted, deleted, or duplicated as well. For
example, a queue animation object that accompanies the Process module (from Arena’s
Basic Process panel when the action includes a seize) could be changed from its default
line type to a point type, or could be repositioned relative to the module handle location.
Note: When the handle of a module instance is moved, user view objects are relocated with the
handle. In the user view window of the module definition, however, relocating the handle does not
move the user view objects.

Module-related objects
When defining modules, certain objects are added to the module user view window
automatically. These are:
„ the module handle,
„ entry points,
„ exit points, and
„ all operands that have their InUserView property set to True in the dialog design.
Figure 7.2 shows the user view of an instance of the Process module from the Basic
Process panel. It includes a handle (Process #), entry point, exit point. Note that when the
module handle name, Process #, is changed, the handle of the module takes on that new
name as well. (See “The Module Text Options dialog box” on page 159 for more
information.)

Figure 7.2 User view of Process module instance

158
 • • • • •
7 • THE USER VIEW WINDOW

The module handle

The module handle refers to the name that appears when the module is placed in a model
or logic window. Arena automatically places a module handle object (displaying the
module name, by default) in each module’s user view window when the module is
created. You may change the handle name by double-clicking on the module handle object
in the user view window (see “The Module Text Options dialog box” on page 159). A
module handle may contain a maximum of 32 characters.
Because all modules must have exactly one module handle, the handle object may not be
cut, copied, duplicated, or deleted from the user view window; it also may not be grouped

7 • User View Window

with other objects.

The Module Text Options dialog box

The module handle, by default, displays the module name. The name may be changed by
double-clicking on the module handle to open the Module Text Options dialog box. You
may either change the text string specified, or you may uncheck the Use Text String for
Module Handle check box and specify an operand name that will appear as the module
handle.
You will notice that in the Arena template modules (Basic Process, Advanced Process,
Advanced Transfer), when you place a module in a model window, the handle is the
unique name given to that module. For example, the Process module, when placed,
becomes Process 1. The second instance becomes Process 2, the third is Process 3, and so
on. These names are based on the name of the module, which can be changed by the user
in the Process dialog box. Therefore, the module handle is not always Process, but is
based on the user’s name input into the module Name operand.
The module handle font, font style, and font size are set at the default size so that all
Arena modules have a consistent interface for accessing module data. By clearing the Use
Default Font check box, however, you may change the module handle’s size, style, and
font. Additionally, the line, text, and fill color may be changed using the Color toolbar.

Figure 7.3 Module Text Options dialog (with Text String or Operand Name used for module
handle)
159
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Entry and exit points

Entry point and exit point objects in the user view are created automatically by Arena for
each entry point and exit point operand defined in the dialog design window. The entry
and exit point objects provide a graphical means of connecting the resulting module to
other modules.
Entry and exit points may be moved anywhere within the user view window. When you
select an entry or exit point, the operand name for that point is shown below the graphical
object (so you may distinguish the points from one another if you have more than one
entry or exit point operand).
The appearance of entry and exit points depends on the type of point. Figure 7.4 shows
each entry and exit point type in a user view (including a repeatable exit point), with the
point type labeled next to the graphical entry/exit point.
The orientation of a non-repeatable exit point object may be rotated by double-clicking on
the object. Entry and exit point objects may not be cut or copied to the clipboard,
duplicated, deleted, or grouped with other objects.
Note: If the operand that defines the entry/exit point is deleted from the dialog design window, the
corresponding object is removed from the user view window.

Figure 7.4 Entry and exit point types

You may not attach a switch to an entry or exit point object in the user view window. You
may, however, attach a switch to the operand (in the dialog design window) that defines
this object; the switch attached to the operand will control whether the graphical entry/exit
point object is displayed in the module’s user view.

160
 • • • • •
7 • THE USER VIEW WINDOW

Displayed operands
Operands that have been defined in the dialog design window with the InUserView
property set to True will automatically create a text object (referred to as a displayed
operand) in the user view window. (Refer to the chapter “The Dialog Design Window” for
information about defining displayed operands.) In the user view window, the text object
representing the displayed operand is shown as the name of the operand. After a modeler
places the module in a model or template logic window, the text changes to show the
value of the operand.
You may locate the displayed operand anywhere within the user view window. You may

7 • User View Window

not cut or copy displayed operand objects to the clipboard, delete them from the user view
window, or group them with other objects.
For example, Figure 7.5 shows a user view window for a Train Arrivals module
containing two displayed operands—Yard and Interarrival Time.

Figure 7.5 User View window with two displayed operands

161
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

If a modeler placed this module and provided values of Conway and NORMAL(0.21,0.11)
for the operands, the user view for the module instance would display the two operand
values below the module handle, as shown in Figure 7.6.

Figure 7.6 Displayed operands in module instance

As is the case with entry and exit point operands, you cannot attach a switch to this type of
object in the user view window. Instead, whether it appears in a model or logic window it
is controlled by the switch (if any) attached to its associated operand in the dialog design
window.
Also, draw objects (discussed in the next section) may be grouped; however, they may not
be grouped with the module handle.
You may attach switches to draw objects in the user view. If a switch is attached, the
object will appear only if the attached switch is evaluated to True.
If you display a repeatable operand in the user view, the user view will simply show the
operand name (as is the case for non-repeatable operands). When a modeler uses the
module, Arena will place the values of the operands in a vertical list. If a third, repeatable
operand, Characteristics, were added to the module in Figure 7.5 and a module instance

162
 • • • • •
7 • THE USER VIEW WINDOW

were created with values Number of Cars, Schedule, and Number of Engines, the display
of the instance would appear as shown in Figure 7.7.

7 • User View Window

Figure 7.7 Module instance with repeatable displayed operand

Because the length of an operand value typically is unknown (i.e., modelers might provide
short or long values), displayed operands in the user view typically are placed vertically.

Draw objects
Draw objects (boxes, lines, circles, etc.) may be placed in the user view window via the
Draw toolbar. These are added in the same way that you would add draw objects to a
model window. Simply choose the desired object from the toolbar and place it in the
window. The hidden and visible layers may be used to control whether or not objects
defined in a module’s user view will appear during a simulation run. (Refer to online help
for more information about these layers.)
Draw objects may be cut, copied, pasted, duplicated, and deleted. If objects are cut or
copied to the clipboard, you may paste them into any window that supports draw objects.
After placing a module in a model or template logic window, a modeler may change the
characteristics of (or delete) draw objects that were provided by the module user view.
Draw objects placed in the user view window may have attached switches (see “User
View switch use” on page 166). If so, the object will appear only if the attached switch is
evaluated to True.

163
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Animation objects
Animation objects (e.g., queues, stations, levels) may be placed in the user view window
via the Animate toolbar. These are added in the same way that you would add animation
objects to a model window. Simply choose the desired object from the Animate toolbar,
type the required information into the object’s dialog, and place the object in the user view
window.
Animation objects may be cut, copied, pasted, duplicated, and deleted. If animation
objects are cut or copied to the clipboard, you may paste them into any window that
supports animation objects.
When editing an animation object, you may specify that it is named by using the value of
one or more module operands. To create this tie between the module dialog and an
animation object, you create an operand reference by enclosing the operand name in back
quotes (`) . For example, if you are defining a module in which a count is collected with
operand Counter Name defining the name of the counter, you might place an animation
variable in the user view to show the value of the count during the simulation run. The
Expression entry in the variable dialog could be defined as NC(`Counter Name`), as
shown in Figure 7.8.

Figure 7.8 Operand reference in animation variable dialog box

164
 • • • • •
7 • THE USER VIEW WINDOW

Operands may be referenced only in the entries within animation object dialogs listed in
Table 7.1. Other animation object characteristics may be defined in the user view, but may
not reference module operands.
Also, if an animation object is part of a module instance’s user view, the entry listed in
Table 7.1 is not changeable (i.e., is grayed out) by the modeler, with the exception of
repeatable values (i.e., plot expressions, entity values, resource states, and global values).
The operand references in the animation objects follow the guidelines described in
“Referencing module data” on page 114 of “The Logic Window” chapter.

7 • User View Window

References to repeating operands are not permitted in animation objects, including the
cases where the animation object allows a repeating set of values (i.e., plot expressions,
entity values, resource states, and global values).
If an animation object containing operand references is copied from the user view window
to the clipboard and is pasted into a model window, the entries containing references are
changed to blank (since, after being pasted, the animation object is no longer part of a
module). If the animation object had a switch attached to it, the switch is removed if the
object is pasted into a model window.
Animation objects placed in the user view window may have attached switches (see the
next section). If so, the object will appear only if the attached switch is evaluated to True.

Table 7.1 Animation object characteristics that permit operand references

Animation Object Entry Permitting Reference

Queue Identifier
Storage Identifier
Parking Area <none>
Seize Area <none>
Station Identifier
Intersection Identifier
Route <none>
Segment Identifier
Distance Identifier
Network Identifier
Variables Expression, Format
Clocks Time Units Per Hour, Hour, Minute, Second

165
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Table 7.1 Animation object characteristics that permit operand references

Animation Object Entry Permitting Reference

Date Time Units Per Day, Month, Day, Year, Hour, Minute, Second
Levels Expression, Minimum, Maximum, Expression (Accum.),
Minimum (for Expression (Accum.)), Maximum (for Expression
(Accum.)), # of Points, # of Distribution Points, Width
Histograms Expression
Plots Any textual property value (i.e. you may enter a value into the
field for specifying the property value)
Entity Value
Transporter Identifier
Resource Identifier, State
Global Expression, Value

User View switch use

Of the objects that may appear in the user view window, only animation and draw objects
may have attached switches. A switch contains a conditional expression that is evaluated
to True or False. If the switch condition is evaluated to be True, all animation or draw
objects with the switch attached will appear in the model window. If False, these objects
will not appear in the model window. For more information about switches and their uses,
refer to “The Switch Window” chapter.
To attach a switch to an animation object in the user view window, highlight the object
and choose the Object > Switch > Attach menu option, or click the Attach Switch
toolbar button (shown at left). Then type the name of the switch or select it from the drop-
down list in the dialog that is displayed.
Note: Only a single switch may be attached to any object in a module definition.

For example, if the module illustrated in Figure 7.8 also contained a switch named
SwCount, this switch could be attached to the variable in the user view window so that the
animation variable only was displayed if a count is being collected (i.e., the value of
SwCount is True). In this case, after the switch is attached, the variable’s name (as

166
 • • • • •
7 • THE USER VIEW WINDOW

displayed in the user view window) changes to show the switch name enclosed in square
brackets, as shown in Figure 7.9.

7 • User View Window

Figure 7.9 Animation variable with SwCount switch attached

To detach a switch from an object, highlight the desired object and choose the Object >
Switch > Detach menu option.
To attach a different switch to an object that already has a switch attached, simply attach
the new switch using the procedure described above. The former switch will
automatically be detached and the new switch attached.
If multiple objects are selected (i.e., through a box selection or by using CTRL+Click to
select individual objects), the attach and detach switch actions apply to all of the selected
objects.

167
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

168
8 The Switch Window
A switch is a construct that allows a template designer to define variations of:
„ the fields displayed in a module dialog,
„ the model logic and elements that are generated when a simulation run is initiated, or
„ the animation objects displayed in a module’s user view.
To control the appearance of the module or its underlying simulation logic, you define
switches (using the switch window) and attach them to the objects in the module
definition’s other windows (dialog design, logic, user view).
As its name implies, a switch can have a True (“on”) or False (“off”) value. If an object
has a switch attached, the object is displayed or included in simulation logic only if the
switch condition evaluates to True.
The use of switches permits you to capture a wide range of variations of some process or
system element in a single module, rather than needing to define separate, similar modules
for each variation. Switches also can be used to control the information presented to
modelers so that only the relevant fields are displayed.

8 • Switch Window
For example, if a module representing an automated teller machine (ATM) has an option
for the modeler to indicate whether deposits are accepted at the ATM and a modeler
selects “No,” there may be no reason to ask the modeler to define the processing time for
deposits. In this case, a switch can be defined to turn off the deposit process time operand
(i.e., remove it from the dialog) for any ATM that doesn’t accept deposits. The
corresponding logic for processing deposits also could be removed by attaching the switch
to the appropriate module instances in the module’s logic window.
In this chapter, we present the mechanisms for defining switches and for interacting in the
switch window. The “Dialog Design Window,” “Logic Window,” “User View Window,”
and “Elements” chapters describe the effects of switches on each type of module construct
and the mechanism for attaching switches to objects in a module definition.

Defining switches
A switch simply consists of a name and a definition. The switch definition is a conditional
expression that evaluates to True or False. It may contain operand names, operand values,
and/or other switch names.

169
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

A switch can be attached to any of the following objects in a module definition:

„ operand, repeat group, and dialog objects in the dialog design window using the
SwitchName property;
„ module instances in the logic window; and
„ animation and draw objects in the user view window.
A switch may be attached to numerous objects of the same or different types. For
example, a switch named SwCount might be attached both to an operand in the dialog
design window and to an animation variable in the user view window. When the switch’s
conditional expression is evaluated, these logic, operand, and/or animation objects will
either become part of the model (if the switch is True) or will be ignored (if the switch is
False).

Switches are defined by opening the module’s switch window and specifying the switch
name and definition. A module’s switch window is opened by clicking on the module in
the template window’s Module Definitions list, then selecting the Window > Switch
menu item or pressing the Switch Window button on the Template Development toolbar.
To create a new switch definition, click the Add button in the switch window. In this
dialog, you will specify the switch name and the definition (i.e., the condition under
which the switch is True) and click OK. Figure 8.1 shows the switch window with a
single switch definition (SwDeposits).
It is sometimes useful when duplicating, copying, pasting, or deleting switch definitions
to perform the operation on multiple switches. You may select multiple switches by using
SHIFT+click to select a range of switches or by using CTRL+click to add individual
switches to the selection set.

Figure 8.1 Switch window

Switch names
A switch name may be specified as an unlimited number of alphanumeric characters.
Whenever switches are referenced or are attached to module objects, the switch name is
not treated as case-sensitive.
Note: Within a module, the operand, repeat group, dialog, and switch names must be unique.

170
 • • • • •
8 • THE SWITCH WINDOW

Switch definitions
Switch definitions are conditional expressions that rely on the values of other operands
and/or switches.
When referencing an operand, the operand name must be enclosed in back quotes (`); to
compare the operand to a value, the value must be enclosed in double quotes (“). For
example, to define a switch that is true if the operand Accept Deposits (which might be
displayed as a check box in the module dialog) has a value of Yes, the condition would be
`Accept Deposits`==”Yes” (as shown in Figure 8.1).
To use the value of another switch in a definition, simply type the name of the switch (i.e.,
no special characters are necessary to identify the switch name).
Table 8.1 summarizes the valid references for operands, values, and switch names.

Table 8.1 Switch reference types

Referenced Item Enclose In Example Definition

Operand Back quotes (` `) `ResName`==”Machine”

8 • Switch Window
Value of operand Double quotes (” ”) `State`< >”Busy”
Switch — Switch1 && !Switch2

To define the conditional expression for a switch definition, you may use one or more
standard logical or mathematical comparison operators, summarized in Table 8.2. The
operators are listed in the order of evaluation of a switch condition.

Table 8.2 Switch definition logic operators

Logical
Operator Meaning Use Example

== “is equal to” Compare op to value `Setup Required`==”Yes”

<> “is not equal to” Compare op to value Counter`< >”None”
! “not” Take the opposite of a !SwSetupRequired
switch value
&& “and” Combine comparisons, SwCount &&
requiring both to be true `Counter`==”Individual”

171
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Table 8.2 Switch definition logic operators

Logical
Operator Meaning Use Example

|| “or” Combine comparisons, SwSetup || SwNewRecipe

requiring either to be true
> “is greater than” Compare op to value `Number`>”14”
>= “is greater than or equal Compare op to value `Weight`>=”100.3”
to”
< “is less than” Compare op to value `Time`<“10.5”
<= “is less than or equal to” Compare op to value `Tables`<=”20”

Comparisons of operands to values are performed by comparing the characters typed in

for the operand value versus the characters specified in double quotes in the switch
definition. These comparisons are not case-sensitive.
Parentheses are not supported in switch definitions. For complex conditions, separate the
condition such that grouped comparisons (i.e., those you would like to place in
parentheses) are defined in individual switches, then use these switches to build the larger,
complex condition.
As described in “The Template Window,” you can view a list of the switches defined for
all modules in a template panel file or for a single module using the Check > Report
menu option. This report lists a table of switch names and definitions, so that you may
view a summary of all switch definitions together (rather than needing to edit each switch
individually).
Switches are displayed in the switch window in alphabetical order.

Switch definition rules

„ A switch may not reference itself in its definition.
„ Circular references are not allowed. This means that a switch may not reference
another switch that uses the first switch in its definition. For example, if switch
SwBind is defined to be SwLooseleaf &&`Format`==”3 Ring,” then the switch
SwLooseleaf may not contain a reference to SwBind.
„ A switch may not be attached to an operand that is referenced in its definition. For
example, the switch SwBind defined above may not be attached to the Format
operand, since Format is used in its definition.

172
 • • • • •
8 • THE SWITCH WINDOW

This applies to direct references (as in the operand Format in the above example) or to
indirect references created via switches contained in a definition. For example, if the
switch SwLooseleaf in the above example was defined using the condition
`Prebound`==”No”, the SwBind switch could not be attached to the operand
Prebound since Prebound is involved in the definition of SwBind indirectly through
SwLooseleaf.
„ If a switch references a repeatable operand, the switch will have a separate value for
each tuple (i.e., each set of values for the repeating operands) of the module’s repeat
group. (Refer to the chapter “The Dialog Design Window” for a discussion of repeat
groups and tuples.)
For example, the Basic Process panel’s Assign module allows repeated assignments to
different types of elements (Attributes, Variables, Pictures, etc.). The assignment
repeat group contains a set of operands with switches that ensure that only the
appropriate operand will be displayed, based on the selection of the assignment type.
One switch is true when Attributes is selected, one is true when Variable is selected,
etc.
When the Assign module is used in a model, the first tuple might assign an attribute;
the second, a picture; and the third, a variable. The module’s switches are evaluated

8 • Switch Window
for each individual tuple. In the case of the first tuple, the switch that is true when
Attributes is selected has a true value, but the switches that are based on the
assignment type being Variables, Pictures, etc., are false. In the second tuple, the
Pictures switch is true and the others are false. And in the third tuple, the Variables
switch is true.
„ Because the value of the switch changes depending on which set of repeating
operands (i.e., tuple) you are examining, a switch that references a repeatable operand
should be attached only to operands in the same repeat group.
„ A switch may not reference an entire repeat group (i.e., switches only may reference
operands).
„ A switch may not refer to a specific tuple of the repeat group (e.g., the fifth
assignment in a module).

173
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

174
9 The Panel Icon Window
The panel icon of a module is the graphic display that appears in a panel when a modeler
attaches a template panel to the Project Bar. Figure 9.1 shows the panel that is displayed
when the Arena template’s Basic Process panel is attached.

9 • Panel Icon Window

Figure 9.1 Arena template Basic Process panel

The panel icons are defined in a panel icon window using drawing objects such as lines,
boxes, circles, etc. To open a module’s panel icon window, select the module in the
template window’s Module Definitions list, then choose the Window > Panel Icon menu
item or click the Panel Icon Editor button on the Template Development toolbar.

175
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

A panel icon window is shown in Figure 9.2.

Figure 9.2 Panel icon window

Creating the panel icon

There are three panel display options allowed for templates: Standard Buttons (the
default), Large Buttons, and Text Only; this setting is defined in the Template Options
dialog (refer to “The Template Window” chapter). All icons in a template panel file have
the same size.
To design your icon, we recommend that you select a very simple picture that represents
the activity of the module and label it by placing the module name at the bottom of the
icon. When you open the panel icon window, Arena automatically places the module
name (first four letters only) as a text object at the bottom of the panel icon window. You
may change the characteristics of this object as you would when editing any other text
object (e.g., change the text string, the size and orientation, etc.) by double-clicking on the
default text.
You may use the Draw toolbar to create additional graphics for your icon by selecting the
desired tools from the palette and placing objects in the window. Characteristics of objects
(line width and style, border, and fill colors) can be specified either before or after placing
the objects in the window. Draw objects also may be pasted from another window using
the clipboard.
You may also access the Arena Symbol Factory to cut and paste symbols into the panel
icon window. This library of symbols may be accessed by going to Tools > Arena
Symbol Factory. Simply select a category of symbols and click on the symbol you desire.
This will place the symbol in the Preview box, where you can then copy it to the clipboard
and paste it into your panel icon window.

176
10 Elements
In many cases, the modules that we build represent a component of a system that contains
one or more objects. For example, we might build a workstation module that represents an
in-buffer, a worker, a machine, and an out-buffer. These objects in the system have certain
characteristics and behaviors that we must capture in our module. For example, the in-
buffer must maintain an ordered set of parts to be processed on the machine.
Arena, through its base language SIMAN, provides a complete set of modeling objects
called elements that can be used directly for representing the components of a system. For
example, Arena provides a queue element that maintains an ordered list of items and has
operations for inserting entities into and removing entities from the queue and for
searching and sorting the members of the queue.
By using Arena’s built-in elements in your modules, you gain access to predefined model-
ing objects that represent complex physical components in your system. Elements are
important in module building because they provide a powerful mechanism for represent-
ing standard objects in a module such as workers, equipment, conveyors, carts, etc.
Although elements referenced in a module are frequently used to represent physical
components of systems such as machines and workers, in some cases, the elements are
used to represent information such as process plans, failure patterns, shift schedules, etc.
These data elements provide a structured method for representing system information.
Arena provides operations that access the data contained in these elements based on the
element type. For example, an entity may undergo a route operation that references a
sequence element, in which case, the sequence element specifies the destination station
and the assignments to be made to entity attributes and model variables.
The real power of the elements lies in the built-in functionality that is automatically
provided by Arena/SIMAN for each element type. When you incorporate an element in
your module, the element has a standard set of characteristics, called properties, that
describe the element and a standard set of operations that can be applied to alter its state.
For example, if you employ a resource element, it has a standard set of data properties that
describe it (capacity/shift pattern, operating states, failure and repair characteristics, etc.)
as well as standard operations that can alter its state (Seize, Release, Preempt, etc.).
Likewise, a conveyor element has standard properties that specify its characteristics (path,
speed, etc.) and standard operations that change its state (Stop, Start, Convey, etc.).
Although there are a few key element types that are commonly used in building modules,
10 • Elements

there are a total of more than 40 different element types built into the SIMAN language to
represent the wide range of system components that you might encounter. The complete
set of element types and their corresponding properties and operations are documented in

177
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

detail in the online help. Table 10.1 lists some of the properties and operations associated
with six frequently used elements.

Table 10.1 Some elements and sample properties and operations

Element Properties Operations

Resource Name Seize

Capacity/Schedule Release
States (Busy, Idle, etc.) Preempt
Failure Pattern Alter
Costing and Efficiency
Conveyor Name Access
Path Segments Convey
Velocity Exit
Cell Size Start
Status Stop
Type
Transporter Name Allocate
Number of Units Request
Type Move
Velocity Transport
Acceleration Free
Deceleration Halt
Initial Unit Characteristics Activate
. (Position, Status, Size)
Queue Name Queue
Ranking Criterion Insert
Shared Indicator Search
Remove
Station Name Convey
Associated Intersection Route
Recipe Transport
Station
Variable Name Assign
Initial Value

Arena provides a complete set of modules for manipulating the state of an element. The
Arena template provides modules for referencing and using the most common element
types such as stations, resources, conveyors, and transporters. The modules in the Basic
Process panel provide access to these elements at the workstation or workstation

178
 • • • • •
10 • ELEMENTS

component level. For example, the Process module represents an operation in which
multiple resources may be seized, held for a specified time, and then released.
The Advanced Process panel provides lower-level operations from which complex
operations can be built. For example, the Seize module in the Advanced Process panel
allows you to seize units of one or more resources, and the Release module allows you to
release one or more resources. By combining these modules with other modules, very
complex resource logic can be represented. The modules in the Advanced Transfer panel
provide access to the elements that are used to represent material transfer devices, such as
conveyors, carts, AGVs, etc.
In some cases, you may need access to additional operations (e.g., scanning a condition)
that are not directly supported by the Arena template or you may need to use one or more
elements that have no direct support in the Arena template. In this case, you can use
modules from the SIMAN template to define and manipulate these elements. The
elements in SIMAN are defined using the modules in the Elements panel; the operations
for manipulating these elements are provided in the modules that are included in the
Blocks panel. The modules in the Elements and Blocks panels provide complete access to
all element types and operations supported by the SIMAN language.

Defining elements in modules

Creating elements
When you define a module, you can specify that one or more elements, such as queues,
resources, transporters, etc., be created when a modeler places an instance of your
module. Your module also may present properties of its elements in the module dialog so
a modeler can change the characteristics of the elements. And the module logic may
specify operations that act on the module’s elements such as seizing a resource or
transporting to a destination station.
In a module definition, you may create an element in two ways. First, in your module’s
logic window, you can place instances of modules that themselves create elements. For
example, if you are defining a baking-line module and you place a Process instance in the
logic window that specifies a resource named Oven, an Oven resource element will be
created when a modeler uses your baking-line module. You can think of this mechanism
as defining elements through Arena’s hierarchy.
The second mechanism for creating elements is to place an operand in the dialog design
window of your module definition and, in the operand’s LogicProperties property, specify
10 • Elements

the operand as an Element. In this case, you need not place a module instance in the logic
window to cause the element to be created. Instead, by specifying that the operand’s type
is Element, you indicate that the value of that operand in an instance of your module is to
be taken as the name of an element. You can think of this approach as defining elements

179
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

via element operands. Refer to “The Dialog Design Window” for a description of the
LogicProperties property and operand types.
The two approaches for defining elements, including their merits, will be discussed
further in “Defining elements via hierarchy” on page 183 and “Element operands” on
page 183.

Element lists
When a modeler creates an element (e.g., a resource), it is added to a list that is stored as
part of the simulation model. These element lists are stored separately by element type.
Module instances can display these lists so that, in many cases, a modeler simply can
select an existing element from a list.
For example, if you build a model containing Enter, Process, and Leave modules from the
Arena template, you might define the station name in the Enter module to be Print Jobs.
When you do so, a station element named Print Jobs is added to the simulation model and
to the list of station elements. Within the Process module, you might specify that entities
require processing with a resource named Joe, adding an element to the resources list.
When you then edit the Leave module, if you require a resource for transferring out of the
module using a station transfer, you will find the resource Joe and the station Print Jobs
already on the resources and stations lists, respectively.
The use of element lists in module definitions can make a template much easier for
modelers to use by allowing them to select the elements they already have defined in their
model, rather than needing to retype the name of the element. You can further tailor the
lists presented to a modeler by using element sub-lists. This concept is described in
“Element operands” on page 183.

Properties
Elements have characteristics that we refer to as properties. A particular element that has
been created in a simulation model, such as a resource named Oven, has its own set of
values for its properties. One resource element (e.g., Oven) may have a capacity of 12,
while another resource element (e.g., Bake Prep) may have a capacity of 1.
You may allow a modeler to define the property values for a particular element by using
one of two mechanisms (in the module definition) that are similar to those available for
creating elements. In the first case, you place a module instance (such as a Resource
module from Elements panel) in the logic window of your module definition. In this
module instance, you can specify that element properties are defined through references to
your module’s operands (e.g., a resource capacity operand). In this case, your module
gives a value to the property through hierarchy.

180
 • • • • •
10 • ELEMENTS

The second mechanism for defining a property is to place an operand in the dialog design
window of your module definition and, in the operand’s LogicProperties property, specify
the operand as a Property. You then specify which operand in the module definition
defines the element with which the property operand is to be associated (e.g., the operand
defining the resource, if the property is a resource capacity). This approach has the benefit
of correctly displaying an element’s property even if it is defined by more than one
module instance in a simulation model. We discuss this approach further in “Defining
Property operands” on page 187.

Use of elements and properties in module definitions

The concept of elements and properties is important regarding template design for two
primary reasons. First, Arena’s storage of elements and properties as global information
allows access to the properties of a particular element by many module instances in a
simulation model. Second, elements may be collected into lists for presentation in module
dialogs. We discuss these two concepts in the following sections.

Access to properties in a model

The use of element and property operands allows modelers to access information related
to elements in more than one place in a simulation model. Although property information
for a given element is “global” and could be accessed through multiple modules, it is
recommended that property information for an element be defined within a single module,
such as a data module, for a given element type. This typically eliminates confusion for
the end user, so that properties of a resource, such as capacity, schedule, failures, etc., are
defined and changed in only one location, not in multiple modules. The Auto-Created
Module feature allows logic-type modules to define data modules automatically. (Refer to
the operand object’s LogicProperties property description in “The Dialog Design
Window” chapter.)
For example, if you were building a model of a welding line, you might use a Process
module (from the Basic Process panel) to represent the welding process for standard-type
parts. Another set of logic in the same model for welding oversized parts might use a
different Process module. Both of these modules would use the Welding resource for
processing. A Resource data module (also from the Basic Process panel) is created
automatically for the Welding resource, with default information for its properties, such as
a capacity of 1. The Resource module can then be edited to specify the characteristics of
the Welding resource (e.g., its schedule, failure patterns). 10 • Elements

Although you may define a module that contains property information within the dialog,
such as defining a Process type of module where the user can define capacity and
schedule information within the Process module itself, you are limited by the terminology
associated with SIMAN when specifying property information, as the operands are
property-type operands and must feed directly into a SIMAN element field to be “global.”

181
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

For example, if asking a user in a dialog for the schedule rule for a resource schedule, you
must specify the keywords Wait/Ignore/Preempt if the field is a property-type operand in a
module that can be placed multiple times (such as a Process-type module). If an “alias” is
used (refer to “The Dialog Design Window” for information on the use of aliases), the
field can no longer be a property operand accessible from multiple modules.

Displaying element lists

The use of elements also gives the advantage of displaying lists to modelers (as described
previously). These lists are classified by element type (e.g., resources, queues, stations) so
that a modeler is presented with a list of elements that is constrained to the appropriate
type based on the operand’s use in the module. For example, if you add a ComboBox
control to a modules’s dialog design and then define that operand as an element operand,
the drop-down list of the operand will show all of the elements that have been added to the
model (of the type of element defined by the operand).
A basic or property operand that is a ComboBox control also may present a list of
elements. (Refer to “The Dialog Design Window” for descriptions of the user interface
controls that may be added to module dialogs.) In this case, the drop-down list displays
the elements that have been created in the model so that a modeler may select from those
elements already defined. However, if a new entry is made in a basic or property operand,
this new value is not added to the list of elements.
For example, in the Match module from the SIMAN blocks panel, the Match Expression
field displays a list of attributes. However, if a modeler enters a value, such as PalletSize,
in the Quantity field that does not match the attributes that already have been defined, a
new attribute element is not created. This is because the Match Expression field actually
accepts any type of expression value; however, it is common to use an attribute for this
field.
The display of element lists in non-element operands often is useful when the data type of
the operand is expression (to allow mathematical operators, etc.), but where a particular
element type often will be used. In the template reference guides, we list the element type
in parentheses if the list is for display only or in square brackets if the operand defines an
element.
As the template designer, you may create sub-lists to further restrict the scope of the
element list provided to a modeler. For example, if you have an operand that defines a
resource, you can identify a sub-list associated with that operand; e.g., Operators. When a
modeler defines a new element (by typing a name into the resource field), the element is
added to the Operators sub-list. Other modules in your template (or in other templates)
might also display the Operators sub-list of resource elements. In this case, the modeler is
presented with a list of only those resources elements that have been specified as

182
 • • • • •
10 • ELEMENTS

Operators. Other resource sub-lists, such as Supervisors, CNC Machines, and Setup
Operators could exist to collect additional classifications of resource elements.
The sub-lists information in “Element operands” on page 183 provides additional
information about element lists. These lists can result in much more rapid model building
for a modeler, as well as decreasing the likelihood of the modeler entering incorrect
information.

Defining elements via hierarchy

In a module definition, the most direct way to design the module so that it creates the
necessary elements when it is used in a model is through hierarchy. If you are defining a
module and you place instances of the Enter, Process, and Leave modules in your logic
window, for example, a number of elements will be created automatically in any instance
of your module, such as any resources, stations, or material-handling devices you specify.
Using this approach, you do not need to be concerned with adding information to your
module definition relative to elements. (The elements were defined automatically through
the module instances.) In fact, throughout this guide, we have provided module examples
without discussing the concept of elements.
For simple module definitions, this approach will be sufficient; the appropriate
information will be provided to define the simulation model completely (i.e., both the
logic and the elements). However, simply defining elements via hierarchy does not afford
the benefits listed in the previous section (i.e., defining element lists or access to
properties).
Note: If you display any element properties in your module’s dialog, we strongly recommend that
you use element and property operands in the dialog design, rather than hierarchy, to define the
elements.

The remainder of this chapter (with the exception of the “Switches and elements” section)
relates to using element and property operands in module definitions.

Element operands
Defining element operands
As we described in the introduction, in the module definition’s dialog design an operand
can be identified as an Element type, which indicates that the value of the operand in an
instance of the module will be used to name an element.
10 • Elements

In the dialog design window, all operand objects have a LogicProperties property
available in the window’s Design Properties grid. This property provides a dialog for
specifying characteristics of the operand related to its purpose in the module’s interface
and logic.

183
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

In the Logic Properties dialog, the operand’s Type may be specified as Element.

Figure 10.1 Logic Properties dialog for an Element operand

When the Type is specified as “Element,” the following fields are displayed:
Element Type—The type of SIMAN element that the operand will define/reference. Select
the desired type from the list. The operand's value will then be used as the name of the
element of the selected type (e.g., an operand with value “Operator” will define or
reference a SIMAN element with name “Operator”).
Sub-list—The sub-list partition of elements (by Element Type, such as resource) of which
this operand’s element is to be a member. For example, the element type Resources might
have sub-lists for Operators and Machines. Sub-lists are described in more detail in the
next section.
Define/Reference—Indicator whether the element that is created by this operand should
be defined for the simulation model or whether it only should be referenced. If Referenced
is selected, then some other module must define the element that is referenced by this
module. This typically is used when incomplete property information is definable in a
module.

184
 • • • • •
10 • ELEMENTS

Sub-lists
Sub-lists allow partitioning into subsets the element lists that are presented to a modeler.
There is a standard sub-list for each element type that is named the same as the element
(e.g., RESOURCES). Elements that are created by instances of modules from the Arena
and SIMAN templates are added to this sub-list.
Note: If the sub-list field is blank in the operand definition, any element that is created by an
instance of the module will be added to the master list of elements, which presents a list of all
elements of the particular element type (i.e., the combination of all elements defined as members
of all sub-lists).

In Figure 10.1, the sub-list in the operand’s Logic Properties dialog is specified as
“Inserters.” Thus, each time a value is entered into that operand in a module instance, a
new element (i.e., a resource) will be created and added to the Inserters sub-list of
resource elements.
By using sub-lists in your template design, you can present the various elements
represented in your template in as many different groups or classifications as you would
like. Each classification (i.e., sub-list) simply is a name associated with a particular
element list.
For example, a template containing an “Automatic Insertion” module with the operand in
Figure 10.1 might also have a module for soldering operations that defines solder
resources. Sub-lists could be created that place the Automatic Insertion resource elements
onto an Insertion sub-list and the soldering operation resource elements onto a Solder sub-
list. When a modeler wants to select an Automatic Insertion resource to perform an
operation, the drop-down list presented in the dialog would present only those resource
elements that have been defined to be inserters (i.e., have been placed on the Inserters sub-
list). The solder resources would not be displayed in the drop-down list of inserters.
Note: In any model, the sub-lists are shared across modules from different template panel files.
For example, if a module from one template adds an element to the Inserters resource sub-list,
another module from a different template also could add elements to the same sub-list.

In the dialog design window, note that if a ComboBox control is specified as a basic or
property operand, then the List property of the control can also be specified to show an
Element type and Sub-List. Those features work identically to the description of the
entries in Figure 10.1.

Defining and referencing elements

10 • Elements

If you add an element operand to a module, you can specify whether the elements created
by the operand should be placed both in the simulation model and added to the element
lists, or whether the element should only be added to the element list. This is controlled by

185
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

the Define/Reference option in the operand object’s LogicProperties property dialog (see
Figure 10.1).
If you select Define, the element is added to the simulation model (i.e., it will be written to
the SIMAN experiment file), and its name is added to the appropriate element list (in the
specified sub-list). If you indicate that the operand is only a reference to an element, the
element name is added to the element list only. In this case, the element is not yet defined
to be part of the simulation model; i.e., it will not be written to the SIMAN experiment file
until another module instance containing a Define-type of element operand with the same
value is placed.
This type of element operand, a reference operand, is used when a module contains an
operand that specifies an element, but the module does not contain the complete set of
operands to define the required properties of the element. If an element is created in a
simulation model only via reference element operands, an Undefined Identifier error will
be given if the model is checked.
The use of the Auto-Created Module Settings button within an operand’s
LogicProperties property dialog allows more flexibility in defining and referencing an
element. A data module, for example, may be created automatically using the Auto-
Created Module feature when a particular element is referenced. (Please refer to “The
Dialog Design Window” for more details.)
For example, the Advanced Transfer panel’s Leave module contains a field naming the
transporter to be requested (if you select Request Transporter as the transfer out
mechanism). If you enter a transporter name, such as Shuttle1, an element named Shuttle1
is added to the list of transporters. This will automatically create a Transporter data
module entry with the name Shuttle1, containing default information about the
transporter, including a distance set name of Shuttle1.Distance. However, because
required properties such as the transporter distance set are not part of the Leave or
Transporter module, a modeler who simply places the Leave module has not completely
defined the transporter information. In this model, the Shuttle1 transporter element has an
indicator that it is referenced only (i.e., not yet defined). To have a complete model, the
modeler would need to edit the data module that defines the Shuttle1.Distance distance
set. (Trying to run the model without doing so will give an Error window, specifying
“This module has not been edited,” where you may click the Find button that will take
you to the Distance data module.)

186
 • • • • •
10 • ELEMENTS

Property operands
Defining Property operands
In the dialog design window of a module definition, in the LogicProperties property of an
operand object, the operand’s Type may also be specified as Property.

Figure 10.2 Logic Properties dialog for Property operand

When the Type is specified as “Property,” then the following fields are displayed in the
Logic Properties dialog:
Element Operand—Name of the operand that is defining the SIMAN element in this
module of which this property operand is associated. In Figure 10.2, an element operand
named “Inserter ID” has been added to the dialog design. This operand is defining a
RESOURCES element. We are now defining a property operand pointing to a property of
that resource.
Element Type—Type of SIMAN element defined/referenced by the Element Operand.
This field may not be edited; it is provided for information only.
Property Name—Name of the element property to which this operand is pointing, selected 10 • Elements
from a list of valid properties associated with the Element Type. (Refer to the tables in
Appendix B for a listing of the property types that are defined for each type of element.)
In the example in Figure 10.2, we select the “Integer or Sched ID” property, which defines
the (integer) capacity value for a fixed-capacity resource or the name of the schedule for a
resource whose capacity type is Schedule.

187
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Read Only—This option is only available if the operand is a HiddenOperand control in

the dialog design. If enabled, the hidden operand will simply read into its value the current
value of the element property with which it is associated. The element’s property value
will NOT be overwritten by the operand’s Value property. The default value defined for
the hidden operand will only be written to the element’s property value if that property has
yet to be defined (i.e., the current value of the property is null).
Note that the Read Only feature may be used to allow modules to communicate indirectly.
For example, a “master” module may define an option to “Collect Statistics,” which
would be written as a property of a named element. All other “subordinate” modules
could have hidden operands referring to the named element and its property, but the
hidden property operands in the “subordinate” modules would have the Read Only option
checked. Other operands that collect various types of statistics in the “subordinate”
modules may be switched in or out depending on the value of the hidden property
operand. In this way, editing the “master” module would affect the other modules, giving
you a type of “Global Operand” capability.

Defining repeating properties

Some elements contain properties whose values are repeatable, such as initial positions of
the transporter units defined by a Transporters element or the list of failures for a
Resource element.
In the module definition’s dialog design, a repeat group object (RepeatGroupDialog or
RepeatGroupTable control) can be specified to be a property repeat group. When you
define a property repeat group, you are indicating that a repeating set of values will be
written by one or more property operands contained in the repeat group. (Refer to the
chapter “The Dialog Design Window” for a more information on using repeat groups in
the module’s dialog design.)
Similar to operand objects, a repeat group’s LogicProperties property specifies whether
the repeat group is pointing to an element’s repeatable property. Figure 10.3 shows the
Logic Properties dialog for a property repeat group object. In that example, the repeat
group is pointing to the Failures property of a RESOURCES element (the resource is
being defined by an Inserter ID element operand).

188
 • • • • •
10 • ELEMENTS

Figure 10.3 Logic Properties dialog for a Property repeat group

If the repeat group’s Type is specified as “Property,” then the following fields are
displayed in the Logic Properties dialog:
Element Operand—As is the case in the definition of property operands, this entry
specifies the name of the operand that is defining the SIMAN element in this module of
which this property repeat group is associated.
Element Type—Type of SIMAN element defined/referenced by the Element Operand.
This field may not be edited; it is provided for information only.
Property Name—Name of the element property that this repeat group defines, selected
from a list of valid repeatable properties associated with the Element Type.
Note: In the dialog design, when you define a repeat group to be a property, all operands and
repeat groups that are contained within the repeat group must be property or element operands.

10 • Elements

189
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

To further illustrate the use of property repeat groups, suppose we have designed an
Automatic Insertion module with a dialog design as shown in Figure 10.4 below.

Figure 10.4 Operand Explorer view of dialog design for Automatic Insertion module

First, the Automatic Insertion module contains a repeat group object named “Inserter
Failures.” This repeat group has been specified as a property repeat group, and it points to
the Failures property of a resource element defined by the operand named “Inserter ID”
(see Figure 10.3).
In the Automatic Insertion module, we can now define one or more failures for the
insertion resource. There are three property operands in the failures repeat group (see the
Tables appendix for this list): the Failure keyword, the name of the failure, and the entity
rule (Ignore, Wait, or Preempt).
For the definition of the Automatic Insertion module, we have added two property
operands to the Inserter Failures repeat group. First, a hidden Failure Keyword operand is
used to provide the FAILURE keyword for a failure entry. The LogicProperties property
dialog for this operand is shown in Figure 10.5.

190
 • • • • •
10 • ELEMENTS

Figure 10.5 Logic Properties dialog for hidden Failure Keyword operand

Second, for the name of the failure, we add an operand (Failure Class) to the repeat group
and indicate that it is the Failure ID property of the resource, as shown in Figure 10.6.

10 • Elements

Figure 10.6 Logic Properties dialog for Failure Class property operand

191
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

We can choose whether to add a third property operand to the module that specifies the
failure entity rule. For this example, we will not do so, in which case the property of the
resource is given the default value, Ignore.

Defining an element/property using a hidden operand

In the Automatic Insertion example, the Failure Class operand identifies the name of a
failure that is a property of a resource. However, it does not create the failure element or
define any of the properties of the failure (i.e., the type of failure, its duration, etc.).
We can change the module so that it both defines the robot resource element and fully
defines the associated failure elements. Figure 10.7 shows an updated dialog design for
the module.

Figure 10.7 Operand Explorer view of dialog design for enhanced Automatic Insertion module

First, we will need to add an element operand that defines the failure element. We also
will need to add the property operands for the failure element information.
To define the failure element, we add a hidden operand to the Inserter Failures repeat
group. This element operand defines an element of type Failures. We use an operand
reference (`Failure Class`) to provide the default value of this element operand. This
ensures that the failure element that is created is named correctly based on the failure
property of the resource.

192
 • • • • •
10 • ELEMENTS

Figure 10.8 shows the design properties of the hidden operand named “Failure_Element.”

Figure 10.8 Design properties of hidden element operand to define Failures element

By presenting the property operand in the module dialog, we ensure that if another
module instance changes the failures associated with an automatic insertion resource, the
Automatic Insertion module instance will be updated to reflect the changed values. (This
is because property values are stored globally in the simulation model, as described
previously.) The hidden Failure_Element operand ensures that the failure element also is
defined in the simulation model and provides an element operand that the failure
properties can reference.
10 • Elements

In this example, we will be defining the failure information for the specified failure within
the Automatic Insertion module. In this case, we use the Define (instead of Reference) for
the element Failure (as seen above in Figure 10.8). If the Automatic Insertion module
simply specified the failure name and a separate Failures data module defined the

193
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

characteristics of the failure, this module would still contain the above hidden operand (so
the failure name is on the list of Failures); however, the element would simply have a
reference to it, instead of defining it.
To define the failure properties, three additional property operands are added to the
Inserter Failures repeat group, corresponding to the three required properties of a failure
element: Failure Type, Time or Count Between, and Duration. Figure 10.9 shows the
operand dialog for the first of these, the Failure Type. In its definition, it is specified to be
a property type of operand; it is a property of the element named by operand
Failure_Element; and it is the Type property of the failure element. The remaining two
operands (Count or Time Between and Time to Repair) are defined similarly, with the
appropriate selection of the property type (Time or Count Between and Duration,
respectively).

Figure 10.9 Logic Properties dialog of Failure type property operand

194
 • • • • •
10 • ELEMENTS

In Figure 10.10 we show a sample instance of the Automatic Insertion module. This
instance defines an insertion resource named DIP_Line A following the Two Shifts
schedule. The resource has two associated failures: Out of Tolerance (whose repeat group
dialog is opened in the figure) and Preventive Maintenance.

Figure 10.10 Automatic Insertion example module instance

Switches and elements

Switches may be attached to element operands in the dialog design by specifying the
SwitchName property in the object’s design properties. Or, you may select the object and
use the Object > Switch > Attach menu item to attach a switch and select the switch from
the list that is presented in the Attach Switch dialog. (Refer to the chapter “The Dialog
Design Window” for more information.)
When a module that includes element operands with switches is used in a simulation
model, the behavior of switches as they relate to the appearance of the module dialog also
is the same as occurs for basic operands. If the operand’s attached switch condition
evaluates to True, the operand is displayed. If the switch condition is False, the operand is
not displayed. 10 • Elements

However, element operands have the additional feature of creating elements—adding

them to lists, and if the element operand reference type is Define, defining the element in
the simulation model. Because more than one module instance in a model may have an
element operand that accesses the same element, there is the potential that the same

195
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

element’s defining operand might be “switched in” in some module instances and
“switched out” in others.
In the case of such a conflict, Arena retains the element on the element list as long as any
operand that creates the element is not switched out (i.e., either has no attached switch
or a true switch). The same rule applies to properties of an element.
Note: If an element operand has an attached switch in a module definition, all property operands
that define properties of that element also should be switched to ensure that there is no condition
under which the element could be switched out and one or more properties switched in.

For example, the Record module contains an operand, Counter Name, that is an element
operand defining a Counters element. This operand is switched in or out in a module
instance based on the selection for the type (Counter, Entity Statistics, Time Interval,
Between, or Expression). If one Record module instance has a type of Count and names
the counter Items Completed, the Items Completed counter is created. Another Record
module instance might be placed in the model that also counts in the Items Completed
counter. If the first Record module was edited and the type changed to Entity Statistics,
the Items Completed operand is switched out in that module instance. However, because
the Items Completed counter still is switched in (i.e., in the second Record module
instance), it still exists in the simulation model. If the second Record module is deleted (or
its type changed to something other than Count), the Items Completed counter is removed
from the element list since no module has a switched in reference to it.

Special element types

The types of model elements that may be referenced in a template include each of the
types of elements defined in the SIMAN experiment. (Refer to online help for complete
documentation on the SIMAN experiment and the Elements panel.) We provide three
additional classifications of elements in Arena to address special circumstances you may
face in designing templates. These element classifications are described in the following
sections. Refer to the “Tables” appendix for a complete list of these additional element
types and their properties.

Fixed-length elements
Many of the element types in Arena have one or more properties that may have a
repeating set of values, such as the initial values for a variable or the failures associated
with a resource (as illustrated earlier in this chapter). Templates can be designed to
provide values to these repeating properties by placing a property repeat group and the
appropriate property operands in a module definition.
In some cases, you might want to design a module that places a value at a specific index in
the repeating operand. For example, you might establish that the first value in a recipe is
the resource name to be used at a given job step, the second value is the processing time,

196
 • • • • •
10 • ELEMENTS

and the third value is the yield for a given job type. If you wanted to display this
information as non-repeating operands in a dialog, you would not be able to use property
operands (because the recipe element specifies that the values are in a repeat group).
We have added element types that mirror each of the elements containing repeating
values. These additional element types are referred to as fixed-length elements. These
fixed-length elements contain a predefined set of values for the repeating property; they
are named using the prefix Fixed_. For example, the Fixed_REC50 element has 50
assignment properties followed by a repeating assignment property; the standard
RECIPES element contains only the repeat group for assignments.
Additional fixed-length elements contain a predefined number of repeating properties
within the repeat group. These elements are named using the prefix Fixed_ and a suffix R.
These elements allow you to define a one- or two-dimensional array where each row in
the array is an individual tuple. For example, the Fixed_VAR10R element has 10
predefined initial value properties per repeat group.
You utilize the fixed-length elements exactly as you use the standard elements, by
defining element operands to create elements and property operands to define the values
of the element’s properties. Fixed-length elements are generated along with standard
elements at model generation.
Note: The element lists and sub-lists are separate from one another, even for related element
types (e.g., Fixed_REC50 and RECIPES elements).

Hidden element list

You may find a circumstance where you want to provide a modeler with a drop-down list
of values, but you do not want these values to be written to the SIMAN experiment file.
We have added an element type, referred to as the hidden element, that allows you to
define an element list but that will not be used to generate the simulation model.
The hidden element functions like a standard element but doesn’t directly write its values
to the SIMAN experiment file. In the LogicProperties property dialog, an operand that is
type element can be defined as a hidden element type by selecting Hidden from the list of
available element types. This option appears at the end of the list of element types. There
are no properties associated with the hidden element type.
An example of using a hidden list is as follows. In the Arena template modules (Basic
Process, Advanced Process, and Advanced Transfer), each module you place is given a
name, based on the module type. For example, if you place the Create, Process, then
10 • Elements

Dispose module, they are named automatically Create 1, Process 1, and Dispose 1. You
may edit those modules and change the module name, which changes the module handle
you see in the user view. Each of the name fields has a drop-down list, which is a list of all
module names in the model. These are not written to any SIMAN element, as they are

197
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

simply there for the user’s benefit for identifying the module. Figure 10.11 shows the
Name operand’s design properties in the Create module definition.

Figure 10.11 Dialog design properties of the Name operand in the Create module

The hidden element can also be used with repeat group properties. As previously
discussed, all operands contained in a repeat group property must be defined as an
element or property operand. The hidden element can be used when you have an operand
that doesn’t define an element or a property but is contained within a repeat group
property.

Inverted elements
Inverted elements are used when you want to design a module that allows the modeler to
create a single repeat group tuple for each instance of a module. For example, you may
want an individual module to define a member of a set of resources without having to
define all of the members of the resource set in a single module. There are five available

198
 • • • • •
10 • ELEMENTS

inverted elements: Inv_DISTANCES for creating a distances element, Inv_LINKS for

creating a networks element, Inv_SEGMENTS for creating a segments element, Inv_SETS
for creating a sets element, and Inv_Statesets for creating a set of states for resources.
The difference between an inverted element and a standard element relates to how the
elements and properties are defined. For example, the standard Segments element defines
a segment name. Its properties are beginning station, next station, and length. The
Inv_SETS element defines an element whose default value is used internally. This
element’s properties are beginning station, next station, length, and segment set name. The
Inv_SEGMENTS element value must be unique and is usually created as a combination
of visible operand values (explained in the following example).
A module that uses an inverted element combines visible standard elements with hidden
inverted elements. At model generation, all instances of a module that use
Inv_SEGMENTS and have the same segment set name property value are converted and
sorted to create a valid standard segments element.
For example, suppose the template design is to include a Segment module whereby users
can define the animation of a conveyor while defining the segment set, using the
Inv_SEGMENTS element. Figure 10.12 shows an Animated Segment module’s dialog.

Figure 10.12 Dialog box for Animated Segment module

10 • Elements

199
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Figure 10.13 shows the Operand Explorer view of the module’s dialog design.

Figure 10.13 Operand Explorer view of dialog design of Animated Segment module

This module’s dialog design consists of four hidden operands (Name, BegN, EndN, and
SetN) and four visible operands (Beg, End, Set, and Length). The Name operand is
defined as the inverted element Inv_SEGMENTS and its properties are BegN (property
name Beginning Station), EndN (property name Next Station), SetN (property name
Segment Set ID), and Length (property name Length).

200
 • • • • •
10 • ELEMENTS

The Name operand’s design properties are shown in Figure 10.14.

Figure 10.14 Design properties of Name operand

In Figure 10.14, see that the default value for the operand is `Beg``End``Set.` This
provides the operand with a unique default value. The operands Beg and End are visible
element type operands that define standard station elements. They correspond with the
Beginning and Ending Station drop-down fields in the Segment module’s dialog. The Set
operand is a visible element-type operand that defines a standard Segments element.
10 • Elements

201
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

The BegN and EndN property operand’s default values reference the Beg and End
operand values, respectively. Figure 10.15 shows the operand BegN’s design properties.

Figure 10.15 Design properties of BegN operand

The SetN operand is also a hidden property whose default value references the Set
operand value.
When a module is designed in this manner, each instance of the module creates one tuple
of the segments element. Arena correctly saves and sorts all instances of the module so
that the beginning and ending stations are in the correct order. The other two material-
handling inverted elements (Inv_LINKS and Inv_DISTANCES) are used in the same
fashion.
The Inv_SETS element and Inv_Statesets elements are slightly different. The Inv_SETS
and Inv_STATESETS elements are the opposite of the standard sets and statesets
elements. The standard sets and statesets elements defines a set name, and its properties

202
 • • • • •
10 • ELEMENTS

are set members. The Inv_SETS and Inv_Statesets elements defines a set member as the
element value and this element’s property is the set name. At model generation, all
instances of Inv_SETS with the same set name property value are combined into a
standard sets element. Likewise, all instances of Inv_STATESETS with the same stateset
name property value are combined into a standard statesets element. This approach allows
you the flexibility to define individual set members from different modules.
Currently, the Arena and SIMAN templates do not use any of the inverted element types.

10 • Elements

203
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

204
A Template Design Guidelines

A • Template Design
Guidelines
While there is no single best way to build a module or template, careful and consistent
design can make a template much easier to use and maintain. This is especially important
if you will be distributing your work to others within or outside your organization. The
following list of guidelines and hints may be helpful in providing the best simulation
environment for you and/or others.

Dialog box design (dialog design window)

Dialogs
„ Plan ahead. Try to create a picture of the dialog boxes for the modules in your
template panel and lay out the information in some consistent format.
„ Use Line and GroupBox controls to group related information within a dialog.
„ Use secondary dialog boxes instead of a single large dialog.
„ Secondary dialogs generally should not contain required operands unless they are
switched “On” by the user.
„ Within a template panel, use consistent designs in the modeler’s interaction with
dialog boxes. If keyboard tabbing order typically moves vertically among operands,
try to avoid cases where the tab key moves to an operand located to the left or right.
„ Try to design the dialog box so that there is some amount of symmetry, but avoid large
empty spaces.

Operand objects
„ Prompt text should be concise; when abbreviations are used, be very clear what term
is abbreviated.
„ TextBox and ComboBox controls should have non-blank prompts unless nearby
operands or static text clearly point out the meaning of the text/combo operand.
„ If the options of a RadioButtonGroup control have a clear meaning, a prompt label is
optional. However, if there is any possibility of ambiguity or misunderstanding,
provide a prompt label.
„ Prompts should be clear and contain a minimum of SIMAN jargon.
„ If an operand is referenced by a required field of a module in the logic window, it
should also be required in the module’s dialog design.

205
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

„ The data type of an operand should be the same as or more restrictive than the data
type of any field that references it (in a module instance in the logic window).
„ Use switches to enable/disable controls so non-applicable fields will not be displayed.
„ Try not to place ComboBox controls near the bottom of a tall dialog. Arena drops the
list down and displays it above the box if the box would be displayed off the screen.
While this allows a modeler to see the entire list you have defined, it is not as
convenient as a box that drops down below the edit box.
„ RadioButtonGroup control vs. ComboBox control
„ Use a radio button group if there is ample room in the dialog or if the choice is
very important.
„ Use a combo box if the field is not changed often or if room is limited.
„ CheckBox control vs. RadioButtonGroup control
„ Use check box only if the meaning of the choice (Checked/Unchecked) is very
clear.
„ Use radio button group if you want to limit the user to the defined entries only.

Helpful hints for defining objects in the dialog design window

„ Use meaningful operand names. These will be used for default prompts and for
column headings with Module Data Import/Export.

General
„ Module entry and exit points should not be hidden so that the module can be used in
the definition of another module (i.e., a Label/Next Label operand should appear in
the module dialog box so that a reference may be entered when the module is placed
in another module definition’s logic window).
„ Utilize the Auto-Created Module functionality to create “data” modules from “logic”
modules automatically.

Panel icon
„ Retain the text label of the icon and use the same font type and size for all modules.
„ Be consistent within a template with use of color and style.
„ Keep the icon simple.
„ Use similar design types for panel icons; avoid mixing 2-D and 3-D panel icons.

206
 • • • • •
A • TEMPLATE DESIGN GUIDELINES

„ If the module has a resource in the user view, try to represent the module in the panel

A • Template Design
icon by drawing a simplified version of the resource’s idle or busy picture.

Guidelines
„ If modules are related to others, the icons can represent that relationship.
„ Present “logic” modules together and “data” modules together in a template panel (as
is done in the Arena template’s Basic Process, Advanced Process and Advanced
Transfer panels). Place the more important grouping at the top of the panel.

User view
„ Place the module handle at the bottom of the user view. Consider using an operand
(such as the module name) as the module handle text.
„ Static background that should not appear during a simulation run should be drawn on
the hidden layer.
„ Operands in user view should be kept to a minimum to avoid clutter in model
windows.
„ Do not group animation objects in the user view; although the objects may still be
edited, the individual identifiers do not appear when you select a grouped object.
„ All animation objects should reference operands of the module in the
expression/identifier entry (since this value is not changeable by the modeler in a
module instance).
„ Attach switches to animation objects that correspond to other module items that might
be switched out.

Module logic
„ Use Draw objects and Named Views in the logic window to identify various parts of
the module logic.
„ Verify module logic first in a model window so that you can interact with the model
and view a detailed animation. Then use Arena’s clipboard to transfer the logic into a
module definition’s logic window and add the appropriate operand references and/or
switches.
„ Base your modules on SIMAN Blocks and Elements. This allows you to then define
elements either through the logic window or the dialog design window.

207
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Naming conventions
„ When a module contains a station designation, the station name should be supplied by
the user. Other operands may be given default names based on the station name with a
suffix.
„ Using the following suffixes will provide improved consistency and help prevent
multiple use of the same name:
`Station Name`_R - Resources
`Station Name`_Q - Queues
`Station Name`_S - Storages
`Station Name`_C - Counters
`Station Name`_Ta - Tallies
„ Supply a standard prefix to your template panel files if you create and share multiple
files.
„ If you build modules that have similar names to modules in other templates, use a
prefix in the module’s main dialog title (e.g., AGV_Transport) to distinguish it from
the other modules that perform a similar activity.

Template documentation
We encourage you to provide documentation of templates for your own use or for others;
it is particularly useful to provide helpful information that may be accessed from within
the software. This can be done in several ways.
„ Use static text (Text control) to provide a brief description in a dialog.
„ Provide a text file (e.g., tplname.txt) that describes each module in your template
panel.
With the assistance of a help authoring tool, create and “connect” true online help to your
template. This is explained in detail in Appendix C.

Trace
Although low-level trace is automatically available on all SIMAN blocks, this is often not
useful to a less experienced modeler. The TRACE block can be used in a module
definition to provide supplemental, module-specific trace. Some guidelines regarding the
design of trace information for your modules follow.
„ Because the entity number and module identifier are automatically generated during
the simulation run (providing a header for each new trace message), this information
need not be included in a module trace.

208
 • • • • •
A • TEMPLATE DESIGN GUIDELINES

„ To distinguish the messages you generate from module headers and low-level trace,

A • Template Design
we recommend that each message start with a hyphen in column 1 (e.g., “-Waiting for
teller\n”).

Guidelines
„ Since it is not always possible to evaluate every expression accurately, it is most
consistent to write the expression itself (within the format) instead of writing it as an
argument.
„ Use the STR keyword to write symbol names instead of numbers (e.g., a resource
name).

Statistics and reports

Although the animation is the most visible part of model building, it is often the statistics
upon which most decisions are made.
„ Provide optional statistics on most items in which a modeler is likely to have an
interest.
„ To avoid complexity and confusion, set the default statistics to be collected only on
key items.
„ The most basic (and default) level of statistics should appear in the standard summary
report.
„ The Reports Element can be used to categorize statistics by module or other logical
grouping.
„ The Reportlines Element can be used to generate a professional, completely
customized report by module or other logical grouping.
„ Use the STR keyword to write symbol names instead of numbers (like a resource).

209
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

210
B Tables
Elements and properties

Standard elements
Listed below are the standard (SIMAN) elements and properties that are available for
module building. For more information on a particular element, refer to online help.
Note: Those properties that are repeat group properties are denoted with an (R). Their included
operands are indented following the repeat group name.

B • Tables
ACTIVITYAREAS Element Properties

Organization Level
Parent Activity Area
Auto Stats Generate
Auto States Category
Auto States Identifier

ARRIVALS Element Properties

Type
Type ID
Time
Interval or Key
Offset
Max Batches
Max Time
Batch Size
Assignments (R)
. Variable ID
. Value

211
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

ATTRIBUTES Element Properties

Number
1-D Array Index
2-D Array Index
Data Type
Initial Values (R)
. Value

BEGIN Element Properties

Listing
Run Controller

BLOCKAGES Element Properties

Number
Initial Blockages
Global Priority
Priority Expression

CONTINUOUS Element Properties

Number of Dif Eq
Number of State Eq
Minimum Step Size
Maximum Step Size
Save Point Interval
Method
Absolute Error
Relative Error
Severity

212
 • • • • •
B • TABLES

CONTINUOUS Element Properties

Cross Severity

B • Tables

213
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

CONVEYORS Element Properties

Number
Segment Set ID
Velocity
Cell Length
Status
Max Cells per Entity
Type
Accumulation Length
Auto Stats Generate
Auto Stats Category
Auto Stats Identifier

COUNTERS Element Properties

Number
Limit
Initial Option
Output File
Report ID
Data Type
Category
Process ID

214
 • • • • •
B • TABLES

CSTATS Element Properties

Number
Name
Output File
Report ID
Data Type
Category
Process ID

B • Tables
DISCRETE Element Properties

Max Number of Entities

Number of Attributes
Largest Queue Number
Largest Station Number
Animation Attribute

DISTANCES Element Properties

Station (R)
. Beginning Station ID
. Ending Station ID
. Distance

DISTRIBUTIONS Element Properties

Dist Number
Dist Index1
Dist Index2
Dist Values (R)
. Values

215
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

DSTATS Element Properties

Number
Name
Output File
Report ID
Data Type
Category
Process ID

ENTITIES Element Properties

Number
Initial Picture
Intial Holding Cost Rate
Initial VA Cost
Initial NVA Cost
Initial Wait Cost
Initial Tran Cost
Initial Other Costs
Auto Stats Generate
Auto Stats Category
Auto Stats Identifier

EVENTS Element Properties

Crossing Variable
Crossing Direction
Threshold Value
Crossing Tolerance

216
 • • • • •
B • TABLES

EXPRESSIONS Element Properties

Number
1-D Array Index
2-D Array Index
Data Type
Expression Values (R)
. Expression
I/O Point

B • Tables
Usage
Description

FAILURES Element Properties

Number
Type
Time or Count Between
Duration
State

FILES Element Properties

Number
System Name
Access Type
Access Length
Structure
End of File Action
Comment Character
Initialize Option
Recordset Name
Recordset CommandText

217
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

FILES Element Properties

Recordset CommandType

FREQUENCIES Element Properties

Number
Type
Name
Output File
Report ID
Data Type
Data Category
Process ID
Categories (R)
. Value or Range
. Value
. High Value
. Category
. Category Option

INCLUDE Element Properties

File Description

INITIALIZE Element Properties

Value

INTERSECTIONS Element Properties

Number
Travel Length
Link Selection Rule
Rule Attribute ID

218
 • • • • •
B • TABLES

INTERSECTIONS Element Properties

Velocity Change Factor

LEVELS Element Properties

Number
1-D Array Index
2-D Array Index
Initial Values (R)

B • Tables
. Value

LINKS Element Properties

Number
Beginning Intersection ID
Beginning Direction
Ending Intersection ID
Ending Direction
Number of Zones
Length of Each Zone
Link Type
Velocity Change Factor

NETWORKS Element Properties

Number
Links (R)
. Starting Link
. Ending Link

NICKNAMES Element Properties

Name or Constant

219
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

OUTPUTS Element Properties

Number
Output File
Name
Report ID
Data Type
Category
Process ID

PARAMETERS Element Properties

Number
Values (R)
. Value

PICTURES Element Properties

Number

PROJECT Element Properties

Title
Analyst Name
Month
Day
Year
Summary Report
Costing
Entities
Resources
Queues

220
 • • • • •
B • TABLES

PROJECT Element Properties

Transporters
Conveyors
Processes
Stations
ActivityAreas
Tanks

B • Tables
QUEUES Element Properties

Number
Ranking Criterion
Rule Expression
Associated Block/SHARED
Auto Stats Generate
Auto Stats Category
Auto Stats Identifier

RANKINGS Element Properties

Ranking Criterion
Ranking Expression

RATES Element Properties

Number
1-D Array Index
2-D Array Index
Initial Values (R)
. Value

221
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

RECIPES Element Properties

Statics (R)
. Static Name
. Value

REDIRECTS Element Properties

Number
Network ID
Intersections (R)
. Beginning Intersection ID
. Ending Intersection ID
. Next Intersection ID

REPLICATE Element Properties

Number of Replications
Beginning Time
Replication Length
Initialize System
Initialize Statistics
Warmup Period
Terminating Condition
DLL Name
Hours per Day
Base Time Units
Execute Mode
Realtime Mode
Realtime Factor
Simulation Start Date Time
Include Fractional RC Units

222
 • • • • •
B • TABLES

REPORTLINES Element Properties

Number
Report ID
Format
Expressions (R)
. Expression

REPORTS Element Properties

B • Tables
Number
System Name
Title
Heading
Sort
Format

RESOURCES Element Properties

Number
Capacity or Schedule
Integer or Sched ID
Capacity Entity Rule
Stateset ID
Initial State
Resource Type
Map ID
Velocity
Initial Position
Position ID
Zone
Busy Cost

223
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

RESOURCES Element Properties

Idle Cost
Usage Cost
Category Type
Failures (R)
. Failure
. Failure ID
. Failure Entity Rule
Auto Stats Generate
Auto Stats Category
Auto Stats Identifier
Base Efficiency
Efficiency Schedule ID

RULES Element Properties

Selection Rule
Rule Expression

SCHEDULES Element Properties

Schedule Type
Format Type
Scale Factor
Time Units
Values (R)
. Value
. Duration

SEEDS Element Properties

Seed Value
Initialize Option

224
 • • • • •
B • TABLES

SEGMENTS Element Properties

Beginning Station
Next Stations (R)
. Next Station
. Length

SENSORS Element Properties

Number

B • Tables
Tank Name
Location Type
Location
Crossing Direction
Block Label
Initial State

SEQUENCES Element Properties

Number
Stations (R)
. Station ID
. Assignments (R)
. . . Variable
. . . Value

SETS Element Properties

Number
Members (R)
. Member

225
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

STATESETS Element Properties

Number
States (R)
. State Name
. Stateset Type

STATICS Element Properties

Default Value

STATIONS Element Properties

Number
Intersection ID
Recipe ID
Parent Activity Area
Auto Stats Generate
Auto Stats Category
Auto Stats Identifier

STORAGES Element Properties

Number

TABLES Element Properties

Number
Low Value
Fixed Increment
Dependent Values (R)
. Dependent Value

226
 • • • • •
B • TABLES

TALLIES Element Properties

Number
Output File
Report ID
Data Type
Category
Process ID

B • Tables
TANKS Element Properties

Number
Capacity
Initial Level
Input Variable Name
Output Variable Name
Report Statistics
Category
Identifier
Regulator Name
Maximum Rate
Time Units

TASKS Element Properties

Task Number
Exec Expr
Format
Parameter

227
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

TRACE Element Properties

Beginning Time
Ending Time
Condition
Expressions (R)
. Expression

TRANSPORTERS Element Properties

Number
Number of Units
System Map Type
Map ID
Control
Velocity
Acceleration
Deceleration
Turning Velocity
Unit Data (R)
. Initial Position
. Position ID
. Zone
. Initial Status
. Vehicle Size
. Size Integer
Auto Stats Generate
Auto Stats Category
Auto Stats Identifier

228
 • • • • •
B • TABLES

VARIABLES Element Properties

Number
1-D Array Index
2-D Array Index
Data Type
Clear Option
Category Type
Response Category Type

B • Tables
Initial Values (R)
. Value
I/O Point
Usage
Description

Inverted elements
Listed below are the inverted elements and their properties as described in the “Elements”
chapter.

Inv_DISTANCES Element Properties

Beginning Station ID
Ending Station ID
Distance
Distance Set ID

Inv_LINKS Element Properties

Number
Beginning Intersection ID
Beginning Direction
Ending Intersection ID

229
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Inv_LINKS Element Properties

Ending Direction
Number of Zones
Length of Each Zone
Link Type
Velocity Change Factor
Network ID

Inv_SEGMENTS Element Properties

Beginning Station
Next Station
Length
Segment Set ID

Inv_SETS Element Properties

Set Name

Inv_STATESETS Element Properties

Properties
Stateset Type
State Set ID

230
 • • • • •
B • TABLES

Fixed-length elements
Listed below are the fixed-length elements and their properties as described in the
“Elements” chapter. The standard element associated with the fixed-length element is
presented next to the element name in parentheses. The repeatable properties are denoted
with an (R).

Fixed_ARR5 Element
(Arrivals) Properties

Type

B • Tables
Type ID
Time
Interval or Key
Offset
Max Batches
Max Time
Batch Size
Variable ID 1
Value 1
Variable ID 2
Value 2
Variable ID 3
Value 3
Variable ID 4
Value 4
Variable ID 5
Value 5
Assignments (R)
. Variable ID
. Value

231
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Fixed_ARR50 Element
(Arrivals) Properties

Type
Type ID
Time
Interval or Key
Offset
Max Batches
Max Time
Batch Size
Variable ID 1
Value 1
Variable ID 2
Value 2
••••
Variable ID 50
Value 50
Assignments (R)
. Variable ID
. Value

Fixed_ATT10R Element
(Attributes) Properties

Number
1-D Array Index
2-D Array Index
Data Type

232
 • • • • •
B • TABLES

Fixed_ATT10R Element
(Attributes) Properties

Initial Values (R)

. Value 1
. Value 2
.••••
. Value 10

Fixed_ATT50 Element
(Attributes) Properties

B • Tables
Number
1-D Array Index
2-D Array Index
Data Type
Value 1
Value 2
••••
Value 50
Initial Values (R)
. Value

Fixed_EXP2R Element
(Expressions) Properties

Number
1-D Array Index
2-D Array Index
Data Type
Expression Values (R)
. Expression 1
. Expression 2
I/O Point
Usage

233
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Fixed_EXP2R Element
(Expressions) Properties

Description

Fixed_EXP3R Element
(Expressions) Properties

Number
1-D Array Index
2-D Array Index
Data Type
Expression Values (R)
. Expression 1
. Expression 2
. Expression 3
I/O Point
Usage
Description

Fixed_EXP4R Element
(Expressions) Properties

Number
1-D Array Index
2-D Array Index
Data Type
Expression Values (R)
. Expression 1
. Expression 2
. Expression 3
. Expression 4
I/O Point
Usage
Description

234
 • • • • •
B • TABLES

Fixed_EXP7R Element
(Expressions) Properties

Number
1-D Array Index
2-D Array Index
Data Type
Expression Values (R)
. Expression 1
. Expression 2

B • Tables
.••••
. Expression 7
I/O Point
Usage
Description

Fixed_EXP30R Element
(Expressions) Properties

Number
1-D Array Index
2-D Array Index
Data Type
Expression Values (R)
. Expression 1
. Expression 2
.••••
. Expression 30
I/O Point
Usage
Description

235
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Fixed_EXP5 Element
(Expressions) Properties

Number
1-D Array Index
2-D Array Index
Data Type
Expression 1
Expression 2
••••
Expression 5
Expressions (R)
. Expression
I/O Point
Usage
Description

Fixed_EXP10 Element
(Expressions) Properties

Number
1-D Array Index
2-D Array Index
Data Type
Expression 1
Expression 2
••••
Expression 10
Expressions (R)
. Expression
I/O Point
Usage

236
 • • • • •
B • TABLES

Fixed_EXP10 Element
(Expressions) Properties

Description

B • Tables

237
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Fixed_EXP10R Element
(Expressions) Properties

Number
1-D Array Index
2-D Array Index
Data Type
Expression Values (R)
. Expression 1
. Expression 2
.••••
. Expression 10
I/O Point
Usage
Description

Fixed_EXP15 Element
(Expressions) Properties

Number
1-D Array Index
2-D Array Index
Data Type
Expression 1
Expression 2
••••
Expression 15
Expressions (R)
. Expression
I/O Point
Usage
Description

238
 • • • • •
B • TABLES

Fixed_EXP20 Element
(Expressions) Properties

Number
1-D Array Index
2-D Array Index
Data Type
Expression 1
Expression 2

B • Tables
••••
Expression 20
Expressions (R)
. Expression
I/O Point
Usage
Description

Fixed_EXP25 Element
(Expressions) Properties

Number
1-D Array Index
2-D Array Index
Data Type
Expression 1
Expression 2
••••
Expression 25
Expressions (R)
. Expression
I/O Point
Usage

239
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Fixed_EXP25 Element
(Expressions) Properties

Description

240
 • • • • •
B • TABLES

Fixed_EXP50 Element
(Expressions) Properties

Number
1-D Array Index
2-D Array Index
Data Type
Expression 1
Expression 2

B • Tables
••••
Expression 50
Expressions (R)
. Expression
I/O Point
Usage
Description

Fixed_FRE50 Element
(Frequencies) Properties

Number
Type
Name
Output File
Report ID
Value or Range 1
Value 1
High Value 1
Category 1
Category Option 1
Value or Range 2
Value 2

241
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Fixed_FRE50 Element
(Frequencies) Properties

High Value 2
Category 2
Category Option 2
••••
Value or Range 50
Value 50
High Value 50
Category 50
Category Option 50
Categories (R)
. Value or Range
. Value
. High Value
. Category
. Category Option

Fixed_LEV10R Element
(Levels) Properties

Number
1-D Array Index
2-D Array Index
Initial Values (R)
. Value 1
. Value 2
.••••
. Value 10

242
 • • • • •
B • TABLES

Fixed_LEV50 Element
(Levels) Properties

Number
1-D Array Index
2-D Array Index
Value 1
Value 2
••••

B • Tables
Value 50
Initial Values (R)
. Value

Fixed_PAR50 Element
(Parameters) Properties

Number
1-D Array Index
2-D Array Index
Value 1
Value 2
••••
Value 50
Initial Values (R)
. Value

243
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Fixed_RAT10R Element
(Rates) Properties

Number
1-D Array Index
2-D Array Index
Initial Values (R)
. Value 1
. Value 2
.••••
. Value 10

Fixed_RAT50 Element
(Rates) Properties

Number
1-D Array Index
2-D Array Index
Value 1
Value 2
••••
Value 50
Initial Values (R)
. Value

244
 • • • • •
B • TABLES

Fixed_REC20 Element
(Recipes) Properties

Static Name 1
Value 1
Static Name 2
Value 2
••••
Static Name 20

B • Tables
Value 20
Statics (R)
. Static Name
. Value

Fixed_REC50 Element
(Recipes) Properties

Static Name 1
Value 1
Static Name 2
Value 2
••••
Static Name 50
Value 50
Statics (R)
. Static Name
. Value

245
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Fixed_RES50 Element
(Resources) Properties

Number
Capacity or Schedule
Integer or Sched ID
Capacity Entity Rule
Stateset ID
Initial State
Failure 1
Failure ID 1
Failure Entity Rule 1
Failure 2
Failure ID 2
Failure Entity Rule 2
••••
Failure 50
Failure ID 50
Failure Entity Rule 50
Failures (R)
. Failure
. Failure ID
. Failure Entity Rule

246
 • • • • •
B • TABLES

Fixed_RLN50 Element
(Reportlines) Properties

Number
Report ID
Format
Expression 1
Expression 2
••••

B • Tables
Expression 50
Expressions (R)
. Expression

Fixed_SCH50 Element
(Schedules) Properties

Resource Capacity 1
Capacity Duration 1
Resource Capacity 2
Capacity Duration 2
••••
Resource Capacity 50
Capacity Duration 50
Capacities (R)
. Resource Capacity
. Capacity Duration

247
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Fixed_SEQ3 Element
(Sequences) Properties

Number
Stations (R)
Station ID
Variable 1
Value 1
Variable 2
Value 2
Variable 3
Value 3
Assignments (R)
. Variable
. Value

Fixed_SEQ20 Element
(Sequences) Properties

Number
Stations (R)
Station ID
Variable 1
Value 1
Variable 2
Value 2
••••
Variable 20
Value 20
Assignments (R)
. Variable
. Value

248
 • • • • •
B • TABLES

Fixed_SEQ40 Element
(Sequences) Properties

Number
Stations (R)
Station ID
Variable 1
Value 1
Variable 2

B • Tables
Value 2
••••
Variable 40
Value 40
Assignments (R)
. Variable
. Value

Fixed_SEQ50 Element
(Sequences) Properties

Number
Stations (R)
Station ID
Variable 1
Value 1
Variable 2
Value 2
••••
Variable 50
Value 50
Assignments (R)
. Variable
. Value

249
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Fixed_SEQ100 Element
(Sequences) Properties

Number
Stations (R)
Station ID
Variable 1
Value 1
Variable 2
Value 2
••••
Variable 100
Value 100
Assignments (R)
Variable
Value

Fixed_SEQ250 Element
(Sequences) Properties

Number
Stations (R)
Station ID
Variable 1
Value 1
Variable 2
Value 2
••••
Variable 250
Value 250
Assignments (R)
Variable
Value

250
 • • • • •
B • TABLES

Fixed_SET50 Element
(Sets) Properties

Member 1
Member 2
••••
Member 50
Members (R)
. Member

B • Tables
Fixed_STA50 Element
(Statesets) Properties

Number
State Name 1
Stateset Type 1
State Name 2
Stateset Type 2
••••
State Name 50
Stateset Type 50
States (R)
. State Name
. Stateset Type

251
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Fixed_TAB50 Element
(Tables) Properties

Number
Low Value
Fixed Increment
Dependent Value 1
Dependent Value 2
••••
Dependent Value 50
Dependent Values (R)
. Dependent Value

Fixed_TRA50 Element
(Transporters) Properties

Number
Number of Units
System Map Type
Map ID
Control
Velocity
Acceleration
Deceleration
Turning Velocity
Initial Position 1
Position ID 1
Zone 1
Initial Status 1
Vehicle Size 1
Size Integer 1
Initial Position 2

252
 • • • • •
B • TABLES

Fixed_TRA50 Element
(Transporters) Properties

Position ID 2
Zone 2
Initial Status 2
Vehicle Size 2
Size Integer 2
••••

B • Tables
Initial Position 50
Position ID 50
Zone 50
Initial Status 50
Vehicle Size 50
Size Integer 50
Unit Data (R)
. Initial Position
. Position ID
. Zone
. Initial Status
. Vehicle Size
. Size Integer

Fixed_VAR2R Element
(Variables) Properties

Number
1-D Array Index
2-D Array Index
Clear Option
Category Type
Response Category Type
Data Type

253
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Fixed_VAR2R Element
(Variables) Properties

Initial Values (R)

. Value 1
. Value 2
I/O Point
Usage
Description

Fixed_VAR10 Element
(Variables) Properties

Number
1-D Array Index
2-D Array Index
Clear Option
Category Type
Response Category Type
Data Type
Value 1
Value 2
••••
Value 10
Initial Values (R)
. Value
I/O Point
Usage
Description

254
 • • • • •
B • TABLES

Fixed_VAR10R Element
(Variables) Properties

Number
1-D Array Index
2-D Array Index
Clear Option
Category Type
Response Category Type

B • Tables
Data Type
Initial Values (R)
. Value 1
. Value 2
.••••
. Value 10
I/O Point
Usage
Description

Fixed_VAR50 Element
(Variables) Properties

Number
1-D Array Index
2-D Array Index
Clear Option
Category Type
Response Category Type
Data Type
Value 1
Value 2
••••
Value 50

255
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Fixed_VAR50 Element
(Variables) Properties

Initial Values (R)

. Value
I/O Point
Usage
Description

Fixed_VAR200 Element
(Variables) Properties

Number
1-D Array Index
2-D Array Index
Clear Option
Category Type
Response Category Type
Data Type
Value 1
Value 2
••••
Value 200
Initial Values (R)
. Value
I/O Point
Usage
Description

256
 • • • • •
B • TABLES

Data Types
As described in “The Dialog Design Window” chapter, there are SIMAN data types that
are available. In most cases, these data types are derived from the valid field entries from
modules in the Blocks and Elements panels. Refer to online help for more information on
a specific block or element and its valid field values.

Data type definitions

The following is a list of the available SIMAN data types. The Data Type Name refers to
the name of the data type as it appears in the Data Type property drop-down list entry in
the dialog design window. Values are the permitted values a modeler may enter. If these

B • Tables
values are a literal text string or punctuation, they are enclosed in double quotes. If the
value is another data type (either a standard or SIMAN data type), then the value has no
double quotes. Allowable Control Types specifies what control types are permitted with
the data type.

Data Type Name AccmLength

Values AttrID, real

Data Type Name ActivityAreaLevel

Values Integer

Data Type Name AllorSpecific

Values “All”, “Specific”

Data Type Name ArrivalTime

Values “Time”, “First”, “Last”, “Warmup”, “Every”, “Keyhit”,

“Message”

Data Type Name ArrivalType

Values “Station”, “Queue”, “Block”, “Event”

257
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Data Type Name AttrID

Values IdOrInt, SymbolName “(“ Integer “)”, SymbolName “(“

Integer “,” Integer “)”, “A(“ Integer “)”

Data Type Name BasicTimeUnit

Values “Seconds”, “Minutes”, “Hours”, “Days”

Data Type Name Capacity

Values “Capacity”, “Schedule”

Data Type Name ConsOrRange

Values “Constant”, “Range”

Data Type Name ConvType

Values “Accumulating”, “Nonaccumulating”

Data Type Name CountInitOpt

Values “Replicate”, YesOrNo

Data Type Name CrossDir

Values “Positive”, “Negative”, “Either”

Data Type Name CrossDirPosNeg

Values “Positive”, “Negative”

Data Type Name Date

Values Date

258
 • • • • •
B • TABLES

Data Type Name DateTime

Values Date, Time

Data Type Name Day

Values “11”, “12”, “13”, “14”, “15”, “16”, “17”, “18”, “19”, ”20”,
“21”, “22”, “23”, “24”, “25”, “26”, “27”, “28”, “29”, “30”,
“31”, MD1

B • Tables
Data Type Name DistExp

Values “EXPO(Mean)”, “NORM(Mean,StdDev)”,

“TRIA(Min,Mode,Max)”, UNIF(Min,Max)”,
“ERLA(ExpoMean,k)”,
“GAMM(Beta,Alpha)”, “JOHN(G,D,L,X)”,
“LOGN(LogMean,LogStd)”,
“POIS(Mean)”, “WEIB(Beta,Alpha)”,
“CONT(P1,V1,...)”, “DISC(P1,V1,...)”, Expression

Data Type Name EnabledDisabled

Values “Enabled”, “Disabled”

Data Type Name EndOpt

Values “Error”, “Dispose”, “Rewind”, “Ignore”

Data Type Name EntRule

Values “Preempt”, “Ignore”, “Wait”

Data Type Name EventType

Values “User”, “VBA”, “ActiveX”

259
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Data Type Name FailType

Values “Count”, “Time”

Data Type Name Failure

Values “Failure”

Data Type Name FileAccType

Values “Sequential”, “Direct”, “User”

Data Type Name FileFormat

Values AnyCharacters

Data Type Name FileName

Values AnyCharacters

Data Type Name FileStructure

Values “Unformatted”, “Free Format”, “WKS File”, FileFormat

Data Type Name FlowAllocation

Values “ValueAdded”, “NonValueAdded”, “Wait”, “Transfer”,

“Other”

Data Type Name FlowType

Values “Add”, “Transfer”, “Remove”

Data Type Name FormatType

Values “Duration”, “Calendar”

260
 • • • • •
B • TABLES

Data Type Name FreqExp

Values “Value”, “State”

Data Type Name GlobalPriority

Values “QTIME”, “LVF”, “HVF”

Data Type Name IdOrInt

B • Tables
Values SymbolName, Integer

Data Type Name IdOrIntOrRange

Values SymbolName, Integer “-” Integer, Integer, SymbolName “-”

SymbolName

Data Type Name IdOrIntOrReal

Values SymbolName, Integer, Real

Data Type Name IdOrRealorKey

Values SymbolName, Real, “INFINITE”

Data Type Name InitOpt

Values “Hold”, “Rewind”, “Close”

Data Type Name InitVar

Values “J”, “M”, “NS”, “IS”, “X” “(“ Integer”)”

Data Type Name LinkType

Values “Unidirectional”, “Bidirectional”, “Spur”

261
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Data Type Name Location

Values “Station”, “Intersection”, “Link”

Data Type Name LSR

Values “FCFS”, “LCFS”, “Closest”, “Farthest”, “LVF”, “HVF”

Data Type Name MD1

Values “1”, “2”, “3”, “4”, “5”, “6”, “7”, “8”, “9”, “10”, “01”, “02”,
“03”, “04”, “05”, “06”, “07”, “08”, “09”

Data Type Name Method

Values “RKF”, “Euler”, “User”

Data Type Name Month

Values “11”, “12”, “13”, “14”, “15”, “16”, “17”, “18”, “19”, “20”,
“21”, “22”, “23”, “24”, “25”, “26”, “27”, “28”, “29”, “30”,
“31”, MD1

Data Type Name NonNegativeReal

Values Non Negative Real

Data Type Name DataNonNegativeRealorSymbol

Values Non Negative Real, SymbolName

Data Type Name NonNegativeRealSymbolName

Values Non Negative Real, SymbolName, “NONE”

262
 • • • • •
B • TABLES

Data Type Name PositiveInteger

Values Positive Integer (optional min, max values)

Data Type Name PositiveReal

Values Positive Real

Data Type Name PreemptDest

B • Tables
Values Label, “STO”“(“ IdOrInt “)”

Data Type Name QBlock

Values Label, “SHARED”

Data Type Name QSR

Values “CYC”, “RAN”, “POR”, “LRC”, “SRC”, “LNQ” , “SNQ”,

“UR” “(“ IdOrInt “)”, “ER” “(“ IdOrInt “)”

Data Type Name QuotedString

Values Quoted String

Data Type Name RangeIndex

Values Integer, Integer “..” Integer

Data Type Name RankingCrit

Values “FIFO”, “LIFO”, “LVF”, “HVF”

Data Type Name RealorInfinite

Values Real, “Infinite”

263
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Data Type Name RealorSymbolName

Values Real, SymbolName

Data Type Name RegulatorTimeUnit

Values “Per Second”, “Per Hour”, “Per Minute”, “Per Day”

Data Type Name RepLengthTimeUnit

Values “Hours”, “Days”, “Weeks”

Data Type Name ResourceAction

Values “Hold”, “HoldUntil”

Data Type Name ResourceorSet

Values “Resource”, “Set”

Data Type Name RSR

Values “CYC”, “RAN”, “POR”, “LRC”, “SRC”, “LNB”, “SNB”,

“UR” “(“ IdOrInt “)”, “ER” “(“ IdOrInt “)”

Data Type Name ResourceType

Values “Stationary”, “Positional”, “Distance”, “Network”

Data Type Name RestrColumn

Values “Exclude”, “Include”

264
 • • • • •
B • TABLES

Data Type Name Rule

Values “CYC”, “RAN”, “POR”, “LDS”, “SDS”, “LRC”, “SRC”,

“LNQ”, “SNQ”, “LNB”, “SNB”, “UR”, “ER”, “MIN”,
“MAX”

Data Type Name SaveCrit

Values “First”, “Last”, “Product”, “Sum”

B • Tables
Data Type Name SeedInitOpt

Values YesOrNo, “Common”, “Antithetic”

Data Type Name SensorLocationType

Values “Specific Level”, “Percentage Capacity”

Data Type Name Severity

Values “Fatal”, “Warning”, “No”

Data Type Name SignedInteger

Values Signed Integer (optional min, max values)

Data Type Name Sort

Values “Ascending”, “Descending”, “Unsorted”

Data Type Name StateSetType

Values “Idle”, “Busy”, “Inactive”, “Failed”, IdOrInt

Data Type Name Status

Values “Active”, “Inactive”

265
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Data Type Name SystemMap

Values “Distance”, “Network”

Data Type Name Time

Values Time

Data Type Name TSR

Values “CYC”, “RAN”, “POR”, “LDS”, “SDS”, “UR”, “ER”

Data Type Name UnitTimeUnit

Values “Seconds Per Unit”, “Minutes Per Unit”, “Hours Per Unit”,
“Days Per Unit”

Data Type Name VehicleSize

Values “Length”, “Zone”

Data Type Name Year

Values Integer

Data Type Name ZoneControl

Values “Start”, “End”, Integer

266
 • • • • •
B • TABLES

Connection point data types and SIMAN blocks

Entry/exit point types
There are six different entry point types and six different exit point types, as noted below.

Entry Types Exit Types

Standard Standard
Queue Queue
Seize PickQ

B • Tables
Hold Type A QPick
Hold Type B Select
Hold Type C Balk

DESCRIPTIONS
The three different entry types (Hold Type A, B, and C) are used to distinguish those
modules that can connect to a QPick module (Access, Request, etc.) and those that cannot
(Capture, Group). The Hold Type B is used when a Queue block is required.
A Seize entry type is required for the Select exit type since only a Seize module can
follow a Select module.

CONNECTION VALIDATION

Exit Type Entry Type

Standard Standard, Queue, Seize, Hold Type A, Hold Type C

Queue Seize, Hold Type A, Hold Type B, Hold, Type C
PickQ Queue
QPick Seize, Hold Type A, Hold Type B
Select Seize

267
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

CONNECTION TYPES ON SIMAN MODULES

Block Connection Type

Access Hold Type A

Allocate Hold Type A
Capture Hold Type C
Combine Hold Type C
Group Hold Type C
PickQ PickQ (on queue label), Standard (on balk label)
Preempt Hold Type A
Proceed Hold Type C
QPick QPick (on hidden next label), PickQ (on queue label)
Queue Queue (Entry point), Queue (Exit Point on hidden next label)
Request Hold Type A
Scan Hold Type C
Seize Seize
Select Hold Type A, Select
Wait Hold Type C

268
C Creating Online Help Files
Arena provides template developers with a help interface that easily allows designers to
associate online help files with their templates, providing template users with detailed
instructions on the use of various modules and their options.
Here is an example of how the template help interface works. Let’s assume that you have
created a template called Sample.tpl that contains a module called Server. Let’s also
assume that the Server module’s main dialog looks like this:

C • Creating Online Help

Figure C.1 Main dialog of the Server module

The repeat group and secondary dialog (Server Names and Options) look like this:

Figure C.2 Server Names Repeat Group Figure C.3 Options Secondary dialog
dialog

269
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

When you generate the Sample.tpo file, Arena will write out a help interface file called
Sample.HH that looks something like this:
Automated help: *.HH
#define TemplateContents 4293984255
#define Server 4294443008
#define Server_ 0
#define Server_Server_Names 524288
#define Server_Server_Name 1048576
#define Server_Quantity 1572864
#define Server_Process_Time 2097152
#define Server_Options 2621440
#define Server_Cost 3145728
The left column (for example, #define TemplateContents) displays the Help Context ID
that will be used by the Help Authoring Tool (for example, RoboHelp®). The right
column displays the Help Context Number that will be referenced by Arena. This file
serves as a “map” between your Help Authoring Tool and Arena.
The first entry for every template’s .HH file contains the entry #define TemplateContents.
This context ID allows template developers to have a Table of Contents topic in the
template help file. When a template panel is attached to the Project Bar, the template name
is added to the list of attached templates in Arena’s Help menu. Clicking on any of these
menu options will automatically display the help topic associated with the
TemplateContents context ID. See the instructions below to find out how to associate a
context ID with a help topic.
The remaining entries are determined as follows: Each module will have an entry
corresponding to the module name (for example, #define Server). By default, this context
ID is utilized when you click the Context Sensitive Help toolbar button (on the Standard
toolbar) and then click on a module button in the Project Bar. This could be used to
display a general overview of the types of uses for that module. This behavior may be
changed by editing the Module Help Option in the Template Options dialog.
In Arena, every module dialog (including secondary dialogs and dialogs displayed when
adding or editing items in repeat groups) contains a Help button. Each Help button may
display either the main help topic for that module or a unique help topic for that particular
dialog of the module. For example, the Server module displayed above has three dialogs:
the main dialog (Server), and two secondary dialogs (Server Names repeat group and
Options). Each of these dialogs has a Help button. The Server dialog’s Help button will
display the main help topic for the module. The Server Names dialog may display either
the main help topic (as displayed by the Server dialog) or a unique help topic specific to
the Server Names dialog. The Options dialog may display either the main help topic (as
displayed by the Server dialog) or a unique help topic specific to the Options dialog.

270
 • • • • •
C • CREATING ONLINE HELP FILES

To enable or disable unique help topics for individual dialogs, you specify a dialog form
object’s UniqueHelpTopic property as True or False in the module definition’s dialog
design window. By default, this property is set to True for a dialog form. If you enable a
unique help topic for a particular dialog but fail to create a corresponding topic in your
help file, users who press the Help button in that dialog will receive a message from the
Windows® Help system indicating that the topic does not exist in the help file. Therefore,
you should always set the UniqueHelpTopic to True if you do not intend to create a help
topic specific to the dialog.
Similarly, in the module definition’s dialog design window, each dialog form object
includes a WhatsThisHelp property that is specified as True or False. This option will
provide the dialog with a question mark in the top right of the title bar, allowing the user
to ask for help on a specific operand in the dialog. If you enable this option but fail to
provide a topic for each specific operand in your help file, users who click the question
mark and then click an operand will receive a message that the topic does not exist.
Therefore, you should not enable the “What’s This?” help option if you do not intend to
create a help topic for each operand in the dialog.
When the help interface (.HH) file is generated along with the .tpo file, the context IDs are

C • Creating Online Help

written for each dialog according to the following rules: the main dialog’s context ID is
created by appending an underscore (_) to the module name, for example, Server_. The
context IDs for all other dialogs are created by appending the dialog name to the module
name, separated by underscores; spaces embedded in dialog and repeat group names are
converted to underscores. For example, the Server Names dialog would generate a context
ID of Server_Server_Names. The Options dialog’s context ID would be Server_Options.
Context IDs for “What’s This?” help are created for each operand by appending the
operand name to the dialog name with an underscore. For example, the Server Names
dialog would generate context IDs Server_Server_TimeName and Server_Quantity for
the operands Server Name and Quantity within the Server Names dialog.
To use the help interface file generated above, you need to first use your Help Authoring
Tool to create help information in the form of “topics.” Next you tell your Help Authoring
Tool that you have a help interface or “map” file (for example, Sample.HH). To do this in
RoboHelp, you need to add the file to the list of “map files” for the project by following
the procedure outlined below:
1. From the Project menu, choose Setup.
2. Click the Advanced tab. Under the Setup Section heading, highlight the
(Map)/Include Files item, then click the Setup Section heading.
3. Choose the help interface file provided by Arena (e.g., Sample.HH) from the list and
click Add.
4. Click OK several times until you’ve closed all the dialogs and are back to the help
document.

271
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Next you need to associate the individual help topics in your help document with the
context IDs contained in the help interface file. To do this, you must edit each help topic
and locate the Context String field (you may need to click the Advanced button to open
up this section of the dialog). Click on the Choose button to bring up the Choose Context
String Provided By Development Team dialog. Make sure that the help interface file
provided by Arena is highlighted in the Project Map File field. Then select the appropriate
context ID from the Symbolic Identifier list (for example, if you were editing the main
help topic for the module, you would choose the Server_ context ID). Click OK until you
have closed all dialogs and are back to the help document. The topic is now associated
with the context ID.
To associate the TemplateContents context ID with your Table of Contents for the
template, you must do the following:
1. From the Project menu, choose Setup.
2. Click the Contents button.
3. Choose the TemplateContents context ID from the list of Context Strings.
4. Click OK several times until you have closed all the dialogs and are back to the help
document.
The next time you “make” the help file, it will incorporate the appropriate Help Context
Numbers (the values in the right column of the .HH file) in the .hlp file. Note that the help
file should have the same name as the template file. For example, Sample.tpo will look for
a file called Sample.hlp.

272
Index

A Defining modeling logic „ 40

Delay module „ 48
Accelerator keys „ 108
Design Properties grid „ 83
Advanced Process panel „ 2, 179
Dialog Design toolbar „ 108
Advanced Transfer panel „ 2, 179
Dialog Design window „ 33
Animation object
Design Properties grid „ 83
display in user view „ 164
dialog form objects „ 79
in logic window „ 113
hidden operands „ 79
Arena Symbol Factory „ 4
Operand Explorer „ 78
Arena template „ 178
operand objects „ 79
Assign module „ 45
repeat group objects „ 79
Auto-Create „ 74, 95
Toolbox „ 80
Toolbox controls
B CheckBox „ 81
Back quote character ComboBox „ 81
use for referencing operand „ 114 DatePicker „ 81
Basic Process panel „ 2, 178 DateTimePicker „ 81
DialogButton „ 81
C FilePicker „ 81
GroupBox „ 81
Changes to instances „ 74
HiddenOperand „ 81
Check boxes
Line „ 81
customizing options „ 141
RadioButtonGroup „ 81
special access for references in logic window
RepeatGroupDialog „ 81
„ 120

Index
RepeatGroupTable „ 81
Clipboard „ 74, 111, 113, 165, 176
Text „ 81
Compatibility of existing module instances
TextBox „ 81
„ 74
TimePicker „ 81
Conditional assignment module „ 152
View Dialog Form button „ 78
Contact information „ 5
Dialog form „ 81
Creating online help files „ 269
arranging controls „ 83
Customer Support Center „ 4
layout „ 39
locking controls „ 83
D opening „ 82
DataType property resizing „ 83
SIMAN „ 100 Direct connection „ 121
standard „ 100 in module logic „ 123
Decide module „ 44

273
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

Distances element „ 198 H

Document conventions „ 3
Help file creation „ 269
Documentation set „ 3
Help interface file „ 271
Draw object
Hidden operands „ 79
hidden/visible layer „ 163
in user view „ 163
I
E InUserView property „ 101
Element „ 177
data elements „ 177 L
define vs. reference option „ 185 Loading a template panel library (.tpl) file „ 66
defining through hierarchy „ 179, 183 Logic window
defining via element operand „ 179 attaching switches „ 146
lists „ 180, 182 connecting module instances „ 142
sub-lists „ 182, 185 decomposing processes „ 109
special types design hints „ 207
fixed-length „ 196 detaching switches „ 146
hidden „ 197 differences with model window „ 111
inverted „ 198 hidden module (utlarena.tpo) and switches
switches on elements „ 195 „ 150

Elements panel „ 179 multiple connections and switches „ 142

entry „ 93 opening „ 110
Entry point repeating exit points and single connection
operand reference in logic window „ 123 „ 143

operand validation/reference „ 94 rules and guidelines „ 154

operands „ 37 switches in module instances „ 121
switches attached „ 160 verifying logic relative to switches „ 149
user view object „ 160 LogicProperties property „ 92
Errors/warnings „ 67 repeat groups „ 102
reviewing „ 68
Exit point M
operand „ 37
Model window
operand validation/reference „ 94
differences with logic window „ 111
repeatable „ 131
Module „ 95
switches attached „ 160
handle „ 157, 159
user view object „ 160
process of building logic „ 41
repeater „ 133
F required option „ 72
Field types of entity flow „ 121
use in Logic Window chapter „ 113 Module definition
changes and existing instances „ 74
G copying „ 74
deleting „ 66
Global pictures „ 55
operand references „ 114

274
 • • • • •
INDEX

renaming „ 66 basic „ 92
Module definition window „ 65 element „ 92
opening „ 67 entry point „ 93
Module handle „ 159 exit point „ 94
Module instance hidden „ 101
use in model or logic window „ 110 property „ 93
Module-building tutorial „ 29 special functions „ 97
Assign module „ 45 specifying the DataType property „ 99
Decide module „ 44 specifying the InUserView property „ 101
Delay module „ 48 specifying the LogicProperties property
Process module „ 45 „ 92

Queue module „ 42 specifying the Name property „ 91

Queues element „ 50 specifying the SwitchName property „ 101
Release module „ 48 specifying the Value property „ 96
Seize module „ 42 Operands, using „ 91
Variables element „ 50
P
N Panel icon „ 175
Name property „ 91 design hints „ 206
repeat groups „ 102 size and display in template panel „ 72, 176
NetworkLink element „ 198 Panel icon window „ 175
Number of Alternate Outputs „ 134 tutorial „ 56
Process module „ 45
O Project Bar „ 9, 23, 58, 71, 72
Property „ 177, 180
Online help „ 3
switches on properties „ 196
Opening a module definition window „ 67
Opening a new template panel library (.tpl) file
„ 65
Q
Operand Queue module „ 42
default value „ 115, 192 Queues element „ 50
design hints „ 205
display in user view „ 161 R

Index
repeatable operand „ 162
Radio button group
element „ 183
customizing options „ 141
property „ 187
special access for references in logic window
defining element and property using
„ 120
hidden operand „ 192
Referencing operands
repeat group „ 188
animation objects in user view „ 164
references to „ 111
combining repeating and non-repeating
switching multiple with references to
references „ 131
provided set „ 117
concatenating text and reference „ 115
template panel library (.tpl) file operand
containing multiple references „ 116
report „ 68
entry point operands „ 123
value reference in switch definition „ 171
in switch definition „ 171
Operands
multiple references to same operand „ 119

275
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

repeating exit point „ 133 use in logic window „ 146

repeating operands „ 127 use in module definition windows „ 170
Release module „ 48
Repeat group „ 102 T
switch use „ 173
Technical support „ 4
Repeat group objects „ 79
Template
Repeat groups
documenting „ 208
accessing the number of tuples and the tuple
Template Development toolbar „ 33
number „ 105
Template panel „ 65
combining repeating operand values into a
changing the display name „ 71
single value „ 106
creating new window „ 32
definition depth and reference rules „ 104
detaching „ 75
reference rules „ 125
icon size and display „ 72
specifying the LogicProperties property
private „ 71
„ 102
Template panel library (.tpl) file
specifying the Name property „ 102
changes and existing module instances „ 74
Repeatable logic „ 133
checking for errors/warnings „ 67
Repeatable module „ 133
Template panel object (.tpo) file
Review errors „ 68
changes and existing instances „ 74
generate .tpo in template window „ 67, 70
S providing to modeler „ 70
Sample models „ 3 rules regarding attachment to logic windows
Segments element „ 198 „ 112

Seize module „ 42 Template window

Sets element „ 198 closing „ 66
SIMAN template „ 179 deleting a module „ 66
Simulation logic and module design „ 109 generating the template panel object (.tpo)
SMARTs library „ 3 file „ 70
Station transfer „ 121 renaming a module „ 66
in module logic „ 122 report „ 68
Statistics template options „ 71
hints for designing in module „ 209 version „ 70
Submodel „ 109 Toolbox, using
Switch „ 169 CheckBox control „ 86
and element „ 195 ComboBox control „ 85
and property „ 196 DatePicker control „ 89
attached to user view animation object DateTimePicker control „ 88
„ 165 DialogButton control „ 87
defining „ 170 FilePicker control „ 90
definition „ 70, 169, 171 GroupBox control „ 85
operand comparison with value „ 172 HiddenOperand control „ 91
in logic window module instance „ 121 Line control „ 85
name „ 170 RadioButtonGroup control „ 86
rules regarding definitions „ 172 RepeatGroupDialog control „ 87
template panel library (.tpl) file switch report RepeatGroupTable control „ 88
„ 68 Text control „ 84

276
 • • • • •
INDEX

TextBox control „ 85
the controls „ 83
TimePicker control „ 89
Trace
design hints for use in module definition
„ 208

Trace in module definitions „ 153

Training courses „ 5
Tuple
value of switch in „ 173

U
User view „ 157
design hints „ 207
designing „ 53
modifications by modeler „ 158
User view window „ 157
tutorial „ 53
Utlarena.tpo file „ 150
conditional assignment module „ 152
hidden module „ 150

V
Value property „ 96
Variables element „ 50

W
Web support „ 4
What’s This? help „ 271
Context IDs „ 271
World units „ 157

Index

277
• • • • • ARENA TEMPLATE DEVELOPER’S GUIDE

278