Arena Template Developer's Guide

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

TEMPLATE DEVELOPER’S GUIDE

PUBLICATION ARENDG-RM001D-EN-P–November 2007Supersedes Publication ARENDG-RM001C-EN-P

Arena®

Contact Rockwell Customer Support Telephone — 1.440.646.3434Online Support — http://www.rockwellautomation.com/support/

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

Trademark Notices Arena, Rockwell Automation, and SIMAN are registered trademarks of Rockwell Automation, Inc.

Other Trademarks ActiveX, Microsoft, Microsoft Access, SQL Server, Visual Basic, Visual C++, Visual SourceSafe, Windows, Windows ME, Windows NT, Windows 2000, Windows Server 2003, and Windows XP are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.Adobe, Acrobat, and Reader are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries.ControlNet is a registered trademark of ControlNet International.DeviceNet is a trademark of the Open DeviceNet Vendor Association, Inc. (ODVA)Ethernet is a registered trademark of Digital Equipment Corporation, Intel, and Xerox CorporationOLE for Process Control (OPC) is a registered trademark of the OPC Foundation. Oracle, SQL*Net, and SQL*Plus are registered trademarks of Oracle Corporation.All other trademarks are the property of their respective holders and are hereby acknowledged.

Warranty This product is warranted in accordance with the product license. The product’s performance may be affected by system configuration, the application being performed, operator control, maintenance and other related factors. Rockwell Automation is not responsible for these intervening factors. The instructions in this document do not cover all the details or variations in the equipment, procedure, or process described, nor do they provide directions for meeting every possible contingency during installation, operation, or maintenance. This product’s implementation may vary among users.This document is current as of the time of release of the product; however, the accompanying software may have changed since the release. Rockwell Automation, Inc. reserves the right to change any information contained in this document or the software at anytime without prior notice. It is your responsibility to obtain the most current information available from Rockwell when installing or using this product.

Version: 12.00.00 (CPR9)Modified: October 8, 2007 12:10 pm

ii

http://www.rockwellautomation.com/support/

http://www.rockwellautomation.com/support/

Contents

1 • Welcome 1What is Arena simulation software? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Intended audience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2About this guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2Where can I go for help? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Reference the user’s guides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Explore our examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Get help. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Use the SMARTs library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Access the Arena Symbol Factory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Get phone support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Get Web support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Get training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Get consulting services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Contact us . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 • Arena Template Development Overview 7Modeling with Arena—An overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Templates and panels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Module definitions and instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Defining a module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Panel icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13User view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Dialog design and operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Elements and properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Arena hierarchy and SIMAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Flowcharts and data modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Use of templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25General modeling tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Industry-oriented environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Application-focused tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Improving modeling productivity and sharing modeling technology . . . . . . . . . 26

iii

ARENA TEMPLATE DEVELOPER’S GUIDE•

• •

• •

3 • Module-building Tutorial 29Module overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Getting started—A new template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Dialog Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

The dialog design window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Adding the module’s dialog operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Adding the module's entry/exit point operands . . . . . . . . . . . . . . . . . . . . . . . . . . 37Arranging the Dialog form layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40The logic window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Overview of the Printer module logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Receiving entities and seizing the printer—The Queue and Seize modules . . . . 42Deciding whether to changeover the printer—The Decide module . . . . . . . . . . . 44Changeover logic—Assign, Process, and Assign modules . . . . . . . . . . . . . . . . . 45The print logic—Delay and Release modules . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Defining the Printer module elements—Queues and Variables elements . . . . . . 50

User View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Panel Icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56A sample model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Preparing the template for use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Single printer simulation model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4 • The Template Window 65The template menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Creating a new template window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Loading an existing template panel file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Closing a template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Saving the template panel library file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Creating and editing modules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66The module definitions list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Opening module definition windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Preparing the template panel for use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Checking the template panel for errors and warnings . . . . . . . . . . . . . . . . . . . . . 67Reviewing errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Template panel file reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Generating the template panel object (.tpo) file . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Other template panel information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Changing the version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Template options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Defining required modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

iv

CONTENTS• • • • •

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

5 • The Dialog Design Window 77Dialog Design Window overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

The Operand Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78The Toolbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80The dialog form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81The Design Properties grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Using the Toolbox controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Using the Text control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Using the GroupBox control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Using the Line control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Using the TextBox control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Using the ComboBox control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Using the RadioButtonGroup control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Using the CheckBox control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Using the DialogButton control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87Using the RepeatGroupDialog control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87Using the RepeatGroupTable control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88Using the DateTimePicker control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88Using the DatePicker control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Using the TimePicker control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Using the FilePicker control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90Using the HiddenOperand control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Using operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Specifying the Name property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Specifying the LogicProperties property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Specifying the Value property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Specifying the DataType property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99Specifying the SwitchName property. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Specifying the InUserView property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Hidden operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Using repeat groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102Specifying the Name property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102Specifying the LogicProperties property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102Repeat group definition depth and reference rules . . . . . . . . . . . . . . . . . . . . . . . 104Accessing the number of tuples and the tuple number . . . . . . . . . . . . . . . . . . . . 105Combining repeating operand values into a single value . . . . . . . . . . . . . . . . . . 106Using repeatable modules in the logic window with repeat groups . . . . . . . . . . 107

v


• •

• •

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

6 • The Logic Window 109Simulation logic and module design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

The logic window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Differences between logic and model windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Running simulation models (model window) . . . . . . . . . . . . . . . . . . . . . . . . . . 111Referencing operands (logic window) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Switching module instances (logic window) . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Defining repeatable logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Module connections in the logic window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Attaching template panels while working in a logic window . . . . . . . . . . . . . . 112Display of animation objects (logic window). . . . . . . . . . . . . . . . . . . . . . . . . . . 113“Fields” and “operands” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Referencing module data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114Referencing operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114Special access for check boxes, radio button groups, and combo boxes . . . . . . 120Switches in logic window module instances . . . . . . . . . . . . . . . . . . . . . . . . . . . 121Defining transfer of entities into and out of a module . . . . . . . . . . . . . . . . . . . . 121Referencing non-repeating operands from a repeat group . . . . . . . . . . . . . . . . . 125Referencing repeating operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127Defining repeatable exit points in a module . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131Repeatable modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133Example 1: Parallel logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135Example 2: Serial logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137Example 3: Defining alternate outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139Customized options using radio button and check box controls . . . . . . . . . . . . 141

Module connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142Using graphical connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142Defining multiple connections from a single exit point . . . . . . . . . . . . . . . . . . . 142Repeating exit points in the logic window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Switching module instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146Attaching and detaching switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146Effect of switches in the logic window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147Using Arena’s utility modules (from utlarena.tpo) . . . . . . . . . . . . . . . . . . . . . . 150

Defining module trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153Logic definition rules and guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

7 • The User View Window 157Module instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

vi

CONTENTS• • • • •

Module-related objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158The module handle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159The Module Text Options dialog box. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159Entry and exit points. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160Displayed operands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Draw objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163Animation objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164User View switch use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

8 • The Switch Window 169Defining switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Switch names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170Switch definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171Switch definition rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

9 • The Panel Icon Window 175Creating the panel icon. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

10 • Elements 177Defining elements in modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

Creating elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179Element lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

Use of elements and properties in module definitions . . . . . . . . . . . . . . . . . . . . . . . 181Access to properties in a model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181Displaying element lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

Defining elements via hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183Element operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

Defining element operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183Sub-lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185Defining and referencing elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

Property operands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187Defining Property operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187Defining repeating properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188Defining an element/property using a hidden operand. . . . . . . . . . . . . . . . . . . . 192

Switches and elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195Special element types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

Fixed-length elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196Hidden element list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

vii


• •

• •

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

A • Template Design Guidelines 205Dialog box design (dialog design window) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Dialogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205Operand objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205Helpful hints for defining objects in the dialog design window. . . . . . . . . . . . . 206General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

Panel icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206User view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207Module logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207Naming conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208Template documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208Trace. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208Statistics and reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

B • Tables 211Elements and properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

Standard elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211Inverted elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229Fixed-length elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257Data type definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

Connection point data types and SIMAN blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . 267Entry/exit point types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

C • Creating Online Help Files 269

273

Index 273

viii

1 • Welcom

e

1 Welcome

What is Arena simulation software?Arena is an advanced simulation system that provides an interactive environment for building, graphically animating, verifying, and analyzing simulation models. With Arena, you can design a unique Arena template that is specific to your particular project, company, or industry. The template development features build on Arena’s natural hierarchical structure enabling you to create new simulation tools in a graphical, easy-to-use environment.

Within Arena’s template-building area, you create complete simulation building blocks, called modules. These modules may be very simple, such as one that counts customers as they leave a bank. Or you might build a highly complex module that captures all of the activities at a shipyard dock. In fact, Arena’s hierarchy encourages you to take apart the systems you study into their critical, basic elements, then combine these basic elements into the more complex components and subsystems to be simulated.

The modules that you build are collected into libraries, referred to as templates. You may use these templates in support of your own simulation activities, or you may share these simulation tools with other modelers.

By encouraging this sharing of technology, Arena offers the opportunity for you, as a simulation modeler, to create completely customized environments, without writing any programming code. Novice modelers can access the power of simulation as a decision support tool by working with terminology, modeling logic, and graphical animation that are specially developed for their needs. Experienced simulationists can improve their productivity and share the knowledge they have gained by capturing essential simulation logic and quickly packaging it into a verified, reusable building block for future models.

As mentioned above, within Arena you have the ability to define new modeling constructs, called modules, and to store them in libraries, referred to as Application Solution Templates (AST’s), or templates.

If you are familiar with Arena’s model-building and analysis environment, you will find that the template development features build on the concepts and interface you already have learned. When you run Arena, you will simply open a Template Window (instead of a Model Window). Select the File > New menu option or press the New File toolbar

1


• •

• •

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

Figure 1.1 Arena’s Template Window selection

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

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

About this guideThe Arena Template Developer’s Guide is designed to serve as both an instruction manual for building templates and as a reference guide for the template-building features. We start by presenting two chapters that familiarize you with the concepts and terminology employed in Arena and walk you through a simple module-building tutorial. Following this, we provide a description of the template window, then of each of the five windows that you employ to build modules. Next we present Elements, the final concept related to the definition of Arena modules. Appendix B of this book contains reference tables.

To begin your experience with template development, we recommend that you read Chapter 2, “Arena Template Development Overview,” to become familiar with Arena concepts and terminology. Then, follow the step-by-step instructions provided in the module-building tutorial in Chapter 3. While you are building your first module, you may want to refer to concepts presented in Chapter 2.

2

1 • WELCOME• • • • •

1 • Welcom

e

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 you’re new to simulation or a seasoned veteran putting a new tool to use, you’ll quickly feel at home with Arena simulation software.

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

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

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

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

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

3


• •

• •

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

Get phone supportRockwell 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 professionalshelp with installation problems or questions related to the software’s requirementstroubleshootinglimited support regarding the interaction of Arena with other programssupport 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 numberthe operating system you are usingthe exact wording of any messages that appeared on your screena description of what happened and what you were doing when the problem occurreda description of how you tried to solve the problem.

Get Web supportIn addition to phone support, the Rockwell Automation Customer Support Center offers extensive online knowledgebases of tech notes and frequently asked questions for support of non-urgent issues. These databases are updated daily by our support specialists.

To receive regular e-mail messages with links to the latest tech notes, software updates, and firmware updates for the products that are of interest to you or to submit an online support request, register through http://support.rockwellautomation.com/.

4

1 • WELCOME• • • • •

1 • Welcom

e

And be sure to check the Arena User Zone section of our Web site at www.ArenaSimula-tion.com. The User Zone links to a peer-to-peer forum on Arena topics and has a link to a download page where you can check for possible software updates (patches). If you can’t find the answer you need, contact your local representative or Arena technical support.

Get trainingDo you need training? Rockwell Automation offers a standard training course comprised of lecture and hands-on workshops designed to introduce you to the fundamental concepts of modeling with Arena.

We also offer customized training courses designed to meet your specific needs. These courses can be held in our offices or yours, and we can accommodate one person or twenty. You design the course that’s right for you! Simply contact our consulting services group to discuss how we can help you achieve success in your simulation efforts.

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

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

Support E-mail: [email protected] E-mail: [email protected]

Support phone: 1.440.646.3434URL: www.ArenaSimulation.com

URL: www.rockwellautomation.com

5


• •

• •

6

2 • Overview

2 Arena Template Development OverviewIn 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.

Modeling with Arena—An overviewIn Arena, simulation models are built by placing modules in a model window, providing data for these modules, and specifying the flow of entities through modules. A module defines the underlying logic that is applied when an entity is directed to the module, as well as the associated graphical animation, to depict the module’s activities during a simulation run. This section provides a brief overview of model building with Arena. For information about using Arena to build, animate, and analyze simulation models, refer to the Arena User’s Guide and online help.

To use a module in an Arena model, a panel containing the module is attached to the Project Bar. This panel displays all of the modules that may be selected for placement in the model. To build a model, you select a module from the panel and place it in the model window. The graphics associated with the module, referred to as its user view, are added to the model window. This display of the module always contains a module handle (typically the module name) and may include static drawing objects, animation objects, operand display values, and connection points, as illustrated in Figure 2.1.

Figure 2.1 Process module user view

7


• •

• •

After a module has been placed in the model window, its associated data may be edited by double-clicking on the module. This action opens the module’s main dialog, which typically contains one or more changeable values, referred to as operands of the module. These operands provide the mechanisms for changing the behavior of the module in different uses within simulation models. For example, using the Process module from the Basic Process panel, you might seize, delay, and release with a resource named Line D Labeler. In the same model, you might place another Process module that requires a resource named Line D Packer for processing. Entities sent to the first module wait for the Line D Labeler resource. While entities arriving at the second Process module undergo similar logic (i.e., the logic captured in the Process module), they are waiting for a different resource (Line D Packer).

To define the flow of entities among modules, either direct connections or station transfers may be used. A direct connection is formed by placing a connection from a module exit point to a module entry point. Entities that leave a module through an exit point are transferred through the connection to the entry point with no time delay. A station transfer takes place when an entity leaves a module by means of a route, transport, or convey, as seen in the Leave or Route modules of the Advanced Transfer panel; in these cases, a station destination is specified and the entity is sent to the module that defines the station, such as an Enter or Station module (Advanced Transfer panel). These station transfers often involve time delays and may require a material transfer device (e.g., person, shuttle car, conveyor) to move the entity to its destination station.

After modules are placed in a model and values are provided for their operands, a simulation run may be performed. To initiate a run, Arena generates a SIMAN model file (representing the model logic) and an experiment file (containing data to support the model) based on the modules that have been placed in the Arena model. Values of module operands may cause particular sections of the model to be generated or ignored, may cause the creation of elements in the experiment, and may enable or disable display of animation components. For example, collecting a count in the Record module causes a Count block to be included in the SIMAN model file and a Counters element listing the counter name to be written to the SIMAN experiment file. In this case, no animation component is included automatically. After the model and experiment have been generated and the animation graphics (if any) initialized, the simulation commences, acting on the simulation program (.p) file that results from the model generation phase.

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

8

2 • ARENA TEMPLATE DEVELOPMENT OVERVIEW• • • • •

2 • 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.)

Figure 2.2 Sample template window

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

9


• •

• •

Module definitions and instancesA module in Arena is a single construct that may be selected from a template panel and placed in a model or, as we will see, in the definition of a new module. Each icon in a template panel represents a single module, such as a Create (to generate entities) or Process (for simple processing of entities).

The information about a module that is stored in the template panel library (.tpl) file is referred to as the module definition. In the template panel object (.tpo) file, the information contained in the module definitions is condensed for use in a simulation model. When a module is selected from a .tpo file and is placed in a model window, we refer to the representation of the module in the model window as a module instance.

The module definition defines the structure of the module and provides default data and visualization of the module. Each time a new instance of the module is created, the new instance contains the defaults provided by the module definition. However, these defaults may be modified by the modeler so that each instance carries with it its own characteris-tics. For example, the default main dialog for the Create module (provided by the Arena template’s Basic Process panel) displays eight operands that the modeler may edit: the module Name or label, the Entity Type (Entity 1, by default), information related to the time between arrivals (the Type, Value, and the number of Units), the number of Entities per Arrival, the Maximum number of Arrivals, and the time of First Creation. (See Figure 2.3.)

Figure 2.3 Main dialog for Create module

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

10


2 • Overview

customers arrive at varying times or rates. First, a Create module is placed in the model window. The modeler may change the values of the Create module instance’s operands. For example, the first customer type may utilize the default arrival stream, which is random (exponential). A second type of customer may arrive at a Constant rate. In that case, a modeler might change the value in one instance of the Create modules to Constant. Note that by changing the value in an instance, the modeler does not modify the definition. In the case of the Create module, the next instance (and all instances, until edited) will have a default type of arrival stream of Random (from the module definition).

