CSI4124_SYS5110_CaseStudies_Fall_2014.pdf

8/9/2019 CSI4124_SYS5110_CaseStudies_Fall_2014.pdf

1/138

1

School of Electrical Engineering and Computer Science

Faculty of Engineering

University of Ottawa

Fall 2014

Modelling and Simulation

Case StudiesCSI4124/SYS5110Foundations of Modelling

and SimulationGilbert Arbez

Oct 7


2/138

2

Table of ContentsIntroduction ................................................................................................................................................. 4

Case Study Overviews ............................................................................................................................ 5

Kojos Kitchen............................................................................................................................................ 8

Problem Description ............................................................................................................................... 8

Project Goal ............................................................................................................................................ 9

ABCmod Conceptual Model................................................................................................................. 10

Simulation Model.................................................................................................................................. 15

Experimentation and Analysis .............................................................................................................. 21

Annex AData Modelling ................................................................................................................... 24

Kojos Kitchen (Version 2)....................................................................................................................... 25

Problem Description ............................................................................................................................. 25

Project Goal .......................................................................................................................................... 26





Port Project (Version 1) ............................................................................................................................ 42


Project Goals ......................................................................................................................................... 44







Project Goals ......................................................................................................................................... 70







Project Goals ......................................................................................................................................... 97


3/138

3


Simulation Model................................................................................................................................ 109

Experimentation and Analysis ............................................................................................................ 111

Annex AData Modelling ................................................................................................................. 137


4/138

4

IntroductionThis document presents a set of case studies which expands on the examples presented in the bookModelling and Simulation: Exploring Dynamic System Behaviour

1and presents additional case

studies. And overview of each case study is presented in this section. The case study overview describes

the important modelling and simulation concepts presented in the case study. It also includes anydifferences between the version presented in this document and in the textbook.

The case studies presented here follows the modelling and simulation process presented in Section

2.3 of the textbook. In particular each cases study is presented with project documentation that includesthe following sections (a combination of the documents described in Part II introduction of the

textbook).

1. Problem Description: Provides a Problem Statement that describes the problem to be solved and

the SUI Details that describes all known information about the SUI.2. Project Goals: This section expands on the problem statement to describe the problem in

modelling terms. It details the parameters and output for the model as well as experimentation

which describes how parameters are modified such that output can be analysed to solve the

problem.3. Conceptual Model: This section is comprised of three sub-sections. The first sub-section

consists of the high-level conceptual model captures the features ofthe model at a level of detail

that is both adequate for communication and comprehensive. The second sub-section consists ofthe detailed conceptual model which provides the detail needed for simulation model

development. The third and final sub-section presents the design of experimentation; at

minimum this sub-section defines a log format to evaluate the changes in the state of the modelduring a simulation run.

4. Simulation Model and Program: This section provides an overall design of the simulation

model, that is, how the conceptual model is translated to an ABSmod/J simulation model. It

also reports on the application of the validation experimentation developed in the Conceptual

Model section. Software for each case study is supplied and should be reviewed in conjunctionwith this section and the Experimentation and Analysis section.

5. Experimentation and Analysis: Three sub-sections make up the Experimentation and Analysissection. The first, Experimentation, describes the experimentation software developed, while the

second, Output Analysis focuses on the output produced during experimentation for solving the

problem. The last sub-section, Conclusions, provides the conclusions and recommendations that

flow from the output analysis.6. Annex AData Modelling: Data modelling is a task in the modelling and simulation project that

is considered part of conceptual modelling. It involves collecting data from the SUI, typically

stochastic data, and developing either deterministic or stochastic models (see Section 3.6 of thetextbook). In the context of a course it is often difficult or impossible to collect data for

completing data modelling purposes and often data models are provided as project information.Thus data models are described in an annex of the project document. In cases when data is

available, then the steps in arriving at a data model is presented in the Annex as well.

The presented case studies were developed with the following preferences, enhancements andclarifications.

1Modelling and Simulation: Exploring System Dyanmics, Louis G. Birta, Gilbert Arbez, 2 ndedition, 2013


5/138

5

1) Parameters and Input: A preference for defining parameters and input variables as entity

attributes is applied.

2) ABSmod/J was updated with features to allow experimentation, that is, the class

ConfidenceIntervalprovides the means to produce confidence intervals and the class

WelchAveragethat supports the application of a moving average to determine warm up times.

The experimentation software includes the creating of confidence intervals and applyingWelchs moving average method rather than using external analysis tools such as Excel. Forgraphing (which is used with Welchs method), Excel is still practical for creating graphs from

csv files generated by experimentation software. The creation of confidence intervals also

allows implementation of optimisation strategies in the Java experimentation software.

3) The Simplification and Assumptions section (presented in the textbook) was divided into 2sections Simplifications and Assumptions. See Section 2.1 for details on the differences

between these 2 concepts.

4) Unless otherwise noted, common random numbers were used in all experiments (see section

7.4.1 of the textbook for more details). The case study Port Project, Version 1, explorescommon random numbers.

5)

The standard for comments in the ABCmod constructs is to insert text with italics font andenclosed in parentheses () as in: (this is a comment).6) The following provides additional information on assumed functions for the standard procedures

presented in 4.3.3.2.

a. InsertQueu, InsertQueHead, RemoveQu: These procedures update the attribute n, that is,the length of the queue when the list is updated (i.e. entity added or removed).

b. InsertGrp, RemoveGrp: These procedures update the attribute n, that is, the length of the

queue when the list is updated (i.e. entity added or removed).

Case Study Overviews

Kojos Kitchen

This Case Study consists of a simple queueing problem and was introduced in Chapter 4 of the textbook[1]. It is meant to introduce a modelling and simulation project that uses the ABCmod conceptual

modelling framework, the use of the ABSmod/J toolkit for the creation of the simulation model (and

program) and experimentation to arrive at the solution of the problem.With respect to the Kojos Kitchen example that appears in the textbook, the following changes were

made:

The input variable uNumEmpand parameter addEmpare defined as attributes of the entity

RG.Counter, that is,RG.Counter.uNumEmpandRG.Counter.addEmpsince these variablesrepresent properties of theRG.Counterentity.

The attribute iC.Customer.typewas changed to iC.Customer.uType and specified as an input

variable since this attribute is set upon the entities arrival into the model and is set to a valueprovided byRVP.uCustomerType.

The initialisation ofRG.Counter.uNumEmpis done in the StaffChangeaction rather than theInitialiseaction. Given that the StaffChangeaction was defined to provide the value of the

input variableRG.Counter.uNumEmp, it seemed more logical to initialise its value here rather

than in another action.

The SSOV output variables are initialised to 0 in theInitialiseaction.

Some editorial changes have been made to make clarifications and/or corrections.


6/138

6

Extensive notes have been added to the section Design of the Simulation Model and Program in

this document to help the reader better understand the transformation of the conceptual model into the

simulation model/program.

Kojos Kitchen (Version 2)

In this second version of the Kojos Kitchen, the experimentation in the project goal is modified toconsider multiple employee scheduling scenarios.

It demonstrates analysis of the multiple scenarios as described in section 7.4.2 of the Birta/Arbeztextbook.

Also explored was the allowing the use of difference individual confidence levels. This

approach requires fewer runs while meeting the 10% criterion for the ratio of the confidenceinterval half-length to point estimate.

It also introduces the use of a vector as a parameter, that is, a sequence of numbers to indicate thenumber of employees behind the deli counter during different periods of the day. This sequence

actually corresponds to the range sequence of an input variable. Both the range sequence andthe input variables are model attributes, that is, RG.Counter.schedule and

RG.Counter,uNumEmp respectively. The first 2 cases specified in the Project Gaols are the same as the two cases specified in the

Project Goal of the initial version of the Kojos Kitchen project.

Port Project (Version 1)

This case study provides a second example of a simple model which is slightly more complex that the

Kojo Kitchen projects. It introduces the activities that involve only one entity (see MoveToHarbour and

MoveToBerths), the sequel activity (Loading), the use of trajectory sets as part of the models output,

the additional experimentation required for a steady state study, and illustrates the benefits of usingcommon random numbers.

With respect to the Port Project example (version 1) that appears in the textbook, the followingchanges were made:

The Initialisation action was removed from the high-level conceptual model behaviouraldiagram. This is a standard action included in all conceptual models and a detail that is

included in the Detailed Conceptual Model.

The input variable uTankerSize was changed to the attribute iC.Tanker.uSize. This impliesthat the attribute iC.Tanker.size is also changed to iC.Tanker.uSize.

The input variables uBerthingTime, uDeberthingTime and uEmptyTravTime were removed

from the Input tables since these are constants.

The trajectory sequence TRJ[numOccBerths] is changed to TRJ[RG.Berths.n]. Given thatnumOccBerths = RG.Berths.n; the variable numOccBerths is removed by this change.

The trajectory sequence TRJ[tankerWait] is changed to TRJ[iC.Tanker.totalWait]. Given thattankerWait = iC.Tanker.totalWait; the variable tankerWait is removed by this change.


This case study adds an important behavioural feature to the SUI, interruptions. This will affect the

activity MoveToBerths that can be interrupted before its completion. Note that the addition of this

behavioural feature to the SUI does not affect significantly the results of the study.


7/138

7


The effect of the storm was ignored in the other versions of the Port Project. In this third version, the

storm is modelled. The behavioural feature from version 2 is maintained in version 3. The effect of

modelling the storms adds interruptions to virtually all activities (with the exception of the Loadingactivity) and demonstrates the use of the scheduled activity in modelling an exogenous input.

