In MINER talk, the specification of an experiment is called a MINER Scenario, in short Scenario. The Scenario is one of the core entities when working with MINER and it is therefore vital to understand this concept.

A MINER Scenario is a specification of an experiment which consists of multiple activities. It is a complete and final specification in the sense that it does not contain templates or variables that are expanded at a later time. Each activity is defined in a MINER Action, in short Action.

An Action specifies at least:

• the MinerTool to use
• the configuration of the MinerTool
• the ToolProxy(-ies) where the MinerTool is employed

Additionally, an Action can define the Results that the MinerTool must produce, the active period of the Action and a few more properties.

A Scenario is defined by a set of Actions. Nevertheless, the Actions are not directly attached to a Scenario object. Instead, there is an intermediate level called MINER Task, in short Task.

 

A Task is used to logically group a set of Actions. As an example, one might define a Task “Background traffic” which contains several Actions – each of them working with a specific type of traffic generator.

An Action can be defined to start later and end earlier that its parent Task. Equally, a Task can start later and end earlier than its parent Scenario.

Sample scenario

The following sample shows a MINER Scenario that consists of the 3 Tasks “IPPM”, “Background Traffic”, and “Capture”. The Task “IPPM” performs active measurements according to some IPPM specifications. The Task “Background Traffic” contains 3 Actions, each of which actively generates traffic. The Task “Capture” contains 1 Action that is executed on 2 ToolProxies. The image below depicts the Scenario tree.

Compared to its parent Scenario, a Task can start later (never earlier) and finish earlier (never later).  In the same way, an Action can start  later and end earlier than its parent Task.  The Tasks and Actions from the sample Scenario can e.g. be shifted on the time axis as shown in the image below.

Additionally, it is now possible to trigger the activation of an Action via a user-defined Event. In this case, the Action goes through its initialization phase in the same way as any Action does. However, when the Execution enters the active phase, this action remains inactive until the user (client application) generates the activation event. In the same way, an Action can be deactivated via an event.