Arena Template Developer's Guide

Arena
TEMPLATE DEVELOPERS GUIDE

PUBLICATION ARENDG-RM001D-EN-PNovember 2007
Supersedes Publication ARENDG-RM001C-EN-P
Contact Rockwell
Customer Support Telephone 1.440.646.3434 Online Support http://www.rockwellautomation.com/support/ 2007 Rockwell Automation Technologies, Inc. All rights reserved. Printed in USA. This document and any accompanying Rockwell Software products are copyrighted by Rockwell Automation Technologies, Inc. Any reproduction and/or distribution without prior written consent from Rockwell Automation Technologies, Inc. is strictly prohibited. Please refer to the license agreement for details. 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, 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 may be affected by system configuration, the application being performed, operator control, maintenance and other related factors. Rockwell Automation is not responsible for these intervening factors. The instructions in this document do not cover all the details or variations in the equipment, procedure, or process described, nor do they provide directions for meeting every possible contingency during installation, operation, or maintenance. This 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: 12.00.00 (CPR9) Modified: October 8, 2007 12:10 pm
Copyright Notice
Trademark Notices Other Trademarks
Warranty
ii
Contents
1 Welcome
What is Arena simulation software? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intended audience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . About this guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Where can I go for help? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reference the users guides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Explore our examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Get help. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Use the SMARTs library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Access the Arena Symbol Factory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Get phone support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Get Web support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Get training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Get consulting services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Contact us . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1 2 2 3 3 3 3 3 4 4 4 5 5 5
2 Arena Template Development Overview
Modeling with ArenaAn overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Templates and panels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Module definitions and instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Defining a module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Panel icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 User view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Dialog design and operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Elements and properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Arena hierarchy and SIMAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Flowcharts and data modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Use of templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 General modeling tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Industry-oriented environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Application-focused tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Improving modeling productivity and sharing modeling technology . . . . . . . . . 26
iii
ARENA TEMPLATE DEVELOPERS GUIDE
3 Module-building Tutorial
Module overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Getting startedA new template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dialog Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The dialog design window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding the modules dialog 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
29 32 33 33 35 37 39 40 40 41 42 44 45 48 50 53 56 57 57 58 64
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
65 65 66 66 66 66 66 67 67 67 68 68 70 70 70 71 72
iv
CONTENTS
Defining data modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining a name operand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating copies of module definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Compatibility of existing module instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73 73 74 74
5 The Dialog Design Window
77
Dialog Design Window overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 The Operand Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 The Toolbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 The dialog form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 The Design Properties grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Using the Toolbox controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Using the Text control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Using the GroupBox control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Using the Line control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Using the TextBox control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Using the ComboBox control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Using the RadioButtonGroup control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Using the CheckBox control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Using the DialogButton control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Using the RepeatGroupDialog control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Using the RepeatGroupTable control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Using the DateTimePicker control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Using the DatePicker control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Using the TimePicker control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Using the FilePicker control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Using the HiddenOperand control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Using operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Specifying the Name property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Specifying the LogicProperties property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Specifying the Value property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Specifying the DataType property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Specifying the SwitchName property. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Specifying the InUserView property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Hidden operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Using repeat groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Specifying the Name property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Specifying the LogicProperties property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Repeat group definition depth and reference rules . . . . . . . . . . . . . . . . . . . . . . . 104 Accessing the number of tuples and the tuple number . . . . . . . . . . . . . . . . . . . . 105 Combining repeating operand values into a single value . . . . . . . . . . . . . . . . . . 106 Using repeatable modules in the logic window with repeat groups . . . . . . . . . . 107
Using accelerator keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Dialog Design toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
109
109 109 111 111 111 112 112 112 112 113 113 114 114 120 121 121 125 127 131 133 135 137 139 141 142 142 142 143 146 146 147 150 153 154
7 The User View Window
157
Module instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
vi
CONTENTS
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
158 159 159 160 161 163 164 166
8 The Switch Window

Defining switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Switch names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Switch definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Switch definition rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
169
169 170 171 172
9 The Panel Icon Window
175
Creating the panel icon. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
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 via hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Element operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining element operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sub-lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining and referencing elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Property operands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining Property operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining repeating properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining an element/property using a hidden operand. . . . . . . . . . . . . . . . . . . . Switches and elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Special element types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fixed-length elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hidden element list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
177
179 179 180 180 181 181 182 183 183 183 185 185 187 187 188 192 195 196 196 197
vii
Inverted elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
A Template Design Guidelines

Dialog box design (dialog design window) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dialogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Operand objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Helpful hints for defining objects in the dialog design window. . . . . . . . . . . . . General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Panel icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . User view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Module logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Naming conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Template documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Statistics and reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
205
205 205 205 206 206 206 207 207 208 208 208 209
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/exit point types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
211
211 211 229 231 257 257 267 267
C Creating Online Help Files
269 273
Index
273
viii
Welcome
1 Welcome
What is Arena simulation software?

Arena is an advanced simulation system that provides an interactive environment for building, graphically animating, verifying, and analyzing simulation models. With Arena, you can design a unique Arena template that is specific to your particular project, company, or industry. The template development features build on Arenas natural hierarchical structure enabling you to create new simulation tools in a graphical, easy-touse environment. Within Arenas template-building area, you create complete simulation building blocks, called modules. These modules may be very simple, such as one that counts customers as they leave a bank. Or you might build a highly complex module that captures all of the activities at a shipyard dock. In fact, 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 may use these templates in support of your own simulation activities, or you may share these simulation tools with other modelers. By encouraging this sharing of technology, Arena offers the opportunity for you, as a simulation modeler, to create completely customized environments, without writing any programming code. Novice modelers can access the power of simulation as a decision support tool by working with terminology, modeling logic, and graphical animation that are specially developed for their needs. Experienced simulationists can improve their productivity and share the knowledge they have gained by capturing essential simulation logic and quickly packaging it into a verified, reusable building block for future models. As mentioned above, within Arena you have the ability to define new modeling constructs, called modules, and to store them in libraries, referred to as Application Solution Templates (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. When you run Arena, you will simply open a Template Window (instead of a Model Window). Select the File > New menu option or press the New File toolbar
button. In the dialog 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 access the capabilities of template building, you should already have developed a good understanding of the basic Arena modeling interface and the either the SIMAN template or 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 online 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. We start by presenting two chapters that familiarize you with the concepts and terminology employed in Arena and walk you through a simple module-building tutorial. Following this, we provide a description of the template window, then of each of the five windows that you employ to build modules. Next we present Elements, the final concept related to the definition of Arena modules. Appendix B of this book contains reference tables. To begin your experience with template development, we recommend that you read Chapter 2, Arena Template Development Overview, to become familiar with Arena concepts and terminology. Then, follow the step-by-step instructions provided in the module-building tutorial in Chapter 3. While you are building your first module, you may want to refer to concepts presented in Chapter 2.
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. Whether youre new to simulation or a seasoned veteran putting a new tool to use, youll quickly feel at home with Arena simulation software.
1 Welcome
Reference 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 providing module information on the basic of modeling with the Basic Process, Advanced Process, Advanced Transfer, and Flow Process panels as well as complete descriptions of Arena variables found in the Arena product templates. DOCUMENT
CONVENTIONS
Throughout the guides, a number of style conventions are used to help identify material. New terms and concepts may be emphasized by use of italics or bold; file menu paths are in bold with a (>) separating the entries (e.g., go to Help > Arena Help); text you are asked to type is shown in Courier Bold (e.g., in this field, type Work Week), and dialog box and window button names are shown in bold (e.g., click OK).
Explore our examples

Arena is accompanied by a number of sample models that illustrate many of the commonly used approaches for capturing the essence of manufacturing processes. Examples are provided for both job shop and flow shop environments. For a description of and list of Arenas examples, go to Help > Arena Help. On the Contents tab, choose Model Building Basics, and then select Viewing Arena Example Models.
Get help
Online help is always at your fingertips! Arena incorporates the latest in help features, including Whats This? help that displays a brief description of fields in dialogs, contextsensitive help on menu and toolbar buttons, and a help button on each of Arenas modules. Just refer to the Arena help table of contents and index for a list of all help topics.
Use the SMARTs library

As you craft models of your own manufacturing processes, use our SMARTs library to explore how to best use Arena. This suite of tutorial models covers topics ranging from modeling resources to animation techniques. The library is organized into categories to help you find the right model with ease. When 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.
Access the Arena Symbol Factory

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

Rockwell Automation provides full support for the entire Arena family of products. Questions concerning installation, how modules work, the use of the model editor, and the use of the software are handled by technical support. ARENA
TECHNICAL SUPPORT INCLUDES:
(for users on active maintenance) a technical support hotline and e-mail address staffed by full-time, experienced professionals help with installation problems or questions related to the 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), you should be at your computer and be prepared to give the following information: the product serial number the product version number the operating system you are using the exact wording of any messages that appeared on your screen a description of what happened and what you were doing when the problem occurred a description of how you tried to solve the problem.
Get Web support

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

1 Welcome
1 WELCOME
And be sure to check the Arena User Zone section of our Web site at www.ArenaSimulation.com. The User Zone links to a peer-to-peer forum on Arena topics and has a link to a download page where you can check for possible software updates (patches). If you cant find the answer you need, contact your local representative or Arena technical support.
Get training
Do you need training? Rockwell Automation offers a standard training course comprised of lecture and hands-on workshops designed to introduce you to the fundamental concepts of modeling with Arena. We also offer customized training courses designed to meet your specific needs. These courses can be held in our offices or yours, and we can accommodate one person or twenty. You design the course thats right for you! Simply contact our consulting services group to discuss how we can help you achieve success in your simulation efforts.
Get consulting services

Rockwell Automation also provides expert consulting and turnkey implementation of the entire Arena product suite. Please contact our offices for more information.
Contact us
We strive to help all of our customers become successful in their manufacturing improvement efforts. Toward this objective, we invite you to contact your local representative or Rockwell Automation at any time that we may be of service to you. Support E-mail: Arena-Support@ra.rockwell.com Corporate E-mail: Arena-Info@ra.rockwell.com Support phone: 1.440.646.3434 URL: www.ArenaSimulation.com URL: www.rockwellautomation.com
Arena Template Development Overview

In this chapter, we introduce the concepts related to building templates using Arena. As described in Chapter 1, Arena provides a fully integrated environment for building, graphically animating, verifying, and analyzing simulation models. It does so by the creation of reusable modeling components called modules that are collected into libraries, or templates. To introduce you to template building, we start by reviewing the model-building process in Arena.
2 Overview
Modeling with 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, refer to the Arena Users Guide and online help. To use a module in an Arena model, a panel containing the module is attached to the Project Bar. This panel displays all of the modules that may be selected for placement in the model. To build a model, you select a module from the panel and place it in the model window. The graphics associated with the module, referred to as its user view, are added to the model window. This display of the module always contains a module handle (typically the module name) and may include static drawing objects, animation objects, operand display values, and connection points, as illustrated in Figure 2.1.
Figure 2.1 Process module user view
After a module has been placed in the model window, its associated data may be edited by double-clicking on the module. This action opens the modules main dialog, which typically contains one or more changeable values, referred to as operands of the module. These operands provide the mechanisms for changing the behavior of the module in different uses within simulation models. For example, using the Process module from the Basic Process panel, you might seize, delay, and release with a resource named Line D Labeler. In the same model, you might place another Process module that requires a resource named Line D Packer for processing. Entities sent to the first module wait for the Line D Labeler resource. While entities arriving at the second Process module undergo similar logic (i.e., the logic captured in the Process module), they are waiting for a different resource (Line D Packer). To define the flow of entities among modules, either direct connections or station transfers may be used. A direct connection is formed by placing a connection from a module exit point to a module entry point. Entities that leave a module through an exit point are transferred through the connection to the entry point with no time delay. A station transfer takes place when an entity leaves a module by means of a route, transport, or convey, as seen in the Leave or Route modules of the Advanced Transfer panel; in these cases, a station destination is specified and the entity is sent to the module that defines the station, such as an Enter or Station module (Advanced Transfer panel). These station transfers often involve time delays and may require a material transfer device (e.g., person, shuttle car, conveyor) to move the entity to its destination station. After modules are placed in a model and values are provided for their operands, a simulation run may be performed. To initiate a run, Arena generates a SIMAN model file (representing the model logic) and an experiment file (containing data to support the model) based on the modules that have been placed in the Arena model. Values of module operands may cause particular sections of the model to be generated or ignored, may cause the creation of elements in the experiment, and may enable or disable display of animation components. For example, collecting a count in the Record module causes a Count block to be included in the SIMAN model file and a Counters element listing the counter name to be written to the SIMAN experiment file. In this case, no animation component is included automatically. After the model and experiment have been generated and the animation graphics (if any) initialized, the simulation commences, acting on the simulation program (.p) file that results from the model generation phase.
Templates and panels

A template consists of a panel or a set of panels that encompass modeling constructs for a particular application, system, class of systems, or general target environment. A template panel contains modules collected into a file and intended to be presented as a selfcontained group. The panels commonly used for standard Arena modeling include: Basic Process, Advanced Process, and Advanced Transfer. Each panel consists of related
2 ARENA TEMPLATE DEVELOPMENT OVERVIEW
modeling constructs; together, these are documented and referred to as the Arena template. Similarly, the SIMAN template contains two panels: Blocks and Elements. Arena modelers attach template panels to the Project Bar in the application window of the Arena modeling environment. The Project Bar hosts the primary objects used to build a model, so the modeler selects modules from the appropriate Project Bar panel and places them in the model window. The template file that is attached to the Project Bar is called the template panel object file (or .tpo file). The panel displays a list of the modules contained in the .tpo file. When developing your own template, you work with a template panel library file (or .tpl file). This file contains the definitions of the modules in the template panel. The concepts of module definitions and instances are discussed in the next section. To work with a template panel file, you can create a new file by selecting the File > New menu item in Arena and choosing the Template Window option; or use the File > Open menu item to open an existing .tpl file. In either case, you access the module definitions contained in the template panel via a template window, as shown in Figure 2.2. (See The Template Window on page 65 for additional information.)
2 Overview
Figure 2.2 Sample template window
After you have defined the modules that will be contained in the template panel library, you can save the module definitions in a .tpl file. To prepare the template panel for use in a simulation model, a template panel object (.tpo) file is generated, using the Check > Generate TPO menu item. This step verifies that the module definitions are complete, then creates a .tpo file that is ready to be attached for use in a model.
Module definitions and instances

A module in Arena is a single construct that may be selected from a template panel and placed in a model or, as we will see, in the definition of a new module. Each icon in a template panel represents a single module, such as a Create (to generate entities) or Process (for simple processing of entities). The information about a module that is stored in the template panel library (.tpl) file is referred to as the module definition. In the template panel object (.tpo) file, the information contained in the module definitions is condensed for use in a simulation model. When a module is selected from a .tpo file and is placed in a model window, we refer to the representation of the module in the model window as a module instance. The module definition defines the structure of the module and provides default data and visualization of the module. Each time a new instance of the module is created, the new instance contains the defaults provided by the module definition. However, these defaults may be modified by the modeler so that each instance carries with it its own characteristics. For example, the default main dialog for the Create module (provided by the Arena templates Basic Process panel) displays eight operands that the modeler may edit: the module Name or label, the Entity Type (Entity 1, by default), information related to the time between arrivals (the Type, Value, and the number of Units), the number of Entities per Arrival, the Maximum number of Arrivals, and the time of First Creation. (See Figure 2.3.)
Figure 2.3 Main dialog for Create module
The module definition also specifies the characteristics of the Create modules dialog, including the position of the operands, the prompts associated with them, their default values, etc. When a Create module is placed in a model window, an instance is created. Many instances of a given type of module may be placed in the model window. For example, the simulation model may represent a grocery store where different types of
10

