|
EUROPEAN SOUTHERN OBSERVATORY |
Re-Engineering Project: Structure and OperationREVIEWLSO-PLA-ESO-9000-1/v-0.9.3 |
Prepared | Olivier Hainaut | 2002-02-10 |
Reviewed | Michael Sterzik | 2002-05-13 |
Released | Jorge Melnick | 2002- |
SciOp
Internal Use Only
0.1 | 2002-02-10 first draft, ohainaut |
0.9 | 2002-02-22 Major revision after general meeting |
0.9.1 | 2002-03-20 Typos and html fixes. No text change |
0.9.2 | 2002-05-13 Comments by RME, PLE, EBA, MST incorporated, stylistic changes, and comments (msterzik) |
0.9.3 |
2002-05-19 Additional comments from RME and JME incorporated. Broadcasted review version - ohainaut |
This document is the result of the discussion
that took place on Thu. 2002 Feb 14 at la Silla and Vitacura,
based on an earlier draft of this document. Presence at that
meeting, in La Silla, Andres Gonzalez, Ariel Sanchez, Cristian
Esparza, Eduardo Celis, Emilio Barrios, Francisco Labrana,
Gaetano Andreoni, George Hau, Jose Cortes, Karla Aubel, Lisa
Germany, Malvina Billeres, Martin Kurster, Olivier Hainaut,
Rolando Vega, Ivo Saviane, and in Vitacura, Gaspare Lo Curto,
Kate Brooks and Leonardo Vanzi.
Version 0.91 was released to the LaSilla audience for
discussion and comments. These comments were edited by MST.
Comments included are written in italics. Regions affected by the comment are in red, and new version of the red text are in green. Contributions
are from Paul LeSaux (PLS), Rene Mendez (RME), and Michael
Sterzik (MST). Emilio Barrios (EBA) detailled his comments at
/sci/facilities/lasilla/telescopes/3p6/tecdoc/tmp/LaSillaSciOpPlan.html
. The incorporation of these comments lead to v.0.9.2. Additional comments
were received by Jorge Melnick. These and additional input from O.Hainaut
were included to constitute 0.9.3, which is released for a second round of
comments.
This document discusses the general structure of the Science Operation Department (SciOp) of La Silla, in the framework of the restructuration of the 2p2, 3p6 and NTT teams. This document will eventually become part of a larger document describing the Science Operation Department as a whole.
It will be clear to the gentle (JME) reader that the TIOs are getting much more responsibilities than in the past. The reason for this is that the TIOs are the ones who actually operate the observatory (JME) telescopes, not the astronomers. Indeed, TIOs tend to have a longer life time in the organization (time scale of 10 yrs) than the astronomers (time scale of 2 yrs), therefore, they can accumulate much more experience and have a very broad overview of the telescopes and instrumentation. This is acknowledged in this plan, whose global idea is to distribute the responsibilities to whom they naturally below: a question about the best strategy to observe the spectral variability of a quasar in the near IR is for an astronomer, but a question about the best way to select and acquire a guide star in a crowded field for spectroscopic chopping-and-nodding observations is for the TIO.
In this document, "he" and "his" refer to the position described. In practice, these position can be occupied by people of any gender.
[1] LSO-PLA-ESO-90000-4 SciOp Re-engineering: SciOp communications
[2] LSO-PLA-ESO-90000-5 SciOp Re-engineering: Administrative and Managerial internal structure
SciOp provides astronomical data to its clients,
as well as the information needed by the clients
The data produced by SciOp (including those
produced by Visiting Astronomers) must be of the best achievable
technical quality (e.g. instrument always in focus), and must be
calibrated -or, more specifically calibratable, i.e. they must be
accompanied by a set of auxiliary data that allows the astronomer
to fully remove the instrumental signature of the instrument
(flat field, standard stars, etc.). These auxiliary data are
defined in the calibration plan of each instrument.
In more details, the scope of SciOp is:
The "clients" of SciOp are the members
of the international astronomical community at large, and in
priority the astronomers of the ESO member states.
More specifically, these includes:
RME, MST: we do not agree. While SciOp should support instrument + telescope operation and some basic set-up tasks, astronomical support should not be included for visitor (or "guest") instruments under *any* circumstance.
Reply: OK. Text modified to make this clear:
From an "ISO-9001" point of view, the processes that belong to SciOp are the following:
COMMENT: RME,MST: not our role to formulate a scientific questions for VA!.
Reply: OK: REMOVE... >i.e. helping the astr...question<.
to prepare a good proposal that will get time (assuming of course that it is a "good" question)
COMMENT: RME: only the technical aspects of the proposal.
Reply: OK. Text changed:
to prepare a technically sound proposal that will get time (assuming of course that it is a "good" question),
to prepare his observations so that they optimally reply to his question, help him performing the observations, or perform them ourselves (all flavors of Service Mode), and finally help him in the data reduction (not by reducing the data for him). Basically, all the technical aspect of his question are our job: with our help, he should find trivial to reply to his astronomical question.
The SciOp Department will be constituted of Astronomers, Telescope and Instrument Operators (TIOs) and Operation Engineers. The main differences with the current Team structure are the following:
COMMENT: PLE: I think that the redundancy is, in general, not that much otherwise this would mean we have been very unefficient since 1995 : I am precisely feeling the opposite. Anyhow this reengineering process may try to assess these redundancies more accurately.
REPLY: Right. Not redundant WITHIN the team, but from team to team. For instance, each team has a documention officer, SciOp will probably have one. Changed:
..., to remove the duplication of tasks that currently exists because of they are done independently in each team,...
COMMENT: EBA: Regarding the Electronic Function scope I'm in favor to keep J. Vilaza and J. Santana as a day Telescopes Controller to deal with all the maintenance tasks together with Operation Engineers and provide coverage for the instruments exchange and daily startups.
REPLY: This is the idea: that LED provides "operation support", who should be Santana/Vilaza -at least at the very beginning, till other members of LED. are certified to perform these tasks. However, the overall coordination stays with the telscope coordinators in SciOp, which eventually accecpts the work done by LED.
COMMENT: JME: I do not think this is a good idea. It will dilute the responsibility and coherence of LED
REPLY (ORH): the idea is not to tell LED what they should do. Nevertheless, it is important (-critical-) that the expertise of the current electronics be passed to LED. This is twofold:
COMMENT: MST: Another critical deficit is that SciOp - in the current configurtation - does not include a hardware engineer with broad system knowledge (a system engineer). In the case of the 3.6m telescope it was essential to have the system engineer close to operations, as several operational problems could only be correctly indentified and solved by understanding the complex interrelation of mechanics, electrics, electronics and software.
- direct electronic expertise: it would be unrealistic to pretend that all their knowhow is completely described in the written documentation, however complete. Indeed, the teams currently use the procedures as support of their actions to guarantee that these are performed in a complete and repetitible way, but does not guarantee the swiftness of these actions, nor necessarilly their context
- hardware/system overview: currently, the electronic engineer of the team is also acting as system engineer, keeping the overview of the whole system. We consider critical that someone in LED 1) preserves that knowledge and overview of the system 2) disseminate that knowledge into LED.
REPLY: this is the idea of the "close connection" with LED, which has to include a system eng. (probably R.Parra), who will be the supervisor of the technicians.
COMMENT: JME: I really think that we should switch modes asap aand not have this mode of LED people with "historic" ties with SciOp. Better to have a mode where LED has a Telescope Support Group headed by one of the "oldies".
REPLY: ok with the Tels Supp. Group lead by one of the current engineers. However, it is important that more than one person in that group has actual experience with the on-line work on the telescopes.
All these comments lead to this new version:
COMMENT: EBA: If the team wants to improve the first troubleshooting level, SciOp have to have the following function scope or level of expertise on: Software, Electronic, Optics, Day AND/OR Night Operation, Safety, Cryogenic, Administration, Astronomy, Weather Conditions, Data reduction (As a reference check the Team Task section 4.2.4 on the The Team Theme Plan). If not, we will be back to the Night Assistance and the Ing. Operation Group (as I know, like Paranal).
REPLY: Agreed: we should maintain first level of troubleshooting in the areas mentioned. Added:
The expertize to perform first level of troubleshooting and basic preventive maintenance should be maintained within SciOp.
COMMENT: MST: essentially correct, the question of INSTRUMENT CHANGEOVERS HAS TO BE ADDRESSES for the 3p6 (operations? engineering? mechanics?).
REPLY: Any task is either performed internally (SciOp, eg. routine maintenance measurements performed by running and interpretting a template script), or externally, e.g. instrument change over. In that case, the provider is responsible, and SciOp accept (or not) the job done. Added:
In that framework, each task will either be performed internally (according to internal SciOp procedure), or externally (e.g. 3.6m top ring change will be handled by LED). In case it is performed by an external provider, SciOp will accept (or not) the job done.
The main difference between La Silla SciOp and
Paranal SciOp is that, in La Silla, SciOp "owns" the
telescopes and instruments, on which the support teams and
departments will perform work for us. In Paranal, the Engineering
Dptm owns the telescope and instruments, and lend them to SciOp
for the night. The main advantage of the La Silla scheme is that
SciOp owns the complete processes (c.f. previous section).
COMMENT (JME): what is the main disadvantage?
The main disadvantage of this scheme is
that most of the maintenance work will be "outsourced" to LED; to work properly,
it will require a very good coordination. This makes the role of the Telescope
Coordinator crutial.
Each instrument (e.g. EMMI, WFI...) will have an INSTRUMENT SCIENTIST (astronomer) and an INSTRUMENT TIO. Together, the Instrument Scientist and Instrument TIO form the INSTRUMENT CORE that concentrate all the expertise on the instrument: if there is some info or knowledge on the instrument, the Core should have it.
PLE: Until now an important part of that expertise has
been located in operation engineer, team electronics and optics
(A. Gilliotte).
MST: It appears reasanable that some specialized
experience will stay with these experts (e.g. optical layout,
cryogenics, electronics).
REPLY: OK. text changed:
CORE that concentrates all the operation-related
expertise on the instrument: if there is some info or knowledge related to
the operation of an instrument, the Core should have it. Obviously, some
of the specialized experience will stay with the corresponding expert (e.g.
optical layout, cryogenics, electronics...).
The role of the instrument scientist will be very similar to that of the current instrument scientist, i.e. more specifically
It is important to note that the SciOp Operation Engineers will be deeply involved in most of these points. Also note that it is not expected that the instrument scientist will perform all the support on his instrument.
The instrument scientist will be assisted by a TIO, who will be have expert knowledge of that instrument, both for day and night operation. The role of the Instrument TIO can be summarized as following:
It is important to note that the Instrument TIO does not have to work only on that instrument. The "Instrument TIO" job is more a background task that he can perform during his "background turno" (former Mid-Day/Mid-Night, cf below), during the night (long exposures), during the day (phone calls), etc... While it is desirable that he keeps accumulating experience on the instrument (e.g. operating it at night, performing set-up at day, etc), it is also important that he spends some "background" time on the instrument, e.g. when performing some tests while it is in the lab. In summary, the actions related to the "Instrument TIO" job have a time-scale of weeks/months (following up problems, testing new modes) and not day-by-day.
Also, only one TIO is "Instrument TIO"
for a given instrument, not 2, in order not to dilute
responsibility. Of course, the Instrument TIO can appoint one or
various delegates, for instance in his contra-turno, or to tackle
with a specific issue, but he will remain the one
"officially" in charge.
COMMENT (JME): Really?
REPLY: Yes. We consider important that one person tracks things down and responds.
COMMENT: PLE, MST: At least for a transition period the Instrument
TIO should get trained her/himself by operation engineer ,
electronics, optics an whoever else.
REPLY: OK. Text added:
To reach the level of full "Instrument TIO", it
is likely that some additional training will be required by the operation
engineer, electronics, optics, and/or whoever needed.
COMMENT: PLE: Which instruments are available in off line in a lab
? Formerly at 3.6 in particular it was only possible (but almost
never allowed) to use most instruments during their runs. Are
they still such cases?
REPLY: MST: At the 3.6, EFOSC, CES and later
HARPS have the possibilities for off-line calibations (CCD
testing, wavelength stability, resolution test). In the case of NTT for instance all instruments are always
mounted but dayly tasks often do not leave time for getting
expertise or testing improvements.
COMMENT: PLE: It may be necessary to drop some of these tasks and/or to
find ways to make other ones faster ( more automatic ).
In the particular case of new instruments ( HARPS ) I feel
the need to express my previous experience for instance with EMMI
: as we tried to integrate softly the newcomer without disturbing
La Silla operations, no special "Instrument Force" was
dedicated to it, as all of us kept there full foreground duty.
This led to a period of at least one year during which we
operated the instrument without knowing it reasonably well and to
a setup quality which I later on considered retrospectively
shameful. I hope we can do it better next time.
I mean we'll be able to dedicate a team full time or so to the
new instrument. I have always wittnessed this duality at La Silla
: everybody is shared in variable % between two kind of
tasks :
- foreground routine or trouble shooting tasks needing clockwork
turnos to ensure full coverage
- background development and improvement activities with flexible
schedule to be here when "things" happen.
For me, this document is saying that the background % should
increase for every TIO. So unless we assume TIO are not busy
enough presently, their foreground % must decrease.
REPLY: MST: Infact, I do feel that operating with 3 TIOs/per turno/per
telescope leaves free resources that can go in a higher
background %. E.g. it should be sufficient to operate the 3p6+NTT
with 2 day + 2 night + only ONE day/night TIO, free one fill
day/night TIO for background...)
REPLY: ORH: we should aim at avoiding the EMMI-like situation at all cost:
an instrument arrives, it is commissioned, then accepted -or not. In this
document, we have the right to be idealistic.
From the administrative point of view, the "Instrument TIO" title will appear in the Goals and Objective. The evaluation criteria will be (these are examples, not an exhaustive list): efficiency in following up problem reports (not in solving them, which is the task of the person/deptm to whom the problem is assigned), efficiency in performing the calibration plan, in coaching other TIOs, etc. For the first year, there will of course be some real-time adjustments to the G&O: the idea is definitely not to sack anybody on this new responsibility, but to get the best out of the system, and to get the system as good as possible.
COMMENT: PLS: An other remark is that every TIO will interact with two
"leaders" : on line coordinator and Instrument
Scientist related to its two kinds of tasks : foreground and
background and will have to keep a balance between both. Although
one must not necessarily expect conflicts, some thought may be
given to this situation. For instance it may be adequate for an
Instrument TIO to change its presence schedule to attend an
instrument event. (MST: The responasabilities of the TIO and the
instrument force should be clearly defined in the G&Os, and
therefore not confilict within the team. Instrument forces should
be seen as "working" entities, but not as
administrative ones.
REPLY: this is the idea: Instrument Forces/Instrument Nuclei are technical
structure, with a technical leader. Coordinator is the on-line operation
manager. Head of TIO section is the administrative supervisor. All these
structure overlap one the same people, but have very well separated fields
of application. Text added below in instrument forces.
In a similar way, each telescope (NTT, 3.6, 2.2) will have a Telescope Scientist and Telescope TIO, forming a Telescope Core. The Telescope Core has the same role for the telescope and related systems as the Instrument Core for the instruments. For instance, the mirrors, domes, hydraulics, etc... are under the Telescope Scientist/TIO Core' responsibility.
MST, RME: we think that we do not need a special
"telescope TIO" - the tasks to be overssen are either
too complex (e.g. image quality monitoring, dome mechanics), or a
related to maintenance work (e.g. mirror quality monitoring and
cleaning), i.e. LEDt, or Optics.
REPLY: MST: I understand the generic tasks here image quality and
pointing performance assessment. Infact, an astronomer should
supervise these activities. But understanding of these tasks
should be rather delagated to engineers (either the system
engineer (which we dont have), or the operations/configuration
control managers), and not to TIOs.
REPLY: ORH: Don't underestimate the TIOs: among the Telescope TIOs' tasks:
maintenance of the pointing model, Mirror model, follow-up of telescope-related
action points and problem reports... Text changed:
The various Instrument Nuclei are combined into "INSTRUMENT FORCES"; the various Instrument Forces that come into mind are:
These forces should exchange expertise at all
levels: observation procedures, data reduction, hints and tips,
etc. Also, the Instrument Scientist of one of the instrument will
almost automatically be able to give basic support on the others
of the same instrument force. This should foster communication
between the current teams. One Core can belong to several
Forces. Other forces could be considered, eg 2p2 (=2p2 + WFI +
FEROS), NTT (= NTT+EMMI+SUSI+SOFI), 3p6 (=3p6+ EFOSC+ TIMMI +
CES/HARPS)
MST.RME,PLE: We all like the idea of the
"crossteam" forces better.
REPLY: thx :-)
Note that it is not expected from the Instrument
Forces to do all the support/operation of their respective
instrument (it is not feasible, for instance SofI is used
~150n/yr, and TIMMI about 100n/yr, totalling 250n/yr, i.e. too
much for 2 astronomers even if they were doing only support).
COMMENT (JME): ?? make the force larger. Why do you only have 2 scientists here?
REPLY: OK, let's expand:
In addition to the Instrument Scientists of the instruments constituting it, the Force will also include additional scientists, i.e. "new" astronomers who are not yet Instrument Scientists, and "senior" scientists (this includes Fellows who completed their first year) who fully master all the instruments from one Force and are expanding to other Forces. In that framework, the support of a given instrument will be provided by the astronomers of its Force, not only by the Instrument Scientists. The average nr of nights during which each instrument is scheduled must be taken into account when constituting the forces and, to a certain extend, when hiring replacement for leaving scientists.
At this point, the 5 above-mentioned forces
should meet briefly, but fairly formally (e.g. every 2 months),
with the following agenda:
Each of these meeting should be summarize briefly in a "monthly instrument force report", which will 1/ diffuse the info to SciOp as a whole, 2/ document and archive the problems, achievement, hints and tips..., 3/ provide input for the bimonthly SciOp report that the head of SciOp has to produce for the upper management (i.e. help me!).
In the future, the rhythm and scope of these
meetings will be adjusted depending of the usefulness of the
first ones.
It must be noted that the Instrument Core and Instrument
Force structure is a technical structure, which obviously overlaps with the
administrative structure (described in [2]) since the same people are
involved. It is not a problem, since these structures have well defined scopes
that are not overlaping.
COMMENTS: PLS: I have also the feeling that some previous tasks of
the operation engineers are at least partly transferred to the
Instrumet TIOs and Scientists. Namely:
to IS:
- training other department members to use the instrument.
- track pending problems
to Ins. TIO
- testing obsevation modes
- training other TIOs on the best way to use instrument
- track pending problems.
First I think there are enough problems to leave some to
engineers.
Training TIOs may remain part of their job for still quite
a while.
They could keep working on web pages for a while too at
least training TIOs to create documentation in it and to
define and describe procedures.
They should remain in charge of templates and
configuration control unless these are completely outsourced to
SWC (MST: NO, it is critical to have the expertise in the SciOp
dept!).
Last but not the least they should get involved in
or develop small projects generally in relation with SWC.
But mainly it must be explained here why and which kind of
engineers are necessary inside the SciOp department.
And this can only be done by astronomers with perhaps some TIO
comments.
COMMENT: JME: The task of the Op.Eng. is not well defined. If most of their time is devoted to engineering, lets move them to LED!
COMMENT: JME: what about configuration control?
REPLY: this section was created to clarify the role of the OpEng. and Conf.Ctrl
No major change with respect to the current system:
Of course, the night TIO can always call whoever he things can help in his decision, or whoever he things can help make his decision enforced (i.e. if the Visiting Astronomer wants to get explanation on the humidity rules by an astronomer, get the Support Astronomer, Shift Leader (see below) or head of SciOp to come to help). In particular, for weather matters, an unexperienced Night TIO should call a more senior Night TIO.
As maintenance will be mostly performed by "outsiders" (i.e. from Engineering Dpt and SWC), coordination will be of critical importance.
For each telescope, the Day TIO will be in charge of that coordination (and be TELESCOPE COORDINATOR). His role is equivalent to that of the Paranal's UT Manager. On a day-to-day basis, he will
One of the Telescope Coordinators (typically a "senior" one) will be SCIOP COORDINATOR, i.e. in addition to coordinate his telescope, he will also coordinate the actions that affect SciOp as a whole. He will be in charge of representing SciOp at the Action Point Meeting on Thu, and -if needed- invite additional SciOp members to be present at that meeting. He is also the person who mans the lasilla@eso.org account (cf [1])
Durning the day (starting at a decent time considering the time he went to bed the night before), the Support Astronomer will
The third TIO will either
It should be noted that if the 3rd TIO is needed for on-line work, this has priority on any background task. For instance, if he is needed for urgent trouble shooting, problem solving, or to ensure the day/night transition, he should stop his background activities.
They participate to maintenance plan, and on-line operation. Most of their time should be devoted to configuration control and operation developments, as described above
Many comments were done on this super-short section. They led to the new Section 4.3- OpEng. The comments are addressed there.