With respect to the Port Project example (version 3) that appears in the textbook, the following

changes were made:

1. The project goal included a parameter permits the inclusion of the storm or not. Thus the resultsfrom the Version 2 Port Project can be produced for comparision with those produced by the

model that includes the storm behaviour.

2. The exogenous input variable uStormwas added to the model. Thus the attributestoppedwas

removed from theR.Tugentity and the attribute anchored used in its place. The use of theuStormas an input variable was a better representation of an exogenousinput variable rather

than the use of theR.Tug.anchoredattribute to represent the presence of a storm.

3. When the MoveToBerths is interrupted by an arriving tanker, the MoveToHarbour activity isstarted. Thus the ReturnToHarbour sequel activity is not required. An additional attribute,

returnToHarbour, was added to theR.Tugentity and some additional logic was added to both

MoveToBerthsandMoveToHarbourto deal with this case.


8/138

8

Kojos Kitchen

Problem Description

Problem StatementKojos Kitchen is one of the fast food outlets in the food court of a shopping mall. Kojos manager is very happywith business, but has been receiving complaints from customers about long waiting times. He is interested in

exploring staffing options to reduce these complaints.

SUI Details

Figure 1 Kojos Kitchen Fast Food Outlet

The mall (and hence Kojos) is open between 10:00am and 9:00 pm every day. Kojos serves only two types of

product; namely, sandwiches and sushi. Two rush hour periods occur during the business day, one between 11:30am and 1:30 pm, and the other between 5:00 pm and 7:00 pm. Currently two employees work at the counterthroughout the day preparing sandwiches and sushi products for the customers.

SandwichandSushiCounter

Su

Sw

SuSu SwSw

E

E

Sw Su E

EmployeeSushi

Customer

Sandwich

Customer


9/138

9

Project GoalThe specific interest is with comparing the current situation (base case) to an alternative where a third employee is

added during the busy periods (between 11:30 am and 1:30 pm and between 5:00 pm and 7:00 pm). Theperformance measure of interest is the percentage of customers that wait longer than 5 minutes for service over

the course of a business day.

Parameters

RG.Counter.addEmp: Set to 0 for base case and 1 for alternate case; the alternate case add a third employee

during the two busy periods.

Experimentation

Study: Bounded Horizon Study.

Observation Interval: Time units areminutes.

Observation interval between t=0 and time after t=660 when all customers have left the deli.

Base Case: Two employees service customers at the counter during hours of operation (10 am to 9

pm).Alternate Case:An additional employee is added to the counter during the busy periods between

11:30 am and 1:30 pm and between 5:00 pm and 7:00 pm.

Output

propLongWait: The proportion of customers that wait more than 5 minutes in line to reach the counter.


10/138

10

ABCmod Conceptual Model

High Level Conceptual Model

Simplifications

We assume there are only two types of customer one type purchases only sandwiches and the othertype purchases only sushi products.

Structural View

Figure 2KojosKitchen Structural Diagram

Entity Categories: CustLine: An entity structure with role=Queue and scope=Unary that represents the line of customers in front

of the counter.

Counter: An entity structure with role=Resource Group and scope = Unary that represents the counter where

customers are being served.

Customer: An entity structure with role=Consumer and scope = Class that represents the collection of

customers requiring service at the counter. There are two types of customers, the sandwich customer and thesushi customer. Customers are distinguished using the Customer attribute uType.

Behavioural View

Figure 3 Customer Life Cycle

Actions: Arrivals: This scheduled action generates the input entity stream of customers.

StaffChange: The change in the number of employees behind the counter. This Action is not shown in

the behavioural diagram since it is not part of the customer life cycle.

Activities: Serving: This activity represents the serving of a customer.

Q.CustLine

RG.Counter

iC.Customer

Legend

Arrivals

Serving


11/138

11

Input

Exogenous Input (Entity Stream)

Variable

Name

Description Domain Sequence Range Sequence

uCB This input entity streamrepresents the arriving

customers

RVP.DuC() 1 customer arrives at each arrival.

Endogenous Input (independent)

Variable Name Description Domain Sequence Range Sequence

RG.Counter.uNumEmp This inputvariable

represents the

number of

employees at the

counter serving

customers.

< 0, (10h00)

90, (11h30 start of

busy period)

210, (13h30 end of

busy period)

420, (17h00, start of

busy period)

540> (19h00 end of

busy period)

< 2,

RG.Counter.uNumEmp +RG.Counter.addEmp,

RG.Counter.uNumEmp -RG.Counter.addEmp,

RG.Counter.uNumEmp +RG.Counter.addEmp,

RG.Counter.uNumEmp -RG.Counter.addEmp >

Endogenous Input (Semi-independent)

Variable Name Description Value(s)

uSrvTm Service time of a customer. RVP.uSrvTm()iC.Customer.uType Defines the type of an arriving customer. RVP.uCustomerType()


12/138

12

Detailed Conceptual Model

Structural Components

Parameters

Name Description ValueRG.Counter.addEmp Number of additional employees serving at the

counter during the busy periods.

0 (for the base case) or

1 (for the alternate scenario).

Consumer Class: CustomerThis entity structure represents the customers who purchase items at Kojo's Kitchen.

Attributes DescriptionstartWaitTime Time stamp that holds the value of time when the customer enters the customer line.

uType The assigned value indicates the type of customer. Two values are possible: 'W' for a

sandwich customer or 'U' for a sushi customer.

Resource/Group Unary: CounterThis resource group represents the counter where customers receive service.

Attributes Description

list The group of the Customer entities that are being served.n Number of entries in list (necessarily n uNumEmp).

uNumEmp Input variable that defines the number of employees at the counter available to

service customers.

addEmp Parameter that defines the number of additional employees serving at the counter

during the busy periods.

Queue Unary: CustLineThe queue of customers waiting for service at the counter.

Attributes Descriptionlist List of the customers entities waiting in line for service.

Discipline: FIFO.

n The number of iC.Customer entities in List.

Behavioural components

Time units: minutes

Observation interval: tB0B= 0, Implicit Stop Condition: (t B>660 minutes (11 hour business day) ANDRG.Counter.n = 0).

Action: Initialise

TimeSequence < 0 >

Event SCS RG.Counter.n 0

Q.CustLine.n 0

SSOV.numServed 0

SSOV.numLongWait 0

Output

OUTPUTS

