CSI4124 SYS5110 CaseStudies Fall 2014 PDF

School of Electrical Engineering and Computer Science
Faculty of Engineering
University of Ottawa
Modelling and Simulation

Case Studies
CSI4124/SYS5110 Foundations of Modelling
and Simulation
Gilbert Arbez
Fall 2014
Oct 7
Table of Contents
Introduction ................................................................................................................................................. 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 A Data 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

Simulation Model................................................................................................................................ 109
Experimentation and Analysis ............................................................................................................ 111
Annex A Data Modelling ................................................................................................................. 137
Introduction
This document presents a set of case studies which expands on the examples presented in the book
Modelling and Simulation: Exploring Dynamic System Behaviour1 and 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 any
differences 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 includes
the 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 of the model at a level of detail
that is both adequate for communication and comprehensive. The second sub-section consists of
the 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 model
during 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 conjunction
with this section and the Experimentation and Analysis section.
5. Experimentation and Analysis: Three sub-sections make up the Experimentation and Analysis
section. 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 A Data 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 the
textbook). 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 and
clarifications.
Modelling and Simulation: Exploring System Dyanmics, Louis G. Birta, Gilbert Arbez, 2 nd edition, 2013
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
ConfidenceInterval provides the means to produce confidence intervals and the class
WelchAverage that supports the application of a moving average to determine warm up times.
The experimentation software includes the creating of confidence intervals and applying
Welchs moving average method rather than using external analysis tools such as Excel. For
graphing (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 2
sections 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, explores
common random numbers.
5) The standard for comments in the ABCmod constructs is to insert text with italics font and
enclosed 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 uNumEmp and parameter addEmp are defined as attributes of the entity
RG.Counter, that is, RG.Counter.uNumEmp and RG.Counter.addEmp since these variables
represent properties of the RG.Counter entity.
The attribute iC.Customer.type was 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 value
provided by RVP.uCustomerType.
The initialisation of RG.Counter.uNumEmp is done in the StaffChange action rather than the
Initialise action. Given that the StaffChange action was defined to provide the value of the
input variable RG.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 the Initialise action.
Some editorial changes have been made to make clarifications and/or corrections.
5
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 to
consider multiple employee scheduling scenarios.
It demonstrates analysis of the multiple scenarios as described in section 7.4.2 of the Birta/Arbez
textbook.
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 confidence
interval half-length to point estimate.
It also introduces the use of a vector as a parameter, that is, a sequence of numbers to indicate the
number 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 and
the 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 using
common random numbers.
With respect to the Port Project example (version 1) that appears in the textbook, the following
changes were made:
The Initialisation action was removed from the high-level conceptual model behavioural
diagram. 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 implies
that 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 that
numOccBerths = RG.Berths.n; the variable numOccBerths is removed by this change.
The trajectory sequence TRJ[tankerWait] is changed to TRJ[iC.Tanker.totalWait]. Given that
tankerWait = 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.

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 Loading
activity) 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 results
from 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 uStorm was added to the model. Thus the attribute stopped was
removed from the R.Tug entity and the attribute anchored used in its place. The use of the
uStorm as an input variable was a better representation of an exogenous input variable rather
than the use of the R.Tug.anchored attribute to represent the presence of a storm.
3. When the MoveToBerths is interrupted by an arriving tanker, the MoveToHarbour activity is
started. Thus the ReturnToHarbour sequel activity is not required. An additional attribute,
returnToHarbour, was added to the R.Tug entity and some additional logic was added to both
MoveToBerths and MoveToHarbour to deal with this case.
Kojos Kitchen
Problem Description
Problem Statement
Kojos Kitchen is one of the fast food outlets in the food court of a shopping mall. Kojos manager is very happy
with 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
Su
Sw
Sw
Su
Sw
Sandwich and Sushi Counter
Su
Sw
Su
Sandwich
Customer
Sushi
Customer
Employee
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:30
am and 1:30 pm, and the other between 5:00 pm and 7:00 pm. Currently two employees work at the counter
throughout the day preparing sandwiches and sushi products for the customers.
Project Goal
The 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). The
performance 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 are minutes.
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.
ABCmod Conceptual Model

High Level Conceptual Model
Simplifications
We assume there are only two types of customer one type purchases only sandwiches and the other
type purchases only sushi products.
Structural View
RG.Counter
Q.CustLine
Legend
iC.Customer
Figure 2 Kojos 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 the
sushi customer. Customers are distinguished using the Customer attribute uType.
Behavioural View
Arrivals
Serving
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.
10
Input
Variable
Name
uC
Exogenous Input (Entity Stream)

Domain Sequence
Description
This input entity stream
represents the arriving
customers
Variable Name
RG.Counter.uNumEmp
Variable Name
uSrvTm
iC.Customer.uType
RVP.DuC()
1 customer arrives at each arrival.
Endogenous Input (independent)

Description Domain Sequence
This 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 of
busy period)
11
Range Sequence
< 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)

Description
Service time of a customer.
Defines the type of an arriving customer.
Range Sequence
Value(s)
RVP.uSrvTm()
RVP.uCustomerType()
Detailed Conceptual Model

Structural Components
Parameters
Description
Name
RG.Counter.addEmp
Number of additional employees serving at the

counter during the busy periods.
Value
0 (for the base case) or
1 (for the alternate scenario).
Consumer Class: Customer

This entity structure represents the customers who purchase items at Kojo's Kitchen.
Attributes
Description
startWaitTime
uType
Time stamp that holds the value of time when the customer enters the customer line.
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: Counter

This resource group represents the counter where customers receive service.
Attributes
Description
list
n
uNumEmp
The group of the Customer entities that are being served.

Number of entries in list (necessarily n uNumEmp).
Input variable that defines the number of employees at the counter available to
service customers.
Parameter that defines the number of additional employees serving at the counter
during the busy periods.
addEmp
Queue Unary: CustLine

The queue of customers waiting for service at the counter.
Attributes
Description
list
List of the customers entities waiting in line for service.

Discipline: FIFO.
The number of iC.Customer entities in List.
Behavioural components
Time units: minutes
Observation interval: t 0 = 0, Implicit Stop Condition: (t > 660 minutes (11 hour business day) AND
RG.Counter.n = 0).
B
Action: Initialise
TimeSequence
Event SCS
<0>
RG.Counter.n 0
Q.CustLine.n 0
SSOV.numServed 0
SSOV.numLongWait 0
Output
OUTPUTS
Simple Scalar Output Variables (SSOV's)
Name
Description
numServed
numLongWait
propLongWait
Number of customers served.

Number of customers that waited longer than 5 minutes.
numLongWait/numServed.
12
Input Constructs
Name
Random Variate Procedures

Description
RVP.DuC()
Provides the values of the arrival

times of customers. No arrivals
occur after closing (i.e. for t 660).
RVP.uCustomerType()
Provides the type of the arriving

customer. Returns either W
(sandwich customer) or U (sushi
customer).
Provides a value for the service time
of customer according to the value
of type.
RVP.uSrvTm(type)
Data Model
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.)
Proportion of sandwich customers:
PROPW=65%
Proportion of sushi customers:
PROPU=35%
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: Arrivals
The 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: StaffChange
Manages the value of the input variable RG.Counter.uNumEmp, that is,
schedules additional employee during busy times for the alternate case.
TimeSequence <0, 90, 210, 420, 540 >
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.addEmp
ENDIF
13
Behavioural Constructs
Activity: Serving
Service 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 are
presented on a single line as follows:
Clock: xxxxxxx, Q.CustLine.n: xx, RG.Counter.n: xx, RG.Counter.uNumEmp: xx
where the xxxs are replaced with the current value of the clock and designated attribute values.
14
Simulation Model
Design of Simulation Model and Program
The simulation model is implemented in the class KojoKitchen (an extension of the ABSmod/J class
AOSimulation model) 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 are
placed 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 KojoKitchen class.
ABCmod
Construct
iC.Customer
Entity Structures
Java Class
Customer
Object References
Notes: The enumerated data type Type is

defined to restrict the values of the uType
attribute to W and U.
Typically by the reference

variable icCustomer in the
various methods that
manipulate Customer objects.
RG.Counter
Counter
KojoKitchen.rgCounter
Q.CustLine
Notes:
The list of Customer objects are
maintained in a HashSet object. Thus
the standard ABCmod procedures
SP.InsertGrp and SP.RemoveGrp are
implemented as methods in the
Counter class.
The attribute n is note implemented as
an instance variable since it is
maintained by the HashSet object.
Thus the method getN provides the
means to obtain the value of the
attribute.
KojoKitchen.qCustLine
ArrayList (standard Java Class)
Notes
The various methods available in the
ArrayList class 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
ArrayList object (adjusted
automatically when ArrayList
methods are called). The method
qCustLine.size() provides the value of
the Q.CustLine.n attribute.
15
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 kkSimModel provides public access to the following:
The constructor KojoKitchen to allow creation and initialisation of a KojoKitchen object,
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 employee
Clock: 0.0, Q.CustLine.n: 0, RG.Counter.n: 0, input RG.Counter.uNumEmp: 0
------------SBL---------TimeStamp:0.0 Activity/Action: kkSimModel.StaffChange
TimeStamp:2.3590927534467654 Activity/Action: kkSimModel.Arrivals
TimeStamp: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.Arrivals
TimeStamp:90.0 Activity/Action: kkSimModel.StaffChange
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.
The continuation of the log shows that an arriving customer ends up at the conter. and start of the model
execution.
------------SBL---------Note the Arrivals action place the
Customer entity in Q.CustLine, but
TimeStamp:7.3176282053544295 Activity/Action: kkSimModel.Serving
the starting event of the Serving
activity moved the entity to the
---------------------Counter group.
16
The continuation of the log shows that another arriving customer will also move through the queue to
the counter at the same time.
Two instances of the Serving
activity exist one serving
each of the Customer entities
---------------------in the group.
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 will
make place at the counter for this newly arrived customer.
------------SBL---------TimeStamp:7.3176282053544295 Activity/Action: kkSimModel.Serving
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 allowed
the condition to start another Serving activity which moved the customer from the queue to the counter.
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.
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 the
busy period.
17
The log shows the customer line becoming quite long.

The log shows the end of the simulation run where no customers exist at closing time.
------------SBL---------TimeStamp:720.0 Stop Notification
Last line show the value of the output variable
---------------------propLongWait, i.e. in this run 50% of customers
1, 0.5054347826086957
longer than five minutes.
18
waiting
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.

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):
19
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 log
does show that the counter never exceeds 3 after the Serving activity is completed.
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
---------------------1, 0.059782608695652176
20
RG.Counter.uNumEmp: 2
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 and
validation, reported in the previous section.
2) KojoExperiment2: generates a table equivalent to Table 7.2 of the text book showing simulation
values 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.060
2
0.457
0.171
3
0.731
0.118
4
0.665
0.294
5
0.634
0.230
6
0.517
0.062
7
0.629
0.126
8
0.701
0.109
9
0.463
0.017
10
0.514
0.223
11
0.570
0.161
12
0.519
0.212
13
0.410
0.116
14
0.609
0.180
15
0.151
0.014
16
0.686
0.237
17
0.572
0.072
18
0.599
0.204
19
0.455
0.132
20
0.659
0.234
-----------------------PE
0.552
0.148
S(n)
0.128
0.077
zeta
0.050
0.030
CI Min
0.503
0.119
CI Max
0.602
0.178
------------------------
The 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.
21
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 book
for 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.090
30
0.558
0.112
0.035
0.523
0.593
0.062
40
0.565
0.112
0.030
0.535
0.595
0.053
60
0.582
0.107
0.023
0.559
0.605
0.040
80
0.578
0.108
0.020
0.558
0.598
0.035
100
0.581
0.108
0.018
0.564
0.599
0.031
1000
0.587
0.110
0.006
0.581
0.593
0.010
10000
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.200
30
0.151
0.086
0.027
0.124
0.177
0.177
40
0.162
0.108
0.029
0.133
0.191
0.178
60
0.173
0.116
0.025
0.148
0.198
0.144
80
0.166
0.111
0.021
0.145
0.186
0.125
100
0.167
0.112
0.019
0.149
0.186
0.111
1000
0.174
0.121
0.006
0.168
0.180
0.036
10000
0.174
0.119
0.002
0.172
0.176
0.011
------------------------------------------------------------------
22
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.060
2
0.457
0.171
3
0.731
0.118
4
0.665
0.294
5
0.634
0.230
6
0.517
0.062
7
0.629
0.126
8
0.701
0.109
9
0.463
0.017
10
0.514
0.223
11
0.570
0.161
12
0.519
0.212
13
0.410
0.116
14
0.609
0.180
15
0.151
0.014
16
0.686
0.237
17
0.572
0.072
18
0.599
0.204
19
0.455
0.132
20
0.659
0.234
21
0.671
0.335
22
0.620
0.245
23
0.565
0.012
24
0.533
0.038
25
0.431
0.111
26
0.578
0.243
27
0.522
0.225
28
0.610
0.181
29
0.654
0.043
30
0.514
0.115
-----------------------PE
0.558
0.151
S(n)
0.112
0.086
zeta
0.035
0.027
CI Min
0.523
0.124
CI 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 is
recommended 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 a
study would involve revising the project goal would involve only minor modifications to the model from
this study.
23
Annex A Data Modelling

The 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 with
an 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
13h30 to 17h00
9 minutes
19h00 to 21h00
6 minutes
2) Customer type: The type of the customer for arriving customers is 65% a sandwich customer
and 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
24
Kojos Kitchen (Version 2)

Problem Description
Problem Statement
Kojos Kitchen is one of the fast food outlets in the food court of a shopping mall. Kojos manager is very happy
with 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
Su
Sw
Sw
Su
Sw
Sandwich and Sushi Counter
Su
Sw
Su
Sandwich
Customer
Sushi
Customer
Employee
Figure 4 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:30
am and 1:30 pm, and the other between 5:00 pm and 7:00 pm. Currently two employees work at the counter
throughout the day preparing sandwiches and sushi products for the customers.
25
Project Goal
The 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). The
performance 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.
Time units are minutes.

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
Case 1 (Base Case)
Case 2
Case 3
Case 4
Parameter
RG.Counter.schedule
< 2, 2, 2, 2, 2 >
< 2, 3, 2, 3, 2 >
< 1, 3, 1, 3, 1 >
< 1, 3, 2, 3, 1 >
Person-Hours
22
26
19
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.
The following sequence gives the number of hours for each shift: {1.5, 2, 3.5, 2, 2} for a total of 11 hours.
26

Simplifications
We assume there are only two types of customer one type purchases only sandwiches and the other
type purchases only sushi products.
Structural View
RG.Counter
Q.CustLine
Legend
iC.Customer
Figure 5 Kojos 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 the
sushi customer. Customers are distinguished using the Customer attribute uType.
Behavioural View
Arrivals
Serving
Figure 6 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.
27
Input
Description
Domain Sequence
Variable
Name
uC

customers
Variable Name
RG.Counter.uNumEm
p
Variable Name
uSrvTm
iC.Customer.uType
RVP.DuC()
1 customer arrives at each

arrival.
Endogenous Input (independent)

Description
Domain Sequence
This input
variable
represents the
number of
employees at the
counter serving
customers.
Range Sequence
< 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)
Range Sequence
RG.Counter.schedule
Endogenous Input (Semi-independent)

Description
Value(s)
Service time of a customer.
Defines the type of an arriving
customer.
28
RVP.uSrvTm()
RVP.uCustomerType()

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

sequence of number of employees for each of 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, that is the range for
the domain sequence <0, 90, 210, 420, 540>.
Value
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: Customer

This entity structure represents the customers who purchase items at Kojo's Kitchen.
Attributes
Description
startWaitTime
uType
Time stamp that holds the value of time when the customer enters the customer line.
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: Counter

This resource group represents the counter where customers receive service.
Attributes
Description
list
n
uNumEmp
The group of the Customer entities that are being served.

Number of entries in List (necessarily n RG.Counter.empNum).
Input variable that defines the number of employees at the counter available to
service customers.
Parameter that defines the employee schedule.
schedule
Queue Unary: CustLine

The queue of customers waiting for service at the counter.
Attributes
Description
list
List of the customers entities waiting in line for service.

