3 Designing the Control System
The application of the SM concepts to an experiment should follow a number of steps, where the control problem is progressively narrowed down to a manageable level of complexity.
First of all, one should indicate what are the broad areas where an independent control activity is necessary (independent means that the areas may be operated independently, but interactions between different areas are not precluded); these areas will eventually become SM domains. An examples of these areas in an experiment are "run control" or "detector control"; if the apparatus is composed of several detectors, each of them may belong to an independent SM domain; a particularly comple x activity may be partitioned into distinct domains; the coherent running of the whole experiment may require a recomposition of tasks, by an hierarchical structure encompassing several domains. There is a wide freedom in the various choices, but it is important that each area be closely related to entities or groups of activities that are meaningful in the experiment context. Then, for each SM domain, one should determine what are the controllable items: these are the real entities that can be driven by co mmands and are susceptible of assuming a state; for each of them a service program will have to be provided, which will drive all the activity related to this entity, according to the instructions received by the SM (the program will be associated to an object in the SM). The experimenters may find it useful to define other objects related to logical entities (called logical objects throughout this manual, as opposed to associated objects) in order to represent the various modes of operating the experiment (such as "data-taking", "calibration" etc.) or the collections of simpler objects (such as "central detector", which for instance may be "ready" when all the components of the real central detector are ready).
A model of the behaviour of the given domain must be formulated as a SM program (a normal text file, that can be written using any text editor). There is a simple language to be used, which contains all the primitives suitable to this purpose (see figure 4 for an example).
The SM program describes the objects previously defined, the states they can take and the commands they accept in each state. The actions generated by each command must then be described: they consist of a sequence of instructions, each instruction being an executable statement of the experiment description language. The main types of instructions are DO and IF. DO is an instruction that sends a command to another object and therefore allows controlling the process of hierarchically dependent objects; IF is an instruction that allows conditional branching on the state of other objects. Of course Boolean expressions referring to the state of many objects are allowed by the language. The language contains also a WHEN statement, that allows the SM to trigger an action when there is an unsolicited state change in an object. The service programs must be prepared as well: they are the proxies in the terminology used throughout this manual. These programs operate on the apparatus upon receiving command messages. Their behaviour must be represented by a state machine. The generation of the code implementing the state machine is assisted by the SMI tool set; to this purpose, the behaviour of the associated object must be fully described, beyond what is normally needed by the SM. The functional part of the service program is left to the programmer, the communications with the SM program beeing provided by a set of library routines
The implementation phase consists of the generation of the SM (one or many) and of all the associated processes. The SM description is translated to an intermediate format that is then read at run time by a generic State Manager engine, that instanciates all SMI objects and drives the SM model. The proxy skelettons are also generated from the SM description.
The run-time system consists of one SM process per SM domain and all its proxies. The order of activation is not relevant, since the mechanisms by which the SM and its partner processes know about each other are irrespective of who has started first.