Simple Scalar Output Variables (SSOV's)

Name DescriptionnumServed Number of customers served.

numLongWait Number of customers that waited longer than 5 minutes.

propLongWait numLongWait/numServed.


13/138

13

Input Constructs

Random Variate Procedures

Name Description Data ModelRVP.DuC() Provides the values of the arrival

times of customers. No arrivals

occur after closing (i.e. for t 660).

Exponential(X) where X is:

MEAN1=10, for 0 t < 90

MEAN2=1.75, for 90 t < 210

MEAN3=9, for 210 t < 420MEAN4=2.25, for 420 t < 540

MEAN5=6, for 540 t < 660

(All values are in minutes.)

RVP.uCustomerType() Provides the type of the arriving

customer. Returns either W

(sandwich customer) or U (sushi

customer).

Proportion of sandwich customers:

PROPW=65%

Proportion of sushi customers:

PROPU=35%

RVP.uSrvTm(type) Provides a value for the service time

of customer according to the value

of type.

For type W (sandwich customer):

UNIFORM(STWMIN, STWMAX)

where STWMIN=3 minutes and

STWMAX=5 minutes.

For type U (sushi customer):

UNIFORM(STUMIN, STUMAX)where STUMIN=5 minutes and

STUMAX=8 minutes.

Action: ArrivalsThe Input Entity Stream of arriving customers.

TimeSequence RVP.DuC()

Event SCS iC.Customer SP.Derive(Customer)

iC.Customer.uType RVP.CustomerType()

iC.Customer.startWaitTime t

SP.InsertQue(Q.CustLine, iC.Customer)

Action: StaffChangeManages the value of the input variable RG.Counter.uNumEmp, that is,

schedules additional employee during busy times for the alternate case.

TimeSequence

Event SCS IF(t=0) THEN

RG.Counter.uNumEmp 2

ELSE IF(t=90) THEN

RG.Counter.uNumEmp + RG.Counter.addEmp

ELSE IF(t=210) THEN

RG.Counter.uNumEmp - RG.Counter.addEmp

ELSE IF(t=420) THEN

RG.Counter.uNumEmp + RG.Counter.addEmp

ELSE IF(t=540) THEN

RG.Counter.uNumEmp - RG.Counter.addEmpENDIF


14/138

14

Behavioural Constructs

Activity: ServingService for a customer.

Precondition (RG.Counter.n < RG.Counter.uNumEmp) AND (Q.CustLine.n 0)

Event SCS iC.Customer SP.RemoveQue(Q.CustLine)

IF(tiC.Customer.StartWaitTime > 5)THEN

SSOV.numLongWait + 1

ENDIF

SSOV.numServed + 1

SSOV.propLongWait SSOV.numLongWait/SSOV.numServed

SP.InsertGroup(RG.Counter, iC.Customer)

Duration RVP.uSrvTm(iC.Customer.uType)

Event SCS SP.RemoveGroup(RG.Counter, iC.Customer)

SP.Leave(iC.Customer)

Design of Validation Experimentation

Given the simplicity of the model, it is possible to validate the model using a trace log as described

below. The model shall be validated for both the base case and the alternate case.

Trace Logging

The state of the simulation model is monitored by tracking the number of customers in Q.CustLine, the

number of customers in RG.Counter, and the input variable RG.Counter.uNumEmp. These values arepresented on a single line as follows:

Clock: xxxxxxx, Q.CustLine.n: xx, RG.Counter.n: xx, RG.Counter.uNumEmp: xx

where thexxxs are replaced with the current value of the clock and designated attribute values.


15/138

15

Simulation Model

Design of Simulation Model and Program

The simulation model is implemented in the class KojoKitchen(an extension of the ABSmod/J class

AOSimulationmodel) and a number of other classes used to implement the various constructs from the

ABCmod conceptual model. All Java classes that make up the Java Kojo Kitchen simulation model areplaced in the Java package kkSimModel.

The following table shows how the various ABCmod entity structures are mapped to Java classes and

how objects instantiated from these classes are reference by the KojoKitchenclass.

Entity Structures

ABCmod

Construct

Java Class Object References

iC.Customer Customer

Notes: The enumerated data type Typeis

defined to restrict the values of the uType

attribute to Wand U.

Typically by the reference

variable icCustomerin thevarious methods that

manipulate Customer objects.RG.Counter Counter

Notes:

The list of Customerobjects are

maintained in a HashSetobject. Thusthe standard ABCmod procedures

SP.InsertGrpand SP.RemoveGrpare

implemented as methods in the

Counterclass.

The attribute n is note implemented asan instance variable since it is

maintained by the HashSetobject.Thus the method getNprovides the

means to obtain the value of theattribute.

KojoKitchen.rgCounter

Q.CustLine ArrayList(standard Java Class)Notes

The various methods available in the

ArrayListclass provide the

implementation of the various

ABCmod procedures, such as

SP.InsertQue (qCustLine.add)

SP.RemveQue (qCustLine.remove). The attribute n is maintained within the

ArrayListobject (adjusted

automatically when ArrayList

methods are called). The methodqCustLine.size() provides the value of

the Q.CustLine.nattribute.

KojoKitchen.qCustLine


16/138

16

The following table provides mapping between the conceptual model Action/Activities to Java classes.

Actions/Activities

ABCmod Constructs Java Classes

Arrivals Arrivals

StaffChange StaffChange

Serving Serving

Other classes that make up the Kojos Kitchen ABSmod/J simulation model include:

Output(referenced by KojoKitchen.output): Contains the SSOVs.

RVPs(referenced by KojoKitchen.rvp): Contains the Java methods used to implement the CM

RVPs.

Seeds: The class used to pass seeds for random number generators used in implementing the

various RVPs.

The package kkSimModelprovides public access to the following:

The constructor KojoKitchento allow creation and initialisation of a KojoKitchenobject,

The method getPropLongWait() to allow access the value of the output variable propLongwait. All public methods provided by the class AOSimulation(e.g. runsimulation) for supporting

experimentation.

Results of the Validation Experimentation

Base Case (RG.Counter.addEmp = 0)

Start of log shows proper initialisation and start of the model execution.

Case 1 - no additional employeeClock: 0.0, Q.CustLine.n: 0, RG.Counter.n: 0, input RG.Counter.uNumEmp: 0------------SBL----------TimeStamp:0.0 Activity/Action: kkSimModel.StaffChangeTimeStamp:2.3590927534467654 Activity/Action: kkSimModel.ArrivalsTimeStamp:720.0 Stop Notification----------------------Clock: 0.0, Q.CustLine.n: 0, RG.Counter.n: 0, input RG.Counter.uNumEmp: 2------------SBL----------TimeStamp:2.3590927534467654 Activity/Action: kkSimModel.ArrivalsTimeStamp:90.0 Activity/Action: kkSimModel.StaffChangeTimeStamp:720.0 Stop Notification

The continuation of the log shows that an arriving customer ends up at the conter. and start of the model

execution.

----------------------Clock: 2.3590927534467654, Q.CustLine.n: 0, RG.Counter.n: 1, input RG.Counter.uNumEmp: 2------------SBL----------

TimeStamp:6.5341389054485095 Activity/Action: kkSimModel.ArrivalsTimeStamp:7.3176282053544295 Activity/Action: kkSimModel.ServingTimeStamp:90.0 Activity/Action: kkSimModel.StaffChangeTimeStamp:720.0 Stop Notification----------------------

Shows the state of the model

after the Initialise action and

before the StaffChan e action.

The RG.Counter.numEmp

attribute is updated by the

StaffChange action. The next

scheduled behaviour object is

the Arrivals action.

Note the Arrivals action place the

Customer entity in Q.CustLine, but

the starting event of the Serving

activity moved the entity to the

Counter group.


17/138

17

The continuation of the log shows that another arriving customer will also move through the queue to

the counter at the same time.Clock: 6.5341389054485095, Q.CustLine.n: 0, RG.Counter.n: 2, input RG.Counter.uNumEmp: 2------------SBL----------TimeStamp:6.563480393383569 Activity/Action: kkSimModel.ArrivalsTimeStamp:7.3176282053544295 Activity/Action: kkSimModel.ServingTimeStamp:9.79073557174359 Activity/Action: kkSimModel.Serving

TimeStamp:90.0 Activity/Action: kkSimModel.StaffChangeTimeStamp:720.0 Stop Notification----------------------

The continuation of the log shows that another arriving customer will now remain in line since there is

no room at the counter. Note that the next pending behaviour object is the Serving activity which willmake place at the counter for this newly arrived customer.Clock: 6.563480393383569, Q.CustLine.n: 1, RG.Counter.n: 2, input RG.Counter.uNumEmp: 2------------SBL----------TimeStamp:7.3176282053544295 Activity/Action: kkSimModel.ServingTimeStamp:9.79073557174359 Activity/Action: kkSimModel.ServingTimeStamp:13.652527460896664 Activity/Action: kkSimModel.ArrivalsTimeStamp:90.0 Activity/Action: kkSimModel.StaffChangeTimeStamp:720.0 Stop Notification

The continuation of the log shows that after the end of the Serving activity the customer in the queue is

no longer there. The end of the Serving activity removed a Customer from the Counter which allowedthe condition to start another Serving activity which moved the customer from the queue to the counter.----------------------Clock: 7.3176282053544295, Q.CustLine.n: 0, RG.Counter.n: 2, input RG.Counter.uNumEmp: 2------------SBL----------TimeStamp:9.79073557174359 Activity/Action: kkSimModel.ServingTimeStamp:13.652527460896664 Activity/Action: kkSimModel.ArrivalsTimeStamp:14.040522525153227 Activity/Action: kkSimModel.ServingTimeStamp:90.0 Activity/Action: kkSimModel.StaffChange

The continuation of the log shows how the end of a Serving activity reduces the number of customers at

the Counter when no customers exist in the queue.----------------------Clock: 9.79073557174359, Q.CustLine.n: 0, RG.Counter.n: 1, input RG.Counter.uNumEmp: 2------------SBL----------TimeStamp:13.652527460896664 Activity/Action: kkSimModel.ArrivalsTimeStamp:14.040522525153227 Activity/Action: kkSimModel.Serving

TimeStamp:90.0 Activity/Action: kkSimModel.StaffChangeTimeStamp:720.0 Stop Notification

Examination of the log (not shown here) shows the proper operation of the model with customers

arriving and leaving according to expected behaviour. At t = 90.0, the log shows no changes in the

number of employees at the counter since in the base case, no additional employees are added during thebusy period.----------------------Clock: 86.09923816047561, Q.CustLine.n: 0, RG.Counter.n: 1, input RG.Counter.uNumEmp: 2------------SBL----------TimeStamp:90.0 Activity/Action: kkSimModel.StaffChangeTimeStamp:90.40314790356787 Activity/Action: kkSimModel.ArrivalsTimeStamp:91.03701794281554 Activity/Action: kkSimModel.ServingTimeStamp:720.0 Stop Notification----------------------Clock: 90.0, Q.CustLine.n: 0, RG.Counter.n: 1, input RG.Counter.uNumEmp: 2------------SBL----------TimeStamp:90.40314790356787 Activity/Action: kkSimModel.ArrivalsTimeStamp:91.03701794281554 Activity/Action: kkSimModel.ServingTimeStamp:210.0 Activity/Action: kkSimModel.StaffChangeTimeStamp:720.0 Stop Notification

Two instances of the Serving

activity existone serving

each of the Customer entities

in the group.


18/138

18

The log shows the customer line becoming quite long.----------------------Clock: 139.82792741859404, Q.CustLine.n: 5, RG.Counter.n: 2, input RG.Counter.uNumEmp: 2------------SBL----------TimeStamp:141.0792529016623 Activity/Action: kkSimModel.ArrivalsTimeStamp:141.86391422275335 Activity/Action: kkSimModel.ServingTimeStamp:141.9920036036326 Activity/Action: kkSimModel.ServingTimeStamp:210.0 Activity/Action: kkSimModel.StaffChange

TimeStamp:720.0 Stop Notification----------------------Clock: 141.0792529016623, Q.CustLine.n: 6, RG.Counter.n: 2, input RG.Counter.uNumEmp: 2------------SBL----------TimeStamp:141.86391422275335 Activity/Action: kkSimModel.ServingTimeStamp:141.9920036036326 Activity/Action: kkSimModel.ServingTimeStamp:142.91555594940115 Activity/Action: kkSimModel.ArrivalsTimeStamp:210.0 Activity/Action: kkSimModel.StaffChangeTimeStamp:720.0 Stop Notification----------------------Clock: 141.86391422275335, Q.CustLine.n: 5, RG.Counter.n: 2, input RG.Counter.uNumEmp: 2

The log shows the end of the simulation run where no customers exist at closing time.----------------------Clock: 657.2316782686836, Q.CustLine.n: 0, RG.Counter.n: 1, input RG.Counter.uNumEmp: 2------------SBL----------TimeStamp:658.5392258728331 Activity/Action: kkSimModel.Arrivals

TimeStamp:660.4848293594265 Activity/Action: kkSimModel.ServingTimeStamp:720.0 Stop Notification----------------------Clock: 658.5392258728331, Q.CustLine.n: 0, RG.Counter.n: 2, input RG.Counter.uNumEmp: 2------------SBL----------TimeStamp:660.4848293594265 Activity/Action: kkSimModel.ServingTimeStamp:662.6859069822764 Activity/Action: kkSimModel.ServingTimeStamp:720.0 Stop Notification----------------------Clock: 660.4848293594265, Q.CustLine.n: 0, RG.Counter.n: 1, input RG.Counter.uNumEmp: 2------------SBL----------TimeStamp:662.6859069822764 Activity/Action: kkSimModel.ServingTimeStamp:720.0 Stop Notification----------------------Clock: 662.6859069822764, Q.CustLine.n: 0, RG.Counter.n: 0, input RG.Counter.uNumEmp: 2------------SBL----------TimeStamp:720.0 Stop Notification

----------------------1, 0.5054347826086957

The log shows the end of the simulation run where no customers exist at closing time.

Last line show the value of the output variable

propLongWait, i.e. in this run 50% of customers waiting


19/138

19

Alternate Case (RG.Counter.addEmp = 1)

The log for the alternate case shows the same behaviour at the start of the observation interval. But at t =

90, the number of employees was increased to three, which allows up to three customers to be serviced

at the Counter.----------------------Clock: 86.09923816047561, Q.CustLine.n: 0, RG.Counter.n: 1, input RG.Counter.uNumEmp: 2------------SBL----------TimeStamp:90.0 Activity/Action: kkSimModel.StaffChangeTimeStamp:90.40314790356787 Activity/Action: kkSimModel.ArrivalsTimeStamp:91.03701794281554 Activity/Action: kkSimModel.ServingTimeStamp:720.0 Stop Notification----------------------Clock: 90.0, Q.CustLine.n: 0, RG.Counter.n: 1, input RG.Counter.uNumEmp: 3------------SBL----------TimeStamp:90.40314790356787 Activity/Action: kkSimModel.ArrivalsTimeStamp:91.03701794281554 Activity/Action: kkSimModel.ServingTimeStamp:210.0 Activity/Action: kkSimModel.StaffChangeTimeStamp:720.0 Stop Notification

----------------------Clock: 91.91608500885084, Q.CustLine.n: 0, RG.Counter.n: 2, input RG.Counter.uNumEmp: 3

------------SBL----------TimeStamp:93.10153334964482 Activity/Action: kkSimModel.ArrivalsTimeStamp:93.59553811868535 Activity/Action: kkSimModel.ServingTimeStamp:97.08795009608619 Activity/Action: kkSimModel.ServingTimeStamp:210.0 Activity/Action: kkSimModel.StaffChangeTimeStamp:720.0 Stop Notification----------------------Clock: 93.10153334964482, Q.CustLine.n: 0, RG.Counter.n: 3, input RG.Counter.uNumEmp: 3------------SBL----------TimeStamp:93.59553811868535 Activity/Action: kkSimModel.ServingTimeStamp:94.95123488899888 Activity/Action: kkSimModel.ArrivalsTimeStamp:97.08795009608619 Activity/Action: kkSimModel.ServingTimeStamp:100.23465076512142 Activity/Action: kkSimModel.ServingTimeStamp:210.0 Activity/Action: kkSimModel.StaffChangeTimeStamp:720.0 Stop Notification

The log shows that the number of employees drops back to 2 at the end of the busy periods (shown for

the first busy period here):----------------------Clock: 209.0527233535199, Q.CustLine.n: 0, RG.Counter.n: 2, input RG.Counter.uNumEmp: 3------------SBL----------TimeStamp:210.0 Activity/Action: kkSimModel.StaffChangeTimeStamp:212.82177002486264 Activity/Action: kkSimModel.ArrivalsTimeStamp:213.98274433824778 Activity/Action: kkSimModel.ServingTimeStamp:214.08086560018566 Activity/Action: kkSimModel.ServingTimeStamp:720.0 Stop Notification----------------------Clock: 210.0, Q.CustLine.n: 0, RG.Counter.n: 2, input RG.Counter.uNumEmp: 2------------SBL----------TimeStamp:212.82177002486264 Activity/Action: kkSimModel.ArrivalsTimeStamp:213.98274433824778 Activity/Action: kkSimModel.ServingTimeStamp:214.08086560018566 Activity/Action: kkSimModel.ServingTimeStamp:420.0 Activity/Action: kkSimModel.StaffChange

TimeStamp:720.0 Stop Notification


20/138

20

The log shows interesting phenomena at the end of the busy period. It shows 2 employees at the

counter and yet three customers being served. This represents the case where the leaving employee

needed to stay a few minutes beyond the end of his or her shift to finish serving a customer. The logdoes show that the counter never exceeds 3 after the Serving activity is completed.----------------------Clock: 539.2566934620494, Q.CustLine.n: 4, RG.Counter.n: 3, input RG.Counter.uNumEmp: 3

------------SBL----------TimeStamp:540.0 Activity/Action: kkSimModel.StaffChangeTimeStamp:540.0175107086852 Activity/Action: kkSimModel.ArrivalsTimeStamp:540.7470173623846 Activity/Action: kkSimModel.ServingTimeStamp:541.1650576051524 Activity/Action: kkSimModel.ServingTimeStamp:543.2561145485046 Activity/Action: kkSimModel.ServingTimeStamp:720.0 Stop Notification----------------------Clock: 540.0, Q.CustLine.n: 4, RG.Counter.n: 3, input RG.Counter.uNumEmp: 2------------SBL----------TimeStamp:540.0175107086852 Activity/Action: kkSimModel.ArrivalsTimeStamp:540.7470173623846 Activity/Action: kkSimModel.ServingTimeStamp:541.1650576051524 Activity/Action: kkSimModel.ServingTimeStamp:543.2561145485046 Activity/Action: kkSimModel.ServingTimeStamp:720.0 Stop Notification

In the alternate case the line of customers could still get rather long, but clearly not as often. For the test

simulation run only 6% of customers waited longer than 5 minutes.----------------------Clock: 657.2316782686836, Q.CustLine.n: 0, RG.Counter.n: 1, input RG.Counter.uNumEmp: 2------------SBL----------TimeStamp:658.5392258728331 Activity/Action: kkSimModel.ArrivalsTimeStamp:660.4848293594265 Activity/Action: kkSimModel.ServingTimeStamp:720.0 Stop Notification----------------------Clock: 658.5392258728331, Q.CustLine.n: 0, RG.Counter.n: 2, input RG.Counter.uNumEmp: 2------------SBL----------TimeStamp:660.4848293594265 Activity/Action: kkSimModel.ServingTimeStamp:662.6859069822764 Activity/Action: kkSimModel.ServingTimeStamp:720.0 Stop Notification----------------------Clock: 660.4848293594265, Q.CustLine.n: 0, RG.Counter.n: 1, input RG.Counter.uNumEmp: 2------------SBL----------TimeStamp:662.6859069822764 Activity/Action: kkSimModel.Serving

TimeStamp:720.0 Stop Notification----------------------Clock: 662.6859069822764, Q.CustLine.n: 0, RG.Counter.n: 0, input RG.Counter.uNumEmp: 2------------SBL----------TimeStamp:720.0 Stop Notification----------------------1, 0.059782608695652176


21/138

21

Experimentation and Analysis

Experimentation

A number of experimentation programs were created for this project. Review the following Java

classes:

1) KojoExperiment1: used for generation of trace logs for the purpose of verification andvalidation, reported in the previous section.

