sim

7.1. DATA TABLES 217

Table 7.1: Simio Standard Properties for representing table data columns.

Property Type Boolean Color Date Time Day Pattern Enumeration Event Expression Integer List Rate Table Real Schedule Selection Rule Sequence Table State String Table

Description True (1 or non-zero) or False (0) A property for graphically setting color A specific day and time (7:30:00 November 18, 2010) A reference to a Day Pattern for a schedule A set of values described in a prc~defined enumeration Event that triggers a token release from a step An expression evaluated to a real number (1.5+MyState) An integer number (5, or -1) A set of values described in a string list A reference to a rate table A decimal number (2.7, or -1.5) A reference to a sched ule A reference to a selection rule A reference to a sequence table A reference to a state Textual information (Red, l3Iue) A reference to a data table or sequence table

valuable in organizing, representing, and using your data as well as interfacing with external data.

7.1.1 Basics of Tables

A data table is defined using the Tables panel in the Data window. To add a new table you click on Add Data Table in the Tables section of the Table ribbon. Once you've added a table you can rename it and give it a description by clicking on the tab for the table and then setting the table properties in the Property window.

Tip: If you add multiple tables, each one has its own tab. Recall our discussion in Section 4.1 about configuring window placement. That can be particularly handy when working with data tables.

To add columns to a table you select a table to make it active and then click on property types under Standard Property, Element Reference, Object Reference, or Foreign Key. A table column is typically represented by the Standard Properties illustrated in Table 7.1. Use an Object Reference when you want a table to reference an object instance or list of objects such as an Enti ty, Node, Transporter, or other model object. Likewise use an Element Reference if you want a table to reference a specific element like aTallyStatistic or Material.

7.1.2 Model 7-1: An ED Using a Data Table

Let's illustrate these table concepts by representing the data for a simple health- care example. Consider an emergency departrrwnt (ED) that has some known data concerning how patients of various severities are handled. Specifically, we

218 CHAPTER. 7. WOR.KING WITH MODEL DATA

Table 7.2: Model 7-1 ED Basic patient data.

Patient Type Routine Moderate Severe Urgent

Priority 1 2 :~ 4

Treatment Time (Minutes) Random. Triangular(:3,5, 10) Random.Triangular( 4,8,25) nandom. Triangular( 10,15,30) Random. Triangular( 15,25,40)

have four patient types, their priority value, and their typical treatment time as given in Table 7.2. The first steps in building our model involve defining the model entities aud the data table:

1. Load Simio and start a new model as we've done before. The first thing we'll do is drag four instances of ivlodelEntity into the model facility view. Click on each one and use the properties or the F2 key to rename them to Routine, Moderate, Severe, and Urgent, respectively.

2. Let's take a minute to animate those entities a little better, so that we can tell them apart. Follow the same procedure described in Section 4.7. Click on an entity instance, then click on the symbol library. Scroll down to the People category and select Man6. Repeat this using Man6 for all four entity instances. Although all entities will use the same symbol, we can tell them apart by giving each person a different shirt color. Zoom in so you can see your new symbols clearly. Click on the Rout ine entity. On the right side of the Symbols ribbon is a Color button. Clicking the lower half of the color button will display a color pallet. Select a green color and then apply it to Routine by clicking on the shirt of the man symbol. Repeat this procedure to apply a light blue to the Severe patients and Red to the Urgent patients. We'll leave Moderate with the default color.

:l. Next, let's create the data table. Select the Data tab just under the ribbon, then select the Tables panel on the left if it's not already selected. The Table ribbon will appear, although most of it's unavailable (grayed out) because we don't yet have an active table. Click on the Add Data Table button to add a blank table, then click on the Name property in the properties window and change the name to PatientData (no spaees are allowed in Simio names).

