代写program、代做Python/Java语言编程

日期：2024-11-12 09:10

Decision Science: Programming Assignment

Haide College, Autumn Semester 2024

Due dates:

• Milestone (quiz): 7 November 2024, 23:59. [5% course mark]

• Submission (code): 14 November 2024, 23:59 [20% course mark]

Purpose

The purpose of this assessment is to create a fully functional simulation of a more complex system. Building

simulations is one of the key objectives of this course. You will need to be able to do this in an industry or

government job working in decision sciences. Building a simulation is also the best way to absorb and gain a

deep understanding of the ideas and topics that are discussed in this course. Even if you are just managing

simulations projects, you should have some experience in creating the simulation itself.

This is quite a large and difficult task, but the assessment will provide considerable structure.

Outcomes

This Task addresses the following Course Learning Outcomes:

• communicate how randomness and controlled variation can be used to model complex systems in a range

of application domains such as industry, health, and transportation;

• create a model of a real-world problem specified in words and implement it as a discrete-event simulation;

• validate results from a discrete-event simulation.

Scenario

You will be simulating a passport (immigration) control queuing system at an airport. This is based on the

queuing system for foreign travelers arriving at Qingdao airport.

Passengers get off their flight, walk to the passport checkpoint area and join a single primary queue. When

they get near the front of this queue they are organised into several short secondary queues. Each secondary

queue leads to a counter staffed by an attendant, who checks the passenger’s passport and clears them to their

journey.

Additional features. The airport uses some strategies to make this process more efficient. This includes:

1. extra counters open when the system is busy, and close when it is less busy

2. attendants regularly rotate so they can take breaks

3. passengers may be served at a counter not corresponding to their outside their allocated secondary queue

in some circumstances

Assumptions

You should assume the following:

• all queues operates in a First in First Out (FIFO) basis

• there are 2 counters open at the start of the simulation

• Times: all times are independent and

– The interarrival time between flights is exponential with an expected value of 45 minutes

– The number of passengers on each flight who will pass through this passport control area is uniformly

distributed between 15 and 25 passengers (similar to the number of foreign arrivals on a plane to

Qingdao)

– The transit time for a passenger to walk from the plane to the queueing system is uniformly

distributed between 5 and 30 minutes

– The service time for passengers once they reach a counter is Pareto distributed with a minimum

time of 2 minutes and an expected value of 4 minutes

The following assumptions relate to the additional features of the system.

1

• Additional feature 1. Extra counters open when the system is busy, and close when it is less busy

– Let ncounters be the number of counters currently open, and N be the total number of passengers

in the queuing system (main queue, all secondary queues and in service). An extra counter will

open if N > 10 × ncounters. A counter will close if N < 10 × (ncounters − 2).

– There are a minimum of 2 counters and a maximum of 5 counters

– When a counter “closes” this mean that no more passengers are accepted into its secondary queue.

Any passengers currently in the secondary queue will be served as usual.

• Additional feature 2. Attendants regularly rotate so they can take breaks

– Some of the counter attendants rotate at an interval of 30 minutes, during which time service at

the counter is paused for 1 minute. This means that the service time for any passenger at a rotating

counter will increase by 1 minute.

– For odd numbered counters, the first rotation is at 30 minutes from the start of the simulation

(and then every 2 × 30 = 60 minutes)

– For even numbered counters, the first rotation is at 60 minutes from the start of the simulation

(and then every 2 × 30 = 60 minutes)

• Additional feature 3. Passengers may be served at a counter not corresponding to their allocated

secondary queue in some circumstances.

– A passenger at the front of their secondary queue, who has been in their secondary queue for more

than 20 minutes will be served next at any available open counter. In the case of multiple passengers

in this situation, priority is given to the passenger who has spent the longest waiting time in their

secondary queue.

– If an open counter is available and its secondary queue is empty, they will serve a passenger from

another secondary queue. Priority is given to the passenger with the longest secondary queue

waiting time.

• The airport is open 24 hours, 7 days a week.

– The behaviour of the system is not influenced by the time of day.

• The airport has specified that they consider a single simulation running for one day of simulated time

(1440 minutes) to be sufficient for statistical relevance.

