Template Developer's Guide PDF

Arena
TEMPLATE DEVELOPERS GUIDE

PUBLICATION ARENDG-RM001G-EN-PJanuary 2012
Supersedes Publication ARENDG-RM001F-EN-P
PN-111652
Contact
Copyright Notice
Trademark Notices
Other Trademarks
Warranty
Rockwell Automation Customer Support Telephone 1.440.646.3434

Online Support http://www.rockwellautomation.com/support/
2014 Rockwell Automation, Inc. All rights reserved. Printed in USA.
This document and any accompanying Rockwell Software products are copyrighted by Rockwell Automation, Inc. Any
reproduction and/or distribution without prior written consent from Rockwell Automation, Inc. is strictly prohibited.
Please see the license agreement for details.
Arena, Rockwell Automation, and SIMAN are registered trademarks of Rockwell Automation, Inc.
ActiveX, Microsoft, Microsoft Access, SQL Server, Visual Basic, Visual C++, Visual SourceSafe, Windows, Windows
ME, Windows NT, Windows 2000, Windows Server 2003, Windows Vista, 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.
This product is warranted in accordance with the product license. The products performance can 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 products 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: 14.70.00
Modified: April 18, 2014 9:32:31 AM
ii
Contents
1 Welcome
What is Arena simulation software? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Intended audience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
About this guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Where can I go for help? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Refer to the users guides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Explore our examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Get help. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Use the Smarts library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Get phone support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Get Web support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Refer to the Arena Web site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Get training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Get consulting services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contact us . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Arena Template Development Overview
1
1
2
2
3
3
3
3
3
4
4
5
5
5
5
Modeling with ArenaAn overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Templates and panels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Module definitions and instances. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Defining a module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Panel icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
User view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Dialog box design and operands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Elements and properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Arena hierarchy and SIMAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Flowcharts and data modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Use of templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
General modeling tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Industry-oriented environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Application-focused tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Improving modeling productivity and sharing modeling technology . . . . . . . . . 27
iii
ARENA TEMPLATE DEVELOPERS GUIDE
3 Module-building Tutorial
Module overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Getting startedA new template. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dialog Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The dialog box design window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adding the modules dialog box operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adding the module's entry/exit point operands . . . . . . . . . . . . . . . . . . . . . . . . . .
Arranging the Dialog form layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The logic window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Overview of the Printer module logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Receiving entities and seizing the printerThe Queue and Seize modules . . . .
Deciding whether to changeover the printerThe Decide module . . . . . . . . . . .
Changeover logicAssign, Process, and Assign modules . . . . . . . . . . . . . . . . .
The print logicDelay and Release modules . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining the Printer module elementsQueues and Variables elements . . . . . .
User View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Panel Icon. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A sample model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Preparing the template for use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Single printer simulation model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 The Template Window

The template menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating a new template window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Loading an existing template panel file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Closing a template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Saving the template panel library file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating and editing modules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The module definitions list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Opening module definition windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Preparing the template panel for use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Checking the template panel for errors and warnings . . . . . . . . . . . . . . . . . . . . .
Reviewing errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Template panel file reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Generating the template panel object (.tpo) file . . . . . . . . . . . . . . . . . . . . . . . . . .
Other template panel information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Changing the version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Template options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining required modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining data modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iv
29
29
32
33
33
35
37
39
40
40
41
42
44
45
48
50
53
56
57
57
58
64
65
65
65
66
66
66
66
66
67
67
67
68
68
71
71
71
71
73
74
CONTENTS
Defining a name operand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Expression Builder Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating copies of module definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Compatibility of existing module instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 The Dialog Design Window
74
75
75
75
77
Dialog Design Window overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

The Operand Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
The Toolbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
The dialog box form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Specifying the DataType property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Specifying the SwitchName property. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Specifying the InUserView property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Hidden operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Using repeat groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Specifying the Name property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Specifying the LogicProperties property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Repeat group definition depth and reference rules . . . . . . . . . . . . . . . . . . . . . . . 105
Accessing the number of tuples and the tuple number . . . . . . . . . . . . . . . . . . . . 107
Combining repeating operand values into a single value . . . . . . . . . . . . . . . . . . 107
Using repeatable modules in the logic window with repeat groups . . . . . . . . . . 109
Using accelerator keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Dialog Design toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6 The Logic Window

Simulation logic and module design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The logic window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Differences between logic and model windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Running simulation models (model window). . . . . . . . . . . . . . . . . . . . . . . . . . .
Referencing operands (logic window) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Switching module instances (logic window) . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining repeatable logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Module connections in the logic window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attaching template panels while working in a logic window. . . . . . . . . . . . . . .
Display of animation objects (logic window). . . . . . . . . . . . . . . . . . . . . . . . . . .
Fields and operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Referencing module data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Referencing operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Special access for check boxes, radio button groups, and combo boxes . . . . . .
Switches in logic window module instances . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining transfer of entities into and out of a module . . . . . . . . . . . . . . . . . . . .
Referencing non-repeating operands from a repeat group . . . . . . . . . . . . . . . . .
Referencing repeating operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining repeatable exit points in a module . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Repeatable modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 1: Parallel logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 2: Serial logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 3: Defining alternate outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Customized options using radio button and check box controls . . . . . . . . . . . .
Module connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using graphical connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining multiple connections from a single exit point . . . . . . . . . . . . . . . . . . .
Repeating exit points in the logic window . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Switching module instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attaching and detaching switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Effect of switches in the logic window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using Arenas utility modules (from utlarena.tpo). . . . . . . . . . . . . . . . . . . . . . .
Defining module trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Logic definition rules and guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vi
111
111
112
113
113
114
114
114
115
115
115
116
116
116
123
124
125
129
131
136
139
141
143
145
147
148
148
148
149
152
153
154
156
160
161
CONTENTS
7 The User View Window

Module instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Module-related objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The module handle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Module Text Options dialog box. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Entry and exit points. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Displayed operands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Draw objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Animation objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
User View switch use. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8 The Switch Window

Defining switches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Switch names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Switch definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Switch definition rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9 The Panel Icon Window
163
164
164
165
165
166
167
170
170
173
175
176
177
177
179
181
Creating the panel icon. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
10 Elements
Defining elements in modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Element lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Use of elements and properties in module definitions . . . . . . . . . . . . . . . . . . . . . . . .
Access to properties in a model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Displaying element lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining elements from hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Element operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining element operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sublists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining and referencing elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Property operands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining Property operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining repeating properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining an element or property using a hidden operand. . . . . . . . . . . . . . . . . .
Switches and elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
183
185
185
186
187
187
188
188
190
190
190
192
193
194
194
195
199
202
vii
Special element types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Fixed-length elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Hidden element list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Inverted elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A Template Design Guidelines

Dialog box design (dialog box design window). . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dialog boxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Operand objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Helpful hints for defining objects in the dialog box design window . . . . . . . . .
General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Panel icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
User view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Module logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Naming conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Template documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Trace. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Statistics and reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B Tables
Elements and properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Standard elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Inverted elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fixed-length elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data type definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Connection point data types and SIMAN blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Entry or exit point types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C Creating Online Help Files

Index
viii
203
204
204
206
211
211
211
211
212
212
213
213
214
214
214
215
215
217
217
217
237
239
264
264
275
275
277
281
Welcome
What is Arena simulation software?
Arena is an advanced simulation system that provides an interactive environment
for building, 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 Arenas natural
hierarchical structure enabling you to create new simulation tools in a graphical,
easy-to-use environment.
In Arenas template-building area, you create complete simulation building blocks,
called modules. These modules can 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, Arenas 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
can use these templates in support of your own simulation activities, or you can 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 simulation
modelers can improve their productivity and share the knowledge they gain by
capturing essential simulation logic and quickly packaging it into a verified, reusable
building block for future models.
As already mentioned, in Arena you have the ability to define new modeling
constructs, called modules, and to store them in libraries, referred to as Application
Solution Templates (ASTs), or templates.
If you are familiar with Arenas model-building and analysis environment, you will
find that the template development features build on the concepts and interface you
already have learned. To work with templates, when you run Arena, you will open a
Template Window instead of a Model Window. Select the File > New menu option or
press the New File toolbar button. In the dialog box that is displayed, select Template
Window and click OK, as shown in Figure 1.1.
Figure 1.1 Arenas 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 build templates, you should already have a good understanding
of the basic Arena modeling interface and either the SIMAN template or Arenas
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 Users Guide and Help.
About this guide

The Arena Template Developers Guide is designed to serve as both an instruction
manual for building templates and as a reference guide for the template-building
features. The first two chapters familiarize you with the concepts and terminology
employed in Arena and walk you through a module-building tutorial. Adescription of
the template window follows, and then of each one of the five windows that you use
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.
Before you begin to work with the template-building features, 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 see concepts presented in Chapter 2.
1 WELCOME
Where can I go for help?

Our commitment to your success starts with the suite of learning aids and assistance
we provide for Arena.
Refer to the users guides

The documentation set includes this manual, Arena Template Developers Guide,
which introduces template creation and module building. In addition, the Arena
Users Guide and Variables Guide are separate reference manuals that provide module information on 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 (for example, go to Help > Arena
Help); text you are asked to type is shown in Courier Bold (for example, in this field,
type Work Week), and dialog box and window button names are shown in bold (for
example, click OK).
Explore our examples

Arena is accompanied by a number of sample models that illustrate many of the commonly used approaches for capturing the essence of a variety of processes. Examples
are provided for both job shop and flow shop environments. For a list of Arenas
examples, go to Help > Arena Help. On the Contents tab, choose Model Building
Basics, and then select Viewing Arena Example Models.
Get help
Help is always at your fingertips! Arena incorporates the latest in help features,
including Whats This? help that displays a brief description of fields in dialog boxes,
context-sensitive help on menu and toolbar buttons, and a help button on each of
Arenas modules. See 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 best to 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. When youre wondering how to take the
next step in your model, browse the Smarts library for a ready-made solution. For a
list of 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.
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 softwares 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, option 3 & 7), 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.
International technical support is provided by the global representatives. For contact

information on the representative nearest you, visit the Global Partners page on
www.ArenaSimulation.com.
Get Web support

In addition to phone support, the Rockwell Automation Customer Support Center
offers extensive online knowledgebases of technical notes and frequently asked
questions for support of non-urgent issues. These databases are updated daily by our
support specialists. Go to http://www.rockwellautomation.com/support/ to sign up for
online support.
4
1 WELCOME
Once you have signed up for online support you can elect to receive regular e-mail
messages with links to the latest technical notes, software updates, and firmware
updates for the products that are of interest to you. You can also submit online
support requests.
If you cant find the answer you need, contact your local representative or Arena
technical support.
Refer to the Arena Web site

The Arena Web site provides a collection of brief how-to videos and FAQ topics
that may be of assistance to you. This material and more is available through the
Tools and Resources tab of www.ArenaSimulation.com.
Get training
Do you need training? Rockwell Automation offers a standard training course consisting of lectures 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 thats right for you! 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
improvement efforts. Toward this objective, we invite you to contact your local
representative or Rockwell Automation at any time that we can be of service to you.
Be sure to connect with us on Facebook and join the Arena Users Group on
LinkedIn.
Support E-mail: Arena-Support@ra.rockwell.com
Support Phone: 1.440.646.3434, options 3 & 7
General E-mail: Arena-Info@ra.rockwell.com
U.S. Sales Phone: 1.724.741.4000
URL: www.ArenaSimulation.com
URL: www.RockwellAutomation.com
5
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, 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.
Modeling with ArenaAn 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
modules 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, see the Arena Users Guide and 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 can 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 can 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
After a module has been placed in the model window, its associated data can be
edited by double-clicking the module. This action opens the modules main dialog
box, 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 in 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 (that is, 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 can 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 can require a
material transfer device (for example, 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 can 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 can cause particular sections of the model to be generated or
ignored, can cause the creation of elements in the experiment, and can turn on or turn
off 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.
2 ARENA TEMPLATE DEVELOPMENT OVERVIEW
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 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 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 from 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

9
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.
Module definitions and instances

A module in Arena is a single construct that can be selected from a template panel
and placed in an existing 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 module (to
generate entities) or Process module (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 describes 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 can be modified by the modeler so that each instance carries with it its
own characteristics. For example, the default main dialog box for the Create module
(provided by the Arena templates Basic Process panel) displays eight operands that
the modeler can 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.)
10
Figure 2.3 Main dialog box for Create module
The module definition also specifies the characteristics of the Create modules dialog
box, including the position of the operands, the prompts associated with them, their
default values, and so on. When a Create module is placed in a model window, an
instance is created. Many instances of a given type of module can be placed in the
model window. For example, the simulation model can represent a grocery store
where different types of customers arrive at varying times or rates. First, a Create
module is placed in the model window. The modeler can change the values of the
Create module instances operands. For example, the first customer type can use the
default arrival stream, which is random (exponential). A second type of customer can
arrive at a Constant rate. In that case, a modeler might change the value in one
instance of the Create modules to Constant. 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 arrival stream type of
Random (from the module definition).
Module instances can be placed in Arena model windows (and later saved in model
.doe files) or in the logic windows of newmodule definitions (to be saved in .tpl files).
For simplicitys sake, we usually discuss the use of module instances by the modeler
(suggesting placement in model windows) in this guide. As you are reading, however,
keep in mind that instances of the modules you are defining can 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 box 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
11
the Window menu open each of the windows for the selected Module Definitions list.
The corresponding buttons on the Template Development toolbar may also be used.
As is the case throughout Arena, you can have as many windows open as you need
for one module definition or more). Figure 2.4 shows a template window with five
module definition windows opened for a single example module (Shipping).
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 we most often work when initially building a
new module; that is, first defining the dialog box design and logic, then defining
switches to control turning on and off module options, and finally adding the user
view and panel icon graphics. However, the five components of a module can be
defined in any order. As you work with a module definition, you often will modify
the contents of several of these windows.
Figure 2.5 Template Development toolbar

12
In this chapter, we present an overview of each one 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 a
template panel; then we describe the user view and the modules dialog box 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 modules dialog box and operands. First, when the
template panel object (.tpo) file is attached to the Project Bar, the panel icons are
displayed. This is a table of small graphics icons representing the modules contained
in the template panel. Figure 2.6 shows the Arena templates Basic Process panel
attached to the Project Bar.
Figure 2.6 Basic Process template panel
13
While a modules 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, and so on. The panel icon for the definition of the Basic
Process panels 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 modules user view is displayed. This user view contains the module handle (the
name of the module, displayed as a text object in a box that opens the modules main
dialog box when the modeler double-clicks on it), and can contain entry points, exit
points, operand values, static drawing graphics, and 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 instances 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 used in the module. Figure 2.9 shows the modified user views of two
Process module instances using pictures from Arenas people.plb picture library in
place of the default resource pictures.
14
Figure 2.9 Modified Process module instances
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 box cause them to be
switched out. (We discuss switches later in the chapter.)
Figure 2.10 User view window of the definition of Arenas Process module
Dialog box 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 box 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
15
operands, and their organization into one or more dialog boxes for the module. A
module designer might 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 in a system. Furthermore, through use of switches, the dialog box 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
box that is opened when an instance is first formed appears as shown in Figure 2.11.
Figure 2.11 Record module default dialog box
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 names value and the current
simulation time, instead of increasing or decreasing a specified count.
In a template panel library (.tpl) file, the Dialog Box Design window is the interface
for defining the dialog box form layout(s) and operands of a module definition. In
this window, a module designer defines dialog box sizes, data displayed to and
entered by the user, default and permissible values, and the layout of interface
controls.
The dialog box design window includes an Operand Explorer section to browse the
module definition's hierarchy of dialog boxes (many modules contain multiple dialog
boxes), operands, and repeat groups (for defining repeatable operands or sets of
operands, such as the resources to be used in a process). It also includes a Toolbox
16
section to add user interface controls to the modules dialog box forms and a Design
Properties grid to edit the properties of one or more selected objects.
Figure 2.12 shows the dialog box design window for the definition of the Basic
Process panels Batch module, which contains a main dialog box and a number of
operands that are members of the dialog box.
Figure 2.12 Dialog box design window for the Batch modules definition
A modeler working with a module instance can modify the values of operands, but
cannot change the configuration of dialog boxes, 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 modules data are part of the module definition; each
instance 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
17
is created by building an Arena submodel. The Logic window, which is used to

