com.workflowfm.proter

Event used to model a repeating process.

An arrival rate is used to indicate when new instances of a simulation should be added to the coordinator.

Asynchronous Simulation implementation with callback functions.

Each task needs to be accompanied by a callback function that implements the simulation logic to be followed when the task completes.

A constant value generator.

Always generates the same value.

A constant Long value generator.

Always generates the same value.

Provides coordination for discrete event simulation of multiple asynchronous simulations.

Default implementation of Manager.

It can run in a single thread or multi-threaded depending on the singleThread constructor parameter. In the multi-threaded setting, task completions are reported to the simulations asynchronously through a new thread (Future) each time. This allows simulations to run things concurrently, with the added overhead of thread spawning.

Discrete Events that need to be handled by the Coordinator..

A random function sampling some probability distribution to produce a Double value.

It can be used to generate a value for simulation parameters (typically duration and cost). It can be a Constant which always provides the same value or any probability distribution.

Distributions must also provide an estimate of the generated values such that can be used in an environment of imperfect knowledge. For example, the Scheduler does not know the actual durations of tasks, which can vary from the expected estimate for various reasons.

Event fired when a Task has finished.

Extends AsyncSimulation with callbacks that fulfil a Promise/Future.

This can be helpful for simulation implementations that use Futures to capture their asynchronous logic.

A random function sampling some probability distribution to produce a Long value.

It can be used to generate a value for simulation parameters (typically duration). It can be a ConstantLong which always provides the same value or any probability distribution.

Distributions must also provide an estimate of the generated values such that can be used in an environment of imperfect knowledge. For example, the Scheduler does not know the actual durations of tasks, which can vary from the expected estimate for various reasons.

A Lookahead contains information about the order in which tasks run.

The structure is immutable. It is built by the simulation and passed to the scheduler where it is used for scheduling by revealing information about future tasks so that look-ahead can be achieved.

A Lookahead that uses a set in the implementation

A Structure used for combining multiple Lookaheads into one.

A trait that adds Lookahead capabilities to a simulation.

Works in conjunction with LookaheadScheduler.

Provides a lookahead structure that can be built up by the simulation and then sent to the scheduler for use in making schedules which look into the future to consider upcoming tasks in scheduling.

Abstract simulation manager.

An empty Lookahead that does nothing.

Response issued when the simulation has completed.

Response issued when the simulation is still running and waiting for virtual time to pass.

Captures the potential responses of a simulation case to an event.

A simulation is notified by its Manager when relevant events have taken place, such as one of its tasks completing. The simulation can use subclasses of this trait to respond to such notification. The Manager will wait for such a response before it resumes the virtual time.

A manager for a single simulation case.

We view a simulation as a case or workflow of simulated tasks. This class is responsible for keeping track of all the tasks for the corresponding simulation, informing the Coordinator of new tasks to be added and informing the simulation processes when a task is completed.

=Basic Interaction Flow= The interaction flow with the Coordinator is expected as follows:

1. The simulation logic starts executing via run.
2. Tasks are added via task.
3. When the simulation logic finishes producing tasks, it should call ready.
4. Eventually, one of the tasks completes and complete is called. The simulation logic resumes execution.
5. The simulation may now produce further tasks in reaction to the completed one(s). It can either handle and acknowledge each completed task individually using ack or use ready in one go as above.
6. When the simulation logic completes, it can use succeed (instead of ack or ready) to notify the Coordinator of its result.

=Additional Functions= The simulation may also:

1. React to things happening to other simulations. It can send a request to wait using simWait. The Coordinator will then wait for the Simulation to send new tasks or to complete, as if a task just completed. This needs to happen while the Coordinator is still waiting for the other simulation(s) we are reacting to.
2. Abort previously added tasks using abort.
3. Report completion due to failure using fail.
4. Optionally maintain a Lookahead structure of future tasks, returning it through getLookahead.

A generator of simulation instances.

This is used to model repeating processes, for instance with a given arrival rate.

It generates copies of a SimulationRef. It must ensure that each copy has a unique name and is independent from all other copies. An integer counter is provided as an argument for that purpose, though it is not necessary to use that.

An abstract reference to simulation logic.

Includes the basic interface that we expect from a simulation case:

1. Starting the simulation.
2. Notifying when tasks complete.
3. Stopping/aborting the simulation.

A generator of simulation instances.

This is used to model repeating processes, for instance with a given arrival rate.

It generates copies of a SimulationRef. It must ensure that each copy has a unique name and is independent from all other copies. An integer counter is provided as an argument for that purpose, though it is not necessary to use that.

A Simulation that simulates a single Task.

A SimulationGenerator for SingleTaskSimulation instances.

Event fired when a simulation needs to start.

A generator/factory of tasks (specifically TaskInstances).

As a case class, it can be easily manipulated dynamically to alter its values.

Uses Distributions for the duration and cost. These may be based on random variables. The actual values are sampled at task creation time.

Although typically only 1 task is generated, in principle it can generate multiple task instances with the same properties. However, each task generated will have different samples of the Distributions.

An instance of a task to be performed in virtual time.

A persistent resource to be used by Tasks/TaskInstances.

A TaskResource, or simply "resource", corresponds to a persistent resource. Typical examples are human actors or persistent machinery.

Each Task may require a different combination of resources.

Each TaskResource is assumed to have a unique name and a costPerTick, i.e. the cost (if any) of using the resource per unit of time.

We say a TaskResource is ''attached'' to a TaskInstance when the task that uses this resource is being performed. The currentTask variable holds the task that is currently attached to the resource (if any) coupled with the virtual timestamp of when it started. A TaskResource is ''idle''' when it has no tasks attached to it.

The Coordinator calls upon startTask to attach a task to the resource and finishTask to detach it. The Coordinator has full control over the resource and makes all necessary checks to ensure consistent behaviour (e.g. not starting a TaskInstance when another TaskInstance is already attached).

Event fired when a global time limit has been reached.

A uniform distribution.

Samples a random variable uniformly between min and max.

A uniform Long distribution.

Samples a random variable uniformly between min and max.