Questions

The airport’s management would like to plan for an anticipated increase in passenger numbers, as the number

of arrivals using this passport queueing system is expected to double in the next five years. They would like

to understand how best to manage their staff, if additional counters need to be built, and whether their are

any aspects of the queuing system that can be fine-tuned. Based upon passenger feedback, passengers are

concerned with total amount of time they must spend in this queuing system.

The airport’s management wish to identify the minimum number of counters that will ensure the expected

total time in the queuing system when the number of customers double is no worse than the current level.

Airport management is also concerned with the well-being of their attendants, so would like to understand how

the frequency and length of their rotation impacts passenger experience.

Note. You do not have to answer these questions as part of this assignment, but this motivates the

use of parameters so we can vary the assumptions of our model.

Your Task

This assessment is scaffolded into three parts:

• Part 1: Modelling (Module 2)

• Part 2: Programming (Module 3)

• Part 3: Verification and testing (Module 4)

The details of each part are outlined in later in this brief. It is suggested you work through each of these in

order, although there may be some back and forth between Parts 2 & 3.

2

Requirements

This assessment is worth 25% of your course mark. This is split between two parts:

Milestone online quiz (5%). Answer a series of short multiple choice/numerical answer questions to

demonstrate your understanding of the queuing model and functionality of the simulation.

• Submission requirement: Submit online quiz via Cloudcampus.

Julia code (20%). Write a simulation code in Julia according to the specification provided in this document.

There are a total of 80 marks for this part of the assessment, broken down as follows:

• Basic functionality: code implements the basic functionality of this queuing system, as per the specification.

[40 marks]

• Additional feature 1: code implements this feature correctly. [12 marks]

• Additional feature 2: code implements this feature correctly. [12 marks]

• Additional feature 3: code implements this feature correctly. [12 marks]

• Code style: submission meets general style guidelines for good Julia code. [4 marks]

All the above are detailed in the rubric at the end of this document. Here you are required to submit a single

.jl file, which contains type definitions, data structures and functions to run the simulation.

• Submission requirement: Submit Julia file via Cloudcampus.

• Submission requirement: An include command on your file must not give an error, if it does give an

you will get 0 marks (since this prevents your code from being automatically tested).

If you need clarification about any of the above, please ask course staff during workshop, via email or via the

course discussion board.

3

Part 1: Modelling

In this part, you will model the system that you will be implementing.

The system

You will be simulating a passport (immigration) control queuing system at an airport. This is based on the

queuing system for foreign travelers arriving at Qingdao airport.

See page 1 (“Scenario”) of this document for a detailed description of the system.

Tasks for Part 1

Before you commence coding you should perform a series of modelling tasks. These tasks will prepare you for

Part 2, when you will implement a simulation in Julia. You should work through these tasks and complete the

online milestone quiz. Note you are not required to submit written responses to these points.

1. Draw a schematic of the system. This can be a rough sketch on a piece of paper - this is a great way to

get an initial understanding of the system.

2. Describe the state(s) of the system.

Hint: What state details are needed to answer supermarket owner’s questions?

3. Describe the number of entities in the system in relation to the state(s).

Hint: A simple equation may be helpful in this description.

4. Assume there are four events in the simulation: passengers leaves the aircraft after landing

(FlightDisembarks), passenger arrives at queue (Arrival), passenger departs queue (Departure)

and attendants rotating for a break (for additional feature 2, RotateAttendants). For each event:

• describe how each event changes the state of the system.

• describe the new events that may be created as a result of this event.

5. Draw a state diagram, illustrating the possibly states of the system and how the state changes in response

to the various events.

6. Draw a flow chart illustrating your simulation structure.

To be clear, you will not be asked to submit written responses to the above but your understanding of these

points will be assessed via the milestone quiz (worth 5% of your course mark).

It is not possible to write a simulation code working through the above detail, so take your time here to get

some clear ideas about what you need to code before you start Part 2.

4

Part 2: Programming

In this part, you will start to program the model.

Reminder

The system to be modelled is described in page 1 of this document (“Scenario”)

Tasks for Part 2

Before starting the process of coding up your simulation, go back to your work from Part 1 and think about if