2) KojoExperiment2: generates a table equivalent to Table 7.2 of the text book showing simulationvalues for 20 simulation runs for each Case. The results are shown below(see the text book for a

discussion of these results)2.

Run Case 1 Case 2------------------------

1 0.505 0.0602 0.457 0.1713 0.731 0.1184 0.665 0.2945 0.634 0.230

6 0.517 0.0627 0.629 0.1268 0.701 0.1099 0.463 0.01710 0.514 0.22311 0.570 0.16112 0.519 0.21213 0.410 0.11614 0.609 0.18015 0.151 0.01416 0.686 0.23717 0.572 0.07218 0.599 0.204

19 0.455 0.13220 0.659 0.234------------------------

PE 0.552 0.148S(n) 0.128 0.077zeta 0.050 0.030

CI Min 0.503 0.119CI Max 0.602 0.178------------------------

2The results differ from those in the textbook since the data generated in the text book used a model where the arrivals of the

Sushi and Sandwich customers were modelled as two separate entity streams rather than a single entity stream.


22/138

22

3) KojoExperiment3: generates a table equivalent to Table 7.3 of the text book showing simulation

values for up to 10000 simulation runs for each Case. This table shows the effect of increasing

the number of runs on the confidence interval. The results are shown below (see the text bookfor a discussion of these results).

------------------------------------------------------------------Case 1

------------------------------------------------------------------n y(n) s(n) zeta(n) CI Min CI Max zeta(n)/y(n)------------------------------------------------------------------