Discipline: FIFO.
The number of iC.Customer entities in List.
Time units: minutes
Observation interval: t 0 = 0, Implicit Stop Condition: (t > 660 minutes (11 hour business day) AND
RG.Counter.n = 0).
B
Action: Initialise
TimeSequence
Event SCS
<0>
RG.Counter.n 0
Q.CustLine.n 0
SSOV.numServed 0
SSOV.numLongWait 0
29
Output
OUTPUTS
Simple Scalar Output Variables (SSOV's)
Name
Description
numServed
numLongWait
propLongWait
Number of customers served.

Number of customers that waited longer than 5 minutes.
numLongWait/numServed.
Input Constructs
Name

Description
RVP.DuC()

times of customers. No arrivals
occur after closing (t = 660).
RVP.uCustomerType()
Provides the type of the arriving

customer. Returns either W
(sandwich customer) or U (sushi
customer).
Provides a value for the service time
of customer according to the value
of type.
RVP.uSrvTm(type)
Data Model
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.)
Proportion of sandwich customers:
PROPW=65%
Proportion of sushi customers:
PROPU=35%
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: Arrivals
The 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: StaffChange
Manages the value of the input variable RG.Counter.uNumEmp, that is,
schedules additional employee during busy times for the alternate case.
TimeSequence <0, 90, 210, 420, 540 >
Event SCS
IF(t=0) THEN
RG.Counter.uNumEmp RG.Counter.schedule[0]
ELSE IF(t=90) THEN
ELSE IF(t=210) THEN
ELSE IF(t=420) THEN
ELSE IF(t=540) THEN
ENDIF
30
Activity: Serving
Service 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)

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 the xxxs are replaced with current value of the clock and designated attribute values.
31
Simulation Model
The simulation model is implemented in the class KojoKitchen (an extension of the ABSmod/J class
ABCmod conceptual model. All Java classes that make up the Java Kojo Kitchen simulation model are
placed in the Java package kkSimModel.
Entity Structures
Java Class
ABCmod
Construct
iC.Customer
RG.Counter
Q.CustLine
Customer
Notes: The enumerated data type Type is defined
to restrict the values of the uType attribute to W
and U.
Counter
Notes:
The list of Customer objects are maintained
in a HashSet object. Thus the standard
ABCmod procedures SP.InsertGrp and
SP.RemoveGrp are implemented as methods in
the Counter class.
The attribute n is note implemented as an
instance variable since it is maintained by the
HashSet object. Thus the method getN
provides the means to obtain the value of the
attribute.
Notes
ArrayList class provide the implementation
of the various ABCmod procedures, such as
ArrayList object (adjusted automatically
when ArrayList methods are called). The
method qCustLine.size() provides the value of
Object References
Typically by the reference variable
icCustomer in the various
methods that manipulate Customer
objects.
KojoKitchen.rgCounter
KojoKitchen.qCustLine
Actions/Activities
ABCmod Constructs
Java Classes
Arrivals
StaffChange
Serving
Arrivals
StaffChange
Serving
32
Other classes that make up the Kojos Kitchen ABSmod/J simulation model include:
Output (referenced by KojoKitchen.output): Contains the SSOVs.
RVPs.
various RVPs.
The package kkSimModel provides public access to the following:
The constructor KojoKitchen to allow creation and initialisation of a KojoKitchen object,
The method getPropLongWait() to allow access the value of the output variable propLongwait.
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 employee
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.
The continuation of the log shows that an arriving customer ends up at the conter. and start of the model
execution.
------------SBL---------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.
The continuation of the log shows that another arriving customer will also move through the queue to
the counter at the same time.
Two instances of the Serving
activity exist one serving
each of the Customer entities
in the group.
----------------------
33
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 will
make place at the counter for this newly arrived customer.
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 allowed
the condition to start another Serving activity which moved the customer from the queue to the counter.
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.
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 the
busy period.
34
The log shows the customer line becoming quite long.

Last line show the value of the output variable
---------------------propLongWait, i.e. in this run 50% of customers
1, 0.5054347826086957
longer than five minutes.
35
waiting
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.

The log shows that the employee scheduled is followed:



36
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 log
does show that the counter never exceeds 2 after the Serving activity is completed.
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.
---------------------1, 0.059782608695652176
37





For the test simulation run 29% of customers waited longer than 5 minutes.
---------------------Terminated 1, 0.29347826086956524





38
For the test simulation run 24% of customers waited longer than 5 minutes.
---------------------Terminated 1, 0.24456521739130435
Note that single runs for each case is not sufficient to draw conclusions.

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 ( (1 0.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.107
Diff31
-0.277
0.014
0.048
-0.325
-0.229
0.173
Diff41
-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 Case
3 and still maintain an overall confidence interval according to the following equation derived
from Bonferonnis inequality.
K
C (1 K ) Ck
k 1
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.
The 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.
39
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.090
Diff31
-0.283
0.015
0.029
-0.312
-0.253
0.104
Diff41
-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
Case 1 (Base Case)
Case 2
Case 3
Case 4
Parameter
RG.Counter.schedule
< 2, 2, 2, 2, 2 >
< 2, 3, 2, 3, 2 >
< 1, 3, 1, 3, 1 >
< 1, 3, 2, 3, 1 >
Employee-Hours
22
26
19
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 implement
this 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 improving
customer 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 Case
4), but should be considered if the additional investment in the increased number of employee-hours is
acceptable. .
40

The 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 with
an 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
13h30 to 17h00
9 minutes
19h00 to 21h00
6 minutes
5) Customer type: The type of the customer for arriving customers is 65% a sandwich customer
and 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
41

Problem Description
Problem Statement
Tankers 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 a
tug 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 in Figure 7.
Harbour
Berth 1
Berth 2
Berth 3
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 firstserved 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 harbour
master who then adds the tankers name to the end of the list of tankers needing to be berthed.
2. Each tanker must wait until all previously arrived tankers have been berthed by the tug. When the
tug next becomes available for berthing, it is assigned, by the harbour master, to berth the tanker at
the top of the berthing list.
3. The loading procedure starts as soon as the berthing operation is complete at which time the tug is
released to carry out its next task.
4. When the loading of a tanker is completed, the tankers captain contacts the harbour master to
request the services of the tug to move it back to the harbour entrance (the deberthing operation).
The harbour master adds the tankers name to the end of a second list of tankers; namely, those
waiting for deberthing.
5. Each loaded tanker must wait until all previously loaded tankers have been deberthed (i.e., those
that precede it on the deberthing list) before it is allocated the tug by the harbour master. The tug
moves the tanker from the berth back to the harbour entrance and the tanker leaves the port. The tug
proceeds to its next task.
42
Tug Operation
When the tug finishes a berthing operation, the harbour master will request the tug to deberth the tanker
at the top of the deberthing list. However, if the deberthing list is empty but the berthing list is not empty
and a berth is available, then the tug is requested by the harbour master to travel to the harbour entrance
and begin berthing the tanker at the top of the berthing list. Otherwise, the tug remains idle in the berth
area.
When the tug finishes a deberthing operation and the berthing list is not empty (i.e., there are waiting
tankers in the harbour), the harbour master assigns the tanker at the top of the berthing list to the tug for
a berthing operation. If the list is empty but there is at least one tanker in the berths the tug begins the
journey back to the berth area without any tanker in tow (i.e., empty).
If, at the end of a deberthing operation, the berthing list is empty and there are no occupied berths,
the tug remains idle at the harbour entrance waiting for the arrival of a tanker.
Because the port is in a geographical area where storms commonly occur, there is a defined
procedure that the tug must follow in order to minimize storm damage. Specifically, when a storm
occurs, both the tug and any tanker that is being towed batten down hatches and drop anchor. When the
storm is over, the tug resumes the operation that was underway before the storm occurred
43
Project Goals
With respect to the port authoritys interest on the impact of the expansion, the goal of the project is to
gain knowledge about how increasing the number of berths from three to four will reduce the waiting
time of tankers and how the usage of the berths will change.
Parameters
RG.Berths.numBerths: The number of berths for loading tankers. The two values of interest are
three and four.
Experimentation
Study: Steady state study.
Time units are hours
Cannot be predetermined because a steady state study is required
Base Case: case where RG.Berths.numBerths = 3.
Alternate Case: case where RG.Berths.numBerths = 4.
Output
avgWaitTime: This output variable provides the average waiting time of tankers. Its reduction
indicates a reduction of turn-around time for tankers. Waiting time for a tanker includes any time
interval during which the tanker is waiting to be serviced by the tug; i.e., the periods when the
tanker is waiting to be towed to berths or waiting to be towed back to the harbour entrance. In the
ideal case, these subtasks would be initiated immediately and waiting time would be zero.
avgOccBerths: This output variable provides the average number of berths that are occupied.
This value is a measure of the usage of the berths.
44

Assumptions
The harbour master recommends the assumption that the time required for the tug to travel from the
harbour to the berths or from the berths to the harbour with no tanker in tow, is a constant (hence
data modelling is not required here).
The harbour master recommends the assumption that the times required for berthing a tanker and for
deberthing a tanker are both constants that are independent of tanker size (hence data modelling is
not required here).
Simplifications
The occurrence of storm conditions is not considered.

The tankers fall into three size categories: SMALL, MEDIUM, and LARGE.
It is not necessary to model the harbour master, because his/ her directives are captured in the
behaviour constructs of the model.
The berths are not actually modelled as individual entities but rather as a resource group (namely as
an entity that has two roles, that of a resource that can simultaneously service several tanker
entities). The size of this resource group can be either 3 or 4.
Structural View
The structural diagram shows the entities used to represent the tankers, tug, berths and lists used by the
harbour master.
Q.DeberthingList
R.Tug
RG.Berths
Q.BerthingList
Legend
iC.Tanker
Figure 8 Port structural diagram
Entity Categories
BerthingList: A single queue entity that represents the berthing list of empty tankers waiting to
be berthed by the tug.
DeberthingList: A single queue entity that represents the list of tankers loaded with oil ready for
deberthing.
Tug: A single resource entity that berths and deberths the tankers as it travels between the
harbour and berths.
Berths: A single resource group entity that represents the set of berths used for loading the
tankers with oil. The attribute numBerths of this entity category is a parameter.
Tanker: A consumer entity category representing the tankers that arrive empty at the port and are
then loaded with oil. Because of the transient existence of tankers within the model this entity
category has scope=Class.
45
Notes:
Except for the Tanker entity category, all other categories have scope = Unary.
Any particular Tanker entity instance can necessarily be referenced simultaneously by both the
RG.Berths and the Q.DeberthingList entities.
Behavioural View
TankerArrival
Berthing
Loading
MoveToHarbour
Deberthing
Berthing
MoveToBerths
Deberthing
(a) Tanker Life-cycle diagram
(b) Tug Life-cycle diagram
Figure 9 Port Behaviour Diagram
Actions:
TankerArrival: This scheduled action generates the input entity stream of tankers. With each
arrival, tanker attribute values are assigned and the tanker instance is placed into the
Q.BerthingList entity.
Activities:
Berthing: This activity represents the Tug entity towing an empty Tanker entity from the
harbour to the berths.
Deberthing: This activity represents the Tug entity towing a loaded Tanker entity from the
berths to the harbour (at which point the Tanker entity leaves the model).
MoveToBerths: This activity represents the Tug entity moving to the berths area with no Tanker
entity in tow.
MoveToHarbour: This activity represents the Tug entity moving to the harbour with no Tanker
entity in tow.
Loading: This activity represents the loading of a Tanker. This is a sequel activity and is
initiated at the completion of the Deberthing activity.
46
Input
Description
Domain Sequence
Variable
Name
uTnkr(t)

RVP.DuTnkr()
represents the arriving tankers.
Endogenous Input (Semi-Independent)
Variable Name
Description
iC.Tanker.uSize
uLoadTime
The size of the arriving tanker.

Loading time for a tanker. The loading
time depends on the size of the tanker.
Range Sequence
N/A; 1 tanker arrives at
each arrival time.
Value(s)
RVP.uTankerSize()
RVP.uLoadTime(size)

Name
BERTH_TIME
DEBERTH_TIME
EMPTY_TIME
Name
RG.Berths.numBerths
Constants
Description
Time required for the berthing operation.
Time required for the deberthing operation.
Harbour to berth (and berth to harbour) travel time for
tug when travelling without a tanker in tow.
Parameters
Description
Number of operational berths at the port.
Value
1 hour
2 hours
0.25
hour
Values
3 and 4
Consumer Class: Tanker

This consumer entity structure represents the tankers that arrive in the port, load and leave.
Attributes
uSize
startWait
totalWait
Description
This input variable represents the size of the tanker (value is one of SMALL,
MEDIUM, LARGE) as assigned via RVP.uTankerSize().
A timestamp used to determine waiting times.
Accumulated time waiting for a tanker instance.
Resource Unary: Tug

This resource entity structure represents the tugboat that is needed to berth tankers that arrive in
the harbour and to deberth tankers that have finished loading.
Attributes
status
Description
Indicates the status of the tug as specified by one of the following values:
BUSY travelling with or without a tanker in tow,
PAUSE_H stopped in the harbour ready for the next task,
PAUSE_B stopped in the berth area ready for the next task.
The status attribute is initialised to PAUSE_B, that is, the Tug starts at the Berths.
47
Resource Group Unary: Berths

This resource group entity structure represents the collection of berths used for loading tankers.
Attributes
list
n
numBerths
Description
A list of the Tanker entity instances that occupy berths .
The number of entries in List (maximum value is numBerths).
The number of available berths (this is a parameter).
Queue Unary: BerthingList

This queue entity structure represents the harbour master's berthing list of tankers in the harbour
waiting to be assisted into a berth by the tug.
Attributes
list
n
Description
A list of the Tanker entity instances in the harbour masters berthing list (FIFO).
The number of entries in List.
Queue Unary: DeberthingList

This queue entity structure represents the harbour master's list of tankers that have completed
loading and are waiting in a berth for deberthing assistance from the tug (FIFO).
Attributes
list
n
Description
The list of Tanker entity instances in the harbour masters deberthing list.
Discipline: FIFO.
48
Time units: Hours
Observation interval: Steady state study starts at 0 and the right hand end of the observation interval is to be determined
during experimentation.
Action: Initialise
TimeSequence
Event SCS
<0>
R.Tug.status PAUSE_B
RG.Berths.n 0
Q.BerthingList.n 0
Q.DeberthingList.n 0
Output
Name
TRJ[RG.Berths.n]
Name
PHI[iC.Tanker.totalWait]
Name
avgOccBerths
avgWaitTime
OUTPUTS
Trajectory Sequences
Description
This trajectory sequence records the values of the attribute RG.Berths.n which
represents the number of occupied berths.
Sample Sequences
Description
Each value in PHI[iC.Tanker.totalWait] is of the form (tk, yk) where yk is the value of
for some tanker instance and tk is the time when the tug begins deberthing that tanker.
Derived Scalar Output Variables (DSOV's)

Description
Output Sequence
Name
Average number of occupied berths.
Average time that the tankers spend
waiting for the tug.
TRJ[RG.Berths.n]
Operation
AVG
AVG
User Defined Procedures

None required.
Input Constructs
Name

Description
Data Model
RVP.uLoadTime(Size)
The returned value is the loading time

for a tanker entity instance. It is
assigned according to the tanker's size;
i.e., SMALL, MEDIUM or LARGE).
Each of the data models is UNIFORM(Min, Max)

where min and max take on the following values (in
hours) according to the tanker size.
Size
Min
Max
SMALL SMIN=8 SMAX=10
MEDIUM MMIN=10 MMAX=14
LARGE LMIN=15 LMAX=12
RVP.uTankerSize()
Returns the "size" of an arriving

tanker entity instance; value is one
of SMALL, MEDIUM or LARGE.
The percentage of SMALL, MEDIUM and

LARGE arriving tankers is given in the
following table.
Size
Percent
SMALL
PERSML=25%
MEDIUM PERMED=25%
LARGE
PERLRG= 50%
RVP.DuTnkr()

times of tanker instances.
49
First arrival at t=0 and interarrival given by:

EXP(AVGARR) where AVGARR = 8 hours.
Action: TankerArrivals
Provides the input entity stream of arriving tanker entity instances; includes the
associated derive operation and attribute value assignment.
TimeSequence RVP.DuTnkr()
Event SCS
iC.Tanker SP.Derive(Tanker)
iC.Tanker.uSize RVP.uTankerSize()
iC.Tanker.startWait t
iC.Tanker.totalWait 0
SP.InsertQue(Q.BerthingList, iC.Tanker)
Activity: Deberthing
This activity represents the Tug entity towing a loaded Tanker entity from the
Precondition (R.Tug.status = PAUSE_B) AND (Q.DeberthingList.n 0)
Event SCS
iC.Tanker SP.RemoveQue(Q.DeberthingList)
(Update totalWait )
iC.Tanker.totalWait + (t - iC.Tanker.startWait)
(Remove Tanker from Berths)
SP.RemoveGrp(RG.Berths, iC.Tanker)
R.Tug.status BUSY
Duration
DEBERTH_TIME
Event SCS
R.Tug.status PAUSE_H
(Update sample sequence)
SP.Put(PHI[tankerWait], iC.Tanker.totalWait)
SP.Leave(iC.Tanker)
Activity: Berthing
This activity represents the Tug entity towing an empty tanker entity from the
harbour to the berths. Note that the availability of an empty berth is implicit in the
fact that the tug is located in the harbour.
Precondition (R.Tug.status = PAUSE_H) AND (Q.BerthingList.n > 0)
Event SCS
R.Tug.status BUSY
iC.Tanker SP.RemoveQue(Q.BerthingList)
iC.Tanker.totalWait + (t iC.Tanker.startWait)
Duration
BERTH_TIME
Event SCS
SP.InsertGrp(RG.Berths, iC.Tanker)
SP.Start(Loading, iC.Tanker)
Activity: MoveToHarbour
This activity represents the Tug entity moving to the harbour area with no Tanker
entity in tow.
Precondition (R.Tug.status = PAUSE_B) AND (Q.DeberthingList.n = 0) AND
(Q.BerthingList.n > 0) AND
(RG.Berths.n < RG.Berths.numBerths)
Event SCS
R.Tug.status BUSY
Duration
EMPTY_TIME
Event SCS
50
Activity: MoveToBerths
This activity represents the Tug entity moving to the berths area with no Tanker
entity in tow. .
Precondition (R.Tug.status = PAUSE_H) AND (Q.BerthingList.n = 0) AND
(RG.Berths.n > 0)
Event SCS
R.Tug.status BUSY
Duration
EMPTY_TIME
Event SCS
Activity: Loading
This activity represents the loading of a Tanker. This is a sequel activity and is
initiated at the completion of the Deberthing activity
Causal
(iC.Tanker)
Event SCS
Duration
RVP.uLoadTime(iC.Tanker.uSize)
Event SCS
SP.InsertQue(Q.DeberthingList, iC.Tanker)

Trace Logging
The state of the simulation model is monitored by tracking the status of the tug (R.Tug.status) and the
number of tanker referenced in the two queues (Q
.BerthingList, Q.DeberthingList) and in the
resource group (RG.Berths). These values are presented on a single line as follows:
Clock: xxxxxxx R.Tug.status: xx Q.BerthingList.n: xx Q.DeberthingList.n: xx RG.Berths.n: xx
where the xxxs are replace with current values of the clock and attributes accordingly.
51
Simulation Model
The simulation model is implemented in the class PortVer1 (an extension of the ABSmod/J class
ABCmod conceptual model. All Java classes that make up the Java Port (Version 1) simulation model
are placed in the Java package portModelV1.
ABCmod
Construct
iC.Tanker
RG.Berths
Q.BerthingList
Q.DeberthingList
Entity Structures
Java Class
Tanker
Notes: The enumerated data type SizeTypes is
defined to restrict the values of the uSize attribute
to SMALL, MEDIUM and LARGE.
Berths
Notes:
The list of Tanker objects are maintained in a
HashSet object. Thus the standard ABCmod
procedures SP.InsertGrp and SP.RemoveGrp
are implemented as methods in the Berths
class.
attribute.
Notes
Object References
icTanker in the various methods
that manipulate Tanker objects.
PortVer1.rgBerths
PortVer1.qBerthingList
PortVer1.qDeberthingList
Actions/Activities
ABCmod Constructs
TankerArrivals
Deberthing
Berthing
MoveToHarbour
MoveToBerths
Loading
Java Classes
TankerArrivals
Deberthing
Berthing
MoveToHarbour
MoveToBerths
Loading
52
Other classes that make up the Port (Version 1) ABSmod/J simulation model include:
Constants: Contains the models constants.
Output (referenced by PortVer1.output): Contains the two output sequences, trajectory sequence
TRJ[RG.Berths.n] implemented as the OutputSequence object refereced by trjRGBethsN and the
sample sequence PHI[tankerWait] implemented as an OutputSequence object referenced by
phiTankerWait. The method updateSquences in this class provides the means to update the
trajectory sequence and is called by the method eventOccured (PortVer1 class).
RVPs (referenced by PortVer1.rvp): Contains the Java methods used to implement the CM RVPs.
various RVPs.
The package portModelV1 provides public access to the following:
The constructor PortVer1 to allow creation and initialisation of a PortVer1 object,
The methods getAvgOccBerths() and getAvgWaitTime() to allow access the value of the output
variables avgOccBerths and avgWaitTime respectively. To allow experimentation for
determining and using warmup times, observation interval time parameters were added to the
method getAvgOccBerths() and the clearTRJRGBerthsN methods clearPHIiCTankerTotalWait
and allow the clearing of output from the output sequences.
experimentation.
53

The Java class PortV1Exp1 contains the experimentation software to generate the logs of 2 simulation
runs, one for each case. The following presents parts of the log that demonstrates the proper and
expected behaviour of the model.
Case 1 (RG.Berths.numBerths = 3)
The start of the log shows initialisation of the modelling and behaviour when tankers arrive:
Since initially the tug is at the berths, the MoveToHarbor activity is initiated to move the tug to the
harbour when a tanker arrives.
Number of berths = 3
Clock: 0.0 R.Tug.status: PAUSE_B Q.BerthingList.n: 0 Q.DeberthingList.n: 0 G.Berths.n: 0
------------SBL---------TimeStamp:0.0 Activity/Action: portModelV1.TankerArrivals
---------------------Clock: 0.0 R.Tug.status: BUSY Q.BerthingList.n: 1 Q.DeberthingList.n: 0 G.Berths.n: 0
------------SBL---------TimeStamp:0.25 Activity/Action: portModelV1.MoveToHarbour
TimeStamp:0.4337228175144171 Activity/Action: portModelV1.TankerArrivals
Once the MoveToHarbour activity completes, then a Berthing activity is initiated.
---------------------Clock: 0.25 R.Tug.status: BUSY Q.BerthingList.n: 0 Q.DeberthingList.n: 0 RG.Berths.n: 0

TimeStamp:2.25 Activity/Action: portModelV1.Berthing
Arriving tankers are placed on the berthing list while the tug is berthing the first tanker.

------------SBL---------TimeStamp:2.25 Activity/Action: portModelV1.Berthing
At the end of the Berthing activity, the tanker is placed in RG.Berths and a Loading activity is
initiated. Note also that the MoveToHarbour activity is initiated to move the tug back to the harbour
to get a waiting tanker.

TimeStamp:14.43629150185734 Activity/Action: portModelV1.Loading
Reviewing the log showed the other expected behaviour of the port:
The following shows 2 tankers placed in the berths with 2 corresponding Loading activities.
---------------------Clock: 4.5 R.Tug.status: PAUSE_B Q.BerthingList.n: 0 Q.DeberthingList.n: 0 RG.Berths.n: 2
54
The following shows 3 tankers placed in the berths with 3 corresponding Loading activities. Note
that the Tug remains at the berths in this situation.

------------SBL---------TimeStamp:14.079704659525305 Activity/Action: portModelV1.Loading
When a Loading activity terminates, the Deberthing activity is initiated, thus removing it from
RG.Berths.

TimeStamp:15.079704659525305 Activity/Action: portModelV1.Deberthing
----------------------
When the RG.Berths is full, the tug remains in at the berths (i.e. no MoveToHarbour activity is
initiated).

----------------------
55
When Loading is completed, the Deberthing activity is initiated. When the Deberthing activity is
complete, a Berthing activity is initiated to move the waiting tanker to the freed berths in RG.Berths.

------------SBL---------TimeStamp:55.29060596784392 Activity/Action: portModelV1.Deberthing
------------------------------------------Clock: 57.29060596784392 R.Tug.status: PAUSE_B Q.BerthingList.n: 0 Q.DeberthingList.n: 0 RG.Berths.n: 3
----------------------
The log showed that most of the time, the BerthingList was not very long. There some situations
where a number of tankers were waiting in the harbour.

56
During busy periods, the tug is involved in alternating Deberthing and Berthing activities..
---------------------Clock: 183.64477761925284 R.Tug.status: BUSY Q.BerthingList.n: 3 Q.DeberthingList.n:

----------------------
0 RG.Berths.n: 2
1 RG.Berths.n: 2
1 RG.Berths.n: 2
2 RG.Berths.n: 2
2 RG.Berths.n: 2
1 RG.Berths.n: 2
The stop notification terminates the simulation run (note the state of the model at the end of the run).
For this run, the output values were reported as 1.72 as the average size of RG.Berths and an average
waiting time of 5.4 hours.
---------------------Simulation Done time to output the results
Average berth size 1.7211696571373574
Average wait time 5.422940431259121
57
The log shows the same basic operation as for the first case.
Clock: 0.0 R.Tug.status: PAUSE_B Q.BerthingList.n: 0 Q.DeberthingList.n: 0 RG.Berths.n: 0
----------------------
The log does show that as many as 4 tankers can be berthed and loaded:
----------------------
the same basic operation as for the first case.
58

Steady State Observation Interval
For a steady state study, the selection of the observation interval is made to accommodate a warm up
time and an end time for generating appropriate confidence intervals. First we consider the warm up
time by applying Welchs method, and then develop some experimentation to define an suitable right
hand side (end time) of the observation interval.
Welch's Method, W = 0
Avedrage Number of Occupied Berths
The Java class PortV1Warm contains the experimentation software required to determine the warm up
time. It uses the ABSmod/J class WelchAverage to apply Welchs moving average method to data
collected within time cells (see Section 7.3.1 of the textbook).
Ten simulation runs are used with 60 intervals of 7 days (1 week). Two matrices,
avgOccBerthsResults and avgWaitTimeResults, are used to collect the average number of occupied
berths and the average tanker waiting time for each of the intervals during the simulation runs. The
matrices are then used with the class WelchAverage to apply the moving average method to the
collected data. The results of the method are then printed out in comma delimited form such that a
graph may be generated using Excel.
The following shows the resulting graphs for the avgOccBerths output variable with window sizes of
0, 1, 3 and for the avgWaitTime output variable with window sizes of 0, 3 and 5; these results duplicate
those shown in Figures 7.4 and 7.5 of the textbook.
2.5
2
1.5
1
0.5
0
1
8
9
Week
10
11
12
13
14
15
2.5
2
1.5
1
0.5
0
1
8
9
Week
10
11
12
13
14
15
2.5
2
1.5
1
0.5
0
1
8
9
Week
10
11
12
13
14
15
Figure 10 Welchs method applied to the output avgOccBerths (average number of occupied berths)
59
8
9
Week
10
11
12
13
14
Average Tanker Total Wait Time
10
9
8
7
6
5
4
3
2
1
0
15
10
9
8
7
6
5
4
3
2
1
0
1
8
9
Week
10
11
12
13
14
15
10
9
8
7
6
5
4
3
2
1
0
1
8
9
Week
10
11
12
13
14
15
Figure 11 Welchs method applied to the output avgWaitTime (average tanker total wait time)
In the case of the number of occupied berths, there is no apparent transient. Even without the use of running
averages (see Figure 10, W = 0), the graph is relatively smooth. This result can be attributed to the small size of
the group (namely 3 or 4) which results in the available berths being quickly filled by the first few arrivals of
tankers.
A transient is certainly apparent for the tanker total wait time as shown in Figure 11 and moving averages are
required to smooth out the graph. A window size of 5 provides a suitable result and shows that the transient lasts
for approximately 3 weeks. Either 4 or 5 weeks can be selected as a suitable warm-up period. The warm up period
of 5 weeks was selected for
The warm-up period has relevance for the elimination of the transient in the tanker total wait time output
variable. However this does not preclude the collection of number of occupied berths data during the warm-up
period.
Its now time to consider experimentation to define a suitable end time for the observation interval. The Java
class PortV1Exp2 was designed to examine the effect of using a 10 week, 20 week and 30 week observation
interval with number of simulation runs ranging from 20 runs to 10000 runs. Table 7.5 from the textbook was
duplicated using this class and is shown below.
End Time = 10 weeks (1680.0
hours), TimeStamp: 13:28:47

60
+--------+------------------------------------+------------------------------------+------------------------------------+
|
Number of berths 3
|
+--------+------------------------------------+------------------------------------+------------------------------------+
tf: |
10 weeks
|
20 weeks
|
30 weeks
|
+--------+------------------------------------+------------------------------------+------------------------------------+
+--------+------------------------------------+------------------------------------+------------------------------------+
n
| yb(n)
s(n)
z(n) z(n)/yb(n)| yb(n)
s(n)
s(n)
z(n) z(n)/yb(n)|
+--------+------------------------------------+------------------------------------+------------------------------------+
+--------+------------------------------------+------------------------------------+------------------------------------+
|
Average Number of Occupied Berths
|
+--------+------------------------------------+------------------------------------+------------------------------------+
20 |
1.845
0.135
0.052
0.0282 |
1.858
0.070
0.027
0.0145 |
1.866
0.064
0.025
0.0133 |
30 |
1.820
0.137
0.042
0.0233 |
1.833
0.087
0.027
0.0147 |
1.842
0.077
0.024
0.0129 |
40 |
1.824
0.136
0.036
0.0199 |
1.833
0.094
0.025
0.0137 |
1.838
0.070
0.019
0.0101 |
60 |
1.827
0.145
0.031
0.0172 |
1.833
0.098
0.021
0.0116 |
1.828
0.076
0.016
0.0090 |
80 |
1.828
0.138
0.026
0.0140 |
1.834
0.101
0.019
0.0103 |
1.833
0.075
0.014
0.0076 |
100 |
1.823
0.137
0.023
0.0125 |
1.834
0.100
0.017
0.0091 |
1.830
0.077
0.013
0.0070 |
1000 |
1.834
0.130
0.007
0.0037 |
1.833
0.094
0.005
0.0027 |
1.833
0.077
0.004
0.0022 |
10000 |
1.826
0.132
0.002
0.0012 |
1.832
0.095
0.002
0.0009 |
1.833
0.078
0.001
0.0007 |
+--------+------------------------------------+------------------------------------+------------------------------------+
+--------+------------------------------------+------------------------------------+------------------------------------+
|
|
+--------+------------------------------------+------------------------------------+------------------------------------+
20 |
7.201
2.332
0.902
0.1252 |
7.216
1.885
0.729
0.1010 |
7.268
1.503
0.581
0.0800 |
30 |
6.870
2.392
0.742
0.1080 |
7.061
1.664
0.516
0.0731 |
7.279
1.372
0.426
0.0585 |
40 |
6.750
2.460
0.655
0.0971 |
7.116
1.994
0.531
0.0746 |
7.330
1.470
0.392
0.0534 |
60 |
8.003
5.691
1.228
0.1534 |
7.466
2.604
0.562
0.0752 |
7.333
1.714
0.370
0.0504 |
80 |
7.915
5.216
0.971
0.1226 |
7.474
2.422
0.451
0.0603 |
7.422
1.751
0.326
0.0439 |
100 |
7.900
5.134
0.852
0.1079 |
7.684
2.486
0.413
0.0537 |
7.468
1.773
0.294
0.0394 |
1000 |
7.669
4.531
0.236
0.0308 |
7.700
2.819
0.147
0.0191 |
7.711
2.299
0.120
0.0155 |
10000 |
7.504
4.527
0.074
0.0099 |
7.705
2.929
0.048
0.0063 |
7.740
2.295
0.038
0.0049 |
+--------+------------------------------------+------------------------------------+------------------------------------+
+--------+------------------------------------+------------------------------------+------------------------------------+
61
+--------+------------------------------------+------------------------------------+------------------------------------+
|
Number of berths 4
|
+--------+------------------------------------+------------------------------------+------------------------------------+
tf: |
10 weeks
|
20 weeks
|
30 weeks
|
+--------+------------------------------------+------------------------------------+------------------------------------+
+--------+------------------------------------+------------------------------------+------------------------------------+
n
| yb(n)
s(n)
s(n)
s(n)
z(n) z(n)/yb(n)|
+--------+------------------------------------+------------------------------------+------------------------------------+
+--------+------------------------------------+------------------------------------+------------------------------------+
|
|
+--------+------------------------------------+------------------------------------+------------------------------------+
20 |
1.859
0.145
0.056
0.0302 |
1.872
0.073
0.028
0.0150 |
1.877
0.066
0.026
0.0136 |
30 |
1.835
0.144
0.045
0.0243 |
1.847
0.089
0.028
0.0149 |
1.854
0.078
0.024
0.0130 |
40 |
1.839
0.143
0.038
0.0208 |
1.847
0.094
0.025
0.0136 |
1.850
0.071
0.019
0.0102 |
60 |
1.844
0.154
0.033
0.0180 |
1.846
0.101
0.022
0.0117 |
1.840
0.078
0.017
0.0091 |
80 |
1.845
0.145
0.027
0.0146 |
1.847
0.104
0.019
0.0105 |
1.845
0.077
0.014
0.0077 |
100 |
1.839
0.143
0.024
0.0129 |
1.847
0.104
0.017
0.0093 |
1.841
0.080
0.013
0.0072 |
1000 |
1.850
0.135
0.007
0.0038 |
1.846
0.097
0.005
0.0027 |
1.845
0.079
0.004
0.0022 |
10000 |
1.842
0.136
0.002
0.0012 |
1.845
0.098
0.002
0.0009 |
1.846
0.080
0.001
0.0007 |
+--------+------------------------------------+------------------------------------+------------------------------------+
+--------+------------------------------------+------------------------------------+------------------------------------+
|
|
+--------+------------------------------------+------------------------------------+------------------------------------+
20 |
2.539
1.019
0.394
0.1552 |
2.536
0.625
0.242
0.0953 |
2.535
0.411
0.159
0.0627 |
30 |
2.494
0.922
0.286
0.1147 |
2.558
0.560
0.174
0.0679 |
2.599
0.442
0.137
0.0528 |
40 |
2.461
0.875
0.233
0.0947 |
2.557
0.556
0.148
0.0579 |
2.583
0.416
0.111
0.0429 |
60 |
2.779
1.548
0.334
0.1201 |
2.604
0.698
0.151
0.0578 |
2.549
0.482
0.104
0.0408 |
80 |
2.721
1.421
0.264
0.0972 |
2.586
0.685
0.127
0.0493 |
2.551
0.495
0.092
0.0361 |
100 |
2.724
1.376
0.228
0.0839 |
2.629
0.679
0.113
0.0429 |
2.555
0.493
0.082
0.0320 |
1000 |
2.555
1.116
0.058
0.0227 |
2.562
0.640
0.033
0.0130 |
2.563
0.509
0.026
0.0103 |
10000 |
2.516
1.096
0.018
0.0072 |
2.562
0.662
0.011
0.0043 |
2.567
0.512
0.008
0.0033 |
+--------+------------------------------------+------------------------------------+------------------------------------+
+--------+------------------------------------+------------------------------------+------------------------------------+
62
The output for the Average Tanker Total Wait time shows that a 10 week observation interval is not
sufficient to provide good confidence intervals and shows that 30 weeks is not required. Thus a 20 week
observation interval with 30 simulation runs is chosen for experimentation to solve the modelling and
simulation problem.
Experimentation
The Java class PortV1Exp3 provide the experimentation program used to solve the problem and to
demonstrate the utility of common random numbers as well as an analysis of comparing alternatives as
discussed in section 7.4 of the textbook.
Using a 20 week observation interval and 30 simulation runs, the following tables present results with
and without the use of common random numbers (duplicate the tables 7.6 and 7.7 from the textbook).
With Common Random Numbers
+--------+------------+-------------+-------------++------------+-------------+-------------+
|
|
||
Average Tanker Total Wait Times
|
+--------+------------+-------------+-------------++------------+-------------+-------------+
| RG.Berths.numBerths |
|
||
RG.Berths.numBerths
|
|
+--------+------------+-------------+-------------++------------+-------------+-------------+
| Run
|
3
|
4
| Difference ||
3
|
4
| Difference |
+--------+------------+-------------+-------------++------------+-------------+-------------+
+--------+------------+-------------+-------------++------------+-------------+-------------+
|
1|
1.721|
1.729|
0.008||
5.987|
2.188|
-3.799|
|
2|
1.847|
1.862|
0.014||
7.434|
3.182|
-4.252|
|
3|
1.911|
1.920|
0.008||
7.657|
2.758|
-4.899|
|
4|
1.876|
1.888|
0.011||
6.332|
2.040|
-4.291|
|
5|
1.897|
1.917|
0.020||
7.235|
2.484|
-4.752|
|
6|
1.833|
1.844|
0.011||
4.590|
1.680|
-2.910|
|
7|
1.866|
1.888|
0.023||
8.267|
3.412|
-4.856|
|
8|
1.864|
1.877|
0.013||
9.323|
2.997|
-6.326|
|
9|
1.790|
1.796|
0.006||
6.399|
2.580|
-3.819|
|
10|
1.949|
1.969|
0.020||
7.212|
2.405|
-4.807|
|
11|
1.953|
1.956|
0.003||
9.391|
2.953|
-6.438|
|
12|
1.830|
1.846|
0.016||
7.776|
2.548|
-5.229|
|
13|
1.720|
1.743|
0.023||
4.822|
1.720|
-3.102|
|
14|
2.005|
2.044|
0.039||
12.646|
4.036|
-8.610|
|
15|
1.811|
1.819|
0.008||
4.706|
1.629|
-3.077|
|
16|
1.834|
1.852|
0.018||
6.132|
2.446|
-3.686|
|
17|
1.932|
1.941|
0.009||
9.014|
3.128|
-5.887|
|
18|
1.836|
1.841|
0.005||
5.784|
1.732|
-4.052|
|
19|
1.828|
1.833|
0.004||
5.796|
2.018|
-3.778|
|
20|
1.856|
1.870|
0.014||
7.822|
2.787|
-5.035|
|
21|
1.921|
1.924|
0.003||
7.392|
2.853|
-4.539|
|
22|
1.744|
1.754|
0.011||
6.097|
2.496|
-3.601|
|
23|
1.636|
1.659|
0.023||
6.184|
2.663|
-3.521|
|
24|
1.823|
1.856|
0.032||
6.887|
3.126|
-3.762|
|
25|
1.747|
1.746|
-0.000||
6.620|
2.215|
-4.405|
|
26|
1.843|
1.848|
0.005||
7.075|
2.426|
-4.649|
|
27|
1.668|
1.683|
0.015||
4.613|
1.802|
-2.811|
|
28|
1.699|
1.715|
0.015||
7.429|
2.920|
-4.509|
|
29|
1.928|
1.964|
0.036||
8.780|
3.093|
-5.686|
|
30|
1.828|
1.833|
0.005||
6.415|
2.422|
-3.993|
+--------+------------+-------------+-------------++------------+-------------+-------------+
+--------+------------+-------------+-------------++------------+-------------+-------------+
ybar(n)|
0.014||
-4.503|
s(n)|
0.010||
1.197|
zeta(n)|
0.003||
0.371|
CI Min(n)|
0.011||
-4.874|
CI Max(n)|
0.017||
-4.131|
+--------+------------+-------------+-------------++------------+-------------+-------------+
+--------+------------+-------------+-------------++------------+-------------+-------------+
63
Without Common Random Numbers

+--------+------------+-------------+-------------++------------+-------------+-------------+
|
|
||
|
+--------+------------+-------------+-------------++------------+-------------+-------------+
|
||
RG.Berths.numBerths
|
|
+--------+------------+-------------+-------------++------------+-------------+-------------+
| Run
|
3
|
4
| Difference
||
3
|
4
| Difference
||
+--------+------------+-------------+-------------++------------+-------------+-------------+
+--------+------------+-------------+-------------++------------+-------------+-------------+
|
1|
1.721|
1.834|
0.113||
5.987|
2.944|
-3.043|
|
2|
1.847|
1.868|
0.021||
7.434|
2.591|
-4.844|
|
3|
1.911|
1.925|
0.014||
7.657|
2.508|
-5.149|
|
4|
1.876|
1.951|
0.075||
6.332|
3.285|
-3.046|
|
5|
1.897|
1.603|
-0.295||
7.235|
2.107|
-5.128|
|
6|
1.833|
1.965|
0.132||
4.590|
3.589|
-1.001|
|
7|
1.866|
1.929|
0.064||
8.267|
2.259|
-6.008|
|
8|
1.864|
1.889|
0.025||
9.323|
2.528|
-6.796|
|
9|
1.790|
1.725|
-0.065||
6.399|
1.836|
-4.563|
|
10|
1.949|
1.767|
-0.182||
7.212|
1.905|
-5.307|
|
11|
1.953|
1.824|
-0.128||
9.391|
1.436|
-7.955|
|
12|
1.830|
1.934|
0.105||
7.776|
3.003|
-4.774|
|
13|
1.720|
1.757|
0.037||
4.822|
2.183|
-2.639|
|
14|
2.005|
2.008|
0.004||
12.646|
2.633|
-10.014|
|
15|
1.811|
1.996|
0.185||
4.706|
2.743|
-1.963|
|
16|
1.834|
1.877|
0.043||
6.132|
4.419|
-1.713|
|
17|
1.932|
1.976|
0.044||
9.014|
4.340|
-4.674|
|
18|
1.836|
1.743|
-0.093||
5.784|
1.659|
-4.125|
|
19|
1.828|
1.842|
0.014||
5.796|
2.162|
-3.634|
|
20|
1.856|
1.937|
0.080||
7.822|
2.347|
-5.475|
|
21|
1.921|
1.854|
-0.067||
7.392|
2.363|
-5.029|
|
22|
1.744|
1.889|
0.145||
6.097|
3.644|
-2.452|
|
23|
1.636|
1.793|
0.157||
6.184|
2.935|
-3.249|
|
24|
1.823|
1.821|
-0.003||
6.887|
2.117|
-4.770|
|
25|
1.747|
1.905|
0.159||
6.620|
2.200|
-4.420|
|
26|
1.843|
1.873|
0.030||
7.075|
2.474|
-4.601|
|
27|
1.668|
1.559|
-0.109||
4.613|
2.799|
-1.815|
|
28|
1.699|
1.736|
0.037||
7.429|
1.934|
-5.495|
|
29|
1.928|
1.646|
-0.282||
8.780|
1.789|
-6.990|
|
30|
1.828|
1.904|
0.076||
6.415|
4.787|
-1.628|
+--------+------------+-------------+-------------++------------+-------------+-------------+
+--------+------------+-------------+-------------++------------+-------------+-------------+
ybar(n)|
0.011||
-4.410|
s(n)|
0.118||
1.967|
zeta(n)|
0.037||
0.610|
CI Min(n)|
-0.026||
-5.020|
CI Max(n)|
0.048||
-3.800|
+--------+------------+-------------+-------------++------------+-------------+-------------+
+--------+------------+-------------+-------------++------------+-------------+-------------+
As presented in the textbook, without common random numbers, the confidence intervals half lengths
increases when common random numbers are not used. The above confidence intervals were produced
with individual confidence levels of 90%
Output Analysis
To produce the required output which provides a problem resolution, an observation interval of 20
weeks is used with 30 simulation runs. Given that 2 confidence intervals are used to compare the two
cases, an individual confidence level of Ck = 0.95 (=1-((1-0.9)/2)) to achieve an overall confidence level
of 0.9. The following table was generated with the class PortV1Exp3 where the confidence level was
changed to 0.95 and common random numbers used.
64
+--------+------------+-------------+-------------++------------+-------------+-------------+
|
|
||
|
+--------+------------+-------------+-------------++------------+-------------+-------------+
|
||
RG.Berths.numBerths
|
|
+--------+------------+-------------+-------------++------------+-------------+-------------+
| Run
|
3
|
4
| Difference ||
3
|
4
| Difference |
+--------+------------+-------------+-------------++------------+-------------+-------------+
+--------+------------+-------------+-------------++------------+-------------+-------------+
|
1|
1.721|
1.729|
0.008||
5.987|
2.188|
-3.799|
|
2|
1.847|
1.862|
0.014||
7.434|
3.182|
-4.252|
|
3|
1.911|
1.920|
0.008||
7.657|
2.758|
-4.899|
|
4|
1.876|
1.888|
0.011||
6.332|
2.040|
-4.291|
|
5|
1.897|
1.917|
0.020||
7.235|
2.484|
-4.752|
|
6|
1.833|
1.844|
0.011||
4.590|
1.680|
-2.910|
|
7|
1.866|
1.888|
0.023||
8.267|
3.412|
-4.856|
|
8|
1.864|
1.877|
0.013||
9.323|
2.997|
-6.326|
|
9|
1.790|
1.796|
0.006||
6.399|
2.580|
-3.819|
|
10|
1.949|
1.969|
0.020||
7.212|
2.405|
-4.807|
|
11|
1.953|
1.956|
0.003||
9.391|
2.953|
-6.438|
|
12|
1.830|
1.846|
0.016||
7.776|
2.548|
-5.229|
|
13|
1.720|
1.743|
0.023||
4.822|
1.720|
-3.102|
|
14|
2.005|
2.044|
0.039||
12.646|
4.036|
-8.610|
|
15|
1.811|
1.819|
0.008||
4.706|
1.629|
-3.077|
|
16|
1.834|
1.852|
0.018||
6.132|
2.446|
-3.686|
|
17|
1.932|
1.941|
0.009||
9.014|
3.128|
-5.887|
|
18|
1.836|
1.841|
0.005||
5.784|
1.732|
-4.052|
|
19|
1.828|
1.833|
0.004||
5.796|
2.018|
-3.778|
|
20|
1.856|
1.870|
0.014||
7.822|
2.787|
-5.035|
|
21|
1.921|
1.924|
0.003||
7.392|
2.853|
-4.539|
|
22|
1.744|
1.754|
0.011||
6.097|
2.496|
-3.601|
|
23|
1.636|
1.659|
0.023||
6.184|
2.663|
-3.521|
|
24|
1.823|
1.856|
0.032||
6.887|
3.126|
-3.762|
|
25|
1.747|
1.746|
-0.000||
6.620|
2.215|
-4.405|
|
26|
1.843|
1.848|
0.005||
7.075|
2.426|
-4.649|
|
27|
1.668|
1.683|
0.015||
4.613|
1.802|
-2.811|
|
28|
1.699|
1.715|
0.015||
7.429|
2.920|
-4.509|
|
29|
1.928|
1.964|
0.036||
8.780|
3.093|
-5.686|
|
30|
1.828|
1.833|
0.005||
6.415|
2.422|
-3.993|
+--------+------------+-------------+-------------++------------+-------------+-------------+
+--------+------------+-------------+-------------++------------+-------------+-------------+
ybar(n)|
0.014||
-4.503|
s(n)|
0.010||
1.197|
zeta(n)|
0.004||
0.447|
CI Min(n)|
0.010||
-4.950|
CI Max(n)|
0.018||
-4.056|
+--------+------------+-------------+-------------++------------+-------------+-------------+
+--------+------------+-------------+-------------++------------+-------------+-------------+
For the two cases where number of berths is 3 and 4, the above table shows the output data for each of the
output variables (the average group size and tanker total wait time). The difference column is obtained as:
(RG.Berths.numBerths=4) - (RG.Berths.numBerths=3). The comparison of the two alternatives is carried out
using Eq. (7.3) given in the textbook. Note that the ratio of the half-length to the point estimates is 0.29 for the
average number of occupied berths and 0.0992 for the average tanker total wait times. In the second case the
10% criterion for the ratio of the half-length to the point estimate has been met. In the former case, it has not, but
given that values in the confidence level are so small, this does not pose any concern.
The confidence interval information is provided at the bottom of the above table. Some interpretation of the
data is as follows:
1. It is clear that increasing the number of berths to 4 does decrease the average tanker total wait time (by almost
4.5 hours).
2. Although the confidence interval for the berth group size is to the right of zero, the point estimate of the
difference is so small relative to the individual point estimates we are obliged to conclude that increasing the
berth size has no effect on this output variable. This is somewhat counter-intuitive but is a consequence of the
relative values of tanker arrival rate, the tugs cycle time (time to deberth and berth a tanker) and the tanker
loading times. For example, if the loading times are increased, then the average berth group size does increase
65
and vice versa. An alternate measure that would be interesting is the percentage of time that all available berths
are occupied. The interested reader is encouraged to experiment with the simulation program by exploring the
effects of changing these various times. Closer examination of the trace log for the two cases may provide
clues on why this result is obtained.
Conclusions
Adding a 4th berth improves significantly the tanker total wait times but not the average number of
occupied berths. An additional modelling and simulation project can provide the following information
that can explain the latter result:
1) Percentage of time all available berths are occupied.
2) Percentage of time no tankers are berthed (i.e. all berths are empty).
The project could also examine how adding more berths can impact the tanker waiting times and at
which point additional berths provide no improvement on the tanker waiting times.
66