create a module definitions 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 youve created.
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. These discussions also refer to the
creation of module logic, unless otherwise noted.
When the logic window is active, the Run toolbar is not available because Arena
module definitions cannot be simulated themselvesonly 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 can 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 modules 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 instances dialog box to
the underlying module logic is through operand references established in the logic
window of the module definition.
To illustrate this, lets 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 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 box for the Admissions Clerk module is shown in
Figure 2.13.
Figure 2.13 Dialog box for hospital Admissions Clerk module
18
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 plan to use the
value of a module operand, you enclose the name of the operand in back quotes (`).
Assuming that the operands have the same name as the prompts (that is, 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.
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, a Process module is placed in the
underlying model logic with values of Mary for the resource to be used and
UNIFORM(10,30) for the process time.
19
Unlike a module instances user view and operands, the modules logic cannot be
directly modified by a modeler. Instead, the modules operands can be used to
specialize an instance of a module to meet a particular need by passing data to the
logic (that is, the module instances in the logic window) and by switching sections of
the logic in or out.
There can 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, because they are not accessible from operands in their module.
Switches
In an Arena module definition, individual objects in the user view, dialog box design,
and logic windows can 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, 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
modules 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 can display pertinent
information, based on a users 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
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 box design window, a switch is added to an object by
specifying the objects 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.
Figure 2.16 Tally Block with attached switch in logic window
Using switches in module definitions can aid users of the module focusattention only
on the fields that are relevant, given other information theyve provided (for example,
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
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 can 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
Packer as the name of the resource to seize and release. 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 or conveyors. 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, and so on; and
conveyors have properties such as velocity and type (accumulating or nonaccumulating). (See Appendix B Tables on page 217 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 box design window, you identify particular
operands that will define elements by specifying in the operands 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. See the The
Dialog Design Window on page 77 for information about defining element and
property operands.
22
Arena hierarchy and SIMAN

Arena employs a hierarchical architecture for simulation modelingthat is, modules
are defined utilizing other modules. This approach offers many benefits. Modules
that represent subsets of a process or set of similar processes can be developed and
verified once, and then can 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 (for example, select next job to process, enter
passenger name, or wrap label) also can be used 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 Arenas 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 or Branch. 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 counterparts. However, the modules in Arena offer options for
the types of information that is to be placed in an operand (for example, whether the
type of element to be assigned a value is an attribute, a variable, a picture, and so on),
and define both the model logic (that is, blocks) and elements (that is, information to
be written to SIMANs 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 or counters. Many data
modules in the Arena template panels (for example, 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 can be thought of as a module using a single
level of hierarchy, as illustrated in Figure 2.17.
23
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 (that is, the contents of the logic
window). Instead, you have created a new interface to a DELAY module followed by
a SIGNALmodule by defining ModuleAs operands and by establishing the
references to those operands in the DELAY 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
ModuleBs 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
24
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 Arenas 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.
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 from a spreadsheet interface. For more
information on defining a module as a data module, see Defining data modules on
page 74.
Use of templates
Introduction
Templates can 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 use 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 that make up the SIMAN templateBlocks and Elementsprovide a
25
graphical interface to the SIMAN language for modelers and form the base of all
Arena modules. The three panels that make up the Arena templateBasic Process,
Advanced Process, and Advanced Transferprovide modules that capture
commonly encountered processes and system elements using generic terminology
(for example, 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, and so
on. 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 in some organizations, Arena has been used for a
wide spectrum of simulation studies, from long-range planning to analysis of nearterm 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 for 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.
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 Arenas hierarchical templates, a template
can be built that is fully customized to represent accurately the elements of systems in
the industry, rather than 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, and so on,
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
26
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 templates
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 Arenas 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 dialog boxes); and parts, processes, and so on, in the
target application environments can be represented accurately.
In some cases, a modeler might build a template for his or 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, and functions. Later, objectoriented 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 can reuse and that can be customized in each use.
By permitting you to collect all of the important characteristics of a simulated system
element (that is, 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
modules definition. The second approachbuilding 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 modeling approach you have developed.
27
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 box 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 can be helpful to review 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
box design, logic, user view, and panel icon) to create the module. Finally, we use the
module to build 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 use
this Printer module will contain entities representing print jobs.
Our Printer module will be analogous to a server; that is, 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 type of paper used by 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
29
restriction on the flexibility a modeler has to tailor the module to represent a

particular system accurately.
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 provide other options for the modeler.
The Printer module dialog box is shown in Figure 3.1.
Figure 3.1 Printer module dialog box
In the Printer module, the modeler enters 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, that is, 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 Arenas Basic Process panel is used. Stepby-step instructions for creating this logic are presented later in the chapter.
30
3 MODULE-BUILDING TUTORIAL
Figure 3.2 Printer module logic
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 to 0 and changes a variable that records
the last job type processed on the printer (to the entitys job type).
If no changeover is 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. If a changeover
is required, the entity enters 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 can either build the submodel directly in the
logic window of the module definition or you can prepare an Arena model with the
same logic. If you build the logic first as an Arena model, you can use Arenas 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 modules
logic window using Arenas clipboard.
31
For the purposes of this tutorial, however, we present the Printer module by defining
the logic directly in the module definitions logic window. In this way, we can discuss
both the sample problem to be addressed (that is, the high-speed printer station
module) and the particular aspects that relate to creating modules. You might 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, and 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 box 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 box design
window, which we find to be a natural way of creating a complete module definition.
Getting startedA 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
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 can be edited),
the name displayed in a template panel if the display type is text (rather than
icon),
the default name of the modules main dialog box object (defined in the dialog
box design window),
the default title of the modules main dialog box, 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, click 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: To save the template panel to a template panel library (.tpl) file, select the File >
Save menu item from the main menu bar.
Dialog Design
The dialog box design window
We begin designing the Printer module by defining its dialog box design and its
operands. Open the dialog box design window by selecting the Printer module (in the
template window's Module Definitions list), and 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 box design interface for the
Printer module, as shown in Figure 3.4.
33
Figure 3.4 Dialog box design window
The dialog box design window consists of the following components:
Dialog Formthe dialog box form layout is displayed in the center of the
window.
Toolboxprovides an interface for adding controls (for example, text boxes,

combo boxes, or dialog box buttons) and static graphics (for example, text, lines,
or group boxes) to the dialog box form layout(s).
Operand Explorerdisplays the hierarchical organization of the dialog box

form, operand, and repeat group objects that define the dialog box structure of the
module.
Design Propertiesprovides an interface for viewing and/or editing properties

of the currently selected object(s).
When a module definitions dialog box design window is opened, by default the main
dialog box form of the module is displayed in the center of the window. Thus, for our
Printer module definition, we see a dialog box form named Printer. This is the
dialog box 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 box form, go to the Design Properties
window. This window should display the properties of the Printer DialogForm object.
34
Edit the Height and Width property rows and enter a height of 110 and a width of
170.
Figure 3.5 Design properties of the Printer DialogForm object
You can also resize a dialog box 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 modules dialog box operands

The Printer modules dialog box will include four visible operands can be edited 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 box form layout and module
definition:
1. Click the ComboBox control in the Toolbox section. Then, move the pointer to
the location in the dialog box form where the Printer Name operand is to be
placed. Left-click again to place the combo box on the dialog box form layout.
Note: At this point, your dialog box form layout cannot resemble the form in Figure 3.1.
You will learn how to arrange the operands 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
35
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 box
form.
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 box for specifying characteristics of
the operand related to its purpose in the modules 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 box is completed
according to Figure 3.6.
Figure 3.6 Logic properties of the Printer Name ComboBox object
36
The items that will be displayed and available for selection in a ComboBox operands
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.
TECHNICIAN, CHANGEOVER TIME,
AND
PRINT TIME
OPERANDS
The three remaining visible operandsTechnician, Changeover Time, and Print

Timeare 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 operands
type is also specified as Element of type RESOURCES. The operands 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 that can be seen and edited by users in the
modules dialog box, 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, which
allow the user to connect other 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 in the dialog box. However, graphical entry and
exit points will be available in the modules user view to place the module
connections.
To add a hidden operand to the module definition, click the HiddenOperand control in
the Toolbox section. Then, move the pointer to any location in the dialog box 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 box design (and also in the Operand
Explorer tree) as shown in Figure 3.7.
37
HiddenOperand object
Figure 3.7 HiddenOperand object in the dialog box design window
After adding two hidden operands to the dialog box 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
Figure 3.8 Logic properties of the Label HiddenOperand object
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 modules operands.
Controls that have been placed onto a dialog box forms surface can be selected,
moved, and resized. Arrange the combo box and text box controls on the Printer
39
dialog box form such that the layout looks like Figure 3.1. The completed dialog box
design window for the Printer module should look similar to Figure 3.10 below.
Figure 3.10 Completed dialog box design for Printer module
You can close the dialog box design window by clicking the Window Close button,
or you can leave the dialog box 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 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
40
tutorial, we assume that you already are familiar with the basic interactions for
building models in Arena.
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 described previously 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 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 templates Create module and
specifying an entity type, which will assign the internal attribute Entity.Type equal to
that type. This aspect of module designwhether to predefine information or to
provide options to modelersoften 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
41
module logic. As you create the module, it can 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 printerThe Queue

and Seize modules
The first module instance in the Printer logic is the Queue module from the SIMAN
templates Blocks panel. Entities are first created in another module in the model,
such as a Create module. A graphical connection from that module sends entities into
the Printer module, where entities begin processing through the Printer module logic
at this Queue module. In its dialog box, 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 (that is, `Printer Name`). In this case, our
queue name will have the _Q appended so that it is different from the resource
42
name. The label field for the queue, which represents the graphical entry into the
Queue module, contains a reference to the hidden operand `Label`.
Figure 3.12 Queue module dialog box in printer logic
Alternatively, you could use 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. 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
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 box for the Seize module instance.
Figure 3.13 Seize module dialog box in printer logic
Deciding whether to changeover the printerThe 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 box for the Decide module instance is shown in Figure 3.14. The dialog
box 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
44
the entity attribute 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 box in printer logic
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 logicAssign, 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
box 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
The first Assign module dialog box 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. 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
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.
Figure 3.16 Process module dialog box 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 assignment, select Variable for the assignment type
47
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 logicDelay and Release modules

After a print job entity completes the changeover logic, it 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
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, reference the Print module operand by
typing `Print Time` in the Duration field, as shown in Figure 3.18. The SIMAN
48
block does not specify a time unit, such as hours or minutes. The default time units
for modules is set later in this example using the Run > Setup menu.
Figure 3.18 Delay module dialog box in printer logic
The Release module 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
49
module. This allows entities to flow from the Printer module to the next module to
which it is connected. Figure 3.19 shows the dialog box for the Release module.
Figure 3.19 Release module instance dialog box in printer logic
As we mentioned previously, the Enter or Station module can be used to enter into the
module, instead of connecting into the Queue module. We can use a Route module or
Leave module to send entities to another station in the model. In this case, a Next
Activity operand would be required to specify where to send the entity instead of
connecting from the Release module. Additionally, the Stations element would need
to be generated.
Defining the Printer module elementsQueues 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
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.
Figure 3.20 Queues module dialog box in printer logic
51
Similarly, the `Printer Name`_Change variable can be generated by placing a

Variables module instance from the Elements panel. In the module, add a single
variable, named `Printer Name`_Change, as shown in Figure 3.21.
Figure 3.21 Variables module dialog box in printer logic
52
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, 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.
The logic for the Printer module now is complete. You can close the logic window by
selecting the Close option from the logic window menu, or you can leave the window
open while you define the last two parts of the Printer modulethe user view and
panel icon.
Note: In this example, we use the logic window to create two elements associated with
the printer, the queue, and the changeover variable. These elements could also be
generated by using hidden element-type operands in the dialog box 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 see 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 (for example, a model window),
the objects that are added to the window are created in the module definitions user
view window.
The user view for the Printer module will contain six objects:
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 box. Arena places the displayed operand in the user view window
after the Printer Name operand was defined with the InUserview property specified
53
as True (in the dialog box 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.
To open the user view window, select the Window > User View menu item or click
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 it to open the Animation
Resource dialog box. In this dialog box, 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
Figure 3.23 shows the completed resource picture dialog box for the Printer module.
Figure 3.23 Animation resource picture dialog box
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 complete), the global symbol will then disappear, since no
55
picture is specified for a trigger value of 0. Figure 3.24 shows the completed global
picture.
Figure 3.24 Animation global picture dialog box
The global picture is used instead of animating the `Technician` resource who
performs the changeover. This is done because the technician can 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 modules
definition). It is drawn in a window that is similar to the picture edit window used to
create animation resources, entities, and so on.
56
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 the name so you can change this to the whole word
Printer. This results in a panel icon shown in Figure 3.25.
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.
57
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 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
files 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
box design window, the operands referenced in the user view window are defined,
and so on
If you correctly followed the instructions for building the Printer module, you will
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 windows 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 box for
the object containing the error (that is, the Delay module instance). You can type the
correction in the dialog box and select OK, then generate the .tpo file.
Warnings, on the other hand, do not have to be resolved. The .tpo file will be
generated 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 connecting each Create module to the Printer module. Once jobs complete the
printing process, they are sent 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
58
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.
Figure 3.26 shows the completed model; step-by-step instructions for building the
model follow.
Figure 3.26 Sample simulation model using Printer module
GENERATING
PRINT JOB ENTITIESTHE
CREATE
MODULE
To build the model, begin by opening a new model window. The first two modules to
be placed are Create modules from Arenas 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
constant 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
59
change the 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 box for Entity 1 jobs
Figure 3.28 Create module dialog box for Entity 2 jobs
PROCESSING
THE PRINT JOBSTHE
PRINTER
MODULE
To use the Printer module you have defined, you need to attach a second panelthe
template panel object file you generatedto the Project Bar. Attach the panel and
select the .tpo file you named earlier (for example, HSPrint.tpo).
Note: If the file you created does not appear in the list, you might have forgotten to
generate the .tpo file after correcting errors. Open the template window and click the
Generate toolbar button to create a template panel object file.
60
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 doubleclicking the Printer module handle. Figure 3.30 shows the completed Printer module
dialog box.
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 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
used 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 box
61
FINISHED
PRINT JOBSTHE
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
SETUP MENU
AND RUN LENGTH INFORMATIONTHE
RUN >
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 (that is, 10
Entity 1 jobs and one Entity 2 job). With a changeover time of .2 minutes, we can
predict that the changeover technician will be used 4% of the time. This is calculated
by two changeovers (at .2 minutes per 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% (that is, there should be 5.5 minutes
11*0.5of 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. As you step through the
first entitys 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
62
changeover time. Figure 3.31 shows the animation of the Printer module during the
first changeover.
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, and
so on. At the end of the simulation, you are asked if you want to view the simulation
results. The Category Overview report is generated to show overview information on
entities, queues, and resources. These reports can 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 (that is, 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.
63
Figure 3.32 Resources report showing Resource Detail Summary
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. You can also attach its template panel object file
to the Project Bar and use it in the logic window of another modules definition to
create new template panels.
64
The Template Window

Arenas template development features center around designing and creating
templates consisting of modules. These modules can 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 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 box design, logic, switch, user view, and panel iconthat 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. When you open a template window, the Template Development toolbar
appears. A new template window is shown in Figure 4.1.
Figure 4.1 New template window

65
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, 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 module name and click the Edit button. A dialog box opens that
prompts you for the new module name. Two check boxes (Required and Data
Module), a field for Name Operand, and an Expression Builder Definitions button are
also in the module definition dialog box. Please see 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 box will open 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 box 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 be displayed in the Error window.
The warnings and errors created by checking template panels are displayed using the
same 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 correct the error when you click
the Find or Edit button 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 modules 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
67
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 box of the object that caused
the error or warning so that you can directly correct the error.
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. 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. 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
box design window and the definitions of switches for the module definitions in a
template panel file. (See The Dialog Design Window and The Switch Window
chapters for a description of operands and switches.) These reports can aid you in
designing dialog boxes and in validating the definition of switches in complex
68
modules. To view these reports, choose the Check > Report menu option from the
main menu bar. The report dialog box is opened, as shown in Figure 4.4.
Figure 4.4 Template panel Report dialog box
You can elect to view the operand or switch report; you also can 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 can 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
can print the report using the File > Print item.
OPERAND POSITIONS
REPORT
The Operand Positions report contains a listing of all operands, repeat groups, and
dialog boxes in a table providing their display locations in the module dialog box.
Hidden operands are designated with (HD) following their names, repeat groups with
(RG), and dialog boxes with (DB). Figure 4.5 shows a sample Operand Positions report.
69
Figure 4.5 Sample Operand Positions report
OPERAND PROMPTS
REPORT
The Operand Prompts report 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.
70
SWITCH
REPORT
The Switch report 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 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 can make to the template panels you create.
Template options
A number of additional characteristics of template panels can be changed using the
Template Options dialog box. To open it, select the Edit > Template Options menu
71
item from the main menu bar. The Template Options dialog box is opened, as shown
in Figure 4.7.
Figure 4.7 Template Options dialog box
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. You can
change the name that is displayed on the panel by typing the new label in the
Template Display Name field and choosing OK.
Note: Changing the display name does not modify the name of the .tpl/.tpo files; it
provides a new text string to be displayed on the top of the panel.
CREATING PRIVATE
TEMPLATE PANELS
You might 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 box and choose OK. If you distribute a template panel
containing a module definition that has a private panel attached, you must provide the
private template panels .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.
72
CHANGING
THE DEFAULT PANEL DISPLAY
The default display of the modules in the template panel can be changed for each
template you create. You can set the default display to be Large Icons, Small Icons, or
Text only. After attaching the template panel to the Project Bar, you can change this
setting by right-clicking while hovering inside the Project Bar and then selecting the
desired option from the shortcut menu. By default, small and large icons are
displayed in two columns and text-only is displayed in a single column. The display
can 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 the Help button in the module dialog box. If Separate Help
Items is selected, the two actions described above will display two different help
topics. This might 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 box 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.
See the 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 box that is used
to define a new name for a module, as shown in Figure 4.8. It also indicates whether a
73
module will be required in any model that uses it. If the Required check box is
selected, the module is defined as required.
Figure 4.8 Module Definition dialog box 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 can be sent to perform by
other modules in the template.
Defining data modules

Another option in a modules Module Definition dialog box, displayed when you click
the Add 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 using 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 can be created automatically by logic
modules. For more information on the Auto-Created feature, see Auto-Creating
modules on page 96.
Defining a name operand

Another option in a modules Module Definition dialog box is the Name Operand
field. If you choose an operand from a module to be designated as the modules Name
74
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 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 modules 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 modules ResName will be passed to the
Resource modules MyName operand.
The operand specified in the Name Operand field must first be defined in the dialog
box design window. Also, it must be visible (generally, it is displayed in the
spreadsheet) and is non-repeatable. Dialog boxes and Repeat groups cannot be
specified in this field.
Expression Builder Definitions

The Expression Builder Definitions button opens a dialog box that allows you to
define expression builder strings for the module definition. The expression strings
will be available in the Expression Builder tree-view if a module instance is placed in
the model.
See the Help topics The Expression Builder and Expression Builder Definitions
for more information.
Creating copies of module definitions

The clipboard can 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
75
.doe/.tpl files even if you make changes to the dialog box design or switch windows
of module definitions. For example, if you have a template panel file, bank1.tpl,
containing modules named Customers, 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 change the definition of either the
Customers or Tellers module (by changing the dialog box design, logic, switch, user
view, or panel icon windows).
Examples of changes you can 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), and changing repeatable data into nonrepeatable data (by removing the repeat group object). We make every attempt to use
the data in existing 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 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 template panel file.
76
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 modules dialog box or viewing a modules fields
in the module spreadsheet.
The dialog box design window is Arenas interface for designing the dialog
boxstructure and dialog box form layout(s) of a module. In this window, a module
designer defines dialog box sizes, the data that is presented 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 box design window
interface. The second part of this chapter describes the user interface controls that are
be placed in a module's dialog box. These include form, operand, and repeat group
objects, as well as controls for user input and displaying 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 box design window is opened by selecting a module (in the template
windows 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 box form layouts for the module. Its
interface includes an Operand Explorer section to browse all of the dialog box form,
operand, and repeat group objects in the module definition; a Toolbox section to add
user interface controls to dialog box forms; and a Design Properties grid to edit the
properties of one or more selected objects.
77
The Operand Explorer

The dialog box design windows Operand Explorer (located in the top-right corner of
the window) displays the hierarchical organization of the dialog box form, operand,
and repeat group objects that define the dialog box structure of the module.
Figure 5.1 The Operand Explorer
The root node of the explorer tree is the modules main dialog box form. This is the
dialog box that is first displayed when the modeler double-clicks an instance of the
module in a model or logic window.
The dialog box form, operand, and repeat group objects that define the structure of the
modules interface are displayed in the explorer tree according to the specified
hierarchical relationships. The objects are displayed using the string format TabIndex:
ObjectName [SwitchName]. The dialog box or repeat group object that is highlighted in
bold indicates which dialog box form layout is currently open in the window.
In the explorer tree, you can select, delete, cut, copy, and paste objects. Objects can
also be dragged and dropped in the tree to change the hierarchical relationships.
Double-clicking an object in the tree automatically opens the dialog box form
associated with the object and selects the object. You can also click the View Dialog
Form button ( ) to perform this action.
78
5 THE DIALOG DESIGN WINDOW
The functions of dialog box form, operand, and repeat group objects are described
further below.
DIALOG FORM
OBJECTS
A module definition contains one or more dialog box forms to display choices and
accept input from modelers into instances of the module.
By default, every module has a main dialog box form. This is the dialog box 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 can be too much information to place in a single dialog box. You
can add a new secondary dialog box form object to nest information by placing a
DialogButton control from the Toolbox onto a dialog box forms layout.
OPERAND
OBJECTS
An operand object is an object in the module definition that contains a single value
and (if not disabled or hidden) can be edited with a user interface control by the
template user. For example, in the Stop module of Arenas Advanced Transfer panel,
there is an operand for the modules Name field, and an operand for the modules
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 box
forms layout.
Hidden operands. In some cases, it is not desirable for a particular operand to be
visible to the modules 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 can provide the capability for defining a list of multiple (or repeatable)
fields. For example, the Assign module from Arenas Basic Process panel allows you
to assign values to a list of variables, attributes, and so on. 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 box forms layout. Use
the RepeatGroupDialog control if the repeating data is to be entered using a
secondary dialog box form. Use the RepeatGroupTable control if values for a single
repeatable field are to be entered into a table.
79
The Toolbox
The dialog box design windows Toolbox (located on the left side of the window)
provides an interface for adding user interface controls (for example, text boxes,
combo boxes, or dialog box buttons) and static graphics (for example, text, lines, or
group boxes) to a dialog box form layout.
Figure 5.2 The Toolbox
To add a control from the Toolbox, first click the desired control in the Toolbox
section. Then, hover the pointer over the location in the dialog box form where the
control is to be placed. The pointer will change to a cross hair with the selected
controls icon displayed at the top and right of the cross hair.
Controls are placed in the dialog box form by one of three methods. Once your
control has been selected, you can click 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 dragand-drop directly from the Toolbox to the dialog box form.
80
Table 5.1 Summary of Toolbox controls
Control Name
Description
Text
Used to display a simple text string on a dialog box 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 box 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 box form.
RepeatGroupDialog
Used to allow a user to enter values for multiple (or repeatable)

sets of fields from a secondary dialog box.
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

(that is, not displayed in the module dialog box).
81
The dialog box form

A dialog box 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 box form is
defined by placing controls from the dialog box design windows Toolbox onto the
forms surface.
When the dialog box design window for a module definition is opened, by default the
main dialog box form of the module is displayed in the center of the window. This is
the dialog box that 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 box design window
OPENING
A DIALOG BOX FORM
A module definitions dialog box design can contain more than one dialog box form.
For example, in addition to the main dialog box, the interface can include one or more
secondary dialog boxes accessed using DialogButton or RepeatGroupDialog
controls.
To open the dialog box form associated with or containing a particular object in the
module definition, double-click that object in the Operand Explorer. Or, alternatively,
82
you can select an object in the Operand Explorer and use the View > Dialog Form
menu item or click the View Dialog Form button ( ).
Double-clicking a DialogButton or RepeatGroupDialog control in a dialog box form
layout will also automatically open the dialog box form associated with that control.
RESIZING
A DIALOG BOX FORM
To resize a dialog box form, 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 can also enter specific dimension values for a dialog box form by selecting the
form and then editing the Height and Width properties in the Design Properties grid.
ARRANGING
CONTROLS ON A DIALOG BOX FORM
Controls that have been placed onto a dialog box forms surface can be selected,
moved, and resized.
Multiple controls can be layered, aligned, equally sized, or spaced using menu
commands available from the Format menu.
You can 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 BOX FORM
When designing the user interface on a dialog box 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 box forms controls.
Locking controls prevents them from being dragged to a new size or location on the
forms 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 box design windows Design Properties grid (located in the bottom right
corner of the window) provides an interface for viewing or editing properties of the
currently selected object(s).
83
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 box form that is currently open in the
window. The combo box can 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 box design windows Toolbox.
Using the Text control

A Text control can be used to display a simple static text string on a dialog box 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 controls height.
84
Using the GroupBox control

A GroupBox control can 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 can be used to draw simple line segments on a dialog box form.
To draw a line on a dialog box 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 can
be used to get input from the user or to display text.
A TextBox control has two parts: a prompt label and a box. You can 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 can 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.
In the module definition, operand object values can be referenced (by enclosing the
operand objects name in back quotes, for example, Òperand1`) 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