2 Overview
customers arrive at varying times or rates. First, a Create module is placed in the model window. The modeler may change the values of the Create module instances operands. For example, the first customer type may utilize the default arrival stream, which is random (exponential). A second type of customer may arrive at a Constant rate. In that case, a modeler might change the value in one instance of the Create modules to Constant. Note that by changing the value in an instance, the modeler does not modify the definition. In the case of the Create module, the next instance (and all instances, until edited) will have a default type of arrival stream of Random (from the module definition). Module instances may be placed in Arena model windows (and later saved in model .doe files) or in the logic windows of new module definitions (to be saved in .tpl files). For simplicitys sake, we usually discuss 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 may be used either in a simulation model or in the definition of a module in another template panel.
Defining a module
A module definition is created by working with five windows: dialog design, logic, switch, user view, and panel icon. A template window (see Figure 2.2) provides a base from which the module definition windows are opened. The items in the Window menu open each of the windows (or the corresponding buttons on the Template Development toolbar may be used) for the selected Module Definitions list. As is the case throughout Arena, you may have as many windows open as you desire (for one or more module definitions). Figure 2.4 shows a template window with the five module definition windows opened for a single example module (Shipping).
11
Figure 2.4 Relationship among Arena template and module definition windows
The five buttons used to open module definition windows (from the toolbar shown in Figure 2.5) are arranged in the order that we find we most often work when initially building a new module; i.e., first defining the dialog design and logic, then switches to control turning on and off module options, and finally the user view and panel icon graphics. However, the five components of a module may be defined in any order. As you work with a module definition, you often will modify the contents of a few of these windows.
Figure 2.5 Template Development toolbar
In this chapter, we have chosen to present an overview of each of the five module definition windows in the order that someone who places an instance of a module will interact with the module. We start with the icon for the module button that is displayed in
12
a template panel; then we describe the user view and the modules dialog design and operands, which are the components of a module instance that a modeler can modify directly. We finish with the underlying module logic and switches, which are not directly accessible to the user of a module.
Panel icon
Three of the aspects of a module definition are visible to the user of the module: the panel icon, the user view, and the modules dialog and operands. First, when the template panel object (.tpo) file is attached to the Project Bar, the panel icons are displayed. This simply is a table of small graphics icons representing the modules contained in the template panel. Figure 2.6 shows the Arena templates Basic Process panel attached to the Project Bar.
2 Overview
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, etc. 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 within a box that opens the modules main dialog when the modeler double-clicks on it), and may contain entry points, exit points, operand values, static drawing graphics, and/or animation objects. The objects in the user view are visible to the modeler; most are changeable by the modeler individually in each module instance. For example, you might place a Process module (from the Basic Process panel) in a model window. Initially, the user view (in the model window) will appear as shown in Figure 2.8, containing the module handle (Process #), an entry point, an exit point, and an animated variable representing the work in process (WIP) or number of entities currently in that model.
Figure 2.8 Process module 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 utilized within 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 2 Overview
The user view for a module definition is created in the User View window. In Figure 2.10, you can see that the user view window for the Process module contains more objects than are displayed by default when an instance of the Process module is first placed in a window. These additional user view objects are not displayed because the values of operands in the default Process module dialog cause them to be switched out. (We discuss switches later in the chapter.)
Figure 2.10 User view window of the definition of Arenas Process module
Dialog design and operands

An important part of a module definition is the user interface, the visual part that a modeler sees when opening a module's dialog or viewing a module's fields in the module spreadsheet. Often, the most challenging part of creating a module is selecting which operands are to be presented to modelers, the default values and display characteristics of these operands, and their organization into one or more dialogs for the module. A module designer might
15
decide to provide only a few operands; modelers using this module have few choices, but are able to work with a very simple module. Complex modules might present dozens of operands, allowing a single module to capture a very complicated process that might vary significantly from system to system or in different cases within a system. Furthermore, through use of switches, the dialog can be reconfigured to display only the appropriate operands, based on the values of other operands as supplied by the modeler. In the Record module from the Basic Process panel, for example, the default dialog that is opened when an instance is first formed appears as shown in Figure 2.11.
Figure 2.11 Record module default dialog
If the modeler changes the Type field from Count to Time Interval in an instance of the Record module, a different operand is displayed with the prompt Attribute Name in place of the Value operand and the operand Tally Name is requested instead of Counter Name. In this case, the modeler will be collecting information on the time difference between the specified attribute names value and the current simulation time, instead of simply increasing or decreasing a specified count. In a template panel library (.tpl) file, the Dialog Design window is the interface for defining the dialog form layout(s) and operands of a module definition. In this window, a module designer defines dialog sizes, data displayed to and entered by the user, default and permissible values, and the layout of interface controls. The dialog design window includes an Operand Explorer section to browse the module definition's hierarchy of dialogs (many modules contain multiple dialogs), operands, and repeat groups (for defining repeatable operands or sets of operands, such as the resources to be utilized in a process). It also includes a Toolbox section to add user interface controls to the modules dialog forms and a Design Properties grid to edit the properties of one or more selected objects.
16

2 Overview
Figure 2.12 shows the dialog design window for the definition of the Basic Process panels Batch module, which simply contains a main dialog and a number of operands that are members of the dialog.
Figure 2.12 Dialog design window for the Batch modules definition
A modeler working with a module instance may modify the values of operands, but cannot change the configuration of dialogs, the default values supplied when a new instance of a module is placed in a window, or the associations among operands. These characteristics of a modules data are part of the module definition; each instance simply supplies values to the operands provided by the definition.
Logic
The final two aspects of a module are hidden from the modeler: the module logic and the definition of module switches. The logic underlying an Arena module definition is created simply by building an Arena submodel. The Logic window, which is used to create a module 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.
17
Note that the logic window is the second window in Arena that can contain instances of modules. As mentioned previously, in this guide we most often discuss placement of modules in model windows by the modeler. Remember, as you read, that these discussions also refer to the creation of module logic unless otherwise noted. Note that when the logic window is active, the Run toolbar is not available because Arena module definitions cannot be simulated 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 may turn on the display of the animation objects in the window by using the View > Layers menu item. An important aspect of defining Arena modules is the tie between the operands and logic. The operands provide the external interface for a modeler; the logic is the internal behavior of the module under the circumstances defined by the values of operands. A modeler can customize a 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 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 simply provide the name of the clerk and the time to process an admission. In the underlying logic, we will use the Process module from the Basic Process panel. A sample dialog for the Admissions Clerk module is shown in Figure 2.13.
Figure 2.13 Dialog for hospital Admissions Clerk module
In each instance of the Admissions Clerk module, different values might be given for the two module operands (Clerk Name and Time to Admit). To use these values, we will pass the value of the Clerk Name operand to the Resource name field in the Process module, and the Time to Admit operand to the Expression field. To reference an operand of the module from an instance (such as the Process module), you edit the instance in the logic window; wherever you would like to use the value of a
18

2 Overview
module operand, you enclose the name of the operand in back quotes (`). Assuming that the operands have the same name as the prompts (i.e., Clerk Name and Time to Admit), the references would be established in the Process module as `Clerk Name` and `Time to Admit` as shown in Figure 2.14.
Figure 2.14 Operand references in Process module for Admissions Clerk module
If one instance of the admissions clerk module has values Mary and UNIFORM(10,30) for the module operands, then effectively a Process module has been placed in the underlying model logic with values of Mary for the resource to be utilized and UNIFORM(10,30) for the process time.
19
Unlike a module instances user view and operands, the modules logic cannot be directly modified by a modeler. Instead, the modules operands may be used to specialize an instance of a module to a particular need by passing data to the logic (i.e., the module instances in the logic window) and, as we will see, by causing sections of the logic to be switched in or out. Note that there may be one or more operands in a logic module instance (in the logic window) that are not available for the end user. For example, in the Process module description above, the Type remains the default Standard, Action is Seize Delay Release, Priority is default of Medium(2), and Delay Type is Expression. These operand values cannot be changed by a modeler, as they are not accessible via operands in their module.
Switches
In an Arena module definition, individual objects in the user view, dialog design, and logic windows may be selected to be included in an instance only if a particular condition is true. For example, an instance of the Record module in the Basic Process panel only displays the Value operand if the Type is Count or Expression. If the Type is Entity Statistics, Time Interval, or Time Between, then the Value operand is not displayed; Instead, other operands relating to those types of statistics are displayed; we refer to this as being switched out. In the underlying module logic, a Count block is included in the logic (with the appropriate values referenced from the 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 may 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

2 Overview
The definition of a switch is based on conditions involving the values of operands, such as ` Type`== Count defining a switch whose value is true whenever the operand Type has a value equal to Count. (Operands are referenced by enclosing the operand name in back quotes, as in the logic window; values are enclosed in double quotes.) To use a switch in the user view or logic windows, the switch is attached to the object. In the dialog design window, a switch is added to an object by specifying the 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
Use of switches in module definitions can aid users of the module in focusing attention only on the fields that are relevant given other information theyve provided (e.g., if a modeler has indicated that a count type of statistic be collected, there is no reason to display the Tally Name field). Also, switches used in the logic window can ensure that efficient models are generated for performing simulation runs. In the case of the Record module, rather than requiring each entity to query whether or not a count should be collected, the logic either is written out for all entities to perform, or is omitted from the model entirely if no count is to be collected. Of course, in some cases, different entities might undergo different logic, in which case a module such as the Decide module (from the Basic Process panel) can be placed in the logic window to make the decision. But if a particular selection is to apply to all entities that are processed through the module, switches are an effective way to ensure efficient simulation logic.
21
Elements and properties

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

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

2 Overview
represent subsets of a process or set of similar processes may be developed and verified once, then may be reused to define new, higher-level modules that correspond to a process; such as a computer CPU, a ticket agent, or a canning line labeler. The component modules (e.g., select next job to process, enter passenger name, or wrap label) also may be utilized directly in models to capture accurately the nature of complex systems or of system elements that have peculiar facets not represented by higher-level modules. The base modules of 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, Branch, etc. Many of the modules in the Arena template are given the same name as Blocks modules and perform the same function as their Blocks panel counterparts. However, the modules in Arena offer options for the types of information that is to be placed in an operand (e.g., whether the type of element to be assigned a value is an attribute, a variable, a picture, etc.), and define both the model logic (i.e., blocks) and elements (i.e., information to be written to 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, counters, etc. Many data modules in the Arena template panels (e.g., resources, queues, conveyors) correspond to modules in the Elements panel. When you build a new module definition, one of the steps is to define the logic associated with the module. In doing this, you attach one or more template panels to the Project Bar and place instances of modules. If these modules come from the SIMAN template (Blocks/Elements panels), when a modeler uses your module, the final SIMAN model and experiment used for a simulation run are generated directly through the modules you placed. This may be thought of as a module utilizing a single level of hierarchy, as illustrated in Figure 2.17.
Figure 2.17 Single level of module hierarchy (SIMAN modules in logic window)
A modeler (or template designer) who uses ModuleA does not need to understand about the underlying structure of the module (i.e., the contents of the logic window). Instead, you have created a new interface to a DELAY followed by a SIGNAL by defining ModuleAs operands and by establishing the references to those operands in the DELAY
23
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
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.
24
While flowchart modules are placed in the model window and are connected to form a flowchart and describe the logic of your system, data modules are not placed in the model window. Instead, they are edited via a spreadsheet interface. For more information on defining a module as a data module, see Defining data modules on page 73 of The Template Window.
Use of templates Introduction

Templates may be developed using Arena to address a wide range of needs. Some templates will be conceived for use by a large targeted market; others will be intended for use simply by the template designer to increase productivity in building simulation models. In this section, we outline some of the possible uses of Arena template development features. We are confident that this list represents only the tip of the iceberg.
2 Overview
General modeling tools

The first templates developed in Arena were the SIMAN and Arena templates. The two panels composing the SIMAN templateBlocks and Elementsprovide a graphical interface to the SIMAN language for modelers and form the base of all Arena modules. The three panels composing the Arena templateBasic Process, Advanced Process, and Advanced Transferprovide modules that capture commonly encountered processes and system elements using generic terminology (e.g., process, decide, record). In the manufacturing area, modelers have exploited the powerful capabilities built into SIMAN and Arena for capturing essential system characteristics, including operational schedules, process plans, automated material-handling systems, etc. Modelers also have applied the Arena template to represent systems such as airline operations, health care, logistics, distribution, and business process reengineering (BPR). And, even within some organizations, Arena has been used for a wide spectrum of simulation studies, from longrange planning to analysis of near-term system changes. The strength of a general modeling tool, used in a single, cohesive environment, is that modelers are provided with a core set of terms and concepts that can be applied to many different problems. Knowledge gained in studying one system can readily be applied in performing the next simulation project.
Industry-oriented environments
Templates also have been developed targeting use in a particular industry, such as wafer fabrication in the semiconductor industry. Such templates might be developed for commercial use, or in the case of an organization that provides support to an industry, templates might be developed and made available to companies in the industry.
25
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 simply mapping existing modeling functionality provided by a general modeling tool. The designer of the template has the capabilities at hand to mimic exactly the behavior of equipment, people, parts, components, etc., providing whatever spectrum of options is appropriate for the variations of these system elements.
Application-focused tools
Many of the templates that are developed using Arena will aid modelers in representing a particular system, facility, or process. In building these templates, the template designer will have a more narrow focus than the developer of a general modeling template or a template to be used widely in an industry. For example, a template might be built for use in analyzing engine assembly lines in an automotive company or for representing delivery of pharmaceuticals in a hospital. The 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 dialogs); and parts, processes, etc., in the target application environments can be represented accurately. In some cases, a modeler might build a template for his/her own individual use. In other cases, templates might be created for use among a few modelers in a common group; many application-focused templates will be shared among different modeling groups in an organization.
Improving modeling productivity and sharing modeling technology

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

2 Overview
By permitting you to collect all of the important characteristics of a simulated system element (i.e., the logic, the animation, and the data) in a single module, Arena encourages you to both reuse and share what you learn. For example, in modeling a computer network, you might develop a set of modules that capture the logic for allocating jobs to a printer. Each time you need to model another printer, you could copy the logic directly into the model (by selecting and duplicating all of the modules that represent the logic). Or, using Arena, you could instead create a single module to represent the printer, embedding the logic in the modules definition. The second approachbuilding a reusable printer moduledecreases 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
28
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-bystep tutorial that you can follow using the Arena software. If you follow the instructions in this chapter, at the end of the tutorial you will have built a complete module representing a high-speed computer printing station, and you will have created a simulation model using it. While the module you will create is quite simple, it does include the key elements of module definitions: a dialog with a few operands, simulation logic, a user view with animation, and a panel icon. As you build the module outlined in this chapter, it may be helpful to refer to Chapter 2, Arena Template Development Overview, which provides definitions of important terms and explains critical concepts related to building templates. We begin by describing the module that is to be built. Following this, we present sections that document the procedure used in four module definition windows (dialog design, logic, user view, and panel icon) to create the module. Finally, we use the module to build a small simulation model.
Module overview
To illustrate the process of building a module in Arena, we will create a module representing a high-speed printing station in a computer network. Models that utilize this Printer module will contain entities representing print jobs. Our Printer module will be analogous to a server; i.e., it will accept entities to be processed and will send the entities, after processing, to another module. It does not create or dispose of entities. The logic captured by the Printer module includes the concept of a changeover. If the type of job being printed (represented by an entity attribute) changes from one job to another, a technician is signaled to perform a changeover activity, such as changing the paper type feeding the printer. In designing a module such as the Printer example, one of the important decisions to be made is what operands will be presented to the modeler. If you present only a few important operands, modelers will be provided with a simple interface that focuses attention on the most important characteristics of the process represented by the module. However, by limiting the number of operands presented, you also place a restriction on the flexibility a modeler has to tailor the module to represent a particular system accurately.
29
For this tutorial, we will start small and supply only a few operands with the Printer module. Keep in mind, though, that many additional options could be provided to a modeler by expanding the operands defined in the module. After you have created the Printer module described in the tutorial, you can try to expand this example by placing additional operands to solicit other options from the modeler. The Printer module dialog is shown in Figure 3.1.
Figure 3.1 Printer module dialog
In the Printer module, we ask the modeler to enter the following information: the Printer Name, which will provide the name of the printer resource as well as the queue name for those entities waiting for the printer resource, the Technician who performs the changeover, which will define a resource, the Changeover Time (used only during changeovers between job types), and the Print Time (i.e., the time required to print the entire job). The logic window associated with the completed Printer module is shown in Figure 3.2. So that you have an understanding of the logic we plan to represent by the Printer module, we provide a brief description in this section. A combination of modules from the SIMAN Blocks and Elements panels and Arenas Basic Process panel is used. Step-by-step instructions for creating this logic are presented later in the chapter.
30
3 MODULE-BUILDING TUTORIAL
Figure 3.2 Printer module logic 3 Module-building Tutorial
A print job entity arriving at the Printer module begins processing at the Queue module instance. The print job waits to seize the printer resource, then tests in the Decide module to determine whether a changeover should occur. If there is a changeover, the entity follows the changeover logic path (shown from the True exit to the Assign module). In this case, it changes a variable, `Printer Name`_Change, to the value of 1 to indicate that a changeover is taking place and performs the changeover in the Process module. Following the changeover, the print job entity restores the changeover variable back to 0 and changes a variable that records the last job type processed on the printer (to the entitys job type). If no changeover was required, the entity is sent from the Else (or false) condition of the Decide module directly to the Delay module to process the print job. (Entities that underwent a changeover also enter the Delay module after completing the changeover process.) After the print time delay, the print job entity releases the printer resource. To create the Printer module logic, you may either build the submodel directly in the logic window of the module definition or you may prepare an Arena model with the same logic. If you build the logic first as an Arena model, you have the opportunity to use 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 via 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 concurrently discuss both the sample problem to be addressed (i.e., the high-speed printer station module) and the particular aspects relating to creating modules. You may want to create the logic shown in Figure 3.2 in a model window first in order to develop an understanding of the module we will be creating in this tutorial. We will present the Printer module definition windows in the following order: Dialog Design, Logic, User View, Panel Icon. We do so because we find that it is important to consider together the module logic and the operands when designing a module. In this tutorial, we present the dialog design window first because it can be completely defined and tested without the underlying module logic. The logic, on the other hand, is difficult to test without operands to provide an interface for defining the data that can change from instance to instance of the module. When you are developing your own modules, you probably will find that you move back and forth between defining the module logic and adding operands in the dialog design window, which we find to be a natural way of creating a complete module definition.
Getting 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 may 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 object (defined in the dialog design window), the default title of the modules main dialog, and the default name of the module handle (defined in the user view window). To open each of the module definition windows, be sure that the Printer module is selected in the Module Definitions list. To select it, simply click on the module name. We will return to the template window in A Sample Model on page 57 to prepare the template panel file for use in an Arena model.
Note: If you would like to save the template panel to a template panel library (.tpl) file, select the File > Save menu item from the main menu bar.
Dialog Design The dialog design window

We begin designing the Printer module by defining its dialog design and its operands. Open the dialog design window by selecting the Printer module (in the template window's Module Definitions list), then select the Window > Dialog Design menu item or click the Dialog Design Window toolbar button on the Template Development toolbar. This opens the dialog design interface for the Printer module, as shown in Figure 3.4.
33
Figure 3.4 Dialog design window
The dialog design window consists of the following components: Dialog Formthe dialog form layout is displayed in the center of the window. Toolboxprovides an interface for graphically adding controls (e.g., text boxes, combo boxes, or dialog buttons) and static graphics (e.g., text, lines, or group boxes) to the dialog form layout(s). Operand Explorerdisplays the hierarchical organization of the dialog form, operand, and repeat group objects that define the dialog 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 design window is opened, by default the main dialog form of the module is displayed in the center of the window. Thus, for our Printer module definition, we see a dialog form named Printer. This is the dialog that will be displayed when the modeler double-clicks on an instance of a Printer module in a model window. To specify the dimensions of the dialog form, go to the Design Properties window. This window should display the properties of the Printer DialogForm object. Edit the Height and Width property rows and enter a height of 110 and a width of 170.
34
Figure 3.5 Design properties of the Printer DialogForm object
Note that you can also graphically resize a dialog form. First click anywhere on the form to make sure that it is selected. Then, click and drag one of the sizing handles that appear on the border of the form. The sizing handles resemble small black boxes, and the pointer turns into a double-headed arrow when you point at the handle.
Adding the modules dialog operands

The Printer modules dialog will include four visible operands editable by the user (as shown previously in Figure 3.1): Printer Name (combo box control), Technician (combo box control), Changeover Time (text box control), and Print Time (text box control). PRINTER NAME
OPERAND
To add the Printer Name operand to the dialog form layout and module definition, perform the following steps: 1. Click on the ComboBox control in the Toolbox section. Then, move the pointer to the location in the dialog form where the Printer Name operand is to be placed. Leftclick again to place the combo box on the dialog form layout.
Note: At this point, your dialog form layout may not resemble the form in Figure 3.1. You will learn how to arrange the operands graphically in Arranging the Dialog form layout on page 39.
2. In the Design Properties window, specify the properties of the selected combo box as follows: Specify the Name property as Printer Name. This is the name of the operand. It will be used in the logic window for operand references (to provide the value entered by a modeler in an instance of the Printer module to the underlying logic). The Name property is the automatic default for the Text property, which is the prompt text that is shown to the user on the dialog form.
35
Specify the DataType property as SymbolName. This will ensure that a modeler using the Printer module can specify only a valid symbol name for the Printer Name operand. Specify the Required property as True. This will require that any use of an instance of the Printer module will have a non-blank value for the Printer Name operand. Specify the InUserView property as True. Because the Printer Name is the primary piece of information related to the Printer module, displaying it in the user view will help a modeler identify the particular printers represented in a model if more than one Printer module is used. 3. In the Design Properties window, select the LogicProperties property of the combo box. This property provides a dialog for specifying characteristics of the operand related to its purpose in the 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 is completed according to Figure 3.6.
Figure 3.6 Logic properties of the Printer Name ComboBox object
The items that will be displayed and available for selection in a ComboBox 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.
36
TECHNICIAN, CHANGEOVER TIME,
AND
PRINT TIME
OPERANDS
The three remaining visible operandsTechnician, Changeover Time, and Print Time are defined in the same manner as the Printer Name operand. The Technician operand is added using a ComboBox control. This operand also defines a name for a resource, and thus in the LogicProperties property the 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 seen and editable by users in the modules dialog, two hidden operands will be added to the module definition. These operands will be used to define the entry and exit points of the module, thus allowing the user to connect other modules into and out of the Printer module for entity flow. Because the entry label and exit label operand fields are hidden from the user, the user will not have access to the fields within the dialog box. However, graphical entry and exit points will be available in the modules user view to place the module connections. To add a hidden operand to the module definition, click on the HiddenOperand control in the Toolbox section. Then, move the pointer to any location in the dialog form and leftclick again to add the hidden operand. The hidden operand will be displayed in a window section at the bottom of the dialog design (and also in the Operand Explorer tree) as shown in Figure 3.7.
37
HiddenOperand object
Figure 3.7 HiddenOperand object in the dialog design window
After adding two hidden operands to the dialog design and module definition, specify the Name properties of the two operands as Label and Next Label. In the LogicProperties property of the operands, specify the operands as entry and exit points per Figure 3.8 and Figure 3.9.
38
Figure 3.8 Logic properties of the Label HiddenOperand object 3 Module-building Tutorial
Figure 3.9 Logic properties of the Next Label HiddenOperand object
Arranging the Dialog form layout

At this point, you have completed the definition of the Printer modules operands. Controls that have been placed onto a dialog forms surface may be graphically selected, moved, and resized. Arrange the combo box and text box controls on the Printer dialog
39
form such that the layout looks like Figure 3.1. The completed dialog design window for the Printer module should look similar to Figure 3.10 below.
Figure 3.10 Completed dialog design for Printer module
You can close the dialog design window by clicking the Window Close button, or you can leave the dialog design window open for reference while you define the module logic.
Logic The logic window

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

When a modeler places an instance of the Printer module, the underlying logic of the module will be added to the model window. As we described earlier in this chapter, the Printer module accepts entities at a queue, processes them through logic with resources, and sends them to the next module to which the Printer module is connected. The Printer Name operand will be used to establish the name of the queue and the resource in the underlying module logic so that a modeler can identify different printer areas by placing multiple instances of the Printer module and supplying different values to the Printer Name operand. The name of the queue that holds entities prior to processing will reference the Printer Name operand and will include a _Q text string that will be appended to the printer name so that the queue name will be unique, but related to the resource name. To capture the logic necessary for detecting when a changeover is to occur, a simulation variable is used. Each time an entity performs a changeover, a variable associated with the printer is assigned the job type of the entity, indicating the type of the last job processed on the printer. To name this variable, _LAST is appended to the Printer Name (similar 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 module logic.
41
As you create the module, it may be helpful to refer to this figure to ensure that you are correctly connecting the modules in the logic window.
Figure 3.11 Printer module logic
Receiving entities and seizing the printerThe Queue and Seize modules
The first module instance in the Printer logic is the Queue module from the SIMAN templates Blocks panel. Entities would first be created in another module in the model, such as a Create module. A graphical connection from a module would then send entities into the Printer module, where entities will begin processing through the Printer module logic at this Queue module. In its dialog, shown in Figure 3.12, you specify that the name of the Queue module is a reference to the Printer Name operand by entering the operand name enclosed in back quotes (i.e., `Printer Name`). In this case, our queue name will have the _Q appended so that it is different from the resource name. The label field for
42
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 in printer logic
Alternatively, you could have used either the Station or Enter modules from the Advanced Transfer panel to receive entities into the Printer module. Using stations allows for the movement (with an optional delay time) between areas, instead of graphical connections for logic flow. The print job entities will remain in the queue until the printer resource is available, at which time they will Seize the printer resource using a SIMAN Seize module. Note that the printer is seized before a decision is made regarding a changeover. The module is designed this way so that the printer resource is unavailable to process other print jobs during a changeover.
43
In the Seize module instance, you identify the resource to be seized by inserting a single resource into the Resources list. Specify the Resource ID field to be `Printer Name`. Figure 3.13 shows the dialog for the Seize module instance.
Figure 3.13 Seize module dialog in printer logic
Deciding whether to changeover the 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 for the Decide module instance is shown in Figure 3.14. The dialog is shown with the test condition for detecting changeovers. To define the Decide module, use a twoway condition testing the variable `Printer Name`_LAST against the entity attribute
44
Entity.Type, as shown in Figure 3.14. The Else (or false) condition is generated automatically with a 2-way by Condition type of decision.
Figure 3.14 Decide module dialog in printer logic 3 Module-building Tutorial
In the logic window, the connection from the True condition sends entities to the changeover logic, (described next). The False condition connects directly to the printer logic (described after the changeover section).
Note: Because different entities in the same model might access either path of logic, the decision regarding changeover is built into the simulation model logic, rather than controlled by attaching switches to the modules. Switches determine logic to be included for all entities. In cases where different types of entities perform different actions, a module such as Decide (N-way by Condition) or SIMAN Branch block should be used. (Switches are described in the Arena Template Development Overview and Switch Window chapters.)
Changeover 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 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 is shown in Figure 3.15. To define this Assign module, you insert an assignment, keep the default Type as Variable, specify the variable name as `Printer Name`_Change, and type the new value of 1.
Figure 3.15 Assigning printer changeover variable in printer logic
To define the actual changeover process, you supply the resource name and process time information to the Process module by referencing the Technician and Changeover Time operands of the Printer module, as shown in Figure 3.16. Note that you will change the Action field to Seize Delay Release to specify the logic for seizing and releasing the specified technician during the changeover. Also, because the changeover time is defined as an expression, the Delay Type field is changed to Expression so that the `Changeover Time` operand can be used in the Expression field.
46

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 in printer logic
The final module in the changeover logic is another Assign module with two assignments: the printer changeover variable and the last job type printed. To supply this information to the Assign module, insert two assignments. In the first assignment, select the Variable (as was done in the first Assign module) for the assignment type; then enter `Printer Name`_Change for the variable name and 0 for the new value. In the second
47
assignment, select Variable for the assignment type and enter `Printer Name`_LAST for the variable name and Entity.Type for the new value, as shown in Figure 3.17.
Figure 3.17 Assigning last job variable in printer logic
The print logicDelay and Release modules

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

SIMAN block does not specify a time unit, such as hours or minutes. The default time units for modules will be set later in this example using the Run > Setup menu.
Figure 3.18 Delay module dialog in printer logic
The Release module simply needs to release the printer resource. To define this, insert a single resource in the Release module and define its name to be `Printer Name`, as was done in the Seize module. Because this is the last module in the logic, the exit point operand, Next Label, will be referenced in the Next Label field of the Release module.
49
This will allow entities to flow from the Printer module to the next module to which it is graphically connected. Figure 3.19 shows the dialog for the Release module.
Figure 3.19 Release module instance dialog in printer logic
Just as we mentioned earlier that the Enter or Station module could be used to enter into the module (instead of graphically connecting into the Queue module), we could have used a Route or Leave module to send entities to another station in the model. In this case, a Next Activity operand would have been required to specify where to send the entity instead of graphically connecting from the Release module. Additionally, the Stations element would need to be generated.
Defining the Printer module 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 in printer logic
51
Similarly, the `Printer Name`_Change variable can be generated by placing a Variables module instance from the Elements panel. Within the module, add a single variable, named `Printer Name`_Change, as shown in Figure 3.21.
Figure 3.21 Variables module dialog in printer logic
The Entity.Type attribute is automatically generated as one of the internal attributes of all entities when the entity type is specified with a Create module (from Blocks or Basic Process panel). Therefore, an Attributes element module is not necessary to define Entity.Type. However, remember that because this attribute is used to evaluate incoming entities for changeovers, the entity should have an assigned entity type value before entering the Printer module. Otherwise, all entities will have an Entity.Type value equal to 0 and no changeovers will occur.
52
The logic for the Printer module now is complete. You may close the logic window by selecting the Close option from the logic window menu, or you may leave the window open while you define the last two parts of the Printer modulethe user view and panel icon.
Note: In this example, we have used the logic window to create two elements associated with the printer, the queue, and the changeover variable. These elements could have been generated, instead, by utilizing hidden element-type operands in the dialog design window. Based on the information you wish to provide the user for a given element, you will need to decide which method to use for creating specific elements and their properties. Please refer to the chapter Elements for a more in-depth discussion of the various ways to define elements.
User View
The next step is to design the user view for the Printer module. When a modeler places an instance of the Printer module in a window (e.g., a model window), the objects that are added to the window are created in the module 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. Arena places the displayed operand in the user view window after the Printer Name operand was defined with the InUserview property specified as True (in the dialog design window). The entry and exit points are automatically placed when an operand is of type Entry Point or Exit Point. To complete the user view, you will add an animation resource to display the state of the printer during a simulation run and an animation global picture to display a symbol during the changeover process.
53
To open the user view window, select the Window > User View menu item or click on the User View toolbar button on the Template Development toolbar. The user view for the Printer module should appear as shown in Figure 3.22.
Figure 3.22 Initial user view window for Printer module
To add an animation resource, place the resource picture (from the Animate toolbar) above the Printer module handle name and double-click on it to open the Animation Resource dialog. In this dialog, specify the resource identifier to be `Printer Name`, so that the name of the animation resource matches the resource defined when a modeler uses the Printer module. The Printer module needs two pictures for the resource to represent the Idle and Busy states. You specify the resource states and draw the pictures just as is done in Arena models.
54
Figure 3.23 shows the completed resource picture dialog for the Printer module.
Figure 3.23 Animation resource picture dialog
Finally, add an animated global picture to the left of the resource by using the Global button on the Animate toolbar. Specify the expression to be `Printer Name`_Change (the variable that is assigned to 1 during a changeover). The trigger value for the global should be 1, so that the picture you place will show up only when the changeover is occurring. When the value of `Printer Name`_Change variable is set to 0 (after the changeover is
55
complete), the global symbol will then disappear, since no picture is specified for a trigger value of 0. Figure 3.24 shows the completed global picture.
Figure 3.24 Animation global picture dialog
The global picture is used instead of animating the `Technician` resource who performs the changeover. This is done because the technician may be required to perform changeovers at many different printer modules in the model. The global symbol will show the picture of a technician only when the changeover is occurring at that particular printer module.
Panel Icon
The panel icon for a module is the picture that appears in the panel when a template panel file is attached to a model window (or to the logic window of another modules definition). It is drawn in a window that is similar to the picture edit window used to create animation resources, entities, etc.
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 on 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. The Printer module is part of a template panel library. If you have not yet saved your template panel to a library file, do so now by selecting the File > Save menu item from the
57
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 design window, the operands referenced in the user view window are defined, etc. If you correctly followed the instructions for building the Printer module, you should receive a message that the .tpo file was generated successfully. However, if your module definition contains an error, an Arena error window will be displayed containing a description of the error. For example, if you mistyped the operand reference (`Print Time`) in the logic 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 for the object containing the error (i.e., the Delay module instance). You can type the correction in the dialog and select OK, then generate the .tpo file. Warnings, on the other hand, do not have to be resolved. The .tpo file will generate successfully regardless of whether you choose to address the warnings. This, of course, has nothing to do with the correctness of your module definition; the .tpo file will still be generated successfully. After you have successfully generated a template panel object file, you can use the Printer module in a simulation model to test its logic, animation, and so on. In the following section, we present a simple model containing a single printer.
Single printer simulation model

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

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 contant with a value of 1 minute. The second Create module instance requires similar information. Enter a name, Entity 2 Jobs, the time between arrivals is constant, arriving every 10 minutes. Change the Entity Type field to Entity 2 and change the
59
default first entity creation time from 0.0 to 10 minutes. Figures 3.27 and Figure 3.28 show the Create modules for each entity type.
Figure 3.27 Create module dialog for Entity 1 jobs
Figure 3.28 Create module dialog for Entity 2 jobs
PROCESSING
THE PRINT 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 (e.g., HSPrint.tpo).
Note: If the file you created does not appear in the list, you may have forgotten to generate the .tpo file after correcting errors. Open the template window and click on the Generate toolbar button to create a template panel object file.
60
The template panel should contain a single icon, the panel icon you drew to represent the Printer module, as shown in Figure 3.29.
Figure 3.29 Template panel with Printer module panel icon
Place an instance of the Printer module in the model window and edit it by double-clicking on the Printer module handle. Figure 3.30 shows the completed Printer module dialog. In the Printer module, enter the Printer Name as HSPrinter 1. This will automatically create a resource named HSPrinter 1 and will place it on the list of resources. It will also provide the information to the Seize and Release modules in the underlying logic. This name will provide names for the queue (HSPrinter 1_Q) and variables HSPrinter1_LAST and HSPrinter_Change. Enter a name for the Technician field, Changeover Tech. This will also create a resource and place it on the resource list. The Changeover Tech will be the resource utilized in the Process module in the underlying logic for performing the changeover. Finally, specify that the time to conduct a changeover is .2 minutes and the print time is .5 minutes.
Figure 3.30 Printer module instance dialog
61
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 (i.e., 10 Entity 1 jobs and one Entity 2 job). With a changeover time of .2 minutes, we can predict that the changeover tech will be used 4% of the time. This is calculated by two changeovers (at .2 minutes / changeover) every 10 minutes (one changeover to Entity 1, another to Entity 2) with a total time of .4 every 10 minutes. With a printing time of .5 minutes, we can predict that the percent of time that the printer is actually printing should be 55% (i.e., there should be 5.5 minutes 11*0.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), so 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 changeover time. Figure 3.31 shows the animation of the Printer module during the first changeover.
62
Figure 3.31 Animation of Printer module during first changeover
Through the rest of the simulation, you should see a cycle of changeovers to Entity 1, processing of Entity 1 jobs, changeovers to Entity 2, processing of Entity 2 jobs, etc. At the end of the simulation, you will be asked if you would like to view the simulation results. The Category Overview report will be generated to show overview information on entities, queues, and resources. These reports may be viewed by using the arrows on the top of the window. Additional reports can be selected in the Reports panel, including Entities, Queues and Resources reports. As expected, the printer resource was busy 59% of the time, which included 4% of the time for changeovers (i.e., two changeovers of duration .2 minutes for every 10 simulation minutes); and was idle the remaining 41% of the run. Figure 3.32 shows the first Resource report showing the Resource Detail Summary from the simulation run.
Figure 3.32 Resources report showing Resource Detail Summary
63
Summary
You have defined a complete simulation module, the Printer module, that captures the logic associated with a high-speed printing area and permits a modeler to provide values that define critical characteristics of a printing process. This module can be used in building simulation models or, by attaching its template panel object file to the Project Bar and using it in the logic window of another modules definition, it may be used to create new template panels.
64
The Template Window

Arenas template development features center around designing and creating templates consisting of modules. These modules may be used in simulation models (by placing them in Arena model windows), or in the definition of other modules (by placing them in the logic windows of other module definitions). A template panel simply is a file containing a library of module definitions. The template window, displayed by creating a new template document or opening an existing one, is a base window from which new modules are defined. From the Template Development toolbar, you can then access the five module definition windowsdialog 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. Opening a template window causes the Template Development toolbar to appear. 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, simply click the Add button, type the desired name, and press OK. (See Figure 4.1 for a sample template window.) To rename a module at any time, highlight the desired module name and click the Edit button. A dialog box will appear prompting you for the new module name. Two check boxes (Required and Data Module), a field for Name Operand, and an Expression Builder Defintions button are also in the module definition dialog box. Please refer to Template options on page 71 for more information on these items. To delete a module from the template panel file, highlight the module and press the Delete button. A dialog will appear asking you to confirm the deletion. To reorder existing module definitions, use the CTRL+Up arrow and CTRL+Down arrow keystrokes to move the highlighted module up or down in the list, respectively.
Note: The order in which modules will be displayed in a panel (when the template panel is attached to the Project Bar) is defined by the order in which they appear in the Module Definitions list.
66
4 THE TEMPLATE WINDOW
Opening module definition windows

Each module has five associated module definition windows: dialog design, logic, switch, user view, and panel icon. To open one of the module definition windows, highlight the module in the list, then choose the definition window you wish to open from the Window menu option, or press the toolbar button for the desired window. Figure 4.2 shows the five toolbar buttons that open module definition windows.
Figure 4.2 Template Development toolbar with Dialog Design, Logic, Switch, User View, and Panel Icon buttons
For example, to open the logic window of a specific module, highlight the module name and choose the Window > Logic menu option or press on the Logic Window toolbar button from the Template Development toolbar.
Preparing the template panel for use Checking the template panel for errors and warnings
To check the modules in a template panel for possible errors, choose the Check > Template menu option from the main menu bar or press the Check toolbar button from the Template Development toolbar. All errors detected in the template panel will appear in the Error window. The warnings and errors created by checking template panels are displayed using the same 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. 4 The Template Window
Whenever possible, Arena will help you locate and/or correct the error when you click the Find and/or Edit buttons in the Error window. If you click the Find button, the module definition window containing the object that caused the warning or error will be activated, and the construct will be highlighted. For example, if you have referenced an operand Order Size in a 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 case, you can use the Find button to open the logic window and to locate the module that referenced Order Size. The Edit button performs the same function as Find, but in addition to locating the object, it also opens the dialog of the object that caused the error or warning so that you may directly correct the error.
67
Figure 4.3 Template panel Check Error message Note: If no errors are detected when the template panel is checked, a message to that effect is displayed. Simply click OK to close the message box.
Reviewing errors
If you wish to review errors that have already been reported in an Error window, choose the Check > Review Errors menu option from the main menu bar. Note that this function only retrieves previously generated error messages; it will not recheck the template panel. If you have made changes to the template panel since the last time it was checked, you should recheck the template panel before reviewing errors.
Template panel file reports

Arena provides summary reports of the names and positions of objects in the dialog design window and the definitions of switches for the module definitions in a template panel file. (Refer to The Dialog Design Window and The Switch Window chapters for a description of operands and switches.) These reports can aid you in designing dialogs and in validating the definition of switches in complex modules. To view these reports, choose the Check > Report menu option from the main menu bar. The report dialog is opened, as shown in Figure 4.4.
Figure 4.4 Template panel Report dialog
68
You may elect to view the operand and/or switch report; you also may show a report for all modules in the template panel file or for a single module. The requested report(s) is displayed in a scrollable text window. You may save the contents of the report to a text file by selecting the File > Save menu item (that appears in the text window), or you may print the report via the File > Print item. OPERAND POSITIONS
REPORT
The Operand Positions report contains a listing of all operands, repeat groups, and dialogs in a table providing their display locations in the module dialog. Hidden operands are designated with (HD) following their names, repeat groups with (RG), and dialogs with (DB). Figure 4.5 shows a sample Operand Positions report.
Figure 4.5 Sample Operand Positions report
OPERAND PROMPTS
REPORT
The Operand Prompts report simply lists the operand names and their associated prompts. This report should be provided to users of the template for use with the Module Data Import > Export function.
69
SWITCH
REPORT
The Switch report simply lists the switch names and definitions, as illustrated in Figure 4.6.
Figure 4.6 Sample Switch report
Generating the template panel object (.tpo) file

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

The Version entry in the template window is designed to help you record updates that you may make to the template panels you create.
70
Template options
A number of additional characteristics of template panels may be changed using the Template Options dialog. To open it, select the Edit > Template Options menu item from the main menu bar. The Template Options dialog is opened, as shown in Figure 4.7.
Figure 4.7 Template Options dialog
CHANGING
THE TEMPLATE DISPLAY NAME
By default, panels attached to the Project Bar display a label in the panel title bar corresponding to the file name given to the template panel object (.tpo) file. If you wish, you may change the name that is displayed on the panel by typing the new label in the Template Display Name field and choosing OK.
Note: Changing the display name does not modify the name of the .tpl/.tpo files; it simply provides a new text string to be displayed on the top of the panel.
CREATING PRIVATE
TEMPLATE PANELS
You may want to create a template panel that is only to be used in the creation of other templates, not in the creation of simulation models. We refer to this type of template panel as a private panel. To make a template panel private, select the Private option in the Template Options dialog and choose OK. If you distribute a template panel containing a module definition that attaches a private panel, note that you must provide the private template 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.
71
CHANGING
THE DEFAULT PANEL DISPLAY
The default display of the modules in the template panel may be changed for each template you create. You may set the default display to be Large Icons, Small Icons, or Text only. After attaching the template panel to the Project Bar, you may change this setting by right-clicking while hovering inside the Project Bar and then selecting the desired option from the shortcut menu that appears. By default, small and large icons display in two columns and text-only display in a single column. The display may be altered by dragging the splitter bar between the Project Bar and the model window to a different width. CHANGING
THE MODULE HELP OPTIONS
This option determines which help topic will be displayed when the user chooses the Help button and then clicks on the module in the template panel versus editing the module and clicking on the Help button in the module dialog. If Separate Help Items is selected, the two actions described above will display two different help topics. This may be desirable if you wish to give a brief description in one topic and more detailed information in the other. If, however, Common Help Item is selected, performing either action described above will display the same single help topic. EXPORT SORT
OPTION
The Export Sort dialog is used to define the order in which modules are written when a Module Data Export is performed. All modules in the template are contained in the two lists: unsorted modules and sorted modules. Initially, all modules are in the unsorted list. To create a sorted list of modules, highlight each module in the unsorted list that you wish to be sorted and click the Add button to move the module(s) to the sorted list. The Remove button moves the highlighted module(s) in the sorted list back to the unsorted list. In the sorted list, use the Up and Down buttons to move the highlighted module up or down. Refer to the online help topics on the Module Data Transfer feature for more information.
Defining required modules

The Add and Edit buttons in the template window activate a dialog that is used to define a new name for a module, as shown in Figure 4.8. It also indicates whether a module will
72
be required in any model that uses it. If this Required check box is selected, then the module is defined as required.
Figure 4.8 Module Definition dialog box
If a template panel contains a required module and if any module from the template is placed in a model, at least one instance of the required module must also be placed in the model. You might use this option to create a module definition that asks the user for run parameters or that contains special logic that entities may be sent to perform by other modules in the template.
Defining data modules

Another option in a modules Module Definition dialog (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 via drag and drop. Instead, they are added only to the spreadsheet by double-clicking the words in the spreadsheet Double-click here to add a new row. Another feature of data modules is that they may be created automatically by logic modules. For more information on the Auto-Created feature, see Auto-Creating modules on page 95.
Defining a name operand

Yet another option in a modules Module Definition dialog is the Name Operand field. If you choose an operand from a module to be designated as the modules Name Operand, Arena will enforce uniqueness for the value of that operand. For example, if a module called Process defines an operand called Process Name as its Name Operand, a user
73
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 design window. Also, it must be visible (generally, it is displayed in the spreadsheet) and is non-repeatable. Dialogs and Repeat groups may not be specified in this field.
Expression Builder Definitions

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

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

If you have existing model (.doe) files or template panel (.tpl) files that contain instances of modules from a template you are working on, you will be able to load the .doe/.tpl files even if you make changes to the dialog design or switch windows of module definitions. For example, if you have a template panel file, bank1.tpl, containing modules named 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
74

change the definition of either the Customers or Tellers module (by changing the dialog design, logic, switch, user view, or panel icon windows). Examples of changes you may make to existing modules include: adding new operands, removing obsolete operands, changing operand types from Element to Basic (or from any type to any other type), changing repeatable data into non-repeatable data (by removing the repeat group object), and many other. We make every attempt to use the data in 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 rightclicking on the panel tab and choosing Template Panel >Detach from the shortcut menu that appears. Then re-attach the .tpo file after you have completed your edits to the template panel file.
75
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 or viewing a modules fields in the module spreadsheet. The dialog design window is Arenas interface for designing the dialog structure and dialog form layout(s) of a module. In this window, a module designer defines dialog sizes, data displayed to and entered by the user, default and permissible values, and interface controls. The first part of this chapter gives an overview of the dialog design window interface. The second part of this chapter describes the user interface controls available to define dialog form, operand, and repeat group objects in the module definition and get user input and display output. The third and fourth parts of this chapter describe topics related to operand and repeat group objects in more detail. The fifth and sixth parts of this chapter describe the use of accelerator keys and the Dialog Design toolbar.
Dialog Design Window overview

The dialog design window is opened by selecting a module (in the template 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 form layouts for the module. Its interface includes an Operand Explorer section to browse all of the dialog form, operand, and repeat group objects in the module definition; a Toolbox section to add user interface controls to dialog forms; and a Design Properties grid to edit the properties of one or more selected objects.
5 Dialog Design Window
77
The Operand Explorer

The dialog design windows Operand Explorer (located in the top-right corner of the window) displays the hierarchical organization of the dialog form, operand, and repeat group objects that define the dialog structure of the module.
Figure 5.1 The Operand Explorer
The root node of the explorer tree is the modules main dialog form. This is the dialog that is first displayed when the modeler double-clicks on an instance of the module in a model or logic window. The dialog form, operand, and repeat group objects that define the structure of the modules interface are then displayed within the explorer tree according to the specified hierarchical relationships. The objects are displayed using the string format TabIndex: ObjectName [SwitchName]. The dialog or repeat group object highlighted in bold indicates which dialog form layout is currently open in the window. Within the explorer tree, you may select, delete, cut, copy, and paste objects. Objects may also be dragged and dropped graphically within the tree to change the hierarchical relationships. Double-clicking on an object in the tree will automatically open the dialog form associated with the object and then select the object. You may also click the View Dialog Form button ( ) to perform this action.
78
5 THE DIALOG DESIGN WINDOW
The functions of dialog form, operand, and repeat group objects are described further below. DIALOG FORM
OBJECTS
A module definition will contain one or more dialog forms to display choices and accept input from modelers into instances of the module. By default, every module has a main dialog form. This is the dialog that is first displayed when the modeler double-clicks on an instance of the module in a model or logic window. In some cases, there may be too much information to place in a single dialog. You may add a new secondary dialog form object to nest information by placing a DialogButton control from the Toolbox onto a dialog 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) is editable via 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 forms layout.
Hidden operands. Note that, in some cases, it may not be desirable for a particular operand to ever be made 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 may allow the capability to define 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, etc. The Assignments list box in the Assign module is known as a repeat group. You add repeat group objects to a module definition by placing a RepeatGroupDialog or RepeatGroupTable control from the Toolbox onto a dialog forms layout. Use the RepeatGroupDialog control if the repeating data is to be entered using a secondary dialog form. Use the RepeatGroupTable control if values for a single repeatable field are to be entered into a table.
79
The Toolbox
The dialog design windows Toolbox (located on the left side of the window) provides an interface for graphically adding user interface controls (e.g., text boxes, combo boxes, or dialog buttons) and static graphics (e.g., text, lines, or group boxes) to a dialog form layout.
Figure 5.2 The Toolbox
To add a control from the Toolbox, first click on the desired control in the Toolbox section. Then, hover the pointer over the location in the dialog form where the control is to be placed. The pointer will change to a cross hair with the selected controls icon displayed at the top and right of the cross hair. Controls are placed in the dialog form by one of three methods. Once your control has been selected, you can simply click on the form to place the control wherever you wish. Alternatively, you can click and drag to size the control as you place it (the control is placed when the button is released). The third placement method is to perform a simple drag-and-drop directly from the Toolbox to the dialog form.
80
Table 5.1 Summary of Toolbox controls Control Name Text GroupBox Line TextBox ComboBox RadioButtonGroup CheckBox Description Used to display a simple text string on a dialog form. Used to draw a box around and thus provide an identifiable grouping for other controls. Used to draw simple line segments on a dialog form. Used to get input from the user or to display text. Used to display and edit data in a drop-down combo box. Used to present a set of two or more mutually exclusive choices to the user. The choices are presented in a matrix of buttons. 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. Used to provide a button that the user clicks to display another dialog form. Used to allow a user to enter values for multiple (or repeatable) sets of fields via a secondary dialog. Used to allow a user to enter values for a single repeatable field into a table. Used to provide an interface through which to exchange date and time information with a user. Used to provide an interface through which to exchange date information with a user. Used to provide an interface through which to exchange time information with a user. Used to provide an interface for entering an operating system file name. Used to define an operand object that is hidden from the modeler (i.e., not displayed in the module dialog).
DialogButton RepeatGroupDialog RepeatGroupTable DateTimePicker DatePicker TimePicker FilePicker HiddenOperand
The dialog form

A dialog form is a rectangular bit of screen real estate that presents information to the user and accepts input from the user. The user interface of a dialog form is defined by placing controls from the dialog design windows Toolbox onto the forms surface. When the dialog design window for a module definition is opened, by default the main dialog form of the module is displayed in the center of the window. This is the dialog that
81
is first displayed if the modeler double-clicks on an instance of the module in a model window.
Figure 5.3 A Dialog Form in the dialog design window
OPENING
A DIALOG FORM
A module definitions dialog design may contain more than one dialog form. For example, in addition to the main dialog, the interface may include one or more secondary dialogs accessed via DialogButton and/or RepeatGroupDialog controls. To open the dialog form associated with or containing a particular object in the module definition, double-click on that object in the Operand Explorer. Or, alternatively, you may select an object in the Operand Explorer and use the View > Dialog Form menu item or click the View Dialog Form button ( ). Double-clicking on a DialogButton or RepeatGroupDialog control in a dialog form layout will also automatically open the dialog form associated with that control.
82
RESIZING
A DIALOG FORM
To resize a dialog form graphically, first click anywhere on the form to select it. Then, click and drag one of the sizing handles that appear on the border of the form. The sizing handles look like small black boxes, and the pointer turns into a double-headed arrow when you point at the handle. You may also enter specific dimension values for a dialog form by selecting the form and then editing the Height and Width properties in the Design Properties grid. ARRANGING
CONTROLS ON A DIALOG FORM
Controls that have been placed onto a dialog forms surface may be graphically selected, moved, and resized. Multiple controls may be easily layered, aligned, equally sized, or spaced using menu commands available from the Format menu. You may also use the View > Grid, View > Snap to Grid, and View > Snap to Objects menu commands to enable/disable grid and snapping features that help manage control locations on a form. LOCKING
CONTROLS ON A DIALOG FORM
When designing the user interface on a dialog form, you can lock the controls once they are positioned correctly so that you do not inadvertently move or resize them. Use the Format > Lock Controls menu item to lock a dialog 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 design windows Design Properties grid (located in the bottom right corner of the window) provides an interface for viewing and/or editing properties of the currently selected object(s).
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 form that is currently open in the window. The combo box may be used to change the object selection. The lower portion of the Design Properties section displays a textual description of the currently selected grid property.
Using the Toolbox controls

This section describes in more detail each of the user interface controls available in the dialog design windows Toolbox.
Using the Text control

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

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

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

A TextBox control adds an operand object to the module definition. The control may be used to get input from the user or to display text. A TextBox control has two portions: a prompt label and a box. You may graphically select, move, and resize the box and prompt label separately on the form using the mouse. In the Design Properties grid, the Text property defines the prompt label of the text box. The Value property specifies the default string value for the text box. The data type that may be entered as a value is specified by the DataType property. In general, a TextBox control is used for editable text, although you can make a text box read-only by setting the DisplayOnly property to True. Within the module definition, operand object values may be referenced (by enclosing the operand objects name in back quotes, e.g., Ò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 may be used to display and edit data in a drop-down combo box. The control displays an edit box with a down arrow at the right side of the box. Clicking on the arrow reveals a drop-down list from which the user may select an item.
85
A ComboBox control has two portions: a prompt label and a combo box. You may graphically select, move, and resize the prompt label and combo box separately on the dialog form using the mouse. In the Design Properties grid, the Text property defines the prompt label of the combo box. The default string value for the combo box is specified in the Value property. The data type that may be entered as a value is specified by the DataType property. The list of items displayed and available for selection in the combo 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. Within the module definition, operand object values may be referenced (by enclosing the operand objects name in back quotes, e.g., Ò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 RadioButtonGroup control

A RadioButtonGroup control adds an operand object to the module definition. The control may be used to present a set of two or more mutually exclusive choices to the user. The choices are presented in a matrix of buttons. Defining a radio button group tells the user Here is a set of choices from which you can select one and only one. In the Design Properties grid, the button options displayed for the RadioButtonGroup are defined by the OptionList property. The Text property defines the prompt label for the button group. The default option value for the RadioButtonGroup is specified in the Value property. Set the Boxed property to True if you would like a group box drawn around the prompt label and radio buttons. The column arrangement of the radio button options may also be customized using the NumberOfColumns and ColumnWidth properties. Within the module definition, operand object values may be referenced (by enclosing the operand objects name in back quotes, e.g., Ò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 CheckBox control

A CheckBox control adds an operand object to the module definition. The control may be used to indicate whether a particular condition is enabled. Use check boxes to give the user a choice between two values such as Yes/No, True/False, or On/Off.
86
In the Design Properties grid, the Text property defines the prompt label of the check box. The default value for the check box (Yes or No) is specified in the Value property. Within the module definition, operand object values may be referenced (by enclosing the operand objects name in back quotes, e.g., Ò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 DialogButton control

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

A RepeatGroupDialog control adds a repeat group object to the module definition. The control allows a user to enter values for multiple (or repeatable) sets of fields. Each set of the repeatable data is entered using a separate, secondary dialog form that is accessed by selecting the repeat 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 form associated with the RepeatGroupDialog control, double-click on the controls repeat group object in the Operand Explorer. Or, alternatively, you may select the object in the Operand Explorer and use the View > Dialog Form menu item or click the View Dialog Form button ( ).
Double-clicking on a RepeatGroupDialog control in a dialog form layout will also automatically open the dialog form associated with that control.
87
Using the RepeatGroupTable control

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

A DateTimePicker control adds an operand object to the module definition. The control provides a simple and intuitive interface through which to exchange date and time information with a user. A DateTimePicker control has two portions: a prompt label and an edit box. You may graphically select, move, and resize the prompt label and box separately on the dialog form using the mouse. The controls edit box has a down arrow to the right of the box (similar to a ComboBox control). A click on the arrow displays a calendar with the current date value circled. The modeler has the ability to change the date portion entered into the control by selecting either a different day within the current month or by using the calendar arrow keys to specify a different month. To edit the time portion of the control, simply click on the hour, minute, second, or AM/PM text in the edit box. Then type or use the arrow keys to change a value. In the Design Properties grid, The Text property defines the prompt label for the DateTimePicker control. The default date and time value for the control is specified in the
88
Value property. If the Value property is not specified, then the controls default value will be the current date/time. Within the module definition, operand object values may be referenced (by enclosing the operand objects name in back quotes, e.g., Ò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 DatePicker control

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

A TimePicker control adds an operand object to the module definition. The control provides a simple and intuitive interface through which to exchange time information with a user. A TimePicker control has two portions: a prompt label and an edit box. You may graphically select, move, and resize the prompt label and box separately on the dialog form using the mouse. 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 may be changed by highlighting the hour, minute, or second and using the up or down arrows to the right to increase or decrease the time.
89
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. Within the module definition, operand object values may be referenced (by enclosing the operand objects name in back quotes, e.g., Ò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 FilePicker control

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

A HiddenOperand control adds an operand object to the module definition. The control is used to define an operand object that is hidden from the modeler (i.e., not displayed in the module dialog). A hidden operand is normally used to store data that is necessary for the 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. Within the module definition, operand object values may be referenced (by enclosing the operand objects name in back quotes, e.g., Ò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 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 design. An operand is a single value that is important for module display or logic purposes. This section describes in more detail some operand-related properties and issues.
Specifying the Name property

All operand objects have a Name property available in the Design Properties grid. This property is a unique identifier string for the operand. The Text property that is displayed graphically in the dialog form automatically defaults to the Name of the operand. An operands name may be used (by enclosing the name in back quotes, e.g., Ò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.
91
Specifying the LogicProperties property

All operand objects have a LogicProperties property available in the Design Properties grid. This property provides a dialog for specifying characteristics of the operand related to its purpose in the modules interface and logic.
Figure 5.5 The Logic Properties dialog for an operand object
In the Logic Properties dialog, 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 simply stored with each module instance. Basic operands are often used to simply pass values to the logic window or the user view window or to control the display of other operands by being used in switch definitions. ELEMENT
OPERAND
An element operand defines or references a SIMAN element, such as a station or resource. If the Type is specified as Element, then the following fields are displayed in the Logic Properties dialog: Element TypeThe type of SIMAN element that the operand will define/reference. Select the desired type from the list. The operands value will then be used as the name of the element of the selected type (e.g., an operand with value Operator will define or reference a SIMAN element with name Operator).
92
Sub-listThe sub-list 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 sub-lists for Operators and Machines. Define/ReferenceIndicator whether the element that is created by this operand should be defined for the simulation model or whether it only should be referenced. If Referenced is selected, then some other module must define the element that is referenced by this module. This typically is used when incomplete property information is definable in a module. For more information on the use of elements and their properties, see the chapter Elements on page 177. PROPERTY
OPERAND
An operand may be used to represent the value of a SIMAN 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 Logic Properties dialog: 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 may not 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 simply 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 only be written to the elements property value if that property has yet to be defined (i.e., the current value of the property is null). For more information on the use of elements and their properties, see the chapter Elements on page 177. ENTRY POINT
OPERAND
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 may be connected to it graphically.
93
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; e.g., if a queue entry label is referencing this operand, then the Queue type should be selected. EXIT POINT
OPERAND
An exit point operand defines an exit for entity flow out of the module. When you define an exit point operand, a graphical exit point (triangle shape) is placed in the user view window for the operand so that it may be connected graphically to the entry point of another module. There may be multiple exit point operands in a module definition. For example, you may design a module that performs an inspection-type process, in which case, two exit points may be required, one for entities that pass inspection, and one for entities that do not pass inspection. Exit points also may be repeatable, as can be seen in the Decide module of the Basic Process panel. A repeatable exit point (i.e., the exit point operand is associated with a repeat group object in the module definition) has a different graphical representation in the user view than a single exit point, as can be seen in Figure 5.6.
Figure 5.6 Decide module with repeatable exit points
The specified Exit Type should match the exit type of the module field that references the operand from the logic window; e.g., if a queue exit label is referencing this operand, then the Queue type should be selected. ENTRY/EXIT POINT
VALIDATION AND REFERENCE
A graphical connection between an entry point operand and an exit point operand can be made only if the connection is valid. Connection validation is done based on the Entry Type and Exit Type of the operands. The most common entry and exit type used is Standard. Refer to the Tables appendix topic Entry/exit point types on page 267 for
94
more information on entry and exit types and connection validation. The Tables appendix also provides information on where various entry and exit types are used. When a graphical connection is made between modules, Arena automatically creates and stores unique entry and exit label information. An entry label value, usually an integer with a dollar sign (e.g., 123$), is created for the module to which the entity is to be sent. The module from which the entity is sent is given that same exit label value. Entry and exit point operands may have switches attached to them. If an entry or exit point has a switch and the operand is switched out, the operands field will not appear in the modules dialog and the graphical symbol will not appear in the modules user view. Entry and exit point operands may also be hidden operands (i.e., added to the module definition using HiddenOperand controls). In this case, a field corresponding to the operand is not visible to the modeler in the modules dialog; however, the graphical representation of the entry or exit point still appears, offering a way to connect graphically into and out of the module.
Note: If an entry or exit point is defined as hidden, there is no way to reference that operand if the module is used hierarchically. In some of the examples in this guide, we have made the entry and exit points hidden for the sake of the example and sample dialog box. These example modules then may not be used as the first or last modules in a logic window, as there is no way to reference the label or next label field.
AUTO-CREATING
MODULES
The Auto-Created Module feature allows a module designer to specify that a new, separate data module will be added automatically to the model using this operand. When used, the operands value is passed to the data modules Name Operand. Note that the auto-creation only takes place for non-blank values of the operand. For example, if a data module called Resource has a Name operand (specified in the Module Definition dialog) called Name, and another module called Process has a Resource Name operand that auto-creates the Resource data module, the value of the Process 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 Element-type operands. This ensures that the data module has at least two references in the model, as data modules with only one reference are normally purged (i.e., deleted) from the model (see below). Also, they should be set to use the Reference option, as opposed to the Define option, as the data module itself should be set to use the Define option. To use the Auto-Created feature, click the available Settings button for module autocreation in the Logic Properties dialog, then specify the Template Name and Module Name
95
of the module you wish to create from this operand value. You should avoid hard-coding path names in the Template Name field.
Note: You must specify the Template Name, even if the module to be auto-created is in the current template. Also, you should remember to change the Template Name and/or Module Name fields if you later rename either.
Purging auto-created data modules. Data modules that are auto-created by other modules are automatically deleted if the following conditions apply: 1) the module that caused the auto-creation is deleted, 2) the module that caused the auto-creation is edited to have a blank value for the operand that specified the auto-creation (or the operand is switched out), or 3) the auto-created module has only one reference in the model. This automatic deletion occurs only if the data module has not been manually edited by the user. If any modification has occurred, the module will remain.
Specifying the Value property

All operand objects have a Value property available in the Design Properties grid. This property specifies the initial, default value of the operand when an instance of the module is created. Default values may be literal, may reference other operands, or may be a combination of the two. The acceptable data type for an operands value that may be entered by a user is specified using the DataType property. The data type property is described in more detail beginning on page 99. It is not possible to have a blank value for an operand that has a default value specified in the dialog design. When editing a module, if a modeler blanks out an operand that has a default value, the default value will reappear when the user tabs out of this field. REFERENCING
THE VALUE OF ANOTHER OPERAND
The value stored in another operand object may be referenced by entering the 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 design as `Server Name`_RES, then any changes to the operand Server Name will be reflected in the Server Resource field. Thus, if the value of Server Name is specified as Fred, the value of Server Resource will be Fred_RES. If a referenced operand is switched out, then its value is null.
96
COMBINING
REPEATING OPERAND VALUES INTO A SINGLE VALUE
When designing a module, you may define a repeat group object that contains a set of repeatable operands and then have those repeating operand values combined into a single, merged value string. The single value will be returned if you enter the repeat group dialog or repeat group table object name in back quote characters (`) in the Value property of an operand. This topic is discussed in more detail in the Using repeat groups section on page 102. SPECIAL
REFERENCEABLE FUNCTIONS
A set of special functions is available that will provide, in an 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. Note that some of the functions available may be used to access information entered into the Project Parameters and Replication Parameters tabs of a models Run > Setup dialog. Typically, this might be done in a module designed to overwrite the standard simulation parameter defaults and reorganize the options for the end user. If a module that writes out different values for the Project and Replicate elements is placed in a model, those values will override any settings made in the Run > Setup dialog.
Table 5.2 Special functions Function ^Module_ID( )^ Description Returns a unique identifier string for the module in the form Module Definition Name [Instance Number]. For example, Create 5. Returns the module definition name of the module. For example, Create. Returns the instance number of the module in the model. For example, 5. Converts a time value of time units into a time value of base time units (as specified in Run > Setup > Replication Parameters). Converts a rate value of time units into a rate value of base time units (as specified in Run > Setup > Replication Parameters).
^Module_Name( )^ ^Module_Number( )^ ^TIME_TO_BASE_TIME(TimeValue, TimeUnits)^ ^RATE_TO_BASE_RATE(RateValue, TimeUnits)^
97
Table 5.2 Special functions Function ^Line_Number()^ ^Num_Lines(Repeat Group Name)^ ^Project_Title()^ Ânalyst_Name()^ Ûse_Costing()^ Description Returns the index into the repeating sets of data of the repeat group. Returns the number of repeating sets of data in a repeat group. Provides access to the title of the simulation project, as taken from the Project Parameters page. Provides access to the analyst name for the project, as taken from the Project Parameters page. 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. Provides access to the check box (Yes, No) for turning on and off entity attributes and statistics for the simulation model, as taken from the Project Parameters page. Provides access to the check box (Yes, No) for turning on and off resource statistics for the simulation model, as taken from the Project Parameters page. Provides access to the check box (Yes, No) for turning on and off tank statistics for the simulation model, as taken from the Project Parameters page. Provides access to the check box (Yes, No) for turning on and off queue statistics for the simulation model, as taken from the Project Parameters page. Provides access to the check box (Yes, No) for turning on and off transporter statistics for the simulation model, as taken from the Project Parameters page. Provides access to the check box (Yes, No) for turning on and off conveyor statistics for the simulation model, as taken from the Project Parameters page. Provides access to the check box (Yes, No) for turning on and off process statistics for the simulation model, as taken from the Project Parameters page. Provides access to the check box (Yes, No) for turning on and off station statistics for the simulation model, as taken from the Project Parameters page.
Ûse_Entities()^
Ûse_Resources()^
Ûse_Tanks()^
Ûse_Queues()^
Ûse_Transporters()^
Ûse_Conveyors()^
Ûse_Processes()^
Ûse_Stations()^
98
Table 5.2 Special functions Function Ûse_ActivityAreas()^ Description Provides access to the check box (Yes, No) for turning on and off activity area statistics for the simulation model, as taken from the Project Parameters page. Provides access to the number of replications for a project, as taken from the Replication Parameters page. Provides access to the length of the simulation run, as taken from the Replication Parameters page. Provides access to the check box (Yes, No) for initializing the system between simulation replications, as taken from the Replication Parameters page. Provides access to the check box (Yes, No) for initializing the statistics between simulation replications, as taken from the Replication Parameters page. Provides access to the start date and time of the simulation, as taken from the Replication Parameters page. Provides access to the length of time for the warm-up period, as taken from the Replication Parameters page. Provides access to the terminating condition that may end a simulation run, as taken from the Replication Parameters page. Provides access to the number of hours per simulated day, as taken from the Replication Parameters page. Provides access to the base time units used for the simulation clock TNOW and all time conversions, as taken from the Replication Parameters page.
^Number_of_Replications()^ ^Replication_Length()^ Înitialize_System()^
Înitialize_Statistics()^
^StartDateTime()^
^Warm_up_Period()^ ^Terminating_Condition()^
^Hours_Per_Day()^ ^Base_Time_Units()^
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, 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 appear and the pointer will move to the offending operand field.
99
Depending on the control type, an operands data type may or may not be changeable by the template designer. For example, the data type of a CheckBox control is strictly YesOrNo. Module designers should ensure that their operands do not define a less restrictive data type than the logic window fields that reference the operand. For example, if you have a module in the logic window that only accepts real values for a particular field, then the operand that is referenced in that field should be either a real data type or one that is more restrictive (e.g., integer). The available data types are now described. STANDARD
DATA TYPES
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 may contain both mathematical and logical expressions. IntegerAllows any valid non-negative integer value. Note that if a data type is specified as Integer or Real, you may specify minimum and maximum limits for the operand. LabelAllows any alphanumeric characters plus the special characters @, _, %, and #. Must contain at least one special character or letter. (Should not contain only numeric characters with single e or E, which could confuse it with a number written in scientific notation.) RealAllows any positive or negative real value. Note that if a data type is specified as Integer or Real, you may specify minimum and maximum limits for the operand. SymbolNameAllows any alphanumeric characters plus the special characters @, _, %, and #. Must contain at least one special character or letter. (Should not contain only numeric characters with single e or E, which could confuse it with a number written in scientific notation.)
Note: Symbol names may have an unlimited length, but only the first 255 characters of a symbol name are actually considered when evaluating an expression.
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.
100
For example, if you were building a module that defined a conveyor and wanted to define the conveyor as either accumulating or non-accumulating, you could use the data type ConvType since it is defined as having two values: Accumulating and Nonaccumulating. For more information on available SIMAN data types, see Data Types on page 257.
Specifying the SwitchName property

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

All operand objects have an InUserView property available in the Design Properties grid. This property allows an operand value to be displayed in the 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.
Hidden operands
In some cases, it may not be desirable for a particular operand to ever be made visible to the module user. The operand exists solely to store a piece of data for internal logic purposes and thus is always hidden from the user. The HiddenOperand control from the Toolbox may be used to add a hidden operand object to a module definition. Entry and exit point operands can be defined using the HiddenOperand control. In this case, there will not be a field to specify an entry or exit label in the modules dialog. 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.
101
Using repeat groups

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

All repeat group objects have a Name property available in the Design Properties grid. This property is a unique identifier string for the repeat group. The maximum length of a name is 31 characters, and it must be specified using alphanumeric characters. A repeat 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 105 and Combining repeating operand values into a single value on page 106.
Specifying the LogicProperties property

All repeat group objects have a LogicProperties property available in the Design Properties grid. This property provides a dialog for specifying characteristics of the repeat group related to its purpose in the modules interface and logic.
102
Figure 5.7 The Logic Properties dialog for a repeat group object
In the Logic Properties dialog, 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 simply as an interface for the modeler to access a set of repeatable operands. PROPERTY
REPEAT GROUP
A repeat group may also be used to write values to a SIMAN elements property. The property must be a repeatable property. For example, a repeat group may be used to write values to the Members property of a SETS element (as multiple members may be defined within a set), but not the Capacity or Schedule property of a RESOURCES element. If the Type is specified as Property, then the following fields are displayed in the Logic Properties dialog: Element OperandName of the operand that is defining the SIMAN element in this module of which this property repeat group is associated. Element TypeType of SIMAN element defined/referenced by the Element Operand. This field may not be edited; it is provided for information only. 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 177.
103
Repeat group definition depth and reference rules

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

As you are building a module, you may find that you will need to know more information about the repeat group entries that the end user entered. There are two special functions available for accessing this information. ^Num_Lines(Repeat Group Name)^ This function returns the number of tuples or entries that a modeler has inserted into the repeat group of name repeat group name. It may be used in the Value property of an operand object outside of the repeat group, or in a module field in the logic window. Note that Num_Lines cannot be used directly in a switch definition. However, it can be entered as the default Value property of an operand object. The operand can then be referenced in a switch definition. ^Line_Number()^ This function returns the index of the current tuple or entry in the repeat group. It may be used in the Value property of a repeating operand object that is contained directly within a repeat group in the modules dialog design.
105
An example of where the Line_Number function has been utilized 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.
Combining repeating operand values into a single value

When designing a module, you may define a repeat group object that contains a set of repeatable operands and then have those repeating operand values combined into a single, merged value string. The single value is returned if you enter the repeat group dialog or repeat group table object name in back quote characters (`) in the Value property of an operand object, in an animation object in the user view window, in a field of a module instance in the logic window, or in a switch definition string. For example, suppose a repeat group dialog object named Customer Arrivals has been added to a Customers module definition. Using the Repeat Group dialog, a modeler will specify the CustomerType and CumulativeProbabiltity.
106
Figure 5.10 Dialog design of Customers module
In the module logic in the logic window, suppose the template developer wants to have the string DISCRETE(0,0, CumulativeProb1, CustomerType1, CumulativeProb2, CustomerType2, ) written into the field of a module instance, where CumulativeProb1 is the first cumulative probability value specified in the repeat group, CustomerType1 is the first customer type specified in the repeat group, etc. In the module field in the logic window, the template developer enters the expression string: DISCRETE(0,0`Customer Arrivals`). To place separators (i.e., commas) between the probability and value pairs of operands and between entries of the repeat group, the template developer adds two hidden operands named PairSeparator and TupleSeparator. Both of these hidden operands have a , character entered into their Value property. The RepeatGroupIndex property then defines an index for an objects value with respect to other object values contained in the same repeat group and is specifically used for determining value order when combining a repeat 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 within the dialog design window. Refer to the Repeatable modules section on page 133 in The Logic Window chapter for more detailed information.
107
Using accelerator keys

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

While working in the dialog design window, you might find it useful to display and use the controls associated with the Dialog Design toolbar. The toolbar contains controls for formatting and viewing objects placed in the window. The controls are also available from the View, Format, and Object menus. To hide or display the Dialog Design toolbar, choose View > Toolbars > Dialog Design or right-click on any visible toolbar and choose Dialog Design from the list.
108
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 may undergo a simple activity, such as a time delay, or a series of complex activities, such as docking at a shipyard or completing a full surgery operation. The designer of a module has complete control over the scope of the module logic. It is this aspect of module design that is most challenging and often most interesting. For example, if your modeling activities are in the area of bulk food manufacturing, you might create a module that represents the arrival of raw materials from various sources to your manufacturing facility. To capture the pertinent aspects of this activity, you might need to represent the trucks that deliver the raw materials, the truck bays in the receiving area, the forklifts that unload pallets from the trucks, and the personnel who unwrap the palletized materials and transfer them to a storage area. One approach might be to build a Raw Material Receiving module that captures all of these activities, from trucks arriving at the facility to the storage of the raw material for use in manufacturing. Another approach might separate the receiving operation into three individual modules: Truck Arrivals, Truck Unloading, and Transfer to Storage. Or you might design modules for each step in the process, resulting in three individual modules representing the truck arrival process: Truck Entry, Bay Selection, and Docking. Note that the decomposition of this activity could naturally be represented using Arenas hierarchy. No matter what design you select for the modules, you will need to model each of the lowest-level activities (e.g., entry of trucks to the facility, selection of a truck bay, docking at the truck bay). You could first create modules to represent each of these activities, combine them into the middle-level activities (e.g., truck arrivals), and finally build the Raw Material Receiving module from the middle-level modules. By using this approach, a modeler using this template will have the option of using the high-level module (Raw Material Receiving) or of representing the receiving process using the medium- or lowest-level modules. The additional work involved in creating modules at the three levels of decomposition primarily relates to the selection of module operandsto build a Truck Entry module, you must decide which options will be changeable (e.g., time between truck arrivals, truck type) by users of the module.
6 Logic Window
The logic window

A modules logic window defines a submodel; i.e., the modeling logic and data that will be generated when an instance of the module is placed in the window. Just as the model window is used to define the logical representation of a model, the logic window defines the logical representation of a module. You can think of the logic window as a model
109
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 (i.e., in model windows that will be stored as Arena .doe files) or in module definitions (i.e., in logic windows of modules that will be stored in .tpl files). For simplicity, in most places we refer to the modelers placing instances of modules in simulation models. However, you should remember that instances may be placed in logic windows, as well. The remaining sections of this chapter discuss the use of logic windows to define the simulation logic associated with a module definition. We do not present a discussion of the general interface for building Arena models. We assume that you are familiar with the steps involved in building models using Arena template panels. The next section of this chapter highlights the major differences between model windows, which you use to build and run simulation models, and logic windows of module definitions. Following this, we present three sections that describe the main features of
110

6 Logic Window
6 THE LOGIC WINDOW
logic windows that are specifically related to defining modules: referencing module operands, connecting modules in the logic window, and switching module instances in the logic window. The next two sections of the chapter discuss topics of particular interest in designing module logic: defining module trace and using the modules from the Arena utility template (utlarena.tpo). We close this chapter by summarizing rules and presenting guidelines that relate to defining module logic.
Differences between logic and model windows Running simulation models (model window)
As we have described, the general process of defining a logic window is identical to that of building an Arena model. Because logic windows are similar to model windows (i.e., both contain instances of modules), most of the editing information for working in model windows also applies to creating and modifying logic windows. Please refer to the Arena Users Guide for information on attaching template panels, placing and editing modules, connecting modules, etc. One capability that model windows have that is not offered for logic windows is the ability to conduct a simulation run. If you open a 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.
Referencing operands (logic window)

Logic windows have a number of additional capabilities that are not provided by model windows. First, a module instance in a logic window may obtain values for its operands by referencing operands that are defined in the module definitions dialog design window. For example, a module that represents the unloading activity of a truck might include an operand defining the time to unload a pallet. This operand might be referenced by a Delay module instance (from 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 114 describes this topic.
111
Switching module instances (logic window)

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

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

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

While within the logic window of a module definition in a given template (i.e., .tpl file), you may not place any modules that are defined in the current template. For example, if you are working on a template panel file named foodline.tpl, you may not place any
112
6 THE LOGIC WINDOW
modules from foodline.tpo into the logic window of any other module defined in foodline.tpo. Related to this, you may not attach a template to itself indirectly by attaching a .tpo file that itself has the template you are editing attached to the Project Bar. For example, you might have a template named truckops.tpl representing the truck arrival operations described previously. If this template contained module instances from foodline.tpo in any of its module definition logic windows, it would not be permitted to use modules from truckops.tpo while defining modules in the foodline.tpl template. If you have a set of modules that form a hierarchy (such as the three levels of modules described previously related to the raw materials receiving operation), they must be grouped in separate template files since a particular template cant contain instances of modules that are defined in the same template.
6 Logic Window
Display of animation objects (logic window)

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

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

The logic window defines the logic that will take place (controlling the creation, flow, and disposal of entities) when a simulation run is performed by a model containing an instance of the module. This logic may be very simple or highly complex. When a module is placed, the number and types of options provided to a user are defined by the dialog(s) containing the modules operands. The tie between the dialog design window and the logic window is established inside the logic window. In each module instance in the logic window, the values of operands from dialog(s) of the module being designed may be used in place of specific values. To establish this link, you simply type the name of the operand that you want to use and enclose the name between back quote characters (`). We refer to this as referencing an operand.
Note: Operand names are not case-sensitive. Embedded spaces are permitted.
Operand references also are allowed in the Value property of an operand definition and to define certain data for animation objects. The Dialog Design Window and The User View Window chapters describe the locations in which operand references can take place for operand default values and animation objects, respectively. An operand reference dictates that when an instance of the module is created, the actual value of the field containing the reference is to be obtained from the modelers entry in the modules dialog. 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 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
114

6 Logic Window
6 THE LOGIC WINDOW
to the Create module so that the Interval field in the Create module would have a value of UNIF(5,10) and the Batch Size field would have a value of 10.
Note: If a module containing operand references is pasted into a model (.doe) window, the fields containing references are restored to their default values.
Figure 6.2 Operand references example
CONCATENATING
TEXT TO OPERAND REFERENCES
When referencing an operand, you also may type text before or after the reference. For example, you may have another module in your template called Order Verification, where a delay occurs to check orders. In this module, you might want to design the interface such that a modeler enters the percentage of incomplete orders (i.e., a value in the range 0 to 100) into an operand called Percent Incomplete. If this value is to be used in the condition of a Branch module (from the Blocks panel), which requires a probability value (i.e., in the range 0.0 to 1.0), you would need to divide the entry of the modeler by 100. To
115
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 may be referenced in the same field of a module instance in the logic window. In this case, the values of the operands are simply concatenated to form the complete value for the logic windows module instance. Also, text may be interspersed with operand references (as described previously). For example, in the original module, Order Entry, you might decide to use a uniform distribution for the interarrival time of orders and simply ask the modeler for the minimum time and the maximum time. In this case, the Time Between Orders operand
116

6 Logic Window
6 THE LOGIC WINDOW
would be removed from the module. In its place, you could define two operands for your module: Min and Max. To reference these operands, you would change the operand 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 such that only one operand will be switched in for any given set of user inputs. (Refer to the chapter The Dialog Design Window for a description of attaching switches to operands. See The Switch Window for a discussion of switches and their definitions.) To define the logic window field for this type of reference, simply type each operand name enclosed in back quotes, one after the other. In the Order Verification example module, perhaps you would like to design the module to offer the modeler a choice of specifying the time to check the order as either the name of an attribute that stores the time or as a particular time. This information will be used in a
117
Delay module (from the Blocks panel). The modules dialog might contain a selection for the Time to Check with options of Time or Attribute. If the modeler selects Time, an operand named Time is displayed; if the modeler selects Attribute, an Attribute is displayed. Figure 6.5 shows the dialog for an instance of the Order Verification module with the Time to Check selected to be Time. Figure 6.6 shows the same dialog with Attribute selected.
Figure 6.5 Order Verification module example, Time selection
Figure 6.6 Order Verification module example, Attribute selection
In Figure 6.5, the Time operand is displayed so that the modeler can define the time as a value (e.g., 2.5). The dialog in Figure 6.6 allows the modeler to define the time to check an order by selecting (from a drop-down list of attributes) an attribute that stores the value. In the logic window for the Order Verification module definition, the Process Time field of the Delay module would be defined as `Time`Àttribute` (with no intervening spaces). The switched-in operand would supply its value to the Delay module; the
118

6 Logic Window
6 THE LOGIC WINDOW
switched-out operand would have no value (i.e., blank). The dialog for the Delay module instance in the logic window is shown in Figure 6.7.
Figure 6.7 Combining operand references example
MULTIPLE
REFERENCES TO AN OPERAND
When you define a module, you can reference the same operand as many times as is appropriate. As we mentioned earlier, operand references may be made in three places in a module definition: in the Value property of an operand object in the dialog design window, in the logic window (as described in this chapter), and in animation objects in the modules user view. The same operand may be referenced from all three windows and/or from multiple objects within a window. For example, if a resource is required to perform the order verification process, an operand Clerk Name would be added to the module. This would provide the name of the resource in a Process module. (We will discuss adding the Clerk Name to the Process module in Referencing non-repeating operands from a repeat group on page 125.) If a count is collected in the Order Verification module to record the number of incomplete orders each clerk detects, the Clerk Name operand in the module might be referenced in many places. The default value of another module operand that defines the counter name might reference the Clerk Name to form the base of the counter name (e.g., `Clerk Name`_Cnt). The Process module instance in the logic window contains the reference to
119
Clerk Name to define the resource. And in the user view, a resource animation object could reference Clerk Name for the resource identifier.
Special access for check boxes, radio button groups, and combo boxes
While all references to module operands are made by enclosing the operand name in back quotes, a special mechanism is necessary for creating these references in the logic window when the field is displayed using a RadioButtonGroup or CheckBox control. (Refer to The Dialog Design Window or information about these control types.) CheckBox and RadioButtonGroup controls do not allow direct typing of values in a module instances dialog. Instead, a value is provided by selecting one of a predefined set of values. In the case of radio buttons, this is done by selecting a value; in the case of check boxes, the value is defined by checking the box for a value of Yes or clearing the box for a value of No. To reference operands in these fields, Arena provides a special operand reference dialog. To open this dialog when you are editing a module instance in the logic window, place the pointer over any of the values in a RadioButtonGroup control or over a CheckBox prompt and click the right mouse button. The dialog that is opened allows you to type the operand reference for the radio button group/check box using any of the mechanisms described in this chapter. Figure 6.8 shows an instance of a Dispose module from the Basic Process panel. The check box determines whether the entity statistics are generated. The dialog shown was opened by right-clicking on the Record Entity Statistics CheckBox control. A new module with an operand named Entity Statistics will provide the value of Yes or No to the Record module check box.
Figure 6.8 Operand reference for RadioButtonGroup and CheckBox controls
120

6 Logic Window
6 THE LOGIC WINDOW
Note: After you have established a reference for a radio button group or check box field, if you later click on one of the options of a radio button group or on the check box, the reference information is removed and the radio button group/check box is given the value you selected. Note: To allow template developers to reference an operand in a ComboBox control, the PickFromListOnly property for combo boxes is ignored in the logic window.
Switches in logic window module instances

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

In Arena, entities are transferred among modules in one of two ways: using a route, transport, or convey between stations (referred to as station transfer); or using a direct labeled connection (referred to as direct transfer). A module may offer one or both of
121
these mechanisms for receiving entities into the module; modules may define only one of the two mechanisms for any particular place that sends entities out of the module. STATION
TRANSFER
If you want to allow entities to be transferred into your module by a station transfer (i.e., route, transport, or convey to a named station), the 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.
Figure 6.10 Station module instance in Order Verification module
Any entities sent to an instance of the Order Verification module by station transfer would enter at the Station module instance (in the underlying logic) and then proceed to the Process module. To specify that entities should be transferred out of your module by a transfer module, simply place a module instance that permits station transfer (e.g., a Leave or Route module from the Advanced Transfer panel or Route from the Blocks panel) and reference the appropriate operands of your module. When a modeler uses an instance of your module, entities will proceed through the logic you have defined in the logic window.
122

6 Logic Window
6 THE LOGIC WINDOW
When an entity arrives at a module in the logic that has a station transfer, the entity will be sent to the module instance in the simulation model that defines the destination station. 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 (often with a prompt of Label for entry points or Next Label for exit points). In the logic window, you identify the module instance that corresponds to an entry point of your module by placing an operand reference in the appropriate field of the instance. For example, if you wanted to permit either direct transfer or station transfer into the Order Verification module, you could define a new entry point type of operand called Desk Label. In the logic window, this operand would be referenced by the Label field within the instance of the Station module (from Blocks panel), as shown in Figure 6.11.
Figure 6.11 Reference to entry point operand in logic window module instance
Note in the dialog in Figure 6.11 that both methods of transfer into the Order Verification are allowed: station transfer and direct transfer. A modeler using an instance of the Order Verification module has the choice of transferring entities by routing to the station defined
123
by the Order Desk operand and/or connecting other module exit points to the entry point defined by the Desk Label operand.
Note: We recommend that if you have entry and/or exit point operands in a module, you always display the operands in the module dialog (i.e., do not make them hidden). If you define the entry or exit point operand to be hidden, it is not possible for an instance of the module to reference entry point or exit point operands if it is used in the logic window of another modules definition.
If you utilize the Arena template in the logic window of a module (Basic Process, Advanced Process, and Advanced Transfer panels), the direct transfer method of entering into a module is more complicated. The reason for this is that the label/next label fields in all of these modules are hidden from the user (not available for operand values to reference), even though the entry/exit points are graphically visible. (Please refer to the chapter The Dialog Design Window on entry/exit points for more information.) In order for entities to actually enter the module using a label reference, a module with a label (from the Blocks panel) must be the first module into the model logic. Typically, the Delay module from Blocks can be used with a duration value of 0.0, as shown in Figure 6.12.
6.12 Module logic with delay: 0.0 module to access Desk Label entry point label
124
6 THE LOGIC WINDOW
Referencing non-repeating operands from a repeat group

6 Logic Window
The operand references that are made by module instances in a logic window may be made from within a repeating set of fields; this is treated identically to references from non-repeating fields. (Refer to the chapter The Dialog Design Window beginning on page 77 for a discussion of repeat groups and related topics.) We have briefly discussed adding a resource to the Order Verification module and utilizing the Process module from the Basic Process panel. The Clerk Name operand (non-repeating) will be utilized within a resource repeat group. This example will simply create one repeat group tuple with the value entered by the user for the name of the clerk resource. The resulting logic would have entities waiting to seize a single capacity unit of the resource defined by the operand Clerk Name (see Figure 6.13).
Figure 6.13 Operand reference from within repeat group
125
Non-repeating operands may be referenced from multiple tuples of a single repeat group, as well. For example, you might want to extend the Order Verification module to seize a supervisor when an entity is identified as an incomplete order and may also require a worker who is responsible for finding the missing items to come with the supervisor and pick up the incomplete order. In this case, you might want to ask the modeler for the names of the supervisor and worker by providing additional module operands, Supervisor and Worker Name. By referencing each of these operands in another Process module, your logic is such that entities require both the supervisor and worker resources before they can continue processing. This logic is defined by adding the operand references in a Process module to contain two repeat group tuples, the first tuple seizes the resource defined by the Supervisor operand, and the second tuple seizes the resource defined by the Worker Name operand. This Process module is shown in Figure 6.14.
Figure 6.14 Multiple repeat group tuples with operand references
126
6 THE LOGIC WINDOW
Referencing repeating operands

6 Logic Window
Thus far, we have discussed how to reference non-repeating operands from module instances in a logic window. It also is possible to reference repeating operands (i.e., operands that have been defined as members of a repeat group in the modules dialog design window) from logic window modules. To reference a repeating operand, you enclose the name of the operand in back quotes, just as is done when referencing nonrepeating 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 for the Order Entry module might be designed as shown in Figure 6.15. This dialog contains: an operand for the Time Between Orders, an operand for the Order Size, an Attribute Assignments repeat group (with a tuple opened in the figure to show its operands) containing an Order Attribute operand defining the attribute to be assigned and a Value operand specifying the assignment value, and a Next Activity operand that determines the activity to which the entity will be sent.
Figure 6.15 Order Entry module dialog
127
To define the logic for this module, the Create, Assign, and Route modules from the Blocks panel can be used. In the Create module instance, the Batch Size and Interval fields reference the Order Size and Time Between Orders operands, respectively, as seen originally in Figure 6.2. Similarly, the Destination field in the Route module references the Next Activity operand of the Order Entry module. These two references are of the type described previously, where a non-repeating field in a module instance contains a reference to a non-repeating module operand. So that modelers using the Order Entry module can define as many attribute assignments as they would like, the Assign module instance in the logic window must accept all of the values of the Order Attribute and Value operands that are defined in each instance of the Order Entry module. To establish this tie between the repeat group in the Assign module instance and the repeating operands in the Order Entry module, you insert a single repeat group tuple in the Assign module and reference the Arriving Orders module operands, as shown in Figure 6.16.
Figure 6.16 Reference from repeat group fields to repeating operands
128

6 Logic Window
6 THE LOGIC WINDOW
Each time a modeler inserts a new repeat group tuple in an instance of the Order Entry module, a corresponding tuple is inserted in the Assign module instance in the logic window. Similarly, as a modeler edits the data (e.g., deleting tuples or changing values), the edits are reflected in the Assign module instance. MULTIPLE
REFERENCES TO REPEATING OPERAND
An extension of this use of repeating operands is to use a single repeating operand in multiple references within a logic window. In this case, each reference will create a new tuple in the logic window corresponding to each tuple that the modeler defines. To illustrate this concept, 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. The new Order Verification module contains a repeat group with operands named Operator Name and New State. In the logic window, an instance of a Seize module is used to define the logic for seizing the required resources. The operand reference in the Seize module instance is shown in Figure 6.17.
Figure 6.17 Seize module instance with references
129
To assign new state values to the resources after they are seized, an Assign module instance is placed in the logic window. In the Assign module, since a pair of repeating operands is to be referenced, the same technique is used to create the operand references. A single tuple is inserted, and the two module operands (Operator Name and New State) are referenced, as shown in Figure 6.18.
Figure 6.18 Assign module instance with references
A modeler using an instance of this Order Verification module might insert one tuple with values Line A Refill Operator and Filling Incomplete Order for the resource and state operands; a second tuple might have operand values Line A Supervisor and Checking Order Problem. The resulting contents of the logic window would contain two repeat group tuples in the Seize module instance (since the Order Verification module has two tuples), with the names of the two resources filling the Resource fields. Similarly, because the Assign module in the logic window contains references to repeating operands, two assignment tuples would be created with the pairs of values for the resource and state to be assigned. One limitation is placed on references to repeating operands. If you are referencing a repeating operand from within a repeating field in a module instance, you cannot reference a repeating operand that belongs to a different repeat group. This rule applies both to the particular field containing the reference and to other fields in the same repeat group of the module instance.
130

6 Logic Window
6 THE LOGIC WINDOW
For example, in the Assign module instance shown in Figure 6.18, the operand references would be invalid if the Resource Name and New State operands belonged to different repeat groups in the module definition. COMBINING
REFERENCES TO REPEATING AND NON-REPEATING OPERANDS
It is possible to combine references in a repeat group such that some of the fields obtain their values from repeating operands and some reference non-repeating operands. In this case, the repeating operands define how many tuples are to be created in the logic window module instances repeat group, and the value of the non-repeating operand is included in each tuple. For example, if you want to modify the Order Verification module to seize an arbitrary number of resources, but you want to assign all of the resources the same new state value, you would use the same logic window as described previously (Seize and Assign with the same operand references). However, the Order Verification module would contain a repeat group with just the Operator Name operand. The New State operand would be nonrepeating (i.e., in the modules main dialog). A modeler using an instance of this Order Verification module might define that two resources are required (Line A Refill Operator and Line A Supervisor), and might provide a value of Checking Incomplete Order for the new state field. In the logic window, two repeat group tuples would be created in each of the Seize and Assign module instances (because both reference the repeating Operator Name operand). In the Assign module instance, the state value, Checking Incomplete Order, would be placed in both assignment tuples.
Defining repeatable exit points in a module

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

6 Logic Window
6 THE LOGIC WINDOW
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 is shown in Figure 6.21. Each time a modeler defines a new tuple in an instance of the Sort Orders module, a new tuple is created in the underlying Branch module and a new exit point is created both in the Sort Orders module instance and in the underlying Branch module.
Figure 6.21 Branch module referencing repeating operands including exit point operand
Repeatable modules
The repeatable module feature allows you to create a new set of logic for each entry or tuple in a repeat group. The interface and basic procedure is described as follows. In the logic window of a module, place a new box-shaped object (the module repeater) and associate it with a repeat group object in the dialog design window. Place any modules that you wish to be repeating inside the module repeater. Connect the module repeater to other logic as you would any other module.
133
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 non-repeatable logic external to the box, while the inside connection points are used to connect the repeatable modules inside the box to the module repeater itself. To use the module repeater, place the modules that you wish to be repeating inside the box. The box can be resized to allow for adequate space. Connect any modules you place inside the box just as you would if they were outside the box. Make sure that at least one of the group of modules inside the box is connected to a connection point inside the box.
Note: If you have trouble connecting modules either to or from the module repeater, go to the View > Snap menu and turn off the Snap option.
To associate the module repeater with a repeat group in the dialog design window, doubleclick on an edge of the module repeater to open the Module Repeater Settings dialog (shown in Figure 6.22.) Type the name of the associated repeat group or choose it from the list at the Repeat Group Name prompt. Next choose the type of repeating logic. There are two basic types: logic that repeats in parallel, or logic that repeats serially. Parallel repeating logic specifies that each repeat of the logic is independent and represents a different logical path. If you wish to define the repeating logic in parallel, you must connect a repeatable exit point of a module (such as Branch or Duplicate) to the entry point of the module repeater. Example 1 shows how to define parallel repeating logic. Serially repeating logic specifies that each repeat of the logic is connected, one after the other, in the same logical path. Example 2 shows how to define serially repeating logic. Finally, choose the Number of Alternate Outputs required. This option is used to provide additional logic paths out of the module repeater. For example, if a module inside the module repeater has more than one exit point, you may wish to connect one exit point to the main logical path that exits the module repeater and another exit point to an alternate exit point of the module repeater. Example 3 shows how you might use the Number of Alternate Outputs field. For the purpose of the next three examples, hidden entry and exit points have been used in the incoming and outgoing modules so that the module can be connected to other modules in a model window. Please refer to The Dialog Design Window chapter for more information on entry/exit points and hidden operands. It is typically not recommended that entry/exit points be hidden, as there is no way to reference them in a hierarchical module.
134
6 THE LOGIC WINDOW
Example 1: Parallel logic

6 Logic Window
Figure 6.22 shows the logic window with a module repeater connected to a repeatable exit point of a Branch module (Blocks panel).
Figure 6.22 Logic window with module repeater
The dialog design 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 design window with repeat group route times
135
Figure 6.24 shows the Sample dialog with entry of three different types and route times.
Figure 6.24 Sample dialog with types and route times
The resulting model code is shown in Figure 6.25. Note that the Assign module is repeated once for each tuple in the Route Times repeat group.
Figure 6.25 Model code
136
6 THE LOGIC WINDOW
Example 2: Serial logic

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

6 Logic Window
In Figure 6.30, the logic window shows module repeater with Duplicate block inside. Note that the Number of Alternate Outputs is 1 and an additional connection appears along the bottom of the module repeater.
The dialog 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 design window with repeat group Types and Quantities
139
Figure 6.32 shows the sample dialog with entry of two different Types and Quantities.
Figure 6.32 Sample dialog with entry of two different Types and Quantities
The resulting model code is shown in Figure 6.33. Note that the Duplicate block repeats once for each tuple in the repeat group.
140
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 (e.g., a module containing a RadioButtonGroup or CheckBox or a ComboBox control that has a value list), you may want to provide the same options to modelers using your module but with a different set of terms. To do this, you can define a set of hidden operands that contain the values required by the module in your logic window. Each of the hidden operands is switched in only when the value provided by the user of your module selects the matching customized option you provide. (For a description of switches and their definitions, see The Switch Window chapter.) For example, you might want to build a Raw Materials Receiving module representing a receiving area that can be used in systems that move material either by forklifts or by conveyors. The 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, you may want to define a radio button group (called Transfer Type) offering the options Use Forklift and Load on Conveyor. The RadioButtonGroup control in the dialog is used simply to obtain a selection from the modeler; it will not be referenced in the 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. Note that in this example, the Seize Resource and None options in the Leave module cannot occur since the Receiving module does not provide a way for a modeler to define either Seize Resource or None.
6 Logic Window
141
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 may draw a graphical connection between the exit point of one module and the entry point of another module (using the Module > Connect menu or the Connect toolbar button), or you may type the module label in the dialogs of the two modules (if using the Blocks panel). When working in a logic window, the graphical method of connecting modules is preferable, since Arena generates unique module labels for graphical connections. If you were to type a specific label for an entry point to a module in the logic window, you effectively would limit that module to only a single placement within any model (since module labels must be unique throughout an entire model). For example, if you are creating a printing operation module, you might place a Delay module from the Blocks panel in the 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 graphically 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 exactly 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 146 for a discussion of this technique.) To define multiple graphical connections leaving the same exit point, simply add each desired connection to the exit point. For example, Figure 6.34 shows a Batch module instance with two connections emanating from its exit point, one to a Record module and the other to an Assign module. Be sure that the multiple modules that are connected to a
142

6 Logic Window
6 THE LOGIC WINDOW
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 may create an operand reference for a repeating exit point (as described in Referencing module data on page 114), in which case the modeler using your module determines where entities are to be sent for each individual exit point. Or you might graphically connect a single repeating exit point to the entry point of another module in the logic window so that all entities sent from the module in the logic window go to the same next module. The logic window provides an additional option of connecting all of the points created by a repeating exit point to the same module. To define this type of connection, connect the repeating exit point (defined by inserting a tuple in a 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 for this module might ask the modeler to list all part types that require trim, the time to
143
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.
Figure 6.35 Corrugated Metal example dialog
The dialog 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 request the time to trim, name of the stamping machine, and time to stamp.
Figure 6.36 Operand Explorer in dialog design window of Corrugated Metal example
In the logic window, a Branch module from the Blocks panel can be used to determine whether entities should be sent to the trim process (represented by a simple Delay module). Each time the modeler creates a new tuple in the Trimmed Part Types repeat group, a new exit point will be created in the Branch module; all of these exit points will
144

6 Logic Window
6 THE LOGIC WINDOW
be connected automatically to the Delay module. To define this in the logic window, the first tuple inserted into the Branch 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 may have been initialized at an order entry module).
Figure 6.37 Branch module in Corrugated Metal example logic window
The connection point for the first Branch module tuple is connected to the Delay module so that all entities that have a value of the PartType attribute equal to one of the part types defined by the modeler will delay for the trim time; the Delay module is connected to the stamping process Process module. To complete this module definition, a second tuple is inserted in the Branch module with a Branch Type equal to Else. This exit point is connected directly to the Process module representing the stamping process. The complete logic window is shown in Figure 6.38.
145
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 150.
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.
Attaching and detaching switches

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

6 Logic Window
6 THE LOGIC WINDOW
or selecting it from the drop-down list). The module handle expands to include the name of the attached switch, enclosed in square brackets (e.g., [SwCount]). Figure 6.39 shows an example of attaching a switch to a Record module from the Basic Process panel.
Figure 6.39 Attaching a switch to a module instance
To remove a switch that is attached to a module, select the module and select the Detach option of the Object > Switch menu. If you want to attach the same switch to a number of modules or detach switches from multiple modules, select the desired set of modules (either by using SHIFT+Click to select a group of individual modules or by box-selecting all modules in a region of the window) and click on the Attach Switch toolbar button or select the appropriate option of the Switch menu.
Note: A module in the logic window may have only a single switch attached to it. If you have complex conditions involving multiple switches, define a new switch in the switch window with a definition representing the conditions and attach this switch to the logic window module.
Effect of switches in the logic window

As described earlier in this chapter, working in the logic window of a module definition is very similar to creating a simulation model in an Arena model window. You attach template panels to the Project Bar and select, place, edit, and connect module instances. If you want to define alternate logic paths to be included in or removed from the model based on values of module operands, you define switches in the switch window and attach these switches to module instances in the logic window. When a module is placed or edited in a model window, switches are evaluated to true or false based on the modules operand values. If the model is checked for completeness or a
147
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 design window for this module could define a selection operand, Collection Type, with options of Self Serve or Staffed Office. In the switch window, a SwSelf switch is added with a definition of `Collection Type`==Self Serve. A second switch, SwStaffed, has a definition `Collection Type`==Staffed. (Refer to the chapter The Switch Window for more information on defining module switches.) The logic window of the Package Collection module defines both possible paths of logic. In the case of self-serve collection points, perhaps you want customers to perform the logic: Station, Delay, Route. However, for staffed offices, a Process module might be used to represent the availability of package collection workers, so the customers will perform: Station, Process, Route. In both cases, the Station and Route modules might contain the same information, regardless of the collection point type. The SwSelf switch is attached to the Delay module so that it is included in the model logic only when SwSelf is True; similarly, SwStaffed is attached to the Process module. The complete logic window might be defined as shown in Figure 6.40.
Figure 6.40 Logic window with switched modules offering two alternatives
148

6 Logic Window
6 THE LOGIC WINDOW
Note that the Station module has two connections to its exit point. While this is invalid in a model window (i.e., each exit point in a model window must have exactly one connection), logic windows permit multiple connections because switches can effectively delete connections, depending on the values of the modules operands. It is incumbent on you as the module designer to ensure that the switches you have defined and attached to module instances in the logic window will permit exactly one connection to be active (i.e., not switched out) from each exit point in any possible use of your module. In modules with switches, it is very helpful to test carefully each alternative of model logic (based on the variety of possible values for module operands) to ensure that the logic window is correct. There are no restrictions on the complexity of modules that are to be switched in a logic window. The overnight package collection point example simply selects one of two alternatives, where each alternative includes only a single module. Any alternative might involve many modules with additional switches that provide additional options. The definition of modules such as the Leave module (Advanced Transfer panel) might involve dozens of switches controlling the display of operands in the module dialog and the module instances in the logic window. A slight extension of the package collection point example might be to ask the modeler whether customers arriving at self-serve collection points might balk (i.e., not send the package at that collection box) based on some condition. The logic to represent this new option appears in Figure 6.41.
Figure 6.41 Logic window for Package Collection module with customer balking option
149
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. (Refer to the chapter The Template Window for information about private templates.) Because it is a private template, it cannot be attached for use in model windows. The following sections describe the modules contained in this template panel and illustrate their use. HIDDEN
MODULE
One module in the utlarena.tpo template panel file, the Hidden module, is designed specifically to aid in defining logic windows that contain switches on module instances. This module does not generate any model logic or elements. (See the chapter Elements for information on elements.) It simply contains entry points and exit points to allow other modules to connect in and out of it. The hidden module is used for cases where one or more of the alternatives to be switched in/out in the logic window do not generate any model logic. In these cases, a connection must be formed to show the desired flow of logic (because you cannot attach a switch to a connection directly), but there is no module instance to which a switch can be attached to indicate when the alternate path should be taken. For example, 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.
150

6 Logic Window
6 THE LOGIC WINDOW
The desired logic for this additional option, shown in Figure 6.42, includes an instance of a Count module after the Delay only when the modeler indicates that the count is to be collected (i.e., SwCount is True). On the other hand, if no count is to be taken, the second connection from the Delay module should send entities directly to the Route module. However, if a connection were added directly from the Delay to the Route module, the resulting logic would have two valid connections if the modeler chose to count customers (i.e., the connection to the Count module and the one to the Route module). To prevent this, the hidden module is added between the Delay and the Route so that any use of this module can have only a single switched-in connection from the Delay modules exit point.
Figure 6.42 Logic window using hidden module instance Note: The Hidden_All_Types module provides the same functionality as the Hidden module with additional options for the various types of entry and exit points so you can connect it to any other module.
151
THE CONDITIONAL ASSIGNMENT
MODULE
The utlarena.tpo template contains another module, the Conditional Assignment module, which may be used only in logic windows. This module may be thought of as a combination of a Branch module (Blocks panel) and an Assign module (Basic Process panel), where each branch leaving the Conditional Assignment module may perform its own assignment. The module dialog for the Conditional Assignment module is shown in Figure 6.43.
Figure 6.43 Conditional Assignment module dialog
The Conditional Assignment module can be useful in cases where the system you are representing has an unknown number of conditions that dictate the values that should apply for a particular activity. For example, in the module representing the overnight package office, you might want to allow modelers to specify different conditions to be tested about self-serve customers and to define individual delay times based on the condition. To represent this in the logic window, you could use a Conditional Assignment module that references the condition operand and assigns an attribute (DelayType) to the delay time specified by the modeler for each condition. The Conditional Assignment module connects to the Delay module,
152

6 Logic Window
6 THE LOGIC WINDOW
which uses the DelayType attribute (rather than an operand of the module) to specify the delay time. This logic is shown in Figure 6.44.
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. (Refer to the Trace block in online help for a description of the module and its fields.)
153
For example, in the package office module described in the previous section, you could add trace messages indicating when entities leave the module. If the trace messages are to be different for each type of module (i.e., self-serve or staffed), individual Trace modules are added with the appropriate switches attached, as shown in Figure 6.45.
Figure 6.45 Module logic window with Trace modules
Logic definition rules and guidelines

The following rules summarize important points concerning the definition of a 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 graphically connected or should reference a module operand. (The entry point operand for modules that create entities and queue balk exit points are exceptions; they may be unconnected in a logic window.) If a module instance in the logic window has any required fields, you must supply values to them. If a required field contains a simple reference to an operand of your module, the referenced operand should be defined as required in your modules dialog design window. If the required fields value is defined using multiple operand references, you should ensure that under any valid combination of values entered by a modeler (for your module), the field in the module instance cannot be blank. If you reference an operand in a module instance, you should ensure that the data type of the operand that is referenced matches or is more restrictive than the data type of
154

6 Logic Window
6 THE LOGIC WINDOW
the field in the module. For example, you should not define an operand with an expression data type for a resource capacity field that accepts only integer values. If a particular entry or exit point is referenced more than once in the logic window, switches should be attached to those modules containing the references so that it is only possible for one of the modules to be switched in.
155
156
The User View Window

The user view of a module is the display that appears when a modeler places the module in a model window. The user view always contains a module handle. It also may contain module-related objects (such as entry/exit points or displayed operands) that are created based on information provided in the dialog design window. You may add draw and animation objects to the user view as well. To edit a module 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.
7 User View Window
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, grid spacing, etc., is also defined in the same world units used in model windows. (Refer to online help for additional information about model windows.)
Note: If you change the zoom level of the user view, remember to return to home view to ensure that objects you have placed in the user view are sized as you want them to appear in the default view in a model window.
Module instances
When a module instance is placed in a model or logic window, the objects that are in the module definitions user view window are copied into the destination (i.e., model/logic) window. The location where the modeler clicked to place the module is used to position
157
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 may be repositioned individually by the modeler. Also, the characteristics of draw and animation objects may be changed; these objects can be cut, copied, pasted, deleted, or duplicated as well. For example, a queue animation object that accompanies the Process module (from 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 design. Figure 7.2 shows the user view of an instance of the Process module from the Basic Process panel. It includes a handle (Process #), entry point, exit point. Note that when the module handle name, Process #, is changed, the handle of the module takes on that new name as well. (See The Module Text Options dialog box on page 159 for more information.)
Figure 7.2 User view of Process module instance
158
7 THE USER VIEW WINDOW
The module handle

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

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

Entry point and exit point objects in the user view are created automatically by Arena for each entry point and exit point operand defined in the dialog design window. The entry and exit point objects provide a graphical means of connecting the resulting module to other modules. Entry and exit points may be moved anywhere within the user view window. When you select an entry or exit point, the operand name for that point is shown below the graphical object (so you may distinguish the points from one another if you have more than one entry or exit point operand). The appearance of entry and exit points depends on the type of point. Figure 7.4 shows each entry and exit point type in a user view (including a repeatable exit point), with the point type labeled next to the graphical entry/exit point. The orientation of a non-repeatable exit point object may be rotated by double-clicking on the object. Entry and exit point objects may not be cut or copied to the clipboard, duplicated, deleted, or grouped with other objects.
Note: If the operand that defines the entry/exit point is deleted from the dialog design window, the corresponding object is removed from the user view window.
Figure 7.4 Entry and exit point types
You may not attach a switch to an entry or exit point object in the user view window. You may, however, attach a switch to the operand (in the dialog design window) that defines this object; the switch attached to the operand will control whether the graphical entry/exit point object is displayed in the modules user view.
160
Displayed operands
Operands that have been defined in the dialog design window with the InUserView property set to True will automatically create a text object (referred to as a displayed operand) in the user view window. (Refer to the chapter The Dialog Design Window for information about defining displayed operands.) In the user view window, the text object representing the displayed operand is shown as the name of the operand. After a modeler places the module in a model or template logic window, the text changes to show the value of the operand. You may locate the displayed operand anywhere within the user view window. You may not cut or copy displayed operand objects to the clipboard, delete them from the user view window, or group them with other objects. For example, Figure 7.5 shows a user view window for a Train Arrivals module containing two displayed operandsYard and Interarrival Time.
7 User View Window
Figure 7.5 User View window with two displayed operands
161
If a modeler placed this module and provided values of Conway and NORMAL(0.21,0.11) for the operands, the user view for the module instance would display the two operand values below the module handle, as shown in Figure 7.6.
Figure 7.6 Displayed operands in module instance
As is the case with entry and exit point operands, you cannot attach a switch to this type of object in the user view window. Instead, whether it appears in a model or logic window it is controlled by the switch (if any) attached to its associated operand in the dialog design window. Also, draw objects (discussed in the next section) may be grouped; however, they may not be grouped with the module handle. You may attach switches to draw objects in the user view. If a switch is attached, the object will appear only if the attached switch is evaluated to True. If you display a repeatable operand in the user view, the user view will simply show the operand name (as is the case for non-repeatable operands). When a modeler uses the module, Arena will place the values of the operands in a vertical list. If a third, repeatable operand, Characteristics, were added to the module in Figure 7.5 and a module instance
162

7 User View Window
were created with values Number of Cars, Schedule, and Number of Engines, the display of the instance would appear as shown in Figure 7.7.
Figure 7.7 Module instance with repeatable displayed operand
Because the length of an operand value typically is unknown (i.e., modelers might provide short or long values), displayed operands in the user view typically are placed vertically.
Draw objects
Draw objects (boxes, lines, circles, etc.) may be placed in the user view window via the Draw toolbar. These are added in the same way that you would add draw objects to a model window. Simply choose the desired object from the toolbar and place it in the window. The hidden and visible layers may be used to control whether or not objects defined in a modules user view will appear during a simulation run. (Refer to online help for more information about these layers.) Draw objects may be cut, copied, pasted, duplicated, and deleted. If objects are cut or copied to the clipboard, you may paste them into any window that supports draw objects. After placing a module in a model or template logic window, a modeler may change the characteristics of (or delete) draw objects that were provided by the module user view. Draw objects placed in the user view window may have attached switches (see User View switch use on page 166). If so, the object will appear only if the attached switch is evaluated to True.
163
Animation objects
Animation objects (e.g., queues, stations, levels) may be placed in the user view window via the Animate toolbar. These are added in the same way that you would add animation objects to a model window. Simply choose the desired object from the Animate toolbar, type the required information into the objects dialog, and place the object in the user view window. Animation objects may be cut, copied, pasted, duplicated, and deleted. If animation objects are cut or copied to the clipboard, you may paste them into any window that supports animation objects. When editing an animation object, you may specify that it is named by using the value of one or more module operands. To create this tie between the module dialog and an animation object, you create an operand reference by enclosing the operand name in back quotes (`) . For example, if you are defining a module in which a count is collected with operand Counter Name defining the name of the counter, you might place an animation variable in the user view to show the value of the count during the simulation run. The Expression entry in the variable dialog could be defined as NC(`Counter Name`), as shown in Figure 7.8.
Figure 7.8 Operand reference in animation variable dialog box
164
Operands may be referenced only in the entries within animation object dialogs listed in Table 7.1. Other animation object characteristics may be defined in the user view, but may not reference module operands. Also, if an animation object is part of a module instances user view, the entry listed in Table 7.1 is not changeable (i.e., is grayed out) by the modeler, with the exception of repeatable values (i.e., plot expressions, entity values, resource states, and global values). The operand references in the animation objects follow the guidelines described in Referencing module data on page 114 of The Logic Window chapter.
7 User View Window
References to repeating operands are not permitted in animation objects, including the cases where the animation object allows a repeating set of values (i.e., plot expressions, entity values, resource states, and global values). If an animation object containing operand references is copied from the user view window to the clipboard and is pasted into a model window, the entries containing references are changed to blank (since, after being pasted, the animation object is no longer part of a module). If the animation object had a switch attached to it, the switch is removed if the object is pasted into a model window. Animation objects placed in the user view window may have attached switches (see the next section). If so, the object will appear only if the attached switch is evaluated to True.
Table 7.1 Animation object characteristics that permit operand references Animation Object Queue Storage Parking Area Seize Area Station Intersection Route Segment Distance Network Variables Clocks Entry Permitting Reference Identifier Identifier <none> <none> Identifier Identifier <none> Identifier Identifier Identifier Expression, Format Time Units Per Hour, Hour, Minute, Second
165
Table 7.1 Animation object characteristics that permit operand references Animation Object Date Levels Entry Permitting Reference Time Units Per Day, Month, Day, Year, Hour, Minute, Second Expression, Minimum, Maximum, Expression (Accum.), Minimum (for Expression (Accum.)), Maximum (for Expression (Accum.)), # of Points, # of Distribution Points, Width Expression Any textual property value (i.e. you may enter a value into the field for specifying the property value) Value Identifier Identifier, State Expression, Value
Histograms Plots Entity Transporter Resource Global
User View switch use