Module instances may be placed in Arena model windows (and later saved in model .doe files) or in the logic windows of new module definitions (to be saved in .tpl files). For simplicity’s sake, we usually discuss use of module instances by “the modeler” (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 moduleA 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


2 • Overview

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

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

Figure 2.6 Basic Process template panel

13


• •

• •

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

Figure 2.7 Create module panel icon

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

Figure 2.8 Process module instance’s default user view

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

14


2 • Overview

Figure 2.9 Modified Process module instances

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

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

Dialog design and operandsAn 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 name’s value and the current simulation time, instead of simply increasing or decreasing a specified count.

In a template panel library (.tpl) file, the Dialog Design window is the interface for defining the dialog form layout(s) and operands of a module definition. In this window, a module designer defines dialog sizes, data displayed to and entered by the user, default and permissible values, and the layout of interface controls.

The dialog design window includes an Operand Explorer section to browse the module definition's hierarchy of dialogs (many modules contain multiple dialogs), operands, and repeat groups (for defining repeatable operands or sets of operands, such as the resources to be utilized in a process). It also includes a Toolbox section to add user interface controls to the module’s dialog forms and a Design Properties grid to edit the properties of one or more selected objects.

16


2 • Overview

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

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

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

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

17


• •

• •

Note that the logic window is the second window in Arena that can contain instances of modules. As mentioned previously, in this guide we most often discuss placement of modules in “model windows” by “the modeler.” Remember, as you read, that these discussions also refer to the creation of module logic unless otherwise noted.

Note that when the logic window is active, the Run toolbar is not available because Arena module definitions cannot be simulated themselves—only instances in models can be part of a simulation run. Also, by default, the animation objects in a logic window are not displayed since they are primarily useful only for depicting the behavior of a running simulation. You may turn on the display of the animation objects in the window by using the View > Layers menu item.

An important aspect of defining Arena modules is the tie between the operands and logic. The operands provide the “external” interface for a modeler; the logic is the “internal” behavior of the module under the circumstances defined by the values of operands. A modeler can customize a module’s logic each time a new instance of the module is placed by providing different values for the module operands.

The mechanism for passing operand values from the module instance’s dialog to the underlying module logic is through operand references established in the logic window of the module definition.

To illustrate this, let’s consider a module that represents an admissions clerk at a hospital. The entities flowing through this module will represent patients or family members who need to provide admissions information. Modelers using this Admissions Clerk module will simply provide the name of the clerk and the time to process an admission. In the underlying logic, we will use the Process module from the Basic Process panel. A sample dialog for the Admissions Clerk module is shown in Figure 2.13.

Figure 2.13 Dialog for hospital Admissions Clerk module

In each instance of the Admissions Clerk module, different values might be given for the two module operands (Clerk Name and Time to Admit). To use these values, we will pass the value of the Clerk Name operand to the Resource name field in the Process module, and the Time to Admit operand to the Expression field.

To reference an operand of the module from an instance (such as the Process module), you edit the instance in the logic window; wherever you would like to use the value of a

18


2 • 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 instance’s user view and operands, the module’s logic cannot be directly modified by a modeler. Instead, the module’s operands may be used to specialize an instance of a module to a particular need by passing data to the logic (i.e., the module instances in the logic window) and, as we will see, by causing sections of the logic to be switched in or out.

Note that there may be one or more operands in a logic module instance (in the logic window) that are not available for the end user. For example, in the Process module description above, the Type remains the default Standard, Action is Seize Delay Release, Priority is default of Medium(2), and Delay Type is Expression. These operand values cannot be changed by a modeler, as they are not accessible via operands in their module.

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

To define this behavior, objects called switches are created in the module definition. These switches are placed in a switch window, as shown in Figure 2.15.

Figure 2.15 Sample switch window

20


2 • Overview

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

Figure 2.16 Tally Block with attached switch in logic window

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

21


• •

• •

Elements and propertiesThe concepts we have presented thus far relate to building modules, where each module definition is a self-contained unit. When a module is placed in a model, its characteristics are specific to the instance; a change to the value of an operand or to the appearance of an object in the user view has no effect on other modules of the same type.

However, there are some constructs in a simulation model that are inherently global in nature. We refer to these as elements of the model. These elements may be referenced by more than one module instance, and creation of an element places the name of the element on a list that is accessible by other module instances.

For example, if you place a Process module in the Arena template, you might specify the name of the resource to seize and release to be Packer. When you do so, you create a new resource element named Packer. If you place another Process module and pull down the list associated with the Resource name field, you will see that Packer appears in the list.

Elements are separated into types such as queues, resources, conveyors, etc. Each of these types has its own set of characteristics, referred to as properties. A queue has properties such as a ranking rule; resources have capacities, failures, etc.; and conveyors have properties such as velocity and type (accumulating or nonaccumulating). (Refer to Appendix B “Tables” on page 211 for a list of all element types and their properties.)

Each specific element that is defined in a model has its own values for its properties. For example, one resource element named Clerk might follow a capacity schedule named Early Day; another resource element named Supervisor might follow a schedule named Normal Day.

It is important to note that the properties of a particular element, such as the Clerk resource, are global to the entire simulation model. If the Clerk initially is defined by a Process module from the Basic Process panel and you edit a Resource module (also from the Basic Process panel) in the model, the resource Packer will automatically be specified, with default information, such as type and capacity.

In a module definition, in the dialog design window, you identify particular operands that will define elements by specifying in the operand’s LogicProperties property that the operand type is Element. Similarly, an operand that defines a property of an element is given the type Property. The chapter “Elements” presents a more detailed discussion of the concept of elements and their properties. Refer to the “The Dialog Design Window” on page 77 for information about defining element and property operands.

Arena hierarchy and SIMANArena employs a hierarchical architecture for simulation modeling—i.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 Arena’s hierarchy represent the SIMAN simulation language. These modules form the SIMAN template, which contains two panels: Blocks and Elements. The Blocks panel consists of modules that generate blocks in a SIMAN model (.mod) file, such as Delay, Branch, etc. Many of the modules in the Arena template are given the same name as Blocks modules and perform the same function as their Blocks panel counterparts. However, the modules in Arena offer options for the types of information that is to be placed in an operand (e.g., whether the type of element to be assigned a value is an attribute, a variable, a picture, etc.), and define both the model logic (i.e., blocks) and elements (i.e., information to be written to SIMAN’s experiment file).

The Elements panel consists of modules that represent each of the element types in the SIMAN experiment (.exp) file, such as resources, queues, counters, etc. Many data modules in the Arena template panels (e.g., resources, queues, conveyors) correspond to modules in the Elements panel.

When you build a new module definition, one of the steps is to define the logic associated with the module. In doing this, you attach one or more template panels to the Project Bar and place instances of modules. If these modules come from the SIMAN template (Blocks/Elements panels), when a modeler uses your module, the final SIMAN model and experiment used for a simulation run are generated directly through the modules you placed. This may be thought of as a module utilizing a single level of hierarchy, as illustrated in Figure 2.17.

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

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

23


• •

• •

and SIGNAL modules contained in the logic window. As the template designer, you have complete control over which characteristics of the underlying logic are changeable by users of the module and which characteristics are fixed at values you have chosen.

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

Figure 2.18 Multi-layered hierarchy

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

Flowcharts and data modulesAlthough all modules have many common features, it sometimes is useful in the design of a template to distinguish between “flowchart” and “data” modules. We use the term flowchart module to refer to a module that permits entity flow in and/or out, such as the following modules displayed in Arena’s Basic Process panel: Create, Dispose, Process, Decide, Batch, Separate, Assign, and Record. These are the fundamental processing modules that act on entities.

On the other hand, entities do not flow into or out of data modules. These data modules are placed to supply information about elements of a simulation model. Data modules in the Basic Process panel include: Entity, Queue, Resource, Variable, Schedule, and Set.

24


2 • Overview

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

Use of templates

IntroductionTemplates 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.

General modeling toolsThe first templates developed in Arena were the SIMAN and Arena templates. The two panels composing the SIMAN template—Blocks and Elements—provide a graphical interface to the SIMAN language for modelers and form the base of all Arena modules. The three panels composing the Arena template—Basic Process, Advanced Process, and Advanced Transfer—provide modules that capture commonly encountered processes and system elements using generic terminology (e.g., process, decide, record).

In the manufacturing area, modelers have exploited the powerful capabilities built into SIMAN and Arena for capturing essential system characteristics, including operational schedules, process plans, automated material-handling systems, etc. Modelers also have applied the Arena template to represent systems such as airline operations, health care, logistics, distribution, and business process reengineering (BPR). And, even within some organizations, Arena has been used for a wide spectrum of simulation studies, from long-range planning to analysis of near-term system changes.

The strength of a general modeling tool, used in a single, cohesive environment, is that modelers are provided with a core set of terms and concepts that can be applied to many different problems. Knowledge gained in studying one system can readily be applied in performing the next simulation project.

Industry-oriented environmentsTemplates 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 Arena’s hierarchical templates, a template can be built that is fully customized to represent accurately the elements of systems in the industry, rather than simply mapping existing modeling functionality provided by a general modeling tool. The designer of the template has the capabilities at hand to mimic exactly the behavior of equipment, people, parts, components, etc., providing whatever spectrum of options is appropriate for the variations of these system elements.

Application-focused toolsMany of the templates that are developed using Arena will aid modelers in representing a particular system, facility, or process. In building these templates, the template designer will have a more narrow focus than the developer of a general modeling template or a template to be used widely in an industry. For example, a template might be built for use in analyzing engine assembly lines in an automotive company or for representing delivery of pharmaceuticals in a hospital. The template’s scope is not large enough to encompass a large subset of problems in a particular industry; rather, the modules contained in the template are focused on a particular application that might appear in many systems or facilities.

These application-focused templates benefit from Arena’s hierarchical structure in the same ways as industry-focused templates: the interface presented to a modeler can be customized to be very familiar (both in terms of graphical animation and the terminology used in module dialogs); and parts, processes, etc., in the target application environments can be represented accurately.

In some cases, a modeler might build a template for his/her own individual use. In other cases, templates might be created for use among a few modelers in a common group; many application-focused templates will be shared among different modeling groups in an organization.

Improving modeling productivity and sharing modeling technologyFor 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 module’s definition. The second approach—building a reusable “printer” module—decreases the likelihood that you might make a mistake in reusing the original printer representation, encourages you to reuse what you have learned, and makes it much easier for you to share with others the modeling approach you have developed.

27


• •

• •

28

3 • Module-building Tutorial

3 Module-building TutorialIn this chapter, we will build a small module to illustrate the fundamental concepts of creating templates in Arena. We present this material with the goal of providing a step-by-step tutorial that you can follow using the Arena software. If you follow the instructions in this chapter, at the end of the tutorial you will have built a complete module representing a high-speed computer printing station, and you will have created a simulation model using it. While the module you will create is quite simple, it does include the key elements of module definitions: a dialog with a few operands, simulation logic, a user view with animation, and a panel icon.

As you build the module outlined in this chapter, it may be helpful to refer to Chapter 2, “Arena Template Development Overview,” which provides definitions of important terms and explains critical concepts related to building templates.

We begin by describing the module that is to be built. Following this, we present sections that document the procedure used in four module definition windows (dialog design, logic, user view, and panel icon) to create the module. Finally, we use the module to build a small simulation model.

Module overviewTo 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 Arena’s Basic Process panel is used. Step-by-step instructions for creating this logic are presented later in the chapter.

30

3 • MODULE-BUILDING TUTORIAL• • • • •


Figure 3.2 Printer module logic

A print job entity arriving at the Printer module begins processing at the Queue module instance. The print job waits to seize the printer resource, then tests in the Decide module to determine whether a changeover should occur.

If there is a changeover, the entity follows the changeover logic path (shown from the True exit to the Assign module). In this case, it changes a variable, `Printer Name`_Change, to the value of 1 to indicate that a changeover is taking place and performs the changeover in the Process module. Following the changeover, the print job entity restores the changeover variable back to 0 and changes a variable that records the last job type processed on the printer (to the entity’s job type).

If no changeover was required, the entity is sent from the Else (or false) condition of the Decide module directly to the Delay module to process the print job. (Entities that underwent a changeover also enter the Delay module after completing the changeover process.) After the print time delay, the print job entity releases the printer resource.

To create the Printer module logic, you may either build the submodel directly in the logic window of the module definition or you may prepare an Arena model with the same logic. If you build the logic first as an Arena model, you have the opportunity to use Arena’s Run Controller and to view the detailed animation of the module logic by running a simulation of the logic directly (rather than through an instance of the Printer module). Using this approach, after you are confident that the logic has been specified as you want, you can copy the verified logic from the model window to the Printer module’s logic window via Arena’s clipboard.

31


• •

• •

For the purposes of this tutorial, however, we present the Printer module by defining the logic directly in the module definition’s logic window. In this way, we can concurrently discuss both the sample problem to be addressed (i.e., the high-speed printer station module) and the particular aspects relating to creating modules. You may want to create the logic shown in Figure 3.2 in a model window first in order to develop an understanding of the module we will be creating in this tutorial.

We will present the Printer module definition windows in the following order: Dialog Design, Logic, User View, Panel Icon. We do so because we find that it is important to consider together the module logic and the operands when designing a module. In this tutorial, we present the dialog design window first because it can be completely defined and tested without the underlying module logic. The logic, on the other hand, is difficult to test without operands to provide an interface for defining the data that can change from instance to instance of the module. When you are developing your own modules, you probably will find that you move back and forth between defining the module logic and adding operands in the dialog design window, which we find to be a natural way of creating a complete module definition.

Getting started—A new templateThe 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 module’s main dialog object (defined in the dialog design window),the default title of the module’s main dialog, andthe 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 windowWe 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 Form—the dialog form layout is displayed in the center of the window.

Toolbox—provides an interface for graphically adding controls (e.g., text boxes, combo boxes, or dialog buttons) and static graphics (e.g., text, lines, or group boxes) to the dialog form layout(s).

Operand Explorer—displays the hierarchical organization of the dialog form, operand, and repeat group objects that define the dialog structure of the module.

Design Properties—provides an interface for viewing and/or editing properties of the currently selected object(s).

When a module definition’s dialog design window is opened, by default the main dialog form of the module is displayed in the center of the window. Thus, for our Printer module definition, we see a dialog form named “Printer.” This is the dialog that will be displayed when the modeler double-clicks on an instance of a Printer module in a model window.

To specify the dimensions of the dialog form, go to the Design Properties window. This window should display the properties of the Printer DialogForm object. Edit the Height and Width property rows and enter a height of 110 and a width of 170.

34



Figure 3.5 Design properties of the Printer DialogForm object

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

Adding the module’s dialog operandsThe Printer module’s dialog will include four visible operands editable by the user (as shown previously in Figure 3.1): Printer Name (combo box control), Technician (combo box control), Changeover Time (text box control), and Print Time (text box control).

PRINTER NAME OPERAND

To add the Printer Name operand to the dialog form layout and module definition, perform the following steps:

1. Click on the ComboBox control in the Toolbox section. Then, move the pointer to the location in the dialog form where the “Printer Name” operand is to be placed. Left-click again to place the combo box on the dialog form layout.

Note: At this point, your dialog form layout may not resemble the form in Figure 3.1. You will learn how to arrange the operands graphically in “Arranging the Dialog form layout” on page 39.

2. In the Design Properties window, specify the properties of the selected combo box as follows:

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

35


• •

• •

Specify the DataType property as SymbolName. This will ensure that a modeler using the Printer module can specify only a valid symbol name for the Printer Name operand.

Specify the Required property as True. This will require that any use of an instance of the Printer module will have a non-blank value for the Printer Name operand.

Specify the InUserView property as True. Because the Printer Name is the primary piece of information related to the Printer module, displaying it in the user view will help a modeler identify the particular printers represented in a model if more than one Printer module is used.

3. In the Design Properties window, select the LogicProperties property of the combo box. This property provides a dialog for specifying characteristics of the operand related to its purpose in the module’s interface and logic. In this example, we want the Printer Name operand to also define a resource element, based on the printer name. Thus, the Logic Properties dialog is completed according to Figure 3.6.

Figure 3.6 Logic properties of the Printer Name ComboBox object

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

36



TECHNICIAN, CHANGEOVER TIME, AND PRINT TIME OPERANDS

The three remaining visible operands—Technician, Changeover Time, and Print Time—are defined in the same manner as the Printer Name operand.

The Technician operand is added using a ComboBox control. This operand also defines a name for a resource, and thus in the LogicProperties property the operand’s type is also specified as Element of type RESOURCES. The operand’s DataType is specified as SymbolName and its Required property is True.

The Changeover Time and Print Time operands are added using TextBox controls. These two operands allow more flexible entries and thus their DataType properties are specified as Expression. They are Basic type operands in the LogicProperties property and do not require a value to entered by the modeler.

Adding the module's entry/exit point operandsIn addition to the four visible operands seen and editable by users in the module’s dialog, two hidden operands will be added to the module definition. These operands will be used to define the entry and exit points of the module, thus allowing the user to connect other modules into and out of the Printer module for entity flow.

Because the entry label and exit label operand fields are hidden from the user, the user will not have access to the fields within the dialog box. However, graphical entry and exit points will be available in the module’s user view to place the module connections.

To add a hidden operand to the module definition, click on the HiddenOperand control in the Toolbox section. Then, move the pointer to any location in the dialog form and left-click again to add the hidden operand. The hidden operand will be displayed in a window section at the bottom of the dialog design (and also in the Operand Explorer tree) as shown in Figure 3.7.

37


• •

• •

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.

HiddenOperand object

38



Figure 3.8 Logic properties of the Label HiddenOperand object

Figure 3.9 Logic properties of the Next Label HiddenOperand object

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

39


• •

• •

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 windowThe 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 logicWhen 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 template’s Create module and specifying an entity type (which will assign the internal attribute Entity.Type equal to that type). This aspect of module design—whether to predefine information or to provide options to modelers—often is more challenging than the process of building the module itself.

In the following section, we provide a step-by-step description of the process of building the module logic for the Printer module. Figure 3.11 shows the completed module logic.

41


• •

• •

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

Figure 3.11 Printer module logic

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

42



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 printer—The Decide moduleThe next module encountered by print job entities is a Decide module (from the Basic Process panel) with two branches (Type is 2-way by Condition). The first branch tests to see whether the value of the Entity.Type entity attribute differs from the last job type processed on the printer, stored in a variable named `Printer Name`_LAST. If so, entities are sent to the changeover logic. The second branch, an Else (or false) condition, sends entities directly to be processed on the printer.

The dialog for the Decide module instance is shown in Figure 3.14. The dialog is shown with the test condition for detecting changeovers. To define the Decide module, use a two-way condition testing the variable `Printer Name`_LAST against the entity attribute

44



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

In the logic window, the connection from the True condition sends entities to the changeover logic, (described next). The False condition connects directly to the printer logic (described after the changeover section).

Note: Because different entities in the same model might access either path of logic, the decision regarding changeover is built into the simulation model logic, rather than controlled by attaching switches to the modules. Switches determine logic to be included for all entities. In cases where different types of entities perform different actions, a module such as Decide (N-way by Condition) or SIMAN Branch block should be used. (Switches are described in the “Arena Template Development Overview” and “Switch Window” chapters.)

Changeover logic—Assign, Process, and Assign modulesThe 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 logic—Delay and Release modulesAfter 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 elements—Queues and Variables elementsThe 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 module—the user view and panel icon.

Note: In this example, we have used the logic window to create two elements associated with the printer, the queue, and the changeover variable. These elements could have been generated, instead, by utilizing hidden element-type operands in the dialog design window. Based on the information you wish to provide the user for a given element, you will need to decide which method to use for creating specific elements and their properties. Please refer to the chapter “Elements” for a more in-depth discussion of the various ways to define elements.

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

The user view for the Printer module will contain six objects:

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, andan 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 IconThe panel icon for a module is the picture that appears in the panel when a template panel file is attached to a model window (or to the logic window of another module’s definition). It is drawn in a window that is similar to the picture edit window used to create animation resources, entities, etc.

56



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 useYou 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 file’s modules (in this case, just the Printer module) to verify that the operands that are referenced by objects in the module definition windows are defined in the dialog design window, the operands referenced in the user view window are defined, etc.

If you correctly followed the instructions for building the Printer module, you should receive a message that the .tpo file was generated successfully. However, if your module definition contains an error, an Arena error window will be displayed containing a description of the error. For example, if you mistyped the operand reference (`Print Time`) in the logic window’s Delay module as `Printing Time`, the error message “Referenced operand not defined: `Printing Time`” is displayed in the error window. You can use the Edit button to correct the error; it opens the appropriate window (in this case, the logic window) and displays the dialog for the object containing the error (i.e., the Delay module instance). You can type the correction in the dialog and select OK, then generate the .tpo file.

Warnings, on the other hand, do not have to be resolved. The .tpo file will generate successfully regardless of whether you choose to address the warnings. This, of course, has nothing to do with the correctness of your module definition; the .tpo file will still be generated successfully.

After you have successfully generated a template panel object file, you can use the Printer module in a simulation model to test its logic, animation, and so on. In the following section, we present a simple model containing a single printer.

Single printer simulation modelOur 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 ENTITIES—THE CREATE MODULE

To build the model, begin by opening a new model window. The first two modules to be placed are Create modules from Arena’s Basic Process panel, which is automatically attached. Place two Create module instances in the model; the first will generate Entity 1 jobs and the second, Entity 2 jobs.

To define the characteristics of the Entity 1 job arrivals, edit the first Create module. Name the module Entity 1 Jobs and specify that the time between arrivals is contant with a value of 1 minute. The second Create module instance requires similar information. Enter a name, Entity 2 Jobs, the time between arrivals is constant, arriving every 10 minutes. Change the Entity Type field to Entity 2 and change the

59


• •

• •

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

Figure 3.27 Create module dialog for Entity 1 jobs

Figure 3.28 Create module dialog for Entity 2 jobs

PROCESSING THE PRINT JOBS—THE PRINTER MODULE

To use the Printer module you have defined, you need to attach a second panel—the template panel object file you generated—to the Project Bar. Attach the panel and select the .tpo file you named earlier (e.g., HSPrint.tpo).

Note: If the file you created does not appear in the list, you may have forgotten to generate the .tpo file after correcting errors. Open the template window and click on the Generate toolbar button to create a template panel object file.

60



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 JOBS—THE DISPOSE MODULE

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

SIMULATION PROJECT AND RUN LENGTH INFORMATION—THE RUN > SETUP MENU Before initiating a simulation run, select the Run > Setup option. The Project Parameters and Replication Parameters tabs allow you to identify the project information and to establish a run length. For the pilot run, the length of the simulation run is arbitrary, since constant times were used for interarrival and delay times; enter a value of 8 for the Replication Length to simulate an eight-hour workday. Change the Base Time Units field to minutes, since the entity arrival, changeover and print times are specified in minutes.

Also, because the start of the simulation will include an extra changeover (to initialize the printer for printing Type 1 jobs), specify a Warm-up Period of 10 minutes. By starting the collection of statistics at time 10, the simulation run will include predictable cycles of processing 11 entities in 10-minute cycles (i.e., 10 Entity 1 jobs and one Entity 2 job). With a changeover time of .2 minutes, we can predict that the changeover tech will be used 4% of the time. This is calculated by two changeovers (at .2 minutes / changeover) every 10 minutes (one changeover to Entity 1, another to Entity 2) with a total time of .4 every 10 minutes. With a printing time of .5 minutes, we can predict that the percent of time that the printer is actually printing should be 55% (i.e., there should be 5.5 minutes—11*0.5—of printing for every 10 simulation minutes). Remember that the printer resource is also busy during the changeover (or 4%), so the total Busy time (including printing and changeover) should be 59%.

VERIFYING THE MODULE LOGIC

To test the logic for the Printer module, it is useful to step through the simulation model for the first few events (using the Step button on the Run toolbar), just as you might do to verify a model built using modules from other template panels.

The first event in the simulation run will be an arrival of an Entity 1 job entity. The initial value for the variable that stores the last job type processed on the printer is 0 (the default initial value for any general-purpose variable), so as you step through the first entity’s processing, you should see a changeover event take place (the animation picture for the global picture should show the Changeover Tech during the changeover) to set up the printer to process Entity 1 jobs. After the changeover is complete, the job type variable changes to a value of 1. The resource picture shows busy during both the changeover and printing time, as it is not available during the changeover time. Figure 3.31 shows the animation of the Printer module during the first changeover.

62



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


• •

• •

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

64

4 • The Template W

indow

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

A template panel simply is a file containing a library of module definitions. The template window, displayed by creating a new template document or opening an existing one, is a base window from which new modules are defined. From the Template Development toolbar, you can then access the five module definition windows—dialog design, logic, switch, user view, and panel icon—that constitute a module.

The mechanisms used to define modules in a template panel file are described in the chapters: Dialog Design Window, Logic Window, User View Window, Switch Window, and Panel Icon Window. This chapter describes the options and actions that are provided by the template window.

The template menu

Creating a new template windowThe 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 fileTo 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 templateIf 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 fileTo save the .tpl file, choose File > Save from the main menu bar.

Creating and editing modules

The module definitions listTo 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• • • • •


indow

Opening module definition windowsEach 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 warningsTo 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.

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

67


• •

• •

68

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 errorsIf 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 reportsArena 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



indow

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) fileOnce 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 versionThe Version entry in the template window is designed to help you record updates that you may make to the template panels you create.

70



indow

Template optionsA 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 panel’s .tpo file as well. The utlarena.tpo file that is distributed with Arena is a private panel. It is described in “The Logic Window” chapter.

71


• •

• •

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 modulesThe 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



indow

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 modulesAnother option in a module’s 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 operandYet another option in a module’s Module Definition dialog is the Name Operand field. If you choose an operand from a module to be designated as the module’s Name Operand, Arena will enforce uniqueness for the value of that operand. For example, if a module called Process defines an operand called Process Name as its Name Operand, a user

73


• •

• •

building a model with multiple Process modules must give unique Process Names or an error will result.)

Although it is available for both logic and data modules, the Name Operand field is particularly useful for data modules, mainly in conjunction with the Auto-Create option of another module. If an operand from another module auto-creates a data module, the value of the operand is passed to the data module’s Name Operand. For example, if a data module called Resource has a Name Operand called MyName, and another module called Process has a ResName operand that auto-creates the Resource data module, the value of the Process module’s ResName will be passed to the Resource module’s MyName operand.

