To run the lift demo:

tkeden Run.e

Run.e refers to five files that can be included: liftdemo.d, liftsim2.e, which deal with the basic manual interaction and the simulation of a particular user scenario, and liftengg1.e, liftengg2.e, userlift.e which support manual interactions and automatic responses that are similar to normal lift operation.

Will discuss the files sequentially beginning with basic manual interaction in the role of scenario designer or user [liftdemo.d]

Here are some simple direct interactions with the model that illustrate
the way that the lift artefact can support 'human computing' activities:

%eden

locX = 0;
/* move X into the lift */

locX = _liftfloor;
/* move X out of the lift */

_liftfloor++;
/* move lift upwards one floor */
_liftfloor--;
/* move lift downwards one floor */

%donald

open3 = true		# door 3 open
open3 = false		# door 3 closed

button1 = true		# button on floor 1 selected
button1 = false		# button on floor 1 not selected

car1 = true		# button 1 in lift car selected
car1 = false		# button 1 in lift car not selected

%eden

/* equivalent to the above redefinitions are: */

_open3 = 1;	/* open door 3 */
_open3 = 0;	/* close door 3 */
_button1 = 1;	/* select button on floor 1 */
_button1 = 0;	/* deselect button on floor 1 */
_car1 = 1;	/* select button 1 in lift car */
_car1 = 0;	/* deselect button 1 in lift car */

Including the file liftsim2.e specialises the model to a specific scenario in which the lift operates in 5 storey building:

There is a 'procmacro' called playlift that is invoked to display
a particular scenario where X, Y and I all get to the wrong floor.

To initialise the lift situation, type

initplay();

To invoke the scenario, type

%eden
playlift();

To switch a commentary on and off (in the console window), use

%eden
commentary = 1;
commentary = 0;

The speed at which the scenario is executed is determined by the
observable 'secs': by default, this is defined thus:

secs is (commentary) ? 3 : 1;

- which means that each action is displayed with a delay of 3 seconds
if the commentary is requested, and with a delay of 1 second otherwise.

Playing through the scenario shows how interaction with the lift model
can be driven by the human interaction, and how the state of model lends
itself to rich interpretation. It illustrates interaction with the model
of a manual rather than automated nature.

Before introducing automation, it makes sense to set commentary to 0, so
that the delay in simulating actions such as lift movement is set to be 1
second rather than 3:

commentary = 0;

(For even faster results assign 'secs' to 0.)

You can re-initialise the state at any stage by typing

initplay();

To illustrate how automation can be introduced, use

include("liftengg1.e");

- this file shows how automated actions can be introduced to carry out some
of the sequences of actions that would normally be performed by the lift
itself, such as switching of the call buttons and opening / closing the lift doors when the lift arrives at a destination floor. To use this, simulate the
selection of a button on a floor or in the lift, as in

_car3 = 1;
_button5 = 1;

Then invoke

initup();

or

initdown();

to initiate the lift movement in the direction of a destination floor. The
automation is only partial: control returns to the user when the lift has
successfully completed the button and door manipulation procedure at a floor.
Whilst the automated activity of the lift is in progress, the user can
intervene, e.g. to press a button, or move a person into the lift 'at the
proper time' (though in fact the movement is not restricted by the absence
of the lift, or whether the lift door is open).

The automated activity (see the procmacro visitfloor) is performed by 'execute' instructions - these in effect automate precisely those changes of state that
the user carries out manually. Note that the user can determine which button observables to manipulate when the lift is at a given floor 'by inspection'
- the execute instruction mimics the construction of the observable name from
the current location of the lift. Compare:

_car2 = 0;

execute ("_car" // _liftfloor // " = 0;");

A more sophisticated engineering version is obtained by including the file liftengg2.e.

In this model, the motion and scheduling of the lift is automated, and the buttons on the floors and in the lift can be selected by using the mouse. (Though this selection may require holding the mouse button down for long enough to ensure that the system is not executing a delay() routine, during which it is unresponsive to mouse events. This is something of a problem in that a delay routine operates whilst the lift doors are open.) Selecting buttons in the lift whilst it is in motion is also tricky.

Finally, you can introduce

include("userlift.e");

to see how the role of a model user (in this case, X) can be automated. To run the model requires that you first locate X at a particular floor, with a specific destination in mind. For example:

locX = 3;
_destX = 5;

places X on floor 3 from which they will automatically carry out the necessary actions to reach floor 5.


