Slow Controls Framework Choice

Introduction

Online control systems can be roughly divided into three layers, with the dividing line between them not particularly clear. At the bottom are the devices (sensors and actuators) that are controlled by some sort of field bus (CAN-bus, I2C, CAEN-NET, Ethernet, etc), and the controller itself. Talking to the field bus controller is the slow controls layer or framework (also called a SCADA system or Detector Control System (DCS); examples include EPICS, PVSSII, DOOCS/Tine, etc). Finally on top of slow contols and everything else is the Experiment Control System (ECS), which coordinates information from the entire detector (slow controls, databases, trigger configurations, etc). The ECS often includes state machines that e.g. enforce the rules needed to start a run (check if HV is on, if not stop and warn operator, if on check if discriminator thresholds are downloaded, etc).

Note that DCS's can sometimes function as an ECS, and ECS's can sometimes function as a DCS. Some decisions we need to make are what software to choose for the ECS and DCS, and where to set the dividing line. See Field Bus and Controller Specifications for a discussion of field bus choices.

Finally, Wikipedia has a number of articles on controls systems. Start with the article labeled "Process control," which has many links.

Slow Controls Frameworks

Those who know me know that for a number of years I've been looking for a compelling alternative to EPICS, which is used extensively at JLab by the accelerator and the three experimental halls. I learned about EPICS in the late 90's (I wrote many applications for the CLAS online) and did not like what I saw. EPICS even then was outdated, required VME and VxWorks, was expensive to use (controls hardware and software licenses), had difficulty accomodating myriads of new types of controls hardware, usage was manpower intensive, had a one-size-fits-all mentality, was developed when devices were stupid and it still assumed so, and seemed to not be moving with the times (e.g. Java usage was unknown, gui-building was archaic with very limited functionality, utilities from the dark ages were still standard, etc). Things seemed to be changing so slowly, if at all, that I figured EPICS would just continue to become more outdated.

ICALEPCS Conference

The International Conference on Accelerator and Large Experimental Control Systems conference (ICALEPCS), which covers the latest in experimental controls systems, turned out to be critical for keeping up with the latest developments, alternatives to EPICS, etc (we should send at least one person to every ICALEPCS conference!). Much of what follows is based what I learned there.

Possible Slow Controls Framework Choices

As of the last ICALEPCS conference (this fall), viable choices for the Hall D slow controls frameworks were:

System	Notes
EPICS	used at about 1/3 of sites reporting, incl. JLab
PVSSII	commercial, used extensively at the LHC
DOOCS/TINE	used in Europe, esp. Germany
TANGO	relatively new and advanced, used at a number of European synchnotron light sources
others	not compelling

Discussion

Some information from the recent conference and other sources:

• PVSSII usage in HENP is not increasing, it is basically only used at the LHC
• Not everyone at the LHC is happy with PVSSII, nor is it used for all controls applications
• DOOCS/TINE and TANGO work well for many sites

but

• EPICS recently seems to be advancing rapidly, and is catching up with the rest of the world
• EPICS has a large, active user base who wants to bring it up-to-date
• Java was the most frequently used word in conjunction with EPICS
• Many new up-to-date EPICS applications are being written, esp. Java applications
• EPICS no longer requires VME/VxWorks, some sites are Linux-only
• A new Eclipse-based development envionment (Control Systems Studio, or CSS) seems very interesting

so

• I think Linux-only EPICS is the correct choice for Hall D, as none of the others are a compelling alternative

EPICS Usage in Hall D

• Use the world-standard EPICS, NOT the JLab accelerator standard version (which can get way behind)
• Linux-only, no VME/VxWorks
• Use CSS as foundation
• Use Java extensively
• Avoid sub-standard, out-of-date utilities and applications
• Choose devices that use standard field busses to avoid having to develop custom drivers
• EPICS has a driver that can talk to Allen-Bradley PLC's
• Use EPICS only as a SCADA or supervisory layer, all control loops belong in lower layer (in PLC or in device itself)

Some Concerns about EPICS in Hall D

• Will promising new utilities and applications be fully developed?
• How much will we need to write ourselves?
• Non-VME interoperability with Allen-Bradley PLC, OPC, CAN, I2C, and SNMP?
• How many custom Linux drivers will we need to write?
• When to use soft-IOC vs. portable CA server?
• Where does slow controls end and experiment controls begin?
• When do we use EPICS utilities, when do we use others (e.g. MonAlisa), and when to write our own?