Experiment Control System Choice

Introduction

The system controlling an experiment can loosely be divided into three layers: the experiment control layer (ECS), slow controls layer (aka SCADA or DCS), and the field-bus level that actually communicates with sensors and actuators. Here I discuss the ECS, the level that has overall control of the entire running environment. See Slow Controls Framework Choice and Field Bus and Controller Specifications for discussions of the two lower layers.

The LHCb web page nicely describes the role of the ECS: "(The) Experiment Control System is in charge of the configuration, control and monitoring of all the components of the online system. This includes all devices in the areas of: data acquisition, detector control (ex slow controls), trigger, timing and the interaction with the outside world."

State Machines

ECS's often involve use of software state machines that step through a pre-defined sequence in order to move the experiment from one state to another (e.g. booted --> configured --> downloaded --> whatever). These state machines change often, unlike those in factories, which remain fairly stable once they are tuned. Thus in factories the state machines usually reside in PLC's and are programmed by process engineers. In contrast, it is impractical to deploy many of our state machines in PLC's due to their rapidly evolving nature and the need for physicists to modify them, so we use high-level software instead.

AFECS from the JLab DAQ Group

The JLab DAQ group has been working on experimental controls for some time, first as a framework for DAQ run control, and then as a complete ECS. Although stand-alone state machine software is available (SMI++/DIM from CERN, others), the DAQ group product AFECS seems to meet all our needs. AFECS stands for Agent Framework for Experimental Control Systems, and the main innovation is that agent-based techniques are used throughout. Agents are software constructs that represent real outside entities. To communicate with an outside entity you simply talk to its representative agent in the software world in a standard way, and the agent takes care of the actual communication (via Ethernet, through a bus or controller, via a special protocol, etc).

AFECS uses an xml-based language developed at JLab (COOL, or Control Oriented Ontology Language) to describe state machines, allowable transitions, etc. AFECS also accepts SMI++, a state machine language used extensively at CERN.

ECS vs Slow Controls

It is not clear where the dividing line between the ECS and slow controls (DCS) systems should be drawn. Each can do part of what the other does. E.g. AFECS can talk to devices directly, without the need for a DCS layer. And DCS systems such as EPICS can be used to some extent for experiment controls. AFECS is designed to take over much if not all of what DCS's do. But most DCS's provide suites of applications and utilities that are not available in AFECS yet.

Although we could write all the utilities missing in AFECS, it seems to me that we might as well take advantage of what is provided by DCS's, particularly as many of them have large development bases, and AFECS only exists at JLab.

Thoughts on the use of Web-based vs Application-based display

We need gui's to both display information and to control the experiment. Traditionally, applications running on machines in the counting room have been used for this. Recently web-based displays are being used for information display, but not so much for control of the experiment due to security and other concerns.

For Hall D either gui stragegy, web-based and application-based, might be used. Although most systems continue to be application-based, CLAS has had some success using servlets and Flash to generate web-based information displays.

I consider it an open question as to which strategy to adopt. Web-based is less familiar, but solves the global information distribution problem. And with appropriate security mechanisms web-based displays could be used for control as well. But more tools exist to create application-based displays, and it may be marginally easier to develop them.

Please send me your thoughts...