Project

General

Profile

A0 Project

Hi Helen,

Below is what we understand to be the request for Ron's time.
Please look it over, talk it over with Ron, and let me know if you are in agreement.

Jim

Request

Helen Edwards has requested Ron Rechenmacher's help with the RF project at A0.
Her support person, Michael Davidsaver, is leaving the lab in less than 2.5
weeks (on Mar 6th). Loosing Michael puts this project in a state of crisis. Michael
currently maintains the DOOCS installation used to control and monitor the
experiments they do at A0 (DOOCS is a control system developed at DESY). He
also adds and maintains code for new and existing instruments
and also maintain display elements. This control system is also used for
data acquisition. Michael and Ron are two people at the lab that know DOOCS
and can do this work. Helen has expressed interest in moving the operation to
EPICS, partly due to the lack of DOOCS expertise at the lab.

The main reason for this request is that the A0 operation needs support
and additionally, the related LLRF operation needs support and deployment work.

For A0, the support entails mainly answering questions from the user/operator base
of approximately 15 people. A good portion of the questions are a direct result of
a minimal "alarms" implementation and documentation in addition to a lack of robustness
in a couple of the key servers. In addition to answering questions there
are system administration tasks (i.e. maintaining the current configurations).
It is anticipated that these task will require a minimal effort. There is currently no
new server/driver code development for A0.

For the LLRF system, one of the current activities is to deploy the same exact system that
is operating at A0 (a DOOCS based system) at NML. So, there is currently no new
server/driver work.

For the LLRF system, there is also a request to support the development system at FCC.
At FCC, there is approximately 2 people would would be asking question as they arise.
It is anticipated that this will require a minimal effort for the existing DOOCS based sytem.

Helen has a req in HR to replace Michael. The goal is to fill this req
within five weeks.
Ron must be involved in the interview process.

Work Phases

We have identified four phases to the requested work.

(1) 2/23/09 until 3/6/09
Understand the system Michael has in place while he is still here.
Effort: 1.5 days per week (i.e 3 half days) - %30
  • learn (or verify) Michael's configuration for A0
  • help setup New Muon test stand.

During this time, Helen is to make sure HR is working on getting
candidates to fill the job req.

(2) 3/6/09 until 3/27/09
Temporarily take on Michael's role, as described in the introductory text.
Effort: approx %30, present at a0 4 half days (PM - i.e. M,T,T,F) for
support.

(Note: DDS evaluation will continue during this time period)

This plan does not cover continuing support efforts beyond 3/27.
Requests from Gustavo's group to support or develop code for test stands
or hardware must
come directly from his group to ours.

(3) 3/30/09 until 4/10/09
Training of new hire.
Effort: 2 weeks - 3 days solid, then 4 half days - 50%

A new hire must be available at this time to continue into this phase of
the plan.

(4) 4/10/09 and after
Limited consultation time. Follow evolution and software infrastructure
development.
Act in a limited backup role. The goal is to involve AD controls and
leverage
any ANL EPICS developments.
Effort: 10%

Notes

For phase (4), we can use this time to discover opportunities to use shared
software infrastructure and gain more expertise with large-scale distributed
control system / DA toolkits such as EPICS, for the benefit of future experiments
at the lab. The benefit to CET here is to explore software frameworks that
operate at lower-levels (nearer the hardware). Such systems allow for quicker
deployment of test stands and integration of new hardware into existing
systems, largely because of the abstraction they define. These systems have
design elements that can benefits cluster-related projects such as LQCD
reliability and workflow, and the JDEM QC framework. The elements
we are immediately interested in are the messaging protocols, uniformity
of access, and wide range of higher-level applications, such as GUI
builders, configuration editors, archivers, and alarm tools.