Arena TEMPLATE DEVELOPER S GUIDE. PUBLICATION ARENDG-RM001D-EN-P November 2007 Supersedes Publication ARENDG-RM001C-EN-P

Transcription

1 Arena TEMPLATE DEVELOPER S GUIDE PUBLICATION ARENDG-RM001D-EN-P November 2007 Supersedes Publication ARENDG-RM001C-EN-P

2 Contact Rockwell Customer Support Telephone Online Support Copyright Notice Trademark Notices 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. Other Trademarks Warranty 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 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: (CPR9) Modified: October 8, :10 pm ii

3 Contents 1 Welcome 1 What is Arena simulation software? Intended audience About this guide Where can I go for help? Reference the user s 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 Arena Template Development Overview 7 Modeling with Arena An overview Templates and panels Module definitions and instances Defining a module Panel icon User view Dialog design and operands Logic Switches Elements and properties Arena hierarchy and SIMAN Flowcharts and data modules Use of templates Introduction General modeling tools Industry-oriented environments Application-focused tools Improving modeling productivity and sharing modeling technology iii

4 ARENA TEMPLATE DEVELOPER S GUIDE 3 Module-building Tutorial 29 Module overview Getting started A new template Dialog Design The dialog design window Adding the module s 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 printer The Queue and Seize modules Deciding whether to changeover the printer The Decide module Changeover logic Assign, Process, and Assign modules The print logic Delay and Release modules Defining the Printer module elements Queues and Variables elements User View Panel Icon A sample model Preparing the template for use Single printer simulation model Summary The Template Window 65 The template menu Creating a new template window Loading an existing template panel file Closing a template Saving the template panel library file Creating and editing modules The module definitions list Opening module definition windows Preparing the template panel for use Checking the template panel for errors and warnings Reviewing errors Template panel file reports Generating the template panel object (.tpo) file Other template panel information Changing the version Template options Defining required modules iv

5 CONTENTS Defining data modules Defining a name operand Creating copies of module definitions Compatibility of existing module instances The Dialog Design Window 77 Dialog Design Window overview The Operand Explorer The Toolbox The dialog form The Design Properties grid Using the Toolbox controls Using the Text control Using the GroupBox control Using the Line control Using the TextBox control Using the ComboBox control Using the RadioButtonGroup control Using the CheckBox control Using the DialogButton control Using the RepeatGroupDialog control Using the RepeatGroupTable control Using the DateTimePicker control Using the DatePicker control Using the TimePicker control Using the FilePicker control Using the HiddenOperand control Using operands Specifying the Name property Specifying the LogicProperties property Specifying the Value property Specifying the DataType property Specifying the SwitchName property Specifying the InUserView property Hidden operands Using repeat groups Specifying the Name property Specifying the LogicProperties property Repeat group definition depth and reference rules Accessing the number of tuples and the tuple number Combining repeating operand values into a single value Using repeatable modules in the logic window with repeat groups v

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

7 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 The Switch Window 169 Defining switches Switch names Switch definitions Switch definition rules The Panel Icon Window 175 Creating the panel icon Elements 177 Defining elements in modules Creating elements Element lists Properties Use of elements and properties in module definitions Access to properties in a model Displaying element lists Defining elements via hierarchy Element operands Defining element operands Sub-lists Defining and referencing elements Property operands Defining Property operands Defining repeating properties Defining an element/property using a hidden operand Switches and elements Special element types Fixed-length elements Hidden element list vii

8 ARENA TEMPLATE DEVELOPER S GUIDE Inverted elements A Template Design Guidelines 205 Dialog box design (dialog design window) Dialogs Operand objects Helpful hints for defining objects in the dialog design window General Panel icon User view Module logic Naming conventions Template documentation Trace Statistics and reports B Tables 211 Elements and properties Standard elements Inverted elements Fixed-length elements Data Types Data type definitions Connection point data types and SIMAN blocks Entry/exit point types C Creating Online Help Files Index 273 viii

9 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-touse 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 Welcome 1

