Arendg Rm001 en p

Arena

TEMPLATE DEVELOPERS GUIDEPUBLICATION ARENDG-RM001D-EN-PNovember 2007Supersedes Publication ARENDG-RM001C-EN-P

Contact Rockwell

Customer Support Telephone 1.440.646.3434 Online Support http://www.rockwellautomation.com/support/ 2007 Rockwell Automation Technologies, Inc. All rights reserved. Printed in USA. This document and any accompanying Rockwell Software products are copyrighted by Rockwell Automation Technologies, Inc. Any reproduction and/or distribution without prior written consent from Rockwell Automation Technologies, Inc. is strictly prohibited. Please refer to the license agreement for details. Arena, Rockwell Automation, and SIMAN are registered trademarks of Rockwell Automation, Inc. ActiveX, Microsoft, Microsoft Access, SQL Server, Visual Basic, Visual C++, Visual SourceSafe, Windows, Windows ME, Windows NT, Windows 2000, Windows Server 2003, and Windows XP are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Adobe, Acrobat, and Reader are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries. ControlNet is a registered trademark of ControlNet International. DeviceNet is a trademark of the Open DeviceNet Vendor Association, Inc. (ODVA) Ethernet is a registered trademark of Digital Equipment Corporation, Intel, and Xerox Corporation OLE for Process Control (OPC) is a registered trademark of the OPC Foundation. Oracle, SQL*Net, and SQL*Plus are registered trademarks of Oracle Corporation. All other trademarks are the property of their respective holders and are hereby acknowledged. This product is warranted in accordance with the product license. The products performance may be affected by system configuration, the application being performed, operator control, maintenance and other related factors. Rockwell Automation is not responsible for these intervening factors. The instructions in this document do not cover all the details or variations in the equipment, procedure, or process described, nor do they provide directions for meeting every possible contingency during installation, operation, or maintenance. This products implementation may vary among users. This document is current as of the time of release of the product; however, the accompanying software may have changed since the release. Rockwell Automation, Inc. reserves the right to change any information contained in this document or the software at anytime without prior notice. It is your responsibility to obtain the most current information available from Rockwell when installing or using this product. Version: 12.00.00 (CPR9) Modified: October 8, 2007 12:10 pm

Copyright Notice

Trademark Notices Other Trademarks

Warranty

ii

Contents1 WelcomeWhat is Arena simulation software? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intended audience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . About this guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Where can I go for help? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reference the users guides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Explore our examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Get help. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Use the SMARTs library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Access the Arena Symbol Factory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Get phone support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Get Web support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Get training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Get consulting services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Contact us . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11 2 2 3 3 3 3 3 4 4 4 5 5 5

2 Arena Template Development Overview

7

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

iii

ARENA TEMPLATE DEVELOPERS GUIDE

3 Module-building TutorialModule overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Getting startedA new template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dialog Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The dialog design window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding the modules dialog operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding the module's entry/exit point operands . . . . . . . . . . . . . . . . . . . . . . . . . . Arranging the Dialog form layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The logic window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overview of the Printer module logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Receiving entities and seizing the printerThe Queue and Seize modules . . . . Deciding whether to changeover the printerThe Decide module . . . . . . . . . . . Changeover logicAssign, Process, and Assign modules . . . . . . . . . . . . . . . . . The print logicDelay and Release modules . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining the Printer module elementsQueues and Variables elements . . . . . . User View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Panel Icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A sample model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Preparing the template for use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Single printer simulation model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2929 32 33 33 35 37 39 40 40 41 42 44 45 48 50 53 56 57 57 58 64

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

6565 65 66 66 66 66 66 67 67 67 68 68 70 70 70 71 72

iv

CONTENTS

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

73 73 74 74

5 The Dialog Design Window

77

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

v


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