The data models used in the port project are:
1) Tanker loading times: The time to load a tanker depends on its size. The loading times are
modelled using uniform distributions with minimum and maximum parameters shown in the
following table.
Tanker Size
Minimum Parameter
Maximum Parameter
SMALL
8 hours
10 hours
MEDIUM
10 hours
14 hours
LARGE
15 hours
21 hours
2) Tanker Arrivals: Tanker arrivals are model as a Poisson process. Thus interarrival times are
considered exponentially distributed with a mean of 8 hours.
3) Tanker Size: Tankers are assigned the values of SMALL, MEDIUM and LARGE. An arriving
tanker is assumed to have a size according to the following percentages:
a. SMALL: 25%
b. MEDIUM: 25%
c. LARGE: 50%
4) The times for berthing and deberthing tankers are 1 hour and 2 hours respectively as
recommended by the harbour master.
5) The time for the tug to travel with no tanker in tow between the harbour and berths is 15 minutes
as recommended by the harbour master.
67

Problem Description
Problem Statement
SUI Details
Harbour
Berth 1
Berth 2
Berth 3
68
5.
Each loaded tanker must wait until all previously loaded tankers have been deberthed (i.e., those
Tug Operation
area.
When there is no tanker in the harbour waiting to be berthed and the berths are not empty, the tug
again embarks on a return trip to the berthing area without a tanker in tow. However, in this
modified case, if a tanker arrives in the harbour and the tug has not yet completed 70% of its journey
back to the berths or if there is no tanker waiting to be deberthed, the harbor master will instruct the
tug to return to the harbour entrance to start berthing the newly arrived tanker.
Storms
storm is over, the tug resumes the operation that was underway before the storm occurred
69
Project Goals
Parameters
RG.Berths.numBerths: The number of berths for loading tankers. The two values of interest
are three and four.
Experimentation
Base Case: case where RG.Berths.numBerths = 3.
Alternate Case: case where RG.Berths.numBerths = 4.
Output
tanker is waiting to be towed to berths or waiting to be towed back to the harbour entrance. In the
ideal case, these subtasks would be initiated immediately and waiting time would be zero.
70

Assumptions
not required here).
Simplifications
The occurrence of storm conditions is not considered.

