• Due Date: Tuesday 28 December before 23:55.
• Team Size: 2 (pair design/programming)!
  Note that as of the 2017-2018 Academic Year, each International student should team up with "local" (i.e., whose Bachelor degree was obtained at the University of Antwerp).
• Submission Information: Only one member of each team submits a full solution. This must be a compressed archive (ZIP, RAR, TAR.GZ...) that includes your report and all models, images, code and other sources that you have used to crate your solution. The report must be called index.html. Make sure to mention the names and student IDs of all the team members. The other team member must submit a single HTML file containing only the coordinates of both team members. This will allow us to put in grades for both team members in BlackBoard.
• Submission Medium: BlackBoard. Beware that BlackBoard's clock may differ slightly from yours. If BlackBoard is not reachable due to an (unpredicted) maintenance, you submit your solution via e-mail to the TA. Make sure all group members are in CC.
• Contact / TA: Randy Paredis.

This assignment will make you familiar with modeling, simulation and performance analysis in DEVS. You will learn to use modeling patterns to construct a discrete-event simulation on which specific statistics can be obtained and analyzed. This assignment is to be completed with PythonPDEVS. A detailed documentation is available. Take a look at the "Application to Queueing Systems" example to get started with PythonPDEVS. This assignment completes the PRT example that was introduced in the previous assignments.

It is highly encouraged to read the documentation about the given functions and classes. If you use a function or a class in a way that disregards the "note", "warning"... labels, you will not receive any points on the entire task, even if it produces the correct results. Additionally, the documentation provides a set of examples which may help you in completing this assignment.

The figure below gives an example of a PRT map of a fictional city. In total there are 10 stations, which have been marked with a circle. The distance between stations is denoted on the line segments. Each station services one (or multiple) lines. In total, the PRT contains 3 lines: red/full, yellow/striped and blue/dotted. There can be at most a single rail between two nodes in the network, even if there can be multiple lines. People arrive at a station and wait on the platform for a trolley that brings them to their desired destination station. Additionally, there are junctions with traffic lights to prevent train collisions. These junctions are identified with squares with the letter "J". The rails are one-directional, where line 2 (yellow/striped) circulates counter-clockwise and the other lines circulate clockwise.

We are interested in studying the performance of this PRT system. Therefore, the following performance statistics must be observed. When a statistic is to be obtained for a set of stations/trolleys, also include a plot for every single component.

1. Average travel time of a passenger.
2. For each trolley, a summarized overview of trolley capacity over time.
3. For each trolley, the time-average trolley capacity.
4. For each station, the amount of people that have exited at that station.
5. For each station, the amount of people that have exited at their desired destination.
6. For each station, the average travel time of people that have exited at that station.
7. Total amount of people that have traveled over the PRT.
8. Number of people that have succesfully arrived at their desired destination.
9. Number of people still commuting when the experiment terminates.
10. Number of people with a destination that equals their origin station.

The following is a detailed description of all components for this system, as well as all messages that are being sent. Make sure not to hard-code any numbers, as this will help your analysis later on. You are allowed to group multiple components together in Coupled DEVS models. It is allowed to extend the descriptions given below, as they may not be complete. Try to optimize your code such that there is a minimum of code duplication.

Passenger:

Identifies the passengers that travel around in the PRT. Upon creation, they are given an origin and a desired destination station.

Trolley:

Identifies the trolleys that transport passengers around over the PRT. They have a maximal capacity of 10 people and a parametrized velocity. Additionally, they can only serve one of the three lines.

Rail:

Atomic DEVS, identifying a segment over which trolleys can travel (in a single direction). They have a certain distance, which can be combined with a Trolley's velocity to obtain the transit time for this Rail. Trolleys cannot pass each other and there must be at least a 10 second delay between the departure of two Trolleys. For instance, a faster Trolley A will leave the Rail 10 seconds after the slower Trolley B if B is in front of A. For simplicity, there can be an infinite amount of Trolleys on a Rail.

Junction:

Atomic DEVS that identifies a merge of multiple Rails onto a single output. The Trolleys are merged according to their order of arrival. Furthermore, it takes 50 seconds for each Trolley to transfer the junction.

Split:

Opposite of the Junction. There is a single input, but a set of outputs that allow a Trolley to deviate w.r.t. their line number. For instance, the user can define that lines 1 and 2 will be outputted on the right branch and line 3 will be outputted on the left branch. The Trolleys should automatically follow this logic without any delay. This block is not a required component, but will help when creating the Station.

Station:

Coupled DEVS model that contains a Generator, a Collector, a Platform, a Track, a Light and possibly a Split. The Station serves a set of n lines. For simplicity, there is a single input and n outputs (see the Split logic above). The figure below shows a shematic overview of how a Station is created with the given list of components.

Generator:

Atomic DEVS that generates Passengers according to a normal distributed inter-arrival process with a mean of 5 minutes and a standard deviation of 1 minute. For each Passenger, a random destination is chosen. This destination does not have to be reachable from the starting point.

Collector:

Atomic DEVS that obtains Passengers. Should be used as a helper model to obtain the required statistics.

Platform:

Atomic DEVS, identifying a location in a Station where an unlimited amount of Passengers can wait to board a Trolley. For the purposes of this assignment, you can assume they queue on the Platform in a first-in-first-out order. For every line the Station serves, a different queue may be used for simplicity reasons.

Track:

Atomic or Coupled DEVS, identifying the location where Trolleys arrive at the Station. There can only be one Trolley per Track. A Trolley always halts for 1 minute at each Station (50% of the time before and 50% after boarding/disembarking). After its first wait, all Passengers that must exit at this Station disembark the Trolley, followed by the boarding of all people that need to enter that Trolley (as long as there are people waiting and there is room in the Trolley). Next, it waits the second time, before exiting the station. The Track communicates the lines it services to the Platform, such that people that have a destination station located on that line can board the Trolley. Only one Passenger can enter/exit the Trolley every 10 seconds.
There should also be a 20% chance that a Person exits in the wrong station.

Light:

Simple first-come-first-served queue that releases elements upon requests.

You will need to perform the following tasks step by step.

1. Create all individual components for the PRT system, as described above. Try to use the patterns that were discussed in the theory lectures to solve this task. Minimize magic numbers and maximize the usage of OO-programming.
   • Hint: Gradually built all your components and test their behaviour. Do not try to create a system that fully encompasses everything from scratch. This will minimize the amount of required time to complete this assignment.
2. Create the PRT network as shown in the figure above. You can either hard-code all interactions, or create your own file-type from which such a network can be read. Your choice will obviously be reflected in your grade. You may use as many model transformations as you'd like, as long as you fully describe all steps that are required to achieve the network model.
3. Prove the validity of your model by creating a function in your top-level DEVS model, which draws your rail network using GraphViz.
   • Hint: to obtain all ports from sub-models that connect to a port called portA, you can use portA.inline. Similarly, to obtail all ports from sub-models that portA connects to, you can use portA.outline.
   • Hint: to obtain the DEVS model from a port called portA, you can use portA.host_DEVS.
4. Add a function in your top-level DEVS model that outputs/generates the required statistics at the end of the simulation. This function will probably also generate some plots for certain statistics.
5. Start one Trolley in each station that only serves a single line and simulate your model for 24 hours. Compare two different seeds and discuss the statistics. Discuss the results when
   • all Trolleys have the same velocity of 50 km/h.
   • half of the Trolleys have a velocity of 50 km/h and the other half have a velocity of 25 km/h.
6. Enforce that Passengers that are generated at Station A can only travel to Stations that are reachable from A without needing to switch lines. Additionally, they should not mark A as their destination. You may use (manual/automatic) preprocessing to create a "reachable stations" data structure. Also reduce the chance for exiting in the wrong station to 3%. Compare these results to the ones obtained from the previous simulations.
7. Use the same seeds, but alter any of the given constant values to find a better performing PRT system.
8. Remove the randomness from your model by changing the distribution parameters. Use this new, deterministic model to "prove" the validity of the behaviour of your system. Make sure to discuss all the components of the system. This may be a mathematical proof, a proof by simulation trace analysis or a proof by logical reasoning.
9. Write a report that explains your solution for this assigment. Include all figures and plots; and discuss them. Also clearly indicate which models can be found in which files. Make sure to mention all your hypotheses, assumptions and conclusions. See also the "submission information" at the top of this page.

Notice the inconsitencies used in units (50 seconds, 25 km/h, 3 km...). It is up to you to do a conversion to a corresponding set of units. Even though real-time simulation will use the time-advance as seconds, it is not required for this to represent seconds. However, make a logical and well though-out decision.

It can be useful to create constructs that allow you to look up any station-line combination. Additionally, it is preferrable te use a predefined seed for random number generation. This allows a consistent result when testing and debugging your code.

While all components of the model are defined above, you are free to choose how these are implemented. As long as the behaviour is equivalent to how it is described here. Sometimes, there are multiple solutions to the same problem, but there are also ambiguities to allow you to make choices in the implementation. Don't choose for the most impressive solution, but rather the easiest and fastest to implement. Don't forget to discuss where and why you made certain choices!

Where possible, use different experiment files to setup your tasks. This allows you to return to previous tasks without issues, as well as referring to specific modules in your report. Also ensure your model is flexible enough to allow all the tasks by simply changing model parameters. If a task requires a (slight) change in the components used, make sure to include all versions of the components.

Your model should work for Classic DEVS, therefore you can ignore the possibilities of parallelism. If you do allow Parallel DEVS to work, make sure your model still works for Classic DEVS! To simulate using Classic DEVS, you can do the following:

            sim = Simulator(model)
            sim.setClassicDEVS()
            sim.simulate()
          

Take pride in your work. Make sure your report and all models and images are clearly readable. If a figure is difficult to read, also include the corresponding source files (*.gv, *.py...). You will not lose points for doing too much, but you will lose points if you do too little.

• This assignment is to be created with PythonPDEVS. Installing this on your system/virual environment can be done by executing python setup.py install --user from the source directory. Alternatively, placing the source directory on the PYTHONPATH environment variable, or marking it as a "sources root" in an IDE will work as well. Note PythonPDEVS works on both Python 2.7 as well as Python >=3.6. Do not use features from Python 3.10 (current alpha version).
• The statistics can be printed after the simulate() call and printed to the console, to be plotted at the end (e.g. using gnuplot/matplotlib/bokeh). You are strongly advised to first study the "Application to Queueing Systems" example.
• Do not use real-time simulation, unless you read up on the topic in the PythonPDEVS documentation.
• The theory slides describe a set of design patterns to use. Your model will be better if you do. This will be reflected in your grade.
• Useful links:
  • PythonPDEVS documentation: https://msdl.uantwerpen.be/documentation/PythonPDEVS/.
  • PythonPDEVS starting examples:
    • Classic Example
    • Application to Queueing Systems
    • PythonPDEVS "checkout" example (from practical session)