6 The Logic WindowSimulation logic and module design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The logic window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Differences between logic and model windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . Running simulation models (model window) . . . . . . . . . . . . . . . . . . . . . . . . . . Referencing operands (logic window) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Switching module instances (logic window) . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining repeatable logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Module connections in the logic window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Attaching template panels while working in a logic window . . . . . . . . . . . . . . Display of animation objects (logic window). . . . . . . . . . . . . . . . . . . . . . . . . . . Fields and operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Referencing module data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Referencing operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Special access for check boxes, radio button groups, and combo boxes . . . . . . Switches in logic window module instances . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining transfer of entities into and out of a module . . . . . . . . . . . . . . . . . . . . Referencing non-repeating operands from a repeat group . . . . . . . . . . . . . . . . . Referencing repeating operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining repeatable exit points in a module . . . . . . . . . . . . . . . . . . . . . . . . . . . . Repeatable modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 1: Parallel logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 2: Serial logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 3: Defining alternate outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Customized options using radio button and check box controls . . . . . . . . . . . . Module connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using graphical connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining multiple connections from a single exit point . . . . . . . . . . . . . . . . . . . Repeating exit points in the logic window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Switching module instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Attaching and detaching switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Effect of switches in the logic window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Arenas utility modules (from utlarena.tpo) . . . . . . . . . . . . . . . . . . . . . . Defining module trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Logic definition rules and guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

109109 109 111 111 111 112 112 112 112 113 113 114 114 120 121 121 125 127 131 133 135 137 139 141 142 142 142 143 146 146 147 150 153 154

7 The User View Window

157

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

vi

CONTENTS

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

158 159 159 160 161 163 164 166

8 The Switch WindowDefining switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Switch names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Switch definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Switch definition rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

169169 170 171 172

9 The Panel Icon Window

175

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

10 ElementsDefining elements in modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Element lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Use of elements and properties in module definitions . . . . . . . . . . . . . . . . . . . . . . . Access to properties in a model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Displaying element lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining elements via hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Element operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining element operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sub-lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining and referencing elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Property operands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining Property operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining repeating properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining an element/property using a hidden operand. . . . . . . . . . . . . . . . . . . . Switches and elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Special element types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fixed-length elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hidden element list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

177179 179 180 180 181 181 182 183 183 183 185 185 187 187 188 192 195 196 196 197

vii


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

A Template Design GuidelinesDialog box design (dialog design window) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dialogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Operand objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Helpful hints for defining objects in the dialog design window. . . . . . . . . . . . . General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Panel icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . User view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Module logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Naming conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Template documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Statistics and reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

205205 205 205 206 206 206 207 207 208 208 208 209

B TablesElements and properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Standard elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Inverted elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fixed-length elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data type definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Connection point data types and SIMAN blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . Entry/exit point types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

211211 211 229 231 257 257 267 267

C Creating Online Help Files

269 273

Index

273

viii

1

Welcome1 Welcome

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

1


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

Figure 1.1 Arenas Template Window selection

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

Intended 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 Arenas Basic Process, Advanced Process, and Advanced Transfer templates. This guide assumes that you are familiar with Arena modeling concepts and terminology, which are presented in the Arena Users Guide and online help.

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

2

1 WELCOME

Where can I go for help?Our commitment to your success starts with the suite of learning aids and assistance we provide for Arena. Whether youre new to simulation or a seasoned veteran putting a new tool to use, youll quickly feel at home with Arena simulation software.1 Welcome

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

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 commonly used approaches for capturing the essence of manufacturing processes. Examples are provided for both job shop and flow shop environments. For a description of and list of Arenas examples, go to Help > Arena Help. On the Contents tab, choose Model Building Basics, and then select Viewing Arena Example Models.

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

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

Get phone 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. ARENATECHNICAL SUPPORT INCLUDES:

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

Get Web 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 WELCOME

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

Get 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 thats right for you! Simply contact our consulting services group to discuss how we can help you achieve success in your simulation efforts.

Get consulting 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 improvement efforts. Toward this objective, we invite you to contact your local representative or Rockwell Automation at any time that we may be of service to you. Support E-mail: [email protected] Corporate E-mail: [email protected] Support phone: 1.440.646.3434 URL: www.ArenaSimulation.com URL: www.rockwellautomation.com

5


6

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