Structural View
harbour master.
Q.DeberthingList
R.Tug
RG.Berths
Q.BerthingList
Legend
iC.Tanker
Entity Categories
deberthing.
harbour and berths.
71
Notes:
Behavioural View
TankerArrival
Berthing
MoveToHarbour
ReturnToHarbour
Deberthing
Loading
Deberthing
Berthing
MoveToBerths
Actions:
arrival, tanker attribute values are assigned and the tanker instance is placed into the
Q.BerthingList entity.
Activities:
Berthing: This activity represents the Tug entity towing an empty Tanker entity from the
harbour to the berths.
Deberthing: This activity represents the Tug entity towing a loaded Tanker entity from the
entity in tow and may suffer an interruption if a Tanker arrives in the habour before the Tug
reaches the Berths.
ReturnToHarbour: This (sequel) activity is initiated when the tug, while moving to the
berth area without a tanker in tow, is required to return to the harbor because an empty
tanker has arrived.
entity in tow.
Loading: This activity represents the loading of a Tanker. This is a sequel activity and is
initiated at the completion of the Deberthing activity.
72
Input
Description
Domain Sequence
Variable
Name
uTnkr(t)

RVP.DuTnkr()
represents the arriving tankers.
Variable Name
Description
iC.Tanker.uSize
uLoadTime

Loading time for a tanker. The loading
time depends on the size of the tanker.
Range Sequence
each arrival time.
Value(s)
RVP.uTankerSize()
RVP.uLoadTime(size)

Constants
Description
Name
BERTH_TIME
DEBERTH_TIME
EMPTY_TIME

Parameters
Description
Name
RG.Berths.numBerths
Value
1 hour
2 hours
0.25 hour
Values
3 and 4

Attributes
uSize
startWait
totalWait
Description
Resource Unary: Tug

This resource entity structure represents the tugboat that is needed to berth tankers that arrive in
the harbour and to deberth tankers that have finished loading.
Attributes
status
startTime
Description
BUSY travelling with or without a tanker in tow,
PAUSE_H stopped in the harbour ready for the next task,
PAUSE_B stopped in the berth area ready for the next task.
Time stamp indicating the time when the tug leaves the harbour to travel back to
the berth area.
73

Attributes
list
n
numBerths
Description

Attributes
Description
list
n

Attributes
Description
Discipline: FIFO.
list
n
Time units: Hours
Action: Initialise
TimeSequence
Event SCS
<0>
RG.Berths.n 0
Q.BerthingList.n 0
Output
Name
TRJ[RG.Berths.n]
Name
Name
avgOccBerths
avgWaitTime
OUTPUTS
Description
Sample Sequences
Description

Description
Output Sequence
Name
74
TRJ[RG.Berths.n]
Operation
AVG
AVG

None required.
Input Constructs
Name

Description
Data Model
RVP.uLoadTime(Size)
The returned value is the loading time

for a tanker entity instance. It is
assigned according to the tanker's size;
i.e., SMALL, MEDIUM or LARGE).
Each of the data models is UNIFORM(Min, Max)

where min and max take on the following values (in
hours) according to the tanker size.
Size
Min
Max
RVP.uTankerSize()

tanker entity instance; value is one
of SMALL, MEDIUM or LARGE.
The percentage of SMALL, MEDIUM and

LARGE arriving tankers is given in the
following table.
Size
Percent
SMALL
PERSML=25%
MEDIUM PERMED=25%
LARGE
PERLRG= 50%
RVP.DuTnkr()


