CISC836: Assignment 3
Queen's Logo

Beyond Code: An Introduction to Model-Driven Software Development (CISC 836, Winter 2020)

Assignment 3 (MDD with RSARTE)

Due: Tuesday, March 3

  1. Purpose of the Assignment:
    Give you practical experience with timed systems and fault-tolerance (in the context of UML-RT and RSARTE).

  2. Preparation:
    1. The RSARTE installation that you used for Assignment 1 will also be used for this assignment.
    2. Make sure that you are aware of the design guidelines discussed in class.
    3. If questions come up, feel yourself encouraged to post them on the OnQ pages of the course.

  3. Problem Description:
    The problem is to sort a stream of parcels (or pieces of luggage) into 'bins' according to the destination of the parcel. The central piece of hardware to be used is a 'stage' which consists of two 'chutes', one 'sensor', and one 'switcher'. A parcel will enter the stage on one end and eventually emerge on the other end from one of two openings. To form a 'parcel router', stages are arranged in a binary tree-like fashion with the opening of one stage feeding parcels directly into either the entry of the next stage or a bin. The journey of a parcel through a stage proceeds as follows:
    1. After entering the stage, the parcel will travel down the first chute ('chute1'). The time required for the parcel to go from the beginning to the end of the first chute is called 'chute1Delay'.
    2. At the end of the first chute,
      • the parcel enters the second chute ('chute2'). The time required to travel down this chute is called 'chute2Delay'.
      • the destination of the parcel is read by the sensor which uses it to determine which one of the two openings the parcel is to exit the stage from. The sensor sends this direction information (given in terms of one of two values: 0 for 'left' and 1 for 'right') to the switcher which then positions its internal routing mechanism accordingly. The operation of the sensor and the positioning of the switcher is assumed to take neglible time.
    3. At the end of the second chute, the parcel will enter the switcher and emerge at one of the ends after 'switcherDelay' seconds. Any arrival of direction information from the sensor before the parcel leaves the switcher may change the opening the parcel emerges from. In other words, the direction information from the sensor can change the direction of the parcel up until the parcel has left the switcher.
    4. At the end of the switcher, the parcel will leave the stage and either enter the next stage or reach a bin.

  4. Description of provided UML-RT model:
    A simulation of a parcel routing system with 4 destination bins has been designed with UML-RT. The structure of this design closely mimicks that of the physical system and is show below:

    Parcel router capsule diagram Stage capsule diagram

    As shown in the diagrams, the router consists of nine capsule instances on the top level, while each stage contains another four instances (so, the entire router consists of no less than 22 communicating state machines, resulting in more than 7K lines of generated C++ code!):

    For checking purposes, the parcel router contains 3 attributes in which it counts the number of parcels generated for each destination ('generated:int[4]'), the number of parcels that arrived correctly at their destination ('arrived:int[4]'), and the number of parcels that got routed to the wrong bin ('erroneousArrivals').

    The state machine of the parcel router

    1. collects command line arguments (if any),
    2. sends intialization messages to the generator and the stages,
    3. waits for 'generated(dest)' messages from the generator and increments the appropriate counter,
    4. waits for 'arrived(dest)' messages from the bins, checks for incorrect routing, and then increments the appropriate counter,
    5. waits for the 'done' message from the generator, and then logs the total numbers of generated and arrived parcels before it terminates.

  5. How to invoke the simulation:
    The execution can be customized via 5 command line arguments

    >> ./Parcelrouter.exe -UARGS <numParcels> <genDelay> <chute1Delay> <chute2Delay> <switchDelay>

    determining, respectively,

    If only one command line argument is used (>> ./Parcelrouter.exe -UARGS <numParcels>), it is interpreted as the number of parcels and default values are used for the delays (<genDelay>=2, <chute1Delay>=1, <chute2Delay>=1, and <switchDelay>=0). If no argument is provided, the same delay defaults are used and <numParcels> is set to 10. If a different number of arguments is given (2, 3, 4, or more than 5), execution stops with an error message. As in the previous assignments, use the command line option -URTS_DEBUG=quit to bypass the RSARTE command line debugger.

  6. How to invoke the animation:
    The project contains a Java program that will animate executions of the simulator with the help of a socket connection over which the model sends messages whenever the animation view needs to be updated.

    Parcel router animation

    To use the animation, it must be invoked first by right-clicking the 'ParcelRouterAnimation' Java project in the Project Explorer, selecting 'Run As' and then 'Java Application'. Note that:

  7. Problems in the current model:
    The provided model has two problems:
    1. Problem 1 (Lost parcels): When a parcel is generated or has reached the end of a chute or a switcher, the model currently passes on the parcel regardless of whether or not the next unit (i.e., chute, switcher, or bin) is empty and can actually hold that parcel. As a consequence, parcels appear to 'get lost' under certain delay settings. Problematic settings are those which cause a unit to receive a new parcel before the current one has been passed on. Examples are

      >> ./Parcelrouter.exe -UARGS 10 1 2 1 0
      >> ./Parcelrouter.exe -UARGS 10 0 1 0 2

      which, in my implementation, cause 5 and 9 parcels to get lost respectively. Lost parcels will manifest themselves in the execution as 'unexpected messages' preventing it from running to completion. Similarly, the animation will become inconsistent. Note that not all delay settings are problematic. E.g., using

      >> ./Parcelrouter.exe -UARGS 10 1 0 0 0
      >> ./Parcelrouter.exe -UARGS 10 2 1 1 0
      >> ./Parcelrouter.exe -UARGS 10 3 0 1 1

      no parcels get lost.

    2. Problem 2 (Incorrect routing): The model currently routes all parcels to just one bin which is obviously incorrect. Both, the console output and the animation show this. E.g., the console output of the execution of

      >> ./Parcelrouter.exe -UARGS 10 3 0 1 1

      ends in

      [ParcelR] total generations: 4 2 1 3
      [ParcelR] total correct arrivals: 4 0 0 0, total incorrect arrivals: 6
      [ParcelR] delay settings: 3 0 1 1
      [ParcelR] duration: 34 sec, 143997000 nsec
      [ParcelR] stop

    While the animation output is useful for many (non-zero) delay settings, due to the limitations of the animation mentioned above, the console output is, in general, better suited to tell you if an execution exhibited one of the two problems above.
  8. Your tasks:

  9. What to submit using OnQ:

  10. Marking:
    For Parts 2 and 3, your changes to the model will be marked based on their correctness and completeness (with respect to the assignment instructions and the system descripion), but also using the design guidelines discussed in class. Your answer to Part 4 be marked on completeness, precision and clarity.