Modeling with ArenaAn 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 modules activities during a simulation run. This section provides a brief overview of model building with Arena. For information about using Arena to build, animate, and analyze simulation models, refer to the Arena Users Guide and online help. To use a module in an Arena model, a panel containing the module is attached to the Project Bar. This panel displays all of the modules that may be selected for placement in the model. To build a model, you select a module from the panel and place it in the model window. The graphics associated with the module, referred to as its user view, are added to the model window. This display of the module always contains a module handle (typically the module name) and may include static drawing objects, animation objects, operand display values, and connection points, as illustrated in Figure 2.1.

Figure 2.1 Process module user view

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

Templates and 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 selfcontained group. The panels commonly used for standard Arena modeling include: Basic Process, Advanced Process, and Advanced Transfer. Each panel consists of related

8

2 ARENA TEMPLATE DEVELOPMENT OVERVIEW

modeling constructs; together, these are documented and referred to as the Arena template. Similarly, the SIMAN template contains two panels: Blocks and Elements. Arena modelers attach template panels to the Project Bar in the application window of the Arena modeling environment. The Project Bar hosts the primary objects used to build a model, so the modeler selects modules from the appropriate Project Bar panel and places them in the model window. The template file that is attached to the Project Bar is called the template panel object file (or .tpo file). The panel displays a list of the modules contained in the .tpo file. When developing your own template, you work with a template panel library file (or .tpl file). This file contains the definitions of the modules in the template panel. The concepts of module definitions and instances are discussed in the next section. To work with a template panel file, you can create a new file by selecting the File > New menu item in Arena and choosing the Template Window option; or use the File > Open menu item to open an existing .tpl file. In either case, you access the module definitions contained in the template panel via a template window, as shown in Figure 2.2. (See The Template Window on page 65 for additional information.)

2 Overview

Figure 2.2 Sample template window

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

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 characteristics. For example, the default main dialog for the Create module (provided by the Arena templates Basic Process panel) displays eight operands that the modeler may edit: the module Name or label, the Entity Type (Entity 1, by default), information related to the time between arrivals (the Type, Value, and the number of Units), the number of Entities per Arrival, the Maximum number of Arrivals, and the time of First Creation. (See Figure 2.3.)

Figure 2.3 Main dialog for Create module

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

10

2 Overview


customers arrive at varying times or rates. First, a Create module is placed in the model window. The modeler may change the values of the Create module instances operands. For example, the first customer type may utilize the default arrival stream, which is random (exponential). A second type of customer may arrive at a Constant rate. In that case, a modeler might change the value in one instance of the Create modules to Constant. Note that by changing the value in an instance, the modeler does not modify the definition. In the case of the Create module, the next instance (and all instances, until edited) will have a default type of arrival stream of Random (from the module definition). Module instances may be placed in Arena model windows (and later saved in model .doe files) or in the logic windows of new module definitions (to be saved in .tpl files). For simplicitys sake, we usually discuss use of module instances by the modeler (suggesting placement in model windows) in this guide. As you are reading, however, keep in mind that instances of the modules you are defining may be used either in a simulation model or in the definition of a module in another template panel.

Defining a 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


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

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

2 Overview

Figure 2.6 Basic Process template panel

13


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

Figure 2.7 Create module panel icon

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

Figure 2.8 Process module instances default user view

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

14


Figure 2.9 Modified Process module instances 2 Overview

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

Figure 2.10 User view window of the definition of Arenas Process module

Dialog design and 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 names value and the current simulation time, instead of simply increasing or decreasing a specified count. In a template panel library (.tpl) file, the Dialog Design window is the interface for defining the dialog form layout(s) and operands of a module definition. In this window, a module designer defines dialog sizes, data displayed to and entered by the user, default and permissible values, and the layout of interface controls. The dialog design window includes an Operand Explorer section to browse the module definition's hierarchy of dialogs (many modules contain multiple dialogs), operands, and repeat groups (for defining repeatable operands or sets of operands, such as the resources to be utilized in a process). It also includes a Toolbox section to add user interface controls to the modules dialog forms and a Design Properties grid to edit the properties of one or more selected objects.

16

2 Overview


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

Figure 2.12 Dialog design window for the Batch modules definition

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

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 definitions logic, is very similar to an Arena model window; you attach panels to the Project Bar, select and place modules, and edit the module instances youve created.