10 ARENA TEMPLATE DEVELOPER S GUIDE button. In the dialog that is displayed, select Template Window and click OK, as shown in Figure 1.1. Figure 1.1 Arena s Template Window selection This template window serves as a home base for the activities involved in building a template. The windows that you work with to define modules are displayed on the same desktop as Arena model, input, and output windows. You interact with these windows using the standard Arena user interface. Intended audience Before you begin to access the capabilities of template building, you should already have developed a good understanding of the basic Arena modeling interface and the either the SIMAN template or Arena s Basic Process, Advanced Process, and Advanced Transfer templates. This guide assumes that you are familiar with Arena modeling concepts and terminology, which are presented in the Arena User s Guide and online help. About this guide The Arena Template Developer s Guide is designed to serve as both an instruction manual for building templates and as a reference guide for the template-building features. We start by presenting two chapters that familiarize you with the concepts and terminology employed in Arena and walk you through a simple module-building tutorial. Following this, we provide a description of the template window, then of each of the five windows that you employ to build modules. Next we present Elements, the final concept related to the definition of Arena modules. Appendix B of this book contains reference tables. To begin your experience with template development, we recommend that you read Chapter 2, Arena Template Development Overview, to become familiar with Arena concepts and terminology. Then, follow the step-by-step instructions provided in the module-building tutorial in Chapter 3. While you are building your first module, you may want to refer to concepts presented in Chapter 2. 2

11 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 you re new to simulation or a seasoned veteran putting a new tool to use, you ll quickly feel at home with Arena simulation software. Reference the user s guides The documentation set includes this manual, Arena Template Developer s Guide, which introduces template creation and module building. In addition, the Arena User s Guide and Variables Guide are separate reference manuals providing module information on the basic of modeling with the Basic Process, Advanced Process, Advanced Transfer, and Flow Process panels as well as complete descriptions of Arena variables found in the Arena product templates. 1 Welcome DOCUMENT CONVENTIONS Throughout the guides, a number of style conventions are used to help identify material. New terms and concepts may be emphasized by use of italics or bold; file menu paths are in bold with a (>) separating the entries (e.g., go to Help > Arena Help); text you are asked to type is shown in Courier Bold (e.g., in this field, type Work Week), and dialog box and window button names are shown in bold (e.g., click OK). Explore our examples Arena is accompanied by a number of sample models that illustrate many of the commonly used approaches for capturing the essence of manufacturing processes. Examples are provided for both job shop and flow shop environments. For a description of and list of Arena s examples, go to Help > Arena Help. On the Contents tab, choose Model Building Basics, and then select Viewing Arena Example Models. Get help Online help is always at your fingertips! Arena incorporates the latest in help features, including What s This? help that displays a brief description of fields in dialogs, contextsensitive help on menu and toolbar buttons, and a help button on each of Arena s modules. Just refer to the Arena help table of contents and index for a list of all help topics. Use the SMARTs library As you craft models of your own manufacturing processes, use our SMARTs library to explore how to best use Arena. This suite of tutorial models covers topics ranging from modeling resources to animation techniques. The library is organized into categories to help you find the right model with ease. When you re wondering how to take the next step in your model, browse the SMARTs library for a ready-made solution. For a list of 3

12 ARENA TEMPLATE DEVELOPER S GUIDE categories and their related SMARTS, go to Help > Arena Help. On the Contents tab, first click Model Building Basics, and then Learning Arena with SMART Files. Access the Arena Symbol Factory Arena animations can be enhanced using Arena Symbol Factory s extensive library of symbols. These symbols can be used for entity, resource, transporter, or global pictures or as graphic symbols within a model window. You can copy these symbols directly to the Arena model window, add them to your own libraries (.plb files), or add them to any of the Arena picture library files. Get phone support Rockwell Automation provides full support for the entire Arena family of products. Questions concerning installation, how modules work, the use of the model editor, and the use of the software are handled by technical support. ARENA TECHNICAL SUPPORT INCLUDES: (for users on active maintenance) a technical support hotline and address staffed by full-time, experienced professionals help with installation problems or questions related to the software s requirements troubleshooting limited support regarding the interaction of Arena with other programs support of the Arena Object Model, which is used in Microsoft Visual Basic for Applications. If you call the support line ( ), you should be at your computer and be prepared to give the following information: the product serial number the product version number the operating system you are using the exact wording of any messages that appeared on your screen a description of what happened and what you were doing when the problem occurred a description of how you tried to solve the problem. Get Web support In addition to phone support, the Rockwell Automation Customer Support Center offers extensive online knowledgebases of tech notes and frequently asked questions for support of non-urgent issues. These databases are updated daily by our support specialists. To receive regular 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 4