there are any further modelling details needed here. In particular you might like to carefully think about how to

model/implement the three “Additional features”.

The main task here is to write code to implement a discrete-event simulation of the system.

• The code should follow the style of some other codes presented in this course. You might like to use

these as a starting point, or perhaps find it easier to start from an empty file.

• The process you need to follow is outlined below under the heading Specification.

By the end of this part, you should have a working simulation that can output results.

In Part 3 you will test it and use it to create some data with a simulation harness.

As part of your assessment, you will be required to submit one .jl file with your code for implementing the

discrete-event simulation.

Specification

This week you will start coding your simulation. A good deal of the structure of the code is provided.

• This is to help you! There is a lot written below, but by following it carefully you will get a big start

towards developing your simulation.

• It ensure that everyone has a common starting point.

• It makes it easier to review and assess your progress by ensuring that everyone adopts the same basic

structure for their implementation.

The last point is important. Your mark is be based on automated testing of your code. Hence you must set up

your code in the manner given, paying particular attention to setting up the data types exactly as described

below, otherwise these test will fail and you will lose marks.

Here are the required specification details:

1. Filenames. Your code must be included in a single .jl files. These should be named:

• AirportOverseasPassports.jl

This should contain all of your data structures and functions. You will be provided with a file to run

this code AirportOverseasPassports_run.jl which will include the first file and run the simulation

for a set of parameters.

2. You should use the standard packages that you have been using in this course.

These include:

• DataStructures

• Distributions

• StableRNGs

• CSV

You may wish to use a small set of additional packages such as Dates or Printf.

Do not use any packages other than these or those that have been discussed in the course.

3. Your code must specify three data structures:

abstract type Event end

mutable struct Passenger

...

5

mutable struct State ...

Each will contain fields as required. The state structure should contain any queues or lists required, for

instance, the event list. More detail about each follows.

4. The abstract type Event will have the following subtypes:

• FlightDisembarks . . . an aircraft lands and unloads passengers

• Arrival . . . a passenger arrives at the queuing system

• Departure . . . a passenger finish their passport check and leaves

• RotateAttendants . . . the counter attendants take a break

Each subtype of Event must be a mutable struct and must contain the following fields (with the

types indicated):

• FlightDisembarks

– id . . . an integer valued event ID number (Int64)

– flight_id . . . the ID of the flight (Int64)

– no_passengers . . . the number of passengers from the flight that will be processed by the

queuing system, or nothing if the flight has not yet unloaded (Union{Nothing,Int64})

• Arrival

– id . . . an integer valued event ID number (Int64)

– flight_id . . . the ID of the passenger’s flight

– disembark_time . . . the time the passenger’s flight was unloaded (Float64)

– passenger_id . . . an integer valued passenger ID number, or nothing if the event does not

yet have a customer allocated (Union{Nothing,Int64})

• Departure

– id . . . an integer valued event ID number (Int64)

– passenger_id . . . the ID of the departing passenger (Int64)

– counter_id . . . the counter that serviced that serviced the passenger, or nothing if they

have not yet been served (Union{Nothing,Int64})

• RotateAttendants

– id . . . an integer valued event ID number (Int64)

– odd_attendants . . . true if odd numbered counters are rotating, false if even numbered

counters are rotating (Bool)

You may optionally define constructor functions for each of these above subtypes (to initialise some fields

with nothing or a particular value as appropriate).

5. The data structure Passenger should contain fields to record important event times in the lifetime of

the passenger. These are

• id . . . an integer valued customer ID number (Int64)

• flight_id . . . the ID of the passenger’s flight (Int64)

• disembark_time . . . the time the passenger’s flight was unloaded (Float64)

• enter_primary_time . . . the time the passenger entered the primary queue (Float64)

• enter_secondary_time . . . the time the passenger entered the primary queue (Union{Float64,

Nothing})

• start_service_time . . . the time the passenger starts service (Union{Float64, Nothing})

• end_service_time . . . the time the passenger ends service (Union{Float64, Nothing})

• secondary_id . . . the ID of the passenger’s allocated secondary queue (Union{Int64, Nothing})

• counter_id . . . the ID of the counter the passenger was served by (Union{Int64, Nothing})