The operand specified in the Name Operand field must first be defined in the dialog design window. Also, it must be visible (generally, it is displayed in the spreadsheet) and is non-repeatable. Dialogs and Repeat groups may not be specified in this field.

Expression Builder Definitions The Expression Builder Definitions button opens a dialog that allows you to define expression builder strings for the module definition. The expression strings will then be available in the Expression Builder tree-view if a module instance is placed in the model.

See the online help topics “The Expression Builder” and “Expression Builder Definitions” for more information.

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

74



indow

change the definition of either the Customers or Tellers module (by changing the dialog design, logic, switch, user view, or panel icon windows).

Examples of changes you may make to existing modules include: adding new operands, removing obsolete operands, changing operand types from Element to Basic (or from any type to any other type), changing repeatable data into non-repeatable data (by removing the repeat group object), and many other. We make every attempt to use the data in exist-ing operands with the new module structure. However, data in obsolete operands will be discarded.

When you are creating a module and cycling back and forth between editing the definition and placing the module in a simulation model (to test it), we recommend that you work with a new model window whenever you modify the template panel file. Or, if you have established a model window and want to retain the other modules you have placed, delete the module instances that are from your template panel and detach the template panel from the Project Bar using the File > Template Panel > Detach menu item or by right-clicking on the panel tab and choosing Template Panel >Detach from the shortcut menu that appears. Then re-attach the .tpo file after you have completed your edits to the tem-plate panel file.

75


• •

• •

76

5 • Dialog Design Window

5 The Dialog Design WindowAn important part of a module definition is the user interface, which is the visual part that a modeler sees when opening a module’s dialog or viewing a module’s fields in the module spreadsheet.

The dialog design window is Arena’s interface for designing the dialog structure and dialog form layout(s) of a module. In this window, a module designer defines dialog sizes, data displayed to and entered by the user, default and permissible values, and interface controls.

The first part of this chapter gives an overview of the dialog design window interface. The second part of this chapter describes the user interface controls available to define dialog form, operand, and repeat group objects in the module definition and get user input and display output.

The third and fourth parts of this chapter describe topics related to operand and repeat group objects in more detail.

The fifth and sixth parts of this chapter describe the use of accelerator keys and the Dialog Design toolbar.

Dialog Design Window overviewThe dialog design window is opened by selecting a module (in the template window’s Module Definitions list), and then selecting the Window > Dialog Design menu item or clicking the Dialog Design Window button on the Template Development toolbar.

The dialog design window displays the dialog form layouts for the module. Its interface includes an Operand Explorer section to browse all of the dialog form, operand, and repeat group objects in the module definition; a Toolbox section to add user interface controls to dialog forms; and a Design Properties grid to edit the properties of one or more selected objects.

77


• •

• •

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

Figure 5.1 The Operand Explorer

The root node of the explorer tree is the module’s main dialog form. This is the dialog that is first displayed when the modeler double-clicks on an instance of the module in a model or logic window.

The dialog form, operand, and repeat group objects that define the structure of the module’s interface are then displayed within the explorer tree according to the specified hierarchical relationships. The objects are displayed using the string format TabIndex: ObjectName [SwitchName]. The dialog or repeat group object highlighted in bold indicates which dialog form layout is currently open in the window.

Within the explorer tree, you may select, delete, cut, copy, and paste objects. Objects may also be dragged and dropped graphically within the tree to change the hierarchical relationships. Double-clicking on an object in the tree will automatically open the dialog form associated with the object and then select the object. You may also click the View Dialog Form button ( ) to perform this action.

78

5 • THE DIALOG DESIGN WINDOW• • • • •


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

DIALOG FORM OBJECTS

A module definition will contain one or more dialog forms to display choices and accept input from modelers into instances of the module.

By default, every module has a main dialog form. This is the dialog that is first displayed when the modeler double-clicks on an instance of the module in a model or logic window.

In some cases, there may be too much information to place in a single dialog. You may add a new secondary dialog form object to “nest” information by placing a DialogButton control from the Toolbox onto a dialog form’s layout.

OPERAND OBJECTS

An operand object is an object in the module definition that contains a single value and (if not disabled or hidden) is editable via a user interface control by the template user. For example, in the Stop module of Arena’s Advanced Transfer panel, there is an operand for the module’s Name field, and an operand for the module’s Conveyor Name field.

You can add operand objects to a module definition by placing user interface controls such as a TextBox control or CheckBox control from the Toolbox onto a dialog form’s layout.

Hidden operands. Note that, in some cases, it may not be desirable for a particular operand to ever be made visible to the module’s user. The operand exists solely to store a piece of data for internal logic purposes and thus is always “hidden” from the user. The HiddenOperand control from the Toolbox is used to add a hidden operand object to a module definition.

REPEAT GROUP OBJECTS

A module may allow the capability to define a list of multiple (or repeatable) fields. For example, the Assign module from Arena’s Basic Process panel allows you to assign values to a list of variables, attributes, etc. The Assignments list box in the Assign module is known as a repeat group.

You add repeat group objects to a module definition by placing a RepeatGroupDialog or RepeatGroupTable control from the Toolbox onto a dialog form’s layout. Use the RepeatGroupDialog control if the repeating data is to be entered using a secondary dialog form. Use the RepeatGroupTable control if values for a single repeatable field are to be entered into a table.

79

mk:@MSITStore:C:\Source\Current%20Release\Win32Bin\Debug\ARENA.CHM::/DIALOGDESIGN_PROPERTY_SWITCHEDOUTACTION.htm



mk:@MSITStore:C:\Source\Current%20Release\Win32Bin\Debug\ARENA.CHM::/ID_WINDOW_SWITCHES.htm


• •

• •

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

Figure 5.2 The Toolbox

To add a control from the Toolbox, first click on the desired control in the Toolbox section. Then, hover the pointer over the location in the dialog form where the control is to be placed. The pointer will change to a cross hair with the selected control’s icon displayed at the top and right of the cross hair.

Controls are placed in the dialog form by one of three methods. Once your control has been selected, you can simply click on the form to place the control wherever you wish. Alternatively, you can click and drag to size the control as you place it (the control is placed when the button is released). The third placement method is to perform a simple drag-and-drop directly from the Toolbox to the dialog form.

80



The dialog formA dialog form is a rectangular bit of screen real estate that presents information to the user and accepts input from the user. The user interface of a dialog form is defined by placing controls from the dialog design window’s Toolbox onto the form’s surface.

When the dialog design window for a module definition is opened, by default the main dialog form of the module is displayed in the center of the window. This is the dialog that

Table 5.1 Summary of Toolbox controlsControl Name Description

Text Used to display a simple text string on a dialog form.

GroupBox Used to draw a box around and thus provide an identifiable grouping for other controls.

Line Used to draw simple line segments on a dialog form.

TextBox Used to get input from the user or to display text.

ComboBox Used to display and edit data in a drop-down combo box.

RadioButtonGroup Used to present a set of two or more mutually exclusive choices to the user. The choices are presented in a matrix of buttons.

CheckBox Used to indicate whether a particular condition is enabled. Gives the user a choice between two values such as “Yes/No,” “True/False,” or “On/Off.”

DialogButton Used to provide a button that the user clicks to display another dialog form.

RepeatGroupDialog Used to allow a user to enter values for multiple (or repeatable) sets of fields via a secondary dialog.

RepeatGroupTable Used to allow a user to enter values for a single repeatable field into a table.

DateTimePicker Used to provide an interface through which to exchange date and time information with a user.

DatePicker Used to provide an interface through which to exchange date information with a user.

TimePicker Used to provide an interface through which to exchange time information with a user.

FilePicker Used to provide an interface for entering an operating system file name.

HiddenOperand Used to define an operand object that is hidden from the modeler (i.e., not displayed in the module dialog).

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 definition’s dialog design may contain more than one dialog form. For example, in addition to the main dialog, the interface may include one or more secondary dialogs accessed via DialogButton and/or RepeatGroupDialog controls.

To open the dialog form associated with or containing a particular object in the module definition, double-click on that object in the Operand Explorer. Or, alternatively, you may select an object in the Operand Explorer and use the View > Dialog Form menu item or click the View Dialog Form button ( ).

Double-clicking on a DialogButton or RepeatGroupDialog control in a dialog form layout will also automatically open the dialog form associated with that control.

82



RESIZING A DIALOG FORM

To resize a dialog form graphically, first click anywhere on the form to select it. Then, click and drag one of the sizing handles that appear on the border of the form. The sizing handles look like small black boxes, and the pointer turns into a double-headed arrow when you point at the handle.

You may also enter specific dimension values for a dialog form by selecting the form and then editing the Height and Width properties in the Design Properties grid.

ARRANGING CONTROLS ON A DIALOG FORM

Controls that have been placed onto a dialog form’s surface may be graphically selected, moved, and resized.

Multiple controls may be easily layered, aligned, equally sized, or spaced using menu commands available from the Format menu.

You may also use the View > Grid, View > Snap to Grid, and View > Snap to Objects menu commands to enable/disable grid and snapping features that help manage control locations on a form.

LOCKING CONTROLS ON A DIALOG FORM

When designing the user interface on a dialog form, you can lock the controls once they are positioned correctly so that you do not inadvertently move or resize them.

Use the Format > Lock Controls menu item to lock a dialog form’s controls. Locking controls prevents them from being dragged to a new size or location on the form’s surface. However, you can still change the size or location of controls by means of the Design Properties grid.

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

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 controlsThis section describes in more detail each of the user interface controls available in the dialog design window’s Toolbox.

Using the Text controlA Text control may be used to display a simple static text string on a dialog form. The text cannot be edited by the user.

In the Design Properties grid, the Text property specifies the text string displayed by the control. If the text entered exceeds the width of the control, the text wraps to the next line and is clipped if it exceeds the control’s height.

84



Using the GroupBox controlA 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 controlA 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 controlA TextBox control adds an operand object to the module definition. The control may be used to get input from the user or to display text.

A TextBox control has two portions: a prompt label and a box. You may graphically select, move, and resize the box and prompt label separately on the form using the mouse.

In the Design Properties grid, the Text property defines the prompt label of the text box. The Value property specifies the default string value for the text box. The data type that may be entered as a value is specified by the DataType property.

In general, a TextBox control is used for editable text, although you can make a text box read-only by setting the DisplayOnly property to True.