17


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

Figure 2.13 Dialog for hospital Admissions Clerk module

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

18

2 Overview


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

Figure 2.14 Operand references in Process module for Admissions Clerk module

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

19


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

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 modules operands) if Type is Count; a Tally block is used (with varying information) if Type is Entity Statistics, Time Interval, Time Between, or Expression. And finally, while not used in the Record module, user view animation may display pertinent information, based on a users input values. To define this behavior, objects called switches are created in the module definition. These switches are placed in a switch window, as shown in Figure 2.15.

Figure 2.15 Sample switch window

20

2 Overview


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

Figure 2.16 Tally Block with attached switch in logic window

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

21


Elements and 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 operands LogicProperties property that the operand type is Element. Similarly, an operand that defines a property of an element is given the type Property. The chapter Elements presents a more detailed discussion of the concept of elements and their properties. Refer to the The Dialog Design Window on page 77 for information about defining element and property operands.

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

22

2 Overview


represent subsets of a process or set of similar processes may be developed and verified once, then may be reused to define new, higher-level modules that correspond to a process; such as a computer CPU, a ticket agent, or a canning line labeler. The component modules (e.g., select next job to process, enter passenger name, or wrap label) also may be utilized directly in models to capture accurately the nature of complex systems or of system elements that have peculiar facets not represented by higher-level modules. The base modules of Arenas hierarchy represent the SIMAN simulation language. These modules form the SIMAN template, which contains two panels: Blocks and Elements. The Blocks panel consists of modules that generate blocks in a SIMAN model (.mod) file, such as Delay, Branch, etc. Many of the modules in the Arena template are given the same name as Blocks modules and perform the same function as their Blocks panel counterparts. However, the modules in Arena offer options for the types of information that is to be placed in an operand (e.g., whether the type of element to be assigned a value is an attribute, a variable, a picture, etc.), and define both the model logic (i.e., blocks) and elements (i.e., information to be written to SIMANs experiment file). The Elements panel consists of modules that represent each of the element types in the SIMAN experiment (.exp) file, such as resources, queues, counters, etc. Many data modules in the Arena template panels (e.g., resources, queues, conveyors) correspond to modules in the Elements panel. When you build a new module definition, one of the steps is to define the logic associated with the module. In doing this, you attach one or more template panels to the Project Bar and place instances of modules. If these modules come from the SIMAN template (Blocks/Elements panels), when a modeler uses your module, the final SIMAN model and experiment used for a simulation run are generated directly through the modules you placed. This may be thought of as a module utilizing a single level of hierarchy, as illustrated in Figure 2.17.

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

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

23


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

Figure 2.18 Multi-layered hierarchy

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

Flowcharts and data 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 Arenas Basic Process panel: Create, Dispose, Process, Decide, Batch, Separate, Assign, and Record. These are the fundamental processing modules that act on entities. On the other hand, entities do not flow into or out of data modules. These data modules are placed to supply information about elements of a simulation model. Data modules in the Basic Process panel include: Entity, Queue, Resource, Variable, Schedule, and Set.

24


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

Use of templates 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.2 Overview

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

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

Application-focused 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 templates scope is not large enough to encompass a large subset of problems in a particular industry; rather, the modules contained in the template are focused on a particular application that might appear in many systems or facilities. These application-focused templates benefit from Arenas hierarchical structure in the same ways as industry-focused templates: the interface presented to a modeler can be customized to be very familiar (both in terms of graphical animation and the terminology used in module dialogs); and parts, processes, etc., in the target application environments can be represented accurately. In some cases, a modeler might build a template for his/her own individual use. In other cases, templates might be created for use among a few modelers in a common group; many application-focused templates will be shared among different modeling groups in an organization.

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

27


28

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

3 Module-building Tutorial

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

30

3 MODULE-BUILDING TUTORIAL

Figure 3.2 Printer module logic 3 Module-building Tutorial

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

31


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

Getting startedA new 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

3 Module-building Tutorial


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

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

34


Figure 3.5 Design properties of the Printer DialogForm object

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

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

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

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

35


Specify the DataType property as SymbolName. Th

Documents

Arendg Rm001 en p