A ComboBox control adds an operand object to the module definition. The control
can be used to display and edit data in a drop-down combo box. The control displays
85
an edit box with a down arrow at the right side of the box. Clicking the arrow reveals
a drop-down list from which the user can select an item.
A ComboBox control has two parts: a prompt label and a combo box. You can select,
move, and resize the prompt label and combo box separately on the dialog box 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 can be entered as a value is specified by the DataType property.
The list of items displayed and available for selection in the combo boxs drop-down
list are defined by the List property. Set the PickFromListOnly property to True if you
want to limit a users input to what is on the list. Otherwise, a user will be able to type
choices not on the list into the combo boxs edit field.
Using the RadioButtonGroup control

A RadioButtonGroup control adds an operand object to the module definition. The
control can 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 want to have a group box drawn around the
prompt label and radio buttons. The column arrangement of the radio button options
can also be customized using the NumberOfColumns and ColumnWidth properties.
86
Using the CheckBox control

A CheckBox control adds an operand object to the module definition. The control can
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.
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.
Using the DialogButton control

A DialogButton control adds a secondary dialog box 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 box button.
To open the secondary dialog box form associated with the DialogButton control,
double-click the controls dialog box form object in the Operand Explorer. Or you
can select the object in the Operand Explorer and use the View > Dialog Form menu
item or click the View Dialog Form button ( ).
Double-clicking a DialogButton control in a dialog box form layout also
automatically opens the dialog box 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 box form
that is accessed by selecting the repeat groups 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 box form associated with the RepeatGroupDialog
control, double-click the controls repeat group object in the Operand Explorer. Or,
87
alternatively, you can select the object in the Operand Explorer and use the View >
Dialog Form menu item or click the View Dialog Form button ( ).
Double-clicking a RepeatGroupDialog control in a dialog box form layout will also
automatically open the dialog box form associated with that control.
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 can be used only if there is to be exactly one operand
field in the controls repeat group whose value is editable by users (referred to as the
RepeatGroupTableOperand). The repeat group can 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
controls repeat group, double-click the controls repeat group object in the Operand
Explorer. Or alternatively, you can select the object in the Operand Explorer and use
the View > Dialog Form menu item, or click the View Dialog Form button ( ).
Double-clicking the RepeatGroupTable control in a dialog box form layout also
automatically opens the dialog box 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 parts: a prompt label and an edit box. You can
select, move, and resize the prompt label and box separately on the dialog box form
using the mouse.
The controls edit box has a down arrow to the right of the box (similar to a
ComboBox control). Clicking the arrow displays a calendar with the current date
value circled. The modeler can change the date portion entered into the control by
88
selecting either a different day in the current month or by using the calendar arrow
keys to specify a different month.
To edit the time portion of the control, click 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 Value property. If the Value property is not specified, then the controls default
value will be the current date/time.
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 parts: a prompt label and an edit box. You can select,
move, and resize the prompt label and box separately on the dialog box form using
the mouse.
The controls edit box has a down arrow to the right of the box (similar to a
ComboBox control). If the arrow is clicked, a calendar appears with the current date
value circled. The modeler can change the date by selecting either a different day in
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 controls default value will be
the current date.
89
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 parts: a prompt label and an edit box. You can select,
the mouse.
The TimePicker controls 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 can 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.
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 controls default value will be
the current time.
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 can enter a valid file name or click the browser to search for the file.
A FilePicker control has two parts: a prompt label and an edit box. You can select,
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 controls Browse for
File dialog box (that is, the choices in the Files of type drop-down list). Enter a filter
string using the format Description1|Pattern1,Description2|Pattern2, and so on.
90
An example of a filter string is: "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 (*.*)|*.*"
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 (that is,
not displayed in the module dialog box).
A hidden operand is normally used to store data that is necessary for the modules
logic, but which isnt 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.
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 modules
dialog box 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 in the dialog box form automatically defaults to the Name of the operand.
91
An operands name can be used (by enclosing the name in back quotes, for example,
Òperand1`) to reference the operands 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.
Specifying the LogicProperties property

All operand objects have a LogicProperties property available in the Design
Properties grid. This property provides a dialog box for specifying characteristics of
the operand related to its purpose in the modules interface and logic.
Figure 5.5 The Logic Properties dialog box for an operand object
In the Logic Properties dialog box, the operands 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 stored with each module
instance. Basic operands are often used to 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.
92
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 box:
Element TypeThe type of SIMAN element that the operand will define or
reference. Select the desired type from the list. The operands value will be used as
the name of the element of the selected type (for example, an operand with value
Operator will define or reference a SIMAN element with name Operator).
SublistThe sublist partition of elements (by Element Type, such as resource) of
which this operands element is to be a member. For example, the element type
Resources might have sublists for Operators and Machines.
Define/ReferenceIndicates whether the element that is created by this operand
should be defined for the simulation model or whether it only should be referenced. If
Reference 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 defined in a module.
For more information on the use of elements and their properties, see Chapter 10.
PROPERTY
OPERAND
An operand can be used to represent the value of a SIMAN elements property, such
as the capacity type of a resource.
If the Type is specified as Property, then the following fields are displayed in the
Element OperandName of the operand that is defining the SIMAN element in this
module of which this property operand is associated.
Element TypeType of SIMAN element defined/referenced by the Element
Operand. This field cannot be edited; it is provided for information only.
Property NameName of the element property that this operand defines, selected
from a list of valid properties associated with the Element Type.
Read OnlyThis option is available for HiddenOperand controls only. If enabled, the
hidden operand will read into its value the current value of the element property with
which it is associated. The elements property value will NOT be overwritten by the
operands default Value entry. The default value defined for the hidden operand will
93
only be written to the elements property value if that property has yet to be defined
(that is, the current value of the property is null).
For more information on the use of elements and their properties, see Chapter 10.
ENTRY POINT
OPERAND
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
modules user view for the operand so that the exit point of another module can be
connected to it.
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 operands 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; for example, 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 can be connected to the entry point of
another module.
There can be multiple exit point operands in a module definition. For example, you
can design a module that performs an inspection-type process, in which case, two exit
points can be required, one for entities that pass inspection, and one for entities that
do not pass inspection. Exit points also can be repeatable, as can be seen in the
Decide module of the Basic Process panel. A repeatable exit point (that is, 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.
94
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; for example, 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. See the Tables appendix topic Entry or exit point types on page 275 for
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 (for example, 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 can have switches attached to them. If an entry or exit
point has a switch and the operand is switched out, the operands field will not appear
in the modules dialog box and the graphical symbol will not appear in the modules
user view.
Entry and exit point operands can also be hidden operands (that is, 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 modules dialog box; however, the
graphical representation of the entry or exit point still appears, offering a way to
connect 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.
95
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
cannot 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 operands value is passed to the data modules Name Operand. 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 box) called Name, and another module called Process has a
Resource Name operand that auto-creates the Resource data module, the value of the
Process modules Resource Name will be passed to the Resource modules Name
operand, as long as Resource Name is not blank.
In general, operands that use the Auto-Created feature should be defined as Elementtype 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 (that is, 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 autocreation in the Logic Properties dialog box, then specify the Template Name and
Module Name 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.
96
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 can be literal, can reference other operands, or
can be a combination of the two.
The acceptable data type for an operands value that can be entered by a user is
specified using the DataType property. The data type property is described in more
detail beginning on page 101.
It is not possible to have a blank value for an operand that has a default value
specified in the dialog box 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 can be referenced by entering the
operands 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 operands Value property has been specified in the
dialog box design as `Server Name`_RES. 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.
COMBINING
REPEATING OPERAND VALUES INTO A SINGLE VALUE
When designing a module, you can 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 box 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 103.
97
SPECIAL
REFERENCEABLE FUNCTIONS
A set of special functions is available that will provide, in an operands 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.
Some of the functions that are available can be used to access information entered
into the Project Parameters and Replication Parameters tabs of a models Run >
Setup dialog box. 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 box.
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(TimeVal Converts a time value of time units into a time

ue, TimeUnits)^
value of base time units (as specified in Run >
Setup > Replication Parameters).
^RATE_TO_BASE_RATE(RateValu Converts a rate value of time units into a rate value
e, TimeUnits)^
of base time units (as specified in Run > Setup >
Replication Parameters).
^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()^
98
Provides access to the title of the simulation

project, as taken from the Project Parameters page.
Function
Description
Ânalyst_Name()^
Provides access to the analyst name for the project,

as taken from the Project Parameters page.
Ûse_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.
Ûse_Entities()^

turning on and off entity attributes and statistics for
the simulation model, as taken from the Project
Parameters page.
Ûse_Resources()^

turning on and off resource statistics for the
Parameters page.
Ûse_Tanks()^

turning on and off tank statistics for the simulation
model, as taken from the Project Parameters page.
Ûse_Queues()^

turning on and off queue statistics for the
Parameters page.
Ûse_Transporters()^

turning on and off transporter statistics for the
Parameters page.
Ûse_Conveyors()^

turning on and off conveyor statistics for the
Parameters page.
Ûse_Processes()^

turning on and off process statistics for the
Parameters page.
99
100
Function
Description
Ûse_Stations()^

turning on and off station statistics for the
Parameters page.
Ûse_ActivityAreas()^

turning on and off activity area statistics for the
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.
Înitialize_System()^

initializing the system between simulation
replications, as taken from the Replication
Parameters page.
Înitialize_Statistics()^

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 warmup period, as taken from the Replication
Parameters page.
^Terminating_Condition()^
Provides access to the terminating condition that

can 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.
Function
Description
^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.
This property specifies the acceptable data type of the operands Value property.
Data types define what a user is permitted to enter for an operand value. When a user
clicks OK in a modules dialog box, the value entered for each field is checked
against the operands data type to determine whether the value entered is valid. If the
entry isnt valid, an error will be displayed and the pointer will move to the offending
operand field.
Depending on the control type, an operands data type can or cannot 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 (for example, integer).
The available data types are described below.
STANDARD
DATA TYPES
AlphanumericAllows any string containing alphabetic and numeric characters as

well as embedded spaces.
AnyCharacterAllows any string of keyboard characters.
ExpressionAllows any valid numeric expression. It can contain combinations of
letters, numbers, and standard arithmetic operators. An expression data type can
contain both mathematical and logical expressions.
IntegerAllows any valid non-negative integer value. If a data type is specified as
Integer or Real, you can specify minimum and maximum limits for the operand.
101
LabelAllows any alphanumeric characters plus the special characters @, _,

%, and #. It must contain at least one special character or letter. (It should not
contain only numeric characters with single e or E, which could be confused with
a number written in scientific notation.)
RealAllows any positive or negative real value. If a data type is specified as Integer
or Real, you can specify minimum and maximum limits for the operand.
SymbolNameAllows any alphanumeric characters plus the special characters @,
_, %, and #. It must contain at least one special character or letter. (It should
not contain only numeric characters with single e or E, which could be confused
with a number written in scientific notation.)
Note: Symbol names can have an unlimited length, but only the first 255 characters of
a symbol name are actually considered when evaluating an expression.
YesOrNoAllows 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.
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 264.
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 switchs condition is
False, the object will be disabled or hidden in the dialog box according to the
SwitchedOutAction property.
Switches are defined in the Switch window. See The Switch Window on page 175
for more information on switches.
If a referenced operand is switched out, its value is null.
A switch can also be attached to or detached from an object by using the Object >
Switch > Attach or Object > Switch > Detach menu commands.
102
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 modules user view.
The InUserView property is helpful when you want the modeler to see information
about a modules operand values without opening the modules dialog box.
Hidden operands
In some cases, it cannot 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 can 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 modules
dialog box. However, a graphical representation of the connection point will still
appear in the modules user view, allowing users to connect into or out of the module.
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.
Using repeat groups

Some modules allow you 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, and so on. 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 box forms layout. A
RepeatGroupDialog control is used if the repeating data is to be entered using a
secondary dialog box 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.
103
The maximum length of a name is 31 characters, and it must be specified using

alphanumeric characters.
A repeat groups 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 107 and Combining
repeating operand values into a single value on page 107.
Specifying the LogicProperties property

All repeat group objects have a LogicProperties property available in the Design
Properties grid. This property provides a dialog box for specifying characteristics of
the repeat group related to its purpose in the modules interface and logic.
Figure 5.7 The Logic Properties dialog box for a repeat group object
In the Logic Properties dialog box, the repeat groups Type is specified as Basic or
Property.
BASIC
REPEAT GROUP
A basic repeat group does not serve a special purpose and functions merely as an
interface for the modeler to access a set of repeatable operands.
PROPERTY
REPEAT GROUP
A repeat group can also be used to write values to a SIMAN elements property. The
property must be a repeatable property. For example, a repeat group can be used to
104
write values to the Members property of a SETS element (as multiple members can
be defined in 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
module of which this property repeat group is associated.
Element TypeType of SIMAN element defined/referenced by the Element
Property NameName 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 183.
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 box design window or in modules in the logic window and the operands are
not defined as properties that should be in a repeat group, then there are no rules that
need to be followed.
The following restrictions apply when referencing a repeatable operand (that is, an
operand contained in a repeat group in the dialog box design) in a module field in the
logic window:
1. A repeatable operand cannot 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 cannot 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 box 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 (an ordered list) 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.
105
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 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
106
Accessing the number of tuples and the tuple number

As you are building a module, you can 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 that a modeler has inserted into the repeat
group of name repeat group name. It can be used in the Value property of an operand
object outside of the repeat group, or in a module field in the logic window.
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
referenced in a switch definition.
^Line_Number()^
This function returns the index of the current tuple in the repeat group. It can be used
in the Value property of a repeating operand object that is contained directly in a
repeat group in the modules dialog box design.
An example of where the Line_Number function has been used in the standard Arena
templates is in the Basic Process panels 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 modules dialog box.
Combining repeating operand values into a single value

When designing a module, you can 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 box 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 box object named Customer Arrivals
has been added to a Customers module definition. Using the Repeat Group dialog
box, a modeler will specify the CustomerType and CumulativeProbabiltity.
107
Figure 5.10 Dialog design of Customers module
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,
and so on.
In the module field in the logic window, the template developer enters the expression
string: DISCRETE(0,0`Customer Arrivals`).
To place separators (that is, 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 objects value with
respect to other object values contained in the same repeat group and is specifically
108
used for determining value order when combining a repeat groups 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
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 in the dialog box design window. See the
Repeatable modules section on page 139 in The Logic Window chapter for more
detailed information.
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 can 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 (for
example, Process &Name to set the N to be the accelerator key).
109
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 (for example, Option 1|Option &1).
It is a good design practice to identify unique accelerator keys in any single dialog
box.
Dialog Design toolbar

While working in the dialog box 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 any visible toolbar and choose Dialog Design from the list.
110
The 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 can 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.
The decomposition of this activity could naturally be represented using Arenas
hierarchy. No matter what design you select for the modules, you will need to model
each of the lowest-level activities (for example, 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 (for
example, 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 operandsto build a Truck Entry module, you must decide
which options will be changeable (for example, time between truck arrivals, truck
type) by users of the module.
111
The logic window

A modules logic window defines a submodel; that is, 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 window in almost all respects; we discuss the differences
between these two windows in the next section of this chapter.
To open a module definitions 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 (that is, in model windows that will be stored as Arena .doe files)
or in module definitions (that is, 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 can be
placed in logic windows, as well.
112
6 THE LOGIC WINDOW
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 logic windows that are specifically related to defining modules: referencing module operands, connecting modules in the logic window, and switching
module instances in the 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)
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 (that is, both
contain instances of modules), most of the editing information for working in model
windows also applies to creating and modifying logic windows. Please see the Arena
Users Guide for information on attaching template panels, placing and editing
modules, connecting modules, and so on.
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 modules 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 modules logic window. In this way, you have the advantage of using
Arenas Run Controller to interact with the module logic.
113
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 can obtain values for its
operands by referencing operands that are defined in the module definitions dialog
box 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 Arenas 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 modules logic window), a new value can be given to the unload time
operand generating customized simulation logic. Referencing module data on
page 116 describes this topic.
Switching module instances (logic window)

When you are working in a logic window, you can attach switches to module
instances. A switch is merely 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 other module
switches, or both. (See The Switch Window on page 175 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 modules 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
(that is, it is switched out). This is described in more detail in Switches in logic
window module instances on page 124.
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 box 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, see Repeatable modules on page 139.
114
6 THE LOGIC WINDOW
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 can 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 can 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 148.
Attaching template panels while working in a logic

window
While in the logic window of a module definition in a given template (that is, .tpl
file), you cannot 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 cannot
place any modules from foodline.tpo into the logic window of any other module
defined in foodline.tpo.
Related to this, you cannot 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 cant 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.
115
So, Arenas 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 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 (for
example, levels and 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 (using 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 (that is, to create the logic for a module
definition) and the use of the module that we defined (that is, the creation of an
instance of it in a model or another modules logic window). We also have two
contexts for the term operand: the item that is presented in the dialog box of a module
instance in the logic window and the operand defined by an object placed in the
dialog box 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 instances dialog box as fields. We retain the term operand in its
context as the object that is part of a module definition.
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 can 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 box(es) containing the modules operands.
The tie between the dialog box 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 box(es) of the module being designed can be used in place of
specific values. To establish this link, you type the name of the operand that you want
116
6 THE LOGIC WINDOW
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 modelers
entry in the modules dialog box. Your selection of a modules 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 box design window: Time Between Orders and Order Size. In the Create
module instance that you place in the module definitions 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 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.
Note: If a module containing operand references is pasted into a model (.doe) window,
the fields containing references are restored to their default values.
117
Figure 6.2 Operand references example
CONCATENATING
TEXT TO OPERAND REFERENCES
When referencing an operand, you also can type text before or after the reference. For
example, you can 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 so that a modeler enters the percentage of incomplete orders (that is, 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 (that is, in the range 0.0 to 1.0), you would need to divide the entry
118
6 THE LOGIC WINDOW
of the modeler by 100. To 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 definitions logic window).
COMBINING
MULTIPLE OPERAND REFERENCES IN A SINGLE FIELD
Multiple operands can be referenced in the same field of a module instance in the
logic window. In this case, the values of the operands are concatenated to form the
complete value for the logic windows module instance. Also, text can 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 ask the modeler for the minimum
119
time and the maximum time. In this case, the Time Between Orders operand 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
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 modelers 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 so that only one operand will be switched in for any given set
of user inputs. (See 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, type each operand name enclosed in back quotes, one after the other.
120
6 THE LOGIC WINDOW
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 Delay module (from the Blocks panel). The modules
dialog box 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 box for an instance of the Order Verification module with
the Time to Check selected to be Time. Figure 6.6 shows the same dialog box 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 (for example, 2.5). The dialog box 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.
121
In the logic window for the Order Verification module definition, the Process Time
field of the Delay module would be defined as `Time`Àttribute` (with no
intervening spaces). The switched-in operand would supply its value to the Delay
module; the switched-out operand would have no value (that is, blank). The dialog
box for the Delay module instance in the logic window is shown in Figure 6.7.
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 can be made in three places
in a module definition: in the Value property of an operand object in the dialog box
design window, in the logic window (as described in this chapter), and in animation
objects in the modules user view. The same operand can be referenced from all three
windows and/or from multiple objects in 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 129.) 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
122
6 THE LOGIC WINDOW
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 (for example, `Clerk Name`_Cnt). The Process module
instance in the logic window contains the reference to 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. (See The Dialog Design Window or information about these control types.)
CheckBox and RadioButtonGroup controls do not allow direct typing of values in a
module instances dialog box. 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 box. To open this dialog box 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 box that is
opened allows you to type the operand reference for the radio button group or 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 box was
opened by right-clicking 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.
123
Figure 6.8 Operand reference for RadioButtonGroup and CheckBox controls