Within the module definition, operand object values may be referenced (by enclosing the operand object’s name in back quotes, e.g., Ò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 controlA 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 box’s drop-down list are defined by the List property. Set the PickFromListOnly property to True if you want to limit a user’s input to what is on the list. Otherwise, a user will be able to type choices not on the list into the combo box’s edit field.


Using the RadioButtonGroup controlA 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.


Using the CheckBox controlA 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.


Using the DialogButton controlA DialogButton control adds a secondary dialog form to the module definition, providing a button that the user clicks to display the form.

In the Design Properties grid, use the Text property to specify the caption text that appears on a dialog button.

To open the secondary dialog form associated with the DialogButton control, double-click on the control’s dialog form object in the Operand Explorer. Or, alternatively, you may select the object in the Operand Explorer and use the View > Dialog Form menu item or click the View Dialog Form button ( ).

Double-clicking on a DialogButton control in a dialog form layout will also automatically open the dialog form associated with that control.

Using the RepeatGroupDialog controlA RepeatGroupDialog control adds a repeat group object to the module definition. The control allows a user to enter values for multiple (or repeatable) sets of fields. Each set of the repeatable data is entered using a separate, secondary dialog form that is accessed by selecting the repeat group’s Add or Edit buttons. A data set is deleted from the repeat group using the Delete button.

In the Design Properties grid, use the Text property to specify the prompt label that appears at the top of the repeat group.

To open the secondary dialog form associated with the RepeatGroupDialog control, double-click on the control’s repeat group object in the Operand Explorer. Or, alternatively, you may select the object in the Operand Explorer and use the View > Dialog Form menu item or click the View Dialog Form button ( ).

Double-clicking on a RepeatGroupDialog control in a dialog form layout will also automatically open the dialog form associated with that control.

87


• •

• •

Using the RepeatGroupTable controlA RepeatGroupTable control adds a repeat group object to the module definition. The control allows a user to enter values for a single repeatable field into a table.

In the Design Properties grid, use the Text property to specify the prompt label that appears at the top of the repeat group.

A RepeatGroupTable control may be used only if there is to be exactly one operand field in the control’s repeat group whose value is editable by users (referred to as the RepeatGroupTableOperand). The repeat group may contain an unlimited number of hidden operands.

As an example, repeat group tables are used in the Elements panel for defining Initial Values for the Attributes and Variables modules and the Expression Values in the Expressions module.

To view or edit the properties of operand objects contained in a RepeatGroupTable control’s repeat group, double-click on the control’s repeat group object in the Operand Explorer. Or alternatively, you may select the object inthe Operand Explorer and use the View > Dialog Form menu item, or click the View Dialog Form button ( ).

Double-clicking on the RepeatGroupTable control in a dialog form layout will also automatically open the dialog form associated with that control.

Using the DateTimePicker controlA DateTimePicker control adds an operand object to the module definition. The control provides a simple and intuitive interface through which to exchange date and time information with a user.

A DateTimePicker control has two portions: a prompt label and an edit box. You may graphically select, move, and resize the prompt label and box separately on the dialog form using the mouse.

The control’s edit box has a down arrow to the right of the box (similar to a ComboBox control). A click on the arrow displays a calendar with the current date value circled. The modeler has the ability to change the date portion entered into the control by selecting either a different day within the current month or by using the calendar arrow keys to specify a different month.

To edit the time portion of the control, simply click on the hour, minute, second, or AM/PM text in the edit box. Then type or use the arrow keys to change a value.

In the Design Properties grid, The Text property defines the prompt label for the DateTimePicker control. The default date and time value for the control is specified in the

88



Value property. If the Value property is not specified, then the control’s default value will be the current date/time.


Using the DatePicker controlA DatePicker control adds an operand object to the module definition. The control provides a simple and intuitive interface through which to exchange date information with a user.

A DatePicker control has two portions: a prompt label and an edit box. You may graphically select, move, and resize the prompt label and box separately on the dialog form using the mouse.

The control’s edit box has a down arrow to the right of the box (similar to a ComboBox control). If the arrow is clicked on, a calendar appears with the current date value circled. The modeler has the ability to change the date by selecting either a different day within the current month or by using the calendar arrow keys to specify a different month.

In the Design Properties grid, the Text property defines the prompt label of the DatePicker control. The default date value for the control is specified in the Value property. If the Value property is not specified, then the control’s default value will be the current date.


Using the TimePicker controlA 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 control’s edit box has small up and down arrows to the right of the box. When the current time value is selected (using a small check box to the left of the time), the time value may be changed by highlighting the hour, minute, or second and using the up or down arrows to the right to increase or decrease the time.

89


• •

• •

In the Design Properties grid, the Text property defines the prompt label for the TimePicker control. The default time value for the control is specified in the Value property. If the Value property is not specified, then the control’s default value will be the current time.


Using the FilePicker controlA FilePicker control adds an operand object to the module definition. The control provides a simple interface for entering an operating system file name.

The FilePicker control displays an edit box with a browser (…) to the right of the box. Users may enter a valid file name or click on the browser to search for the file.

A FilePicker control has two portions: a prompt label and an edit box. You may graphically select, move, and resize the prompt label and box separately on the dialog form using the mouse.

In the Design Properties grid, the Text property defines the prompt label of the FilePicker control. The default file name for the control is specified in the Value property.

Use the Filter property to specify the file filters to display in the control’s Browse for File dialog (i.e., the choices in the Files of type drop-down list). Enter a filter string using the format Description1|Pattern1,Description2|Pattern2, etc.

The following is an example of a filter string: "All Files|*.*,Text Files|*.txt".

You can define several filter patterns for a filter description by separating the file types with semicolons. For example:

"Image Files(*.BMP;*.JPG;*.GIF)|*.BMP;*.JPG;*.GIF,All Files (*.*)|*.*"


90



Using the HiddenOperand controlA HiddenOperand control adds an operand object to the module definition. The control is used to define an operand object that is hidden from the modeler (i.e., not displayed in the module dialog).

A hidden operand is normally used to store data that is necessary for the module’s logic, but which isn’t necessary, desirable, or permissible for the modeler to view.

In the Design Properties grid, the Value property of a hidden operand must be specified (except entry and exit points); otherwise, there is no way for information to be stored in the operand.


Using operandsMany of the user interface controls described in the previous section, such as the TextBox, ComboBox, and CheckBox controls, represent operands in the module’s dialog design. An operand is a single value that is important for module display or logic purposes.

This section describes in more detail some operand-related properties and issues.

Specifying the Name propertyAll operand objects have a Name property available in the Design Properties grid. This property is a unique identifier string for the operand. The Text property that is displayed graphically in the dialog form automatically defaults to the Name of the operand.

An operand’s name may be used (by enclosing the name in back quotes, e.g., Òperand1`) to reference the operand’s value in the Value property of another operand, in an animation object in the user view window, in a field of a module instance in the logic window, or in a switch definition string.

The maximum length of a name is 31 characters, and it must be specified using alphanumeric characters.

91


• •

• •

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

Figure 5.5 The Logic Properties dialog for an operand object

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

BASIC OPERAND

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

ELEMENT OPERAND

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

If the Type is specified as “Element,” then the following fields are displayed in the Logic Properties dialog:

Element Type—The type of SIMAN element that the operand will define/reference. Select the desired type from the list. The operand’s value will then be used as the name of the element of the selected type (e.g., an operand with value “Operator” will define or reference a SIMAN element with name “Operator”).

92



Sub-list—The sub-list partition of elements (by Element Type, such as resource) of which this operand’s element is to be a member. For example, the element type Resources might have sub-lists for Operators and Machines.

Define/Reference—Indicator whether the element that is created by this operand should be defined for the simulation model or whether it only should be referenced. If Referenced is selected, then some other module must define the element that is referenced by this module. This typically is used when incomplete property information is definable in a module.

For more information on the use of elements and their properties, see the chapter “Elements” on page 177.

PROPERTY OPERAND

An operand may be used to represent the value of a SIMAN element’s property, such as the capacity type of a resource.

If the Type is specified as “Property,” then the following fields are displayed in the Logic Properties dialog:

Element Operand—Name of the operand that is defining the SIMAN element in this module of which this property operand is associated.

Element Type—Type of SIMAN element defined/referenced by the Element Operand. This field may not be edited; it is provided for information only.

Property Name—Name of the element property that this operand defines, selected from a list of valid properties associated with the Element Type.

Read Only—This option is available for HiddenOperand controls only. If enabled, the hidden operand will simply read into its value the current value of the element property with which it is associated. The element’s property value will NOT be overwritten by the operand’s default Value entry. The default value defined for the hidden operand will only be written to the element’s property value if that property has yet to be defined (i.e., the current value of the property is null).


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 module’s 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 operand’s DataType property is automatically restricted to the Label data type.

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

EXIT POINT OPERAND

An exit point operand defines an exit for entity flow out of the module. When you define an exit point operand, a graphical exit point (triangle shape) is placed in the user view window for the operand so that it may be connected graphically to the entry point of another module.

There may be multiple exit point operands in a module definition. For example, you may design a module that performs an inspection-type process, in which case, two exit points may be required, one for entities that pass inspection, and one for entities that do not pass inspection. Exit points also may be repeatable, as can be seen in the Decide module of the Basic Process panel. A repeatable exit point (i.e., the exit point operand is associated with a repeat group object in the module definition) has a different graphical representation in the user view than a single exit point, as can be seen in Figure 5.6.

Figure 5.6 Decide module with repeatable exit points

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

ENTRY/EXIT POINT VALIDATION AND REFERENCE

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

94



more information on entry and exit types and connection validation. The Tables appendix also provides information on where various entry and exit types are used.

When a graphical connection is made between modules, Arena automatically creates and stores unique entry and exit label information. An entry label value, usually an integer with a dollar sign (e.g., 123$), is created for the module to which the entity is to be sent. The module from which the entity is sent is given that same exit label value.

Entry and exit point operands may have switches attached to them. If an entry or exit point has a switch and the operand is switched out, the operand’s field will not appear in the module’s dialog and the graphical symbol will not appear in the module’s user view.

Entry and exit point operands may also be hidden operands (i.e., added to the module definition using HiddenOperand controls). In this case, a field corresponding to the operand is not visible to the modeler in the module’s dialog; however, the graphical representation of the entry or exit point still appears, offering a way to connect graphically into and out of the module.

Note: If an entry or exit point is defined as hidden, there is no way to reference that operand if the module is used hierarchically.

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

AUTO-CREATING MODULES

The Auto-Created Module feature allows a module designer to specify that a new, separate data module will be added automatically to the model using this operand. When used, the operand’s value is passed to the data module’s Name Operand. Note that the auto-creation only takes place for non-blank values of the operand.

For example, if a data module called Resource has a Name operand (specified in the Module Definition dialog) called Name, and another module called Process has a Resource Name operand that auto-creates the Resource data module, the value of the Process module’s Resource Name will be passed to the Resource module’s Name operand, as long as Resource Name is not blank.

In general, operands that use the Auto-Created feature should be defined as Element-type operands. This ensures that the data module has at least two references in the model, as data modules with only one reference are normally purged (i.e., deleted) from the model (see below). Also, they should be set to use the Reference option, as opposed to the Define option, as the data module itself should be set to use the Define option.

To use the Auto-Created feature, click the available Settings button for module auto-creation in the Logic Properties dialog, then specify the Template Name and Module Name

95


• •

• •

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 propertyAll operand objects have a Value property available in the Design Properties grid. This property specifies the initial, default value of the operand when an instance of the module is created. Default values may be literal, may reference other operands, or may be a combination of the two.

The acceptable data type for an operand’s value that may be entered by a user is specified using the DataType property. The data type property is described in more detail beginning on page 99.

It is not possible to have a blank value for an operand that has a default value specified in the dialog design. When editing a module, if a modeler blanks out an operand that has a default value, the default value will reappear when the user tabs out of this field.

REFERENCING THE VALUE OF ANOTHER OPERAND

The value stored in another operand object may be referenced by entering the operand’s Name enclosed in back quote characters (`). When a modeler places and edits an instance of a module containing referenced operands, all operand values are updated dynamically as editing takes place.

For example, suppose that a module contains operands Server Name and Server Resource, and the Server Resource operand’s Value property has been specified in the dialog design as `Server Name`_RES, then any changes to the operand Server Name will be reflected in the Server Resource field. Thus, if the value of Server Name is specified as “Fred,” the value of Server Resource will be “Fred_RES.”

If a referenced operand is switched out, then its value is null.

96



COMBINING REPEATING OPERAND VALUES INTO A SINGLE VALUE

When designing a module, you may define a repeat group object that contains a set of repeatable operands and then have those repeating operand values combined into a single, merged value string. The single value will be returned if you enter the repeat group dialog or repeat group table object name in back quote characters (`) in the Value property of an operand.

This topic is discussed in more detail in the “Using repeat groups” section on page 102.

SPECIAL REFERENCEABLE FUNCTIONS

A set of special functions is available that will provide, in an operand’s default Value, information such as the unique identifier of a module instance or the number of repeating sets of data stored in a repeat group.

A special function is referenced by entering the function name enclosed in carat characters (^). Table 5.2 summarizes the available special functions.

Note that some of the functions available may be used to access information entered into the Project Parameters and Replication Parameters tabs of a model’s Run > Setup dialog. Typically, this might be done in a module designed to overwrite the standard simulation parameter defaults and reorganize the options for the end user. If a module that writes out different values for the Project and Replicate elements is placed in a model, those values will override any settings made in the Run > Setup dialog.

Table 5.2 Special functionsFunction Description

^Module_ID( )^ Returns a unique identifier string for the module in the form Module Definition Name [Instance Number]. For example, “Create 5.”

^Module_Name( )^ Returns the module definition name of the module. For example, “Create.”

^Module_Number( )^ Returns the instance number of the module in the model. For example, “5.”

^TIME_TO_BASE_TIME(TimeValue, TimeUnits)^

Converts a time value of time units into a time value of base time units (as specified in Run > Setup > Replication Parameters).

^RATE_TO_BASE_RATE(RateValue, TimeUnits)^

Converts a rate value of time units into a rate value of base time units (as specified in Run > Setup > Replication Parameters).

97


• •

• •

^Line_Number()^ Returns the index into the repeating sets of data of the repeat group.

^Num_Lines(Repeat Group Name)^ Returns the number of repeating sets of data in a repeat group.

^Project_Title()^ Provides access to the title of the simulation project, as taken from the Project Parameters page.

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

Ûse_Costing()^ Provides access to the check box (Yes, No) for turning on and off costing calculations for the simulation model, as taken from the Project Parameters page.

Ûse_Entities()^ 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.

Ûse_Resources()^ Provides access to the check box (Yes, No) for turning on and off resource statistics for the simulation model, as taken from the Project Parameters page.

Ûse_Tanks()^ Provides access to the check box (Yes, No) for turning on and off tank statistics for the simulation model, as taken from the Project Parameters page.

Ûse_Queues()^ Provides access to the check box (Yes, No) for turning on and off queue statistics for the simulation model, as taken from the Project Parameters page.

Ûse_Transporters()^ Provides access to the check box (Yes, No) for turning on and off transporter statistics for the simulation model, as taken from the Project Parameters page.

Ûse_Conveyors()^ Provides access to the check box (Yes, No) for turning on and off conveyor statistics for the simulation model, as taken from the Project Parameters page.

Ûse_Processes()^ Provides access to the check box (Yes, No) for turning on and off process statistics for the simulation model, as taken from the Project Parameters page.

Ûse_Stations()^ Provides access to the check box (Yes, No) for turning on and off station statistics for the simulation model, as taken from the Project Parameters page.


98



Specifying the DataType propertyAll operand objects have a DataType property available in the Design Properties grid. This property specifies the acceptable data type of the operand’s Value property.

Data types define what a user is permitted to enter for an operand value. When a user clicks OK in a module’s dialog, the value entered for each field is checked against the operand’s data type to determine whether the value entered is valid. If the entry isn’t valid, an error will appear and the pointer will move to the offending operand field.

Ûse_ActivityAreas()^ Provides access to the check box (Yes, No) for turning on and off activity area statistics for the simulation model, as taken from the Project Parameters page.

^Number_of_Replications()^ Provides access to the number of replications for a project, as taken from the Replication Parameters page.

^Replication_Length()^ Provides access to the length of the simulation run, as taken from the Replication Parameters page.

Înitialize_System()^ Provides access to the check box (Yes, No) for initializing the system between simulation replications, as taken from the Replication Parameters page.

Înitialize_Statistics()^ Provides access to the check box (Yes, No) for initializing the statistics between simulation replications, as taken from the Replication Parameters page.

^StartDateTime()^ Provides access to the start date and time of the simulation, as taken from the Replication Parameters page.

^Warm_up_Period()^ Provides access to the length of time for the warm-up period, as taken from the Replication Parameters page.

^Terminating_Condition()^ Provides access to the terminating condition that may end a simulation run, as taken from the Replication Parameters page.

^Hours_Per_Day()^ Provides access to the number of hours per simulated day, as taken from the Replication Parameters page.

^Base_Time_Units()^ Provides access to the base time units used for the simulation clock TNOW and all time conversions, as taken from the Replication Parameters page.


99


• •

• •

Depending on the control type, an operand’s data type may or may not be changeable by the template designer. For example, the data type of a CheckBox control is strictly “YesOrNo.”

Module designers should ensure that their operands do not define a less restrictive data type than the logic window fields that reference the operand. For example, if you have a module in the logic window that only accepts real values for a particular field, then the operand that is referenced in that field should be either a real data type or one that is more restrictive (e.g., integer).

The available data types are now described.

STANDARD DATA TYPES

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

AnyCharacter—Allows any string of keyboard characters.

Expression—Allows any valid numeric expression. It can contain combinations of letters, numbers, and standard arithmetic operators. An expression data type may contain both mathematical and logical expressions.

Integer—Allows any valid non-negative integer value. Note that if a data type is specified as Integer or Real, you may specify minimum and maximum limits for the operand.

Label—Allows any alphanumeric characters plus the special characters “@,” “_,” “%,” and “#.” Must contain at least one special character or letter. (Should not contain only numeric characters with single “e” or “E,” which could confuse it with a number written in scientific notation.)

Real—Allows any positive or negative real value. Note that if a data type is specified as Integer or Real, you may specify minimum and maximum limits for the operand.

SymbolName—Allows any alphanumeric characters plus the special characters “@,” “_,” “%,” and “#.” Must contain at least one special character or letter. (Should not contain only numeric characters with single “e” or “E,” which could confuse it with a number written in scientific notation.)

Note: Symbol names may have an unlimited length, but only the first 255 characters of a symbol name are actually considered when evaluating an expression.

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

SIMAN DATA TYPES

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

100



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 propertyAll objects have a SwitchName property available in the Design Properties grid. This property specifies the switch attached to the object. When the switch’s condition is “False,” the object will be disabled or hidden in the dialog according to the SwitchedOutAction property.

Switches are defined in the Switch window. See “The Switch Window” on page 169 for more information on switches.

If a referenced operand is switched out, then its value is null.

A switch may also be attached to or detached from an object by using the Object > Switch > Attach or Object > Switch > Detach menu commands.

Specifying the InUserView propertyAll operand objects have an InUserView property available in the Design Properties grid. This property allows an operand value to be displayed in the module’s user view.

The InUserView property is helpful when you want the modeler to see information about a module’s operand values without opening the module’s dialog.

Hidden operandsIn some cases, it may not be desirable for a particular operand to ever be made visible to the module user. The operand exists solely to store a piece of data for internal logic purposes and thus is always “hidden” from the user. The HiddenOperand control from the Toolbox may be used to add a hidden operand object to a module definition.

Entry and exit point operands can be defined using the HiddenOperand control. In this case, there will not be a field to specify an entry or exit label in the module’s dialog. However, a graphical representation of the connection point will still appear in the module’s user view, allowing users to connect into or out of the module.

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 groupsA module may allow the capability to define a list of multiple (or repeatable) fields. For example, the Assign module from the Basic Process panel allows you to assign values to a list of variables, attributes, etc. The Assignments list box in the Assign module is known as a repeat group.

You add repeat group objects to a module definition by placing RepeatGroupDialog or RepeatGroupTable controls from the Toolbox onto a dialog form’s layout. A RepeatGroupDialog control is used if the repeating data is to be entered using a secondary dialog form. A RepeatGroupTable control is used if values for a single repeatable field are to be entered into a table.

This section describes in more detail some repeat group-related properties and issues.

Specifying the Name propertyAll repeat group objects have a Name property available in the Design Properties grid. This property is a unique identifier string for the repeat group.

The maximum length of a name is 31 characters, and it must be specified using alphanumeric characters.

A repeat group’s name is referenced when using the Num_Lines function or when merging repeating operand values into a single value. These uses are discussed in the “Accessing the number of tuples and the tuple number” on page 105 and “Combining repeating operand values into a single value” on page 106.

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

102



Figure 5.7 The Logic Properties dialog for a repeat group object

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

BASIC REPEAT GROUP

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

PROPERTY REPEAT GROUP

A repeat group may also be used to write values to a SIMAN element’s property. The property must be a repeatable property. For example, a repeat group may be used to write values to the Members property of a SETS element (as multiple members may be defined within a set), but not the Capacity or Schedule property of a RESOURCES element.

If the Type is specified as “Property,” then the following fields are displayed in the Logic Properties dialog:

Element Operand—Name of the operand that is defining the SIMAN element in this module of which this property repeat group is associated.


Property Name—Name of the element property that this repeat group defines, selected from a list of valid repeatable properties associated with the Element Type.


103


• •

• •

Repeat group definition depth and reference rulesWhen 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 numberAs 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 module’s dialog design.

105


• •

• •

106

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

Combining repeating operand values into a single valueWhen 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.

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 object’s value with respect to other object values contained in the same repeat group and is specifically used for determining value order when combining a repeat group’s repeating operands into a single, merged value string.

In this example, the operand values should be merged in the following order:

TupleSeparatorCumulativeProbabilityPairSeparatorCustomerType

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 groupsThe 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 keysAn 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 toolbarWhile working in the dialog design window, you might find it useful to display and use the controls associated with the Dialog Design toolbar. The toolbar contains controls for formatting and viewing objects placed in the window. The controls are also available from the View, Format, and Object menus.

To hide or display the Dialog Design toolbar, choose View > Toolbars > Dialog Design or right-click on any visible toolbar and choose Dialog Design from the list.

108

6 • Logic Window

6 The Logic Window

Simulation logic and module designThe heart of a module is its simulation logic. Entities arriving at a module instance during a simulation run may undergo a simple activity, such as a time delay, or a series of complex activities, such as docking at a shipyard or completing a full surgery operation. The designer of a module has complete control over the scope of the module logic. It is this aspect of module design that is most challenging and often most interesting.

For example, if your modeling activities are in the area of bulk food manufacturing, you might create a module that represents the arrival of raw materials from various sources to your manufacturing facility. To capture the pertinent aspects of this activity, you might need to represent the trucks that deliver the raw materials, the truck bays in the receiving area, the forklifts that unload pallets from the trucks, and the personnel who unwrap the palletized materials and transfer them to a storage area. One approach might be to build a Raw Material Receiving module that captures all of these activities, from trucks arriving at the facility to the storage of the raw material for use in manufacturing. Another approach might separate the receiving operation into three individual modules: Truck Arrivals, Truck Unloading, and Transfer to Storage. Or you might design modules for each step in the process, resulting in three individual modules representing the truck arrival process: Truck Entry, Bay Selection, and Docking.

Note that the decomposition of this activity could naturally be represented using Arena’s hierarchy. No matter what design you select for the modules, you will need to model each of the lowest-level activities (e.g., entry of trucks to the facility, selection of a truck bay, docking at the truck bay). You could first create modules to represent each of these activities, combine them into the middle-level activities (e.g., truck arrivals), and finally build the Raw Material Receiving module from the middle-level modules.

By using this approach, a modeler using this template will have the option of using the high-level module (Raw Material Receiving) or of representing the receiving process using the medium- or lowest-level modules. The additional work involved in creating modules at the three levels of decomposition primarily relates to the selection of module operands—to build a Truck Entry module, you must decide which options will be changeable (e.g., time between truck arrivals, truck type) by users of the module.

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

109


• •

• •

window in almost all respects; we discuss the differences between these two windows in the next section of this chapter.

To open a module definition’s logic window, select Window > Logic from the main menu bar, or click the Logic Window button on the Template Development toolbar. A sample logic window is shown in Figure 6.1.

Figure 6.1 Sample logic window for an Arriving Customers module

You interact with a logic window in the same way as you work with an Arena model window. To define the module logic, you attach template panels to the Project Bar, select modules, place instances of them in the logic window, connect the module instances, and provide values to their operands.

As you read this chapter, keep in mind that module instances can be placed in simulation models (i.e., in model windows that will be stored as Arena .doe files) or in module definitions (i.e., in logic windows of modules that will be stored in .tpl files). For simplicity, in most places we refer to the “modelers” placing instances of modules in “simulation models.” However, you should remember that instances may be placed in logic windows, as well.

The remaining sections of this chapter discuss the use of logic windows to define the simulation logic associated with a module definition. We do not present a discussion of the general interface for building Arena models. We assume that you are familiar with the steps involved in building models using Arena template panels.

The next section of this chapter highlights the major differences between model windows, which you use to build and run simulation models, and logic windows of module definitions. Following this, we present three sections that describe the main features of

110

6 • THE LOGIC WINDOW• • • • •

6 • 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 User’s Guide for information on attaching template panels, placing and editing modules, connecting modules, etc.

One capability that model windows have that is not offered for logic windows is the ability to conduct a simulation run. If you open a module’s logic window, you will notice that the Run toolbar is not visible.

To use the logic embedded in a module definition to perform a simulation run, you must first place an instance of the module in a model, then run the logic by simulating the model containing the module instance. Or you can test your module logic by first defining the logic in a model window, then using the clipboard to copy the verified logic to the module’s logic window. In this way, you have the advantage of using Arena’s Run Controller to interact with the module logic.

Referencing operands (logic window) Logic windows have a number of additional capabilities that are not provided by model windows. First, a module instance in a logic window may obtain values for its operands by referencing operands that are defined in the module definition’s dialog design window.

For example, a module that represents the unloading activity of a truck might include an operand defining the time to unload a pallet. This operand might be referenced by a Delay module instance (from Arena’s Advanced Process panel or from the Blocks panel) in the logic window to generate the appropriate time delay in the model logic. Each time an instance of this truck unloading module is placed in a model (or in another module’s logic window), a new value can be given to the unload time operand generating customized simulation logic. “Referencing module data” on page 114 describes this topic.

111


• •

• •

Switching module instances (logic window)When you are working in a logic window, you may attach switches to module instances. A switch is simply a construct that has a value of true or false, where the value of the switch is determined by the values of module operands and/or other module switches. (Refer to “The Switch Window” on page 169 for a description of how to define switches.)

In the logic window, switches are used to control alternatives for the model logic to be used when the modeler changes operand values. For example, in a module depicting a metal stamping machine, you might want to offer the option of counting the number of times that jams occur. If the modeler indicates that the count should be taken, a Count module from the Blocks panel would be “switched in” at the appropriate place in the module’s logic. However, if no count is to be taken, the Count module should not be included in that particular instance of the stamping machine module (i.e., it is “switched out”). This is described further in “Switches in logic window module instances” on page 121.

Defining repeatable logicTemplate 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 windowThe 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 windowWhile 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 • 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 can’t contain instances of modules that are defined in the same template.

Display of animation objects (logic window)When you place a module in a logic window, a complete instance is formed, just as would occur if you placed the module in a model window. However, because a logic window cannot be simulated directly, there is no need for animation in the window. So, Arena’s logic window, by default, does not display the animation objects that are part of a module instance.

If you place a module instance in the logic window that contains animation objects in its user view, these animation objects are placed in the logic window; they simply are not displayed by default. If you want to view the animation objects, you can use the View > Layers menu item to turn on the display of the various animation object types (e.g., levels, resources). In the logic window, we retain the animation objects that are part of module instance user views so that a module that is transferred between a model window and a logic window (via the clipboard) remains complete.

“Fields” and “operands”In this chapter, we discuss instances of modules in two contexts: the placement of module instances in a logic window (i.e., to create the logic for a module definition) and the use of the module that we defined (i.e., the creation of an instance of it in a model or another module’s logic window). We also have two contexts for the term operand: the item that is presented in the dialog of a module instance in the logic window and the operand defined by an object placed in the dialog design window of a module definition.

To remove confusion in this chapter about the term “operand,” we have chosen to use a different term, “field,” for the first context. So in this chapter, we refer to the items that appear in a module instance’s dialog as fields. We retain the term operand in its context as the object that is part of a module definition.

113


• •

• •

Referencing module data

Referencing operandsThe logic window defines the logic that will take place (controlling the creation, flow, and disposal of entities) when a simulation run is performed by a model containing an instance of the module. This logic may be very simple or highly complex. When a module is placed, the number and types of options provided to a user are defined by the dialog(s) containing the module’s operands.

The tie between the dialog design window and the logic window is established inside the logic window. In each module instance in the logic window, the values of operands from dialog(s) of the module being designed may be used in place of specific values. To establish this link, you simply type the name of the operand that you want to use and enclose the name between back quote characters (`). We refer to this as referencing an operand.

Note: Operand names are not case-sensitive. Embedded spaces are permitted.

Operand references also are allowed in the Value property of an operand definition and to define certain data for animation objects. “The Dialog Design Window” and “The User View Window” chapters describe the locations in which operand references can take place for operand default values and animation objects, respectively.

An operand reference dictates that when an instance of the module is created, the actual value of the field containing the reference is to be obtained from the modeler’s entry in the module’s dialog. Your selection of a module’s operands and the references to these operands in the logic window dictate the flexibility provided to a modeler for customizing the data and behavior of the module as it is used to represent different circumstances.

To illustrate a simple module reference, consider an Order Entry module that contains an instance of a Create module (from the SIMAN Blocks panel). In this module, you might want to ask the modeler to define the batch size of the order and the interarrival time for the orders to enter the system. To do so, you could define two operands in the dialog design window: Time Between Orders and Order Size. In the Create module instance that you place in the module definition’s logic window, you would reference the Time Between Orders operand to obtain the interval for the Create module and the Order Size operand to obtain the batch size, as depicted in Figure 6.2.

Each time a modeler places an instance of the Order Entry module, new values can be provided for the Time Between Orders and Order Size operands. For example, one instance of the Order Entry module might specify a Time Between Orders operand value of UNIF(5,10) and an Order Size of 10. In the underlying logic, these values would pass

114


6 • 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 definition’s logic window).

COMBINING MULTIPLE OPERAND REFERENCES IN A SINGLE FIELD

Multiple operands may be referenced in the same field of a module instance in the logic window. In this case, the values of the operands are simply concatenated to form the complete value for the logic window’s module instance. Also, text may be interspersed with operand references (as described previously).

For example, in the original module, Order Entry, you might decide to use a uniform distribution for the interarrival time of orders and simply ask the modeler for the minimum time and the maximum time. In this case, the Time Between Orders operand

116


6 • 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 modeler’s entries for the minimum time and maximum time replace the operand references (`Min` and `Max`, respectively) in the Create module.

Another case in which it is useful to reference multiple operands in a single field of a module is when a set of operands is provided to the user, but these operands are controlled by switches such that only one operand will be switched in for any given set of user inputs. (Refer to the chapter “The Dialog Design Window” for a description of attaching switches to operands. See “The Switch Window” for a discussion of switches and their definitions.) To define the logic window field for this type of reference, simply type each operand name enclosed in back quotes, one after the other.

In the Order Verification example module, perhaps you would like to design the module to offer the modeler a choice of specifying the time to check the order as either the name of an attribute that stores the time or as a particular time. This information will be used in a

117


• •

• •

Delay module (from the Blocks panel). The module’s dialog might contain a selection for the Time to Check with options of Time or Attribute. If the modeler selects Time, an operand named Time is displayed; if the modeler selects Attribute, an Attribute is displayed.

Figure 6.5 shows the dialog for an instance of the Order Verification module with the Time to Check selected to be Time. Figure 6.6 shows the same dialog with Attribute selected.

Figure 6.5 Order Verification module example, Time selection

Figure 6.6 Order Verification module example, Attribute selection

In Figure 6.5, the Time operand is displayed so that the modeler can define the time as a value (e.g., 2.5). The dialog in Figure 6.6 allows the modeler to define the time to check an order by selecting (from a drop-down list of attributes) an attribute that stores the value.