4. Now we'll add our three columns of data. Our first column will reference an entity type (an object), so click on Object Reference on the ribbon and then select Entity from that list. You've now ereated a column that will hold an Entity Instance. Go to the Name property (not the Display Name property) in the properties window and change it to PatientType. Our seeond column will be an integer, so dick on Standard Property in the ribbon and select Integer. Go to the Name property and rename it to Priority. Finally, our third column will be an expression so click on Standard Property in the ribbon and select Expression. Go to the Name property and rename it to TreatmentTime. Sinee this represents a time, we need a couple of extra steps here: In the Logic category of

7.1. DATA TABLES 219

Figure 7.1: Model 7-1 ED basic patient data in Simio table.

2 Random.Triangular(4,8,25)

3 Random.Triangular(1O,15,30)

4 Random.Triangular(15,25,40)j(x)

the properties window specify a Unit Type of Time and specify Default Units of Minutes.

5. Now that we have the structure of the table, let's add our four rows of data. You can add the data from Table 7.2. You can enter the data a row at a time or a column at a time; here we'll do the former. Click on the upper left cell and you'll sec a list containing our four entity types. (If you don't see that list, go back two steps.) Select Routine as the Patient Type for row 1. Move to the Priority column, type 1 and press enter and you'll be moved to the TreatmentTime column. Here we'll type in the expression from Table 7.2, Random.TriangularC3, 5,10). Tip: If the values of your data are partially hidden, you can double click on the right edge of the column name and it will expand to full width. Move to the next row in the PatientData table and follow a similar process to enter the remaining data from Table 7.2.

When you're finished your table should look similar to Figure 7.1. We've now defined the patient-related data that our model will use. In the next section, we'll demonstrate how to access the data from the table.

Referencing Data Tables

Table data can be used by explicitly referencing the table name, the row number, and the column name or number using one of the following syntax choices: TableName [RowNumber].ColumnNameor TableName[RowNumber,ColumnNumber]. We could continue building our model now using that syntax to reference our table data. For example, we could use PatientData [3] .TreatmentTime to refer to the treatment time for a Severe patient. While using this syntax is useful for referencing directly into a cell of a table, we often find that a particular entity will always reference a specific table row. For example in our case, we'll determine the row associated with a patient type, and then that entity will always reference data from that same row. You could add your own property or state to track that, but Simio already builds iu this capability. The easiest method to access that capability is by setting the properties in

220 CHAPTER 7. WORKING WITH !'dODEL DATA

Figure 7.2: Associating an entity with an explicit row in a table.

the Table Reference Assignment category of the Source object. If we had a separate arrival stream for each of our four patient types, we'd probably use this technique. We'd have a source object to create each patient type. Figure 7.2 illustrates how the source object for Severe patients could be configured by specifying the table name and an explicit row number. Once you've made this association between an entity and a specific row in a table, you can use a slightly simpler syntax to reference the table data: TableName. ColumnName because the row number is already known. For example, we could now use PatientData. TreatmentTime to refer to the treatment time for any patient type.

Selecting Entity Type

Defore we finish our model, we'll explore one more aspect of tables. It's very common to have data in a table where each row corresponds to an entity type, as we have in our model. It's also common to have the entity type be selected randomly. Simio allows you to do both within the same construct. You can add a numeric column to your table that specifics the weighting of each row (or entity type). Then you can specify that you'll randomly select a row based on that colnmn by using the function TableName. ColumnName.RandomRow.

Let's follow a few final steps to complete our model.

1. In our ED, historical information suggests that our patient mix is Routine (40%), Moderate (:31%), Severe (24%), and Urgent (5%). We need to add this new information to our table. Retnrn to the Data tab and the Tables panel. Click Standard Property and select Real. Go to the Name property and rename it to PatientMix. Then add the above data to that new column. When yon're finished your table shonld now look

7.1. DATA TABLES

_.~a:.~:;:~J~\YITr~a~rr!'1:i~J"~L:L~~i"Mia )!Routine . 1 Random,Triangular(3,5,lO) 40

2 Random.Triangular{4,8,2S) 31

3 Random,Triangular(10,lS,30) 24

4 Random.Tflangular(15,2S.40)

Figure 7.3: Model 7-1 ED Enhanced patient data in Simio tahle.

