2 State Manager Overview

The State Manager (SM) is in essence a computer-based control system for the experiment. The experiment (a set of hardware devices and software programs) is seen by the SM exclusively through computer processes, dedicated to one specific activity, called associated processes or proxies (fig. 1).

The basic action by which the SM can control activities in the experiment is the exchange of messages with the associated processes. This constraint allows the SM to have a unique interface with the outside world: the specific control mechanisms are dealt with by the proxies.

The SM may be driven by command messages originated by other processes, called control processes. The use of an interactive control process is the normal way by which an operator can interact with the SM.

The SM incorporates a model of the different activities to be organised, which is essentially a description of the experiment. The problem of creating a control system is therefore equivalent to that of giving a good description of the experiment in terms of the objects being controlled and the procedures that operate on them. The SM program is the implementation of the model defined by the experiment description. This description, made by the physicist in terms of the SM language, is pro cessed by the SMI tools in order to produce a State Manager and its associated proxies.

Figure 1: the SMI environment

2.1 Object/message model

The approach adopted for modelling the experiment is based on an object-oriented decomposition. The experiment is described in terms of objects: an object may correspond directly to a concrete entity in the experiment (such as "gas valve 12"); it may equally represent a logical subsystem, or any abstraction used in describing the experiment provided it can be identified by a noun (e.g. "run", "trigger", "central detector").

The object-based model closely matches our own model of reality; therefore the experiment can be described with the same concepts and terms as we use in thinking of it.

The main attribute of an object is its state, the only one that is visible by other objects. The state is a variable that can assume any one of a list of values enumerated by the users. The normal practice is to define values that correspond to adjectives which could qualify the name of the object (e.g. the object "run" may be in one of the states "active", "dormant" or "paused"). An object operates on other objects by sending command messages to them. The communication mesh linking the o bjects carries the global flow of control in the system. Again, this model of interaction between objects is one that reflects our abstraction of reality. It allows concurrence in the execution of operations and the development of many threads of control.

2.2 Object behaviour

Objects behave as finite-state machines. A change of state is brought about by the receipt of a command. Once accepted, a command triggers the execution of an action; this eventually terminates when the object reaches a new steady state. An action is identified by a verb applicable to the object name (e.g. the object "run" may perform any of the actions "start", "pause", "continue", and "stop"). The corresponding command is identified by the same verb, which may be thought of as being used in the imperative.

An action consists of a sequence of operations, specified in the SM language by a list of instructions. These are essentially of two types: DO and IF. DO is an instruction that sends a command to another object; IF is an instruction that evaluates a Boolean function of the states of other objects, and makes a conditional branch depending on the result. While an object is executing an action, its state is undefined and no further command is accepted until the action is terminated. The final state reached after the execution of an action may depend on the results of tests performed on the state of other objects.

A command is not the only way of triggering an action: a state change in another object may provoke it; this type of dependence is specified in the SM language by a WHEN clause.

2.3 Communication with the outside world

The SM interacts with other processes through the exchange of messages. A control process may send a message to any object; the SM dispatches the command and initiates the action.

The proxies are seen by the SM through a special type of object in the experiment description, tagged with the attribute associated. These are different in that they cannot execute any action: a command received by an associated object is sent to the corresponding proxy. Conversely, a state change occurring in the entity controlled by a proxy is faithfully reflected by the associated object. The associated objects are, within the SM, the agents that make it possible to control the outside world. The communication between the SM and other processes makes use of an underlying package DIM ; therefore a distributed heterogeneous multi-machine configuration is naturally supported. In such an environment there is one SM process running in one of the machines, while other processes may run on any of the other machines in the configuration. The underlying communication package uses naming conventions to address remote objects correctly.

Independently of the physical configuration adopted (single-machine or multi-machine) it is possible to run more than one SM in the system. This is achieved by partitioning the system into domains, as is discussed in the next section.

Figure 2: External communications of the State Manager

2.4 State Manager domains

A domain defines the scope of visibility for the associated object's names. As the addressing of messages between SM and other processes is based on the object names, the domain establishes the boundaries of the SM control space. This is achieved by assigning a name to each domain. It is the task of the communications package to use the domain name and address the right object, indicated by the domain-object pair. The domain structure is superimposed in a completely transpa rent way; the experiment description contains no mention of the domain, nor need the associated processes have any special code to specify it.

The concept of domain can be applied, for instance, to the case of two SMs running in the same machine; one may be under test, while the other is used to control a production process. Partitioning the system avoids interferences when the SMs address distinct proxies that have the same name.

2.5 Hierarchy of domains

Links can be established between distinct domains, to allow a certain degree of visibility between SMs (fig. 3).

This type of relationship can only be hierarchical; the slave SM does not know by whom it is controlled, while the master SM must know which slave SM it is driving, since it can drive more than one at a time. The links can be established only at specific points in the slave SMs. These points are objects tagged with the attribute visible: they allow the slave SM to be seen by another SM as an associated process. Therefore it is possible for a master SM to declare an associated object (in its own domain) which will mimic the behaviour of the visible object in a different domain. All the commands directed to the associated object will be dispatched to the visible object, and state changes in the visible object will be reproduced by the associated object. The domain must be specified when addressing a visible object, because there may be visible objects with the same name in distinct domains; this is achieved by prefixing the object name with the domain name, the two being separated by a double colon (e.g. 2::A means object A in domain 2).

An example of application of these features is an experiment composed of subsystems (e.g. detectors) that can be run independently: they must be controlled by distinct SMs. At the end of the setting-up phase, the two subsystems will be integrated and the experiment will be run as a whole. There is no need to modify the original SMs: a third one may supervise them.

Figure 3: Hierarchy of State Managers domains