13 1 WELCOME And be sure to check the Arena User Zone section of our Web site at 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 training Do you need training? Rockwell Automation offers a standard training course comprised of lecture and hands-on workshops designed to introduce you to the fundamental concepts of modeling with Arena. We also offer customized training courses designed to meet your specific needs. These courses can be held in our offices or yours, and we can accommodate one person or twenty. You design the course that s right for you! Simply contact our consulting services group to discuss how we can help you achieve success in your simulation efforts. 1 Welcome Get consulting services Rockwell Automation also provides expert consulting and turnkey implementation of the entire Arena product suite. Please contact our offices for more information. Contact us We strive to help all of our customers become successful in their manufacturing improvement efforts. Toward this objective, we invite you to contact your local representative or Rockwell Automation at any time that we may be of service to you. Support Arena-Support@ra.rockwell.com Corporate Arena-Info@ra.rockwell.com Support phone: URL: URL: 5

14 ARENA TEMPLATE DEVELOPER S GUIDE 6

15 2 Arena Template Development Overview In this chapter, we introduce the concepts related to building templates using Arena. As described in Chapter 1, Arena provides a fully integrated environment for building, graphically animating, verifying, and analyzing simulation models. It does so by the creation of reusable modeling components called modules that are collected into libraries, or templates. To introduce you to template building, we start by reviewing the model-building process in Arena. Modeling with Arena An overview In Arena, simulation models are built by placing modules in a model window, providing data for these modules, and specifying the flow of entities through modules. A module defines the underlying logic that is applied when an entity is directed to the module, as well as the associated graphical animation, to depict the module s activities during a simulation run. This section provides a brief overview of model building with Arena. For information about using Arena to build, animate, and analyze simulation models, refer to the Arena User s Guide and online help. To use a module in an Arena model, a panel containing the module is attached to the Project Bar. This panel displays all of the modules that may be selected for placement in the model. To build a model, you select a module from the panel and place it in the model window. The graphics associated with the module, referred to as its user view, are added to the model window. This display of the module always contains a module handle (typically the module name) and may include static drawing objects, animation objects, operand display values, and connection points, as illustrated in Figure Overview Figure 2.1 Process module user view 7

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

17 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

18 ARENA TEMPLATE DEVELOPER S GUIDE Module definitions and instances A module in Arena is a single construct that may be selected from a template panel and placed in a model or, as we will see, in the definition of a new module. Each icon in a template panel represents a single module, such as a Create (to generate entities) or Process (for simple processing of entities). The information about a module that is stored in the template panel library (.tpl) file is referred to as the module definition. In the template panel object (.tpo) file, the information contained in the module definitions is condensed for use in a simulation model. When a module is selected from a.tpo file and is placed in a model window, we refer to the representation of the module in the model window as a module instance. The module definition defines the structure of the module and provides default data and visualization of the module. Each time a new instance of the module is created, the new instance contains the defaults provided by the module definition. However, these defaults may be modified by the modeler so that each instance carries with it its own characteristics. 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