Event SCS
This activity represents the Tug entity towing a loaded Tanker entity from the
Precondition (R.Tug.status = PAUSE_B) AND (Q.DeberthingList.n 0)
Event SCS
(Update totalWait)
R.Tug.status BUSY
Duration
DEBERTH_TIME
Event SCS
SP.Put(PHI[tankerWait], iC.Tanker.totalWait)
SP.Leave(iC.Tanker)
75
Activity: Berthing
This activity represents the Tug entity towing an empty tanker entity from the harbour to the
berths. Note that the availability of an empty berth is implicit in the fact that the tug is located in
the harbour.
Precondition (R.Tug.status = PAUSE_H) AND (Q.BerthingList.n > 0)
Event SCS
R.Tug.status BUSY
Duration
BERTH_TIME
Event SCS
This activity represents the Tug entity moving to the harbour area with no Tanker entity in tow.
Precondition (R.Tug.status = PAUSE_B) AND (Q.DeberthingList.n = 0) AND
(RG.Berths.n < RG.Berths.numBerths)
Event SCS
R.Tug.status BUSY
Duration
EMPTY_TIME
Event SCS
This activity represents the Tug entity moving to the berths area with no Tanker entity in tow.
Precondition
(R.Tug.status = PAUSE_H) AND (Q.BerthingList.n = 0) AND
(RG.Berths.n > 0)
Event SCS
R.Tug.status BUSY
R.Tug.startTime t
Duration
EMPTY_TIME
Interruption
Precondition
( ((t-R.Tug.startTime) < 0.7 * EMTPY_TIME)
OR (Q.DeberthingList.n = 0) )
Event SCS
SP.Start(ReturnToHarbour)
SP.Terminate()
Event SCS
Activity: ReturnToHarbour
This (sequel) activity is initiated when the tug, while moving to the berth area without a tanker in
tow, is required to return to the harbor because an empty tanker has arrived.
Causal
()
Event SCS
Duration
(t R.Tug.startTime)
Event SCS
Activity: Loading
This activity represents the loading of a Tanker. This is a sequel activity and is initiated at the
completion of the Deberthing activity
Causal
(iC.Tanker)
Event SCS
Duration
Event SCS
76

Trace Logging
number of tanker referenced in the two queues (Q.BerthingList, Q.DeberthingList) and in the resource
group (RG.Berths). These values are presented on a single line as follows:
Clock: xxxxxxx R.Tug.status: xx Q.BerthingList.n: xx Q.DeberthingList.n: xx RG.Berths.n: xx
77
Simulation Model
ABCmod Construct
iC.Tanker
RG.Berths
Q.BerthingList
Q.DeberthingList
Entity Structures
Java Class
Tanker
Berths
Notes:
class.
attribute.
Notes
Object References
PortVer2.rgBerths
Actions/Activities
ABCmod Constructs
Java Classes
TankerArrivals
Deberthing
Berthing
MoveToHarbour
MoveToBerths
Loading
ReturnToHarbour
TankerArrivals
Deberthing
Berthing
MoveToHarbour
MoveToBerths
Loading
ReturnToHarbour
78
TRJ[RG.Berths.n] implemented as the OutputSequence object referenced by trjRGBethsN and the
phiICTankerTotalWait. The method updateSequences in this class provides the means to update
the trajectory sequence and is called by the method eventOccured (PortVer2 class).
RVPs (referenced by PortVer2.rvp): Contains the Java methods used to implement the CM RVPs.
various RVPs.
All public methods provided by the class AOSimulation (e.g. runSimulation) for supporting
experimentation.
79

harbour when a tanker arrives.
Clock: 0.0 R.Tug.status: PAUSE_B Q.BerthingList.n: 0 Q.DeberthingList.n: 0 G.Berths.n: 0
---------------------Clock: 0.0 R.Tug.status: BUSY Q.BerthingList.n: 1 Q.DeberthingList.n: 0 G.Berths.n: 0
Once the MoveToHarbour activity completes, then a Berthing activity is initiated.


initiated. Note also that the MoveToHarbour activity is initiated to move the tug back to the harbour
to get a waiting tanker.

80

When a Loading activity terminates, the Deberthing activity is initiated, thus removing it from
RG.Berths.

----------------------
When the RG.Berths is full, the tug remains in at the berths (i.e. no MoveToHarbour activity is
initiated).

----------------------
81

------------------------------------------Clock: 57.29060596784392 R.Tug.status: PAUSE_B Q.BerthingList.n: 0 Q.DeberthingList.n: 0 RG.Berths.n: 3
----------------------
where a number of tankers were waiting in the harbour.

82

----------------------
0 RG.Berths.n: 2
1 RG.Berths.n: 2
1 RG.Berths.n: 2
2 RG.Berths.n: 2
2 RG.Berths.n: 2
1 RG.Berths.n: 2
83
The above trace did not show the contents of the extended scheduled behaviour list (esbl). To see how
interruption behaviour is properly implemented the log was changed to include the output of the esbl.
The ESBL is empty unless a MoveToBerths activity has been scheduled
---------------------------------ESBL------------------------------Clock: 0.0 R.Tug.status: BUSY Q.BerthingList.n: 1 Q.DeberthingList.n: 0 RG.Berths.n: 0
---------------------------------ESBL------------------------------...
------------SBL---------TimeStamp:15.329704659525305 Activity/Action: portModelV2.MoveToBerths
---------------------------------ESBL---------TimeStamp:15.329704659525305 Activity/Action: portModelV2.MoveToBerths
----------------------
The following log section shows how a TankerArrival will interrupt the MoveToBeths activity
which is replaced by the ReturnToHarbour activity. Note that the arrival occurs roughly 9 minutes
before the end of the MoveToBerths activity, well within the 0.7*EMPTY_TIME time limit to return
to the harbour.

TimeStamp:2292.480794757248 Activity/Action: portModelV2.MoveToBerths
------------SBL---------TimeStamp:2292.4593555742867 Activity/Action: portModelV2.ReturnToHarbour
----------------------
84
The above trace did not show the contents of the extended scheduled behaviour list (esbl). To see how
interruption behaviour is properly implemented the log was changed to include the output of the esbl.
The ESBL is empty unless a MoveToBerths activity has been scheduled
---------------------------------ESBL------------------------------...
----------------------
The following log section shows how a TankerArrival will interrupt the MoveToBeths activity
which is replaced by the ReturnToHarbour activity. Note that the arrival occurs roughly 9 minutes
to the harbour.

----------------------
85
----------------------
The log does show that as many as 4 tankers can be berthed and loaded:
----------------------
86
The log also showed the proper return to harbour behaviour upon arrival of a tanker when the tug was
involved in the MoveToBerths activity.
----------------------
87

time by applying Welchs method, and then develop some experimentation to define an suitable right
0, 1, 3 and for the avgWaitTime output variable with window sizes of 0, 3 and 5.
2
1.5
1
0.5
0
1
8
9
Week
10
11
12
13
14
15
2.5
2
1.5
1
0.5
0
1
8
9
Week
10
11
12
13
14
15
2.5
2.5
2
1.5
1
0.5
0
1
8
9
Week
10
11
12
13
14
15
88
8
9
Week
10
11
12
13
14
10
9
8
7
6
5
4
3
2
1
0
15
10
9
8
7
6
5
4
3
2
1
0
1
12
13
8
9
Week
10
11
12
13
14
15
10
9
8
7
6
5
4
3
2
1
0
1
8
9
Week
10
11
14
15
averages (Figure 15, W = 0), the graph is relatively smooth. This result can be attributed to the small size of the
group (namely 3 or 4) which results in the available berths being quickly filled by the first few arrivals of tankers.
of 5 weeks was selected for
period.
interval with number of simulation runs ranging from 20 runs to 80 runs. The results of the experimentation are
shown below.

89
+--------+------------------------------------+------------------------------------+------------------------------------+
|
Number of berths 3
|
+--------+------------------------------------+------------------------------------+------------------------------------+
tf: |
10 weeks
|
20 weeks
|
30 weeks
|
+--------+------------------------------------+------------------------------------+------------------------------------+
+--------+------------------------------------+------------------------------------+------------------------------------+
n
| yb(n)
s(n)
s(n)
s(n)
z(n) z(n)/yb(n)|
+--------+------------------------------------+------------------------------------+------------------------------------+
+--------+------------------------------------+------------------------------------+------------------------------------+
|
|
+--------+------------------------------------+------------------------------------+------------------------------------+
20 |
1.845
0.135
0.052
0.0282 |
1.858
0.070
0.027
0.0145 |
1.866
0.064
0.025
0.0133 |
30 |
1.821
0.137
0.042
0.0233 |
1.833
0.087
0.027
0.0147 |
1.843
0.077
0.024
0.0129 |
40 |
1.824
0.136
0.036
0.0199 |
1.833
0.094
0.025
0.0137 |
1.838
0.070
0.019
0.0101 |
60 |
1.827
0.145
0.031
0.0172 |
1.833
0.098
0.021
0.0116 |
1.828
0.076
0.016
0.0090 |
80 |
1.828
0.138
0.026
0.0140 |
1.834
0.101
0.019
0.0103 |
1.833
0.075
0.014
0.0076 |
+--------+------------------------------------+------------------------------------+------------------------------------+
+--------+------------------------------------+------------------------------------+------------------------------------+
|
|
+--------+------------------------------------+------------------------------------+------------------------------------+
20 |
7.192
2.327
0.900
0.1251 |
7.205
1.876
0.725
0.1006 |
7.258
1.497
0.579
0.0798 |
30 |
6.864
2.387
0.741
0.1079 |
7.051
1.656
0.514
0.0729 |
7.271
1.368
0.424
0.0584 |
40 |
6.745
2.457
0.655
0.0971 |
7.108
1.991
0.530
0.0746 |
7.322
1.468
0.391
0.0534 |
60 |
7.997
5.690
1.228
0.1535 |
7.458
2.603
0.562
0.0753 |
7.325
1.712
0.369
0.0504 |
80 |
7.909
5.216
0.971
0.1227 |
7.466
2.422
0.451
0.0604 |
7.413
1.750
0.326
0.0439 |
+--------+------------------------------------+------------------------------------+------------------------------------+
+--------+------------------------------------+------------------------------------+------------------------------------+
90
+--------+------------------------------------+------------------------------------+------------------------------------+
|
Number of berths 4
|
+--------+------------------------------------+------------------------------------+------------------------------------+
tf: |
10 weeks
|
20 weeks
|
30 weeks
|
+--------+------------------------------------+------------------------------------+------------------------------------+
+--------+------------------------------------+------------------------------------+------------------------------------+
n
| yb(n)
s(n)
s(n)
s(n)
z(n) z(n)/yb(n)|
+--------+------------------------------------+------------------------------------+------------------------------------+
+--------+------------------------------------+------------------------------------+------------------------------------+
|
|
+--------+------------------------------------+------------------------------------+------------------------------------+
20 |
1.859
0.146
0.056
0.0303 |
1.872
0.073
0.028
0.0150 |
1.877
0.066
0.026
0.0136 |
30 |
1.836
0.144
0.045
0.0244 |
1.848
0.089
0.028
0.0149 |
1.855
0.078
0.024
0.0130 |
40 |
1.840
0.143
0.038
0.0208 |
1.847
0.094
0.025
0.0136 |
1.850
0.071
0.019
0.0102 |
60 |
1.844
0.154
0.033
0.0180 |
1.846
0.101
0.022
0.0118 |
1.840
0.078
0.017
0.0091 |
80 |
1.845
0.145
0.027
0.0146 |
1.847
0.104
0.019
0.0105 |
1.845
0.077
0.014
0.0077 |
+--------+------------------------------------+------------------------------------+------------------------------------+
+--------+------------------------------------+------------------------------------+------------------------------------+
|
|
+--------+------------------------------------+------------------------------------+------------------------------------+
20 |
2.534
1.019
0.394
0.1555 |
2.529
0.624
0.241
0.0954 |
2.527
0.410
0.158
0.0627 |
30 |
2.490
0.924
0.287
0.1152 |
2.551
0.558
0.173
0.0679 |
2.592
0.440
0.137
0.0527 |
40 |
2.457
0.876
0.233
0.0950 |
2.550
0.556
0.148
0.0581 |
2.576
0.415
0.110
0.0429 |
60 |
2.775
1.548
0.334
0.1204 |
2.598
0.699
0.151
0.0580 |
2.543
0.481
0.104
0.0408 |
80 |
2.716
1.421
0.264
0.0974 |
2.579
0.686
0.128
0.0495 |
2.545
0.494
0.092
0.0361 |
+--------+------------------------------------+------------------------------------+------------------------------------+
+--------+------------------------------------+------------------------------------+------------------------------------+
91
The output for the Average Tanker Total Wait time shows that a 10 week observation interval is not
sufficient to provide good confidence intervals and shows that 30 weeks is not required. Thus a 20 week
observation interval with 30 simulation runs is chosen for experimentation to solve the modelling and
simulation problem.
Experimentation
The following shows the output of the simulation runs for both cases. The difference between the
cases were used to generate 2 confidence intervals, one to see the change in the number of occupied
berths and the other to see the change in the tanker total waiting time. Given that 2 confidence intervals
are used to compare the two cases, an individual confidence level of Ck = 0.95 (=1-((1-0.9)/2)) to
achieve an overall confidence level of 0.9. The following table was generated with the experimentation
program found in class PortV1Exp3.
End Time = 20 weeks (3360.0 hours), TimeStamp: 15:13:22
End Time = 20 weeks (3360.0 hours), TimeStamp: 15:13:23
+--------+------------+-------------+-------------++------------+-------------+-------------+
|
|
||
|
+--------+------------+-------------+-------------++------------+-------------+-------------+
|
||
RG.Berths.numBerths
|
|
+--------+------------+-------------+-------------++------------+-------------+-------------+
| Run
|
3
|
4
| Difference
||
3
|
4
| Difference
||
+--------+------------+-------------+-------------++------------+-------------+-------------+
+--------+------------+-------------+-------------++------------+-------------+-------------+
|
1|
1.721|
1.730|
0.009||
5.981|
2.184|
-3.797|
|
2|
1.847|
1.862|
0.014||
7.433|
3.182|
-4.251|
|
3|
1.912|
1.921|
0.009||
7.656|
2.764|
-4.892|
|
4|
1.877|
1.888|
0.012||
6.331|
2.032|
-4.299|
|
5|
1.897|
1.917|
0.020||
7.196|
2.485|
-4.711|
|
6|
1.833|
1.844|
0.011||
4.589|
1.677|
-2.912|
|
7|
1.865|
1.889|
0.024||
8.259|
3.396|
-4.862|
|
8|
1.864|
1.877|
0.013||
9.309|
2.985|
-6.324|
|
9|
1.789|
1.795|
0.006||
6.391|
2.570|
-3.820|
|
10|
1.949|
1.969|
0.020||
7.199|
2.394|
-4.805|
|
11|
1.953|
1.957|
0.003||
9.390|
2.929|
-6.462|
|
12|
1.830|
1.846|
0.016||
7.776|
2.545|
-5.232|
|
13|
1.719|
1.743|
0.023||
4.795|
1.709|
-3.087|
|
14|
2.004|
2.043|
0.039||
12.572|
4.028|
-8.544|
|
15|
1.812|
1.820|
0.008||
4.691|
1.622|
-3.069|
|
16|
1.834|
1.852|
0.018||
6.132|
2.446|
-3.687|
|
17|
1.932|
1.941|
0.009||
9.007|
3.124|
-5.883|
|
18|
1.836|
1.841|
0.005||
5.781|
1.730|
-4.052|
|
19|
1.829|
1.832|
0.003||
5.803|
2.010|
-3.793|
|
20|
1.856|
1.869|
0.013||
7.816|
2.776|
-5.039|
|
21|
1.922|
1.925|
0.002||
7.364|
2.833|
-4.531|
|
22|
1.744|
1.755|
0.011||
6.095|
2.491|
-3.604|
|
23|
1.636|
1.658|
0.022||
6.181|
2.648|
-3.533|
|
24|
1.823|
1.857|
0.033||
6.884|
3.101|
-3.784|
|
25|
1.747|
1.746|
-0.001||
6.620|
2.206|
-4.414|
|
26|
1.844|
1.849|
0.005||
7.084|
2.420|
-4.663|
|
27|
1.668|
1.684|
0.015||
4.605|
1.797|
-2.809|
|
28|
1.700|
1.717|
0.017||
7.423|
2.924|
-4.500|
|
29|
1.928|
1.965|
0.037||
8.773|
3.095|
-5.678|
|
30|
1.828|
1.833|
0.005||
6.405|
2.420|
-3.985|
+--------+------------+-------------+-------------++------------+-------------+-------------+
+--------+------------+-------------+-------------++------------+-------------+-------------+
ybar(n)|
0.014||
-4.501|
s(n)|
0.010||
1.190|
zeta(n)|
0.004||
0.444|
CI Min(n)|
0.010||
-4.945|
CI Max(n)|
0.018||
-4.056|
+--------+------------+-------------+-------------++------------+-------------+-------------+
+--------+------------+-------------+-------------++------------+-------------+-------------+
92
Output Analysis
For the two cases where number of berths is 3 and 4, the above table shows the output data for each of the output
variables (the average group size and tanker total wait time). The difference column is obtained as:
(RG.Berths.numBerths=4) - (RG.Berths.numBerths=3). The comparison of the two alternatives is carried out
using Eq. (7.3) given in the textbook. Note that the ratio of the half-length to the point estimates is 0.29 for the
average number of occupied berths and 0.0992 for the average tanker total wait times. In the second case the
10% criterion for the ratio of the half-length to the point estimate has been met. In the former case, it has not, but
given that values in the confidence level are so small, this does not pose any concern.
The confidence interval information is provided at the bottom of the above table. Some interpretation of the
data is as follows:
1. It is clear that increasing the number of berths to 4 does decrease the average tanker total wait time (by almost
4.5 hours).
2. Although the confidence interval for the berth group size is to the right of zero, the point estimate of the
difference is so small relative to the individual point estimates we are obliged to conclude that increasing the
berth size has no effect on this output variable. This is somewhat counter-intuitive but is a consequence of the
relative values of tanker arrival rate, the tugs cycle time (time to deberth and berth a tanker) and the tanker
loading times. For example, if the loading times are increased, then the average berth group size does increase
and vice versa. An alternate measure that would be interesting is the percentage of time that all available berths
are occupied. The interested reader is encouraged to experiment with the simulation program by exploring the
effects of changing these various times. Closer examination of the trace log for the two cases may provide
clues on why this result is obtained.
Conclusions
Adding a 4th berth improves significantly the tanker total wait times but not the average number of
occupied berths. An additional modelling and simulation project can provide the following information
that can explain the latter result:
(Note: It is interesting to note that the results are not that much different than those presented for
version 1 of the Port project, that is, the added behaviour did not affect significantly the operation of the
port).
93