Of the objects that may appear in the user view window, only animation and draw objects may have attached switches. A switch contains a conditional expression that is evaluated to True or False. If the switch condition is evaluated to be True, all animation or draw objects with the switch attached will appear in the model window. If False, these objects will not appear in the model window. For more information about switches and their uses, refer to The Switch Window chapter. To attach a switch to an animation object in the user view window, highlight the object and choose the Object > Switch > Attach menu option, or click the Attach Switch toolbar button (shown at left). Then type the name of the switch or select it from the dropdown list in the dialog that is displayed.
Note: Only a single switch may be attached to any object in a module definition.
For example, if the module illustrated in Figure 7.8 also contained a switch named SwCount, this switch could be attached to the variable in the user view window so that the animation variable only was displayed if a count is being collected (i.e., the value of SwCount is True). In this case, after the switch is attached, the variables name (as
166

7 User View Window
displayed in the user view window) changes to show the switch name enclosed in square brackets, as shown in Figure 7.9.
Figure 7.9 Animation variable with SwCount switch attached
To detach a switch from an object, highlight the desired object and choose the Object > Switch > Detach menu option. To attach a different switch to an object that already has a switch attached, simply attach the new switch using the procedure described above. The former switch will automatically be detached and the new switch attached. If multiple objects are selected (i.e., through a box selection or by using CTRL+Click to select individual objects), the attach and detach switch actions apply to all of the selected objects.
167
168
The Switch Window