20 0.552 0.128 0.050 0.503 0.602 0.09030 0.558 0.112 0.035 0.523 0.593 0.06240 0.565 0.112 0.030 0.535 0.595 0.05360 0.582 0.107 0.023 0.559 0.605 0.04080 0.578 0.108 0.020 0.558 0.598 0.035100 0.581 0.108 0.018 0.564 0.599 0.031

1000 0.587 0.110 0.006 0.581 0.593 0.01010000 0.586 0.113 0.002 0.584 0.588 0.003------------------------------------------------------------------------------------------------------------------------------------

Case 2------------------------------------------------------------------n y(n) s(n) zeta(n) CI Min CI Max zeta(n)/y(n)------------------------------------------------------------------

20 0.148 0.077 0.030 0.119 0.178 0.20030 0.151 0.086 0.027 0.124 0.177 0.17740 0.162 0.108 0.029 0.133 0.191 0.17860 0.173 0.116 0.025 0.148 0.198 0.14480 0.166 0.111 0.021 0.145 0.186 0.125100 0.167 0.112 0.019 0.149 0.186 0.111

1000 0.174 0.121 0.006 0.168 0.180 0.03610000 0.174 0.119 0.002 0.172 0.176 0.011------------------------------------------------------------------


23/138

23

Output Analysis

The number of runs was increased to 30 in KojoExperiment2 to generate interval half lengths that meet

the 10% criterion (that is (n)/y(n) < 0.1)

Run Case 1 Case 2------------------------

1 0.505 0.0602 0.457 0.1713 0.731 0.1184 0.665 0.2945 0.634 0.2306 0.517 0.0627 0.629 0.1268 0.701 0.1099 0.463 0.01710 0.514 0.22311 0.570 0.16112 0.519 0.21213 0.410 0.11614 0.609 0.18015 0.151 0.014

16 0.686 0.23717 0.572 0.07218 0.599 0.20419 0.455 0.13220 0.659 0.23421 0.671 0.33522 0.620 0.24523 0.565 0.01224 0.533 0.03825 0.431 0.11126 0.578 0.24327 0.522 0.22528 0.610 0.18129 0.654 0.04330 0.514 0.115

------------------------PE 0.558 0.151

S(n) 0.112 0.086zeta 0.035 0.027

CI Min 0.523 0.124CI Max 0.593 0.177------------------------

Conclusions

The result in the Output Analysis section shows a significant decrease in the percent of customers that

wait longer than five minutes; from a point estimate of 56% to a point estimate of 15%. Thus clearly

adding an employee during busy periods significantly improves customer service.

Given that a cost is associated with adding an employee, another modelling and simulation study isrecommended to explore alternative scheduling. For example, is it possible to offset the cost additional

employee during busy periods by reducing the number of employees during off peak times. Such astudy would involve revising the project goal would involve only minor modifications to the model from

this study.


24/138

24

Annex AData ModellingThe data models used in the Kojos Kitchen project are:

1) Customer arrivals: Arrivals of customers are modelled as Poisson processes. This implies that

inter-arrival times are exponentially distributed. But arrivals are not constant since busy periods

exist during the operation of the deli. Thus arrivals are models as piecewise homogeneous

stochastic process (see section 3.1 of the textbook) where inter-arrival times are modelled withan exponential distribution whose mean is different for different periods of time. The following

table shows how the mean of the exponential distribution varies over the observation interval.

Period Exponential

Mean

10h00 to 11h30 10 minutes

11h30 to 13h30 1.75 minutes




2) Customer type: The type of the customer for arriving customers is 65% a sandwich customerand 35% a sushi customer.

3) Service time: The time to service a customer is modelled with a uniform distribution for both

types of customers with the following parameters.

Customer Type Minimum Parameter Maximum Parameter

Sandwich 3 minutes 5 minutes

Sushi 5 minutes 8 minutes


25/138

25

Kojos Kitchen (Version 2)

Problem Description

Problem StatementKojos Kitchen is one of the fast food outlets in the food court of a shopping mall.Kojos manager is very happywith business, but has been receiving complaints from customers about long waiting times. He is interested in

exploring staffing options to reduce these complaints.

SUI Details

Figure 4Kojos Kitchen Fast Food Outlet

The mall (and hence Kojos) is open between 10:00am and 9:00 pm every day. Kojos serves only two types of

product; namely, sandwiches and sushi. Two rush hour periods occur during the business day, one between 11:30am and 1:30 pm, and the other between 5:00 pm and 7:00 pm. Currently two employees work at the counterthroughout the day preparing sandwiches and sushi products for the customers.

SandwichandSushiCounter

Su

Sw

SuSu SwSw

E

E

Sw Su E

EmployeeSushi

Customer

Sandwich

Customer


26/138

26

Project GoalThe specific interest is with comparing the current situation (base case) to an alternative where a third employee is

added during the busy periods (between 11:30 am and 1:30 pm and between 5:00 pm and 7:00 pm). Theperformance measure of interest is the percentage of customers that wait longer than 5 minutes for service over

the course of a business day.

Parameters

RG.Counter.schedule: This attribute consists of a sequence of 5 values that gives the number of employees

during the following time slots 10:00 am to 11:30 am, 11:30 am to 1:30 pm, 1:30 pm to 5:00 pm, 5:00 pm to

7:00 pm, 7:00 pm to 9:00 pm (see the Experimentation section below for examples).

Experimentation

Study: Bounded Horizon Study.

Observation Interval: Time units areminutes.

Observation interval between t=0 and time after t=660 when all customers have left the deli.

Four cases have been defined as shown in the following table.

Case Parameter

RG.Counter.schedule

Person-Hours

Case 1 (Base Case) < 2, 2, 2, 2, 2 > 22

Case 2 < 2, 3, 2, 3, 2 > 26

Case 3 < 1, 3, 1, 3, 1 > 19

Case 4 < 1, 3, 2, 3, 1 > 22.5

The last column gives the number of person-hours that the schedule represents3. The number of

person-hours represents the schedule cost. Thus Case 2 increases the schedule cost, Case 3 reduces the

schedule cost while Case 4 maintains about the same schedule cost.

Output

propLongWait: The proportion of customers that wait more than 5 minutes in line to reach the counter.

3The following sequence gives the number of hours for each shift: {1.5, 2, 3.5, 2, 2} for a total of 11 hours.


27/138

27

ABCmod Conceptual Model

High Level Conceptual Model

Simplifications

We assume there are only two types of customer one type purchases only sandwiches and the othertype purchases only sushi products.

Structural View

Figure 5Kojos Kitchen Structural Diagram

Entity Categories: CustLine: An entity structure with role=Queue and scope=Unary that represents the line of customers in front

of the counter.

Counter: An entity structure with role=Resource Group and scope = Unary that represents the counter where

customers are being served.

Customer: An entity structure with role=Consumer and scope = Class that represents the collection of

customers requiring service at the counter. There are two types of customers, the sandwich customer and thesushi customer. Customers are distinguished using the Customer attribute uType.

Behavioural View

Figure 6Customer Life Cycle

Actions: Arrivals: This scheduled action generates the input entity stream of customers.

StaffChange: The change in the number of employees behind the counter. This Action is not shown in

the behavioural diagram since it is not part of the customer life cycle.

Activities: Serving: This activity represents the serving of a customer.

Q.CustLine

RG.Counter

iC.Customer

Legend

Arrivals

Serving


28/138

28

Input

Exogenous Input (Entity Stream)

Variable

Name

Description Domain Sequence Range Sequence

uCB This input entity streamrepresents the arrivingcustomers

RVP.DuC() 1 customer arrives at each

arrival.

Endogenous Input (independent)

Variable Name Description Domain Sequence Range Sequence

RG.Counter.uNumEm

pThis input

variable

represents the

number of

employees at the

counter serving

customers.

< 0, (10h00)

90, (11h30 start of

busy period)

210, (13h30 end of

busy period)

420, (17h00, start of

busy period)

540> (19h00 end ofbusy period)

RG.Counter.schedule

Endogenous Input (Semi-independent)

Variable Name Description Value(s)

uSrvTm Service time of a customer. RVP.uSrvTm()iC.Customer.uType Defines the type of an arriving

customer.

RVP.uCustomerType()


29/138

29

Detailed Conceptual Model

Structural Components

Parameters

Name Description ValueRG.Counter.schedule Employee schedule for the day that consists of a

sequence of number of employees for each of the

following timeslots: 10:00 am to 11:30 am, 11:30am to 1:30 pm, 1:30 pm to 5:00 pm, 5:00 pm to

7:00 pm, 7:00 pm to 9:00 pm, that is the range for

the domain sequence .

One of the four following

sequences:

< 2, 2, 2, 2, 2 >

< 2, 3, 2, 3, 2 >

< 1, 3, 1, 3, 1 >

< 1, 3, 2, 3, 1 >

Consumer Class: CustomerThis entity structure represents the customers who purchase items at Kojo's Kitchen.

Attributes DescriptionstartWaitTime Time stamp that holds the value of time when the customer enters the customer line.

uType The assigned value indicates the type of customer. Two values are possible: 'W' for a

sandwich customer or 'U' for a sushi customer.

Resource Group Unary: CounterThis resource group represents the counter where customers receive service.

Attributes Descriptionlist The group of the Customer entities that are being served.

n Number of entries in List (necessarily n RG.Counter.empNum).

uNumEmp Input variable that defines the number of employees at the counter available to

service customers.

schedule Parameter that defines the employee schedule.