• attendant_rotated . . . true if the attendant rotated during service, false if not (Bool)

Initially unknown values above should be set to nothing when the Passenger is created. Similarly,

attendant_rotated should be initialised as false.

6. The data structure State will contain an event list (priority queue), queues for all resources in the system

and a few other details. These must be

• time . . . the current system time (Float64)

• event_list . . . the list of scheduled event (PriorityQueue{Event,Float64}, here priority is

the time of the event)

• primary_queue . . . queue of passengers waiting in the primary queue (Queue{Passenger})

• secondary_queues . . . vector of queues of passengers waiting in the secondary queues

(Vector{Queue{Passenger}})

6

• in_service . . . vector of passengers currently being served, or nothing if there is no passenger

at a given counter (Vector{Union{Passenger,Nothing}})

• n_entities . . . a counter of the number of entities in the simulation so far (Int64)

• n_events . . . a counter of the number of events in the simulation so far (Int64)

• n_flights . . . a counter of the number of flights that have unloaded passengers (Int64)

• n_open_counters . . . the number of currently open counter (Int64)

The constructor function for State should initialise all queues with empty queues of the correct type,

time to 0.0 and the counters to 0.

7. Parameters

Your code should have a data structure struct Parameters for passing parameters as given in the

below table

parameter

type description

seed Int64 random seed for the simulation

min_counters Int64 minimum number of counters

max_counters Int64 maximum number of counters

secondary_queue_length Int64 length of the secondary queues

mean_interflight Float64 mean time between planes unloading

min_no_passengers Int64 minimum number of passengers from plane to queue

max_no_passengers Int64 maximum number of passengers from plane to queue

min_passenger_transit_time Float64 minimum time to get from plane to queuing system

max_passenger_transit_time Float64 minimum time to get from plane to queuing system

min_service_time Float64 minimum time for passenger to complete service

expected_service_time Float64 expected time for passenger to complete service

final_time Float64 the final time for the simulation

attendant_rotation_interval Float64 the time between attendant rotations

attendant_rotation_time Float64 the time it takes for attendants to rotate

secondary_rush_time Float64 waiting time for a passenger to go to the next available counter

helpful_attendants Bool counter will serve passenger from outside their secondary queue

Note some of these parameters are important to implementing some of the additional features:

• Additional feature 1: min_counters and max_counters; feature switched off if these are equal.

• Additional feature 2: attendant_rotation_interval and attendant_rotation_time; feature

can be switched off if the interval is set to be greater than the total simulation time.

• Additional features 3: secondary_rush_time and helpful_attendants; feature switched off if

helpful_attendants is false.

8. Random number generators

Your code will use three random number generators. Store these as functions in a data structure struct

RandomNGs. For convenience, also store here a function that returns the resolution time. The code to

define this data structure is as follows

struct RandomNGs

rng::StableRNGs.LehmerRNG

interflight_time::Function

no_passengers::Function

transit_times::Function

service_time::Function

end

You should define a constructor function with

function RandomNGs(P::Parameters)

that takes the parameters structure as input and returns the random number generator and the four

functions. Initialise the random number generator as follows

rng = StableRNG( P.seed )

The four functions should similarly use variables from the parameters structure, and be consistent with

the modelling assumptions given earlier in this document.

7

9. Initialisation function

Your code have an initialise function that takes as input the parameters of the system and returns

an initial system state and creates the random number generators you are going to use.

The initialisation function should also create a new system state and inject an initial FlightDisembarks

at time 0.0. If you are implementing additional feature 2 the function should add an initial

FlightDisembarks at t=P.attendant_rotation_interval (this is 30 minutes in the example output).

The function should return the system state and the random number structure.

function initialise(P::Parameters)

R = RandomNGs(P)

system = State(P)

# add an arrival at time 0.0

t0 = 0.0

system.n_events += 1

system.n_flights += 1

enqueue!( system.event_list, FlightDisembarks(system.n_events,system.n_flights),t0)

# add the first attendant rotation

system.n_events += 1

enqueue!( system.event_list, RotateAttendants(system.n_events,true),P.attendant_rotation_interval)

return (system, R)

end