In the logic window for the Order Verification module definition, the Process Time field of the Delay module would be defined as `Time`Àttribute` (with no intervening spaces). The switched-in operand would supply its value to the Delay module; the

118


6 • 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 module’s user view. The same operand may be referenced from all three windows and/or from multiple objects within a window.

For example, if a resource is required to perform the order verification process, an operand Clerk Name would be added to the module. This would provide the name of the resource in a Process module. (We will discuss adding the Clerk Name to the Process module in “Referencing non-repeating operands from a repeat group” on page 125.) If a count is collected in the Order Verification module to record the number of incomplete orders each clerk detects, the Clerk Name operand in the module might be referenced in many places. The default value of another module operand that defines the counter name might reference the Clerk Name to form the base of the counter name (e.g., `Clerk Name`_Cnt). The Process module instance in the logic window contains the reference to

119


• •

• •

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 boxesWhile all references to module operands are made by enclosing the operand name in back quotes, a special mechanism is necessary for creating these references in the logic window when the field is displayed using a RadioButtonGroup or CheckBox control. (Refer to “The Dialog Design Window” or information about these control types.) CheckBox and RadioButtonGroup controls do not allow direct typing of values in a module instance’s dialog. Instead, a value is provided by selecting one of a predefined set of values. In the case of radio buttons, this is done by selecting a value; in the case of check boxes, the value is defined by checking the box for a value of Yes or clearing the box for a value of No.

To reference operands in these fields, Arena provides a special operand reference dialog. To open this dialog when you are editing a module instance in the logic window, place the pointer over any of the values in a RadioButtonGroup control or over a CheckBox prompt and click the right mouse button. The dialog that is opened allows you to type the operand reference for the radio button group/check box using any of the mechanisms described in this chapter.

Figure 6.8 shows an instance of a Dispose module from the Basic Process panel. The check box determines whether the entity statistics are generated. The dialog shown was opened by right-clicking on the Record Entity Statistics CheckBox control. A new module with an operand named Entity Statistics will provide the value of Yes or No to the Record module check box.

Figure 6.8 Operand reference for RadioButtonGroup and CheckBox controls

120


6 • 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 instancesAs you make changes to the values of fields in a module instance’s dialog in the logic window, some of the fields might control the display of other fields. For example, in an instance of a Record module (from the Basic Process panel), if you change the type from Count to Time Interval, the value and counter name fields are switched out and the attribute name and tally name fields are switched in.

If you define an operand reference in the field that controls the display of other fields, all fields that depend upon that value will be switched in. This is because the actual value of the controlling field (e.g., the Type field) will not be known until the module in which it is contained is placed in a model and a value is provided to the operand that is referenced.

In the case of the Record module example, this results in all of the operands that are controlled by the Type value being switched in and overlapping, as shown in Figure 6.9.

Figure 6.9 Record module instance dialog with reference in Type field

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

Defining transfer of entities into and out of a moduleIn 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 module’s logic window must contain a module instance that defines a station, such as the Station module from the Blocks panel. For example, in the Order Verification module discussed previously, we might want to design the module to allow entities to be routed to an order verification desk, which is represented in our module as a station. In the logic window, we could add a Station module prior to the Process module and reference a new operand, Order Desk, to establish the name of the station, as shown in Figure 6.10.

Figure 6.10 Station module instance in Order Verification module

Any entities sent to an instance of the Order Verification module by station transfer would enter at the Station module instance (in the underlying logic) and then proceed to the Process module.

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

122


6 • 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 module’s user view to allow modelers to connect modules together. The operand also can be displayed in the module dialog (often with a prompt of Label for entry points or Next Label for exit points).

In the logic window, you identify the module instance that corresponds to an entry point of your module by placing an operand reference in the appropriate field of the instance. For example, if you wanted to permit either direct transfer or station transfer into the Order Verification module, you could define a new entry point type of operand called Desk Label. In the logic window, this operand would be referenced by the Label field within the instance of the Station module (from Blocks panel), as shown in Figure 6.11.

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

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

123


• •

• •

by the Order Desk operand and/or connecting other module exit points to the entry point defined by the Desk Label operand.

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

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

Typically, the Delay module from Blocks can be used with a duration value of 0.0, as shown in Figure 6.12.

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

124


6 • Logic Window

Referencing non-repeating operands from a repeat groupThe 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 • Logic Window

127

Referencing repeating operandsThus far, we have discussed how to reference non-repeating operands from module instances in a logic window. It also is possible to reference repeating operands (i.e., operands that have been defined as members of a repeat group in the module’s dialog design window) from logic window modules. To reference a repeating operand, you enclose the name of the operand in back quotes, just as is done when referencing non-repeating operands.

To illustrate this, let’s consider our original Order Entry module. This module will be expanded to assign initial values to entity attributes and send the entities to the first activity involved in processing the order.

The dialog for the Order Entry module might be designed as shown in Figure 6.15. This dialog contains:

an operand for the Time Between Orders,

an operand for the Order Size,

an Attribute Assignments repeat group (with a tuple opened in the figure to show its operands) containing an Order Attribute operand defining the attribute to be assigned and a Value operand specifying the assignment value, and

a Next Activity operand that determines the activity to which the entity will be sent.

Figure 6.15 Order Entry module dialog


• •

• •

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

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, let’s return to the Order Verification module discussed previously. In this module, you might want to allow the incomplete order entities to seize an arbitrary number of operators (rather than two specific resources, as was designed in Figure 6.14) and to assign a new state to each operator resource after it is seized.

The new Order Verification module contains a repeat group with operands named Operator Name and New State. In the logic window, an instance of a Seize module is used to define the logic for seizing the required resources. The operand reference in the Seize module instance is shown in Figure 6.17.

Figure 6.17 Seize module instance with references

129


• •

• •

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

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 instance’s repeat group, and the value of the non-repeating operand is included in each tuple.

For example, if you want to modify the Order Verification module to seize an arbitrary number of resources, but you want to assign all of the resources the same new state value, you would use the same logic window as described previously (Seize and Assign with the same operand references). However, the Order Verification module would contain a repeat group with just the Operator Name operand. The New State operand would be non-repeating (i.e., in the module’s main dialog).

A modeler using an instance of this Order Verification module might define that two resources are required (Line A Refill Operator and Line A Supervisor), and might provide a value of Checking Incomplete Order for the new state field. In the logic window, two repeat group tuples would be created in each of the Seize and Assign module instances (because both reference the repeating Operator Name operand). In the Assign module instance, the state value, Checking Incomplete Order, would be placed in both assignment tuples.

Defining repeatable exit points in a moduleModules 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 lines—Condition Type (a radio button group with options of If and Else), Condition, and the Sort Line Label exit point operand. Figure 6.20 shows a sample dialog containing these operands.

Figure 6.20 Sort Orders module dialog

132


6 • Logic Window

In the logic window, the Process module references the Sorter Name and Sort Time operands. The Branch module’s Branch Types repeat group references the three repeating operands of the sortation line module—Condition Type (referenced by clicking the right mouse button on the If/With/Else/Always radio button group field), Condition, and Sort Line Label. This Branch module dialog is shown in Figure 6.21. Each time a modeler defines a new tuple in an instance of the Sort Orders module, a new tuple is created in the underlying Branch module and a new exit point is created both in the Sort Orders module instance and in the underlying Branch module.

Figure 6.21 Branch module referencing repeating operands including exit point operand

Repeatable modulesThe 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 module’s logic window and choose the Object > Module Repeater menu option. Move the cross-hair pointer into the logic window and click once to place a corner of the box. Move the pointer and click again to place the opposite corner of the box.

Once placed, the module repeater has connection points on both the inside and the outside of the box. The outside connection points are used to connect the box to non-repeatable logic external to the box, while the inside connection points are used to connect the repeatable modules inside the box to the module repeater itself.

To use the module repeater, place the modules that you wish to be repeating inside the box. The box can be resized to allow for adequate space. Connect any modules you place inside the box just as you would if they were outside the box. Make sure that at least one of the group of modules inside the box is connected to a connection point inside the box.

Note: If you have trouble connecting modules either to or from the module repeater, go to the View > Snap menu and turn off the Snap option.

To associate the module repeater with a repeat group in the dialog design window, double-click on an edge of the module repeater to open the Module Repeater Settings dialog (shown in Figure 6.22.) Type the name of the associated repeat group or choose it from the list at the Repeat Group Name prompt.

Next choose the type of repeating logic. There are two basic types: logic that repeats in parallel, or logic that repeats serially.

Parallel repeating logic specifies that each repeat of the logic is independent and represents a different logical path. If you wish to define the repeating logic in parallel, you must connect a repeatable exit point of a module (such as Branch or Duplicate) to the entry point of the module repeater. Example 1 shows how to define parallel repeating logic.

Serially repeating logic specifies that each repeat of the logic is connected, one after the other, in the same logical path. Example 2 shows how to define serially repeating logic.

Finally, choose the Number of Alternate Outputs required. This option is used to provide additional logic paths out of the module repeater. For example, if a module inside the module repeater has more than one exit point, you may wish to connect one exit point to the main logical path that exits the module repeater and another exit point to an alternate exit point of the module repeater. Example 3 shows how you might use the Number of Alternate Outputs field.

For the purpose of the next three examples, hidden entry and exit points have been used in the incoming and outgoing modules so that the module can be connected to other modules in a model window. Please refer to “The Dialog Design Window” chapter for more information on entry/exit points and hidden operands. It is typically not recommended that entry/exit points be hidden, as there is no way to reference them in a hierarchical module.

134


6 • Logic Window

Example 1: Parallel logicFigure 6.22 shows the logic window with a module repeater connected to a repeatable exit point of a Branch module (Blocks panel).

Figure 6.22 Logic window with module repeater

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

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

135


• •

• •

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 • Logic Window

Example 2: Serial logicFigure 6.26 shows the serial logic window module repeater with an Assign and Delay block inside.


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

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

137


• •

• •

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 • Logic Window

Example 3: Defining alternate outputsIn 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 window’s Operand Explorer in Figure 6.31 shows the repeat group Types and Quantities with operands Type and Quantity.

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

139


• •

• •

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 • Logic Window

Customized options using radio button and check box controlsIf you are using a module in the logic window that accepts only a certain set of values (e.g., a module containing a RadioButtonGroup or CheckBox or a ComboBox control that has a value list), you may want to provide the same options to modelers using your module but with a different set of terms. To do this, you can define a set of hidden operands that contain the values required by the module in your logic window. Each of the hidden operands is switched in only when the value provided by the user of your module selects the “matching” customized option you provide. (For a description of switches and their definitions, see “The Switch Window” chapter.)

For example, you might want to build a Raw Materials Receiving module representing a receiving area that can be used in systems that move material either by forklifts or by conveyors. The module’s logic window might contain a Leave module from the Arena template’s Advanced Transfer panel to transfer product out of the receiving area. In the Leave module, the options defining the transfer out type include Request Transporter and Access Conveyor, respectively. However, in your dialog, you may want to define a radio button group (called Transfer Type) offering the options Use Forklift and Load on Conveyor.

The RadioButtonGroup control in the dialog is used simply to obtain a selection from the modeler; it will not be referenced in the module’s logic window. Instead, in order to provide the necessary value (Request Transporter or Access Conveyor) to the Leave module, two hidden operands named Request and Access are used, with default values of “Request Transporter” and “Access Conveyor,” respectively. These operands have switches controlling which one is used in generating the module logic. The switch attached to the Request hidden operand is defined to be True when the operand Transfer Type has a value of “Use Forklift”; similarly, the switch attached to Access is True when Transfer Type has a value of “Load on Conveyor.”

In the logic window, the Transfer Out field in the Leave module that defines the type of transfer will reference `Request`À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.

141


• •

• •

Module connections

Using graphical connectionsIn a module’s logic window, you place and connect module instances from other template panels. The interface for creating module connections is the same as that in model windows—you may draw a graphical connection between the exit point of one module and the entry point of another module (using the Module > Connect menu or the Connect toolbar button), or you may type the module label in the dialogs of the two modules (if using the Blocks panel).

When working in a logic window, the graphical method of connecting modules is preferable, since Arena generates unique module labels for graphical connections. If you were to type a specific label for an entry point to a module in the logic window, you effectively would limit that module to only a single placement within any model (since module labels must be unique throughout an entire model).

For example, if you are creating a printing operation module, you might place a Delay module from the Blocks panel in the module’s logic window. If you were to define the Label field of the Delay module to have a value of BookBinding, the printing operation module could only be placed once in any model (either directly from your template or indirectly from any template that has an instance of your printing operation module in its logic window). If a second instance of the printing operation module was placed in a model, Arena would generate an error (the label BookBinding is defined more than once), because the placement of two modules with the same label creates an ambiguity—if an entity is sent to the BookBinding label, there is no rule to define which of the two modules is intended. Because of this, we strongly recommend that you do not enter values for labels to establish connections in the logic window.

Defining multiple connections from a single exit pointOne difference between connecting modules graphically in a logic window and connect-ing modules in a model window is that logic windows allow multiple connections to leave the same exit point. Model windows restrict each exit point to have exactly one connec-tion (whether by a graphical connection or by a specified value for the exit label operand). However, because logic windows permit alternate paths of logic controlled by module switches, it is necessary to permit multiple connections. (See “Switching module instances” on page 146 for a discussion of this technique.)

To define multiple graphical connections leaving the same exit point, simply add each desired connection to the exit point. For example, Figure 6.34 shows a Batch module instance with two connections emanating from its exit point, one to a Record module and the other to an Assign module. Be sure that the multiple modules that are connected to a

142


6 • 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 windowAnother difference between connections in model and logic windows relates to repeating exit points. In the logic window, you may create an operand reference for a repeating exit point (as described in “Referencing module data” on page 114), in which case the modeler using your module determines where entities are to be sent for each individual exit point. Or you might graphically connect a single repeating exit point to the entry point of another module in the logic window so that all entities sent from the module in the logic window go to the same next module.

The logic window provides an additional option of connecting all of the points created by a repeating exit point to the same module. To define this type of connection, connect the repeating exit point (defined by inserting a tuple in a module’s repeat group) to a module’s entry point in the logic window.

For example, you might be creating a module that represents the final processing step for corrugated metal production. Some part types that go through this step require a final trim; in all cases, the parts will be stamped (after trim for those that are trimmed). The dialog for this module might ask the modeler to list all part types that require trim, the time to

143


• •

• •

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

Figure 6.35 Corrugated Metal example dialog

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

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

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

144


6 • Logic Window

be connected automatically to the Delay module. To define this in the logic window, the first tuple inserted into the Branch module’s Branch Types repeat group is defined as shown in Figure 6.37—the condition type is selected to be If, and the condition compares the Part Type operand (which is repeating in the corrugated metal module) with the value of an entity attribute PartType (which may have been initialized at an order entry module).

Figure 6.37 Branch module in Corrugated Metal example logic window

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

145


• •

• •

Figure 6.38 Logic window for Corrugated Metal example

This technique—connecting a repeating exit point to a single module—also is often used in conjunction with the Conditional Assignment module described in “Using Arena’s utility modules (from utlarena.tpo)” on page 150.

Switching module instancesOne of the key aspects of Arena’s templates is the ability to define alternate model logic that is controlled by the values that a modeler provides for the module’s operands. The mechanism for defining that certain parts of a module’s logic should be included only under particular circumstances is to attach a switch to a module in the logic window. The chapter “The Switch Window” describes how switches are defined.

Switches are particularly important because of the effect that their use can have on the speed of a simulation run. If a module uses switches to remove unnecessary paths of logic from the module logic, the resulting simulation model represents the smallest required logic, given the options the modeler has selected. If switches were not a key feature of template development, all decisions about what logic should be used would need to be made during the simulation run by each entity arriving at a module. When you design a module, it is helpful to plan what alternatives you will provide and to sketch out how these options might control the logic generated by module instances in the logic window.

Attaching and detaching switchesIn 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

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 windowAs described earlier in this chapter, working in the logic window of a module definition is very similar to creating a simulation model in an Arena model window. You attach template panels to the Project Bar and select, place, edit, and connect module instances. If you want to define alternate logic paths to be included in or removed from the model based on values of module operands, you define switches in the switch window and attach these switches to module instances in the logic window.

When a module is placed or edited in a model window, switches are evaluated to true or false based on the module’s operand values. If the model is checked for completeness or a

147


• •

• •

simulation run is initiated, the module’s logic window is examined; only the module instances in the logic window that either do not have an attached switch or that have a true switch are included in the simulation model logic. If a module in the logic window has a false switch attached to it, the logic window is treated as though the module, as well as any direct connections into or out of the module, does not exist.

For example, if you are building a module that represents collection points for overnight package service, the module might be used both for self-serve collection boxes and for staffed collection offices. In any particular instance in which the module is used, only one type (self-serve or staffed office) will apply; all entities arriving at the module will be treated either one way or the other. The dialog design window for this module could define a selection operand, Collection Type, with options of Self Serve or Staffed Office. In the switch window, a SwSelf switch is added with a definition of `Collection Type`==”Self Serve.” A second switch, SwStaffed, has a definition `Collection Type`==”Staffed.” (Refer to the chapter “The Switch Window” for more information on defining module switches.)

The logic window of the Package Collection module defines both possible paths of logic. In the case of self-serve collection points, perhaps you want customers to perform the logic: Station, Delay, Route. However, for staffed offices, a Process module might be used to represent the availability of package collection workers, so the customers will perform: Station, Process, Route. In both cases, the Station and Route modules might contain the same information, regardless of the collection point type. The SwSelf switch is attached to the Delay module so that it is included in the model logic only when SwSelf is True; similarly, SwStaffed is attached to the Process module. The complete logic window might be defined as shown in Figure 6.40.

Figure 6.40 Logic window with switched modules offering two alternatives

148


6 • 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 module’s operands.

It is incumbent on you as the module designer to ensure that the switches you have defined and attached to module instances in the logic window will permit exactly one connection to be active (i.e., not switched out) from each exit point in any possible use of your module. In modules with switches, it is very helpful to test carefully each alternative of model logic (based on the variety of possible values for module operands) to ensure that the logic window is correct.

There are no restrictions on the complexity of modules that are to be switched in a logic window. The overnight package collection point example simply selects one of two alternatives, where each alternative includes only a single module. Any alternative might involve many modules with additional switches that provide additional options. The definition of modules such as the Leave module (Advanced Transfer panel) might involve dozens of switches controlling the display of operands in the module dialog and the module instances in the logic window.

A slight extension of the package collection point example might be to ask the modeler whether customers arriving at self-serve collection points might balk (i.e., not send the package at that collection box) based on some condition. The logic to represent this new option appears in Figure 6.41.

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

149


• •

• •

A new logic path has been added emanating from the Station module. In this path, a Decide module has been placed with two exit points: one connecting to a new Delay module and one connecting directly to a Route module (for balking customers). Each of the new modules has a new switch, SwBalk, attached. This switch might be defined based on a new check box operand, Balk Customers, having a value of Yes. The Balk Customers operand, in turn, could be switched in only when SwSelf is true, since the module should ask whether customers are to balk on a condition only for self-serve collection boxes.

To verify that the module is correctly defined, each exit point containing multiple connections should be traced to ensure that exactly one of the connections will be switched in for any value of the SwSelf, SwStaffed, and SwBalk module switches. The only module containing multiple connections to a single exit point is the Station module. By tracing the switched-in modules for each of the combinations of switch values (on and off for each of the three switches), you can ensure that your module will generate valid module logic in any possible use.

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

HIDDEN MODULE

One module in the utlarena.tpo template panel file, the Hidden module, is designed specifically to aid in defining logic windows that contain switches on module instances. This module does not generate any model logic or elements. (See the chapter “Elements” for information on elements.) It simply contains entry points and exit points to allow other modules to connect in and out of it.

The hidden module is used for cases where one or more of the alternatives to be switched in/out in the logic window do not generate any model logic. In these cases, a connection must be formed to show the desired flow of logic (because you cannot attach a switch to a connection directly), but there is no module instance to which a switch can be attached to indicate when the alternate path should be taken.

For example, let’s return to the overnight package-collecting module illustrated in Figure 6.40. We might add an option for the self-serve types of package offices to count the number of customers who dropped off packages. A switch, SwCount, could be defined to be true if the modeler indicated that this count should be collected. Another switch, SwNoCount, could be defined to be true when no count is to be taken.

150


6 • 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 module’s exit point.

Figure 6.42 Logic window using hidden module instance

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

151


• •

• •

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

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 traceArena provides a trace of the logic performed by entities during a simulation run. At the lowest level, SIMAN block Trace gives detailed, step-by-step information about the processes undertaken to represent a module’s logic. As a module designer, you do not need to provide any additional information for this type of trace to be activated. If a modeler using your template wishes to view block Trace, the Run > Run Control > Command opens a command window at the bottom of the screen. The Toggle Trace button can be used to turn SIMAN block trace on or off.

You can define additional, module-specific trace messages by inserting Trace modules (from the Blocks panel) at any place in the logic window that allows standard entry and exit connections. (Refer to the Trace block in online help for a description of the module and its fields.)

153


• •

• •

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 guidelinesThe following rules summarize important points concerning the definition of a module’s logic.

Modules cannot contain instances from the same template panel or any template that has the template being edited attached to it.

Entry and exit points of module instances in the logic window should be graphically connected or should reference a module operand. (The entry point operand for modules that create entities and queue balk exit points are exceptions; they may be unconnected in a logic window.)

If a module instance in the logic window has any required fields, you must supply values to them. If a required field contains a simple reference to an operand of your module, the referenced operand should be defined as required in your module’s dialog design window. If the required field’s value is defined using multiple operand references, you should ensure that under any valid combination of values entered by a modeler (for your module), the field in the module instance cannot be blank.

If you reference an operand in a module instance, you should ensure that the data type of the operand that is referenced matches or is more restrictive than the data type of

154


6 • 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

7 • User View Window

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

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

Figure 7.1 User view window

The user view window’s drawing region is identical to a model window’s region; for example, its home view displays objects in the same size as a model window’s home view. Other information that relates to object sizes, such as text proportions, grid spacing, etc., is also defined in the same world units used in model windows. (Refer to online help for additional information about model windows.)

Note: If you change the zoom level of the user view, remember to return to home view to ensure that objects you have placed in the user view are sized as you want them to appear in the default view in a model window.

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

157


• •

• •

the upper-left corner of the module handle. Other user view objects are arranged around the handle in the relative sizes and positions defined in the user view window.

After being placed in a model, the objects in the module’s user view may be repositioned individually by the modeler. Also, the characteristics of draw and animation objects may be changed; these objects can be cut, copied, pasted, deleted, or duplicated as well. For example, a queue animation object that accompanies the Process module (from Arena’s Basic Process panel when the action includes a seize) could be changed from its default line type to a point type, or could be repositioned relative to the module handle location.

Note: When the handle of a module instance is moved, user view objects are relocated with the handle. In the user view window of the module definition, however, relocating the handle does not move the user view objects.

Module-related objectsWhen 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• • • • •


159

The module handleThe module handle refers to the name that appears when the module is placed in a model or logic window. Arena automatically places a module handle object (displaying the module name, by default) in each module’s user view window when the module is created. You may change the handle name by double-clicking on the module handle object in the user view window (see “The Module Text Options dialog box” on page 159). A module handle may contain a maximum of 32 characters.

Because all modules must have exactly one module handle, the handle object may not be cut, copied, duplicated, or deleted from the user view window; it also may not be grouped with other objects.

The Module Text Options dialog boxThe module handle, by default, displays the module name. The name may be changed by double-clicking on the module handle to open the Module Text Options dialog box. You may either change the text string specified, or you may uncheck the Use Text String for Module Handle check box and specify an operand name that will appear as the module handle.

You will notice that in the Arena template modules (Basic Process, Advanced Process, Advanced Transfer), when you place a module in a model window, the handle is the unique name given to that module. For example, the Process module, when placed, becomes Process 1. The second instance becomes Process 2, the third is Process 3, and so on. These names are based on the name of the module, which can be changed by the user in the Process dialog box. Therefore, the module handle is not always Process, but is based on the user’s name input into the module Name operand.

The module handle font, font style, and font size are set at the default size so that all Arena modules have a consistent interface for accessing module data. By clearing the Use Default Font check box, however, you may change the module handle’s size, style, and font. Additionally, the line, text, and fill color may be changed using the Color toolbar.

Figure 7.3 Module Text Options dialog (with Text String or Operand Name used for module handle)


• •

• •

Entry and exit pointsEntry point and exit point objects in the user view are created automatically by Arena for each entry point and exit point operand defined in the dialog design window. The entry and exit point objects provide a graphical means of connecting the resulting module to other modules.

Entry and exit points may be moved anywhere within the user view window. When you select an entry or exit point, the operand name for that point is shown below the graphical object (so you may distinguish the points from one another if you have more than one entry or exit point operand).

The appearance of entry and exit points depends on the type of point. Figure 7.4 shows each entry and exit point type in a user view (including a repeatable exit point), with the point type labeled next to the graphical entry/exit point.

The orientation of a non-repeatable exit point object may be rotated by double-clicking on the object. Entry and exit point objects may not be cut or copied to the clipboard, duplicated, deleted, or grouped with other objects.

Note: If the operand that defines the entry/exit point is deleted from the dialog design window, the corresponding object is removed from the user view window.

Figure 7.4 Entry and exit point types

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

160



Displayed operandsOperands 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 operands—Yard and Interarrival Time.

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



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 objectsDraw objects (boxes, lines, circles, etc.) may be placed in the user view window via the Draw toolbar. These are added in the same way that you would add draw objects to a model window. Simply choose the desired object from the toolbar and place it in the window. The hidden and visible layers may be used to control whether or not objects defined in a module’s user view will appear during a simulation run. (Refer to online help for more information about these layers.)

Draw objects may be cut, copied, pasted, duplicated, and deleted. If objects are cut or copied to the clipboard, you may paste them into any window that supports draw objects.

After placing a module in a model or template logic window, a modeler may change the characteristics of (or delete) draw objects that were provided by the module user view.

Draw objects placed in the user view window may have attached switches (see “User View switch use” on page 166). If so, the object will appear only if the attached switch is evaluated to True.

163


• •

• •

Animation objectsAnimation objects (e.g., queues, stations, levels) may be placed in the user view window via the Animate toolbar. These are added in the same way that you would add animation objects to a model window. Simply choose the desired object from the Animate toolbar, type the required information into the object’s dialog, and place the object in the user view window.

Animation objects may be cut, copied, pasted, duplicated, and deleted. If animation objects are cut or copied to the clipboard, you may paste them into any window that supports animation objects.

When editing an animation object, you may specify that it is named by using the value of one or more module operands. To create this tie between the module dialog and an animation object, you create an operand reference by enclosing the operand name in back quotes (`) . For example, if you are defining a module in which a count is collected with operand Counter Name defining the name of the counter, you might place an animation variable in the user view to show the value of the count during the simulation run. The Expression entry in the variable dialog could be defined as NC(`Counter Name`), as shown in Figure 7.8.

