Slow Controls Framework Choice

From GlueXWiki
Revision as of 10:37, 30 January 2008 by Wolin (Talk | contribs)

Jump to: navigation, search

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). Controlling the devices via the field busses 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 experimental control layer (ECS), the system that 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 some DCS software can function as an ECS, and some ECS software can function as the DCS. Some decisions we need to make are what software to choose for the top two layers, and where to set the dividing line. See Slow Controls Specifications for a discussion of the choice of field busses.


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 all 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), could not accomodate 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, 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 get older and more outdated.


ICALEPCS Conference

Over the years I occasionally attended the International Conference on Accelerator and Large Experimental Control Systems conference (ICALEPCS), which covers the latest in experimental controls systems. ICALEPCS turned out to be critical for mly keeping up with the latest developments, alternatives to EPICS, etc (we should send at least one person to every ICALEPCS conference!).


Possible Slow Controls Framework Choices

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

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 slow 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 world-standard EPICS, NOT 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


Some Concerns about EPICS in Hall D

  • Will promising new utilities and applicatios be fully developed?
  • How much will we need to write?
  • Non-VME interoperability with Allen-Bradley PLC, OPC, CAN, I2C, and SNMP?
  • How many custom Linux drivers we'll 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, and when do we use others (e.g. MonAlisa)?