Queue Unary: CustLineThe queue of customers waiting for service at the counter.

Attributes Descriptionlist List of the customers entities waiting in line for service.Discipline: FIFO.

n The number of iC.Customer entities in List.

Behavioural components

Time units: minutes

Observation interval: tB0B= 0, Implicit Stop Condition: (t B>660 minutes (11 hour business day) ANDRG.Counter.n = 0).

Action: Initialise

TimeSequence < 0 >Event SCS RG.Counter.n 0

Q.CustLine.n 0

SSOV.numServed 0

SSOV.numLongWait 0


30/138

30

Output

OUTPUTS

Simple Scalar Output Variables (SSOV's)

Name DescriptionnumServed Number of customers served.

numLongWait Number of customers that waited longer than 5 minutes.

propLongWait numLongWait/numServed.

Input Constructs

Random Variate Procedures

Name Description Data ModelRVP.DuC() Provides the values of the arrival

times of customers. No arrivals

occur after closing (t = 660).

Exponential(X) where X is:

MEAN1=10, for 0 t < 90

MEAN2=1.75, for 90 t < 210

MEAN3=9, for 210 t < 420

MEAN4=2.25, for 420 t < 540

MEAN5=6, for 540 t < 660

(All values are in minutes.)

RVP.uCustomerType() Provides the type of the arrivingcustomer. Returns either W

(sandwich customer) or U (sushi

customer).

Proportion of sandwich customers:PROPW=65%

Proportion of sushi customers:

PROPU=35%

RVP.uSrvTm(type) Provides a value for the service time

of customer according to the value

of type.

For type W (sandwich customer):

UNIFORM(STWMIN, STWMAX)

where STWMIN=3 minutes and

STWMAX=5 minutes.

For type U (sushi customer):

UNIFORM(STUMIN, STUMAX)

where STUMIN=5 minutes and

STUMAX=8 minutes.

Action: ArrivalsThe Input Entity Stream of arriving customers. TimeSequence RVP.DuC()

Event SCS iC.Customer SP.Derive(Customer)

iC.Customer.uType RVP.CustomerType()

iC.Customer.startWaitTime t

SP.InsertQue(Q.CustLine, iC.Customer)

Action: StaffChangeManages the value of the input variable RG.Counter.uNumEmp, that is,

schedules additional employee during busy times for the alternate case.

TimeSequence

Event SCS IF(t=0) THEN

RG.Counter.uNumEmp RG.Counter.schedule[0]ELSE IF(t=90) THEN

RG.Counter.uNumEmp RG.Counter.schedule[1]

ELSE IF(t=210) THEN


ELSE IF(t=420) THEN


ELSE IF(t=540) THEN


ENDIF


31/138

31

Behavioural Constructs

Activity: ServingService for a customer.

Precondition (RG.Counter.n < RB.Counter.uNumEmp) AND (Q.CustLine.n 0)

Event SCS iC.Customer SP.RemoveQue(Q.CustLine)

IF(tiC.Customer.StartWaitTime > 5)THEN

SSOV.numLongWait + 1

ENDIF

SSOV.numServed + 1

SSOV.propLongWait SSOV.numLongWait/SSOV.numServed

SP.InsertGroup(RG.Counter, iC.Customer)

Duration RVP.uSrvTm(iC.Customer.uType)

Event SCS SP.RemoveGroup(RG.Counter, iC.Customer)

SP.Leave(iC.Customer)

Design of Validation Experimentation

Given the simplicity of the model, it is possible to validate the model using a trace log as describedbelow. The model shall be validated for both the base case and the alternate case.

Trace Logging

The state of the simulation model is monitored by tracking the number of customers in Q.CustLine, the

number of customers in RG.Counter, and the input variable RG.Counter.uNumEmp. These values are

presented on a single line as follows:Clock: xxxxxxx, Q.CustLine.n: xx, RG.Counter.n: xx, RG.Counter.uNumEmp: xx

where thexxxsare replaced with current value of the clock and designated attribute values.


32/138

32

Simulation Model

Design of Simulation Model and Program

The simulation model is implemented in the class KojoKitchen(an extension of the ABSmod/J class

AOSimulationmodel) and a number of other classes used to implement the various constructs from the

ABCmod conceptual model. All Java classes that make up the Java Kojo Kitchen simulation model areplaced in the Java package kkSimModel.

The following table shows how the various ABCmod entity structures are mapped to Java classes and

how objects instantiated from these classes are reference by the KojoKitchenclass.

Entity Structures

ABCmod

Construct

Java Class Object References

iC.Customer Customer

Notes: The enumerated data type Typeis defined

to restrict the values of the uTypeattribute to W

and U.

Typically by the reference variable

icCustomerin the various

methods that manipulate Customer

objects.

RG.Counter CounterNotes:

The list of Customerobjects are maintained

in a HashSetobject. Thus the standardABCmod procedures SP.InsertGrpand

SP.RemoveGrpare implemented as methods in

the Counterclass.

The attribute n is note implemented as an

instance variable since it is maintained by the

HashSetobject. Thus the method getNprovides the means to obtain the value of the

attribute.

KojoKitchen.rgCounter

Q.CustLine ArrayList(standard Java Class)

Notes

The various methods available in the

ArrayListclass provide the implementationof the various ABCmod procedures, such as

SP.InsertQue (qCustLine.add)

SP.RemveQue (qCustLine.remove).

The attribute n is maintained within the

ArrayListobject (adjusted automatically

when ArrayListmethods are called). Themethod qCustLine.size() provides the value of

the Q.CustLine.nattribute.

KojoKitchen.qCustLine

The following table provides mapping between the conceptual model Action/Activities to Java classes.Actions/Activities

ABCmod Constructs Java ClassesArrivals Arrivals

StaffChange StaffChange

Serving Serving


33/138

33

Other classes that make up the Kojos Kitchen ABSmod/J simulation model include:

Output(referenced by KojoKitchen.output): Contains the SSOVs.

RVPs(referenced by KojoKitchen.rvp): Contains the Java methods used to implement the CMRVPs.

Seeds: The class used to pass seeds for random number generators used in implementing the

various RVPs.

The package kkSimModelprovides public access to the following:

The constructor KojoKitchento allow creation and initialisation of a KojoKitchenobject,

The method getPropLongWait() to allow access the value of the output variable propLongwait.

All public methods provided by the class AOSimulation(e.g. runsimulation) for supportingexperimentation.

Results of the Validation Experimentation

Case 1 (Base Case: RG.Counter.schedule = < 2, 2, 2, 2, 2 >)

Start of log shows proper initialisation and start of the model execution.

Case 1 - no additional employeeClock: 0.0, Q.CustLine.n: 0, RG.Counter.n: 0, input RG.Counter.uNumEmp: 0------------SBL----------TimeStamp:0.0 Activity/Action: kkSimModel.StaffChangeTimeStamp:2.3590927534467654 Activity/Action: kkSimModel.ArrivalsTimeStamp:720.0 Stop Notification----------------------Clock: 0.0, Q.CustLine.n: 0, RG.Counter.n: 0, input RG.Counter.uNumEmp: 2------------SBL----------TimeStamp:2.3590927534467654 Activity/Action: kkSimModel.ArrivalsTimeStamp:90.0 Activity/Action: kkSimModel.StaffChangeTimeStamp:720.0 Stop Notification

The continuation of the log shows that an arriving customer ends up at the conter. and start of the model

execution.

----------------------Clock: 2.3590927534467654, Q.CustLine.n: 0, RG.Counter.n: 1, input RG.Counter.uNumEmp: 2------------SBL----------TimeStamp:6.5341389054485095 Activity/Action: kkSimModel.ArrivalsTimeStamp:7.3176282053544295 Activity/Action: kkSimModel.ServingTimeStamp:90.0 Activity/Action: kkSimModel.StaffChangeTimeStamp:720.0 Stop Notification----------------------

The continuation of the log shows that another arriving customer will also move through the queue to

the counter at the same time.

Clock: 6.5341389054485095, Q.CustLine.n: 0, RG.Counter.n: 2, input RG.Counter.uNumEmp: 2------------SBL----------TimeStamp:6.563480393383569 Activity/Action: kkSimModel.ArrivalsTimeStamp:7.3176282053544295 Activity/Action: kkSimModel.ServingTimeStamp:9.79073557174359 Activity/Action: kkSimModel.ServingTimeStamp:90.0 Activity/Action: kkSimModel.StaffChangeTimeStamp:720.0 Stop Notification

----------------------

Shows the state of the model

after the Initialise action and

before the StaffChange action.

The RG.Counter.numEmp

attribute is updated by the

StaffChange action. The next

scheduled behaviour object is

the Arrivals action.

Note the Arrivals action place the

Customer entity in Q.CustLine, but

the starting event of the Serving

activity moved the entity to the

Counter group.

Two instances of the Serving

activity existone serving

each of the Customer entities

in the group.


34/138

34

The continuation of the log shows that another arriving customer will now remain in line since there isno room at the counter. Note that the next pending behaviour object is the Serving activity which will

make place at the counter for this newly arrived customer.

Clock: 6.563480393383569, Q.CustLine.n: 1, RG.Counter.n: 2, input RG.Counter.uNumEmp: 2------------SBL----------TimeStamp:7.3176282053544295 Activity/Action: kkSimModel.Serving

TimeStamp:9.79073557174359 Activity/Action: kkSimModel.ServingTimeStamp:13.652527460896664 Activity/Action: kkSimModel.ArrivalsTimeStamp:90.0 Activity/Action: kkSimModel.StaffChange

TimeStamp:720.0 Stop Notification

The continuation of the log shows that after the end of the Serving activity the customer in the queue isno longer there. The end of the Serving activity removed a Customer from the Counter which allowedthe condition to start another Serving activity which moved the customer from the queue to the counter.

----------------------Clock: 7.3176282053544295, Q.CustLine.n: 0, RG.Counter.n: 2, input RG.Counter.uNumEmp: 2------------SBL----------TimeStamp:9.79073557174359 Activity/Action: kkSimModel.ServingTimeStamp:13.652527460896664 Activity/Action: kkSimModel.ArrivalsTimeStamp:14.040522525153227 Activity/Action: kkSimModel.Serving

TimeStamp:90.0 Activity/Action: kkSimModel.StaffChange

The continuation of the log shows how the end of a Serving activity reduces the number of customers atthe Counter when no customers exist in the queue.----------------------Clock: 9.79073557174359, Q.CustLine.n: 0, RG.Counter.n: 1, input RG.Counter.uNumEmp: 2------------SBL----------TimeStamp:13.652527460896664 Activity/Action: kkSimModel.ArrivalsTimeStamp:14.040522525153227 Activity/Action: kkSimModel.ServingTimeStamp:90.0 Activity/Action: kkSimModel.StaffChangeTimeStamp:720.0 Stop Notification

Examination of the log (not shown here) shows the proper operation of the model with customersarriving and leaving according to expected behaviour. At t = 90.0, the log shows no changes in the

number of employees at the counter since in the base case, no additional employees are added during thebusy period.----------------------Clock: 86.09923816047561, Q.CustLine.n: 0, RG.Counter.n: 1, input RG.Counter.uNumEmp: 2------------SBL----------TimeStamp:90.0 Activity/Action: kkSimModel.StaffChangeTimeStamp:90.40314790356787 Activity/Action: kkSimModel.ArrivalsTimeStamp:91.03701794281554 Activity/Action: kkSimModel.ServingTimeStamp:720.0 Stop Notification----------------------Clock: 90.0, Q.CustLine.n: 0, RG.Counter.n: 1, input RG.Counter.uNumEmp: 2------------SBL----------TimeStamp:90.40314790356787 Activity/Action: kkSimModel.ArrivalsTimeStamp:91.03701794281554 Activity/Action: kkSimModel.ServingTimeStamp:210.0 Activity/Action: kkSimModel.StaffChangeTimeStamp:720.0 Stop Notification


35/138

35

The log shows the customer line becoming quite long.----------------------Clock: 139.82792741859404, Q.CustLine.n: 5, RG.Counter.n: 2, input RG.Counter.uNumEmp: 2------------SBL----------TimeStamp:141.0792529016623 Activity/Action: kkSimModel.ArrivalsTimeStamp:141.86391422275335 Activity/Action: kkSimModel.ServingTimeStamp:141.9920036036326 Activity/Action: kkSimModel.ServingTimeStamp:210.0 Activity/Action: kkSimModel.StaffChange

TimeStamp:720.0 Stop Notification----------------------Clock: 141.0792529016623, Q.CustLine.n: 6, RG.Counter.n: 2, input RG.Counter.uNumEmp: 2------------SBL----------TimeStamp:141.86391422275335 Activity/Action: kkSimModel.ServingTimeStamp:141.9920036036326 Activity/Action: kkSimModel.ServingTimeStamp:142.91555594940115 Activity/Action: kkSimModel.ArrivalsTimeStamp:210.0 Activity/Action: kkSimModel.StaffChangeTimeStamp:720.0 Stop Notification----------------------Clock: 141.86391422275335, Q.CustLine.n: 5, RG.Counter.n: 2, input RG.Counter.uNumEmp: 2

The log shows the end of the simulation run where no customers exist at closing time.----------------------Clock: 657.2316782686836, Q.CustLine.n: 0, RG.Counter.n: 1, input RG.Counter.uNumEmp: 2------------SBL----------TimeStamp:658.5392258728331 Activity/Action: kkSimModel.ArrivalsTimeStamp:660.4848293594265 Activity/Action: kkSimModel.ServingTimeStamp:720.0 Stop Notification----------------------Clock: 658.5392258728331, Q.CustLine.n: 0, RG.Counter.n: 2, input RG.Counter.uNumEmp: 2------------SBL----------TimeStamp:660.4848293594265 Activity/Action: kkSimModel.ServingTimeStamp:662.6859069822764 Activity/Action: kkSimModel.ServingTimeStamp:720.0 Stop Notification----------------------Clock: 660.4848293594265, Q.CustLine.n: 0, RG.Counter.n: 1, input RG.Counter.uNumEmp: 2------------SBL----------TimeStamp:662.6859069822764 Activity/Action: kkSimModel.ServingTimeStamp:720.0 Stop Notification----------------------Clock: 662.6859069822764, Q.CustLine.n: 0, RG.Counter.n: 0, input RG.Counter.uNumEmp: 2------------SBL----------

TimeStamp:720.0 Stop Notification----------------------1, 0.5054347826086957

The log shows the end of the simulation run where no customers exist at closing time.

Last line show the value of the output variablepropLongWait, i.e. in this run 50% of customers waiting


36/138

36

Case 2 (RG.Counter.schedule = < 2, 3, 2, 3, 2 >)

The log for the case 2 shows the same behaviour at the start of the observation interval. But at t = 90, the

number of employees was increased to three, which allows up to three customers to be serviced at the

Counter.

----------------------

Clock: 86.09923816047561, Q.CustLine.n: 0, RG.Counter.n: 1, input RG.Counter.uNumEmp: 2------------SBL----------TimeStamp:90.0 Activity/Action: kkSimModel.StaffChangeTimeStamp:90.40314790356787 Activity/Action: kkSimModel.ArrivalsTimeStamp:91.03701794281554 Activity/Action: kkSimModel.ServingTimeStamp:720.0 Stop Notification----------------------Clock: 90.0, Q.CustLine.n: 0, RG.Counter.n: 1, input RG.Counter.uNumEmp: 3------------SBL----------TimeStamp:90.40314790356787 Activity/Action: kkSimModel.ArrivalsTimeStamp:91.03701794281554 Activity/Action: kkSimModel.ServingTimeStamp:210.0 Activity/Action: kkSimModel.StaffChangeTimeStamp:720.0 Stop Notification

----------------------

Clock: 91.91608500885084, Q.CustLine.n: 0, RG.Counter.n: 2, input RG.Counter.uNumEmp: 3------------SBL----------TimeStamp:93.10153334964482 Activity/Action: kkSimModel.ArrivalsTimeStamp:93.59553811868535 Activity/Action: kkSimModel.ServingTimeStamp:97.08795009608619 Activity/Action: kkSimModel.ServingTimeStamp:210.0 Activity/Action: kkSimModel.StaffChangeTimeStamp:720.0 Stop Notification----------------------Clock: 93.10153334964482, Q.CustLine.n: 0, RG.Counter.n: 3, input RG.Counter.uNumEmp: 3------------SBL----------TimeStamp:93.59553811868535 Activity/Action: kkSimModel.ServingTimeStamp:94.95123488899888 Activity/Action: kkSimModel.ArrivalsTimeStamp:97.08795009608619 Activity/Action: kkSimModel.ServingTimeStamp:100.23465076512142 Activity/Action: kkSimModel.ServingTimeStamp:210.0 Activity/Action: kkSimModel.StaffChangeTimeStamp:720.0 Stop Notification

The log shows that the employee scheduled is followed:----------------------Clock: 209.0527233535199, Q.CustLine.n: 0, RG.Counter.n: 2, input RG.Counter.uNumEmp: 3----------------------Clock: 210.0, Q.CustLine.n: 0, RG.Counter.n: 2, input RG.Counter.uNumEmp: 2

----------------------Clock: 417.10666624185376, Q.CustLine.n: 0, RG.Counter.n: 2, input RG.Counter.uNumEmp: 2----------------------Clock: 420.0, Q.CustLine.n: 0, RG.Counter.n: 2, input RG.Counter.uNumEmp: 3

----------------------Clock: 539.2566934620494, Q.CustLine.n: 4, RG.Counter.n: 3, input RG.Counter.uNumEmp: 3----------------------

Clock: 540.0, Q.CustLine.n: 4, RG.Counter.n: 3, input RG.Counter.uNumEmp: 2


37/138

37

The log shows interesting phenomena at the end of the busy period. It shows 2 employees at the

counter and yet three customers being served. This represents the case where the leaving employee

needed to stay a few minutes beyond the end of his or her shift to finish serving a customer. The logdoes show that the counter never exceeds 2 after the Serving activity is completed.----------------------Clock: 539.2566934620494, Q.CustLine.n: 4, RG.Counter.n: 3, input RG.Counter.uNumEmp: 3

------------SBL----------TimeStamp:540.0 Activity/Action: kkSimModel.StaffChangeTimeStamp:540.0175107086852 Activity/Action: kkSimModel.ArrivalsTimeStamp:540.7470173623846 Activity/Action: kkSimModel.ServingTimeStamp:541.1650576051524 Activity/Action: kkSimModel.ServingTimeStamp:543.2561145485046 Activity/Action: kkSimModel.ServingTimeStamp:720.0 Stop Notification----------------------Clock: 540.0, Q.CustLine.n: 4, RG.Counter.n: 3, input RG.Counter.uNumEmp: 2------------SBL----------TimeStamp:540.0175107086852 Activity/Action: kkSimModel.ArrivalsTimeStamp:540.7470173623846 Activity/Action: kkSimModel.ServingTimeStamp:541.1650576051524 Activity/Action: kkSimModel.ServingTimeStamp:543.2561145485046 Activity/Action: kkSimModel.ServingTimeStamp:720.0 Stop Notification

For Case 2, the line of customers could still get rather long, but clearly not as often. For the test

simulation run only 6% of customers waited longer than 5 minutes.----------------------Clock: 657.2316782686836, Q.CustLine.n: 0, RG.Counter.n: 1, input RG.Counter.uNumEmp: 2------------SBL----------TimeStamp:658.5392258728331 Activity/Action: kkSimModel.ArrivalsTimeStamp:660.4848293594265 Activity/Action: kkSimModel.ServingTimeStamp:720.0 Stop Notification----------------------Clock: 658.5392258728331, Q.CustLine.n: 0, RG.Counter.n: 2, input RG.Counter.uNumEmp: 2------------SBL----------TimeStamp:660.4848293594265 Activity/Action: kkSimModel.ServingTimeStamp:662.6859069822764 Activity/Action: kkSimModel.ServingTimeStamp:720.0 Stop Notification----------------------Clock: 660.4848293594265, Q.CustLine.n: 0, RG.Counter.n: 1, input RG.Counter.uNumEmp: 2------------SBL----------

TimeStamp:662.6859069822764 Activity/Action: kkSimModel.ServingTimeStamp:720.0 Stop Notification----------------------Clock: 662.6859069822764, Q.CustLine.n: 0, RG.Counter.n: 0, input RG.Counter.uNumEmp: 2------------SBL----------TimeStamp:720.0 Stop Notification----------------------1, 0.059782608695652176


38/138

38


The log shows that the employee scheduled is followed:----------------------Clock: 0.0, Q.CustLine.n: 0, RG.Counter.n: 0, input RG.Counter.uNumEmp: 1





For the test simulation run 29% of customers waited longer than 5 minutes.----------------------Clock: 712.8032535868364, Q.CustLine.n: 0, RG.Counter.n: 0, input RG.Counter.uNumEmp: 1------------SBL----------TimeStamp:720.0 Stop Notification----------------------Terminated 1, 0.29347826086956524


The log shows that the employee scheduled is followed:----------------------Clock: 0.0, Q.CustLine.n: 0, RG.Counter.n: 0, input RG.Counter.uNumEmp: 1



----------------------

Clock: 417.10666624185376, Q.CustLine.n: 1, RG.Counter.n: 1, input RG.Counter.uNumEmp: 2----------------------Clock: 420.0, Q.CustLine.n: 0, RG.Counter.n: 2, input RG.Counter.uNumEmp: 3



39/138

39

For the test simulation run 24% of customers waited longer than 5 minutes.----------------------Clock: 712.8032535868364, Q.CustLine.n: 0, RG.Counter.n: 0, input RG.Counter.uNumEmp: 1------------SBL----------TimeStamp:720.0 Stop Notification----------------------Terminated 1, 0.24456521739130435

Note that single runs for each case is not sufficient to draw conclusions.

Experimentation and Analysis

Experimentation

Two experimentation programs were created for this project. Review the following Java classes:

1) KojoExperiment1: used for generation of trace logs for the purpose of verification and