All you need to do here is copy and paste the above function into your code.

10. Update functions (overall)

Your code must have a set of update! functions with signatures:

function update!( S::State, P::Parameters, R::RandomNGs, E::SomeEvent )

Each update function should process one of your event types so you will need one function per event

type.

Each update! function should modify the state S appropriately, including

• update any state variables

• allocate a passenger to the event (if appropriate)

• add any new events created from this one to the event list

• move entities between the various queues as appropriate (for example, primary to secondary).

These functions must not have side effects. That is, they should not write out any information to files,

or interact with global variables. However, your functions may throw an error if the input is invalid.

Some additional details of the behaviour of these function can be inferred from the provided example

output files.

11. Update function (for Arrival)

This function should process an Arrival event in a manner consistent with the system description and

assumptions.

As in example codes from the course, you may find it helpful to write an additional function to use here

to move a customers around the various queues or into service (common to this and the Departure

update function).

12. Update function (Departure)

This function should process a Departure event in a manner consistent with the system description and

assumptions.

13. Update function (FlightDisembarks)

This function should process a FlightDisembarks event in a manner consistent with the system

description and assumptions.

14. Update function (RotateAttendant)

This function should process a RotateAttendant event in a manner consistent with the system description

and assumptions.

8

15. State-based and entity-based output files

Your code must output two CSV files. The files should both begin with some metadata and parameters

