Actors

The following actors have been identified to be significant for a data acquisition control system (see also figure 53):

• Operator (human) The operator is a human being who uses a location independent human computer interface to interact with the DAQ system in order to perform configuration and control operations. By location independent we mean that the operator can communicate with the data acquisition system from any place outside the system, no matter which geographic location he has or which system platform he uses. The operator may also request information about the current system configuration and the progress of the systems operation.

• Data Faucet (software) The data faucet represents the entry point to the system. It handles the requests from operators, translates them into a system internal command sequence and takes care of properly forwarding it to the control system. It also gathers results from operations and prepares them in a way that they can be displayed in user readable form through a user interface. Data faucets may be created and removed by the operator at any time. They sit close to the DAQ system so that information exchange can be performed efficiently and in order to allow disconnected operation. It must be possible to create at least one data faucet (the operator console) in order to guarantee control over the DAQ system.

• User Interface (software) The user interface is a system that does not belong to the DAQ control system. Commands to and from the control system flow through it. For an evolvable system we want to be independent of the user interface technology. Therefore we split the human-computer interaction into a data faucet and a concrete user interface in the model. The former one understands an internal language to interact with the control system. The latter one has to translate commands that are issued by operators into this internal format. The internal means for information exchange must follow some standard so that deployment in a heterogeneous environment becomes feasible. We use the CORBA component middleware for this task. The commands at operator level and at system level need not be isomorphic. A single command as offered by the user interface may be translated into a set of interaction steps with the data faucet and the control system subsequently.

• Smoke Sensor (software, hardware) A smoke sensor is an actor the resides in a subsystem that lies within the scope of the DAQ control system. It notifies the control system whenever the subsystem to which it belongs deviates from its specification. There will be many instances and types of smoke sensors, depening on the facilities that have to be monitored. Both hardware parts and software elements must be observed. The smoke sensor is not subject to our study, yet it is mentioned in the use case model. It can be implemented as an ``agent'', thus just representing a task located within the scope of the control system. Indeed it is just itemised separately as it has to have special access rights to the system internals.

• Task Capsule (software) A task capsule comprises the actual programs that shall run in the data acquisition cluster. These tasks consist of application programs as well as core system functionalities. The latter ones include policies on how to exchange control and information request commands between the nodes of the computing farm. Core system tasks are also monitoring programs that continuosly inspect vital system properties and set alarms if the system deviates from its specification.

• Logbook (software) The logbook is a distributed persistent data store for configuration data, task status and logging information. Its design and implementation are not covered by this work.