• The due date is Sunday 3 Januari 2020, before 23:55.
• Submissions must be done via BlackBoard. Beware that BlackBoard's clock may differ slightly from yours. All results must be uploaded to BlackBoard and accessible from links in the main (index.html) file.
• The assignment must be made in groups of maximum 2 people. It is understood that all partners will understand the complete assignment (and will be able to answer questions about it). Clearly identify who did what.
• Grading will be done based on correctness and completeness of the solution. Do not forget to document your requirements, assumptions, design, implementation and modelling and simulation results in detail!
• To get feedback about the assignment workload, provide the number of hours you spent on this assignment.
• Contact: Randy Paredis.
  
  

This assignment will make you familiar with modelling, simulation, and performance analysis in DEVS.

You are tasked to model the behaviour of an assembly line in a factory. Products are assembled out of cylinders and cubes and are afterwards inspected for validity. After the latter, most products are accepted, some are thrown in the trash and the remainder will be sent back for reassembly. To allow for optimization and analysis, you are required to model this assembly line.

This model will be used to analyze the influence of model parameters on the behaviour. There are seven statistics we will concern ourselves with (please print them to the console at the end of your simulation and describe them in your report):

1. The total number of created products.
2. The total number of times any product was reassembled.
3. The percent of all products that ended up in the trash.
4. The percent of all products that were accepted.
5. The percent of all accepted products that have been reassembled.
6. The average time a products waited to be processed (either at the assembler or the inspector).
7. The average time a product was in the system.

The model will consist of a Coupled DEVS model named Factory, as shown in the image below:

The following is a detailed description of the components of this model as well as the messages that are being sent. Note that it is perfectly possible some components have the exact same functionality, but were given different names for the description of the system. Try to optimize your code such that there is a minimal of code duplication.

Cylinder

Used to identify a cylinder passing through the system.

Cube

Used to identify a cube passing through the system.

Product

Represents an assembled product. It is highly recommended to use this class to store information you need to compute the required statistics and properties.

Cylinder Source

An atomic DEVS, which generates a Cylinder every three minutes.

Cube Source

An atomic DEVS, which generates a Cube every two minutes.

Preassembler

If we assemble a product first and then delay it in the Assembler (see below), we get the same semantics as if we were to assemble the product over a period of time. Hence, the Preassembler atomic DEVS reduces the overall complexity by transforming 1 Cylinder and 2 Cubes into a product.

Assembler

Since the actual assembly happened in the Preassembler, this atomic DEVS should introduce the required delay, as if it is assembled at this point in time. The delay is a uniform random value, following a normal distribution with a mean of 4 minutes and a standard deviation of 1 minute. The Assembler also sets the "correctness" of a product. This is a uniformly distributed random value in [0, x); where x starts as 1, if it's the first time this product is assembled. If the product is reassembled and its previous correctness equals c, x equals (2 + c) / 3. Additionally, this block will set the Product's creation timestamp.
EDIT: The Assembler can only work on a single Product at any time. All Products arriving in the meantime should be added to a queue.

Inspector

This model sends the products to one of three outputs (trash, accept or fix), after a certain delay. Similar to the Assembler, the delay for the Inspector also follows a normal distribution, but here, the mean is 2 minutes and the standard deviation is 1 minute. Use the correctness of the product to identify which product is sent where, given that 55% of all products will be accepted, 15% will be trashed and 30% will be sent back to the Assembler. Please indicate in your report what design choices you made to allow this to work.
EDIT: The Inspector can only work on a single Product at any time. All Products arriving in the meantime should be added to a queue.

Fix

Marks products to be fixed. This takes no time at all. Products that are sent back will be interleaved with the arriving resources, which should happen automatically if you modelled your Factory correctly.

Trash

The trash bin.

Accept

The exit point for all accepted products.

Perform a reasonable number of simulation experiments. Always choose the simulation duration sufficiently long enough to get statistically relevant measurements.

• Use two different seeds and describe what happens to all seven statistics. Do they change? Why (not)?
• Now, change the percentages set in the Inspector to three values of your choice. Make sure their sums don't exceed 100%! Compare your results with the previously obtained values.
• Choose some meaningful values for the various parameters to demonstrate the correctness of your model. In particular, decouple the randomness from the behaviour, which results in a deterministic system. This allows you to analytically determine the performance metrics and compare them to the simulated statistics. Show your computations and discuss the results.

• During development, you can use a seed to make the random number generators deterministic.
• Seeing as the Assembler and the Inspector have very common functionalities, it is possible to create a superclass "Operator".
• Both the Trash and the Accept components do exactly the same: collecting all arrived products.
• 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!
• Make sure you carefully describe why and how every aspect in your solution works. Provide proof of your statements, either algebraically, experimentally or graphically.

You will use the PyPDEVS (Python PDEVS) simulator [download, git repo]. An in-depth documentation is available, and includes examples. Installing PythonPDEVS can be done by executing python setup.py install --user. Note PythonPDEVS works on both Python 2.7 as well as Python >=3.6.

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.

Note that in PythonPDEVS, when an external transition is triggered, this means that some external input has arrived on one or more of the ports. The inputs will be passed to the method in the form of a dictionary, which is the only argument of the extTransition method. The key values of this dictionary are the ports. If a port is not present in the dictionary, there was no input on that port. The elapsed time can be accessed using the elapsed attribute, but note that this is only correct in the extTransition method. It is therefore not allowed to access the elapsed attribute in an intTransition (and its value will be undefined).