Figure 7.8 Operand reference in animation variable dialog box

164



Operands may be referenced only in the entries within animation object dialogs listed in Table 7.1. Other animation object characteristics may be defined in the user view, but may not reference module operands.

Also, if an animation object is part of a module instance’s user view, the entry listed in Table 7.1 is not changeable (i.e., is grayed out) by the modeler, with the exception of repeatable values (i.e., plot expressions, entity values, resource states, and global values).

The operand references in the animation objects follow the guidelines described in “Referencing module data” on page 114 of “The Logic Window” chapter.

References to repeating operands are not permitted in animation objects, including the cases where the animation object allows a repeating set of values (i.e., plot expressions, entity values, resource states, and global values).

If an animation object containing operand references is copied from the user view window to the clipboard and is pasted into a model window, the entries containing references are changed to blank (since, after being pasted, the animation object is no longer part of a module). If the animation object had a switch attached to it, the switch is removed if the object is pasted into a model window.

Animation objects placed in the user view window may have attached switches (see the next section). If so, the object will appear only if the attached switch is evaluated to True.

Table 7.1 Animation object characteristics that permit operand references

Animation Object Entry Permitting Reference

Queue Identifier

Storage Identifier

Parking Area <none>

Seize Area <none>

Station Identifier

Intersection Identifier

Route <none>

Segment Identifier

Distance Identifier

Network Identifier

Variables Expression, Format

Clocks Time Units Per Hour, Hour, Minute, Second

165


• •

• •

User View switch useOf the objects that may appear in the user view window, only animation and draw objects may have attached switches. A switch contains a conditional expression that is evaluated to True or False. If the switch condition is evaluated to be True, all animation or draw objects with the switch attached will appear in the model window. If False, these objects will not appear in the model window. For more information about switches and their uses, refer to “The Switch Window” chapter.

To attach a switch to an animation object in the user view window, highlight the object and choose the Object > Switch > Attach menu option, or click the Attach Switch toolbar button (shown at left). Then type the name of the switch or select it from the drop-down list in the dialog that is displayed.

Note: Only a single switch may be attached to any object in a module definition.

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

Date Time Units Per Day, Month, Day, Year, Hour, Minute, Second

Levels Expression, Minimum, Maximum, Expression (Accum.), Minimum (for Expression (Accum.)), Maximum (for Expression (Accum.)), # of Points, # of Distribution Points, Width

Histograms Expression

Plots Any textual property value (i.e. you may enter a value into the field for specifying the property value)

Entity Value

Transporter Identifier

Resource Identifier, State

Global Expression, Value

Table 7.1 Animation object characteristics that permit operand references

Animation Object Entry Permitting Reference

166



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

8 • Switch Window

8 The Switch Window

A switch is a construct that allows a template designer to define variations of:

the fields displayed in a module dialog, the model logic and elements that are generated when a simulation run is initiated, orthe animation objects displayed in a module’s user view.

To control the appearance of the module or its underlying simulation logic, you define switches (using the switch window) and attach them to the objects in the module definition’s other windows (dialog design, logic, user view).

As its name implies, a switch can have a True (“on”) or False (“off”) value. If an object has a switch attached, the object is displayed or included in simulation logic only if the switch condition evaluates to True.

The use of switches permits you to capture a wide range of variations of some process or system element in a single module, rather than needing to define separate, similar modules for each variation. Switches also can be used to control the information presented to modelers so that only the relevant fields are displayed.

For example, if a module representing an automated teller machine (ATM) has an option for the modeler to indicate whether deposits are accepted at the ATM and a modeler selects “No,” there may be no reason to ask the modeler to define the processing time for deposits. In this case, a switch can be defined to turn off the deposit process time operand (i.e., remove it from the dialog) for any ATM that doesn’t accept deposits. The corresponding logic for processing deposits also could be removed by attaching the switch to the appropriate module instances in the module’s logic window.

In this chapter, we present the mechanisms for defining switches and for interacting in the switch window. The “Dialog Design Window,” “Logic Window,” “User View Window,” and “Elements” chapters describe the effects of switches on each type of module construct and the mechanism for attaching switches to objects in a module definition.

Defining switchesA 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; andanimation and draw objects in the user view window.

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

Switches are defined by opening the module’s switch window and specifying the switch name and definition. A module’s switch window is opened by clicking on the module in the template window’s Module Definitions list, then selecting the Window > Switch menu item or pressing the Switch Window button on the Template Development toolbar.

To create a new switch definition, click the Add button in the switch window. In this dialog, you will specify the switch name and the definition (i.e., the condition under which the switch is True) and click OK. Figure 8.1 shows the switch window with a single switch definition (SwDeposits).

It is sometimes useful when duplicating, copying, pasting, or deleting switch definitions to perform the operation on multiple switches. You may select multiple switches by using SHIFT+click to select a range of switches or by using CTRL+click to add individual switches to the selection set.

Figure 8.1 Switch window

Switch namesA 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• • • • •

8 • 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.

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.1 Switch reference types

Referenced Item Enclose In Example Definition

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

Value of operand Double quotes (” ”) `State`< >”Busy”

Switch — Switch1 && !Switch2

Table 8.2 Switch definition logic operators

Logical Operator Meaning Use Example

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