following table.
Tanker Size
Minimum Parameter
Maximum Parameter
SMALL
8 hours
10 hours
MEDIUM
10 hours
14 hours
LARGE
15 hours
21 hours
a. SMALL: 25%
b. MEDIUM: 25%
c. LARGE: 50%
94

Problem Description
Problem Statement
The port authority before comiting to the expense of a 4th berth, wishes another study to show that the
assumption that storms that occur frequently in the area of the port has negligible impact on the waiting
times of the tankers.
SUI Details
Harbour
Berth 1
Berth 2
Berth 3
95
5. Each loaded tanker must wait until all previously loaded tankers have been deberthed (i.e., those
Tug Operation
area.
When there is no tanker in the harbour waiting to be berthed and the berths are not empty, the tug
again embarks on a return trip to the berthing area without a tanker in tow. However, in this modified
case, if a tanker arrives in the harbour and the tug has not yet completed 70% of its journey back to the
berths or if there is no tanker waiting to be deberthed, the harbor master will instruct the tug to return to
the harbour entrance to start berthing the newly arrived tanker.
Storms
storm is over, the tug resumes the operation that was underway before the storm occurred.
96
Project Goals
Parameters
RG.Berths.numBerths: The number of berths for loading tankers. The two values of interest
are three and four.
withStorm: When the value of this parameter is set to TRUE, then storms are included in the
behaviour of the model.
Experimentation
Four cases are to be considered which vary the parameters as shown in the following table.
Case
RG.Berths.numBerths
withStorm
Case 1a
3
FALSE
Case 1b
3
TRUE
Case 2a
4
FALSE
Case 2b
4
TRUE
Cases 1a and 1b can be used to determine the effect of the storm on the port with 3 berths.
Cases 2a and 2b can be used to determine the effect of the storm on the port with 4 berths.
Cases 1a and 2a can be used for showing the effect of adding a berth when no storm is present.
Cases 1b and 2b can be used for showing the effect of adding a berth when no storm is present.
Output
tanker is waiting to be towed to berths or waiting to be towed back to the harbour entrance. Wait
times during storms are also included in the total wait times. In the ideal case, these subtasks
would be initiated immediately, not be interrupted by storms and waiting time would be zero.
97

Assumptions
not required here).
When the tug is moving to the berths, after it stopped during a storm, it will never be interrupted by
an arriving tanker in the harbour unless the deberthing list is empty.
Simplifications
Structural View
harbour master.
Q.DeberthingList
R.Tug
RG.Berths
Q.BerthingList
Legend
iC.Tanker
Entity Categories
deberthing.
harbour and berths.
98
Notes:
Behavioural View
TankerArrival
Berthing
MoveToHarbour
Deberthing
Berthing
MoveToBerths
Loading
Deberthing

Actions:
arrival, tanker attribute values are assigned and the tanker instance is placed into the Q.BerthingList
entity.
Activities:
Berthing: This activity represents the Tug entity towing an empty Tanker entity from the harbour to
the berths. This activity can be interrupted by a storm.
Deberthing: This activity represents the Tug entity towing a loaded Tanker entity from the berths to
the harbour (at which point the Tanker entity leaves the model).
entity in tow and may suffer an interruption if a Tanker arrives in the habour before the Tug reaches
the Berths.
entity in tow.
Loading: This activity represents the loading of a Tanker. This is a sequel activity and is initiated at
the completion of the Deberthing activity.
Storm: This scheduled activity provides the means for implementing the policy of the port
authority with respect to the tugs operation when a storm occurs. This activity updates the
99
value of the exogenous input variable uStorm which assumes the value TRUE when the storm is
present and FALSE otherwise.
The Berthing, Deberthing MoveToBerths, ReturnToHarbour and MoveToHarbour can all be
interrupted by a storm when the tug must drop anchor and wait for the storm to finish. The
MoveToBerths activity can also be interrupted by a tanker that arrives before the activity terminates.
Input
Description
Domain Sequence
Variable
Name
uTnkr

tankers.
uStorm
The domain sequence of

this sample discrete variable
models the times at which
the storms start. Its range
gives the duration of the
storm.
The input variable that
indicates the presence of a
storm in the port.
Variable Name
iC.Tanker.uSize
uLoadTime
RVP.DuTnkr()

each arrival time.
Exogenous Input (Environment Variable)

Description
Domain Sequence
Procedure
Variable
Name
uStormT
Range Sequence
Range Sequence
Procedure
RVP.DuStormTiming()
RVP.RuStormTiming()
Sequence <t1, t2, t3, tn>

ti is given the values of
CSD[uStromT] for i odd
ti is given the values in the
sequence
<D[uStormT(tk)]+R[uStormT(tk)]:
k = 1, 2, 3, >, for i even
where D[uStormT(tk)] is the value
of the domain value of uStormT at
tk and R[uStormT(tk)] is the range
value of uStormT at tk.
FALSE at t0 = 0
TRUE for ti, i odd
FALSE for ti, i even.

Description
Loading time for a tanker. The
loading time depends on the size of
the tanker.
100
That is alternates between

TRUE and FALSE:
<FALSE, TRUE, FALSE,
>
Value(s)
RVP.uTankerSize()
RVP.uLoadTime(size)

Constants
Description
Name
BERTH_TIME
DEBERTH_TIME
EMPTY_TIME

Name
Parameters
Description
RG.Berths.numBerths
withStorm

Indicates if storms are included in model behaviour.
Value
1 hour
2 hours
0.25 hour
Values
3 and 4
TRUE,
FALSE

Attributes
uSize
startWait
totalWait
Description
Resource Unary: Tug

This resource entity structure represents the tugboat that is needed to berth tankers that arrive in the
harbour and to deberth tankers that have finished loading.
Attributes
status
startTime
tnkr
travelTime
anchored
startMoveToBerths
returnToHarbour
timeReturnHarbour
Description
BERTHING - berthing a tanker,
DEBERTHING - deberthing a tanker,
TO_HARBOUR - going to the harbour with no tanker in tow,
TO_BERTHS - going to berth area with no tanker in tow
PAUSE_H - in the harbour ready for the next task,
PAUSE_B - in the berth area ready for the next task.
Time stamp indicating the time the tug begins any one of the following activities:
Berthing, Deberthing, MoveToBerths, MoveToHarbour, ReturnToHarbour. All
these activities may be interrupted.
Reference to a tanker in two (the icTanker entity must be referenced when
activities are interrupted by storms).
The time required to complete the task currently being carried out by the tug.
Set to TRUE when the tug was stopped (i.e. is anchored) by the storm and FALSE
otherwise. This attribute is used to re-initiate an activity that is interrupted by a
storm.
Use to record the time a MoveToBerths activity is first started before any
interruptons by a storm may have occurred. This attribute and the next 2 attributes
are required to deal with 2 different interruptions possible with the MoveToBerths
activity.
Set to TRUE when the tug was interrupted by the arrival of a Tanker in the habour
and it has not reached the Berths yet (see MoveToBerths interruptions).
Set to time required to return to harbour after MoveToBerths has been interrupted
and 0 when MoveToBerths has not been interrupted.
101

Attributes
list
n
numBerths
Description

Attributes
Description
list
n

Attributes
Description
Discipline: FIFO.
list
n
Time units: Hours
Action: Initialise
TimeSequence
Event SCS
<0>
R.Tug.anchored FALSE
R.Tug.returnToHarbour FALSE
uStorm FALSE
RG.Berths.n 0
Q.BerthingList.n 0
Output
Name
TRJ[RG.Berths.n]
Name
Name
avgOccBerths
avgWaitTime
OUTPUTS
Description
Sample Sequences
Description
Description
Output Sequence Name
Operation
TRJ[RG.Berths.n]
AVG
AVG
102

None required.
Input Constructs
Description
Name
Data Model
RVP.uLoadTime(Size)
The returned value is the loading

time for a tanker entity instance. It is
assigned according to the tanker's
size; i.e., SMALL, MEDIUM or
LARGE).
Each of the data models is UNIFORM(Min, Max) where min

and max take on the following values (in hours) according to
the tanker size.
Size
Min
Max
RVP.uTankerSize()

tanker entity instance; value is
one of SMALL, MEDIUM or
LARGE.
The return value gives the times
at which storms start. The time
set is empty when withStorm is
set to FALSE.
The percentage of SMALL, MEDIUM and LARGE

arriving tankers is given in the following table.
RVP.DuTnkr()
RVP.DuStormTiming()
Size SMALL
MEDIUM
LARGE
Percent PERSML=25% PERMED=25% PERLRG= 50%

When withStorm = FALSE < >, i.e. the empty
sequence.
When withStorm = TRUE, the time values from the
sequence of inter-arrvials times are determined from
the inter-arrival times with:
EXP(LAMBDA, MIN_STORM_ARR)
RVP.RuStormTiming()
where LAMBDA = 1/(8 hours) and

MIN_STORM_ARR = 20 hours (location parameter
for the exponential distribution). The start of the first
storm is defined by an inter-arrival time from t=0.
The mean of the exponential distribution is 8 + 20 =
28 hours.
UNIFORM(MIN_SDUR, MAX_SDUR)
Where MIN_SDUR = 2, MAX_SDUR = 6
The procedure provides values

for the duration of the storm.
Event SCS
Activity: Storm
This activity specifies storm behaviour. RVP.DuStormTiming() does not provide any times when
withStorm is set to FALSE; in this case uStorm is never set to TRUE. The input variable uStorm is
initialised to FALSE by the Initialise action.
TimeSequence RVP.DuStormTiming()
Event SCS
uStorm TRUE
Duration
RVP.RuStormTiming()
Event SCS
uStorm FALSE
103
This activity represents the Tug entity towing a loaded Tanker entity from the berths to the
harbour (at which point the Tanker entity leaves the model).
Precondition
(uStorm = FALSE) AND
(
((R.Tug.status = PAUSE_B) AND (Q.DeberthingList.n 0))
OR
((R.Tug.anchored = TRUE) AND (R.Tug.status = DEBERTHING))
)
Event SCS
IF(R.Tug.status = PAUSE_B)
R.Tug.tnkr iC.Tanker
R.Tug.status DEBERTHING
R.Tug.travelTime DEBERTH_TIME
ELSE
iC.Tanker R.Tug.tnkr
ENDIF
(Update totalWait)
R.Tug.startTime t
Duration
R.Tug.travelTime
Interruption
Precondition
R.Tug.anchored = TRUE
Event
R.Tug.travelTime - t - R.Tug.startTime
R.Tug.anchored TRUE
R.Tug.tnkr.startWait t
SP.Terminate()
Event SCS
SP.Put(PHI[iC.Tanker.totalWait], iC.Tanker.totalWait)
SP.Leave(iC.Tanker)
104
Activity: Berthing
This activity represents the Tug entity towing an empty tanker entity from the harbour to the
berths. Note that the availability of an empty berth is implicit in the fact that the tug is located in
the harbour.
Precondition
(
((R.Tug.status = PAUSE_H) AND (Q.BerthingList.n > 0))
OR
((R.Tug.anchored = TRUE) AND (R.Tug.status = BERTHING))
)
Event SCS
IF(R.Tug.status = PAUSE_H)
R.Tug.status BERTHING
R.Tug.tnkr iC.Tanker
R.Tug.travelTime BERTH_TIME
ELSE
iC.Tanker R.Tug.tnkr
ENDIF
R.Tug.startTime t
Duration
R.Tug.travelTime
Interruption
Precondition uStorm = TRUE
Event SCS
R.Tug.anchored TRUE
SP.Terminate()
Event SCS
105
This activity represents the Tug entity moving to the harbour area with no Tanker entity in
tow. This activity can be intiated after an interruption: either an interruption of the
MoveToBerths activity (while moving to the berth area without a tanker in tow, is required to
return to the harbor because an empty tanker has arrived) or an interruption of the
MoveToHarbour activity by a storm.
Precondition
(
( (R.Tug.status = PAUSE_B) AND (Q.DeberthingList.n = 0) AND
(RG.Berths.n < RG.Berths.numBerths) )
OR
((R.Tug.anchored = TRUE) AND (R.Tug.Status = TO_HARBOUR))
OR
(R.Tug.returnToHarbour = TRUE)
)
Event SCS
IF(R.Tug.status = PAUSE_B)
R.Tug.status TO_HARBOUR
R.Tug.travelTime EMPTY_TIME
ELSE IF(R.Tug.anchored = TRUE)
R.Tug.anchored = FALSE
ELSE
(Must be because returnToHarbour is true)
R.Tug.returnToHarbour = FALSE
ENDIF
R.Tug.startTime t
Duration
R.Tug.travelTime
Interruption
Event SCS
R.Tug.anchored TRUE
SP.Terminate()
Event SCS
106
This activity represents the Tug entity moving to the berths area with no Tanker entity in tow. .
Precondition
(
( (R.Tug.status = PAUSE_H) AND (Q.BerthingList.n = 0) AND (RG.Berths.n > 0) )
OR
((R.Tug.anchored = TRUE) AND (R.Tug.status = TO_BERTHS))
)
Event SCS
IF(R.Tug.status = PAUSE_H)
R.Tug.status TO_BERTHS
R.Tug.travelTime EMPTY_TIME
R.Tug.startMoveToBerths t (Time activity started before any interruptions)
R.Tug.timeReturnHarbour 0
ELSE
R.Tug.anchored = FALSE
ENDIF
R.Tug.startTime t (Time activity started or resumed after an interruption)
Duration
R.Tug.travelTime
Interruption
Precondition (Q.BerthingList.n > 0) AND
(The following cannot become true after an interruption by a storm unless
the deberthing list is empty)
( ((t-R.Tug.startMoveToBerths) < 0.7 * EMTPY_TIME) OR (Q.DeberthingList.n = 0) )
Event SCS
IF (R.Tug.timeReturnHarbour = 0) (Activity has not been interrupted by storm)
R.Tug.travelTime (t R.Tug.startTime)
ELSE
R.Tug.travelTime R.Tug.timeReturnHarbour
ENDIF
R.Tug.status TO_HARBOUR
R.Tug.returnToHarbour TRUE
SP.Terminate()
Interruption
Event SCS
IF (R.Tug.timeReturnHarbour = 0) (First time interrupted by storm)
R.Tug.timeReturnHarbour t - R.Tug.startTime
ENDIF
R.Tug.anchored TRUE
SP.Terminate()
Event SCS
Activity: Loading
This activity represents the loading of a Tanker. This is a sequel activity and is
initiated at the completion of the Deberthing activity
Causal
(iC.Tanker)
Event SCS
Duration
Event SCS
107

Trace Logging
number of tanker referenced in the two queues (Q
.BerthingList, Q.DeberthingList) and in the
resource group (RG.Berths). These values are presented on a single line as follows:
Clock: xxxxxxx uStorm: xx Q.BerthingList.n: xx Q.DeberthingList.n: xx RG.Berths.n: xx
R.Tug(status: xx anchored: xx startMoveToBerths: xx timeReturnHarbour: xx)
108
Simulation Model
ABCmod Construct
iC.Tanker
RG.Berths
Q.BerthingList
Q.DeberthingList
Entity Structures
Java Class
Tanker
Berths
Notes:
class.
attribute.
Notes
Object References
PortVer3.rgBerths
Actions/Activities
ABCmod Constructs
TankerArrivals
Deberthing
Berthing
MoveToHarbour
MoveToBerths
Loading
Storm
Java Classes
TankerArrivals
Deberthing
Berthing
MoveToHarbour
MoveToBerths
Loading
Storm
109
TRJ[RG.Berths.n] implemented as the OutputSequence object referenced by trjRGBethsN and the
phiICTankerTotalWait. The method updateSequences in this class provides the means to update
the trajectory sequence and is called by the method eventOccured (PortVer3 class).
RVPs.
various RVPs.
All public methods provided by the class AOSimulation (e.g. runSimulation) for supporting
experimentation.
110

