NAOMI Management Plan.
wht-naomi-79
Internal document number AOW/MAN/AJL/7.3/03/97/NAOMI Management Plan
Version date: 14 Mar 1997
1. Project Components
1.1 MARTINI
1.2 ELECTRA
1.3 NAOMI
1.4 JOSE
2. NAOMI Project Structure
2.1 Management Structure
2.2 Terms of Reference
3. Financial Delegations and Allocations
4. Project Reporting
4.1 Project Manager Reporting to Budget Holder
4.2 Local Managers Reporting to Project Manager
5. Project Documentation
6. Project Implementation - Responsibilities
6.1 RGO Work
6.2 ROE Work
6.3 Durham Work
6.4 ING Work
6.5 System Integration
6.6 Acceptance Testing
6.7 System Commissioning
7. Project Implementation - Stages
7.1 Introduction
7.2 Preliminary Design Reviews (PDR)
7.3 Critical Design Reviews (CDR)
7.4 System Review (1)
7.5 System Review (2)
7.6 System Integration
7.7 Acceptance Testing
7.8 Commissioning
7.9 Formal Acceptance of the NAOMI System
7.10 Alternative Strategies
8. Project Implementation - Locations
8.1 Introduction
8.2 Deformable Mirror
8.3 Real Time Control System and Visualization
8.4 NAOMI Wavefront Sensor
8.5 E1 stage
8.6 Opto-mechanical Chassis
8.7 Control task
8.8 GUI
8.9 Laboratory Integrations
8.10 Commissioning
9. Figure Captions
MARTINI is basically a Durham Physics group R & D project. However it offers a valuable opportunity to test an adaptive optics system on the WHT. In carrying out scientific observations allocated by PATT, it will also provide information about the GHRIL environment (seeing, thermal and electromagnetic) which will be highly relevant to NAOMI from the both the Adaptive Optics and Infrared performance aspects. The NAOMI project has supplemented the MARTINI project funds to a small degree in order that as much as possible can be learned from MARTINI. NAOMI has no formal management control over MARTINI but the MARTINI manager (Pete Doel) is being very co-operative in following suggestions from the NAOMI project concerning performing laboratory tests and timing of experiments so that they do not interfere with ELECTRA and NAOMI development.
The timetable is:
· July 1996: full laboratory test of MARTINI
· Aug 1996: PATT observing, including pre-observing commissioning
· 1996 Semester B onwards: available for PATT observing (level of support still and issue needing to be resolved).
The original Durham University long-term goal for ELECTRA is optically co-phased tip-tilt and piston AO correction, via tip-tilt with no co-phasing (E0) and then co-phased sub-areas. The co-phased sub-areas stage has now been replaced by E1, an IR co-phased step. E1 provides a crucial test of the DM which will be used for NAOMI and a WFS which has almost identical basic operation and probably the same CCD that will be used for NAOMI. ELECTRA has its own opto-mechanical chassis.
The timetable is:
· Dec 96 - May 97: E0 full laboratory test
· Jun 1997: E0 commissioning run
· May - Oct 1997: E1 laboratory development & test
· End Nov 1997: Earliest date E1 available for commissioning run
NAOMI is to be the facility instrument, utilising the ELECTRA DM but with an independent opto-mechanical chassis and a Real Time Control System developed from ELECTRA.
The NAOMI timetable is:
· Full laboratory integration: Oct 98 - Feb 99
· Commissioning: Mar 1999
Site evaluation to measure key atmospheric properties is taking place on the WHT via an over-ride programme and campaign measurements. Results will be used to assist RTCS optimization and development of observing procedures and visualization.
The JOSE timetable on the WHT is:
· Start of over-rides: December 1995
· Observations and campaign continue to ~ mid-1997.
The following chart shows the management structure of the project.
Project Scientist:
1. Responsible to The Director, ING, for Defining Project Scientific and Operational Goals.
2. Responsible for advising the project manager on scientific priorities, especially where specifications cannot be met due to technical or financial constraints; confirm via daily involvement with the project and through appropriate reviews that the technical implementation of the project meets the scientific goals.
Project Manager:
1. Responsible to the Director, ING, for timely and within budget delivery of the system.
2. Responsible for overall project management.
External Project
Scientist:
1. Responsible for advising project scientist on astronomical implications of current system specifications, participate in working group discussion on system science requirements and operation.
2. Responsible for general high-level monitoring of project goals and achievements.
3. Responsible for advising the PS, PM and ING Director on the suitability of the goals and achievements against likely user requirements.
4. Responsible for advising the PS and PM on external technical and astronomical developments, especially in relationship to developments on Gemini.
Project Engineer:
1. Responsible to Project Manager.
2. Responsible for development and implementation of system technical specifications to meet scientific and operational specifications.
3. Responsible for overseeing design effort.
4. Responsible for reviewing and developing test procedures for integration and acceptance.
5. Advise Project Manager on cost effectiveness of any choices in implementation and of solutions to technical problems.
Software Manager
1. Responsible to Project Engineer.
2. Responsible for setting software management plan, defining coding and interface standards, confirming that they are being met at a general level via internal review and by use of appropriate software management tools, using authority delegated by the Project Engineer.
Local Managers
1. Responsible to Project Manager through reporting on local project expenditure and use of resources and on project progress.
2. Responsible to Project Engineer on matters of developing technical specifications, building and implementing the system; includes provision of appropriate effort for integration and commissioning.
3. Responsible for implementing local work package in accordance with work package specifications and for management of local resources within the allocation given by the Project Manager.
4. Other duties of local managers, esp. in terms of reporting requirements, are given in the WP Cover Document.
1. Budget Authority is delegated to the Project Manager by the Budget Holder
2. The Project Manager makes the following allocations, from which funds are included by PPARC into the appropriate Observatories Business Plan:
· Director RGO, to carry out WFS and Control Task Work Packages
· Director, ROE, to carry out Opto-Mechanical Chassis Work Package
1. The Project Manager approves the following grants to be let, funded by the project:
· Grant to fund NAOMI Project Scientist and Project Systems Engineer
· Grant to fund relevant E1 work and NAOMI RTCS and Visualization software and hardware and Development.
1. The Allocations to observatories will be on a yearly basis but with a clear indication of the expected allocation profile for the following 3 years. A preliminary allocation has been given to each for FY 1996/97.
2. On terms currently set by PPARC, once allocations are made the Observatories it is formally the responsibility of the respective Directors to deliver the agreed product. The Project Manager does not have any direct authority over Observatory staff unless through existing internal line management.
3. The Project Scientist and Systems Engineer grant has been let until March 1998.
4. The goal for the Durham The RTCS and Visualization Development grant is to let it shortly after an agreement is confirmed between the Director, ING and Durham University on the relationship between the ELECTRA and NAOMI projects and the mutual development and sharing of key components. The grant is likely to be for the full planned period of the NAOMI project, to approximately Mar 1999.
The Project Manager will report formally to the Budget Holder monthly on the status of the project at each month’s end, by the end of the following month, giving total project expenditure, staff resources used, milestones achieved, a general progress summary and a note of any changes in total projected cost . Out-turn estimates will be provided at appropriate times. The Budget Holder will be notified of any intended changes of project scientific goals before they are formally agreed with the Project Scientist and External Project Scientist.
The Local Managers will report formally to the Project Manager monthly, on the status of the project at each month’s end, by the middle of the following month, giving total project expenditure, staff resources used, milestones achieved, a general progress summary and a note of any changes in total projected cost . Local Managers will provide Out-turn estimates in a timely way. They will also keep in more frequent contact with the Project Manager through informal reports by Email, especially concerning any problems, significant progress or changes in staff effort availability. A more detailed description of the Local Managers’ responsibilities is given in the Work Package Cover Document. A template form for the monthly formal report has been given to the Local Managers.
Figure 1 shows a flow chart indicating the key NAOMI documents. All key documents are held in the BSCW Document Handling Facility under version control.
The defining document for what the system must do when it is delivered to La Palma is the Top Level Scientific and Operational Requirements document.
Procurement of a system to meet these requirements is carried out via a series of Work Packages which define the work and product required from each of the sites.
The WPs are linked to the TLSOR document via a Technical Description document which contains some details of implementation. This link document gives the main overall description of how the TLSOR will be met in practice and includes explanatory text to assist in a global understanding of NAOMI. It has links down from the TLSOR document and links up from the WP descriptions.
Associated with the WPs is a WP Cover document which describes how the Project expects the WPs to be managed and reported on and other WP guidelines.
Each WP has an associated Access database which lists all the individual requirements for that WP. Thus there is a WFS Requirements database, an OMC Requirements database and a Software User Requirements databse. These are set up so that they can be used as a Requirements Traceability Matrix.
The chart also shows how the Software Prototypes feed into the development of the system and where WP and System Reviews lie in the NAOMI Management process.
RGO are responsible for the following.
a) The design and production of the WFS, its pick-off mechanism and its non-common-path calibration. Likewise for a tip-tilt sensor if this is implemented (it is not in the baseline plan).
b) The purchase of the WFS camera, the camera head and the CCD. (The camera and CCD must not be purchased without the specific approval of the Project Manager).
c) Engineering level control of all the mechanisms covered by the previous statement.
d) The design of the software interfaces, design and production of the overall system control task, which links the engineering level opto-mechanical chassis control, the RTCS, the science instrument and the telescope.
e) Provision of at least two personnel with a good and appropriate knowledge of the RGO work to take part in the system integration at a site specified by the Project Manager with adequate backup remotely if necessary to assist in solving any problems related specifically to the RGO work.
f) Provision of the External Project Scientist
ROE are responsible for the following.
a) The overall optical and mechanical layout, including the definition of space envelopes, cabling routes, location of electronics racks.
b) Design and production of all opto-mechanical components on the optical bench except the DM, the WFS and its pick-off and its non-common-path calibration unit.
c) Design and production of system handling equipment, packaging and storage equipment.
d) Engineering level control of all mechanisms covered by the previous statement.
e) Provision of at least two people with a good and appropriate knowledge of the ROE work to take part in the system integration at a site specified by the Project Manager with adequate backup remotely if necessary to assist in solving any problems related specifically to the ROE work.
f) Provision of people on the same terms as above to participate in system commissioning at the WHT.
g) Provision of the Project Manager.
Durham University Physics Department are responsible for the following work. Because of the close connection between the ELECTRA and NAOMI projects a special agreement between the ING and Durham is under discussion which covers these responsibilities and their funding in more detail. Once completed, that agreement will supersede the description of Durham responsibilities given here, except for the Project Scientist and Systems Engineer.
a) All E0 development and components (these are not managed or funded by the NAOMI project).
b) RTCS and Visualization software and hardware for E1 (these are not funded by the NAOMI project).
c) All opto-mechanical components of E1 (these are not funded by the NAOMI project).
d) Laboratory integration of E1 (this is not funded by the NAOMI project except where it involves effort from RGO or ROE).
e) Commissioning of E1 (funded by the NAOMI project)
f) RTCS and Visualization software and hardware for NAOMI.
g) Provision of at least two people with a good and appropriate knowledge of the Durham work to take part in the system integration at a site specified by the Project Manager with adequate backup remotely if necessary to assist in solving any problems related specifically to the Durham work.
h) Provision of people on the same terms as above to participate in system commissioning at the WHT.
i) Provision of the Project Scientist and the Project Systems Engineer
j) Current expectation is that Durham also supply the laboratory for the final integration and system pre-delivery acceptance testing.
The ING on La Palma are responsible for the following work.
a) Advising the Project on any local standards required for software, computing, electronics and electrical hardware, safety requirements, handling requirements, environment and space envelope constraints.
b) Provision of removal equipment for taking off and re-installing NAOMI as will be agreed in the handling requirements, storage space, a set-up and test location for NAOMI when not on GHRIL.
c) Provision of electrical power and any coolants agreed with them to be needed for NAOMI system operation
d) Provision of a GHRIL environment which, without the NAOMI system present does not further degrade telescope seeing compared to that measured at prime or Cassegrain focus
e) Provision of a global heat removal capability servicing GHRIL to which NAOMI systems may be easily attached.
f) Provision of an adequate EM-environment (good earthing facility, em screening).
g) Provision of two people to attend a significant portion of the system integration and acceptance testing, to be trained in the use of the system and to agree the passing of the acceptance tests.
h) Note that the NAOMI project expects all the above, with the exception of a) and possibly b) and g) , to be funded from ING operations.
The location for full system integration will be determined based on the project needs and facilities available at the required time. The current expectation is that the system integration will take place in Durham. However intermediate integration stages will take place at the most suitable location (decided by the Project Manager) for the work in question.
The responsibility for the integration will be carried ultimately by the Project Manager, assisted by the Project Scientist and Systems Engineer. However there is a joint responsibility for the Work Package providers to supply effort appropriate for the integration (see relevant bullets above).
The location for the acceptance testing will be the same as for the system integration. It will occur in approximately the last two weeks of the integration period.
The responsibility for the acceptance will be with the ING. It is envisaged that one of the ING astronomers or engineers attending the integration and acceptance testing phases will make a recommendation to the Director, ING, who will then formally accept the full system as having passed the laboratory tests. The actual tests to be carried out should be agreed between the External Project Scientist, the Project Scientist, the Project Manager, the Systems Engineer and the Director, ING or his nominee, prior to the start of the laboratory integration phase.
The location for commissioning will be the WHT. It is likely there will be a pre-GHRIL assembly and testing of the system after its delivery to the island, then a final commissioning at GHRIL.
Responsibility for system commissioning will be as for system integration.
A milestone chart generated from the Local Managers’ Project Plans and an integrated top-level plan will be maintained by the Project Manager. The current version of the milestone chart is attached. The following sections define some review and other major stages to implementation. They do not replace or substitute for the project plan Gantt chart. For the definition of PDR, CDR and System Engineering Reviews to be used by the NAOMI project see the document AOW/MAN/AJL/8.0/07/96.
The Opto-mechanical Chassis (o-m-c) work package and the Wavefront Sensor (WFS) work package will have their own independent PDRs. Material for these will be supplied in a single written document two weeks before the date of the review.
The Opto-mechanical Chassis work package and the Wavefront Sensor work package will have their own independent CDRs. Material for these will be supplied in a single written document two weeks before the date of the review.
There will not be a full system PDR. However a system review will be held after the o-m-c and WFS PDRs, the supervisory software architecture design is complete and possibly after E0 has been evaluated following its observing (provided its commissioning run takes place in a timely way). It will cover all aspects of the project (including RTCS and Supervisory System software and hardware) as they are at the time of the review. However the review will concentrate on checking that the proposed designs meet overall functionality requirements and on system interfaces. The review will be conducted by the Project Scientist, Project Manager and a La Palma representative, possibly with one invited senior reviewer, and will consist of presentations by the local managers and/or appropriate engineers, summarising the designs, plans and status of each project area and giving detail specifically in interface areas and in functionality. It will also include the draft plan for system integration. Its goal will be to ensure that design and planned implementation details remain compatible between work packages and to ensure that the proposed full system meets the agreed scientific and operational requirements.
There will not be a full system CDR. However a second system review will be held after the o-m-c and WFS CDRs, a prototype supervisory system has been built and E1 lab testing is completed. The review will be conducted by the Project Scientist, Project Manager and a La Palma representative and will consist of presentations by the local managers and/or appropriate engineers. One goal will be to ensure that design and planned implementation details remain compatible between work packages and to ensure that the proposed full system meets the agreed scientific and operational requirements. An additional goal will be to confirm the various integration stages over which components will be tested with all or parts of the rest of the system.
There will be one main phase of full system integration but there may be several earlier preliminary integration phases where key sub-components are tested together. These phases will be defined by the time of the second system engineering review and agreed at or shortly after the review. Some possible preliminary integration phases are listed in section 7.10. The full system integration stage is expected to take approximately 18 weeks.
Acceptance tests and pass criteria will be defined before the full system integration phase begins. They should be such as to demonstrate in the laboratory, in a of period less than two weeks, that the system is likely to meet its scientific and operational requirements at the telescope.
It is currently envisaged that on arrival at La Palma the NAOMI system will be installed and tested on its off-GHRIL bench, to confirm no damage was caused during shipping. Tests will be key sub-elements of the acceptance tests. NAOMI will then be moved to GHRIL for full telescope commissioning. Two runs of not less than 7 nights, separated by about a week, are anticipated. Each run should be preceded by about 4 days at GHRIL using day-time only for set-up and environment tests.
Formal acceptance of the NAOMI system as a delivered instrument, by the Director ING, would be expected to follow the second commissioning run.
Most components of the NAOMI system are relatively low risk and/or can be bought to a well defined specification so do not require early consideration of alternative procurement strategies. The most challenging components are the Deformable Mirror and the RTCS system. Therefore alternative strategies to the main route for their supply have been considered and are described briefly below.
Section 6.3 describes the work intended for Durham, which will be authorized via a grant to develop the NAOMI RTCS, Visualization and GUI. After the E0 and E1 commissioning stages, an internal evaluation will be held which could include a cost-benefit analysis of the route to complete the NAOMI RTCS and Visualization requirements. As NAOMI plans have developed, they have involved an increasing level of re-use of ELECTRA products so it is now unlikely that a significant amount of software will be bought from an external source. Decision points between continuing with E1 software development into NAOMI and any logical architecture changes and user requirement revisions will be set up by use of a series of software prototypes. Should serious problems occur with the ELECTRA system, other potential software suppliers have been identified from whom software could be purchased.
Figure 2 is a flow chart illustrating the relationship between the time line of the E0 - E1 - NAOMI RTCS prototype stages. The interaction with the core supervisory system and the WFS most need to be considered carefully.
The main strategy is to develop the ELECTRA mirror to be the NAOMI system DM, for reasons described in the NAOMI Technical Descriptions document. A second DM, suitable as a substitute for the ELECTRA DM, would be purchased and characterised by Durham as a laboratory system to be made immediately available for NAOMI should the main DM fail. There are several stages at which it could be decided to use the backup DM as the main DM. The approach to provision and use of the continuous face-sheet DM is described in the Memorandum of Understanding between Durham and the ING. Given a lead time in the purchase and implementation of the alternative DM (about 9 months combined) there is clearly a latest date by which it could be purchased and not significantly delay the final implementation of NAOMI. This date is included in the milestone table and the plan would be to make any decision before that date. Figure 3 shows schematically the concept of how DM procurement will be handled. However the continuous face-sheet DM purchase need not necessarily wait until E-1 as it is already recognised that Durham will need an alternative to the segmented DM to continue meeting rolling grant goals.
This section is included only to show the type of work that will be taking place, where (the first named place is the location) and who will be participating. Thus the probable locations of key components and integration phases during the project are listed. These should be regarded as highly preliminary at present and used only as a basis for future discussion.
Durham: single actuator hysteresis measurement
drive several actuators
drive all segments, not co-phased
integrate with RTCS
integrate with WFS
full test with E0
Telescope: use with E0
Durham: develop IR co-phasing
test with E1 (including any RTCS improvements)
Telescope: E1 commissioning
Durham: continued development and testing with RTCS, Vis.
+ RGO test with NAOMI WFS (at RGO or Durham)
Durham + ROE test with opto-mechanical chassis
Durham + RGO + ROE + LP integrated test with opto-mechanical chassis, WFS, RTCS and Visualization
Telescope (ALL): NAOMI commissioning
Durham: continuing code development
benchmark tests with (mostly) ELECTRA hardware
test with (NAOMI) Arial C40 boards
test with DM
test with DM and WFS
use with full E0 including GUI
Telescope: E0 commissioning
Durham: Develop further, including to full standards (?)
integrate with E1
Telescope: E1 commissioning
Durham: NAOMI development, including modal optimisation (probable contribution also from RGO via Project Scientist)
Durham + RGO: test with NAOMI WFS and DM
Durham + ALL: full NAOMI lab. integration
Telescope (ALL): NAOMI commissioning
(E0 WFS will be used for E0 and E1)
RGO Modelling and design iterations, including with pick-off and crosshead design and local calibrator
Build and stand-alone test, with calibrator
CCD camera and chip evaluation, optimisation
ROE + RGO: test with opto-mechanical chassis
Durham + RGO: Test with DM
Durham + ALL: Integrated system test
Telescope (ALL): Commissioning
Durham: opto-mechanical design
opto-mechanical build
test with DM, RTCS, WFS, (an IR camera?)
full laboratory integration
E1 commissioning
ROE overall optical design
design overall layout including cabling, modularity, handling
agree WP- specific space envelopes and define instrument port(s)
procure/build opto-mechanical chassis except WFS and pick-off/WFS mounting mechanism
design and build full-path calibration unit
provide engineering level control of all opto-mechanical moving parts, exceptions same as above
design and provide mounting for electronics
stand-alone test of opto-mechanical bench (substitute flats for DM and tip-tilt mirror)
design and provide suitable shipping and storage containers
ROE + RGO: integrate o-m bench and calibration unit with WFS, pick-off and xy stage
Durham + ROE: integrate o-m-b with DM
Durham + ALL: full lab integration with o-m-b, , C-task, WFS, RTCS and Vis.
Telescope (ALL): NAOMI commissioning
Durham: develop E0/E1 core (i.e. system supervisory) task (possible move of this work to RGO is under discussion).
RGO: develop NAOMI core task
RGO: test supervisory task with WFS
ROE + RGO: test supervisory task with o-m-c at ROE
Durham + All: Test supervisory task in lab integration
Telescope + All Commissioning
Durham: develop E0 GUI
E0 lab integration, test with E0 RTCS and Vis.
Telescope (Durham): E0 commissioning
Durham: develop E1 GUI (+ DRAMA interface?)
E1 lab integration, test with E1 RTCS and Vis.
Telescope (Durham): E1 commissioning
Durham: E1 to NAOMI GUI development + DRAMA interface build
Durham + ALL NAOMI lab integration with C-task, o-m-b, WFS, RTCS and Vis.
Telescope (ALL): NAOMI commissioning
RGO: WFS + local calibrator + CCD + camera
ROE + RGO: o-m-b, full WFS, calibrator and pick-off
ROE + Durham: o-m-b, DM
Durham + RGO: DM + full WFS
Durham + ALL: full lab integration (includes acceptance testing)
Telescope prep. area (ALL): Test area check out, repeating key lab. acceptance tests
Telescope (GHRIL) (ALL): Full commissioning
Figure 1: Project Documentation chart (see text for explanation).
Figure 2 : A flow chart indicating the potential development route for the E0 -E1 - NAOMI RTCS software. The diagram is based on the idea that the goal with each prototype is as much as possible to check requirements driven by the user, with a second goal of testing some key system functionality. Therefore the User Requirements Document and its development is folded top and bottom of the figure and decisions, design changes etc are related back to and driven by User Requirements.
Figure 3 : A flow chart indicating the key stages in the development of the ELECTRA Deformable Mirror. The key points are indicated at which a parallel purchase and characterization of an alternative mirror interact with the main DM development route. The alternative mirror could be used either as a backup or selected as a strategic switch to being the main mirror.
Figure 1.
Fig.2