SEVEN

Note

SEVEN is the legacy name of the scenario engine and the name of the underlying scenario model

SEVEN (Scenarios Engine for Virtual ENvironments) is a scenario engine. It allows you to write and to use scenarios for you application. In a virtual environment, the goal of a scenario is to organize tasks that can and have to be realized. A scenario can be used in three different ways:

Constraint actions by scenario The user is constraint by the scenario, which means that he/she is allowed to only do actions described by the scenario. Especially useful for learning precise procedures, since the scenario makes sure no mistakes can be made. It is also possible to set a virtual human to follow the scenario for demonstrations purposes or collaborations.

Scenario as a support The scenario is used as a support to guide the user without constraints. It could highlight elements in the virtual environment to guide him/her through the experience, proposing possible actions.

Monitoring by scenario The scenario can be used passively, listening to the user’s progression. In this way, user’s actions or changes in the world state will drive the scenario forward showing user’s advancement.

Petri-net

SEVEN was created as an extension of Petri net, working on three concepts: places, transitions and tokens. Principle: when every place at a transition’s entrance got a token, the transition can merge these tokens into one, use this new token and then it assigns tokens to every place at the exit.

A place, in a n-safe Petri net, can contain several tokens, and a transition can consume more than one token. In our case, #SEVEN will allow only one token per place (1-safe petri net). So a transition must not trigger if a downstreeam place already has a token. Moreover, a transition cannot consume more than one token per place. Several places can have a token in a scenario

Scenarios use sensors and effectors to communicate with the virtual environment. Sensors can listen to the virtual environment and react to certain conditions. A sensor can wait for a specific state of the world, like a collision between two objects, to happen, it can also wait a user action, a constraint on a value to be met, ...

If all the conditions are fulfilled, the sensor will be activated and the transition can be triggered. If so, the effector of the transition will be executed. The effector can affect the virtual environment,for example display a message, perform an arithmetic calculation, change the color of an object, write into a file, ...

Both sensors and effectors work independently. A transition can have one sensors and one effector.

In the previous example, the sensor is waiting for a collision between the two cubes. When it happens, the effector is triggered and displays the message Well done!.

As soon as the scenario starts, the Initial places create a token to begin the scenario. During the execution of this scenario, the token travels through it to reach a final place. A scenario reaches its final state when every Final place in the scenario has a token, no matter other places.

Scenarios can enrich a scenario with sub-nets (diamond form in the figure below) and External-Net (square form), so we introduced the notion of sequence. A Sequence can be a simple place or a sub-net or an external-net. As they contain a sequence, sub-nets allow hierarchisation in a scenario for an easier understanding. Similarly, external-nets contain a seven scenario, which allows to reuse and factorise parts of scenarios.

State Machine

SEVEN was extended to handle state machines as they can be viewed as petri-nets with more constraints. In a state machine, only one state (equivalent to a place in a petri-net) can have a token. This also prevents a transition to go to more than one place. State machines in SEVEN share the same transitions extensions as the petri-nets (sensors, effectors, ...). While petri-nets are well suited to describe a high-level scenarisation of an application, state machine are usually prefered to describe the evoluation of a single object.

Decision Tree

SEVEN was extended to handle decision trees. Decision trees have a different kind of transition called Decision. Decisions will always trigger but they will provide the token in a different downstream node depending on the sensors results (true/false). Decisions trees can store data in the tokens through effectors or token assign and are meant to be resolved in one run by going from the root/initial node to one of the leaves/final node (meaning sensors/effectors should be atomic and short)