Simulator implementation

There are a couple of design decisions for the simulator (http://www.es.ele.tue.nl/poosl/Tools/rotalumis/) that developers of POOSL models should be aware of.

Evaluation of debugging printString methods

When debugging a POOSL model, string representations of data values are displayed in the Variables view and the Sequence Diagram view. Such string representations are computed using the printString method of the value's data class.

The execution of such a printString method could update some variables or could lead to an error. The simulator executes these debugging printString methods in a safe environment (based on an internal deep copy of the data), such that their execution cannot impact the further model execution.

This safe environment is not obtained using the deepCopy method, but it is directly based on a copy of the internal state of the classes In this way we avoid issues with the non-permanent native classes, for which the execution of a deepCopy method would generate an error. In the safe environment, the execution of state-changing methods from the non-permanent native classes will immediately generate an error.

Evaluation of guards

When running or debugging a POOSL model the enabled transitions are determined continuously. To this end, the simulator evaluates conditions inside guarded statements and receive statements (and hence also the expressions inside send statements). During interactive debugging, the set of enabled transitions is also needed for computing the colors inside the Execution Tree view.

The evaluation of such a guard may update some variables, or may lead to an error. Hence their evaluation may impact the further model execution. In particular any POOSL model must be able to deal with multiple additional evaluations of such guards.

Socket data class

The socket data class is implemented as an ipv4 socket. The following two aspects need to be taken into account:

RandomGenerator data class

The RandomGenerator data class is used to obtain random numbers for simulating probabilistic behavior. A random number generator emulates drawing samples from the sample space of a random variable in accordance with its distribution. This is accomplished by producing a repetitive sequence of (pseudo) random numbers as described by a suitable algorithm. An essential issue for obtaining credible performance results is the actual randomness of the generated random numbers. This randomness depends, amongst others, on the number of random numbers generated before reproducing the sequence and the statistical independency of the generated random numbers.

POOSL allows the use of multiple instances of data class RandomGenerator. The challenge is to ensure the generation of nearly independent parallel sequences of random numbers for the different instances of RandomGenerator. To this end, the simulator uses a separate random number generator for each instance of data class RandomGenerator. Ensuring near independence of the parallel sequences with this approach requires to initialise the random number generators with different initial values (seeds) such that the parallel sequences of random numbers are non-overlapping (Notice that each random number generator uses the same algorithm for generating random numbers). Choosing these seeds should not be done without properly considering whether the parallel sequences are indeed non-overlapping. Simply using another random number generator for producing the seeds is generally insufficient for obtaining credible performance results.

The simulator uses a separate Mersenne Twister for each instance of data class RandomGenerator. The Mersenne Twister has a periodicity of 2 ^ 19937 - 1. The seeds are initialized automatically by means of another random number generator.

Resolving Non-Determinism

Next to generating random numbers for instances of data class RandomGenerator, the simulator requires a random number generator for probabilistically resolving non-determinism in POOSL models. The simulator uses a separate Mersenne Twister with a fixed seed for resolving non-determinism. Notice that a fixed seed allows exact reproduction of a simulation (in case method randomiseSeed is not used in the model). For any simulation, it is assumed that the number of random numbers needed for resolving non-determinism is much larger than the number of random numbers required for instances of RandomGenerator. Therefore, the random numbers generated for the different purposes are considered to be nearly independent, which ensures obtaining credible performance results.