validation, reported in the previous section.2) KojoExperiment2: generates a table equivalent to Table 7.9 of the text book where Cases 2, 3,

and 4 were compared to Case 1 (Base Case). Thus confidence intervals for the differences

between the cases are generated. A confidence level of Ck= 0.967(Ck= 1- ( (1-C)/K) = 1( (10.9)/3) = 0.967 is used for each confidence interval to give an

overall confidence of C = 0.90. Thirty simulation runs were used to generate the table shown

below4.

-------------------------------------------------------------------------------------Comparison Point estimate(ybar(n)) s(n) zeta CI Min CI Max |zeta/ybar(n)|-------------------------------------------------------------------------------------Diff21 -0.408 0.011 0.044 -0.451 -0.364 0.107Diff31 -0.277 0.014 0.048 -0.325 -0.229 0.173Diff41 -0.319 0.013 0.048 -0.366 -0.271 0.149-------------------------------------------------------------------------------------

3) KojoExperiment3: Note that the results from KojoExperiment2 are note quite satisfying since for

Case 2 and Case 3, the confidence level does not meet the 10% criterion (/ y = 22%). The

number of simulation runs could be increased, but there is another alternative. If the confidence

level for Case 2 and Case 3 were reduced, then would be decreased as well as / y . It is thus