like Figure 7.;~.I

221

2. Now we can continue huilding our model. The last change we made allows us to have a single Source that will produce the specified distribution of our four patient types. Place a Source in your model and specify an Inter- arrival Time of Random.Exponential(4) and units of Minutes. Instead of specifying one patient type in the Entity Type property with a specific row numher as we did in Figure 7.2, we'll let Simio pick the row numher and then we'll select the Entity Type based on the PatientType specified in that row. We must select the table row before we create the entity; otherwise the entity would already be created by the time we decide what type it is. So in the Table Reference Assignment, Before Creating Enti- ties category, we'll specify the Table Name of PatientData and the Row Number of PatientData. PatientMix. RandomRoIJ. After the row's se- lected, the Source will go to the Entity Type property to determine which Entity Type to create. There we can select PatientData.PatientType from the pull-down list. This is illustrated in Figure 7.4.

3. To finish our model is pretty painless. Add a Server, set its Initial Capac- ity to 3, and specify a Processing Time of PatientData. TreatmentTime. We're using the data in the table f(lr this field, but note that we're using the short reference method. Since no explicit row is specified, we're telling Simio to use the row that's already associated with each specific entity. When an entity of type Routine arrives, it will use row one and a treat- ment time sampled from the distrihution Random.TriangularC3,5,10). However, when an entity of type Severe arrives, it will usc row three and a treatment time sampled from the distribution Random.Triangular 00,15, 30).

Add a Sink, then connect Source to Server and Server to Sink with Paths. Your model should look something like Figure 7.5.

Before enhancing our model, we'll do a small verification step so that we'll be confident that we've correctly implemented the data table. Using the pro- portions of patient types and the expected service times for each patient type,

IAs noted in Section 5.2, the values in the Patient Mix colullin arc interpreted by Simio only in relation to their relative proportions. v\"hilc we entered the value.<.; here thinking of the percent of patients of each type, they could have equivalently been entered as probabilities (0.40, O.al, 0.24, 0.05), or as any other positive multiple of the values we used (e.g., 4000, 3100, 2400, 500).

222

;;;it Wrl.:;tJ!X>f'

>Ccrl>'"", I

,~~c::~J :J~!~?;~~,~.';!lJ p Modd',,~ly I @ i

CHAPTER 7. WORKING WITH JvIODEL DATA

Rowtlumber The one-based row index into the table.

Figure 7.4: Selecting an entity type from a table.

Figure 7.5: Model 7-1 Completed ED model.