Case 1a (RG.Berths.numBerths = 3, withStorms = false)
harbour when a tanker arrives. Given that the activity is an extended activity, it also ends up on the
esbl. Note also that the Storm activity is not scheduled, given that the parameter withStorm is set
to false which sets the characterising sequence of the uStorm variable to the empty sequence.
Case 1a: Number of berths = 3, Storms: false
Clock: 0.000
uStorm: false Q.BerthingList.n 0 Q.DeberthingList 0 RG.Berths.n 0
R.Tug(status: PAUSE_B travelTime: 0.000
startTime: 0.000
startMoveToBerths: 0.000
timeReturnHarbour: 0.000
anchored: false)
---------------------------------ESBL------------------------------Clock: 0.000
R.Tug(status: TO_HARBOUR travelTime: 0.250
startTime: 0.000
anchored: false)
---------------------------------ESBL---------TimeStamp:0.25 Activity/Action: portModelV3.MoveToHarbour
----------------------
Once the MoveToHarbour activity completes, then a Berthing activity is initiated. Note the value of
the travelTime and startTime attributes.
---------------------Clock: 0.250
R.Tug(status: BERTHING travelTime: 2.000
startTime: 0.250
anchored: false)
---------------------------------ESBL---------TimeStamp:2.25 Activity/Action: portModelV3.Berthing
----------------------
---------------------Clock: 0.434
startTime: 0.250
anchored: false)
111
initiated (note the Loading activity is not placed on the esbl). Note also that the MoveToHarbour
activity is initiated to move the tug back to the harbour to get a waiting tanker.
---------------------Clock: 2.250
startTime: 2.250
anchored: false)
----------------------
---------------------Clock: 4.500
startTime: 2.500
anchored: false)
---------------------------------ESBL-------------------------------
---------------------Clock: 7.940
startTime: 7.940
anchored: false)
---------------------Clock: 9.940
startTime: 7.940
anchored: false)
---------------------------------ESBL-------------------------------
112
When a Loading activity terminates, the Deberthing activity is initiated, thus removing the tanker
from RG.Berths.
---------------------Clock: 14.080
R.Tug(status: DEBERTHING travelTime: 1.000
startTime: 14.080
anchored: false)
---------------------------------ESBL---------TimeStamp:15.079704659525305 Activity/Action: portModelV3.Deberthing
----------------------
When the RG.Berths is full, the tug remains at the berths (i.e. no MoveToHarbour activity is initiated
upon arrival of a tanker).
---------------------Clock: 48.588
startTime: 46.588
anchored: false)
---------------------------------ESBL------------------------------Clock: 51.058
startTime: 46.588
anchored: false)
---------------------------------ESBL-------------------------------
113
---------------------Clock: 54.291
startTime: 54.291
anchored: false)
---------------------Clock: 55.291
startTime: 55.291
anchored: false)
---------------------Clock: 57.291
startTime: 55.291
anchored: false)
---------------------------------ESBL-------------------------------
where a larger number of tankers were waiting in the harbour.
---------------------Clock: 183.088
startTime: 171.477
anchored: false)
---------------------------------ESBL------------------------------Clock: 183.645
startTime: 183.645
anchored: false)
----------------------
114
---------------------Clock: 183.645
uStorm: false Q.BerthingList.n 3 Q.DeberthingList 0 RG.Berths.n
startTime: 183.645
anchored: false)
---------------------Clock: 184.476
startTime: 183.645
anchored: false)
---------------------Clock: 184.645
startTime: 184.645
anchored: false)
---------------------Clock: 186.030
startTime: 184.645
anchored: false)
---------------------Clock: 186.331
startTime: 184.645
anchored: false)
----------------------
115
The following log section shows how a TankerArrival will interrupt the MoveToBerths activity
which is replaced by the MoveToHarbour activity. Note that the arrival occurs roughly 9 minutes
to the harbour.
---------------------Clock: 2292.231 uStorm: false Q.BerthingList.n 0 Q.DeberthingList 0 RG.Berths.n 1

R.Tug(status: TO_BERTHS travelTime: 0.250
startTime: 2292.231
startMoveToBerths: 2292.231 timeReturnHarbour: 0.000
anchored: false)
startTime: 2292.345
anchored: false)
----------------------

startTime: 3350.081
anchored: false)
---------------------------------ESBL------------------------------Simulation Done time to output the results
116
Case 1b (RG.Berths.numBerths = 3, withStorms = true)
Case 1b: Number of berths = 3, Storms: true

Clock: 0.000
startTime: 0.000
anchored: false)
TimeStamp:28.100873174664354 Activity/Action: portModelV3.Storm
(starting event scheduled)
---------------------------------ESBL------------------------------Clock: 0.000
startTime: 0.000
anchored: false)
---------------------Clock: 0.250
startTime: 0.250
anchored: false)
---------------------Clock: 0.434
startTime: 0.250
anchored: false)
----------------------
117
Storms are part of the behaviour in Case 1b. The following sections of code show how the Storm
activity modifies the uStorm input variable.
The following section of the log shows how the starting and terminating events of the Storm activity
are scheduled and their effect on the value of the uStorm input variable. The following example does
not include any interruption of an activity by the storm.
---------------------Clock: 86.856
R.Tug(status: PAUSE_H travelTime: 1.000
startTime: 85.856
anchored: false)
------------SBL---------TimeStamp:89.16412861169447 Activity/Action: portModelV3.Storm
---------------------------------ESBL------------------------------Clock: 89.164
uStorm: true Q.BerthingList.n 0 Q.DeberthingList 0 RG.Berths.n 0
startTime: 85.856
anchored: false)
(terminating event scheduled)
---------------------------------ESBL------------------------------Clock: 91.928
startTime: 85.856
anchored: false)
---------------------------------ESBL-------------------------------
118
The following section of the log shows how a storm interrupts the Berthing activity. Note the
changes in the values of the uStorm input variable and the various attributes. Berthing is resumed
when the storm has passed (uStorm becomes false); it is scheduled using the time saved in the
travelTime attribute). The log shows similar behaviour when the activities MoveToHarbour and
Deberthing activities.
---------------------Clock: 113.643
startTime: 112.642
anchored: false)
---------------------Clock: 114.214
startTime: 112.642
anchored: true)
---------------------------------ESBL------------------------------Clock: 118.350
startTime: 112.642
anchored: true)
---------------------------------ESBL------------------------------Clock: 119.373
startTime: 119.373
anchored: false)
----------------------
119

Interruption of the Deberthing activity:
---------------------Clock: 916.975
startTime: 916.152
anchored: true)
---------------------------------ESBL------------------------------Clock: 918.312
startTime: 916.152
anchored: true)
---------------------------------ESBL------------------------------Clock: 921.962
startTime: 921.962
anchored: false)
Interruption of the MoveToHarbour activity:
---------------------Clock: 1256.035 uStorm: true Q.BerthingList.n 1 Q.DeberthingList 1 RG.Berths.n 1

startTime: 1255.075
anchored: true)
---------------------------------ESBL------------------------------Clock: 1258.022 uStorm: false Q.BerthingList.n 1 Q.DeberthingList 1 RG.Berths.n 1
startTime: 1258.022
anchored: false)
-------------------------------------------
120
The MoveToBerths can be interrupted by the arrival of a storm and also the arrival of a Tanker in the
harbour. It was necessary to examine the logs of several simulation runs to find all situations for the
interruption of the MoveToBerths activity.
The following log shows how the MoveToBerths is resumed after it is interrupted by a storm. In this
situation, the precondition to have the tug return to the harbour does not exist after the the storm. See
the discussion on the logs for Case 2b for confirmation of other behaviour related to the interruption
of the MoveToBerths activity.
---------------------Clock: 678.690
startTime: 678.690
anchored: false)
---------------------Clock: 678.876
startTime: 678.690
anchored: true)
---------------------------------ESBL------------------------------Clock: 681.838
startTime: 678.690
anchored: true)
---------------------------------ESBL------------------------------Clock: 682.953
startTime: 682.953
anchored: false)
----------------------
121
The following log shows how the MoveToBerths it transformed to a MoveToHarbour activity is
resumed after the MoveToBerths activity is interrupted by a storm. In this situation, the precondition
to have the tug return to the harbour is true since the Q.DeberthingList is empty and a tanker is
present in the harbour (i.e. Q.BethingList is not empty).
---------------------Clock: 818.359
startTime: 818.359
anchored: false)
---------------------Clock: 818.449
startTime: 818.359
anchored: true)
---------------------------------ESBL------------------------------Clock: 818.689
startTime: 818.359
anchored: true)
---------------------------------ESBL------------------------------Clock: 823.995
startTime: 823.995
anchored: false)
----------------------
122
startTime: 3354.095
anchored: false)
123
Case 2a (RG.Berths.numBerths = 4 withStorms = false)

The log shows the same basic operation as for the other cases.
Case 2a: Number of berths = 4, Storms: false
Clock: 0.000
startTime: 0.000
anchored: false)
---------------------------------ESBL------------------------------Clock: 0.000
startTime: 0.000
anchored: false)
---------------------Clock: 0.250
startTime: 0.250
anchored: false)
---------------------Clock: 0.434
startTime: 0.250
anchored: false)
----------------------
The log shows up to 4 tankers berthed and loading.

---------------------Clock: 53.308
startTime: 51.308
anchored: false)
---------------------------------ESBL-------------------------------
124
startTime: 3357.081
anchored: false)
125
Case 2b (RG.Berths.numBerths = 4 withStorms = true)

The log shows the same basic operation as for the other cases.
Case 2b: Number of berths = 4, Storms: true
Clock: 0.000
startTime: 0.000
anchored: false)
---------------------------------ESBL------------------------------Clock: 0.000
startTime: 0.000
anchored: false)
---------------------Clock: 0.250
startTime: 0.250
anchored: false)
---------------------Clock: 0.434
startTime: 0.250
anchored: false)
----------------------
126
The log for Case 2b showed other behaviour related to the interruption of the MoveToBerths activity.
The following shows how MoveToBerths was resumed after a storm interruption and not returned to
the harbour since preconditions do not exist (the DeberthingList is not empty).
startTime: 1705.552
anchored: false)
startTime: 1705.552
anchored: true)
---------------------...
startTime: 1705.552
anchored: true)
---------------------------------ESBL------------------------------Clock: 1709.801 uStorm: false Q.BerthingList.n 2 Q.DeberthingList 1 RG.Berths.n 3
startTime: 1709.801
anchored: false)
----------------------
127
startTime: 3359.522
anchored: false)
128

time by applying Welchs method, and then develop some experimentation to define a suitable right
0, 1, 3 and for the avgWaitTime output variable with window sizes of 0, 3, 5, and 10. Case 1b (3 berths
with storms) was used.
2.5
2
1.5
1
0.5
0
1
10
11
12
13
14
15
Week
2.5
2
1.5
1
0.5
0
1
10
11
12
13
14
Week
2.5
2
1.5
1
0.5
0
1
10
11
12
13
14
15
Week
129
15
10
11
12
13
14
15
18
16
14
12
10
8
6
4
2
0
14
12
10
8
6
4
2
0
1
Week
12
10
8
6
4
2
0
2
10
11
12
13
14
15
12
13
14
15
10
11
12
13
14
15
14
8
Week
14
12
10
8
6
4
2
0
1
10
11
Week
Week
averages (see Figure 20, W = 0), the graph is relatively smooth. This result can be attributed to the small size of
the group (namely 3 or 4) which results in the available berths being quickly filled by the first few arrivals of
tankers.
of 7 weeks was selected for futher experimentation.
The following figures shows the graphs for the other cases and demonstrates that a warm up time of 7 weeks is
suitable for all cases.
7
6
5
4
3
2
1
0
1
10
Week
Figure 22 Applying Welchs Method for Case 1a (3 berths, no storms)
130
11
12
13
14
15
2.5
2
1.5
1
0.5
0
1
10
11
12
13
14
2.5
2
1.5
1
0.5
0
15
Week
10
11
12
13
14
15
12
13
14
15
Week
Figure 23 Applying Welchs Method for Case 2a (4 berths, no storms)
2
1.5
1
0.5
0
1
10
11
12
13
14
15
2.5
Week
4.5
4
3.5
3
2.5
2
1.5
1
0.5
0
1
10
11
Week
Figure 24 Applying Welchs Method for Case 2b (4 berths, no storms)
period.
interval with number of simulation runs ranging from 20 runs to 80 runs. The results of the experimentation are
shown below.
The output for the Average Tanker Total Wait for Case 1b (3 berths with storms) shows that a 40
week observation interval with 30 simulation runs is required to provide a good confidence interval.
Thus a 40 week observation interval with 30 simulation runs is chosen for experimentation with all cases
to solve the modelling and simulation problem.
Number of berths: 3
End Time = 20 weeks
End Time = 30 weeks
End Time = 40 weeks
Number of berths: 3
End Time = 20 weeks
End Time = 30 weeks
End Time = 40 weeks
Number of berths: 4
End Time = 20 weeks
End Time = 30 weeks
End Time = 40 weeks
Number of berths: 4
End Time = 20 weeks
End Time = 30 weeks
End Time = 40 weeks
With Storms: false