possible to use difference individual confidence interval to improve results from Case 2 and Case3 and still maintain an overall confidence interval according to the following equation derived

from Bonferonnis inequality.

1

(1 )K

k

k

C K C

Thus KojoExperiment3 included the means to give different values for the Cks.

Experimentation show that our confidence criterion is met with the following confidence levels:

C1= 0.99, C2= 0.94, C3= 0.97 for each of the confidence intervals of comparisons Diff21,

Diff31, and Diff41 respectively. It was still necessary to increase the number of runs to 70. See

the next section for results and discussion.

4The results differ from those in the textbook since the data generated in the text book used a model where the arrivals of the

Sushi and Sandwich customers were modelled as two separate entity streams rather than a single entity stream.


40/138

40

Output Analysis

The number of runs was increased to 65 in KojoExperiment3, with the confidence levels of C1= 0.99,

C2= 0.94, C3= 0.97 for each of the confidence intervals of comparisons Diff21, Diff31, and Diff41

respectively to generate interval half lengths that meet the 10% criterion (that is ( ) / ( )n y n < 0.1).

-------------------------------------------------------------------------------------Comparison Point estimate(ybar(n)) s(n) zeta CI Min CI Max |zeta/ybar(n)|-------------------------------------------------------------------------------------

Diff21 -0.408 0.012 0.037 -0.445 -0.372 0.090Diff31 -0.283 0.015 0.029 -0.312 -0.253 0.104Diff41 -0.325 0.014 0.032 -0.358 -0.293 0.099

-------------------------------------------------------------------------------------

Recall from the project goal the employee schedule and number of employee-hours from the the four

cases as shown in the following table.

Case Parameter

RG.Counter.schedule

Employee-Hours

Case 1 (Base Case) < 2, 2, 2, 2, 2 > 22

Case 2 < 2, 3, 2, 3, 2 > 26

Case 3 < 1, 3, 1, 3, 1 > 19

Case 4 < 1, 3, 2, 3, 1 > 22.5

Clearly Case 2 provides the best improvement with a reduction of 41% in the number of persons that

wait longer than five minutes. This improvement does require an extra 4 employee hours to implementthis option. Case 4 presents an interesting option since for roughly the same number of employee-hours

as in Case 1 (only an addition 0.5 employee hours is required), a decrease of 33% can be achieved. Case

3 is also interesting since the schedule represents a reduction in employee hours while still improvingcustomer service.

Conclusions

The results in the Output Analysis section shows that all schedules explored during the modelling and

simulation study improve customer service, but that each option affects the number of employee-hours

differently.

The schedule used for Case 4 is recommended since it represents no significant increase in the number

of employee-hours but does improve customer service significantly. The scheduled used in Case 2 can

also be considered since it provides the best customer service (with a significant improvement over Case4), but should be considered if the additional investment in the increased number of employee-hours is

acceptable. .


41/138

41

Annex AData ModellingThe data models used in the Kojos Kitchen project are:

4) Customer arrivals: Arrivals of customers are modelled as Poisson processes. This implies that

inter-arrival times are exponentially distributed. But arrivals are not constant since busy periods

exist during the operation of the deli. Thus arrivals are models as piecewise homogeneous

stochastic process (see section 3.1 of the textbook) where inter-arrival times are modelled withan exponential distribution whose mean is different for different periods of time. The following

table shows how the mean of the exponential distribution varies over the observation interval.

Period Exponential

Mean






5) Customer type: The type of the customer for arriving customers is 65% a sandwich customerand 35% a sushi customer.

6) Service time: The time to service a customer is modelled with a uniform distribution for both

types of customers with the following parameters.

Customer Type Minimum Parameter Maximum Parameter

Sandwich 3 minutes 5 minutes

Sushi 5 minutes 8 minutes


42/138

42


Problem Description

Problem StatementTankers of various sizes are loaded with crude oil at a port that currently has berth facilities for loading

three tankers simultaneously. Empty tankers arrive in the harbour entrance and often have to wait there

because they require assistance from a tug (only one is available) to move them into a berth where the

loading takes place. After the loading operation is complete, a tanker again requires assistance from atug to move from the berth back to the harbour entrance. The port authority is concerned about the

increasing number of complaints from tanker captains about excessive delays waiting to be serviced by

the tug. It is therefore considering the construction of a fourth berth and requires some insight into the

likely impact of such an expansion.

SUI Details

The general SUI configuration is shown inFigure 7.

Figure 7 Schematic view of the ports operation

A harbour master oversees the operation of the port and is in radio contact with the tug boat captain and

with each tanker captain. The harbour master ensures that tankers are serviced on a first-come first-

served basis by maintaining a list of tankers requiring berthing and a list of tankers ready for deberthing.

Processing of Tankers

1. An arriving tankers captain communicates his/her arrival at the harbour entrance to the harbourmaster who then adds the tankers name to the end of the list of tankers needing to be berthed.

2. Each tank

Documents

CSI4124_SYS5110_CaseStudies_Fall_2014.pdf