Note: After you have established a reference for a radio button group or check box
field, if you later click one of the options of a radio button group or the check box, the
reference information is removed and the radio button group or 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 instances dialog box 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 (for example, 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.
124
6 THE LOGIC WINDOW
Figure 6.9 Record module instance dialog box 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 can offer one or
both of these mechanisms for receiving entities into the module; modules can 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
(that is, route, transport, or convey to a named station), the modules 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.
125
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,
place a module instance that permits station transfer (for example, 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. 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.
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 modules user view to allow
modelers to connect modules together. The operand also can be displayed in the
module dialog box (often with a prompt of Label for entry points or Next Label for
exit points).
126
6 THE LOGIC WINDOW
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 in 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
Iin the dialog box in Figure 6.11, 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 by the Order Desk operand 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 box (that is, 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 modules definition.
127
If you use the Arena template in the logic window of a module (Basic Process,
Advanced Process, and Advanced Transfer panels), the direct transfer method of
entering a module is more complicated. The reason is because the label or 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 visible. (Please see the
chapter The Dialog Design Window on entry or 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.
Figure 6.12 Module logic with delay: 0.0 module to access Desk Label entry point
label
128
6 THE LOGIC WINDOW
Referencing non-repeating operands from a repeat group

The operand references that are made by module instances in a logic window can be
made from a repeating set of fields; this is treated identically to references from nonrepeating fields. (See 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
using the Process module from the Basic Process panel. The Clerk Name operand
(non-repeating) will be used in a resource repeat group.
This example will 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 in repeat group
129
Non-repeating operands can 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 can 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
130
6 THE LOGIC WINDOW
Referencing repeating operands

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 (that
is, operands that have been defined as members of a repeat group in the modules
dialog box 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, lets 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 box for the Order Entry module might be designed as shown in Figure
6.15. This dialog box 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 that defines the attribute to be
assigned and a Value operand that specifies the assignment value, and
a Next Activity operand that determines the activity to which the entity will be
sent.
131
Figure 6.15 Order Entry module dialog box
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.
132
6 THE LOGIC WINDOW
Figure 6.16 Reference from repeat group fields to repeating operands
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 window. Similarly, as a modeler edits the data (for example, 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 in 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, lets 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.
133
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
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.
134
6 THE LOGIC WINDOW
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 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.
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 repeat groups in the module definition.
135
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 instances repeat group, and the value of the nonrepeating 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 (that is, in the modules main dialog box).
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 can define a repeating exit point to your module as well, such that the modeler
using your module can select as many alternatives as necessary 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 box design window, place a TextBox
type of operand in a repeat group dialog box 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
136
6 THE LOGIC WINDOW
repeating exit point in the dialog box 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 linesCondition 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 box containing these operands.
137
Figure 6.20 Sort Orders module dialog box
In the logic window, the Process module references the Sorter Name and Sort Time
operands. The Branch modules Branch Types repeat group references the three
repeating operands of the sortation line moduleCondition 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 box 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.
138
6 THE LOGIC WINDOW
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 box 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.
To place a module repeater, open the modules 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 nonrepeatable 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.
139
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 box design
window, double-click an edge of the module repeater to open the Module Repeater
Settings dialog box (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 might 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 see 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.
140
6 THE LOGIC WINDOW
Example 1: Parallel logic

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 box design windows 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 box design window with repeat group route
times
141
Figure 6.24 shows the Sample dialog box with entry of three different types and route
times.
Figure 6.24 Sample dialog box with types and route times
The resulting model code is shown in Figure 6.25. The Assign module is repeated
once for each tuple in the Route Times repeat group.
Figure 6.25 Model code
142
6 THE LOGIC WINDOW
Example 2: Serial logic

Figure 6.26 shows the serial logic window module repeater with an Assign and Delay
block inside.
In Figure 6.27, the dialog box design windows Operand Explorer reflects repeat
group processes with operands Process Time and Associated State.
Figure 6.27 Operand Explorer in dialog box design window with repeat group
processes
143
The sample dialog box in Figure 6.28 shows the entry of three different Process
Times and Associated States.
Figure 6.28 Sample dialog box with different Process Times and Associated States
The resulting model code is shown in Figure 6.29. The Assign and Delay blocks
repeat once for each tuple in the repeat group.
144
6 THE LOGIC WINDOW
Example 3: Defining alternate outputs

In Figure 6.30, the logic window shows module repeater with Duplicate block inside.
The Number of Alternate Outputs is 1 and an additional connection appears along the
bottom of the module repeater.
The dialog box design windows 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 box design window with repeat group Types
and Quantities
145
Figure 6.32 shows the sample dialog box with entry of two different Types and
Quantities.
Figure 6.32 Sample dialog box with entry of two different Types and Quantities
The resulting model code is shown in Figure 6.33. The Duplicate block repeats once
for each tuple in the repeat group.
146
6 THE LOGIC WINDOW
Customized options using radio button and check box

controls
If you are using a module in the logic window that accepts only a certain set of values
(for example, a module containing a RadioButtonGroup or CheckBox or a
ComboBox control that has a value list), you might 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 modules logic window might contain a Leave module
from the Arena templates 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
box, you might 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 box is used to obtain a selection from
the modeler; it will not be referenced in the modules 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`Àccess` so that whichever operand is switched in
provides its value (Request or Access) to the Leave module. 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.
147
Module connections
Using graphical connections
In a modules 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 windowsyou can 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 can type the module label in the dialog boxes 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 in 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 modules 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 ambiguityif 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 in a logic window and connecting 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 only one connection
(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 152 for a discussion of this technique.)
To define multiple graphical connections leaving the same exit point, add each
desired connection to the exit point. For example, Figure 6.34 shows a Batch module
148
6 THE LOGIC WINDOW
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 single module have switches attached so that logically only one will be
generated in the underlying model.
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 can create an operand reference for a
repeating exit point (as described in Referencing module data on page 116), in
which case the modeler using your module determines where entities are to be sent
for each individual exit point. Or you can 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 the 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
modules repeat group) to a modules 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 box for this module might ask the modeler to list all part types
149
that require trim, the time to trim parts (assuming it is the same for all part types), the
stamping machine name, and the stamping time. Figure 6.35 shows this examples
module dialog box.
Figure 6.35 Corrugated Metal example dialog box
The dialog box design windows 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 box request the time to trim, name of the stamping machine, and
time to stamp.
Figure 6.36 Operand Explorer in dialog box design window of Corrugated Metal
example
150
6 THE LOGIC WINDOW
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 be connected automatically to the Delay module. To define this in the
logic window, the first tuple inserted into the Branch modules Branch Types repeat
group is defined as shown in Figure 6.37the 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 can 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.
151
Figure 6.38 Logic window for Corrugated Metal example
This techniqueconnecting a repeating exit point to a single modulealso is often

used in conjunction with the Conditional Assignment module described in Using
Arenas utility modules (from utlarena.tpo) on page 156.
Switching module instances

One of the key aspects of Arenas templates is the ability to define alternate model
logic that is controlled by the values that a modeler provides for the modules
operands. The mechanism for defining that certain parts of a modules 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.
152
6 THE LOGIC WINDOW
Attaching and detaching switches

In the logic window, to attach a switch to a module, you select the module (by
clicking its handle) and either select the Object > Switch > Attach menu item or
click the Attach Switch toolbar button on the Template Development toolbar. A
dialog box is opened containing a combo box in which the desired switch should be
entered (by typing its name or selecting it from the drop-down list). The module
handle expands to include the name of the attached switch, enclosed in square
brackets (for example, [SwCount]). Figure 6.39 shows 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 the Attach Switch
toolbar button or select the appropriate option of the Switch menu.
Note: A module in the logic window can 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.
153
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 modules operand values. If the model is checked for
completeness or a simulation run is initiated, the modules 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 box
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. See 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.
154
6 THE LOGIC WINDOW
Figure 6.40 Logic window with switched modules offering two alternatives
Tthe Station module has two connections to its exit point. While this is invalid in a
model window (that is, each exit point in a model window must have exactly one
connection), logic windows permit multiple connections because switches can
effectively delete connections, depending on the values of the modules operands.
As the module designer, you must ensure that the switches you have defined and
attached to module instances in the logic window will permit exactly one connection
to be active (that is, 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 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 box 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 (that is,
not send the package at that collection box) based on some condition. The logic to
represent this new option appears in Figure 6.41.
155
Figure 6.41 Logic window for Package Collection module with customer balking option
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 Arenas 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. (See the chapter The Template Window for information about private
templates.) Because it is a private template, it cannot be attached for use in model
156
6 THE LOGIC WINDOW
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 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, lets 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.
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 collected (that is, 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 (that is, 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 modules exit point.
157
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.
158
6 THE LOGIC WINDOW
THE CONDITIONAL ASSIGNMENT
MODULE
The utlarena.tpo template contains another module, the Conditional Assignment

module, which can be used only in logic windows. This module can 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 can
perform its own assignment. The module dialog box for the Conditional Assignment
module is shown in Figure 6.43.
Figure 6.43 Conditional Assignment module dialog box
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
159
module connects to the Delay module, 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.
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 modules 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. (See the Trace block in Help for a description of
the module and its fields.)
160
6 THE LOGIC WINDOW
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 (that is, 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
modules 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
connected or should reference a module operand. (The entry point operand for
modules that create entities and queue balk exit points are exceptions; they can 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
modules dialog box design window. If the required fields value is defined using
multiple operand references, you should ensure that under any valid combination
161
of values entered by a modeler (for your module), the field in the module instance
cannot be blank.
162
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 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.
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.
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
can contain module-related objects (such as entry or exit points or displayed
operands) that are created based on information provided in the dialog box design
window. You can add draw and animation objects to the user view as well.
To edit a module definitions user view, select the module in the template windows
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 windows drawing region is identical to a model windows region; for
example, its home view displays objects in the same size as a model windows home
view. Other information that relates to object sizes, such as text proportions or grid
spacing, is also defined in the same world units used in model windows. (See 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.
163
Module instances
When a module instance is placed in a model or logic window, the objects that are in
the module definitions user view window are copied into the destination (that is,
model or logic) window. The location where the modeler clicked to place the module
is used to position 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 modules user view can be
repositioned individually by the modeler. Also, the characteristics of draw and
animation objects can 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 Arenas 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 box
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. 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 165 for more
information.
164
7 THE USER VIEW WINDOW
Figure 7.2 User view of Process module instance
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 modules user view window when
the module is created. You can change the handle name by double-clicking the
module handle object in the user view window (see The Module Text Options dialog
box on page 165). A module handle can contain a maximum of 32 characters.
Because all modules must have exactly one module handle, the handle object cannot
be cut, copied, duplicated, or deleted from the user view window; it also cannot be
grouped with other objects.
The Module Text Options dialog box

The module handle, by default, displays the module name. The name can be changed
by double-clicking the module handle to open the Module Text Options dialog box.
You can either change the specified text string, or you can clear 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, when the Process
module is placed, it 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 users name input into the module
Name operand.
165
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 can change the module handles size,
style, and font. Additionally, the line, text, and fill color can be changed using the
Color toolbar.
Figure 7.3 Module Text Options dialog box (with Text String or Operand Name used for
module handle)
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 box design window.
The entry and exit point objects provide a graphical means of connecting the resulting
module to other modules.
Entry and exit points can be moved anywhere in 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 can 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 or exit point.
The orientation of a non-repeatable exit point object can be rotated by doubleclicking the object. Entry and exit point objects cannot be cut or copied to the
clipboard, duplicated, deleted, or grouped with other objects.
Note: If the operand that defines the entry or exit point is deleted from the dialog box
design window, the corresponding object is removed from the user view window.
166
Figure 7.4 Entry and exit point types
You cannot attach a switch to an entry or exit point object in the user view window. You
can, however, attach a switch to the operand in the dialog box design window that
defines this object. The switch that is attached to the operand will control whether the
graphical entry or exit point object is displayed in the modules user view.
Displayed operands
Operands that have been defined in the dialog box 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. (See 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 can locate the displayed operand anywhere in the user view window. You cannot
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 operandsYard and Interarrival Time.
167
Figure 7.5 User View window with two displayed operands
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 box design window.
168
Also, draw objects (discussed in the next section) can be grouped; however, they
cannot be grouped with the module handle.
You can 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 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, is added to the module in Figure 7.5 and a
module instance is created with values Number of Cars, Schedule, and Number of
Engines, the display of the instance appears as shown in Figure 7.7.
Figure 7.7 Module instance with repeatable displayed operand
Because the length of an operand value typically is unknown (that is, modelers might
provide short or long values), displayed operands in the user view typically are
placed vertically.
169
Draw objects
Draw objects (boxes, lines, circles, and so on) can be placed in the user view window
from the Draw toolbar. These are added in the same way that you would add draw
objects to a model window. Choose the desired object from the toolbar and place it in
the window. The hidden and visible layers can be used to control whether or not
objects defined in a modules user view will appear during a simulation run. (See
online Help for more information about these layers.)
Draw objects can be cut, copied, pasted, duplicated, and deleted. If objects are cut or
copied to the clipboard, you can paste them into any window that supports draw
objects.
After placing a module in a model or template logic window, a modeler can change
the characteristics of, or delete, draw objects that were provided by the module user
view.
Draw objects placed in the user view window can have attached switches (see User
View switch use on page 173). If so, the object will appear only if the attached
switch is evaluated to True.
Animation objects
Animation objects (for example, queues, stations, or levels) can be placed in the user
view window from the Animate toolbar. These are added in the same way that you
would add animation objects to a model window. Choose the desired object from the
Animate toolbar, type the required information into the objects dialog box, and place
the object in the user view window.
Animation objects can be cut, copied, pasted, duplicated, and deleted. If animation
objects are cut or copied to the clipboard, you can paste them into any window that
supports animation objects.
When editing an animation object, you can specify that it is named by using the value
of one or more module operands. To create this tie between the module dialog box
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 box could be defined as
NC(`Counter Name`), as shown in Figure 7.8.
170
Figure 7.8 Operand reference in animation variable dialog box
Operands can be referenced only in the entries in animation object dialog boxes listed
in Table 7.1. Other animation object characteristics can be defined in the user view,
but cannot reference module operands.
Also, if an animation object is part of a module instances user view, the entry listed
in Table 7.1 cannot be changed (that is, is grayed out) by the modeler, with the
exception of repeatable values (that is, plot expressions, entity values, resource states,
or global values).
The operand references in the animation objects follow the guidelines described in
Referencing module data on page 116 of The Logic Window chapter.
References to repeating operands are not permitted in animation objects, including
the cases where the animation object allows a repeating set of values (that is, plot
expressions, entity values, resource states, or 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 (because, after being pasted, the animation object is
no longer part of a module). If the animation object has a switch attached to it, the
switch is removed if the object is pasted into a model window.
171
Animation objects placed in the user view window can 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
172
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
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 (that is you can 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 can appear in the user view window, only animation and draw
objects can 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, see 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). Type the name of the switch or select it from
the drop-down list in the dialog box that is displayed.
Note: Only a single switch can 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 can be attached to the variable in the user view window so that
the animation variable is displayed only if a count is being collected (that is, the value
of SwCount is True). In this case, after the switch is attached, the variables name (as
displayed in the user view window) changes to show the switch name enclosed in
square brackets, as shown in Figure 7.9.
Figure 7.9 Animation variable with SwCount switch attached
173
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, 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 (that is, 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.
174
The Switch Window

A switch is a construct that allows a template designer to define variations of:
the fields displayed in a module dialog box,

the model logic and elements that are generated when a simulation run is initiated,
or
the animation objects displayed in a modules 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 definitions other windows (dialog box 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.
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 might 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 (that is, remove it from the dialog box) for any ATM
that doesnt accept deposits. The corresponding logic for processing deposits also
could be removed by attaching the switch to the appropriate module instances in the
modules 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.
175
Defining switches
A switch consists of a name and a definition. The switch definition is a conditional
expression that evaluates to True or False. It can contain operand names, operand
values, or other switch names.
A switch can be attached to any of the following objects in a module definition:
operand, repeat group, and dialog box objects in the dialog box design window
using the SwitchName property;
module instances in the logic window; and
animation and draw objects in the user view window.
A switch can 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
box design window and to an animation variable in the user view window. When the
switchs conditional expression is evaluated, these logic, operand, 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 modules switch window and specifying the
switch name and definition. A modules switch window is opened by clicking the
module in the template windows 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 box, you specify the switch name and the definition (that is, 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 can 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
176
8 THE SWITCH WINDOW
Switch names
A switch name can consist of an unlimited number of alphanumeric characters. When
switches are referenced or are attached to module objects, the switch name is not
treated as case-sensitive.
Note: In a module, the operand, repeat group, dialog box, and switch names must be
unique.
Switch definitions
Switch definitions are conditional expressions that rely on the values of other
operands 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 box) has a value of Yes, the
condition would be Àccept Deposits`==Yes (as shown in Figure 8.1).
To use the value of another switch in a definition, type the name of the switch (that is,
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
Value of operand
Double quotes ( )
`State`< >Busy
Switch
Switch1 && !Switch2
177
To define the conditional expression for a switch definition, you can 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

switch value
!SwSetupRequired
&&
and
Combine comparisons, SwCount &&

requiring both to be true `Counter`==Individual
||
or
Combine comparisons, SwSetup ||

requiring either to be true SwNewRecipe
>
is greater than
Compare op to value
`Number`>14
>=
is greater than or
equal to
Compare op to value
`Weight`>=100.3
<
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 with 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 so that grouped comparisons (that is, 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
178
8 THE SWITCH WINDOW
you can 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 cannot reference itself in its definition.
Circular references are not allowed. This means that a switch cannot 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 cannot contain a reference to SwBind.
A switch cannot be attached to an operand that is referenced in its definition. For

example, the switch SwBind defined above cannot be attached to the Format
operand, since Format is used in its definition.
This applies to direct references (as in the operand Format in the above example)
or to indirect references created using 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 (that is, each set of values for the repeating operands) of the
modules repeat group. (See the chapter The Dialog Design Window for a
discussion of repeat groups and tuples.)
For example, the Basic Process panels Assign module allows repeated
assignments to different types of elements such as Attributes, Variables, or
Pictures. 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, and so on
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 modules switches
are evaluated 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, and so on, are false. In the
179
second tuple, the Pictures switch is true and the others are false. And in the third
tuple, the Variables switch is true.
180
Because the value of the switch changes depending on which set of repeating
operands (that is, tuple) you are examining, a switch that references a repeatable
operand should be attached only to operands in the same repeat group.
A switch cannot reference an entire repeat group (that is, switches only can
reference operands).
A switch cannot refer to a specific tuple of the repeat group (for example, the fifth
assignment in a module).
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 templates Basic Process panel is attached.
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 or circles. To open a modules panel icon window, select the module in
the template windows Module Definitions list, then choose the Window > Panel
Icon menu item or click the Panel Icon Editor button on the Template Development
toolbar.
181
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 box (see The Template Window chapter). All icons in a template
panel file are 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 can change the characteristics of this object as you would
when editing any other text object (for example, change the text string, the size and
orientation) by double-clicking the default text.
You can 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 can be pasted from
another window using the clipboard.
You can also access the Arena Symbol Factory to cut and paste symbols into the
panel icon window. This library of symbols is accessed by going to Tools > Arena
Symbol Factory. Select a category of symbols and click the symbol you need. 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.
182
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 Arenas built-in elements in your modules, you gain access to predefined
modeling objects that represent complex physical components in your system. Elements are important in module building because they provide a powerful mechanism
for representing standard objects in a module such as workers, equipment, conveyors
or carts.
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 or shift
schedules. 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 can 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 and 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 or shift pattern, operating
states, failure and repair characteristics, and so on) as well as standard operations that
can alter its state (such as Seize, Release, or Preempt). Likewise, a conveyor element
has standard properties that specify its characteristics (such as path or speed) and
standard operations that change its state (such as Stop, Start, or Convey).
183
Although there are a few key element types that are commonly used in building
modules, 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 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
184
Element
Properties
Operations
Resource
Name
Capacity or Schedule
States (Busy, Idle, and so on)
Failure Pattern
Costing and Efficiency
Seize
Release
Preempt
Alter
Conveyor
Name
Path Segments
Velocity
Cell Size
Status
Type
Access
Convey
Exit
Start
Stop
Transporter
Name
Number of Units
Type
Velocity
Acceleration
Deceleration
Initial Unit Characteristics
. (Position, Status, Size)
Allocate
Request
Move
Transport
Free
Halt
Activate
Queue
Name
Ranking Criterion
Shared Indicator
Queue
Insert
Search
Remove
Station
Name
Associated Intersection
Recipe
Convey
Route
Transport
Station
10 ELEMENTS
Table 10.1 Some elements and sample properties and operations
Element
Properties
Operations
Variable
Name
Initial Value
Assign
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 component level. For example, the Process module represents an
operation in which multiple resources can 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 or AGVs.
In some cases, you might need access to additional operations (for example, scanning
a condition) that are not directly supported by the Arena template or you might 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 or transporters, be created when a modeler places an instance of
your module. Your module also can present properties of its elements in the module
dialog box so a modeler can change the characteristics of the elements. And the
185
module logic can specify operations that act on the modules elements such as seizing
a resource or transporting to a destination station.
In a module definition, you can create an element in two ways. First, in your
modules 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 Arenas hierarchy.
The second mechanism for creating elements is to place an operand in the dialog box
design window of your module definition and, in the operands LogicProperties
property, specify 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 operands 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 from element operands. See 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 from hierarchy on page 190 and Element operands
on page 190.
Element lists
When a modeler creates an element (for example, 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 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. In 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
186
10 ELEMENTS
tailor the lists presented to a modeler by using element sublists. This concept is
described in Element operands on page 190.
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 (for example, Oven) can have a
capacity of 12, while another resource element (for example, Bake Prep) can have a
capacity of 1.
You can 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 modules operands (for example, a resource
capacity operand). In this case, your module gives a value to the property through
hierarchy.
The second mechanism for defining a property is to place an operand in the dialog
box design window of your module definition and, in the operands 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 (for example, the operand defining the resource, if the property is a
resource capacity). This approach has the benefit of correctly displaying an elements
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 194.
Use of elements and properties in module

definitions
The concept of elements and properties is important regarding template design for
two primary reasons. First, Arenas 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 can be collected into lists for
presentation in module dialog boxes. We discuss these two concepts in the following
sections.
187
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 in 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 or failures, 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. See the operand objects 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 standardtype 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 (for example, its schedule or failure
patterns).
Although you can define a module that contains property information in the dialog
box, such as defining a Process type of module where the user can define capacity
and schedule information in 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. For example, if asking a user in a dialog box 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 (see 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 (for example,
resources, queues, or stations) so that a modeler is presented with a list of elements
that is constrained to the appropriate type based on the operands use in the module.
For example, if you add a ComboBox control to a moduless dialog box design and
188
10 ELEMENTS
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 can present a list of
elements. (See The Dialog Design Window for descriptions of the user interface
controls that can be added to module dialog boxes.) In this case, the drop-down list
displays the elements that have been created in the model so that a modeler can 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, and so on), 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 can create sublists 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 sublist associated with that operand; for example,
Operators. When a modeler defines a new element by typing a name into the resource
field, the element is added to the Operators sublist. Other modules in your template,
or in other templates, might also display the Operators sublist of resource elements.
In this case, the modeler is presented with a list of only those resources elements that
have been specified as Operators. Other resource sublists, such as Supervisors, CNC
Machines, and Setup Operators, could exist to collect additional classifications of
resource elements.
The sublists information in Element operands on page 190 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.
189
Defining elements from 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 (that is, both
the logic and the elements). However, merely defining elements through hierarchy
does not provide the benefits listed in the previous section (that is, defining element
lists or access to properties).
Note: If you display any element properties in your modules dialog box, we strongly
recommend that you use element and property operands in the dialog box 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 definitions dialog box 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.
In the dialog box design window, all operand objects have a LogicProperties property
available in the windows Design Properties grid. This property provides a dialog box
for specifying characteristics of the operand related to its purpose in the modules
interface and logic.
In the Logic Properties dialog box, the operands Type can be specified as Element.
190
10 ELEMENTS
Figure 10.1 Logic Properties dialog box for an Element operand
When the Type is specified as Element, the following fields are displayed:
Element TypeThe type of SIMAN element that the operand will define or
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 (for example, an operand with value
Operator will define or reference a SIMAN element with name Operator).
SublistThe sublist partition of elements (by Element Type, such as resource) of
which this operands element is to be a member. For example, the element type
Resources might have sublists for Operators and Machines. Sublists are described in
more detail in the next section.
Define/ReferenceIndicates whether the element that is created by this operand
should be defined for the simulation model or whether it only should be referenced. If
Reference is selected, some other module must define the element that is referenced
by this module. Typically this is used when incomplete property information is
definable in a module.
191
Sublists
Sublists allow partitioning into subsets the element lists that are presented to a
modeler. There is a standard sublist for each element type that is named the same as
the element (for example, RESOURCES). Elements that are created by instances of
modules from the Arena and SIMAN templates are added to this sublist.
Note: If the sublist 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 (that is, the combination of
all elements defined as members of all sublists).
In Figure 10.1, the sublist in the operands Logic Properties dialog box is specified as
Inserters. Thus, each time a value is entered into that operand in a module instance,
a new element (that is, a resource) will be created and added to the Inserters sublist of
resource elements.
By using sublists 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 (that is, sublist) 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. Sublists could be created that place the Automatic Insertion resource
elements onto an Insertion sublist and the soldering operation resource elements onto
a Solder sublist. When a modeler wants to select an Automatic Insertion resource to
perform an operation, the drop-down list presented in the dialog box would present
only those resource elements that have been defined to be inserters (that is, have been
placed on the Inserters sublist). The solder resources would not be displayed in the
drop-down list of inserters.
Note: In any model, the sublists are shared across modules from different template
panel files. For example, if a module from one template adds an element to the
Inserters resource sublist, another module from a different template also could add
elements to the same sublist.
In the dialog box design window, if a ComboBox control is specified as a basic or

property operand, the List property of the control can also be specified to show an
Element type and Sublist. Those features work identically to the description of the
entries in Figure 10.1.
192
10 ELEMENTS
Defining and referencing 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 the Define/Reference option in the operand objects
LogicProperties property dialog box (see Figure 10.1).
If you select Define, the element is added to the simulation model (that is, it will be
written to the SIMAN experiment file), and its name is added to the appropriate
element list (in the specified sublist). 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; that is, 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 through reference element operands, an Undefined
Identifier error will be given if the model is checked.
The use of the Auto-Created Module Settings button in an operands
LogicProperties property dialog box allows more flexibility in defining and
referencing an element. A data module, for example, can be created automatically
using the Auto-Created Module feature when a particular element is referenced. See
The Dialog Design Window for more details.
For example, the Advanced Transfer panels 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 merely 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 (that is, 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
can click the Find button that will take you to the Distance data module.
193
Property operands
Defining Property operands
In the dialog box design window of a module definition, in the LogicProperties
property of an operand object, the operands Type can also be specified as Property.
Figure 10.2 Logic Properties dialog box for Property operand
When the Type is specified as Property, the following fields are displayed in the Logic
Properties dialog box:
module of which this property operand is associated. In Figure 10.2, an element
operand named Inserter ID has been added to the dialog box design. This operand is
defining a RESOURCES element. We are now defining a property operand pointing
to a property of that resource.
Element TypeType of SIMAN element defined or referenced by the Element
Property NameName of the element property to which this operand is pointing,
selected from a list of valid properties associated with the Element Type. (See 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.
194
10 ELEMENTS
Read OnlyThis option is only available if the operand is a HiddenOperand control

in the dialog box design. If enabled, the hidden operand will read into its value the
current value of the element property with which it is associated. The elements
property value will NOT be overwritten by the operands Value property. The default
value defined for the hidden operand will only be written to the elements property
value if that property has yet to be defined (that is, the current value of the property is
null).
The Read Only feature can be used to allow modules to communicate indirectly. For
example, a master module can 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 can 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 definitions dialog box 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. See the chapter
The Dialog Design Window for a more information on using repeat groups in the
modules dialog box design.
Similar to operand objects, a repeat groups LogicProperties property specifies
whether the repeat group is pointing to an elements repeatable property. Figure 10.3
shows the Logic Properties dialog box for a property repeat group object. In that
195
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).
Figure 10.3 Logic Properties dialog box for a Property repeat group
If the repeat groups Type is specified as Property, the following fields are displayed
in the Logic Properties dialog box:
Element OperandAs 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 TypeThe type of SIMAN element defined or referenced by the Element
Property NameThe 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 box design, when you define a repeat group to be a property, all
operands and repeat groups that are contained in the repeat group must be property
or element operands.
196
10 ELEMENTS
To further illustrate the use of property repeat groups, suppose we have designed an
Automatic Insertion module with a dialog box design as shown in Figure 10.4 below.
Figure 10.4 Operand Explorer view of dialog box 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 box for this operand is shown in Figure 10.5.
197
Figure 10.5 Logic Properties dialog box 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.
Figure 10.6 Logic Properties dialog box for Failure Class property operand
198
10 ELEMENTS
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 or 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 (that is, the type of failure, its
duration, and so on).
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 box
design for the module.
Figure 10.7 Operand Explorer view of dialog box 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.
199
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 box, 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.
In this example, we will be defining the failure information for the specified failure in
the Automatic Insertion module. In this case, we use Define (instead of Reference)
200
10 ELEMENTS
for the element Failure (as seen above in Figure 10.8). If the Automatic Insertion
module specified the failure name and a separate Failures data module defined the
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
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 box 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 box of Failure type property operand
201
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 box is opened in the figure) and Preventive Maintenance.
Figure 10.10 Automatic Insertion example module instance
Switches and elements

Switches can be attached to element operands in the dialog box design by specifying
the SwitchName property in the objects design properties. Or, you can 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 box. See 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
box also is the same as occurs for basic operands. If the operands attached switch
condition evaluates to True, the operand is displayed. If the switch condition is False,
the operand is not displayed.
However, element operands have the additional feature of creating elementsadding
them to lists, and if the element operand reference type is Define, defining the
202
10 ELEMENTS
element in the simulation model. Because more than one module instance in a model
can have an element operand that accesses the same element, there is the potential
that the same elements 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 (that is, 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 (that is,
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 can be referenced in a template include each of the
types of elements defined in the SIMAN experiment. (See 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
can face in designing templates. These element classifications are described in the
following sections. See the Tables appendix for a complete list of these additional
element types and their properties.
203
Fixed-length elements
Many of the element types in Arena have one or more properties that can 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, 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 box, 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
in 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 use 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 elements properties. Fixed-length elements are generated along with
standard elements at model generation.
Note: The element lists and sublists are separate from one another, even for related
element types (for example, Fixed_REC50 and RECIPES elements).
Hidden element list

You might find a circumstance where you want to provide a modeler with a dropdown 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.
204
10 ELEMENTS
The hidden element functions like a standard element but doesnt directly write its
values to the SIMAN experiment file. In the LogicProperties property dialog box, 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
Dispose module, they are named automatically Create 1, Process 1, and Dispose 1.
You can 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 there for the users benefit for identifying the module. Figure
10.11 shows the Name operands design properties in the Create module definition.
Figure 10.11 Dialog box design properties of the Name operand in the Create module
205
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 doesnt define an element or a property but is contained in 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
might 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 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 elements 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 modules
dialog box.
206
10 ELEMENTS
Figure 10.12 Dialog box for Animated Segment module
Figure 10.13 shows the Operand Explorer view of the modules dialog box design.
Figure 10.13 Operand Explorer view of dialog box design of Animated Segment
module
This modules dialog box 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).
207
The Name operands 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`Ènd``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 modules
dialog box. The Set operand is a visible element-type operand that defines a standard
Segments element.
208
10 ELEMENTS
The BegN and EndN property operands default values reference the Beg and End
operand values, respectively. Figure 10.15 shows the operand BegNs 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.
209
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 are set members. The Inv_SETS and Inv_Statesets elements defines a set
member as the element value and this elements 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.
210
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 inside or outside
your organization. The following list of guidelines and hints can be helpful in
providing the best simulation environment for you or others.
Dialog box design (dialog box design

window)
Dialog boxes
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 in a dialog box.
Use secondary dialog boxes instead of a single large dialog box.
Secondary dialog boxes generally should not contain required operands unless
they are switched On by the user.
In a template panel, use consistent designs in the modelers 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 or 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.
211
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 modules dialog box design.
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 or disable controls so non-applicable fields will not be

displayed.
Try not to place ComboBox controls near the bottom of a tall dialog box. 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 box 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 or Cleared) 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 box design

window
Use meaningful operand names. These will be used for default prompts and for
column headings with Module Data Import or Export.
General
212
Module entry and exit points should not be hidden so that the module can be used
in the definition of another module (that is, a Label or Next Label operand should
appear in the module dialog box so that a reference can be entered when the
module is placed in another module definitions logic window).
Use the Auto-Created Module functionality to create data modules from logic
modules automatically.
A TEMPLATE DESIGN GUIDELINES
Panel icon
Retain the text label of the icon and use the same font type and size for all
modules.
Be consistent in 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.
If the module has a resource in the user view, try to represent the module in the
panel icon by drawing a simplified version of the resources idle or busy picture.
If modules are related to others, the icons can represent that relationship.
Present logic modules together and datamodules together in a template panel as

is done in the Arena templates 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 can 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
or identifier entry because 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.
213
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 Arenas clipboard to transfer the
logic into a module definitions logic window and add the appropriate operand
references or switches.
Base your modules on SIMAN Blocks and Elements. This allows you to define
elements either through the logic window or the dialog box design window.
Naming conventions
When a module contains a station designation, the station name should be

supplied by the user. Other operands can 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 modules main dialog box title (for example, 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 can be accessed
from in the software. This can be done in several ways.
214
Use static text (Text control) to provide a brief description in a dialog box.
A TEMPLATE DESIGN GUIDELINES
Provide a text file (for example, 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.
To distinguish the messages you generate from module headers and low-level
trace, we recommend that each message start with a hyphen in column 1 (for
example, Waiting for teller\n).
Since it is not always possible to evaluate every expression accurately, it is most

consistent to write the expression itself (in the format) instead of writing it as an
argument.
Use the STR keyword to write symbol names instead of numbers (for example, 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.
215
216
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).
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, see Help.
Note: Those properties that are repeat group properties are denoted with an (R). Their
included operands are indented following the repeat group name.
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
217
ARRIVALS Element
Properties
Assignments (R)
. Variable ID
. Value
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
218
B TABLES
CONTINUOUS Element Properties

Save Point Interval
Method
Absolute Error
Relative Error
Severity
Cross Severity
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
219
COUNTERS Element
Properties
Number
Limit
Initial Option
Output File
Report ID
Data Type
Category
Process ID
CSTATS Element
Properties
Number
Name
Output File
Report ID
Data Type
Category
Process ID
DISCRETE Element
Properties
Max Number of Entities
Number of Attributes
Largest Queue Number
Largest Station Number
Animation Attribute
220
B TABLES
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
DSTATS Element
Properties
Number
Name
Output File
Report ID
Data Type
Category
Process ID
DSTATS_PERIODIC
Element
Properties
Number
SIMAN Expression
Output File
221
DSTATS Element
Properties
Report ID
Data Type
Category
Process ID
Start Time
Duration
Repeat Time
ENTITIES Element
Properties
Number
Initial Picture
Initial Holding Cost Rate
Initial VA Cost
Initial NVA Cost
Initial Wait Cost
Initial Tran Cost
Initial Other Costs
Auto Stats Generate
Auto Stats Category
EVENTS Element
Properties
Crossing Variable
Crossing Direction
Threshold Value
Crossing Tolerance
222
B TABLES
EXPRESSIONS Element Properties

Number
1-D Array Index
2-D Array Index
Data Type
Linked File
Linked Recordset
Expression Values (R)
. Expression
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
223
FILES Element
Properties
Recordset CommandText
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
224
B TABLES
FREQUENCIES_
PERIODIC Element
Properties
Number
Expression
Type
Output File
Report ID
Data Type
Data Category
Process ID
Start Time
Duration
Repeat Time
Categories (R)
. Value Or Range
. Value
. High Value
. Category
. Category Option
INCLUDE Element
Properties
File Description
INITIALIZE Element
Properties
Value
225
INTERSECTIONS
Element
Properties
Number
Travel Length
Link Selection Rule
Rule Attribute ID
Velocity Change Factor
LEVELS Element
Properties
Number
1-D Array Index
2-D Array Index
Initial Values (R)
. Value
LINKS Element
Properties
Number
Beginning Intersection ID
Beginning Direction
Ending Intersection ID
Ending Direction
Number of Zones
Length of Each Zone
Link Type
226
B TABLES
NETWORKS Element
Properties
Number
Links (R)
. Starting Link
. Ending Link
NICKNAMES Element
Properties
Name or Constant
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
227
PROJECT Element
Properties
Title
Analyst Name
Month
Day
Year
Summary Report
Costing
Entities
Resources
Queues
Transporters
Conveyors
Processes
Stations
ActivityAreas
Tanks
QUEUES Element
Properties
Number
Ranking Criterion
Rule Expression
Associated Block/SHARED
Auto Stats Generate
Auto Stats Category
228
B TABLES
RANKINGS Element
Properties
Ranking Criterion
Ranking Expression
RATES Element
Properties
Number
1-D Array Index
2-D Array Index
Initial Values (R)
. Value
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
229
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
REPORTLINES Element Properties

Number
Report ID
Format
Expressions (R)
. Expression
230
B TABLES
REPORTS Element
Properties
Number
System Name
Title
Heading
Sort
Format
RESOURCES Element
Properties
Number
Integer or Sched ID
Capacity Entity Rule
Stateset ID
Initial State
Resource Type
Map ID
Velocity
Initial Position
Position ID
Zone
Busy Cost
Idle Cost
Usage Cost
Category Type
Failures (R)
. Failure
. Failure ID
. Failure Entity Rule
231
RESOURCES Element
Properties
Auto Stats Generate
Auto Stats Category
Base Efficiency (no longer supported)
Efficiency Schedule ID (no longer supported)
RULES Element
Properties
Selection Rule
Rule Expression
SCHEDULES Element
Properties
Schedule Type
Format Type (Calendar Format Type no longer supported)
Scale Factor
Time Units
Values (R)
. Value
. Duration
SEEDS Element
Properties
Seed Value
Initialize Option
SEGMENTS Element
Properties
Beginning Station
Next Stations (R)
. Next Station
. Length
232
B TABLES
SENSORS Element
Properties
Number
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
STATESETS Element
Properties
Number
States (R)
. State Name
. Stateset Type
STATICS Element
Properties
Default Value
233
STATIONS Element
Properties
Number
Intersection ID
Recipe ID
Parent Activity Area
Auto Stats Generate
Auto Stats Category
STORAGES Element
Properties
Number
TABLES Element
Properties
Number
Low Value
Fixed Increment
Dependent Values (R)
. Dependent Value
TALLIES Element
Properties
Number
Output File
Report ID
Data Type
Category
Process ID
234
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
TRACE Element
Properties
Beginning Time
Ending Time
Condition
Expressions (R)
. Expression
235
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
236
B TABLES
VARIABLES Element
Properties
Number
1-D Array Index
2-D Array Index
Data Type
Clear Option
Category Type
Response Category Type
Linked File
Linked Recordset
File Read Time
Initial Values (R)
. Value
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
237
Inv_LINKS Element
Properties
Number
Beginning Intersection ID
Beginning Direction
Ending Intersection ID
Ending Direction
Number of Zones
Length of Each Zone
Link Type
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
238
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
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
239
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
240
B TABLES
Fixed_ATT10R Element
(Attributes)
Properties
Initial Values (R)
. Value 1
. Value 2
.
. Value 10
Fixed_ATT50 Element
(Attributes)
Properties
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 1
. Expression 2
Usage
Description
241
Fixed_EXP3R Element
(Expressions)
Properties
Number
1-D Array Index
2-D Array Index
Data Type
. Expression 1
. Expression 2
. Expression 3
Usage
Description
Fixed_EXP4R Element
(Expressions)
Properties
Number
1-D Array Index
2-D Array Index
Data Type
. Expression 1
. Expression 2
. Expression 3
. Expression 4
Usage
Description
242
B TABLES
Fixed_EXP7R Element
(Expressions)
Properties
Number
1-D Array Index
2-D Array Index
Data Type
. Expression 1
. Expression 2
.
. Expression 7
Usage
Description
Fixed_EXP30R Element
(Expressions)
Properties
Number
1-D Array Index
2-D Array Index
Data Type
. Expression 1
. Expression 2
.
. Expression 30
Usage
Description
243
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
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
Usage
Description
244
B TABLES
Fixed_EXP10R Element
(Expressions)
Properties
Number
1-D Array Index
2-D Array Index
Data Type
. Expression 1
. Expression 2
.
. Expression 10
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
Usage
Description
245
Fixed_EXP20 Element
(Expressions)
Properties
Number
1-D Array Index
2-D Array Index
Data Type
Expression 1
Expression 2
Expression 20
Expressions (R)
. Expression
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
Usage
Description
246
B TABLES
Fixed_EXP50 Element
(Expressions)
Properties
Number
1-D Array Index
2-D Array Index
Data Type
Expression 1
Expression 2
Expression 50
Expressions (R)
. Expression
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
247
Fixed_FRE50 Element
(Frequencies)
Properties
Value 2
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
248
B TABLES
Fixed_LEV50 Element
(Levels)
Properties
Number
1-D Array Index
2-D Array Index
Value 1
Value 2
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
249
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
250
B TABLES
Fixed_REC20 Element
(Recipes)
Properties
Static Name 1
Value 1
Static Name 2
Value 2
Static Name 20
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
251
Fixed_RES50 Element
(Resources)
Properties
Number
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 50
Failure ID 50
Failures (R)
. Failure
. Failure ID
. Failure Entity Rule
252
B TABLES
Fixed_RLN50 Element
(Reportlines)
Properties
Number
Report ID
Format
Expression 1
Expression 2
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
253
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
254
B TABLES
Fixed_SEQ40 Element
(Sequences)
Properties
Number
Stations (R)
Station ID
Variable 1
Value 1
Variable 2
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
255
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
256
B TABLES
Fixed_SET50 Element
(Sets)
Properties
Member 1
Member 2
Member 50
Members (R)
. Member
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
257
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
258
B TABLES
Fixed_TRA50 Element
(Transporters)
Properties
Size Integer 1
Initial Position 2
Position ID 2
Zone 2
Initial Status 2
Vehicle Size 2
Size Integer 2
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
259
Fixed_VAR2R Element
(Variables)
Properties
Number
1-D Array Index
2-D Array Index
Clear Option
Category Type
Data Type
Initial Values (R)
. Value 1
. Value 2
Usage
Description
Fixed_VAR10 Element
(Variables)
Properties
Number
1-D Array Index
2-D Array Index
Clear Option
Category Type
Data Type
Value 1
Value 2
Value 10
260
B TABLES
Fixed_VAR10 Element
(Variables)
Properties
Initial Values (R)
. Value
Usage
Description
Fixed_VAR10R Element
(Variables)
Properties
Number
1-D Array Index
2-D Array Index
Clear Option
Category Type
Data Type
Initial Values (R)
. Value 1
. Value 2
.
. Value 10
Usage
Description
261
Fixed_VAR50 Element
(Variables)
Properties
Number
1-D Array Index
2-D Array Index
Clear Option
Category Type
Data Type
Value 1
Value 2
Value 50
Initial Values (R)
. Value
Usage
Description
262
B TABLES
Fixed_VAR200 Element
(Variables)
Properties
Number
1-D Array Index
2-D Array Index
Clear Option
Category Type
Data Type
Value 1
Value 2
Value 200
Initial Values (R)
. Value
Usage
Description
263
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. See 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 box design window. Values are the permitted values a modeler can
enter. If these 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.
264
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
B TABLES
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
265
Data Type Name
Date
Values
Date
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
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
266
Data Type Name
EnabledDisabled
Values
Enabled, Disabled
Data Type Name
EndOpt
Values
Error, Dispose, Rewind, Ignore
B TABLES
Data Type Name
EntRule
Values
Preempt, Ignore, Wait
Data Type Name
EventType
Values
User, VBA, ActiveX
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
267
268
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
Data Type Name
FreqExp
Values
Value, State
Data Type Name
GlobalPriority
Values
QTIME, LVF, HVF
Data Type Name
IdOrInt
Values
SymbolName, Integer
Data Type Name
IdOrIntOrRange
Values
SymbolName, Integer - Integer, Integer,

SymbolName - SymbolName
Data Type Name
IdOrIntOrReal
Values
SymbolName, Integer, Real
B TABLES
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
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
269
270
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
Data Type Name
PositiveInteger
Values
Positive Integer (optional min, max values)
Data Type Name
PositiveReal
Values
Positive Real
Data Type Name
PreemptDest
Values
Label, STO( IdOrInt )
Data Type Name
QBlock
Values
Label, SHARED
B TABLES
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
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
271
272
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
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
Data Type Name
SeedInitOpt
Values
YesOrNo, Common, Antithetic
B TABLES
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
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
273
274
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
B TABLES
Connection point data types and SIMAN

blocks
Entry or 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
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, and so on) 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.
275
CONNECTION
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
CONNECTION
276
VALIDATION
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
Creating Online Help Files

Arena provides template developers with a help interface that 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. Lets assume that you
have created a template called Sample.tpl that contains a module called Server. Lets
also assume that the Server modules main dialog box looks like this:
Figure C.1 Main dialog box of the Server module
The repeat group and secondary dialog boxes (Server Names and Options) look
like this:
Figure C.2 Server Names Repeat Group Figure C.3 Options Secondary dialog box
dialog box
277
When you generate the Sample.tpo file, Arena writes out a help interface file called
Sample.HH that looks something like this:
Automated help: *.HH
#define TemplateContents4293984255
#define Server4294443008
#define Server_0
#define Server_Server_Names524288
#define Server_Server_Name1048576
#define Server_Quantity1572864
#define Server_Process_Time2097152
#define Server_Options2621440
#define Server_Cost3145728
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 templates .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 Arenas
Help menu. Clicking 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 used when you click the Context Sensitive Help toolbar button (on the
Standard toolbar) and then click 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 can be
changed by editing the Module Help Option in the Template Options dialog box.
In Arena, every module dialog box (including secondary dialog boxes and dialog
boxes displayed when adding or editing items in repeat groups) contains a Help
button. Each Help button can display either the main help topic for that module or a
unique help topic for that particular dialog box of the module. For example, the
Server module displayed above has three dialog boxes: the main dialog box (Server),
and two secondary dialog boxes (Server Names repeat group and Options). Each of
these dialog boxes has a Help button. The Server dialog boxs Help button will
display the main help topic for the module. The Server Names dialog box can display
either the main help topic (as displayed by the Server dialog box) or a unique help
278
C CREATING ONLINE HELP FILES
topic specific to the Server Names dialog box. The Options dialog box can display
either the main help topic (as displayed by the Server dialog box) or a unique help
topic specific to the Options dialog box.
To enable or disable unique help topics for individual dialog boxes, you specify a
dialog box form objects UniqueHelpTopic property as True or False in the module
definitions dialog box design window. By default, this property is set to True for a
dialog box form. If you enable a unique help topic for a particular dialog box but fail
to create a corresponding topic in your help file, users who press the Help button in
that dialog box 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 box.
Similarly, in the module definitions dialog box design window, each dialog box form
object includes a WhatsThisHelp property that is specified as True or False. This
option will provide the dialog box 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 box. 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 Whats
This? help option if you do not intend to create a help topic for each operand in the
dialog box.
When the help interface (.HH) file is generated along with the .tpo file, the context IDs
are written for each dialog box according to the following rules: the main dialog boxs
context ID is created by appending an underscore (_) to the module name, for example,
Server_. The context IDs for all other dialog boxes are created by appending the dialog
box name to the module name, separated by underscores; spaces embedded in dialog
box and repeat group names are converted to underscores. For example, the Server
Names dialog box would generate a context ID of Server_Server_Names. The Options
dialog boxs context ID would be Server_Options.
Context IDs for Whats This? help are created for each operand by appending the
operand name to the dialog box name with an underscore. For example, the Server
Names dialog box would generate context IDs Server_Server_TimeName and
Server_Quantity for the operands Server Name and Quantity in the Server Names
dialog box.
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,
279
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 (for example, Sample.HH) from
the list and click Add.
4. Click OK several times until youve closed all the dialog boxes and are back to
the help document.
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 might need to click the Advanced
button to open up this section of the dialog box). Click the Choose button to open the
Choose Context String Provided By Development Team dialog box. 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 dialog boxes 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 dialog boxes 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. The
help file should have the same name as the template file. For example, Sample.tpo
will look for a file called Sample.hlp.
280
Index
A
Accelerator keys 109
Advanced Process panel 2, 185
Advanced Transfer panel 2, 185
Animation object
display in user view 170
in logic window 115
Arena template 185
Assign module 45
Auto-Create 75, 96
B
Back quote character
use for referencing operand 117
Basic Process panel 2, 185
C
Changes to instances 75
Check boxes
customizing options 147
special access for references in logic
window 123
Clipboard 75, 113, 116, 171, 182
Compatibility of existing module
instances 75
Conditional assignment module 159
Contact information 5
Creating online help files 277
Customer Support Center 4
D
DataType property
SIMAN 102
standard 101
Decide module 44
Defining modeling logic 40
Delay module 48
Design Properties grid 83
Dialog Design toolbar 110

Dialog Design window 33
Design Properties grid 83
dialog form objects 79
hidden operands 79
Operand Explorer 78
operand objects 79
repeat group objects 79
Toolbox 80
Toolbox controls
CheckBox 81
ComboBox 81
DatePicker 81
DateTimePicker 81
DialogButton 81
FilePicker 81
GroupBox 81
HiddenOperand 81
Line 81
RadioButtonGroup 81
RepeatGroupDialog 81
RepeatGroupTable 81
Text 81
TextBox 81
TimePicker 81
View Dialog Form button 78
Dialog form 82
arranging controls 83
layout 39
locking controls 83
opening 82
resizing 83
Direct connection 125
in module logic 126
Distances element 206
Document conventions 3
Documentation set 3
Draw object
hidden/visible layer 170
in user view 170
281
Element 183
data elements 183
define vs. reference option 193
defining through hierarchy 186, 190
defining via element operand 186
lists 186, 188
sublists 189, 192
special types
fixed-length 204
hidden 204
inverted 206
switches on elements 202
Elements panel 185
entry 94
Entry point
operand reference in logic window 127
operand validation/reference 95
operands 37
switches attached 167
user view object 166
Errors/warnings 67
reviewing 68
Exit point
operand 37
operand validation/reference 95
repeatable 136
switches attached 167
user view object 166
InUserView property 103
F
Field
use in Logic Window chapter 116
G
Global pictures 55
H
Help 3
Help file creation 277
Help interface file 279
Hidden operands 79
282
L
Loading a template panel library (.tpl)
file 66
Logic window
attaching switches 153
connecting module instances 148
decomposing processes 111
design hints 214
detaching switches 153
differences with model window 113
hidden module (utlarena.tpo) and
switches 157
multiple connections and switches 148
opening 112
repeating exit points and single
connection 149
rules and guidelines 161
switches in module instances 124
verifying logic relative to switches 155
LogicProperties property 92
repeat groups 104
M
Model window
differences with logic window 113
Module 96
handle 163, 165
process of building logic 41
repeater 139
required option 73
types of entity flow 125
Module definition
changes and existing instances 75
copying 75
deleting 66
operand references 116
renaming 66
Module definition window 65
opening 67
Module handle 165
INDEX
Module instance
use in model or logic window 112
Module-building tutorial 29
Assign module 45
Decide module 44
Delay module 48
Process module 45
Queue module 42
Queues element 50
Release module 48
Seize module 42
Variables element 50
hidden 103
property 93
special functions 98
specifying the DataType property 101
specifying the InUserView property 103
specifying the LogicProperties
property 92
specifying the Name property 91
specifying the SwitchName
property 102
specifying the Value property 97
Operands, using 91
Name property 91
repeat groups 103
NetworkLink element 206
Number of Alternate Outputs 140
Panel icon 181

design hints 213
size and display in template panel 73,
182
Panel icon window 181
tutorial 56
Process module 45
Project Bar 9, 23, 58, 72, 73
Property 183, 187
switches on properties 203
O
Online help 3
Opening a module definition window 67
Opening a new template panel library (.tpl)
file 65
Operand
default value 117, 199
design hints 211
display in user view 167
repeatable operand 169
element 190
property 194
defining element and property using
hidden operand 199
repeat group 195
references to 114
switching multiple with references to provided set 120
template panel library (.tpl) file operand
report 68
value reference in switch definition 177
Operands
basic 92
element 93
entry point 94
exit point 94
Q
Queue module 42
Queues element 50
R
Radio button group
customizing options 147
special access for references in logic
window 123
Referencing operands
animation objects in user view 170
combining repeating and non-repeating
references 136
concatenating text and reference 118
containing multiple references 119
entry point operands 127
in switch definition 177
multiple references to same operand 122
repeating exit point 138
repeating operands 131
283
Release module 48
Repeat group 103
switch use 180
Repeat group objects 79
Repeat groups
accessing the number of tuples and the tuple number 107
combining repeating operand values into a
single value 107
definition depth and reference rules 105
reference rules 129
specifying the LogicProperties
property 104
specifying the Name property 103
Repeatable logic 139
Repeatable module 139
Review errors 68
S
Sample models 3
Segments element 206
Seize module 42
Sets element 206
SIMAN template 185
Simulation logic and module design 111
Smarts library 3
Station transfer 125
in module logic 125
Statistics
hints for designing in module 215
Submodel 112
Switch 175
and element 202
and property 203
attached to user view animation
object 171
defining 176
definition 71, 176, 177
operand comparison with value 178
in logic window module instance 124
name 177
rules regarding definitions 179
template panel library (.tpl) file switch
report 68
284
use in logic window 152

use in module definition windows 176
T
Technical support 4
Template
documenting 214
Template Development toolbar 33
Template panel 65
changing the display name 72
creating new window 32
detaching 76
icon size and display 73
private 72
Template panel library (.tpl) file
changes and existing module
instances 75
checking for errors/warnings 67
Template panel object (.tpo) file
changes and existing instances 75
generate .tpo in template window 67, 71
providing to modeler 71
rules regarding attachment to logic
windows 115
Template window
closing 66
deleting a module 66
generating the template panel object (.tpo)
file 71
renaming a module 66
report 68
template options 71
version 71
Toolbox, using
CheckBox control 87
ComboBox control 85
DatePicker control 89
DateTimePicker control 88
DialogButton control 87
FilePicker control 90
GroupBox control 85
HiddenOperand control 91
Line control 85
RadioButtonGroup control 86
RepeatGroupDialog control 87
INDEX
RepeatGroupTable control 88
Text control 84
TextBox control 85
the controls 83
TimePicker control 90
Trace
design hints for use in module
definition 215
Trace in module definitions 160
Training courses 5
Tuple
value of switch in 179
Variables element 50
Web support 4
Whats This? help 279
Context IDs 279
World units 163
User view 163
design hints 213
designing 53
modifications by modeler 164
User view window 163
tutorial 53
Utlarena.tpo file 156
conditional assignment module 159
hidden module 157
Value property 97
285

Template Developer's Guide PDF

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Template Developer's Guide PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Arena

TEMPLATE DEVELOPERS GUIDE

Rockwell Automation Customer Support Telephone 1.440.646.3434

2 Arena Template Development Overview

Modeling with ArenaAn overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

ARENA TEMPLATE DEVELOPERS GUIDE

4 The Template Window

Defining a name operand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5 The Dialog Design Window

Dialog Design Window overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

ARENA TEMPLATE DEVELOPERS GUIDE

Using accelerator keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

6 The Logic Window

7 The User View Window

8 The Switch Window

9 The Panel Icon Window

Creating the panel icon. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

ARENA TEMPLATE DEVELOPERS GUIDE

Special element types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A Template Design Guidelines

C Creating Online Help Files

ARENA TEMPLATE DEVELOPERS GUIDE

Figure 1.1 Arenas Template Window selection

About this guide

Where can I go for help?

Refer to the users guides

Explore our examples

Use the Smarts library

ARENA TEMPLATE DEVELOPERS GUIDE

from modeling resources to animation techniques. The library is organized into

Get phone support

TECHNICAL SUPPORT INCLUDES:

the product serial number

International technical support is provided by the global representatives. For contact

Get Web support

Refer to the Arena Web site

Get consulting services

Arena Template Development

Modeling with ArenaAn overview

Figure 2.1 Process module user view

ARENA TEMPLATE DEVELOPERS GUIDE

2 ARENA TEMPLATE DEVELOPMENT OVERVIEW

Templates and panels

Figure 2.2 Sample template window

ARENA TEMPLATE DEVELOPERS GUIDE

Module definitions and instances

2 ARENA TEMPLATE DEVELOPMENT OVERVIEW

Figure 2.3 Main dialog box for Create module

ARENA TEMPLATE DEVELOPERS GUIDE

Figure 2.5 Template Development toolbar

2 ARENA TEMPLATE DEVELOPMENT OVERVIEW

Figure 2.6 Basic Process template panel

ARENA TEMPLATE DEVELOPERS GUIDE

Figure 2.7 Create module panel icon

Figure 2.8 Process module instances default user view

2 ARENA TEMPLATE DEVELOPMENT OVERVIEW

Figure 2.9 Modified Process module instances

Dialog box design and operands

ARENA TEMPLATE DEVELOPERS GUIDE

Figure 2.11 Record module default dialog box

2 ARENA TEMPLATE DEVELOPMENT OVERVIEW

ARENA TEMPLATE DEVELOPERS GUIDE