A switch is a construct that allows a template designer to define variations of: the fields displayed in a module dialog, the model logic and elements that are generated when a simulation run is initiated, or the animation objects displayed in a 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 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 may be no reason to ask the modeler to define the processing time for deposits. In this case, a switch can be defined to turn off the deposit process time operand (i.e., remove it from the dialog) for any ATM that 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.
8 Switch Window
Defining switches
A switch simply consists of a name and a definition. The switch definition is a conditional expression that evaluates to True or False. It may contain operand names, operand values, and/or other switch names.
169
A switch can be attached to any of the following objects in a module definition: operand, repeat group, and dialog objects in the dialog design window using the SwitchName property; module instances in the logic window; and animation and draw objects in the user view window. A switch may be attached to numerous objects of the same or different types. For example, a switch named SwCount might be attached both to an operand in the dialog design window and to an animation variable in the user view window. When the switchs conditional expression is evaluated, these logic, operand, and/or animation objects will either become part of the model (if the switch is True) or will be ignored (if the switch is False). Switches are defined by opening the modules switch window and specifying the switch name and definition. A modules switch window is opened by clicking on 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, you will specify the switch name and the definition (i.e., the condition under which the switch is True) and click OK. Figure 8.1 shows the switch window with a single switch definition (SwDeposits). It is sometimes useful when duplicating, copying, pasting, or deleting switch definitions to perform the operation on multiple switches. You may select multiple switches by using SHIFT+click to select a range of switches or by using CTRL+click to add individual switches to the selection set.
Figure 8.1 Switch window
Switch names
A switch name may be specified as an unlimited number of alphanumeric characters. Whenever switches are referenced or are attached to module objects, the switch name is not treated as case-sensitive.
Note: Within a module, the operand, repeat group, dialog, and switch names must be unique.
170
8 THE SWITCH WINDOW
Switch definitions
Switch definitions are conditional expressions that rely on the values of other operands and/or switches. When referencing an operand, the operand name must be enclosed in back quotes (`); to compare the operand to a value, the value must be enclosed in double quotes (). For example, to define a switch that is true if the operand Accept Deposits (which might be displayed as a check box in the module dialog) has a value of Yes, the condition would be Àccept Deposits`==Yes (as shown in Figure 8.1). To use the value of another switch in a definition, simply type the name of the switch (i.e., no special characters are necessary to identify the switch name). Table 8.1 summarizes the valid references for operands, values, and switch names.
Table 8.1 Switch reference types Referenced Item Operand Value of operand Switch Enclose In Back quotes (` `) Double quotes ( ) Example Definition `ResName`==Machine
8 Switch Window
`State`< >Busy Switch1 && !Switch2
To define the conditional expression for a switch definition, you may use one or more standard logical or mathematical comparison operators, summarized in Table 8.2. The operators are listed in the order of evaluation of a switch condition.
Table 8.2 Switch definition logic operators Logical Operator == <> ! && Meaning is equal to is not equal to not and Use Compare op to value Compare op to value Take the opposite of a switch value Combine comparisons, requiring both to be true Example `Setup Required`==Yes Counter`< >None !SwSetupRequired SwCount && `Counter`==Individual
171
Table 8.2 Switch definition logic operators Logical Operator || > >= < <= Meaning or is greater than is greater than or equal to is less than Use Combine comparisons, requiring either to be true Compare op to value Compare op to value Compare op to value Example SwSetup || SwNewRecipe `Number`>14 `Weight`>=100.3 `Time`<10.5 `Tables`<=20
is less than or equal to Compare op to value
Comparisons of operands to values are performed by comparing the characters typed in for the operand value versus the characters specified in double quotes in the switch definition. These comparisons are not case-sensitive. Parentheses are not supported in switch definitions. For complex conditions, separate the condition such that grouped comparisons (i.e., those you would like to place in parentheses) are defined in individual switches, then use these switches to build the larger, complex condition. As described in The Template Window, you can view a list of the switches defined for all modules in a template panel file or for a single module using the Check > Report menu option. This report lists a table of switch names and definitions, so that you may view a summary of all switch definitions together (rather than needing to edit each switch individually). Switches are displayed in the switch window in alphabetical order.
Switch definition rules

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

8 Switch Window
8 THE SWITCH WINDOW
This applies to direct references (as in the operand Format in the above example) or to indirect references created via switches contained in a definition. For example, if the switch SwLooseleaf in the above example was defined using the condition `Prebound`==No, the SwBind switch could not be attached to the operand Prebound since Prebound is involved in the definition of SwBind indirectly through SwLooseleaf. If a switch references a repeatable operand, the switch will have a separate value for each tuple (i.e., each set of values for the repeating operands) of the modules repeat group. (Refer to 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 (Attributes, Variables, Pictures, etc.). The assignment repeat group contains a set of operands with switches that ensure that only the appropriate operand will be displayed, based on the selection of the assignment type. One switch is true when Attributes is selected, one is true when Variable is selected, etc. When the Assign module is used in a model, the first tuple might assign an attribute; the second, a picture; and the third, a variable. The 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, etc., are false. In the second tuple, the Pictures switch is true and the others are false. And in the third tuple, the Variables switch is true. Because the value of the switch changes depending on which set of repeating operands (i.e., tuple) you are examining, a switch that references a repeatable operand should be attached only to operands in the same repeat group. A switch may not reference an entire repeat group (i.e., switches only may reference operands). A switch may not refer to a specific tuple of the repeat group (e.g., the fifth assignment in a module).
173
174
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.
9 Panel Icon Window
Figure 9.1 Arena template Basic Process panel
The panel icons are defined in a panel icon window using drawing objects such as lines, boxes, circles, etc. To open a 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.
175
A panel icon window is shown in Figure 9.2.
Figure 9.2 Panel icon window
Creating the panel icon

There are three panel display options allowed for templates: Standard Buttons (the default), Large Buttons, and Text Only; this setting is defined in the Template Options dialog (refer to The Template Window chapter). All icons in a template panel file have the same size. To design your icon, we recommend that you select a very simple picture that represents the activity of the module and label it by placing the module name at the bottom of the icon. When you open the panel icon window, Arena automatically places the module name (first four letters only) as a text object at the bottom of the panel icon window. You may change the characteristics of this object as you would when editing any other text object (e.g., change the text string, the size and orientation, etc.) by double-clicking on the default text. You may use the Draw toolbar to create additional graphics for your icon by selecting the desired tools from the palette and placing objects in the window. Characteristics of objects (line width and style, border, and fill colors) can be specified either before or after placing the objects in the window. Draw objects also may be pasted from another window using the clipboard. You may also access the Arena Symbol Factory to cut and paste symbols into the panel icon window. This library of symbols may be accessed by going to Tools > Arena Symbol Factory. Simply select a category of symbols and click on the symbol you desire. This will place the symbol in the Preview box, where you can then copy it to the clipboard and paste it into your panel icon window.
176
10 Elements
In many cases, the modules that we build represent a component of a system that contains one or more objects. For example, we might build a workstation module that represents an in-buffer, a worker, a machine, and an out-buffer. These objects in the system have certain characteristics and behaviors that we must capture in our module. For example, the inbuffer 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, carts, etc. Although elements referenced in a module are frequently used to represent physical components of systems such as machines and workers, in some cases, the elements are used to represent information such as process plans, failure patterns, shift schedules, etc. These data elements provide a structured method for representing system information. Arena provides operations that access the data contained in these elements based on the element type. For example, an entity may undergo a route operation that references a sequence element, in which case, the sequence element specifies the destination station and the assignments to be made to entity attributes and model variables. The real power of the elements lies in the built-in functionality that is automatically provided by Arena/SIMAN for each element type. When you incorporate an element in your module, the element has a standard set of characteristics, called properties, that describe the element and a standard set of operations that can be applied to alter its state. For example, if you employ a resource element, it has a standard set of data properties that describe it (capacity/shift pattern, operating states, failure and repair characteristics, etc.) as well as standard operations that can alter its state (Seize, Release, Preempt, etc.). Likewise, a conveyor element has standard properties that specify its characteristics (path, speed, etc.) and standard operations that change its state (Stop, Start, Convey, etc.). Although there are a few key element types that are commonly used in building modules, 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
10 Elements
177
detail in the online help. Table 10.1 lists some of the properties and operations associated with six frequently used elements.
Table 10.1 Some elements and sample properties and operations Element Resource Properties Name Capacity/Schedule States (Busy, Idle, etc.) Failure Pattern Costing and Efficiency Name Path Segments Velocity Cell Size Status Type Name Number of Units Type Velocity Acceleration Deceleration Initial Unit Characteristics . (Position, Status, Size) Name Ranking Criterion Shared Indicator Name Associated Intersection Recipe Name Initial Value Operations Seize Release Preempt Alter Access Convey Exit Start Stop Allocate Request Move Transport Free Halt Activate Queue Insert Search Remove Convey Route Transport Station Assign
Conveyor
Transporter
Queue
Station
Variable
Arena provides a complete set of modules for manipulating the state of an element. The Arena template provides modules for referencing and using the most common element types such as stations, resources, conveyors, and transporters. The modules in the Basic Process panel provide access to these elements at the workstation or workstation
178
10 ELEMENTS
component level. For example, the Process module represents an operation in which multiple resources may be seized, held for a specified time, and then released. The Advanced Process panel provides lower-level operations from which complex operations can be built. For example, the Seize module in the Advanced Process panel allows you to seize units of one or more resources, and the Release module allows you to release one or more resources. By combining these modules with other modules, very complex resource logic can be represented. The modules in the Advanced Transfer panel provide access to the elements that are used to represent material transfer devices, such as conveyors, carts, AGVs, etc. In some cases, you may need access to additional operations (e.g., scanning a condition) that are not directly supported by the Arena template or you may need to use one or more elements that have no direct support in the Arena template. In this case, you can use modules from the SIMAN template to define and manipulate these elements. The elements in SIMAN are defined using the modules in the Elements panel; the operations for manipulating these elements are provided in the modules that are included in the Blocks panel. The modules in the Elements and Blocks panels provide complete access to all element types and operations supported by the SIMAN language.
Defining elements in modules Creating elements

When you define a module, you can specify that one or more elements, such as queues, resources, transporters, etc., be created when a modeler places an instance of your module. Your module also may present properties of its elements in the module dialog so a modeler can change the characteristics of the elements. And the module logic may specify operations that act on the modules elements such as seizing a resource or transporting to a destination station. In a module definition, you may create an element in two ways. First, in your 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 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
10 Elements
179
via element operands. Refer to The Dialog Design Window for a description of the LogicProperties property and operand types. The two approaches for defining elements, including their merits, will be discussed further in Defining elements via hierarchy on page 183 and Element operands on page 183.
Element lists
When a modeler creates an element (e.g., a resource), it is added to a list that is stored as part of the simulation model. These element lists are stored separately by element type. Module instances can display these lists so that, in many cases, a modeler simply can select an existing element from a list. For example, if you build a model containing Enter, Process, and Leave modules from the Arena template, you might define the station name in the Enter module to be Print Jobs. When you do so, a station element named Print Jobs is added to the simulation model and to the list of station elements. Within the Process module, you might specify that entities require processing with a resource named Joe, adding an element to the resources list. When you then edit the Leave module, if you require a resource for transferring out of the module using a station transfer, you will find the resource Joe and the station Print Jobs already on the resources and stations lists, respectively. The use of element lists in module definitions can make a template much easier for modelers to use by allowing them to select the elements they already have defined in their model, rather than needing to retype the name of the element. You can further tailor the lists presented to a modeler by using element sub-lists. This concept is described in Element operands on page 183.
Properties
Elements have characteristics that we refer to as properties. A particular element that has been created in a simulation model, such as a resource named Oven, has its own set of values for its properties. One resource element (e.g., Oven) may have a capacity of 12, while another resource element (e.g., Bake Prep) may have a capacity of 1. You may allow a modeler to define the property values for a particular element by using one of two mechanisms (in the module definition) that are similar to those available for creating elements. In the first case, you place a module instance (such as a Resource module from Elements panel) in the logic window of your module definition. In this module instance, you can specify that element properties are defined through references to your modules operands (e.g., a resource capacity operand). In this case, your module gives a value to the property through hierarchy.
180
10 ELEMENTS
The second mechanism for defining a property is to place an operand in the dialog design window of your module definition and, in the 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 (e.g., 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 187.
Use of elements and properties in module definitions

The concept of elements and properties is important regarding template design for two primary reasons. First, 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 may be collected into lists for presentation in module dialogs. We discuss these two concepts in the following sections.
Access to properties in a model

The use of element and property operands allows modelers to access information related to elements in more than one place in a simulation model. Although property information for a given element is global and could be accessed through multiple modules, it is recommended that property information for an element be defined within a single module, such as a data module, for a given element type. This typically eliminates confusion for the end user, so that properties of a resource, such as capacity, schedule, failures, etc., are defined and changed in only one location, not in multiple modules. The Auto-Created Module feature allows logic-type modules to define data modules automatically. (Refer to the operand 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 standard-type parts. Another set of logic in the same model for welding oversized parts might use a different Process module. Both of these modules would use the Welding resource for processing. A Resource data module (also from the Basic Process panel) is created automatically for the Welding resource, with default information for its properties, such as a capacity of 1. The Resource module can then be edited to specify the characteristics of the Welding resource (e.g., its schedule, failure patterns).
10 Elements
Although you may define a module that contains property information within the dialog, such as defining a Process type of module where the user can define capacity and schedule information within the Process module itself, you are limited by the terminology associated with SIMAN when specifying property information, as the operands are property-type operands and must feed directly into a SIMAN element field to be global.
181
For example, if asking a user in a dialog for the schedule rule for a resource schedule, you must specify the keywords Wait/Ignore/Preempt if the field is a property-type operand in a module that can be placed multiple times (such as a Process-type module). If an alias is used (refer to The Dialog Design Window for information on the use of aliases), the field can no longer be a property operand accessible from multiple modules.
Displaying element lists

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

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

As we described in the introduction, in the module definitions dialog design an operand can be identified as an Element type, which indicates that the value of the operand in an instance of the module will be used to name an element. In the dialog design window, all operand objects have a LogicProperties property available in the windows Design Properties grid. This property provides a dialog for specifying characteristics of the operand related to its purpose in the modules interface and logic.
10 Elements
183
In the Logic Properties dialog, the operands Type may be specified as Element.
Figure 10.1 Logic Properties dialog for an Element operand
When the Type is specified as Element, the following fields are displayed: Element TypeThe type of SIMAN element that the operand will define/reference. Select the desired type from the list. The operand's value will then be used as the name of the element of the selected type (e.g., an operand with value Operator will define or reference a SIMAN element with name Operator). Sub-listThe sub-list 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 sub-lists for Operators and Machines. Sub-lists are described in more detail in the next section. Define/ReferenceIndicator whether the element that is created by this operand should be defined for the simulation model or whether it only should be referenced. If Referenced is selected, then some other module must define the element that is referenced by this module. This typically is used when incomplete property information is definable in a module.
184
10 ELEMENTS
Sub-lists
Sub-lists allow partitioning into subsets the element lists that are presented to a modeler. There is a standard sub-list for each element type that is named the same as the element (e.g., RESOURCES). Elements that are created by instances of modules from the Arena and SIMAN templates are added to this sub-list.
Note: If the sub-list field is blank in the operand definition, any element that is created by an instance of the module will be added to the master list of elements, which presents a list of all elements of the particular element type (i.e., the combination of all elements defined as members of all sub-lists).
In Figure 10.1, the sub-list in the operands Logic Properties dialog is specified as Inserters. Thus, each time a value is entered into that operand in a module instance, a new element (i.e., a resource) will be created and added to the Inserters sub-list of resource elements. By using sub-lists in your template design, you can present the various elements represented in your template in as many different groups or classifications as you would like. Each classification (i.e., sub-list) simply is a name associated with a particular element list. For example, a template containing an Automatic Insertion module with the operand in Figure 10.1 might also have a module for soldering operations that defines solder resources. Sub-lists could be created that place the Automatic Insertion resource elements onto an Insertion sub-list and the soldering operation resource elements onto a Solder sublist. When a modeler wants to select an Automatic Insertion resource to perform an operation, the drop-down list presented in the dialog would present only those resource elements that have been defined to be inserters (i.e., have been placed on the Inserters sublist). The solder resources would not be displayed in the drop-down list of inserters.
Note: In any model, the sub-lists are shared across modules from different template panel files. For example, if a module from one template adds an element to the Inserters resource sub-list, another module from a different template also could add elements to the same sub-list.
In the dialog design window, note that if a ComboBox control is specified as a basic or property operand, then the List property of the control can also be specified to show an Element type and Sub-List. Those features work identically to the description of the entries in Figure 10.1.
Defining and referencing elements

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
10 Elements
185
the Define/Reference option in the operand objects LogicProperties property dialog (see Figure 10.1). If you select Define, the element is added to the simulation model (i.e., it will be written to the SIMAN experiment file), and its name is added to the appropriate element list (in the specified sub-list). If you indicate that the operand is only a reference to an element, the element name is added to the element list only. In this case, the element is not yet defined to be part of the simulation model; i.e., it will not be written to the SIMAN experiment file until another module instance containing a Define-type of element operand with the same value is placed. This type of element operand, a reference operand, is used when a module contains an operand that specifies an element, but the module does not contain the complete set of operands to define the required properties of the element. If an element is created in a simulation model only via reference element operands, an Undefined Identifier error will be given if the model is checked. The use of the Auto-Created Module Settings button within an operands LogicProperties property dialog allows more flexibility in defining and referencing an element. A data module, for example, may be created automatically using the AutoCreated Module feature when a particular element is referenced. (Please refer to 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 simply places the Leave module has not completely defined the transporter information. In this model, the Shuttle1 transporter element has an indicator that it is referenced only (i.e., not yet defined). To have a complete model, the modeler would need to edit the data module that defines the Shuttle1.Distance distance set. (Trying to run the model without doing so will give an Error window, specifying This module has not been edited, where you may click the Find button that will take you to the Distance data module.)
186
10 ELEMENTS
Property operands Defining Property operands

In the dialog design window of a module definition, in the LogicProperties property of an operand object, the operands Type may also be specified as Property.
Figure 10.2 Logic Properties dialog for Property operand
When the Type is specified as Property, then the following fields are displayed in the Logic Properties dialog: Element OperandName of the operand that is defining the SIMAN element in this module of which this property operand is associated. In Figure 10.2, an element operand named Inserter ID has been added to the dialog design. This operand is defining a RESOURCES element. We are now defining a property operand pointing to a property of that resource. Element TypeType of SIMAN element defined/referenced by the Element Operand. This field may not be edited; it is provided for information only. Property NameName of the element property to which this operand is pointing, selected from a list of valid properties associated with the Element Type. (Refer to the tables in Appendix B for a listing of the property types that are defined for each type of element.) In the example in Figure 10.2, we select the Integer or Sched ID property, which defines the (integer) capacity value for a fixed-capacity resource or the name of the schedule for a resource whose capacity type is Schedule.
10 Elements
187
Read OnlyThis option is only available if the operand is a HiddenOperand control in the dialog design. If enabled, the hidden operand will simply read into its value the current value of the element property with which it is associated. The 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 (i.e., the current value of the property is null). Note that the Read Only feature may be used to allow modules to communicate indirectly. For example, a master module may define an option to Collect Statistics, which would be written as a property of a named element. All other subordinate modules could have hidden operands referring to the named element and its property, but the hidden property operands in the subordinate modules would have the Read Only option checked. Other operands that collect various types of statistics in the subordinate modules may be switched in or out depending on the value of the hidden property operand. In this way, editing the master module would affect the other modules, giving you a type of Global Operand capability.
Defining repeating properties

Some elements contain properties whose values are repeatable, such as initial positions of the transporter units defined by a Transporters element or the list of failures for a Resource element. In the module definitions dialog design, a repeat group object (RepeatGroupDialog or RepeatGroupTable control) can be specified to be a property repeat group. When you define a property repeat group, you are indicating that a repeating set of values will be written by one or more property operands contained in the repeat group. (Refer to the chapter The Dialog Design Window for a more information on using repeat groups in the modules dialog 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 for a property repeat group object. In that example, the repeat group is pointing to the Failures property of a RESOURCES element (the resource is being defined by an Inserter ID element operand).
188
10 ELEMENTS
Figure 10.3 Logic Properties dialog for a Property repeat group
If the repeat groups Type is specified as Property, then the following fields are displayed in the Logic Properties dialog: 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 TypeType of SIMAN element defined/referenced by the Element Operand. This field may not be edited; it is provided for information only. Property NameName of the element property that this repeat group defines, selected from a list of valid repeatable properties associated with the Element Type.
Note: In the dialog design, when you define a repeat group to be a property, all operands and repeat groups that are contained within the repeat group must be property or element operands.
10 Elements
189
To further illustrate the use of property repeat groups, suppose we have designed an Automatic Insertion module with a dialog design as shown in Figure 10.4 below.
Figure 10.4 Operand Explorer view of dialog design for Automatic Insertion module
First, the Automatic Insertion module contains a repeat group object named Inserter Failures. This repeat group has been specified as a property repeat group, and it points to the Failures property of a resource element defined by the operand named Inserter ID (see Figure 10.3). In the Automatic Insertion module, we can now define one or more failures for the insertion resource. There are three property operands in the failures repeat group (see the Tables appendix for this list): the Failure keyword, the name of the failure, and the entity rule (Ignore, Wait, or Preempt). For the definition of the Automatic Insertion module, we have added two property operands to the Inserter Failures repeat group. First, a hidden Failure Keyword operand is used to provide the FAILURE keyword for a failure entry. The LogicProperties property dialog for this operand is shown in Figure 10.5.
190
10 ELEMENTS
Figure 10.5 Logic Properties dialog for hidden Failure Keyword operand
Second, for the name of the failure, we add an operand (Failure Class) to the repeat group and indicate that it is the Failure ID property of the resource, as shown in Figure 10.6.
10 Elements
Figure 10.6 Logic Properties dialog for Failure Class property operand
191
We can choose whether to add a third property operand to the module that specifies the failure entity rule. For this example, we will not do so, in which case the property of the resource is given the default value, Ignore.
Defining an element/property using a hidden operand

In the Automatic Insertion example, the Failure Class operand identifies the name of a failure that is a property of a resource. However, it does not create the failure element or define any of the properties of the failure (i.e., the type of failure, its duration, etc.). We can change the module so that it both defines the robot resource element and fully defines the associated failure elements. Figure 10.7 shows an updated dialog design for the module.
Figure 10.7 Operand Explorer view of dialog design for enhanced Automatic Insertion module
First, we will need to add an element operand that defines the failure element. We also will need to add the property operands for the failure element information. To define the failure element, we add a hidden operand to the Inserter Failures repeat group. This element operand defines an element of type Failures. We use an operand reference (`Failure Class`) to provide the default value of this element operand. This ensures that the failure element that is created is named correctly based on the failure property of the resource.
192
10 ELEMENTS
Figure 10.8 shows the design properties of the hidden operand named Failure_Element.
Figure 10.8 Design properties of hidden element operand to define Failures element
By presenting the property operand in the module dialog, we ensure that if another module instance changes the failures associated with an automatic insertion resource, the Automatic Insertion module instance will be updated to reflect the changed values. (This is because property values are stored globally in the simulation model, as described previously.) The hidden Failure_Element operand ensures that the failure element also is defined in the simulation model and provides an element operand that the failure properties can reference. In this example, we will be defining the failure information for the specified failure within the Automatic Insertion module. In this case, we use the Define (instead of Reference) for the element Failure (as seen above in Figure 10.8). If the Automatic Insertion module simply specified the failure name and a separate Failures data module defined the
10 Elements
193
characteristics of the failure, this module would still contain the above hidden operand (so the failure name is on the list of Failures); however, the element would simply have a reference to it, instead of defining it. To define the failure properties, three additional property operands are added to the Inserter Failures repeat group, corresponding to the three required properties of a failure element: Failure Type, Time or Count Between, and Duration. Figure 10.9 shows the operand dialog for the first of these, the Failure Type. In its definition, it is specified to be a property type of operand; it is a property of the element named by operand Failure_Element; and it is the Type property of the failure element. The remaining two operands (Count or Time Between and Time to Repair) are defined similarly, with the appropriate selection of the property type (Time or Count Between and Duration, respectively).
Figure 10.9 Logic Properties dialog of Failure type property operand
194
10 ELEMENTS
In Figure 10.10 we show a sample instance of the Automatic Insertion module. This instance defines an insertion resource named DIP_Line A following the Two Shifts schedule. The resource has two associated failures: Out of Tolerance (whose repeat group dialog is opened in the figure) and Preventive Maintenance.
Figure 10.10 Automatic Insertion example module instance
Switches and elements

Switches may be attached to element operands in the dialog design by specifying the SwitchName property in the objects design properties. Or, you may select the object and use the Object > Switch > Attach menu item to attach a switch and select the switch from the list that is presented in the Attach Switch dialog. (Refer to the chapter The Dialog Design Window for more information.) When a module that includes element operands with switches is used in a simulation model, the behavior of switches as they relate to the appearance of the module dialog also is the same as occurs for basic operands. If the 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 element in the simulation model. Because more than one module instance in a model may have an element operand that accesses the same element, there is the potential that the same
10 Elements
195
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 (i.e., either has no attached switch or a true switch). The same rule applies to properties of an element.
Note: If an element operand has an attached switch in a module definition, all property operands that define properties of that element also should be switched to ensure that there is no condition under which the element could be switched out and one or more properties switched in.
For example, the Record module contains an operand, Counter Name, that is an element operand defining a Counters element. This operand is switched in or out in a module instance based on the selection for the type (Counter, Entity Statistics, Time Interval, Between, or Expression). If one Record module instance has a type of Count and names the counter Items Completed, the Items Completed counter is created. Another Record module instance might be placed in the model that also counts in the Items Completed counter. If the first Record module was edited and the type changed to Entity Statistics, the Items Completed operand is switched out in that module instance. However, because the Items Completed counter still is switched in (i.e., in the second Record module instance), it still exists in the simulation model. If the second Record module is deleted (or its type changed to something other than Count), the Items Completed counter is removed from the element list since no module has a switched in reference to it.
Special element types

The types of model elements that may be referenced in a template include each of the types of elements defined in the SIMAN experiment. (Refer to online help for complete documentation on the SIMAN experiment and the Elements panel.) We provide three additional classifications of elements in Arena to address special circumstances you may face in designing templates. These element classifications are described in the following sections. Refer to the Tables appendix for a complete list of these additional element types and their properties.
Fixed-length elements
Many of the element types in Arena have one or more properties that may have a repeating set of values, such as the initial values for a variable or the failures associated with a resource (as illustrated earlier in this chapter). Templates can be designed to provide values to these repeating properties by placing a property repeat group and the appropriate property operands in a module definition. In some cases, you might want to design a module that places a value at a specific index in the repeating operand. For example, you might establish that the first value in a recipe is the resource name to be used at a given job step, the second value is the processing time,
196
10 ELEMENTS
and the third value is the yield for a given job type. If you wanted to display this information as non-repeating operands in a dialog, you would not be able to use property operands (because the recipe element specifies that the values are in a repeat group). We have added element types that mirror each of the elements containing repeating values. These additional element types are referred to as fixed-length elements. These fixed-length elements contain a predefined set of values for the repeating property; they are named using the prefix Fixed_. For example, the Fixed_REC50 element has 50 assignment properties followed by a repeating assignment property; the standard RECIPES element contains only the repeat group for assignments. Additional fixed-length elements contain a predefined number of repeating properties within the repeat group. These elements are named using the prefix Fixed_ and a suffix R. These elements allow you to define a one- or two-dimensional array where each row in the array is an individual tuple. For example, the Fixed_VAR10R element has 10 predefined initial value properties per repeat group. You utilize the fixed-length elements exactly as you use the standard elements, by defining element operands to create elements and property operands to define the values of the elements properties. Fixed-length elements are generated along with standard elements at model generation.
Note: The element lists and sub-lists are separate from one another, even for related element types (e.g., Fixed_REC50 and RECIPES elements).
Hidden element list

You may find a circumstance where you want to provide a modeler with a drop-down list of values, but you do not want these values to be written to the SIMAN experiment file. We have added an element type, referred to as the hidden element, that allows you to define an element list but that will not be used to generate the simulation model. The hidden element functions like a standard element but doesnt directly write its values to the SIMAN experiment file. In the LogicProperties property dialog, an operand that is type element can be defined as a hidden element type by selecting Hidden from the list of available element types. This option appears at the end of the list of element types. There are no properties associated with the hidden element type. An example of using a hidden list is as follows. In the Arena template modules (Basic Process, Advanced Process, and Advanced Transfer), each module you place is given a name, based on the module type. For example, if you place the Create, Process, then Dispose module, they are named automatically Create 1, Process 1, and Dispose 1. You may edit those modules and change the module name, which changes the module handle you see in the user view. Each of the name fields has a drop-down list, which is a list of all module names in the model. These are not written to any SIMAN element, as they are
10 Elements
197
simply 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 design properties of the Name operand in the Create module
The hidden element can also be used with repeat group properties. As previously discussed, all operands contained in a repeat group property must be defined as an element or property operand. The hidden element can be used when you have an operand that doesnt define an element or a property but is contained within a repeat group property.
Inverted elements
Inverted elements are used when you want to design a module that allows the modeler to create a single repeat group tuple for each instance of a module. For example, you may want an individual module to define a member of a set of resources without having to define all of the members of the resource set in a single module. There are five available
198
10 ELEMENTS
inverted elements: Inv_DISTANCES for creating a distances element, Inv_LINKS for creating a networks element, Inv_SEGMENTS for creating a segments element, Inv_SETS for creating a sets element, and Inv_Statesets for creating a set of states for resources. The difference between an inverted element and a standard element relates to how the elements and properties are defined. For example, the standard Segments element defines a segment name. Its properties are beginning station, next station, and length. The Inv_SETS element defines an element whose default value is used internally. This 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.
Figure 10.12 Dialog box for Animated Segment module
10 Elements
199
Figure 10.13 shows the Operand Explorer view of the modules dialog design.
Figure 10.13 Operand Explorer view of dialog design of Animated Segment module
This modules dialog design consists of four hidden operands (Name, BegN, EndN, and SetN) and four visible operands (Beg, End, Set, and Length). The Name operand is defined as the inverted element Inv_SEGMENTS and its properties are BegN (property name Beginning Station), EndN (property name Next Station), SetN (property name Segment Set ID), and Length (property name Length).
200
10 ELEMENTS
The Name 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. The Set operand is a visible element-type operand that defines a standard Segments element.
10 Elements
201
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 materialhandling inverted elements (Inv_LINKS and Inv_DISTANCES) are used in the same fashion. The Inv_SETS element and Inv_Statesets elements are slightly different. The Inv_SETS and Inv_STATESETS elements are the opposite of the standard sets and statesets elements. The standard sets and statesets elements defines a set name, and its properties
202

10 Elements
10 ELEMENTS
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.
203
204
Template Design Guidelines

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

Plan ahead. Try to create a picture of the dialog boxes for the modules in your template panel and lay out the information in some consistent format. Use Line and GroupBox controls to group related information within a dialog. Use secondary dialog boxes instead of a single large dialog. Secondary dialogs generally should not contain required operands unless they are switched On by the user. Within a template panel, use consistent designs in the 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/combo operand. If the options of a RadioButtonGroup control have a clear meaning, a prompt label is optional. However, if there is any possibility of ambiguity or misunderstanding, provide a prompt label. Prompts should be clear and contain a minimum of SIMAN jargon. If an operand is referenced by a required field of a module in the logic window, it should also be required in the modules dialog design.
205
The data type of an operand should be the same as or more restrictive than the data type of any field that references it (in a module instance in the logic window). Use switches to enable/disable controls so non-applicable fields will not be displayed. Try not to place ComboBox controls near the bottom of a tall dialog. Arena drops the list down and displays it above the box if the box would be displayed off the screen. While this allows a modeler to see the entire list you have defined, it is not as convenient as a box that drops down below the edit box. RadioButtonGroup control vs. ComboBox control Use a radio button group if there is ample room in the dialog or if the choice is very important. Use a combo box if the field is not changed often or if room is limited. CheckBox control vs. RadioButtonGroup control Use check box only if the meaning of the choice (Checked/Unchecked) is very clear. Use radio button group if you want to limit the user to the defined entries only.
Helpful hints for defining objects in the dialog design window

Use meaningful operand names. These will be used for default prompts and for column headings with Module Data Import/Export.
General
Module entry and exit points should not be hidden so that the module can be used in the definition of another module (i.e., a Label/Next Label operand should appear in the module dialog box so that a reference may be entered when the module is placed in another module definitions logic window). Utilize the Auto-Created Module functionality to create data modules from logic modules automatically.
Panel icon
Retain the text label of the icon and use the same font type and size for all modules. Be consistent within a template with use of color and style. Keep the icon simple. Use similar design types for panel icons; avoid mixing 2-D and 3-D panel icons.
206

A TEMPLATE DESIGN GUIDELINES
If the module has a resource in the user view, try to represent the module in the panel 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 data modules 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 may still be edited, the individual identifiers do not appear when you select a grouped object. All animation objects should reference operands of the module in the expression/identifier entry (since this value is not changeable by the modeler in a module instance). Attach switches to animation objects that correspond to other module items that might be switched out.
Module logic
Use Draw objects and Named Views in the logic window to identify various parts of the module logic. Verify module logic first in a model window so that you can interact with the model and view a detailed animation. Then use Arenas clipboard to transfer the logic into a module definitions logic window and add the appropriate operand references and/or switches. Base your modules on SIMAN Blocks and Elements. This allows you to then define elements either through the logic window or the dialog design window.
207
Naming conventions
When a module contains a station designation, the station name should be supplied by the user. Other operands may be given default names based on the station name with a suffix. Using the following suffixes will provide improved consistency and help prevent multiple use of the same name: `Station Name`_R - Resources `Station Name`_Q - Queues `Station Name`_S - Storages `Station Name`_C - Counters `Station Name`_Ta - Tallies Supply a standard prefix to your template panel files if you create and share multiple files. If you build modules that have similar names to modules in other templates, use a prefix in the modules main dialog title (e.g., AGV_Transport) to distinguish it from the other modules that perform a similar activity.
Template documentation
We encourage you to provide documentation of templates for your own use or for others; it is particularly useful to provide helpful information that may be accessed from within the software. This can be done in several ways. Use static text (Text control) to provide a brief description in a dialog. Provide a text file (e.g., tplname.txt) that describes each module in your template panel. With the assistance of a help authoring tool, create and connect true online help to your template. This is explained in detail in Appendix C.
Trace
Although low-level trace is automatically available on all SIMAN blocks, this is often not useful to a less experienced modeler. The TRACE block can be used in a module definition to provide supplemental, module-specific trace. Some guidelines regarding the design of trace information for your modules follow. Because the entity number and module identifier are automatically generated during the simulation run (providing a header for each new trace message), this information need not be included in a module trace.
208

A TEMPLATE DESIGN GUIDELINES
To distinguish the messages you generate from module headers and low-level trace, we recommend that each message start with a hyphen in column 1 (e.g., -Waiting for teller\n). Since it is not always possible to evaluate every expression accurately, it is most consistent to write the expression itself (within the format) instead of writing it as an argument. Use the STR keyword to write symbol names instead of numbers (e.g., a resource name).
Statistics and reports

Although the animation is the most visible part of model building, it is often the statistics upon which most decisions are made. Provide optional statistics on most items in which a modeler is likely to have an interest. To avoid complexity and confusion, set the default statistics to be collected only on key items. The most basic (and default) level of statistics should appear in the standard summary report. The Reports Element can be used to categorize statistics by module or other logical grouping. The Reportlines Element can be used to generate a professional, completely customized report by module or other logical grouping. Use the STR keyword to write symbol names instead of numbers (like a resource).
209
210
Tables
Elements and properties Standard elements
Listed below are the standard (SIMAN) elements and properties that are available for module building. For more information on a particular element, refer to online help.
Note: Those properties that are repeat group properties are denoted with an (R). Their included operands are indented following the repeat group name. B Tables
ACTIVITYAREAS Element
Properties Organization Level Parent Activity Area Auto Stats Generate Auto States Category Auto States Identifier
ARRIVALS Element
Properties Type Type ID Time Interval or Key Offset Max Batches Max Time Batch Size Assignments (R) . Variable ID . Value
211
ATTRIBUTES Element
Properties Number 1-D Array Index 2-D Array Index Data Type Initial Values (R) . Value
BEGIN Element
Properties Listing Run Controller
BLOCKAGES Element
Properties Number Initial Blockages Global Priority Priority Expression
CONTINUOUS Element
Properties Number of Dif Eq Number of State Eq Minimum Step Size Maximum Step Size Save Point Interval Method Absolute Error Relative Error Severity
212
B TABLES
CONTINUOUS Element
Properties Cross Severity
B Tables
213
CONVEYORS Element
Properties Number Segment Set ID Velocity Cell Length Status Max Cells per Entity Type Accumulation Length Auto Stats Generate Auto Stats Category Auto Stats Identifier
COUNTERS Element
Properties Number Limit Initial Option Output File Report ID Data Type Category Process ID
214
B TABLES
CSTATS Element
Properties Number Name Output File Report ID Data Type Category Process ID
B Tables
DISCRETE Element
Properties Max Number of Entities Number of Attributes Largest Queue Number Largest Station Number Animation Attribute
DISTANCES Element
Properties Station (R) . Beginning Station ID . Ending Station ID . Distance
DISTRIBUTIONS Element
Properties Dist Number Dist Index1 Dist Index2 Dist Values (R) . Values
215
DSTATS Element
Properties Number Name Output File Report ID Data Type Category Process ID
ENTITIES Element
Properties Number Initial Picture Intial Holding Cost Rate Initial VA Cost Initial NVA Cost Initial Wait Cost Initial Tran Cost Initial Other Costs Auto Stats Generate Auto Stats Category Auto Stats Identifier
EVENTS Element
Properties Crossing Variable Crossing Direction Threshold Value Crossing Tolerance
216
B TABLES
EXPRESSIONS Element
Properties Number 1-D Array Index 2-D Array Index Data Type Expression Values (R) . Expression I/O Point
B Tables
Usage Description
FAILURES Element
Properties Number Type Time or Count Between Duration State
FILES Element
Properties Number System Name Access Type Access Length Structure End of File Action Comment Character Initialize Option Recordset Name Recordset CommandText
217
FILES Element
Properties Recordset CommandType
FREQUENCIES Element
Properties Number Type Name Output File Report ID Data Type Data Category Process ID Categories (R) . Value or Range . Value . High Value . Category . Category Option
INCLUDE Element
Properties File Description
INITIALIZE Element
Properties Value
INTERSECTIONS Element
Properties Number Travel Length Link Selection Rule Rule Attribute ID
218
B TABLES
INTERSECTIONS Element
Properties Velocity Change Factor
LEVELS Element
Properties Number 1-D Array Index 2-D Array Index

B Tables
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 Velocity Change Factor
NETWORKS Element
Properties Number Links (R) . Starting Link . Ending Link
NICKNAMES Element
Properties Name or Constant
219
OUTPUTS Element
Properties Number Output File Name Report ID Data Type Category Process ID
PARAMETERS Element
Properties Number Values (R) . Value
PICTURES Element
Properties Number
PROJECT Element
Properties Title Analyst Name Month Day Year Summary Report Costing Entities Resources Queues
220
B TABLES
PROJECT Element
Properties Transporters Conveyors Processes Stations ActivityAreas Tanks

B Tables
QUEUES Element
Properties Number Ranking Criterion Rule Expression Associated Block/SHARED Auto Stats Generate Auto Stats Category Auto Stats Identifier
RANKINGS Element
Properties Ranking Criterion Ranking Expression
RATES Element
Properties Number 1-D Array Index 2-D Array Index Initial Values (R) . Value
221
RECIPES Element
Properties Statics (R) . Static Name . Value
REDIRECTS Element
Properties Number Network ID Intersections (R) . Beginning Intersection ID . Ending Intersection ID . Next Intersection ID
REPLICATE Element
Properties Number of Replications Beginning Time Replication Length Initialize System Initialize Statistics Warmup Period Terminating Condition DLL Name Hours per Day Base Time Units Execute Mode Realtime Mode Realtime Factor Simulation Start Date Time Include Fractional RC Units
222
B TABLES
REPORTLINES Element
Properties Number Report ID Format Expressions (R) . Expression
REPORTS Element
Properties Number System Name Title Heading Sort Format
B Tables
RESOURCES Element
Properties Number Capacity or Schedule Integer or Sched ID Capacity Entity Rule Stateset ID Initial State Resource Type Map ID Velocity Initial Position Position ID Zone Busy Cost
223
RESOURCES Element
Properties Idle Cost Usage Cost Category Type Failures (R) . Failure . Failure ID . Failure Entity Rule Auto Stats Generate Auto Stats Category Auto Stats Identifier Base Efficiency Efficiency Schedule ID
RULES Element
Properties Selection Rule Rule Expression
SCHEDULES Element
Properties Schedule Type Format Type Scale Factor Time Units Values (R) . Value . Duration
SEEDS Element
Properties Seed Value Initialize Option
224
B TABLES
SEGMENTS Element
Properties Beginning Station Next Stations (R) . Next Station . Length
SENSORS Element
Properties Number
B Tables
Tank Name Location Type Location Crossing Direction Block Label Initial State
SEQUENCES Element
Properties Number Stations (R) . Station ID . Assignments (R) . . . Variable . . . Value
SETS Element
Properties Number Members (R) . Member
225
STATESETS Element
Properties Number States (R) . State Name . Stateset Type
STATICS Element
Properties Default Value
STATIONS Element
Properties Number Intersection ID Recipe ID Parent Activity Area Auto Stats Generate Auto Stats Category Auto Stats Identifier
STORAGES Element
Properties Number
TABLES Element
Properties Number Low Value Fixed Increment Dependent Values (R) . Dependent Value
226
B TABLES
TALLIES Element
Properties Number Output File Report ID Data Type Category Process ID

B Tables
TANKS Element
Properties Number Capacity Initial Level Input Variable Name Output Variable Name Report Statistics Category Identifier Regulator Name Maximum Rate Time Units
TASKS Element
Properties Task Number Exec Expr Format Parameter
227
TRACE Element
Properties Beginning Time Ending Time Condition Expressions (R) . Expression
TRANSPORTERS Element
Properties Number Number of Units System Map Type Map ID Control Velocity Acceleration Deceleration Turning Velocity Unit Data (R) . Initial Position . Position ID . Zone . Initial Status . Vehicle Size . Size Integer Auto Stats Generate Auto Stats Category Auto Stats Identifier
228
B TABLES
VARIABLES Element
Properties Number 1-D Array Index 2-D Array Index Data Type Clear Option Category Type Response Category Type Initial Values (R) . Value I/O Point Usage Description
B Tables
Inverted elements
Listed below are the inverted elements and their properties as described in the Elements chapter.
Inv_DISTANCES Element Properties Beginning Station ID Ending Station ID Distance Distance Set ID
Inv_LINKS Element
Properties Number Beginning Intersection ID Beginning Direction Ending Intersection ID
229
Inv_LINKS Element
Properties Ending Direction Number of Zones Length of Each Zone Link Type Velocity Change Factor Network ID
Inv_SEGMENTS Element
Properties Beginning Station Next Station Length Segment Set ID
Inv_SETS Element
Properties Set Name
Inv_STATESETS Element
Properties Properties Stateset Type State Set ID
230
B TABLES
Fixed-length elements
Listed below are the fixed-length elements and their properties as described in the Elements chapter. The standard element associated with the fixed-length element is presented next to the element name in parentheses. The repeatable properties are denoted with an (R).
Fixed_ARR5 Element (Arrivals)
Properties Type
B Tables
Type ID Time Interval or Key Offset Max Batches Max Time Batch Size Variable ID 1 Value 1 Variable ID 2 Value 2 Variable ID 3 Value 3 Variable ID 4 Value 4 Variable ID 5 Value 5 Assignments (R) . Variable ID . Value
231
Fixed_ARR50 Element (Arrivals)
Properties Type Type ID Time Interval or Key Offset Max Batches Max Time Batch Size Variable ID 1 Value 1 Variable ID 2 Value 2 Variable ID 50 Value 50 Assignments (R) . Variable ID . Value
Fixed_ATT10R Element (Attributes)
Properties Number 1-D Array Index 2-D Array Index Data Type
232
B TABLES
Fixed_ATT10R Element (Attributes)
Properties Initial Values (R) . Value 1 . Value 2 . . Value 10
Fixed_ATT50 Element (Attributes)
Properties Number 1-D Array Index 2-D Array Index Data Type Value 1 Value 2 Value 50 Initial Values (R) . Value
B Tables
Fixed_EXP2R Element (Expressions)
Properties Number 1-D Array Index 2-D Array Index Data Type Expression Values (R) . Expression 1 . Expression 2 I/O Point Usage
233
Properties Description
Properties Number 1-D Array Index 2-D Array Index Data Type Expression Values (R) . Expression 1 . Expression 2 . Expression 3 I/O Point Usage Description
Properties Number 1-D Array Index 2-D Array Index Data Type Expression Values (R) . Expression 1 . Expression 2 . Expression 3 . Expression 4 I/O Point Usage Description
234
B TABLES
Properties Number 1-D Array Index 2-D Array Index Data Type Expression Values (R) . Expression 1 . Expression 2 . . Expression 7 I/O Point Usage Description
B Tables
235
Fixed_EXP5 Element (Expressions)
Properties Number 1-D Array Index 2-D Array Index Data Type Expression 1 Expression 2 Expression 5 Expressions (R) . Expression I/O Point Usage Description
Properties Number 1-D Array Index 2-D Array Index Data Type Expression 1 Expression 2 Expression 10 Expressions (R) . Expression I/O Point Usage
236
B TABLES
B Tables
237
Properties Number 1-D Array Index 2-D Array Index Data Type Expression 1 Expression 2 Expression 15 Expressions (R) . Expression I/O Point Usage Description
238
B TABLES
Properties Number 1-D Array Index 2-D Array Index Data Type Expression 1 Expression 2
B Tables
Expression 20 Expressions (R) . Expression I/O Point Usage Description
Properties Number 1-D Array Index 2-D Array Index Data Type Expression 1 Expression 2 Expression 25 Expressions (R) . Expression I/O Point Usage
239
240
B TABLES
Properties Number 1-D Array Index 2-D Array Index Data Type Expression 1 Expression 2
B Tables
Expression 50 Expressions (R) . Expression I/O Point Usage Description
Fixed_FRE50 Element (Frequencies)
Properties Number Type Name Output File Report ID Value or Range 1 Value 1 High Value 1 Category 1 Category Option 1 Value or Range 2 Value 2
241
Fixed_FRE50 Element (Frequencies)
Properties High Value 2 Category 2 Category Option 2 Value or Range 50 Value 50 High Value 50 Category 50 Category Option 50 Categories (R) . Value or Range . Value . High Value . Category . Category Option
Fixed_LEV10R Element (Levels)
Properties Number 1-D Array Index 2-D Array Index Initial Values (R) . Value 1 . Value 2 . . Value 10
242
B TABLES
Fixed_LEV50 Element (Levels)
Properties Number 1-D Array Index 2-D Array Index Value 1 Value 2
B Tables
Value 50 Initial Values (R) . Value
Fixed_PAR50 Element (Parameters)
Properties Number 1-D Array Index 2-D Array Index Value 1 Value 2 Value 50 Initial Values (R) . Value
243
Fixed_RAT10R Element (Rates)
Properties Number 1-D Array Index 2-D Array Index Initial Values (R) . Value 1 . Value 2 . . Value 10
Fixed_RAT50 Element (Rates)
Properties Number 1-D Array Index 2-D Array Index Value 1 Value 2 Value 50 Initial Values (R) . Value
244
B TABLES
Fixed_REC20 Element (Recipes)
Properties Static Name 1 Value 1 Static Name 2 Value 2 Static Name 20

B Tables
Value 20 Statics (R) . Static Name . Value
Fixed_REC50 Element (Recipes)
Properties Static Name 1 Value 1 Static Name 2 Value 2 Static Name 50 Value 50 Statics (R) . Static Name . Value
245
Fixed_RES50 Element (Resources)
Properties Number Capacity or Schedule Integer or Sched ID Capacity Entity Rule Stateset ID Initial State Failure 1 Failure ID 1 Failure Entity Rule 1 Failure 2 Failure ID 2 Failure Entity Rule 2 Failure 50 Failure ID 50 Failure Entity Rule 50 Failures (R) . Failure . Failure ID . Failure Entity Rule
246
B TABLES
Fixed_RLN50 Element (Reportlines)
Properties Number Report ID Format Expression 1 Expression 2

B Tables
Expression 50 Expressions (R) . Expression
Fixed_SCH50 Element (Schedules)
Properties Resource Capacity 1 Capacity Duration 1 Resource Capacity 2 Capacity Duration 2 Resource Capacity 50 Capacity Duration 50 Capacities (R) . Resource Capacity . Capacity Duration
247
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
248
B TABLES
Properties Number Stations (R) Station ID Variable 1 Value 1 Variable 2

B Tables
Value 2 Variable 40 Value 40 Assignments (R) . Variable . Value
249
Properties Number Stations (R) Station ID Variable 1 Value 1 Variable 2 Value 2 Variable 100 Value 100 Assignments (R) Variable Value
Properties Number Stations (R) Station ID Variable 1 Value 1 Variable 2 Value 2 Variable 250 Value 250 Assignments (R) Variable Value
250
B TABLES
Fixed_SET50 Element (Sets)
Properties Member 1 Member 2 Member 50 Members (R) . Member

B Tables
Fixed_STA50 Element (Statesets)
Properties Number State Name 1 Stateset Type 1 State Name 2 Stateset Type 2 State Name 50 Stateset Type 50 States (R) . State Name . Stateset Type
251
Fixed_TAB50 Element (Tables)
Properties Number Low Value Fixed Increment Dependent Value 1 Dependent Value 2 Dependent Value 50 Dependent Values (R) . Dependent Value
Fixed_TRA50 Element (Transporters)
Properties Number Number of Units System Map Type Map ID Control Velocity Acceleration Deceleration Turning Velocity Initial Position 1 Position ID 1 Zone 1 Initial Status 1 Vehicle Size 1 Size Integer 1 Initial Position 2
252
B TABLES
Fixed_TRA50 Element (Transporters)
Properties Position ID 2 Zone 2 Initial Status 2 Vehicle Size 2 Size Integer 2

B Tables
Initial Position 50 Position ID 50 Zone 50 Initial Status 50 Vehicle Size 50 Size Integer 50 Unit Data (R) . Initial Position . Position ID . Zone . Initial Status . Vehicle Size . Size Integer
Fixed_VAR2R Element (Variables)
Properties Number 1-D Array Index 2-D Array Index Clear Option Category Type Response Category Type Data Type
253
Properties Initial Values (R) . Value 1 . Value 2 I/O Point Usage Description
Fixed_VAR10 Element (Variables)
Properties Number 1-D Array Index 2-D Array Index Clear Option Category Type Response Category Type Data Type Value 1 Value 2 Value 10 Initial Values (R) . Value I/O Point Usage Description
254
B TABLES
Properties Number 1-D Array Index 2-D Array Index Clear Option Category Type Response Category Type
B Tables
Data Type Initial Values (R) . Value 1 . Value 2 . . Value 10 I/O Point Usage Description
Properties Number 1-D Array Index 2-D Array Index Clear Option Category Type Response Category Type Data Type Value 1 Value 2 Value 50
255
Properties Initial Values (R) . Value I/O Point Usage Description
Properties Number 1-D Array Index 2-D Array Index Clear Option Category Type Response Category Type Data Type Value 1 Value 2 Value 200 Initial Values (R) . Value I/O Point Usage Description
256
B TABLES
Data Types
As described in The Dialog Design Window chapter, there are SIMAN data types that are available. In most cases, these data types are derived from the valid field entries from modules in the Blocks and Elements panels. Refer to online help for more information on a specific block or element and its valid field values.
Data type definitions

The following is a list of the available SIMAN data types. The Data Type Name refers to the name of the data type as it appears in the Data Type property drop-down list entry in the dialog design window. Values are the permitted values a modeler may enter. If these values are a literal text string or punctuation, they are enclosed in double quotes. If the value is another data type (either a standard or SIMAN data type), then the value has no double quotes. Allowable Control Types specifies what control types are permitted with the data type.
Data Type Name Values AccmLength AttrID, real
B Tables
Data Type Name Values
ActivityAreaLevel Integer
AllorSpecific All, Specific
ArrivalTime Time, First, Last, Warmup, Every, Keyhit, Message
ArrivalType Station, Queue, Block, Event
257
AttrID IdOrInt, SymbolName ( Integer ), SymbolName ( Integer , Integer ), A( Integer )
BasicTimeUnit Seconds, Minutes, Hours, Days
Capacity Capacity, Schedule
ConsOrRange Constant, Range
ConvType Accumulating, Nonaccumulating
CountInitOpt Replicate, YesOrNo
CrossDir Positive, Negative, Either
CrossDirPosNeg Positive, Negative
Date Date
258
B TABLES
DateTime Date, Time
Day 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, MD1
B Tables
DistExp 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
EnabledDisabled Enabled, Disabled
EndOpt Error, Dispose, Rewind, Ignore
EntRule Preempt, Ignore, Wait
EventType User, VBA, ActiveX
259
FailType Count, Time
Failure Failure
FileAccType Sequential, Direct, User
FileFormat AnyCharacters
FileName AnyCharacters
FileStructure Unformatted, Free Format, WKS File, FileFormat
FlowAllocation ValueAdded, NonValueAdded, Wait, Transfer, Other
FlowType Add, Transfer, Remove
FormatType Duration, Calendar
260
B TABLES
FreqExp Value, State
GlobalPriority QTIME, LVF, HVF
IdOrInt
B Tables
SymbolName, Integer
IdOrIntOrRange SymbolName, Integer - Integer, Integer, SymbolName - SymbolName
IdOrIntOrReal SymbolName, Integer, Real
IdOrRealorKey SymbolName, Real, INFINITE
InitOpt Hold, Rewind, Close
InitVar J, M, NS, IS, X ( Integer)
LinkType Unidirectional, Bidirectional, Spur
261
Location Station, Intersection, Link
LSR FCFS, LCFS, Closest, Farthest, LVF, HVF
MD1 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 01, 02, 03, 04, 05, 06, 07, 08, 09
Method RKF, Euler, User
Month 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, MD1
NonNegativeReal Non Negative Real
DataNonNegativeRealorSymbol Non Negative Real, SymbolName
NonNegativeRealSymbolName Non Negative Real, SymbolName, NONE
262
B TABLES
PositiveInteger Positive Integer (optional min, max values)
PositiveReal Positive Real
PreemptDest
B Tables
Label, STO( IdOrInt )
QBlock Label, SHARED
QSR CYC, RAN, POR, LRC, SRC, LNQ , SNQ, UR ( IdOrInt ), ER ( IdOrInt )
QuotedString Quoted String
RangeIndex Integer, Integer .. Integer
RankingCrit FIFO, LIFO, LVF, HVF
RealorInfinite Real, Infinite
263
RealorSymbolName Real, SymbolName
RegulatorTimeUnit Per Second, Per Hour, Per Minute, Per Day
RepLengthTimeUnit Hours, Days, Weeks
ResourceAction Hold, HoldUntil
ResourceorSet Resource, Set
RSR CYC, RAN, POR, LRC, SRC, LNB, SNB, UR ( IdOrInt ), ER ( IdOrInt )
ResourceType Stationary, Positional, Distance, Network
RestrColumn Exclude, Include
264
B TABLES
Rule CYC, RAN, POR, LDS, SDS, LRC, SRC, LNQ, SNQ, LNB, SNB, UR, ER, MIN, MAX
SaveCrit First, Last, Product, Sum

B Tables
SeedInitOpt YesOrNo, Common, Antithetic
SensorLocationType Specific Level, Percentage Capacity
Severity Fatal, Warning, No
SignedInteger Signed Integer (optional min, max values)
Sort Ascending, Descending, Unsorted
StateSetType Idle, Busy, Inactive, Failed, IdOrInt
Status Active, Inactive
265
SystemMap Distance, Network
Time Time
TSR CYC, RAN, POR, LDS, SDS, UR, ER
UnitTimeUnit Seconds Per Unit, Minutes Per Unit, Hours Per Unit, Days Per Unit
VehicleSize Length, Zone
Year Integer
ZoneControl Start, End, Integer
266
B TABLES
Connection point data types and SIMAN blocks Entry/exit point types
There are six different entry point types and six different exit point types, as noted below.
Entry Types Standard Queue Seize Hold Type A Hold Type B Hold Type C Exit Types Standard Queue PickQ QPick Select Balk
B Tables
DESCRIPTIONS The three different entry types (Hold Type A, B, and C) are used to distinguish those modules that can connect to a QPick module (Access, Request, etc.) and those that cannot (Capture, Group). The Hold Type B is used when a Queue block is required. A Seize entry type is required for the Select exit type since only a Seize module can follow a Select module. CONNECTION
Exit Type Standard Queue PickQ QPick Select
VALIDATION
Entry Type Standard, Queue, Seize, Hold Type A, Hold Type C Seize, Hold Type A, Hold Type B, Hold, Type C Queue Seize, Hold Type A, Hold Type B Seize
267
CONNECTION
Block Access Allocate Capture Combine Group PickQ Preempt Proceed QPick Queue Request Scan Seize Select Wait
TYPES ON
SIMAN
MODULES
Connection Type Hold Type A Hold Type A Hold Type C Hold Type C Hold Type C PickQ (on queue label), Standard (on balk label) Hold Type A Hold Type C QPick (on hidden next label), PickQ (on queue label) Queue (Entry point), Queue (Exit Point on hidden next label) Hold Type A Hold Type C Seize Hold Type A, Select Hold Type C
268
Creating Online Help Files

Arena provides template developers with a help interface that easily allows designers to associate online help files with their templates, providing template users with detailed instructions on the use of various modules and their options. Here is an example of how the template help interface works. 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 looks like this:
C Creating Online Help
Figure C.1 Main dialog of the Server module
The repeat group and secondary dialog (Server Names and Options) look like this:
Figure C.2 Server Names Repeat Group dialog
Figure C.3 Options Secondary dialog
269
When you generate the Sample.tpo file, Arena will write out a help interface file called Sample.HH that looks something like this: Automated help: *.HH #define TemplateContents #define Server #define Server_ #define Server_Server_Names #define Server_Server_Name #define Server_Quantity #define Server_Process_Time #define Server_Options #define Server_Cost 4293984255 4294443008 0 524288 1048576 1572864 2097152 2621440 3145728
The left column (for example, #define TemplateContents) displays the Help Context ID that will be used by the Help Authoring Tool (for example, RoboHelp). The right column displays the Help Context Number that will be referenced by Arena. This file serves as a map between your Help Authoring Tool and Arena. The first entry for every 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 on any of these menu options will automatically display the help topic associated with the TemplateContents context ID. See the instructions below to find out how to associate a context ID with a help topic. The remaining entries are determined as follows: Each module will have an entry corresponding to the module name (for example, #define Server). By default, this context ID is utilized when you click the Context Sensitive Help toolbar button (on the Standard toolbar) and then click on a module button in the Project Bar. This could be used to display a general overview of the types of uses for that module. This behavior may be changed by editing the Module Help Option in the Template Options dialog. In Arena, every module dialog (including secondary dialogs and dialogs displayed when adding or editing items in repeat groups) contains a Help button. Each Help button may display either the main help topic for that module or a unique help topic for that particular dialog of the module. For example, the Server module displayed above has three dialogs: the main dialog (Server), and two secondary dialogs (Server Names repeat group and Options). Each of these dialogs has a Help button. The Server dialogs Help button will display the main help topic for the module. The Server Names dialog may display either the main help topic (as displayed by the Server dialog) or a unique help topic specific to the Server Names dialog. The Options dialog may display either the main help topic (as displayed by the Server dialog) or a unique help topic specific to the Options dialog.
270

C Creating Online Help
C CREATING ONLINE HELP FILES
To enable or disable unique help topics for individual dialogs, you specify a dialog form objects UniqueHelpTopic property as True or False in the module definitions dialog design window. By default, this property is set to True for a dialog form. If you enable a unique help topic for a particular dialog but fail to create a corresponding topic in your help file, users who press the Help button in that dialog will receive a message from the Windows Help system indicating that the topic does not exist in the help file. Therefore, you should always set the UniqueHelpTopic to True if you do not intend to create a help topic specific to the dialog. Similarly, in the module definitions dialog design window, each dialog form object includes a WhatsThisHelp property that is specified as True or False. This option will provide the dialog with a question mark in the top right of the title bar, allowing the user to ask for help on a specific operand in the dialog. If you enable this option but fail to provide a topic for each specific operand in your help file, users who click the question mark and then click an operand will receive a message that the topic does not exist. Therefore, you should not enable the Whats This? help option if you do not intend to create a help topic for each operand in the dialog. When the help interface (.HH) file is generated along with the .tpo file, the context IDs are written for each dialog according to the following rules: the main dialogs context ID is created by appending an underscore (_) to the module name, for example, Server_. The context IDs for all other dialogs are created by appending the dialog name to the module name, separated by underscores; spaces embedded in dialog and repeat group names are converted to underscores. For example, the Server Names dialog would generate a context ID of Server_Server_Names. The Options dialogs 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 name with an underscore. For example, the Server Names dialog would generate context IDs Server_Server_TimeName and Server_Quantity for the operands Server Name and Quantity within the Server Names dialog. To use the help interface file generated above, you need to first use your Help Authoring Tool to create help information in the form of topics. Next you tell your Help Authoring Tool that you have a help interface or map file (for example, Sample.HH). To do this in RoboHelp, you need to add the file to the list of map files for the project by following the procedure outlined below: 1. From the Project menu, choose Setup. 2. Click the Advanced tab. Under the Setup Section heading, highlight the (Map)/Include Files item, then click the Setup Section heading. 3. Choose the help interface file provided by Arena (e.g., Sample.HH) from the list and click Add. 4. Click OK several times until youve closed all the dialogs and are back to the help document.
271
Next you need to associate the individual help topics in your help document with the context IDs contained in the help interface file. To do this, you must edit each help topic and locate the Context String field (you may need to click the Advanced button to open up this section of the dialog). Click on the Choose button to bring up the Choose Context String Provided By Development Team dialog. Make sure that the help interface file provided by Arena is highlighted in the Project Map File field. Then select the appropriate context ID from the Symbolic Identifier list (for example, if you were editing the main help topic for the module, you would choose the Server_ context ID). Click OK until you have closed all dialogs and are back to the help document. The topic is now associated with the context ID. To associate the TemplateContents context ID with your Table of Contents for the template, you must do the following: 1. From the Project menu, choose Setup. 2. Click the Contents button. 3. Choose the TemplateContents context ID from the list of Context Strings. 4. Click OK several times until you have closed all the dialogs and are back to the help document. The next time you make the help file, it will incorporate the appropriate Help Context Numbers (the values in the right column of the .HH file) in the .hlp file. Note that the help file should have the same name as the template file. For example, Sample.tpo will look for a file called Sample.hlp.
272
Index
A
Accelerator keys 108 Advanced Process panel 2, 179 Advanced Transfer panel 2, 179 Animation object display in user view 164 in logic window 113 Arena Symbol Factory 4 Arena template 178 Assign module 45 Auto-Create 74, 95 Defining modeling logic 40 Delay module 48 Design Properties grid 83 Dialog Design toolbar 108 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 81 arranging controls 83 layout 39 locking controls 83 opening 82 resizing 83 Direct connection 121 in module logic 123
B
Back quote character use for referencing operand Basic Process panel 2, 178 114
C
Changes to instances 74 Check boxes customizing options 141 special access for references in logic window 120 Clipboard 74, 111, 113, 165, 176 Compatibility of existing module instances 74 Conditional assignment module 152 Contact information 5 Creating online help files 269 Customer Support Center 4
Index
D
DataType property SIMAN 100 standard 100 Decide module 44
273
Distances element 198 Document conventions 3 Documentation set 3 Draw object hidden/visible layer 163 in user view 163
H
Help file creation 269 Help interface file 271 Hidden operands 79
I
InUserView property 101
E
Element 177 data elements 177 define vs. reference option 185 defining through hierarchy 179, 183 defining via element operand 179 lists 180, 182 sub-lists 182, 185 special types fixed-length 196 hidden 197 inverted 198 switches on elements 195 Elements panel 179 entry 93 Entry point operand reference in logic window 123 operand validation/reference 94 operands 37 switches attached 160 user view object 160 Errors/warnings 67 reviewing 68 Exit point operand 37 operand validation/reference 94 repeatable 131 switches attached 160 user view object 160
L
Loading a template panel library (.tpl) file 66 Logic window attaching switches 146 connecting module instances 142 decomposing processes 109 design hints 207 detaching switches 146 differences with model window 111 hidden module (utlarena.tpo) and switches 150 multiple connections and switches 142 opening 110 repeating exit points and single connection 143 rules and guidelines 154 switches in module instances 121 verifying logic relative to switches 149 LogicProperties property 92 repeat groups 102
M
Model window differences with logic window Module 95 handle 157, 159 process of building logic 41 repeater 133 required option 72 types of entity flow 121 Module definition changes and existing instances copying 74 deleting 66 operand references 114 111
F
Field use in Logic Window chapter 113
74
G
Global pictures 55
274
INDEX
renaming 66 Module definition window 65 opening 67 Module handle 159 Module instance use in model or logic window 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
110
basic 92 element 92 entry point 93 exit point 94 hidden 101 property 93 special functions 97 specifying the DataType property 99 specifying the InUserView property 101 specifying the LogicProperties property 92 specifying the Name property 91 specifying the SwitchName property 101 specifying the Value property 96 Operands, using 91
N
Name property 91 repeat groups 102 NetworkLink element 198 Number of Alternate Outputs
P
Panel icon 175 design hints 206 size and display in template panel Panel icon window 175 tutorial 56 Process module 45 Project Bar 9, 23, 58, 71, 72 Property 177, 180 switches on properties 196 72, 176
134
O
Online help 3 Opening a module definition window 67 Opening a new template panel library (.tpl) file 65 Operand default value 115, 192 design hints 205 display in user view 161 repeatable operand 162 element 183 property 187 defining element and property using hidden operand 192 repeat group 188 references to 111 switching multiple with references to provided set 117 template panel library (.tpl) file operand report 68 value reference in switch definition 171 Operands
Q
Queue module 42 Queues element 50
R
Radio button group customizing options 141 special access for references in logic window 120 Referencing operands animation objects in user view 164 combining repeating and non-repeating references 131 concatenating text and reference 115 containing multiple references 116 entry point operands 123 in switch definition 171 multiple references to same operand 119
Index
275
repeating exit point 133 repeating operands 127 Release module 48 Repeat group 102 switch use 173 Repeat group objects 79 Repeat groups accessing the number of tuples and the tuple number 105 combining repeating operand values into a single value 106 definition depth and reference rules 104 reference rules 125 specifying the LogicProperties property 102 specifying the Name property 102 Repeatable logic 133 Repeatable module 133 Review errors 68
use in logic window 146 use in module definition windows
170
T
Technical support 4 Template documenting 208 Template Development toolbar 33 Template panel 65 changing the display name 71 creating new window 32 detaching 75 icon size and display 72 private 71 Template panel library (.tpl) file changes and existing module instances 74 checking for errors/warnings 67 Template panel object (.tpo) file changes and existing instances 74 generate .tpo in template window 67, 70 providing to modeler 70 rules regarding attachment to logic windows 112 Template window closing 66 deleting a module 66 generating the template panel object (.tpo) file 70 renaming a module 66 report 68 template options 71 version 70 Toolbox, using CheckBox control 86 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 RepeatGroupTable control 88 Text control 84
S
Sample models 3 Segments element 198 Seize module 42 Sets element 198 SIMAN template 179 Simulation logic and module design 109 SMARTs library 3 Station transfer 121 in module logic 122 Statistics hints for designing in module 209 Submodel 109 Switch 169 and element 195 and property 196 attached to user view animation object 165 defining 170 definition 70, 169, 171 operand comparison with value 172 in logic window module instance 121 name 170 rules regarding definitions 172 template panel library (.tpl) file switch report 68
276
INDEX
TextBox control 85 the controls 83 TimePicker control 89 Trace design hints for use in module definition 208 Trace in module definitions 153 Training courses 5 Tuple value of switch in 173
U
User view 157 design hints 207 designing 53 modifications by modeler 158 User view window 157 tutorial 53 Utlarena.tpo file 150 conditional assignment module 152 hidden module 150
V
Value property 96 Variables element 50
W
Web support 4 Whats This? help 271 Context IDs 271 World units 157
Index
277
278

Arena Template Developer&#39;s Guide

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Arena Template Developer&#39;s Guide

Загружено:

Авторское право:

Доступные форматы

Arena

TEMPLATE DEVELOPERS GUIDE

Trademark Notices Other Trademarks

2 Arena Template Development Overview

ARENA TEMPLATE DEVELOPERS GUIDE

4 The Template Window

5 The Dialog Design Window

ARENA TEMPLATE DEVELOPERS GUIDE

Using accelerator keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Dialog Design toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

6 The Logic Window

7 The User View Window

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

158 159 159 160 161 163 164 166

8 The Switch Window

9 The Panel Icon Window

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

ARENA TEMPLATE DEVELOPERS GUIDE

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

A Template Design Guidelines

C Creating Online Help Files

What is Arena simulation software?

ARENA TEMPLATE DEVELOPERS GUIDE

Figure 1.1 Arenas Template Window selection

About this guide

Where can I go for help?

Reference the users guides

Explore our examples

Use the SMARTs library

ARENA TEMPLATE DEVELOPERS GUIDE

Access the Arena Symbol Factory

Get phone support

Get Web support

Get consulting services

ARENA TEMPLATE DEVELOPERS GUIDE

Arena Template Development Overview

Modeling with ArenaAn overview

Figure 2.1 Process module user view

ARENA TEMPLATE DEVELOPERS GUIDE

Templates and panels

2 ARENA TEMPLATE DEVELOPMENT OVERVIEW

Figure 2.2 Sample template window

ARENA TEMPLATE DEVELOPERS GUIDE

Module definitions and instances

Figure 2.3 Main dialog for Create module

2 ARENA TEMPLATE DEVELOPMENT OVERVIEW

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 2 Overview

Dialog design and operands

ARENA TEMPLATE DEVELOPERS GUIDE

Figure 2.11 Record module default dialog

2 ARENA TEMPLATE DEVELOPMENT OVERVIEW

ARENA TEMPLATE DEVELOPERS GUIDE

Figure 2.13 Dialog for hospital Admissions Clerk module

2 ARENA TEMPLATE DEVELOPMENT OVERVIEW

ARENA TEMPLATE DEVELOPERS GUIDE

Figure 2.15 Sample switch window

Arena Template Developer's Guide

Arena Template Developer's Guide