(you can include comments preceded with a #). These should be stored in subfolders named for the

random seed and some parameter values.

• The first file state.csv should contain a time-ordered list of all events that are processed in the

simulation.

This should be written from the point of view after the event. For instance, you should report the

system that an arriving passenger sees immediately after their arrival.

The CSV file should have columns titled:

event_ID,time,event,upcoming_arrivals,primary_length,secondary_lengths,in_service,n_total,n_open_counters

Here upcoming_arrivals should be a count of Arrival events in the event_list, and n_total is

the total number of people checking out, including those in service and those with a problem. See the

provided example files for formatting of the vectors in secondary_lengths and in_service.

• The second file entities.csv should contain a list of all entities that have completed service. The

CSV file should have columns titled (note the header should be one line as in the example output):

```

passenger_id,flight_id,disembark_time,enter_primary,enter_secondary,start_service,end_service,secondary_id,...

counter_id,attendant_rotated

```

You will need to write and construct these CSV files line by line. This is most easily done with println

statements, but you may use a package like CSV or Printf if you prefer.

16. Run function(s)

You code should contain a top-level function run_checkout_sim with the signature

run_checkout_sim(P::Parameters)

This function should take the parameters structure as its input. It should then

• initialise the system state,

• create the output files (and subfolders)

• write metadata, parameters and the header to the output files

• run the simulation by calling the run! function (see below)

• close the output files

The run! should have the signature

run!(system::State, P::Parameters, R::RandomNGs, fid_state::IO, fid_entities::IO)

This function should run the main simulation loop up to the final time given in the Parameters. It

should write output to the state.csv file for all events and to the entities.csv for Departure events

only. It should also update the system time before the update! function is called.

17. Code style

Your code must be written with good style. See Julia’s style guidelines for further information.

In particular:

• use comments (in English) efficiently and effectively

• store commonly used code as functions

9

Further Julia hints on PriorityQueue

When a problem occurs, the depature time of the customer will be extended. That is, you need to change the

time, i.e. the priority, of the corresponding departure event.

You can modify the priority of an object in a priority queue in Julia as follows:

using DataStructures

pq = PriorityQueue()

pq["a"] = 10; pq["b"] = 5; pq["c"] = 7;

pq

Output:

PriorityQueue{Any, Any, Base.Order.ForwardOrdering} with 3 entries:

"b" => 5

"c" => 7

"a" => 10

To change the priority of an object:

pq["a"] = 0 # change the priority of "a"

pq

Output:

PriorityQueue{Any, Any, Base.Order.ForwardOrdering} with 2 entries:

"a" => 0

"b" => 5

"c" => 7

Note that the order of the items in the queue has now changed. However, be careful here since the above

approch would not update the time stored in the Event structure.

Additionally, you may find it useful to iterate over the keys of a PriorityQueue as follows (continuing from

the above code):

for k in keys(pq)

if k == "c"

pq[k] = 3

end

end

pq

Output:

PriorityQueue{Any, Any, Base.Order.ForwardOrdering} with 2 entries:

"a" => 0

"c" => 3

"b" => 5

This last piece of code may seem overly complex for this example, but can be adapted for the purposes here.

Additionally, you may find it helpful to use the dequeue_pair!, peek and delete! functions for priority

queues. Try using these on the above example as follows:

key, priority = dequeue_pair!(pq) # dequeue, return key and priority

peek(pq) # look at the top of the queue, without removing

delete(pq, "c") # delete an item with a given key

10

Part 3: Verification and testing

Note that no marks are directly associated with the activities described below. This is all about

testing your code thoroughly to ensure it works as expected!

In this part, you will test your implementation to make sure it can output results and is consistent with some

provided output.

Tasks for Part 3

Although you might not need to modify the code in AirportOverseasPassports.jl, you may need to modify

it in response to bugs found in testing.

The main tasks will be to verify that your code works correctly (as described in Module 3: Verification), and to

construct a small simulation harness in which to run a set of comparison simulations (as described in Module 4:

Tools to Automate Simulation). Following these steps will help to detect any issues/bugs and ensure you get

the maximum number of marks for the code you have written.

1. Test and verify your code.

Compare the output of your code to the provided sample outputs:

• state_all.csv and entities_all.csv . . . output for the simulation with all additional features

implemented (parameters in metadata)

• state_basic.csvandentities_basic.csv‘ . . . output for simulation with no additional features (param eters in metadata)

If you have implemented your code exactly as specified, and used the same seed and random number

generation, your output should look very, very similar (the only differences should be in details such as

numbers of decimal points, white-spacing or ID numbers).

However, your code may result in some differences. Some are important and others less so. You need to

be quite analytical to understand which. That is, what differences occur because of a minor change in

the order of actions, and what differences are caused by bugs. If there are differences, you should create

some of your own tests to understand what is different from the code that produced the above results.

2. Create a test harness that will run your code for 100 different seed values ranging from 1–100. This

could simply be a script that looped over these values.

This will create 100 versions of the simulation, so by selectively examining the output and/or computing

summary statistics you can get a better sense of how well your simulation functions. In particular,

changing the seed can reveal “edge cases”, that is a situation that occurs rarely (and might not have

been in the sample output), which may lead to an error in your code.

Additionally, from these outputs, you could perform some statistical analysis to inform the airport’s

management about their questions. Note you do not need to answer these questions as part of this

assessment (that process will be part of the Project Report for a different problem).

11

Detailed rubric

You will be assessed on the following components of your work. [80 marks total]

• Basic functionality: code implements the basic functionality of this queuing system, as per the specification.

[40 marks]

• Additional feature 1: code implements this feature correctly. [12 marks]

• Additional feature 2: code implements this feature correctly. [12 marks]

• Additional feature 3: code implements this feature correctly. [12 marks]

• Code style: submission meets general style guidelines for good Julia code. [4 marks]

The marking scheme for each component is given in detail below.

Basic functionality

Criteria Marks

1 Define all data structures 4

2 Random number generators (service times) 4

3 Random number generators (all other RNGs) 4

4 Run and write functions 4

5 update! function (Arrival) 4

6 update! function (Departure) 4

7 update! function (FlightDisembarks) 4

8 State CSV (setup + initialisation) 4

9 State CSV (event behaviour correct) 4

10 Entity CSV (setup + behaviour correct) 4

Additional feature 1:

Criteria Marks

11 Additional counters open per specification 4

12 Counters close per specification 4

13 Instrumented correctly in state and entity outputs 4

Additional feature 2:

Criteria Marks

14 update! function (RotateAttendants) 4

15 Service times adjusted per specification 4

16 Instrumented correctly in state and entity outputs 4

Additional feature 3:

Criteria Marks

17 Promote passenger to next server if long waiting 4

18 Passenger can be served by different counter 4

19 Instrumented correctly in state and entity outputs 4

Code style:

Criteria Marks

Use of comments and functions per style guidelines 4

12