19 2 ARENA TEMPLATE DEVELOPMENT OVERVIEW customers arrive at varying times or rates. First, a Create module is placed in the model window. The modeler may change the values of the Create module instance s operands. For example, the first customer type may utilize the default arrival stream, which is random (exponential). A second type of customer may arrive at a Constant rate. In that case, a modeler might change the value in one instance of the Create modules to Constant. Note that by changing the value in an instance, the modeler does not modify the definition. In the case of the Create module, the next instance (and all instances, until edited) will have a default type of arrival stream of Random (from the module definition). Module instances may be placed in Arena model windows (and later saved in model.doe files) or in the logic windows of new module definitions (to be saved in.tpl files). For simplicity s sake, we usually discuss use of module instances by the modeler (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. 2 Overview Defining a module A module definition is created by working with five windows: dialog design, logic, switch, user view, and panel icon. A template window (see Figure 2.2) provides a base from which the module definition windows are opened. The items in the Window menu open each of the windows (or the corresponding buttons on the Template Development toolbar may be used) for the selected Module Definitions list. As is the case throughout Arena, you may have as many windows open as you desire (for one or more module definitions). Figure 2.4 shows a template window with the five module definition windows opened for a single example module (Shipping). 11

20 ARENA TEMPLATE DEVELOPER S GUIDE Figure 2.4 Relationship among Arena template and module definition windows The five buttons used to open module definition windows (from the toolbar shown in Figure 2.5) are arranged in the order that we find we most often work when initially building a new module; i.e., first defining the dialog design and logic, then switches to control turning on and off module options, and finally the user view and panel icon graphics. However, the five components of a module may be defined in any order. As you work with a module definition, you often will modify the contents of a few of these windows. Figure 2.5 Template Development toolbar In this chapter, we have chosen to present an overview of each of the five module definition windows in the order that someone who places an instance of a module will interact with the module. We start with the icon for the module button that is displayed in 12

21 2 ARENA TEMPLATE DEVELOPMENT OVERVIEW a template panel; then we describe the user view and the module s dialog design and operands, which are the components of a module instance that a modeler can modify directly. We finish with the underlying module logic and switches, which are not directly accessible to the user of a module. Panel icon Three of the aspects of a module definition are visible to the user of the module: the panel icon, the user view, and the module s dialog and operands. First, when the template panel object (.tpo) file is attached to the Project Bar, the panel icons are displayed. This simply is a table of small graphics icons representing the modules contained in the template panel. Figure 2.6 shows the Arena template s Basic Process panel attached to the Project Bar. 2 Overview Figure 2.6 Basic Process template panel 13

22 ARENA TEMPLATE DEVELOPER S GUIDE While a module s panel icon is visible to the modeler, it is not changeable; the icon that is drawn in the module definition will be the same whenever the.tpo file is attached to the Project Bar. The Panel Icon window that is used to draw the icon in the module definition is similar to the picture edit window used to draw Arena pictures of resource, entity, etc. The panel icon for the definition of the Basic Process panel s Create module is shown in Figure 2.7. Figure 2.7 Create module panel icon User view After a module has been selected and placed in a window, an instance is formed and the module s user view is displayed. This user view contains the module handle (the name of the module, displayed as a text object within a box that opens the module s main dialog when the modeler double-clicks on it), and may contain entry points, exit points, operand values, static drawing graphics, and/or animation objects. The objects in the user view are visible to the modeler; most are changeable by the modeler individually in each module instance. For example, you might place a Process module (from the Basic Process panel) in a model window. Initially, the user view (in the model window) will appear as shown in Figure 2.8, containing the module handle ( Process # ), an entry point, an exit point, and an animated variable representing the work in process (WIP) or number of entities currently in that model. Figure 2.8 Process module instance s default user view You might place another instance of the Process module in the same model, then add a resource animation picture for that Process module instance to represent the resource utilized within the module. Figure 2.9 shows the modified user views of two Process module instances using pictures from Arena s people.plb picture library in place of the default resource pictures. 14

23 2 ARENA TEMPLATE DEVELOPMENT 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.) 2 Overview Figure 2.10 User view window of the definition of Arena s Process module Dialog design and operands An important part of a module definition is the user interface, the visual part that a modeler sees when opening a module's dialog or viewing a module's fields in the module spreadsheet. Often, the most challenging part of creating a module is selecting which operands are to be presented to modelers, the default values and display characteristics of these operands, and their organization into one or more dialogs for the module. A module designer might 15

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

25 2 ARENA TEMPLATE DEVELOPMENT OVERVIEW Figure 2.12 shows the dialog design window for the definition of the Basic Process panel s Batch module, which simply contains a main dialog and a number of operands that are members of the dialog. 2 Overview Figure 2.12 Dialog design window for the Batch module s definition A modeler working with a module instance may modify the values of operands, but cannot change the configuration of dialogs, the default values supplied when a new instance of a module is placed in a window, or the associations among operands. These characteristics of a module s data are part of the module definition; each instance simply supplies values to the operands provided by the definition. Logic The final two aspects of a module are hidden from the modeler: the module logic and the definition of module switches. The logic underlying an Arena module definition is created simply by building an Arena submodel. The Logic window, which is used to create a module definition s logic, is very similar to an Arena model window; you attach panels to the Project Bar, select and place modules, and edit the module instances you ve created. 17

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

27 2 ARENA TEMPLATE DEVELOPMENT OVERVIEW module operand, you enclose the name of the operand in back quotes (`). Assuming that the operands have the same name as the prompts (i.e., Clerk Name and Time to Admit), the references would be established in the Process module as `Clerk Name` and `Time to Admit` as shown in Figure Overview Figure 2.14 Operand references in Process module for Admissions Clerk module If one instance of the admissions clerk module has values Mary and UNIFORM(10,30) for the module operands, then effectively a Process module has been placed in the underlying model logic with values of Mary for the resource to be utilized and UNIFORM(10,30) for the process time. 19