< > “is not equal to” Compare op to value Counter`< >”None”

! “not” Take the opposite of a switch value

!SwSetupRequired

&& “and” Combine comparisons, requiring both to be true

SwCount && `Counter`==”Individual”

171


• •

• •

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 rulesA 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.

|| “or” Combine comparisons, requiring either to be true

SwSetup || SwNewRecipe

> “is greater than” Compare op to value `Number`>”14”

>= “is greater than or equal to”

Compare op to value `Weight`>=”100.3”

< “is less than” Compare op to value `Time`<“10.5”

<= “is less than or equal to” Compare op to value `Tables`<=”20”

Table 8.2 Switch definition logic operators

Logical Operator Meaning Use Example

172

8 • THE SWITCH WINDOW• • • • •

8 • Switch Window

This applies to direct references (as in the operand Format in the above example) or to indirect references created via switches contained in a definition. For example, if the switch SwLooseleaf in the above example was defined using the condition `Prebound`==”No”, the SwBind switch could not be attached to the operand Prebound since Prebound is involved in the definition of SwBind indirectly through SwLooseleaf.

If a switch references a repeatable operand, the switch will have a separate value for each tuple (i.e., each set of values for the repeating operands) of the module’s repeat group. (Refer to the chapter “The Dialog Design Window” for a discussion of repeat groups and tuples.)

For example, the Basic Process panel’s Assign module allows repeated assignments to different types of elements (Attributes, Variables, Pictures, etc.). The assignment repeat group contains a set of operands with switches that ensure that only the appropriate operand will be displayed, based on the selection of the assignment type. One switch is true when Attributes is selected, one is true when Variable is selected, etc.

When the Assign module is used in a model, the first tuple might assign an attribute; the second, a picture; and the third, a variable. The module’s switches are evaluated 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

9 • Panel Icon Window

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

Figure 9.1 Arena template Basic Process panel

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

175


• •

• •

A panel icon window is shown in Figure 9.2.

Figure 9.2 Panel icon window

Creating the panel iconThere 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

10 ElementsIn many cases, the modules that we build represent a component of a system that contains one or more objects. For example, we might build a workstation module that represents an in-buffer, a worker, a machine, and an out-buffer. These objects in the system have certain characteristics and behaviors that we must capture in our module. For example, the in-buffer must maintain an ordered set of parts to be processed on the machine.

Arena, through its base language SIMAN, provides a complete set of modeling objects called elements that can be used directly for representing the components of a system. For example, Arena provides a queue element that maintains an ordered list of items and has operations for inserting entities into and removing entities from the queue and for searching and sorting the members of the queue.

By using Arena’s built-in elements in your modules, you gain access to predefined model-ing objects that represent complex physical components in your system. Elements are important in module building because they provide a powerful mechanism for represent-ing standard objects in a module such as workers, equipment, conveyors, carts, etc.

Although elements referenced in a module are frequently used to represent physical components of systems such as machines and workers, in some cases, the elements are used to represent information such as process plans, failure patterns, shift schedules, etc. These data elements provide a structured method for representing system information. Arena provides operations that access the data contained in these elements based on the element type. For example, an entity may undergo a route operation that references a sequence element, in which case, the sequence element specifies the destination station and the assignments to be made to entity attributes and model variables.

The real power of the elements lies in the built-in functionality that is automatically provided by Arena/SIMAN for each element type. When you incorporate an element in your module, the element has a standard set of characteristics, called properties, that describe the element and a standard set of operations that can be applied to alter its state. For example, if you employ a resource element, it has a standard set of data properties that describe it (capacity/shift pattern, operating states, failure and repair characteristics, etc.) as well as standard operations that can alter its state (Seize, Release, Preempt, etc.). Likewise, a conveyor element has standard properties that specify its characteristics (path, speed, etc.) and standard operations that change its state (Stop, Start, Convey, etc.).

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

177


• •

• •

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

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

Table 10.1 Some elements and sample properties and operations

Element Properties Operations

Resource NameCapacity/ScheduleStates (Busy, Idle, etc.)Failure PatternCosting and Efficiency

SeizeReleasePreemptAlter

Conveyor NamePath SegmentsVelocityCell SizeStatusType

AccessConveyExitStartStop

Transporter NameNumber of UnitsTypeVelocityAccelerationDecelerationInitial Unit Characteristics. (Position, Status, Size)

AllocateRequestMoveTransportFreeHaltActivate

Queue NameRanking CriterionShared Indicator

QueueInsertSearchRemove

Station NameAssociated IntersectionRecipe

ConveyRouteTransportStation

Variable NameInitial Value

Assign

178

10 • ELEMENTS• • • • •

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 elementsWhen you define a module, you can specify that one or more elements, such as queues, resources, transporters, etc., be created when a modeler places an instance of your module. Your module also may present properties of its elements in the module dialog so a modeler can change the characteristics of the elements. And the module logic may specify operations that act on the module’s elements such as seizing a resource or transporting to a destination station.

In a module definition, you may create an element in two ways. First, in your module’s logic window, you can place instances of modules that themselves create elements. For example, if you are defining a baking-line module and you place a Process instance in the logic window that specifies a resource named Oven, an Oven resource element will be created when a modeler uses your baking-line module. You can think of this mechanism as defining elements through Arena’s hierarchy.

The second mechanism for creating elements is to place an operand in the dialog design window of your module definition and, in the operand’s LogicProperties property, specify the operand as an Element. In this case, you need not place a module instance in the logic window to cause the element to be created. Instead, by specifying that the operand’s type is Element, you indicate that the value of that operand in an instance of your module is to be taken as the name of an element. You can think of this approach as defining elements

179


• •

• •

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 listsWhen 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.

PropertiesElements have characteristics that we refer to as properties. A particular element that has been created in a simulation model, such as a resource named Oven, has its own set of values for its properties. One resource element (e.g., Oven) may have a capacity of 12, while another resource element (e.g., Bake Prep) may have a capacity of 1.

You may allow a modeler to define the property values for a particular element by using one of two mechanisms (in the module definition) that are similar to those available for creating elements. In the first case, you place a module instance (such as a Resource module from Elements panel) in the logic window of your module definition. In this module instance, you can specify that element properties are defined through references to your module’s operands (e.g., a resource capacity operand). In this case, your module gives a value to the property through hierarchy.

180

10 • ELEMENTS• • • • •

10 • Elements

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

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

Access to properties in a modelThe use of element and property operands allows modelers to access information related to elements in more than one place in a simulation model. Although property information for a given element is “global” and could be accessed through multiple modules, it is recommended that property information for an element be defined within a single module, such as a data module, for a given element type. This typically eliminates confusion for the end user, so that properties of a resource, such as capacity, schedule, failures, etc., are defined and changed in only one location, not in multiple modules. The Auto-Created Module feature allows logic-type modules to define data modules automatically. (Refer to the operand object’s LogicProperties property description in “The Dialog Design Window” chapter.)

For example, if you were building a model of a welding line, you might use a Process module (from the Basic Process panel) to represent the welding process for standard-type parts. Another set of logic in the same model for welding oversized parts might use a different Process module. Both of these modules would use the Welding resource for processing. A Resource data module (also from the Basic Process panel) is created automatically for the Welding resource, with default information for its properties, such as a capacity of 1. The Resource module can then be edited to specify the characteristics of the Welding resource (e.g., its schedule, failure patterns).

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 listsThe use of elements also gives the advantage of displaying lists to modelers (as described previously). These lists are classified by element type (e.g., resources, queues, stations) so that a modeler is presented with a list of elements that is constrained to the appropriate type based on the operand’s use in the module. For example, if you add a ComboBox control to a modules’s dialog design and then define that operand as an element operand, the drop-down list of the operand will show all of the elements that have been added to the model (of the type of element defined by the operand).

A basic or property operand that is a ComboBox control also may present a list of elements. (Refer to “The Dialog Design Window” for descriptions of the user interface controls that may be added to module dialogs.) In this case, the drop-down list displays the elements that have been created in the model so that a modeler may select from those elements already defined. However, if a new entry is made in a basic or property operand, this new value is not added to the list of elements.

For example, in the Match module from the SIMAN blocks panel, the Match Expression field displays a list of attributes. However, if a modeler enters a value, such as PalletSize, in the Quantity field that does not match the attributes that already have been defined, a new attribute element is not created. This is because the Match Expression field actually accepts any type of expression value; however, it is common to use an attribute for this field.

The display of element lists in non-element operands often is useful when the data type of the operand is expression (to allow mathematical operators, etc.), but where a particular element type often will be used. In the template reference guides, we list the element type in parentheses if the list is for display only or in square brackets if the operand defines an element.

As the template designer, you may create sub-lists to further restrict the scope of the element list provided to a modeler. For example, if you have an operand that defines a resource, you can identify a sub-list associated with that operand; e.g., Operators. When a modeler defines a new element (by typing a name into the resource field), the element is added to the Operators sub-list. Other modules in your template (or in other templates) might also display the Operators sub-list of resource elements. In this case, the modeler is presented with a list of only those resources elements that have been specified as

182

10 • ELEMENTS• • • • •

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 hierarchyIn a module definition, the most direct way to design the module so that it creates the necessary elements when it is used in a model is through hierarchy. If you are defining a module and you place instances of the Enter, Process, and Leave modules in your logic window, for example, a number of elements will be created automatically in any instance of your module, such as any resources, stations, or material-handling devices you specify. Using this approach, you do not need to be concerned with adding information to your module definition relative to elements. (The elements were defined automatically through the module instances.) In fact, throughout this guide, we have provided module examples without discussing the concept of elements.

For simple module definitions, this approach will be sufficient; the appropriate information will be provided to define the simulation model completely (i.e., both the logic and the elements). However, simply defining elements via hierarchy does not afford the benefits listed in the previous section (i.e., defining element lists or access to properties).

Note: If you display any element properties in your module’s dialog, we strongly recommend that you use element and property operands in the dialog design, rather than hierarchy, to define the elements.

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

Element operands

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

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

183


• •

• •

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

Figure 10.1 Logic Properties dialog for an Element operand

When the Type is specified as “Element,” the following fields are displayed:

Element Type—The type of SIMAN element that the operand will define/reference. Select the desired type from the list. The operand's value will then be used as the name of the element of the selected type (e.g., an operand with value “Operator” will define or reference a SIMAN element with name “Operator”).

Sub-list—The sub-list partition of elements (by Element Type, such as resource) of which this operand’s element is to be a member. For example, the element type Resources might have sub-lists for Operators and Machines. Sub-lists are described in more detail in the next section.

Define/Reference—Indicator whether the element that is created by this operand should be defined for the simulation model or whether it only should be referenced. If Referenced is selected, then some other module must define the element that is referenced by this module. This typically is used when incomplete property information is definable in a module.

184

10 • ELEMENTS• • • • •

10 • Elements

Sub-listsSub-lists allow partitioning into subsets the element lists that are presented to a modeler. There is a standard sub-list for each element type that is named the same as the element (e.g., RESOURCES). Elements that are created by instances of modules from the Arena and SIMAN templates are added to this sub-list.

Note: If the sub-list field is blank in the operand definition, any element that is created by an instance of the module will be added to the master list of elements, which presents a list of all elements of the particular element type (i.e., the combination of all elements defined as members of all sub-lists).

In Figure 10.1, the sub-list in the operand’s Logic Properties dialog is specified as “Inserters.” Thus, each time a value is entered into that operand in a module instance, a new element (i.e., a resource) will be created and added to the Inserters sub-list of resource elements.

By using sub-lists in your template design, you can present the various elements represented in your template in as many different groups or classifications as you would like. Each classification (i.e., sub-list) simply is a name associated with a particular element list.

For example, a template containing an “Automatic Insertion” module with the operand in Figure 10.1 might also have a module for soldering operations that defines solder resources. Sub-lists could be created that place the Automatic Insertion resource elements onto an Insertion sub-list and the soldering operation resource elements onto a Solder sub-list. When a modeler wants to select an Automatic Insertion resource to perform an operation, the drop-down list presented in the dialog would present only those resource elements that have been defined to be inserters (i.e., have been placed on the Inserters sub-list). The solder resources would not be displayed in the drop-down list of inserters.

Note: In any model, the sub-lists are shared across modules from different template panel files. For example, if a module from one template adds an element to the Inserters resource sub-list, another module from a different template also could add elements to the same sub-list.

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

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

185


• •

• •

the Define/Reference option in the operand object’s LogicProperties property dialog (see Figure 10.1).

If you select Define, the element is added to the simulation model (i.e., it will be written to the SIMAN experiment file), and its name is added to the appropriate element list (in the specified sub-list). If you indicate that the operand is only a reference to an element, the element name is added to the element list only. In this case, the element is not yet defined to be part of the simulation model; i.e., it will not be written to the SIMAN experiment file until another module instance containing a Define-type of element operand with the same value is placed.

This type of element operand, a reference operand, is used when a module contains an operand that specifies an element, but the module does not contain the complete set of operands to define the required properties of the element. If an element is created in a simulation model only via reference element operands, an Undefined Identifier error will be given if the model is checked.

The use of the Auto-Created Module Settings button within an operand’s LogicProperties property dialog allows more flexibility in defining and referencing an element. A data module, for example, may be created automatically using the Auto-Created Module feature when a particular element is referenced. (Please refer to “The Dialog Design Window” for more details.)

For example, the Advanced Transfer panel’s Leave module contains a field naming the transporter to be requested (if you select Request Transporter as the transfer out mechanism). If you enter a transporter name, such as Shuttle1, an element named Shuttle1 is added to the list of transporters. This will automatically create a Transporter data module entry with the name Shuttle1, containing default information about the transporter, including a distance set name of Shuttle1.Distance. However, because required properties such as the transporter distance set are not part of the Leave or Transporter module, a modeler who simply places the Leave module has not completely defined the transporter information. In this model, the Shuttle1 transporter element has an indicator that it is referenced only (i.e., not yet defined). To have a complete model, the modeler would need to edit the data module that defines the Shuttle1.Distance distance set. (Trying to run the model without doing so will give an Error window, specifying “This module has not been edited,” where you may click the Find button that will take you to the Distance data module.)

186

10 • ELEMENTS• • • • •

10 • Elements

Property operands

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

Figure 10.2 Logic Properties dialog for Property operand

When the Type is specified as “Property,” then the following fields are displayed in the Logic Properties dialog:

Element Operand—Name of the operand that is defining the SIMAN element in this module of which this property operand is associated. In Figure 10.2, an element operand named “Inserter ID” has been added to the dialog design. This operand is defining a RESOURCES element. We are now defining a property operand pointing to a property of that resource.


Property Name—Name 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.

187


• •

• •

Read Only—This option is only available if the operand is a HiddenOperand control in the dialog design. If enabled, the hidden operand will simply read into its value the current value of the element property with which it is associated. The element’s property value will NOT be overwritten by the operand’s Value property. The default value defined for the hidden operand will only be written to the element’s property value if that property has yet to be defined (i.e., the current value of the property is null).

Note that the Read Only feature may be used to allow modules to communicate indirectly. For example, a “master” module may define an option to “Collect Statistics,” which would be written as a property of a named element. All other “subordinate” modules could have hidden operands referring to the named element and its property, but the hidden property operands in the “subordinate” modules would have the Read Only option checked. Other operands that collect various types of statistics in the “subordinate” modules may be switched in or out depending on the value of the hidden property operand. In this way, editing the “master” module would affect the other modules, giving you a type of “Global Operand” capability.

Defining repeating propertiesSome elements contain properties whose values are repeatable, such as initial positions of the transporter units defined by a Transporters element or the list of failures for a Resource element.

In the module definition’s dialog design, a repeat group object (RepeatGroupDialog or RepeatGroupTable control) can be specified to be a property repeat group. When you define a property repeat group, you are indicating that a repeating set of values will be written by one or more property operands contained in the repeat group. (Refer to the chapter “The Dialog Design Window” for a more information on using repeat groups in the module’s dialog design.)

Similar to operand objects, a repeat group’s LogicProperties property specifies whether the repeat group is pointing to an element’s repeatable property. Figure 10.3 shows the Logic Properties dialog for a property repeat group object. In that example, the repeat group is pointing to the Failures property of a RESOURCES element (the resource is being defined by an Inserter ID element operand).

188

10 • ELEMENTS• • • • •

10 • Elements

Figure 10.3 Logic Properties dialog for a Property repeat group

If the repeat group’s Type is specified as “Property,” then the following fields are displayed in the Logic Properties dialog:

Element Operand—As is the case in the definition of property operands, this entry specifies the name of the operand that is defining the SIMAN element in this module of which this property repeat group is associated.


Property Name—Name of the element property that this repeat group defines, selected from a list of valid repeatable properties associated with the Element Type.

Note: In the dialog design, when you define a repeat group to be a property, all operands and repeat groups that are contained within the repeat group must be property or element operands.

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• • • • •

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.

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 operandIn 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• • • • •

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

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• • • • •

10 • Elements

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

Figure 10.10 Automatic Insertion example module instance

Switches and elements

Switches may be attached to element operands in the dialog design by specifying the SwitchName property in the object’s design properties. Or, you may select the object and use the Object > Switch > Attach menu item to attach a switch and select the switch from the list that is presented in the Attach Switch dialog. (Refer to the chapter “The Dialog Design Window” for more information.)

When a module that includes element operands with switches is used in a simulation model, the behavior of switches as they relate to the appearance of the module dialog also is the same as occurs for basic operands. If the operand’s attached switch condition evaluates to True, the operand is displayed. If the switch condition is False, the operand is not displayed.

However, element operands have the additional feature of creating elements—adding them to lists, and if the element operand reference type is Define, defining the element in the simulation model. Because more than one module instance in a model may have an element operand that accesses the same element, there is the potential that the same

195


• •

• •

element’s defining operand might be “switched in” in some module instances and “switched out” in others.

In the case of such a conflict, Arena retains the element on the element list as long as any operand that creates the element is not switched out (i.e., either has no attached switch or a true switch). The same rule applies to properties of an element.

Note: If an element operand has an attached switch in a module definition, all property operands that define properties of that element also should be switched to ensure that there is no condition under which the element could be switched out and one or more properties switched in.

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

Special element typesThe 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 elementsMany 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• • • • •

10 • Elements

and the third value is the yield for a given job type. If you wanted to display this information as non-repeating operands in a dialog, you would not be able to use property operands (because the recipe element specifies that the values are in a repeat group).

We have added element types that mirror each of the elements containing repeating values. These additional element types are referred to as fixed-length elements. These fixed-length elements contain a predefined set of values for the repeating property; they are named using the prefix Fixed_. For example, the Fixed_REC50 element has 50 assignment properties followed by a repeating assignment property; the standard RECIPES element contains only the repeat group for assignments.

Additional fixed-length elements contain a predefined number of repeating properties within the repeat group. These elements are named using the prefix Fixed_ and a suffix R. These elements allow you to define a one- or two-dimensional array where each row in the array is an individual tuple. For example, the Fixed_VAR10R element has 10 predefined initial value properties per repeat group.

You utilize the fixed-length elements exactly as you use the standard elements, by defining element operands to create elements and property operands to define the values of the element’s properties. Fixed-length elements are generated along with standard elements at model generation.

Note: The element lists and sub-lists are separate from one another, even for related element types (e.g., Fixed_REC50 and RECIPES elements).

Hidden element listYou may find a circumstance where you want to provide a modeler with a drop-down list of values, but you do not want these values to be written to the SIMAN experiment file. We have added an element type, referred to as the hidden element, that allows you to define an element list but that will not be used to generate the simulation model.

The hidden element functions like a standard element but doesn’t directly write its values to the SIMAN experiment file. In the LogicProperties property dialog, an operand that is type element can be defined as a hidden element type by selecting Hidden from the list of available element types. This option appears at the end of the list of element types. There are no properties associated with the hidden element type.

An example of using a hidden list is as follows. In the Arena template modules (Basic Process, Advanced Process, and Advanced Transfer), each module you place is given a name, based on the module type. For example, if you place the Create, Process, then Dispose module, they are named automatically Create 1, Process 1, and Dispose 1. You may edit those modules and change the module name, which changes the module handle you see in the user view. Each of the name fields has a drop-down list, which is a list of all module names in the model. These are not written to any SIMAN element, as they are

197


• •

• •

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

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

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

Inverted elementsInverted 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• • • • •

10 • Elements

inverted elements: Inv_DISTANCES for creating a distances element, Inv_LINKS for creating a networks element, Inv_SEGMENTS for creating a segments element, Inv_SETS for creating a sets element, and Inv_Statesets for creating a set of states for resources.

The difference between an inverted element and a standard element relates to how the elements and properties are defined. For example, the standard Segments element defines a segment name. Its properties are beginning station, next station, and length. The Inv_SETS element defines an element whose default value is used internally. This element’s properties are beginning station, next station, length, and segment set name. The Inv_SEGMENTS element value must be unique and is usually created as a combination of visible operand values (explained in the following example).

A module that uses an inverted element combines visible standard elements with hidden inverted elements. At model generation, all instances of a module that use Inv_SEGMENTS and have the same segment set name property value are converted and sorted to create a valid standard segments element.

For example, suppose the template design is to include a Segment module whereby users can define the animation of a conveyor while defining the segment set, using the Inv_SEGMENTS element. Figure 10.12 shows an Animated Segment module’s dialog.

Figure 10.12 Dialog box for Animated Segment module

199


• •

• •

200

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

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

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

10 • ELEMENTS• • • • •

10 • Elements

201

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

Figure 10.14 Design properties of Name operand

In Figure 10.14, see that the default value for the operand is `Beg`È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 module’s dialog. The Set operand is a visible element-type operand that defines a standard Segments element.


• •

• •

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

Figure 10.15 Design properties of BegN operand

The SetN operand is also a hidden property whose default value references the Set operand value.

When a module is designed in this manner, each instance of the module creates one tuple of the segments element. Arena correctly saves and sorts all instances of the module so that the beginning and ending stations are in the correct order. The other two material-handling inverted elements (Inv_LINKS and Inv_DISTANCES) are used in the same fashion.

The Inv_SETS element and Inv_Statesets elements are slightly different. The Inv_SETS and Inv_STATESETS elements are the opposite of the standard sets and statesets elements. The standard sets and statesets elements defines a set name, and its properties

202

10 • ELEMENTS• • • • •

10 • Elements

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

Currently, the Arena and SIMAN templates do not use any of the inverted element types.

203


• •

• •

204

A • Template Design

Guidelines

A Template Design GuidelinesWhile 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)

DialogsPlan ahead. Try to create a picture of the dialog boxes for the modules in your template panel and lay out the information in some consistent format.

Use Line and GroupBox controls to group related information within a dialog.

Use secondary dialog boxes instead of a single large dialog.

Secondary dialogs generally should not contain required operands unless they are switched “On” by the user.

Within a template panel, use consistent designs in the modeler’s interaction with dialog boxes. If keyboard tabbing order typically moves vertically among operands, try to avoid cases where the tab key moves to an operand located to the left or right.

Try to design the dialog box so that there is some amount of symmetry, but avoid large empty spaces.

Operand objectsPrompt text should be concise; when abbreviations are used, be very clear what term is abbreviated.

TextBox and ComboBox controls should have non-blank prompts unless nearby operands or static text clearly point out the meaning of the text/combo operand.

If the options of a RadioButtonGroup control have a clear meaning, a prompt label is optional. However, if there is any possibility of ambiguity or misunderstanding, provide a prompt label.

Prompts should be clear and contain a minimum of SIMAN jargon.

If an operand is referenced by a required field of a module in the logic window, it should also be required in the module’s dialog design.

205


• •

• •

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 windowUse meaningful operand names. These will be used for default prompts and for column headings with Module Data Import/Export.

GeneralModule entry and exit points should not be hidden so that the module can be used in the definition of another module (i.e., a Label/Next Label operand should appear in the module dialog box so that a reference may be entered when the module is placed in another module definition’s logic window).

Utilize the Auto-Created Module functionality to create “data” modules from “logic” modules automatically.

Panel icon Retain the text label of the icon and use the same font type and size for all modules.

Be consistent within a template with use of color and style.

Keep the icon simple.

Use similar design types for panel icons; avoid mixing 2-D and 3-D panel icons.

206

A • TEMPLATE DESIGN GUIDELINES• • • • •


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 resource’s 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 template’s Basic Process, Advanced Process and Advanced Transfer panels). Place the more important grouping at the top of the panel.

User viewPlace 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 logicUse Draw objects and Named Views in the logic window to identify various parts of the module logic.

Verify module logic first in a model window so that you can interact with the model and view a detailed animation. Then use Arena’s clipboard to transfer the logic into a module definition’s logic window and add the appropriate operand references and/or switches.

Base your modules on SIMAN Blocks and Elements. This allows you to then define elements either through the logic window or the dialog design window.

207


• •

• •

Naming conventionsWhen a module contains a station designation, the station name should be supplied by the user. Other operands may be given default names based on the station name with a suffix.

Using the following suffixes will provide improved consistency and help prevent multiple use of the same name:

`Station Name`_R - Resources`Station Name`_Q - Queues`Station Name`_S - Storages`Station Name`_C - Counters`Station Name`_Ta - Tallies

Supply a standard prefix to your template panel files if you create and share multiple files.

If you build modules that have similar names to modules in other templates, use a prefix in the module’s main dialog title (e.g., AGV_Transport) to distinguish it from the other modules that perform a similar activity.

Template documentationWe 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.

TraceAlthough 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• • • • •


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 reportsAlthough 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

B • Tables

B Tables

Elements and properties

Standard elementsListed 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.

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• • • • •

B • Tables

Cross Severity

CONTINUOUS Element Properties

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• • • • •

B • Tables

CSTATS Element Properties

Number

Name

Output File

Report ID

Data Type

Category

Process ID

DISCRETE Element Properties

Max Number of Entities

Number of Attributes

Largest Queue Number

Largest Station Number

Animation Attribute

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


EVENTS Element Properties

Crossing Variable

Crossing Direction

Threshold Value

Crossing Tolerance

216

B • TABLES• • • • •

B • Tables

EXPRESSIONS Element Properties

Number

1-D Array Index

2-D Array Index

Data Type

Expression Values (R). Expression

I/O Point

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


• •

• •

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

FILES Element Properties

218

B • TABLES• • • • •

B • Tables

Velocity Change Factor

LEVELS Element Properties

Number

1-D Array Index

2-D Array Index

Initial Values (R). Value

LINKS Element Properties

Number

Beginning Intersection ID

Beginning Direction

Ending Intersection ID

Ending Direction

Number of Zones

Length of Each Zone

Link Type


NETWORKS Element Properties

Number

Links (R). Starting Link. Ending Link

NICKNAMES Element Properties

Name or Constant

INTERSECTIONS Element Properties

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• • • • •

B • Tables

Transporters

Conveyors

Processes

Stations

ActivityAreas

Tanks

QUEUES Element Properties

Number

Ranking Criterion

Rule Expression

Associated Block/SHARED

Auto Stats Generate

Auto Stats Category


RANKINGS Element Properties

Ranking Criterion

Ranking Expression

RATES Element Properties

Number

1-D Array Index

2-D Array Index


PROJECT Element Properties

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• • • • •

B • Tables

REPORTLINES Element Properties

Number

Report ID

Format

Expressions (R). Expression

REPORTS Element Properties

Number

System Name

Title

Heading

Sort

Format

RESOURCES Element Properties

Number

Capacity or Schedule

Integer or Sched ID

Capacity Entity Rule

Stateset ID

Initial State

Resource Type

Map ID

Velocity

Initial Position

Position ID

Zone

Busy Cost

223


• •

• •

Idle Cost

Usage Cost

Category Type

Failures (R). Failure. Failure ID. Failure Entity Rule

Auto Stats Generate

Auto Stats Category


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

RESOURCES Element Properties

224

B • TABLES• • • • •

B • Tables

SEGMENTS Element Properties

Beginning Station

Next Stations (R). Next Station. Length

SENSORS Element Properties

Number

Tank Name

Location Type

Location

Crossing Direction

Block Label

Initial State

SEQUENCES Element Properties

Number

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

SETS Element Properties

Number

Members (R). Member

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


STORAGES Element Properties

Number

TABLES Element Properties

Number

Low Value

Fixed Increment

Dependent Values (R). Dependent Value

226

B • TABLES• • • • •

B • Tables

TALLIES Element Properties

Number

Output File

Report ID

Data Type

Category

Process ID

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


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


228

B • TABLES• • • • •

B • Tables

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

VARIABLES Element Properties

Number

1-D Array Index

2-D Array Index

Data Type

Clear Option

Category Type

Response Category Type


I/O Point

Usage

Description

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


• •

• •

Ending Direction

Number of Zones

Length of Each Zone

Link Type


Network ID

Inv_SEGMENTS Element Properties

Beginning Station

Next Station

Length

Segment Set ID

Inv_SETS Element Properties

Set Name

Inv_STATESETS Element Properties

Properties

Stateset Type

State Set ID

Inv_LINKS Element Properties

230

B • TABLES• • • • •

B • Tables

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

Fixed_ARR5 Element(Arrivals) Properties

Type

Type ID

Time

Interval or Key

Offset

Max Batches

Max Time

Batch Size

Variable ID 1

Value 1

Variable ID 2

Value 2

Variable ID 3

Value 3

Variable ID 4

Value 4

Variable ID 5

Value 5


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


Fixed_ATT10R Element (Attributes) Properties

Number

1-D Array Index

2-D Array Index

Data Type

232

B • TABLES• • • • •

B • Tables

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


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

Fixed_ATT10R Element (Attributes) Properties

233


• •

• •

Description


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


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• • • • •

B • Tables


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


Number

1-D Array Index

2-D Array Index

Data Type


I/O Point

Usage

Description

235


• •

• •

Fixed_EXP5 Element(Expressions) Properties

Number

1-D Array Index

2-D Array Index

Data Type

Expression 1

Expression 2

• • • •

Expression 5


I/O Point

Usage

Description

Fixed_EXP10 Element (Expressions) Properties

Number

1-D Array Index

2-D Array Index

Data Type

Expression 1

Expression 2

• • • •

Expression 10


I/O Point

Usage

236

B • TABLES• • • • •

B • Tables

Description


237


• •

• •


Number

1-D Array Index

2-D Array Index

Data Type


I/O Point

Usage

Description


Number

1-D Array Index

2-D Array Index

Data Type

Expression 1

Expression 2

• • • •

Expression 15


I/O Point

Usage

Description

238

B • TABLES• • • • •

B • Tables


Number

1-D Array Index

2-D Array Index

Data Type

Expression 1

Expression 2

• • • •

Expression 20


I/O Point

Usage

Description


Number

1-D Array Index

2-D Array Index

Data Type

Expression 1

Expression 2

• • • •

Expression 25


I/O Point

Usage

239


• •

• •

Description


240

B • TABLES• • • • •

B • Tables


Number

1-D Array Index

2-D Array Index

Data Type

Expression 1

Expression 2

• • • •

Expression 50


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


• •

• •

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


Fixed_FRE50 Element (Frequencies) Properties

242

B • TABLES• • • • •

B • Tables

Fixed_LEV50 Element (Levels) Properties

Number

1-D Array Index

2-D Array Index

Value 1

Value 2

• • • •

Value 50


Fixed_PAR50 Element (Parameters) Properties

Number

1-D Array Index

2-D Array Index

Value 1

Value 2

• • • •

Value 50


243


• •

• •

Fixed_RAT10R Element (Rates) Properties

Number

1-D Array Index

2-D Array Index


Fixed_RAT50 Element (Rates) Properties

Number

1-D Array Index

2-D Array Index

Value 1

Value 2

• • • •

Value 50


244

B • TABLES• • • • •

B • Tables

Fixed_REC20 Element (Recipes) Properties

Static Name 1

Value 1

Static Name 2

Value 2

• • • •

Static Name 20

Value 20


Fixed_REC50 Element (Recipes) Properties

Static Name 1

Value 1

Static Name 2

Value 2

• • • •

Static Name 50

Value 50


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 50

Failure ID 50


Failures (R). Failure. Failure ID. Failure Entity Rule

246

B • TABLES• • • • •

B • Tables

Fixed_RLN50 Element (Reportlines) Properties

Number

Report ID

Format

Expression 1

Expression 2

• • • •

Expression 50


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


Number

Stations (R)

Station ID

Variable 1

Value 1

Variable 2

Value 2

• • • •

Variable 20

Value 20


248

B • TABLES• • • • •

B • Tables


Number

Stations (R)

Station ID

Variable 1

Value 1

Variable 2

Value 2

• • • •

Variable 40

Value 40



Number

Stations (R)

Station ID

Variable 1

Value 1

Variable 2

Value 2

• • • •

Variable 50

Value 50


249


• •

• •


Number

Stations (R)

Station ID

Variable 1

Value 1

Variable 2

Value 2

• • • •

Variable 100

Value 100

Assignments (R) Variable Value


Number

Stations (R)

Station ID

Variable 1

Value 1

Variable 2

Value 2

• • • •

Variable 250

Value 250

Assignments (R) Variable Value

250

B • TABLES• • • • •

B • Tables

Fixed_SET50 Element(Sets) Properties

Member 1

Member 2

• • • •

Member 50

Members (R). Member

Fixed_STA50 Element (Statesets) Properties

Number

State Name 1

Stateset Type 1

State Name 2

Stateset Type 2

• • • •

State Name 50

Stateset Type 50

States (R). State Name. Stateset Type

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• • • • •

B • Tables

Position ID 2

Zone 2

Initial Status 2

Vehicle Size 2

Size Integer 2

• • • •

Initial Position 50

Position ID 50

Zone 50

Initial Status 50

Vehicle Size 50

Size Integer 50

Unit Data (R). Initial Position. Position ID. Zone. Initial Status. Vehicle Size. Size Integer

Fixed_VAR2R Element (Variables) Properties

Number

1-D Array Index

2-D Array Index

Clear Option

Category Type


Data Type

Fixed_TRA50 Element (Transporters) Properties

253


• •

• •

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


Data Type

Value 1

Value 2

• • • •

Value 10


I/O Point

Usage

Description


254

B • TABLES• • • • •

B • Tables


Number

1-D Array Index

2-D Array Index

Clear Option

Category Type


Data Type

Initial Values (R). Value 1. Value 2. • • • •. Value 10

I/O Point

Usage

Description


Number

1-D Array Index

2-D Array Index

Clear Option

Category Type


Data Type

Value 1

Value 2

• • • •

Value 50

255


• •

• •


I/O Point

Usage

Description


Number

1-D Array Index

2-D Array Index

Clear Option

Category Type


Data Type

Value 1

Value 2

• • • •

Value 200


I/O Point

Usage

Description


256

B • TABLES• • • • •

B • Tables

Data TypesAs 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 definitionsThe 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 AccmLength

Values AttrID, real

Data Type Name ActivityAreaLevel

Values Integer

Data Type Name AllorSpecific

Values “All”, “Specific”

Data Type Name ArrivalTime

Values “Time”, “First”, “Last”, “Warmup”, “Every”, “Keyhit”, “Message”

Data Type Name ArrivalType

Values “Station”, “Queue”, “Block”, “Event”

257


• •

• •

Data Type Name AttrID

Values IdOrInt, SymbolName “(“ Integer “)”, SymbolName “(“ Integer “,” Integer “)”, “A(“ Integer “)”

Data Type Name BasicTimeUnit

Values “Seconds”, “Minutes”, “Hours”, “Days”

Data Type Name Capacity

Values “Capacity”, “Schedule”

Data Type Name ConsOrRange

Values “Constant”, “Range”

Data Type Name ConvType

Values “Accumulating”, “Nonaccumulating”

Data Type Name CountInitOpt

Values “Replicate”, YesOrNo

Data Type Name CrossDir

Values “Positive”, “Negative”, “Either”

Data Type Name CrossDirPosNeg

Values “Positive”, “Negative”

Data Type Name Date

Values Date

258

B • TABLES• • • • •

B • Tables

Data Type Name DateTime

Values Date, Time

Data Type Name Day

Values “11”, “12”, “13”, “14”, “15”, “16”, “17”, “18”, “19”, ”20”, “21”, “22”, “23”, “24”, “25”, “26”, “27”, “28”, “29”, “30”, “31”, MD1

Data Type Name DistExp

Values “EXPO(Mean)”, “NORM(Mean,StdDev)”,

“TRIA(Min,Mode,Max)”, UNIF(Min,Max)”,

“ERLA(ExpoMean,k)”,

“GAMM(Beta,Alpha)”, “JOHN(G,D,L,X)”,

“LOGN(LogMean,LogStd)”,

“POIS(Mean)”, “WEIB(Beta,Alpha)”,

“CONT(P1,V1,...)”, “DISC(P1,V1,...)”, Expression

Data Type Name EnabledDisabled

Values “Enabled”, “Disabled”

Data Type Name EndOpt

Values “Error”, “Dispose”, “Rewind”, “Ignore”

Data Type Name EntRule

Values “Preempt”, “Ignore”, “Wait”

Data Type Name EventType

Values “User”, “VBA”, “ActiveX”

259


• •

• •

Data Type Name FailType

Values “Count”, “Time”

Data Type Name Failure

Values “Failure”

Data Type Name FileAccType

Values “Sequential”, “Direct”, “User”

Data Type Name FileFormat

Values AnyCharacters

Data Type Name FileName

Values AnyCharacters

Data Type Name FileStructure

Values “Unformatted”, “Free Format”, “WKS File”, FileFormat

Data Type Name FlowAllocation

Values “ValueAdded”, “NonValueAdded”, “Wait”, “Transfer”, “Other”

Data Type Name FlowType

Values “Add”, “Transfer”, “Remove”

Data Type Name FormatType

Values “Duration”, “Calendar”

260

B • TABLES• • • • •

B • Tables

Data Type Name FreqExp

Values “Value”, “State”

Data Type Name GlobalPriority

Values “QTIME”, “LVF”, “HVF”

Data Type Name IdOrInt

Values SymbolName, Integer

Data Type Name IdOrIntOrRange

Values SymbolName, Integer “-” Integer, Integer, SymbolName “-” SymbolName

Data Type Name IdOrIntOrReal

Values SymbolName, Integer, Real

Data Type Name IdOrRealorKey

Values SymbolName, Real, “INFINITE”

Data Type Name InitOpt

Values “Hold”, “Rewind”, “Close”

Data Type Name InitVar

Values “J”, “M”, “NS”, “IS”, “X” “(“ Integer”)”

Data Type Name LinkType

Values “Unidirectional”, “Bidirectional”, “Spur”

261


• •

• •

Data Type Name Location

Values “Station”, “Intersection”, “Link”

Data Type Name LSR

Values “FCFS”, “LCFS”, “Closest”, “Farthest”, “LVF”, “HVF”

Data Type Name MD1

Values “1”, “2”, “3”, “4”, “5”, “6”, “7”, “8”, “9”, “10”, “01”, “02”, “03”, “04”, “05”, “06”, “07”, “08”, “09”

Data Type Name Method

Values “RKF”, “Euler”, “User”

Data Type Name Month

Values “11”, “12”, “13”, “14”, “15”, “16”, “17”, “18”, “19”, “20”, “21”, “22”, “23”, “24”, “25”, “26”, “27”, “28”, “29”, “30”, “31”, MD1

Data Type Name NonNegativeReal

Values Non Negative Real

Data Type Name DataNonNegativeRealorSymbol

Values Non Negative Real, SymbolName

Data Type Name NonNegativeRealSymbolName

Values Non Negative Real, SymbolName, “NONE”

262

B • TABLES• • • • •

B • Tables

Data Type Name PositiveInteger

Values Positive Integer (optional min, max values)

Data Type Name PositiveReal

Values Positive Real

Data Type Name PreemptDest

Values Label, “STO”“(“ IdOrInt “)”

Data Type Name QBlock

Values Label, “SHARED”

Data Type Name QSR

Values “CYC”, “RAN”, “POR”, “LRC”, “SRC”, “LNQ” , “SNQ”, “UR” “(“ IdOrInt “)”, “ER” “(“ IdOrInt “)”

Data Type Name QuotedString

Values Quoted String

Data Type Name RangeIndex

Values Integer, Integer “..” Integer

Data Type Name RankingCrit

Values “FIFO”, “LIFO”, “LVF”, “HVF”

Data Type Name RealorInfinite

Values Real, “Infinite”

263


• •

• •

Data Type Name RealorSymbolName

Values Real, SymbolName

Data Type Name RegulatorTimeUnit

Values “Per Second”, “Per Hour”, “Per Minute”, “Per Day”

Data Type Name RepLengthTimeUnit

Values “Hours”, “Days”, “Weeks”

Data Type Name ResourceAction

Values “Hold”, “HoldUntil”

Data Type Name ResourceorSet

Values “Resource”, “Set”

Data Type Name RSR

Values “CYC”, “RAN”, “POR”, “LRC”, “SRC”, “LNB”, “SNB”, “UR” “(“ IdOrInt “)”, “ER” “(“ IdOrInt “)”

Data Type Name ResourceType

Values “Stationary”, “Positional”, “Distance”, “Network”

Data Type Name RestrColumn

Values “Exclude”, “Include”

264

B • TABLES• • • • •

B • Tables

Data Type Name Rule

Values “CYC”, “RAN”, “POR”, “LDS”, “SDS”, “LRC”, “SRC”, “LNQ”, “SNQ”, “LNB”, “SNB”, “UR”, “ER”, “MIN”, “MAX”

Data Type Name SaveCrit

Values “First”, “Last”, “Product”, “Sum”

Data Type Name SeedInitOpt

Values YesOrNo, “Common”, “Antithetic”

Data Type Name SensorLocationType

Values “Specific Level”, “Percentage Capacity”

Data Type Name Severity

Values “Fatal”, “Warning”, “No”

Data Type Name SignedInteger

Values Signed Integer (optional min, max values)

Data Type Name Sort

Values “Ascending”, “Descending”, “Unsorted”

Data Type Name StateSetType

Values “Idle”, “Busy”, “Inactive”, “Failed”, IdOrInt

Data Type Name Status

Values “Active”, “Inactive”

265


• •

• •

Data Type Name SystemMap

Values “Distance”, “Network”

Data Type Name Time

Values Time

Data Type Name TSR

Values “CYC”, “RAN”, “POR”, “LDS”, “SDS”, “UR”, “ER”

Data Type Name UnitTimeUnit

Values “Seconds Per Unit”, “Minutes Per Unit”, “Hours Per Unit”, “Days Per Unit”

Data Type Name VehicleSize

Values “Length”, “Zone”

Data Type Name Year

Values Integer

Data Type Name ZoneControl

Values “Start”, “End”, Integer

266

B • TABLES• • • • •

B • Tables

Connection point data types and SIMAN blocks

Entry/exit point typesThere are six different entry point types and six different exit point types, as noted below.

DESCRIPTIONS

The three different entry types (Hold Type A, B, and C) are used to distinguish those modules that can connect to a QPick module (Access, Request, etc.) and those that cannot (Capture, Group). The Hold Type B is used when a Queue block is required.

A Seize entry type is required for the Select exit type since only a Seize module can follow a Select module.

CONNECTION VALIDATION

Entry Types Exit Types

Standard Standard

Queue Queue

Seize PickQ

Hold Type A QPick

Hold Type B Select

Hold Type C Balk

Exit Type Entry Type

Standard Standard, Queue, Seize, Hold Type A, Hold Type C

Queue Seize, Hold Type A, Hold Type B, Hold, Type C

PickQ Queue

QPick Seize, Hold Type A, Hold Type B

Select Seize

267


• •

• •

CONNECTION TYPES ON SIMAN MODULES

Block Connection Type

Access Hold Type A

Allocate Hold Type A

Capture Hold Type C

Combine Hold Type C

Group Hold Type C

PickQ PickQ (on queue label), Standard (on balk label)

Preempt Hold Type A

Proceed Hold Type C

QPick QPick (on hidden next label), PickQ (on queue label)

Queue Queue (Entry point), Queue (Exit Point on hidden next label)

Request Hold Type A

Scan Hold Type C

Seize Seize

Select Hold Type A, Select

Wait Hold Type C

268

C • Creating Online Help

C Creating Online Help FilesArena provides template developers with a help interface that easily allows designers to associate online help files with their templates, providing template users with detailed instructions on the use of various modules and their options.

Here is an example of how the template help interface works. Let’s assume that you have created a template called Sample.tpl that contains a module called Server. Let’s also assume that the Server module’s main dialog looks like this:

Figure C.1 Main dialog of the Server module

The repeat group and secondary dialog (Server Names and Options) look like this:

Figure C.2 Server Names Repeat Group Figure C.3 Options Secondary dialogdialog

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 4293984255#define Server 4294443008#define Server_ 0#define Server_Server_Names 524288#define Server_Server_Name 1048576#define Server_Quantity 1572864#define Server_Process_Time 2097152#define Server_Options 2621440#define Server_Cost 3145728

The left column (for example, #define TemplateContents) displays the Help Context ID that will be used by the Help Authoring Tool (for example, RoboHelp®). The right column displays the Help Context Number that will be referenced by Arena. This file serves as a “map” between your Help Authoring Tool and Arena.

The first entry for every template’s .HH file contains the entry #define TemplateContents. This context ID allows template developers to have a Table of Contents topic in the template help file. When a template panel is attached to the Project Bar, the template name is added to the list of attached templates in Arena’s Help menu. Clicking on any of these menu options will automatically display the help topic associated with the TemplateContents context ID. See the instructions below to find out how to associate a context ID with a help topic.

The remaining entries are determined as follows: Each module will have an entry corresponding to the module name (for example, #define Server). By default, this context ID is utilized when you click the Context Sensitive Help toolbar button (on the Standard toolbar) and then click on a module button in the Project Bar. This could be used to display a general overview of the types of uses for that module. This behavior may be changed by editing the Module Help Option in the Template Options dialog.

In Arena, every module dialog (including secondary dialogs and dialogs displayed when adding or editing items in repeat groups) contains a Help button. Each Help button may display either the main help topic for that module or a unique help topic for that particular dialog of the module. For example, the Server module displayed above has three dialogs: the main dialog (Server), and two secondary dialogs (Server Names repeat group and Options). Each of these dialogs has a Help button. The Server dialog’s Help button will display the main help topic for the module. The Server Names dialog may display either the main help topic (as displayed by the Server dialog) or a unique help topic specific to the Server Names dialog. The Options dialog may display either the main help topic (as displayed by the Server dialog) or a unique help topic specific to the Options dialog.

270

C • CREATING ONLINE HELP FILES• • • • •

C • Creating Online Help

To enable or disable unique help topics for individual dialogs, you specify a dialog form object’s UniqueHelpTopic property as True or False in the module definition’s dialog design window. By default, this property is set to True for a dialog form. If you enable a unique help topic for a particular dialog but fail to create a corresponding topic in your help file, users who press the Help button in that dialog will receive a message from the Windows® Help system indicating that the topic does not exist in the help file. Therefore, you should always set the UniqueHelpTopic to True if you do not intend to create a help topic specific to the dialog.

Similarly, in the module definition’s dialog design window, each dialog form object includes a WhatsThisHelp property that is specified as True or False. This option will provide the dialog with a question mark in the top right of the title bar, allowing the user to ask for help on a specific operand in the dialog. If you enable this option but fail to provide a topic for each specific operand in your help file, users who click the question mark and then click an operand will receive a message that the topic does not exist. Therefore, you should not enable the “What’s This?” help option if you do not intend to create a help topic for each operand in the dialog.

When the help interface (.HH) file is generated along with the .tpo file, the context IDs are written for each dialog according to the following rules: the main dialog’s context ID is created by appending an underscore (_) to the module name, for example, Server_. The context IDs for all other dialogs are created by appending the dialog name to the module name, separated by underscores; spaces embedded in dialog and repeat group names are converted to underscores. For example, the Server Names dialog would generate a context ID of Server_Server_Names. The Options dialog’s context ID would be Server_Options.

Context IDs for “What’s This?” help are created for each operand by appending the operand name to the dialog name with an underscore. For example, the Server Names dialog would generate context IDs Server_Server_TimeName and Server_Quantity for the operands Server Name and Quantity within the Server Names dialog.

To use the help interface file generated above, you need to first use your Help Authoring Tool to create help information in the form of “topics.” Next you tell your Help Authoring Tool that you have a help interface or “map” file (for example, Sample.HH). To do this in RoboHelp, you need to add the file to the list of “map files” for the project by following the procedure outlined below:

1. From the Project menu, choose Setup.

2. Click the Advanced tab. Under the Setup Section heading, highlight the (Map)/Include Files item, then click the Setup Section heading.

3. Choose the help interface file provided by Arena (e.g., Sample.HH) from the list and click Add.

4. Click OK several times until you’ve closed all the dialogs and are back to the help document.

271


• •

• •

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

Index

AAccelerator keys 108Advanced Process panel 2, 179Advanced Transfer panel 2, 179Animation object

display in user view 164in logic window 113

Arena Symbol Factory 4Arena template 178Assign module 45Auto-Create 74, 95

BBack quote character

use for referencing operand 114Basic Process panel 2, 178

CChanges to instances 74Check boxes

customizing options 141special access for references in logic window

120Clipboard 74, 111, 113, 165, 176Compatibility of existing module instances

74Conditional assignment module 152Contact information 5Creating online help files 269Customer Support Center 4

DDataType property

SIMAN 100standard 100

Decide module 44

Defining modeling logic 40Delay module 48Design Properties grid 83Dialog Design toolbar 108Dialog Design window 33

Design Properties grid 83dialog form objects 79hidden operands 79Operand Explorer 78operand objects 79repeat group objects 79Toolbox 80Toolbox controls

CheckBox 81ComboBox 81DatePicker 81DateTimePicker 81DialogButton 81FilePicker 81GroupBox 81HiddenOperand 81Line 81RadioButtonGroup 81RepeatGroupDialog 81RepeatGroupTable 81Text 81TextBox 81TimePicker 81

View Dialog Form button 78Dialog form 81

arranging controls 83layout 39locking controls 83opening 82resizing 83

Direct connection 121in module logic 123

273


• •

• •

Distances element 198Document conventions 3Documentation set 3Draw object

hidden/visible layer 163in user view 163

EElement 177

data elements 177define vs. reference option 185defining through hierarchy 179, 183defining via element operand 179lists 180, 182

sub-lists 182, 185special types

fixed-length 196hidden 197inverted 198

switches on elements 195Elements panel 179entry 93Entry point

operand reference in logic window 123operand validation/reference 94operands 37switches attached 160user view object 160

Errors/warnings 67reviewing 68

Exit pointoperand 37operand validation/reference 94repeatable 131switches attached 160user view object 160

FField

use in Logic Window chapter 113

GGlobal pictures 55

HHelp file creation 269Help interface file 271Hidden operands 79

IInUserView property 101

LLoading a template panel library (.tpl) file 66Logic window

attaching switches 146connecting module instances 142decomposing processes 109design hints 207detaching switches 146differences with model window 111hidden module (utlarena.tpo) and switches

150multiple connections and switches 142opening 110repeating exit points and single connection

143rules and guidelines 154switches in module instances 121verifying logic relative to switches 149

LogicProperties property 92repeat groups 102

MModel window

differences with logic window 111Module 95

handle 157, 159process of building logic 41repeater 133required option 72types of entity flow 121

Module definitionchanges and existing instances 74copying 74deleting 66operand references 114

274

INDEX• • • • •

Index

renaming 66Module definition window 65

opening 67Module handle 159Module instance

use in model or logic window 110Module-building tutorial 29

Assign module 45Decide module 44Delay module 48Process module 45Queue module 42Queues element 50Release module 48Seize module 42Variables element 50

NName property 91

repeat groups 102NetworkLink element 198Number of Alternate Outputs 134

OOnline help 3Opening a module definition window 67Opening a new template panel library (.tpl) file

65Operand

default value 115, 192design hints 205display in user view 161

repeatable operand 162element 183property 187

defining element and property using hidden operand 192

repeat group 188references to 111switching multiple with references to

provided set 117template panel library (.tpl) file operand

report 68value reference in switch definition 171

Operands

basic 92element 92entry point 93exit point 94hidden 101property 93special functions 97specifying the DataType property 99specifying the InUserView property 101specifying the LogicProperties property

92specifying the Name property 91specifying the SwitchName property 101specifying the Value property 96

Operands, using 91

PPanel icon 175

design hints 206size and display in template panel 72, 176

Panel icon window 175tutorial 56

Process module 45Project Bar 9, 23, 58, 71, 72Property 177, 180

switches on properties 196

QQueue module 42Queues element 50

RRadio button group

customizing options 141special access for references in logic window

120Referencing operands

animation objects in user view 164combining repeating and non-repeating

references 131concatenating text and reference 115containing multiple references 116entry point operands 123in switch definition 171multiple references to same operand 119

275


• •

• •

repeating exit point 133repeating operands 127

Release module 48Repeat group 102

switch use 173Repeat group objects 79Repeat 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 104reference rules 125specifying the LogicProperties property

102specifying the Name property 102

Repeatable logic 133Repeatable module 133Review errors 68

SSample models 3Segments element 198Seize module 42Sets element 198SIMAN template 179Simulation logic and module design 109SMARTs library 3Station transfer 121

in module logic 122Statistics

hints for designing in module 209Submodel 109Switch 169

and element 195and property 196attached to user view animation object

165defining 170definition 70, 169, 171

operand comparison with value 172in logic window module instance 121name 170rules regarding definitions 172template panel library (.tpl) file switch report

68

use in logic window 146use in module definition windows 170

TTechnical support 4Template

documenting 208Template Development toolbar 33Template panel 65

changing the display name 71creating new window 32detaching 75icon size and display 72private 71

Template panel library (.tpl) filechanges and existing module instances 74checking for errors/warnings 67

Template panel object (.tpo) filechanges and existing instances 74generate .tpo in template window 67, 70providing to modeler 70rules regarding attachment to logic windows

112Template window

closing 66deleting a module 66generating the template panel object (.tpo)

file 70renaming a module 66report 68template options 71version 70

Toolbox, usingCheckBox control 86ComboBox control 85DatePicker control 89DateTimePicker control 88DialogButton control 87FilePicker control 90GroupBox control 85HiddenOperand control 91Line control 85RadioButtonGroup control 86RepeatGroupDialog control 87RepeatGroupTable control 88Text control 84

276

INDEX• • • • •

Index

TextBox control 85the controls 83TimePicker control 89

Tracedesign hints for use in module definition

208Trace in module definitions 153Training courses 5Tuple

value of switch in 173

UUser view 157

design hints 207designing 53modifications by modeler 158

User view window 157tutorial 53

Utlarena.tpo file 150conditional assignment module 152hidden module 150

VValue property 96Variables element 50

WWeb support 4What’s This? help 271

Context IDs 271World units 157

277


• •

• •

278

Date post:	18-Apr-2015
Category:	Documents
Upload:	jhonnyoti
View:	68 times
Download:	11 times

Arena Template Developer's Guide

Documents