we can compute the overall expected service time (11.!J6 minutes). With the overall arrival rate of 15 patients/hour, we expect a steady-state server utili7.a- tion of 99.64%. We ran Model 7-1 for 25 replications of length 1100 days with a lOO-day warmnp period and the resulting average scheduled utili7.ation was 99.59% :l: (J.(J854 (the 95% confidence interval half-width). This illustrates an important point about model verification - it's often much easier to verify the model a.,;you build it rather than waiting until the model is "finished." Since our sampled utili7.ation matched our expectation quite well, we're now confident that we've property implemented the patient data table and can move on to our model enhancements.

7.1. DATA TABLES

7.1.3 Sequence Tables

A sequence table is a special type of data table used to specify a sequence of des- tinations for an entity. In a manufacturing job shop, this might be the stations or machines that must be visited to complete a part (e.g., Grinding, Polish- ing, Assembly, Shipping). For a transportation network the sequence might be a series of stops in a bus route (e.g., MainStreet, FifthStreet, NinthStreet, UpTown).

You create a sequence table in the Tables panel of the Data Window just like for normal data tables, but use the Add Sequence Table button. This will create the table ami automatically add a column named Sequence for specifying a routing sequence for an entity. This required column is the major difference between a normal table and a sequence table. In most other ways everything that applies to a data table also applies to a sequence table . .Just as the prop- erties (columns) of a table can be used however you wish, the same is true in sequence tables and you can reference these values the salIle way you'd reference the values in any other table (e.g., TableName.PropertyName).

There are actually two dilferent ways of configuring sequence tables: simple sequence tables and mlational sequence tables. Simple sequence tables are prL~ ferred when you have somewhat isolated use of a single sequence, for example if you have only one sequence or entity type in use. Relational tables have the ad- vantage of more easily supporting the more complex use of sequences that you might encounter with multiple entities following different sequences through the same objects. They're both used in the same way, but differ in how the tables themselves are configured. We'll start by explaining how to configure ami use simple sequence tables.

Simple Sequence Tables

Each simple sequence table defines one routing plan. If you have multiple rout- ing plans (e.g., several bus routes), then each would be defined in its own se- quence table. Each row in the sequence table corresponds to a specific location. The data items in that row are usually used for location-specilic properties, for example the processing time, priority, or other properties required at a partic- ular location.

After your sequence table has been created, you IIlUStcreate an association between the entity and the sequence table (in other words, you need to tell the entity which sequence to follow). There are a couple ways to do that, but the easiest is to do so on an entity instance you've placed in a model. It will have a property named Initial Sequence in its Routing Logic category. Specify the sequence table name in this property. The entity will start at row one in this sequence table and work its way through the rows as stations are visited. Although this happens automatically, it's possible to change the current row, and in fact even change the sequence being followed. This can be done at any time nsing the SetRow step in an add-on process.

At this point the astnte reader (that's you, we hope) will be asking "nut how does the entity know when to lIlove between sequences'?" You must tell the entity when to go t.o t.he next step in its seqnence. The most common place to do that is in the Routing Logic category of a Transfer Node (recall that the

224 CHA PTER. 7. WOR.KING WITH MODEL DATA

outbouud node from every Standard Library object is a Transfer Node). Here you'd specify that the Entity Destination Type is By Sequence. This causes three things to happen:

1. The next table row in the entity's sequence table is made current.

2. The entity's destination is set to the destination specified in that row.

:1. Any other table properties you've specified (e.g., ProcessingTime) will now look t.o the new current row for their values.

Because you're explicitly telling the ent.ity when to move t.o the next se- quence, you also have the option to visit other stations in between sequences if you choose - simply specify the Entity Destination Type as anything other than By Sequence (e.g., Specific). You can do this as many times as you wish. The next time you leave an object and you want to move sequent.ially, just again use By Sequence and it will pick up exactly where you left off.

Relational Sequence Tables

"dany of the above concepts arc the same for relational sequence tables. Rela- tional tables are uscd in much the same way, but configured a bit differently. One difference is that you can combine several different sequences (e.g., the set of visitations for a particular entity) into a single sequence table. And insteao of setting the sequence to follow on the entity instance (using the Initial Sequence property) you can provide that information in another table. Both of these capabilities arc accomplished by linking a main oat.a table with a relational sequence table using special columns identified as Key and Foreign Key. This technique will be demonstrated in Model 7-2.

7.1.4 Model 7-2: Enhanced ED Using Sequence Tables

Let's embellish our previous ED model (Model 7-1) by describing the system in a little more detail. All patients first visit a sign-in station, then all exccpt the Urgent go to a registration area. After being registered they'll go to the first available examination room. After the examination is complete the Routine pa- tients will leave, while the others will contiuue for additional treatment. Urgent patients visit the sign-in, but then go to a trauma room that's equippeo to t.reat more serious conditions. All Urgent patients will remain in the trauma room until they're stabili~ed, then they're transferred to a treatment room, ano then they'll leave.

You may recall that when we started Model 7-1, the first thing we did was place the entities. More generically, we started by placing into the model the objects that we'd be referencing in the table. We'll do that again here. Since Sequence Tables mainly reference locations (more specifically, the input nodes of objects), we'll start by placing the Server objects that represent those locations. Then we'll build our new table, then return to aod properties to our model.

1. Start with Model 7-1. Delete the path between the Server and the Sink as we'll no longer be needing it. Likewise, go to the properties of Serverl, right dick on Processing Time, and select Reset.

simio_HW/Q5.9.jpg