Prophesy-Detailed Description

Prophesy is a generic tool intended for all standard queuing analysis and work flow processes. With it, users can simulate the queuing transfers between a system of inter-related resources, with the objective of estimating:

Uses for Simulation

Prophesy will help you find the best compromise between service levels and resources that will make your company more efficient while helping you optimize costs. There are a variety of business reasons to justify the use of simulations:

While one of the major domain problems Prophesy simulates is that of computer systems, you can also put Prophesy to work in different type of situations. Following are some examples:

Obviously, you do not need to simulate if you already have a system and the performance information can be obtained by simple measurement, but simulations do have a place in the following cases:


How Prophesy Works

In order to provide a highly flexible environment, elements in Prophesy are abstractions of the system elements to simulate. While oriented to simulate computer systems, Prophesy extends the computer system metaphor to support simulation of practically any system involving a client requesting a service. The representation of work is given by the concept of a "Message", and the work flow is represented by messages traveling a system of resources that provide services. This system of inter-linked resources can have practically any desired topology. The system may be hierarchically organized or may be meshed.

Part of the model scoping and definition stage involves deciding what "personality" each of Prophesy's elements will take within your simulation. In addition, you also identify the granularity and level of detail you want to apply to the simulation.

For simulated computer systems, you may specify the number of machine instructions a resource (computer) is capable of executing or simply indicate the number of transactions the computer can process per unit of time.

The fundamental objects of the Prophesy metaphor are:

Prophesy runs with an inter-play of the Resource, Profile, Procedure, and Message objects. Messages are characterized by a Transaction Identifier and a State Identifier, and when delivered to a resource (either because the messages was created by a message injector, or because the message was sent by another resource), they trigger an event. You can define event handlers for the Message (an event for a message with the specified transaction and state ID is called an Activity) in the Resource's Activity List, the procedure specified in the activity list for this event is executed.

Inside the procedure, you specify the processing delays to simulate. You also specify the destination of the message that originated the activity. Messages may be forwarded to another resource (pass it through) without changing it, or its attributes (state, size, priority, etc.) prior to being sent. you may also simply delete the message. In fact, should the procedure fail to forward the message to another destination, the message would be automatically deleted upon procedure termination.

If the procedure delivers the message to another resource, the cycle is repeated again: the message triggers an event which is compared against the destination resource's Activity List, and if a match is found, the associated procedure is executed. If no match is found for the message's transaction and state identifiers, Prophesy checks if there is a generic activity for that message state or transaction and calls the attached procedure if that activity exists. If you have not defined a generic catch-all activity for messages, and no activity exists for the message, the message is simply discarded.

Events caused by messages occur when the message is extracted from the resource's Receive Queue; not when the message is placed in the Receive Queue. That is, execution of a Procedure is equivalent to retrieving a message from the Receive Queue, and processing it.

Prophesy gives a range of options on how message driven events can be scheduled. For instance, messages of highest priority are serviced first. Also you can specify a "patience" index for each message, whereby he or she indicates how long the message should wait in the receiving queue for service before withdrawing itself from that queue.

As messages are created, delivered to queues, processed, and forwarded, Prophesy keeps appropriate time stamps for later reporting of message delay statistics. Running the simulation is nothing more than having the specified message stream traverse the requested resources by triggering the appropriate actions, which in turn execute the specified procedures.

It is within the procedures that messages get delayed and resources are seized for specific simulated operations. Some of these delays are specified in absolute terms, but others are a function of the characteristics defined in the resource's profile. The resource profile is a separate definition file containing the performance features associated with the resource. For instance, there you enter the number of work units per unit of time the resource is capable of servicing.

There are other events that can trigger elements in the Resource's activity list. You may define one activity, triggered by the initiation of the simulation. Also he or she can have an activity which is triggered every specified number of simulation ticks so that procedures can be scheduled to execute upon the start of the simulation and/or every certain number of ticks. Furthermore, you can specify which message types (Transaction/State identifiers) are to be Probed for statistical purposes.

In addition, the resource's activity list may contain an element triggered upon delivery of a message through a certain input/output port. This event allows you to simulate how many times the sending of a message is to be retried and the overhead caused by this retry.

Prophesy does not require you to exit the program during work sessions which involve the following stages:

1. Model Build. Here you create resources via Prophesy's drag-and-drop graphical interface. Resources are defined by opening each of the icon's definition panels. The resource system is specified by linking the resources using graphical commands (mouse clicks).

2. Model Play (Run). You can execute a single run, or use Prophesy's Multiplay feature to run the model several times with a single command. You can interact with the simulation as it runs, or wait until it ends. Message flow animation is optional. The speed of simulation can be adjusted by setting different statistical refresh rates.

3. Analysis. While still in Prophesy's run mode, the results are update dynamically via refresh of resource and queue utilization bars and updated statistical information on message delays.

4. Model Documentation.

A normal work flow is a series of iterations between those phases. In general, while working with Prophesy you will be in one of two operating modes: MODEL BUILD or RUN. The former is where you create, define, and document the model, and the latter is the mode in use while the simulation runs, or after the simulation has ended and you analyze results.

Prophesy provides the following statistical information:

Resource Usage. It contains the mean resource utilization and resource utilization quartiles (i.e. How many times the resource has been found to be used in each of four percentage ranges).

Queue Usage. Consists primarily of the utilization in the resource's queue. Additional information such as number of discarded messages and times the queue has been full is also logged.

Message Statistics. Contains information on a specific message type (Transaction/State). Information such as the message delay is logged here.

Depending on the way the simulation is ran, the partial statistics are simply stored internally, recorded for later review, or displayed on the screen as they are generated.

Resource and Queue usage statistics are displayed with a frequency specified by you in a Simulation Options panel. The Message Statistics are maintained according to a probe frequency rate specified by you while entering a resource activity list. Only message types for which a Probe activity has been defined are surveyed.


Regardless of the way the simulation runs, a total statistical refresh occurs when the simulation ends, so that you can be assured that the final results correspond with the values obtained by the simulation.


You can review the statistical results interactively by opening results windows. He/She may inspect statistical information for all resources and their queues and for all messages for which a Probe activity exists. A Confidence-Analysis function for cumulative results is also integrated within the product.

In addition to the statistical views which are available automatically when the simulation ends (and available even as the simulation runs if you run the simulation at normal speed and with a finite notification rate), you may elect to preserve selective result values in a Results File of your choosing. The results stored in the specified results file are stored in a "Comma Separated Value" format and can be imported into any popular Spreadsheet or Statistics package. You define which results are to be stored in the Results File by defining a Results Template that contains filters indicating what resources you want to inspect and what associated information fields are of interest. Prophesy allows you inspection of the selected results file. You can copy selected information from this file to the clipboard, or apply Confidence Interval analysis over selected result samples. The contents of the Results File is additive, and in it you can preserve the cumulative results of several independent runs. It is up to you to decide when to clear this file.

Back to Abstraction Home Page