(3360.0 hours), TimeStamp:
With Storms: true
With Storms: false
With Storms: true
15:17:00
15:17:01
15:17:02
15:17:03
15:17:04
15:17:06
15:17:07
15:17:08
15:17:09
15:17:10
15:17:11
15:17:12
131
+--------+------------------------------------+------------------------------------+------------------------------------+
|
Number of berths 3 With Storms: false
|
+--------+------------------------------------+------------------------------------+------------------------------------+
|
tf: |
20 weeks
|
30 weeks
|
40 weeks
|
+--------+------------------------------------+------------------------------------+------------------------------------+
+--------+------------------------------------+------------------------------------+------------------------------------+
|
n
| yb(n)
s(n)
s(n)
s(n)
z(n) z(n)/yb(n)|
+--------+------------------------------------+------------------------------------+------------------------------------+
+--------+------------------------------------+------------------------------------+------------------------------------+
|
|
+--------+------------------------------------+------------------------------------+------------------------------------+
|
20 |
1.800
0.083
0.045
0.0251 |
1.821
0.086
0.047
0.0257 |
1.826
0.066
0.036
0.0196 |
|
30 |
1.809
0.089
0.038
0.0212 |
1.820
0.083
0.036
0.0196 |
1.817
0.066
0.029
0.0157 |
|
40 |
1.807
0.089
0.033
0.0181 |
1.815
0.082
0.030
0.0167 |
1.817
0.066
0.024
0.0134 |
|
60 |
1.809
0.092
0.027
0.0151 |
1.815
0.084
0.025
0.0138 |
1.819
0.069
0.020
0.0112 |
|
80 |
1.824
0.095
0.024
0.0133 |
1.825
0.082
0.021
0.0115 |
1.826
0.065
0.017
0.0092 |
+--------+------------------------------------+------------------------------------+------------------------------------+
+--------+------------------------------------+------------------------------------+------------------------------------+
|
|
+--------+------------------------------------+------------------------------------+------------------------------------+
|
20 |
7.361
2.073
1.128
0.1532 |
7.383
1.628
0.886
0.1200 |
7.389
1.490
0.811
0.1097 |
|
30 |
7.593
2.529
1.092
0.1438 |
7.610
1.913
0.826
0.1085 |
7.366
1.593
0.688
0.0934 |
|
40 |
7.260
2.428
0.895
0.1233 |
7.282
1.825
0.673
0.0924 |
7.138
1.555
0.573
0.0803 |
|
60 |
7.127
2.255
0.670
0.0940 |
7.071
1.781
0.529
0.0748 |
7.088
1.445
0.429
0.0606 |
|
80 |
7.350
2.460
0.628
0.0855 |
7.200
1.855
0.474
0.0658 |
7.152
1.490
0.381
0.0532 |
+--------+------------------------------------+------------------------------------+------------------------------------+
+--------+------------------------------------+------------------------------------+------------------------------------+
+--------+------------------------------------+------------------------------------+------------------------------------+
|
Number of berths 3 With Storms: true
|
+--------+------------------------------------+------------------------------------+------------------------------------+
|
tf: |
20 weeks
|
30 weeks
|
40 weeks
|
+--------+------------------------------------+------------------------------------+------------------------------------+
+--------+------------------------------------+------------------------------------+------------------------------------+
|
n
| yb(n)
s(n)
s(n)
s(n)
z(n) z(n)/yb(n)|
+--------+------------------------------------+------------------------------------+------------------------------------+
+--------+------------------------------------+------------------------------------+------------------------------------+
|
|
+--------+------------------------------------+------------------------------------+------------------------------------+
|
20 |
1.861
0.087
0.048
0.0255 |
1.882
0.089
0.049
0.0258 |
1.888
0.068
0.037
0.0196 |
|
30 |
1.871
0.092
0.040
0.0213 |
1.882
0.086
0.037
0.0197 |
1.879
0.068
0.029
0.0156 |
|
40 |
1.869
0.092
0.034
0.0182 |
1.878
0.085
0.031
0.0167 |
1.880
0.068
0.025
0.0134 |
|
60 |
1.871
0.095
0.028
0.0151 |
1.878
0.088
0.026
0.0139 |
1.883
0.071
0.021
0.0112 |
|
80 |
1.887
0.099
0.025
0.0134 |
1.889
0.086
0.022
0.0117 |
1.890
0.068
0.017
0.0092 |
+--------+------------------------------------+------------------------------------+------------------------------------+
+--------+------------------------------------+------------------------------------+------------------------------------+
|
|
+--------+------------------------------------+------------------------------------+------------------------------------+
|
20 | 10.923
3.120
1.698
0.1554 | 11.088
2.605
1.417
0.1278 | 11.104
2.396
1.304
0.1174 |
|
30 | 11.298
3.944
1.702
0.1506 | 11.465
2.957
1.276
0.1113 | 11.114
2.524
1.089
0.0980 |
|
40 | 10.843
3.753
1.383
0.1276 | 10.980
2.811
1.036
0.0944 | 10.858
2.464
0.908
0.0837 |
|
60 | 10.646
3.480
1.033
0.0971 | 10.704
2.797
0.830
0.0776 | 10.768
2.274
0.675
0.0627 |
|
80 | 11.009
3.800
0.971
0.0882 | 10.952
2.928
0.748
0.0683 | 10.945
2.354
0.601
0.0550 |
+--------+------------------------------------+------------------------------------+------------------------------------+
+--------+------------------------------------+------------------------------------+------------------------------------+
132
+--------+------------------------------------+------------------------------------+------------------------------------+
|
Number of berths 4 With Storms: false
|
+--------+------------------------------------+------------------------------------+------------------------------------+
|
tf: |
20 weeks
|
30 weeks
|
40 weeks
|
+--------+------------------------------------+------------------------------------+------------------------------------+
+--------+------------------------------------+------------------------------------+------------------------------------+
|
n
| yb(n)
s(n)
s(n)
s(n)
z(n) z(n)/yb(n)|
+--------+------------------------------------+------------------------------------+------------------------------------+
+--------+------------------------------------+------------------------------------+------------------------------------+
|
|
+--------+------------------------------------+------------------------------------+------------------------------------+
|
20 |
1.812
0.087
0.047
0.0260 |
1.833
0.089
0.048
0.0264 |
1.838
0.067
0.036
0.0198 |
|
30 |
1.822
0.093
0.040
0.0221 |
1.831
0.086
0.037
0.0203 |
1.828
0.067
0.029
0.0158 |
|
40 |
1.819
0.093
0.034
0.0188 |
1.826
0.086
0.032
0.0173 |
1.828
0.067
0.025
0.0136 |
|
60 |
1.821
0.096
0.028
0.0156 |
1.825
0.087
0.026
0.0142 |
1.830
0.071
0.021
0.0115 |
|
80 |
1.836
0.097
0.025
0.0136 |
1.836
0.084
0.022
0.0117 |
1.836
0.067
0.017
0.0094 |
+--------+------------------------------------+------------------------------------+------------------------------------+
+--------+------------------------------------+------------------------------------+------------------------------------+
|
|
+--------+------------------------------------+------------------------------------+------------------------------------+
|
20 |
2.565
0.590
0.321
0.1252 |
2.549
0.459
0.250
0.0979 |
2.555
0.382
0.208
0.0814 |
|
30 |
2.634
0.676
0.292
0.1108 |
2.591
0.511
0.220
0.0850 |
2.533
0.403
0.174
0.0688 |
|
40 |
2.527
0.647
0.239
0.0945 |
2.516
0.475
0.175
0.0696 |
2.463
0.382
0.141
0.0572 |
|
60 |
2.512
0.602
0.179
0.0712 |
2.472
0.443
0.131
0.0532 |
2.444
0.358
0.106
0.0435 |
|
80 |
2.512
0.578
0.148
0.0588 |
2.473
0.425
0.109
0.0439 |
2.434
0.346
0.089
0.0364 |
+--------+------------------------------------+------------------------------------+------------------------------------+
+--------+------------------------------------+------------------------------------+------------------------------------+
+--------+------------------------------------+------------------------------------+------------------------------------+
|
Number of berths 4 With Storms: true
|
+--------+------------------------------------+------------------------------------+------------------------------------+
|
tf: |
20 weeks
|
30 weeks
|
40 weeks
|
+--------+------------------------------------+------------------------------------+------------------------------------+
+--------+------------------------------------+------------------------------------+------------------------------------+
|
n
| yb(n)
s(n)
s(n)
s(n)
z(n) z(n)/yb(n)|
+--------+------------------------------------+------------------------------------+------------------------------------+
+--------+------------------------------------+------------------------------------+------------------------------------+
|
|
+--------+------------------------------------+------------------------------------+------------------------------------+
|
20 |
1.878
0.089
0.048
0.0257 |
1.899
0.094
0.051
0.0269 |
1.906
0.071
0.039
0.0202 |
|
30 |
1.891
0.096
0.042
0.0220 |
1.901
0.091
0.039
0.0205 |
1.898
0.071
0.031
0.0162 |
|
40 |
1.888
0.095
0.035
0.0186 |
1.896
0.090
0.033
0.0174 |
1.898
0.071
0.026
0.0139 |
|
60 |
1.891
0.100
0.030
0.0157 |
1.896
0.092
0.027
0.0143 |
1.901
0.075
0.022
0.0118 |
|
80 |
1.907
0.103
0.026
0.0138 |
1.908
0.090
0.023
0.0120 |
1.909
0.072
0.018
0.0096 |
+--------+------------------------------------+------------------------------------+------------------------------------+
+--------+------------------------------------+------------------------------------+------------------------------------+
|
|
+--------+------------------------------------+------------------------------------+------------------------------------+
|
20 |
4.502
0.806
0.439
0.0974 |
4.453
0.631
0.343
0.0771 |
4.491
0.509
0.277
0.0617 |
|
30 |
4.578
0.877
0.379
0.0827 |
4.574
0.722
0.312
0.0681 |
4.515
0.584
0.252
0.0558 |
|
40 |
4.469
0.838
0.309
0.0691 |
4.505
0.668
0.246
0.0547 |
4.441
0.548
0.202
0.0455 |
|
60 |
4.472
0.823
0.244
0.0547 |
4.448
0.632
0.188
0.0422 |
4.423
0.516
0.153
0.0347 |
|
80 |
4.506
0.834
0.213
0.0473 |
4.468
0.620
0.158
0.0354 |
4.419
0.502
0.128
0.0290 |
+--------+------------------------------------+------------------------------------+------------------------------------+
+--------+------------------------------------+------------------------------------+------------------------------------+
133
Experimentation
The table on the next page shows the output of the simulation runs for both cases. The following 10
confidence intervals were generated to meet the project goal (2 confidence intervals are created for each
of the following one for each of the output variables):
1) Case 1a to get base point estimate values for each output variable;
2) Difference between Case 1a and Case 1b: to see the effect of the storm on the port with three berths ;
3) Difference between Case 2a and Case 2b: to see the effect of the storm on the port with three berths;
4) Difference between Case 1a and Case 2a: to see the effect of adding a berth with no storms;
5) Difference between Case 1b and Case 2b: to see the effect of adding a berth with storms.
Given that 10 confidence intervals are used to compare the various cases, an individual confidence
level of Ck = 0.98 (=1-((1-0.8)/10)) to achieve an overall confidence level of 0.8. The following table
was generated with the experimentation program found in class PortV3Exp3. It was necessary to
increase the number of runs to 40 and the observation interval to 60 weeks to ensure that all confidence
intervals related to the average tanker wait time met the 10% criterion. As for the average number of
occupied berths, given that values in the confidence level are so small, this does not pose any concern
Output Analysis
The table presented in the previous section shows the estimated values of the average number of
occupied berths and the average waiting time for Case 1a (3 berths with no storm); these values are
respectively 1.8 berths and 7.4 hours. The other columns shows how adding storms and or an
additional berth affects these values. All confidence intervals meet the 10% criterion. The confidence
interval information is provided at the bottom of the table. Some interpretation of the data is as follows:
1. Although the confidence intervals for the berth group size is to the right of zero in all cases, the point
estimate of the difference is so small relative to the individual point estimates we are obliged to
conclude that increasing the berth size or adding stomrs has no effect on this output variable. This is
somewhat counter-intuitive when adding a berth but is a consequence of the relative values of tanker
arrival rate, the tugs cycle time (time to deberth and berth a tanker) and the tanker loading times. For
example, if the loading times are increased, then the average berth group size does increase and vice
versa. An alternate measure that would be interesting is the percentage of time that all available
berths are occupied. The interested reader is encouraged to experiment with the simulation program
by exploring the effects of changing these various times. Closer examination of the trace log for the
two cases may provide clues on why this result is obtained.
2. As for the tanker waiting times, adding a berth and/or including storms affects the waiting time.
a. Case 1b (adding storms with 3 berths): Adding a storm increases the average tanker total wait
times by 3.7 hours. Thus with storms, tankers wait on average 11 hours. Given that wait times
include times that storms are present, an increase in waiting time is expected. The results show
that this increase is quite significant.
b. Case 2a (adding a berth, with not storms): Adding a berth clearly reduces the tanker waiting
times. The results show a decrease of 4.8 hours when compared to Case 1b. Thus tankers waiting
times are reduced to 2.6 hours, without considering the effect of storms.
c. Case 2b (adding a berth with storms), in comparision with Case 2a: When compared to Case 2a,
the average tanker wait time increases by 2 hours, which is less significant than with 3 berths.
Including this increase to the results of (b) above would lead to the conclusion that with storms,
the average tanker total wait time would be 4.6 hours.
134
d. Case 2b (adding a berth with storms), in comparision with Case 1b: The results of comparing
Case 2b to Case 1b shows a decrease of 6.6 hours and thus and average tanker waiting time of 11
6.6 = 4.5 hours; this result is the same as that given by (c).
+---------+--------+--------+--------+--------+--------++--------+--------+--------+--------+--------+
|
|
||
|
+---------+--------+--------+--------+--------+--------++--------+--------+--------+--------+--------+
|
Run
|Case 1a | 1b-1a | 2b-2a | 2a-1a | 2b-1b ||Case 1a | 1b-1a | 2b-2a | 2a-1a | 2b-1b |
+---------+--------+--------+--------+--------+--------++--------+--------+--------+--------+--------+
+---------+--------+--------+--------+--------+--------++--------+--------+--------+--------+--------+
|
1|
1.786|
0.066|
0.062|
0.009|
0.005||
5.739|
3.168|
1.771| -3.592| -4.989|
|
2|
1.925|
0.063|
0.079|
0.011|
0.027||
7.479|
4.461|
1.934| -4.881| -7.408|
|
3|
1.905|
0.065|
0.079|
0.012|
0.026||
8.449|
4.054|
2.227| -5.602| -7.430|
|
4|
1.818|
0.067|
0.072|
0.010|
0.016||
6.327|
3.152|
1.721| -4.022| -5.453|
|
5|
1.808|
0.063|
0.064|
0.001|
0.003|| 10.715|
5.588|
2.433| -7.660| -10.815|
|
6|
1.910|
0.064|
0.087|
0.013|
0.036|| 11.509|
6.282|
2.530| -8.160| -11.912|
|
7|
1.755|
0.064|
0.061|
0.008|
0.006||
5.464|
3.292|
1.669| -3.418| -5.041|
|
8|
1.758|
0.063|
0.066|
0.010|
0.014||
6.578|
3.686|
1.846| -4.183| -6.023|
|
9|
1.854|
0.065|
0.071|
0.010|
0.016||
7.577|
3.558|
2.001| -5.138| -6.694|
|
10|
1.784|
0.065|
0.073|
0.004|
0.012||
5.567|
2.783|
1.895| -3.524| -4.411|
|
11|
1.817|
0.055|
0.070|
0.005|
0.020||
6.119|
3.030|
1.859| -3.850| -5.021|
|
12|
1.819|
0.065|
0.060|
0.007|
0.001||
8.749|
4.131|
1.902| -5.836| -8.065|
|
13|
1.821|
0.058|
0.075|
0.008|
0.025||
6.891|
3.341|
1.900| -4.693| -6.134|
|
14|
1.865|
0.068|
0.073|
0.009|
0.015||
6.993|
2.886|
2.088| -4.597| -5.395|
|
15|
1.790|
0.065|
0.065|
0.007|
0.007||
7.151|
4.498|
1.890| -4.791| -7.399|
|
16|
1.925|
0.061|
0.063|
0.013|
0.014|| 10.012|
4.794|
1.922| -7.056| -9.928|
|
17|
1.776|
0.061|
0.077|
0.009|
0.025||
6.653|
3.469|
2.141| -4.339| -5.667|
|
18|
1.863|
0.072|
0.073|
0.016|
0.018||
8.486|
4.544|
2.280| -5.636| -7.901|
|
19|
1.731|
0.053|
0.061|
0.010|
0.017||
7.858|
3.532|
1.809| -5.081| -6.804|
|
20|
1.947|
0.064|
0.066|
0.015|
0.017||
8.359|
3.939|
1.824| -5.428| -7.543|
|
21|
1.864|
0.076|
0.092|
0.014|
0.029||
8.137|
4.671|
2.552| -5.526| -7.646|
|
22|
1.875|
0.061|
0.076|
0.014|
0.030||
8.056|
3.349|
2.054| -5.077| -6.372|
|
23|
1.807|
0.055|
0.077|
0.007|
0.028||
6.227|
3.336|
1.898| -4.065| -5.503|
|
24|
1.786|
0.064|
0.066|
0.016|
0.017||
7.858|
4.433|
2.004| -5.225| -7.654|
|
25|
1.693|
0.060|
0.068|
0.007|
0.016||
4.962|
2.715|
1.781| -2.850| -3.784|
|
26|
1.854|
0.074|
0.084|
0.008|
0.018||
9.500|
5.965|
2.491| -6.629| -10.103|
|
27|
1.745|
0.063|
0.068|
0.008|
0.013||
5.443|
2.554|
1.573| -3.450| -4.431|
|
28|
1.811|
0.070|
0.076|
0.005|
0.011||
6.935|
3.715|
2.064| -4.506| -6.157|
|
29|
1.875|
0.070|
0.082|
0.019|
0.031||
8.339|
3.961|
2.287| -5.640| -7.314|
|
30|
1.810|
0.060|
0.074|
0.016|
0.030||
6.777|
3.261|
2.196| -4.162| -5.228|
|
31|
1.722|
0.059|
0.066|
0.011|
0.018||
5.711|
2.690|
1.795| -3.578| -4.473|
|
32|
1.844|
0.068|
0.081|
0.017|
0.030||
9.491|
4.277|
2.302| -6.558| -8.534|
|
33|
1.849|
0.066|
0.082|
0.005|
0.022||
8.107|
5.015|
2.258| -5.710| -8.467|
|
34|
1.876|
0.069|
0.071|
0.019|
0.022||
7.046|
3.796|
1.988| -4.545| -6.352|
|
35|
1.793|
0.059|
0.071|
0.007|
0.019||
6.845|
3.555|
1.768| -4.643| -6.430|
|
36|
1.830|
0.065|
0.066|
0.011|
0.012||
6.131|
3.172|
1.747| -3.720| -5.145|
|
37|
1.787|
0.058|
0.068|
0.002|
0.012||
5.833|
2.727|
1.709| -3.690| -4.708|
|
38|
1.743|
0.075|
0.073|
0.007|
0.005||
5.271|
3.299|
2.089| -3.167| -4.377|
|
39|
1.720|
0.054|
0.063|
0.009|
0.017||
6.026|
3.094|
1.804| -3.854| -5.145|
|
40|
1.790|
0.070|
0.075|
0.008|
0.013||
5.912|
3.193|
1.895| -3.661| -4.959|
+---------+--------+--------+--------+--------+--------++--------+--------+--------+--------+--------+
+---------+--------+--------+--------+--------+--------++--------+--------+--------+--------+--------+
| ybar(n)|
1.818|
0.064|
0.072|
0.010|
0.018||
7.282|
3.774|
1.997| -4.793| -6.570|
|
s(n)|
0.060|
0.005|
0.008|
0.004|
0.008||
1.524|
0.880|
0.245|
1.214|
1.861|
| zeta(n)|
0.023|
0.002|
0.003|
0.002|
0.003||
0.584|
0.338|
0.094|
0.466|
0.714|
|CI Min(n)|
1.795|
0.062|
0.069|
0.008|
0.015||
6.698|
3.437|
1.903| -5.259| -7.284|
|CI Max(n)|
1.841|
0.066|
0.075|
0.012|
0.021||
7.867|
4.112|
2.091| -4.328| -5.857|
|zeta/ybar|
0.013|
0.033|
0.040|
0.165|
0.181||
0.584|
0.089|
0.047|
0.097|
0.109|
+---------+--------+--------+--------+--------+--------++--------+--------+--------+--------+--------+
135
Conclusions
Clearly adding storms in the model does increase the average tanker total wait times. Adding a 4th berth
improves significantly the tanker total wait times but not the average number of occupied berths (which
is not affected by the presence of storms). Adding a fourth berth does reduce waiting times in both cases
and more significantly when storms are considered. Without storms, average tanker total wait times are
reduced from 7.4 hours to 2.6 hours (a difference of 4.8 hours). When storms are considered, the average
tanker total wait times are reduced from 11 hours to 4.5 hours (a difference of 6.5 hours).
An additional modelling and simulation project can provide the following information that can
explain why the average number of occupied berths remain constant:
136

a. SMALL: 25%
b. MEDIUM: 25%
c. LARGE: 50%
following table.
Tanker Size
Minimum Parameter
Maximum Parameter
SMALL
8 hours
10 hours
MEDIUM
10 hours
14 hours
LARGE
15 hours
21 hours
4) Inter-arrival times for storms are modelled using an exponential distribution that has 2
parameters: the parameter is 1/8, and the location parameter is 20 which implies that the
inter-arrival time is at least 20 hours. The 2 parameter exponential probability distribution
1
function is defined as f ( x) e ( x ) and has a mean m and is defined for x . For
the storm interarrival times, this implies that the minimum value for inter-arrival times is = 20
hours with a mean of m = 8 + 20 = 28 hours.
5) The duration of storms are uniformly distributed between 2 and 6 hours.
137
138

CSI4124 SYS5110 CaseStudies Fall 2014 PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

CSI4124 SYS5110 CaseStudies Fall 2014 PDF

Caricato da

Copyright:

Formati disponibili

School of Electrical Engineering and Computer Science

Modelling and Simulation

ABCmod Conceptual Model................................................................................................................. 98

Case Study Overviews

Port Project (Version 3)

Sandwich and Sushi Counter

Figure 1 Kojos Kitchen Fast Food Outlet

ABCmod Conceptual Model

Figure 2 Kojos Kitchen Structural Diagram

Figure 3 Customer Life Cycle

Serving: This activity represents the serving of a customer.

Exogenous Input (Entity Stream)

1 customer arrives at each arrival.

Endogenous Input (independent)

Endogenous Input (Semi-independent)

Detailed Conceptual Model

Number of additional employees serving at the

Consumer Class: Customer

Resource/Group Unary: Counter

The group of the Customer entities that are being served.

Queue Unary: CustLine

List of the customers entities waiting in line for service.

Number of customers served.

Random Variate Procedures

Provides the values of the arrival

Provides the type of the arriving

Exponential(X) where X is:

Design of Validation Experimentation

Notes: The enumerated data type Type is

Typically by the reference

Shows the state of the model

The log shows the customer line becoming quite long.

longer than five minutes.

Alternate Case (RG.Counter.addEmp = 1)

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

Experimentation and Analysis

Annex A Data Modelling

Kojos Kitchen (Version 2)

Sandwich and Sushi Counter

Figure 4 Kojos Kitchen Fast Food Outlet

Time units are minutes.

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

ABCmod Conceptual Model

Figure 5 Kojos Kitchen Structural Diagram

Figure 6 Customer Life Cycle

Serving: This activity represents the serving of a customer.

This input entity stream

1 customer arrives at each

Endogenous Input (independent)

Endogenous Input (Semi-independent)

Detailed Conceptual Model

Employee schedule for the day that consists of a

Consumer Class: Customer

Resource Group Unary: Counter

The group of the Customer entities that are being served.

Queue Unary: CustLine

List of the customers entities waiting in line for service.

Number of customers served.

Random Variate Procedures

Provides the values of the arrival

Provides the type of the arriving

Exponential(X) where X is:

Design of Validation Experimentation