1. Purpose of this document

This the plan for the production of the observing system for the adaptive imaging system NAOMI. It defines the set of NAOMI prototypes that must be built, the distribution of the work between collaborating sites, the software process involved and the main milestones in the project. Later issues will include resource estimates and schedules for the computing work.

This plan is subordinate to the higher-level documents that describe the production of NAOMI’s mechanical and optical equipment. It presumes that further documents will be produced to describe the details of the computing work-packages.

2. Scope of the system

The product is the observing system that enables NAOMI to be used at the WHT. That is, the project is responsible for integrating all the computers, peripherals and software required for observing into one system. However, a considerable part of this equipment will be reused from the observing systems of other instruments. Some aspects of the integration may be transferred (by negotiation) to ING engineers.

Data-reduction provisions are not a part of this plan. However, arrangements for feeding observation to data-reduction computers may need to be included.

The system produced must provide a platform for the long-term evolution of the NAOMI instrument; the system will be expensive and is not readily disposable. Currently, there are no plans to re-use parts of NAOMI in other adaptive optical systems.

3. Process

By the standards of previous projects for the WHT, NAOMI is extremely complicated and very sparsely funded. There is much new and unproven technology and the risks of failure are particularly high. (A list of specific risks, with plan-fragments for their avoidance, is below.)

NAOMI has already been planned to proceed as a series of three laboratory prototypes followed by a production version. For the software engineering, this is equivalent to Boehm’s ‘spiral model’ which iterates over the ‘waterfall’ model several times. In each iteration more risks are brought under control and more decisions can be validated and finalized. Each iteration requires more outlay of resources but the vulnerability of the outlay to risk is minimized. Ould [1] has written a useful discussion of the spiral model.

At the time of writing, four iterations are planned, corresponding to the NAOMI-A, -B and -C prototypes and the NAOMI-1 production system.

The process within each iteration shall be derived from PSS-05, the ESA standards for software engineering, but the completeness with which those standard are followed can be low in the early stages. Each iteration will have serial user-requirements (UR), software-requirements (SR), architectural-design (AD), and production (DD) phases, followed by a post-mortem phase. The final iteration will include the transfer (TR) and maintenance (OM) phases.

A major outcome of this choice is the distinction between user requirements (URs) and system requirements (SRs). URs are given to the NAOMI-computing project by the overall project; SRs are defined by the sub-project and are the output of the analysis of the URs. URs form the testable part of the contract between the sub-project and its customers — either ING directly or the overall project acting on ING’s behalf; SRs are the ‘property’ of the sub-project, although they are typically made public. URs must be satisfied in the final product; SRs should be satisfied as a way of ensuring that the URs are covered in detail, but particularly difficult SRs can be modified or dropped provided that the URs can be shown to be met by other means.

4. Products

The probable form of the delivered system is shown in a design study: see reference [3]. There are these sub-systems:

· Electra, controlling the fast-moving mirrors;

· the detector for the wavefront sensor (WFSD)

· the carriage for the WFS detector (WFSC)

· the opto-mechanical chassis (OMC), comprising all NAOMI’s slow-moving mechanism except the WFSC;

· the science detector (SD);

· the data-acquisition sub-system (DAsS);

· the telescope control system (TCS);

· the central intelligence of the observing system (CIA);

· various elements of the user interface that are outside the Electra system.

The system will evolve through stages as follows.

4.1 NAOMI-A

This prototype tests the ability of the communications technologies to carry the control loops suggested in the draft design. If the answers are favourable, the project should commit to the communications architecture after a review of the results of the experiment. If the communications are clearly failing, the project will be delayed while the architecture is redesigned. If the results are ambiguous, the experiment must either be extended to clarify the situation (thereby stalling the rest of the project) or the risk must be borne into the next cycle and handled in the production of NAOMI-B.

There is no need to produce (or even define) a complete set of interfaces. One instance from each class will do. For example, it should be possible to show that a control loop implemented as a DRAMA client reading a parameter in Electra and invoking an action in the OMC can run reliably, but it is not necessary to cover all the mechanisms in the OMC.

All mechanisms will be simulated. Even if prototype mechanisms are available, they are unlikely to add much value to the tests.

The NAOMI-A programs are disposable and should be built for speed and ease of manipulation. The code should not be carried forward to NAOMI-B.

4.2 Electra-0 and Electra-1

The Electra-0 experiment is expected either to validate the parts of Electra that NAOMI or to demonstrate shortcomings that can readily be repaired. The Electra-0 results should be available well before the start of the NAOMI-B iteration and possibly before the NAOMI-A experiment. If the Electra-0 experiment indicates that Electra’s mirrors or computing infrastructure will not become suitable for NAOMI, then the entire NAOMI project will stall while a new strategy is decided upon.

The Electra-1 experiment provided a chance to check on any improvements found necessary in Electra-0.

4.3 NAOMI-B

This system validates the ergonomics of NAOMI and allows a functional audit. We should expect to discover ‘hidden’ user requirements at this point. The experiment answers the questions ‘do we really know what we want’ and ‘can we build it with the money available’; it must continue until the answers to both are ‘yes, beyond reasonable doubt’. This is the point where the project is most likely to slip against its schedule.

NAOMI-B doesn’t directly test the architecture. However, it is the logical point at which to abandon an expensive part of the solution for something cheaper. Our estimates of cost have to be reasonably accurate by the end of the experiment.

To do the experiment, NAOMI-B must cover all the interfaces between sub-systems fully, even if the implementation is not in the final form. The people producing the components will have to judge whether it is more efficient to produce final production code that will be reused in NAOMI-C and NAOMI-1, or to make cheap, disposable prototypes.

NAOMI-B does not require a mechanism to be present if it can be simulated in sufficient detail. It seems likely that the DM and FSM will be available but not necessarily the OMC and WFS parts; this is helpful since the fast mechanisms will be the hardest to simulate. The prototype should be arranged so that any mechanism that does become available can be added easily to the experiment. The TCS, CIA, science detector and DAsS should be available for the experiment.

4.4 NAOMI-C

This experiment provides final validation of the computing arrangements by running the full system in a realistic environment and confirming the reliability under load: it is an extended ‘stress test’. The tests need to continue until we can safely commit to a commissioning date for NAOMI-1. (The definition of ‘safely’ needs to be refined.)

NAOMI-C is intended to be a complete system. If some of the software is missing, then the experiment should be postponed. If some of the mechanisms are missing, then the experiment can go ahead provided that those mechanisms can be accurately simulated. (Some criterion of accuracy needs to be defined.)

The start of the NAOMI-C experiment is the last point where we can reasonably absorb new requirements. There should be a final review of the URD following which any new requirements are relegated to the upgrades programme.

4.5 NAOMI-1

NAOMI-1 is the system that ING are paying for. It is presumed to satisfy completely and in detail the user requirements agreed at the start of the NAOMI-C experiment and to pass all tests derived from those requirements.

5. Deliverables

Only NAOMI-1 is deliverable to ING, although NAOMI-C may be taken for tests at the WHT. The delivered product shall consist in (presuming [3] to be a true picture of the system):

· Local controls (electronics and software) for the Electra mirrors;

· Local controls for the Wavefront-sensor Detector (WFSD) and Wavefront-Sensor Carriage (WFSC);

· Local controls for the Opto-mechanical Chassis (OMC);

· Electra’s coordinating software to run on the system-coordination SPARCstation;

· Electra’s visualization system;

· user-interface software for engineering and astronomical use;

· additions and adaptations to the ING Central Intelligence (CIA) to allow Electra, the

· WFS and the OMC to be operated with the WHT and the separately-produced science detector.

· manuals for technical and astronomical users

· project documents from PSS-05: URD, SRD, ADD, DDD, TRD

· archived results from quality-control operations during the project.

Furthermore, the project team will build and install the system at the time of commissioning.

6. Criteria for completion of project

The NAOMI project is complete when the system is accepted and formally signed off by ING representatives. The computing project is, by definition, complete at that point, but it may also be terminated earlier if the NAOMI project management choose to accept and sign for the observing system.

Acceptance of the computing aspects of NAOMI by ING will be based on successful coverage of the agreed user requirements, which will be demonstrated by acceptance tests specified by ING. The bulk of these tests will be performed during commissioning of NAOMI-1; this will lead to provisional acceptance of the system for use by guest observers. Those requirements (notably long-term reliability) that cannot be demonstrated during commissioning will be tested during a 6-month warranty period during which the NAOMI project will undertake repairs and revisions as necessary to satisfy the URs. This period is not intended as an opportunity to change the specification and any changes in URs at this point should be subject to careful review.

7. Upgrades project

We presume that there will be further development after delivery of NAOMI-1. Any new or changed requirements received after the UR review in the NAOMI-C experiment will be relegated to the upgrades project. Any requirements that cannot be met within NAOMI-1’s restricted budget will also be relegated. However, the projects should not aim to relegate any quality-control work on the features that are delivered in NAOMI-1.

8. Work packages

Production of NAOMI’s optical and mechanical hardware is already divided into three sub-projects:

· The Electra project at Durham;

· The wavefront-sensor (WFS) project at RGO;

· The opto-mechanical carriage (OMC) project at ROE.

Each of these work-packages will produce unique, custom components that cannot easily be assembled in one place until final integration of the system. Thus, the work local control-electronics needs to be split according to the division of the astronomical hardware and, so far as possible, the control software should follow the division of the electronics.

There are two other independent, separately-funded projects that will contribute equipment to NAOMI:

· the DRAMA-enabled TCS

· the infra-red science camera based on the Hg-Cd-Te detector.

Based on the preliminary design-study, the work-packages and their component tasks should be as follows. (The level of detail given for each work-package indicates the disparity of the tasks involved; it is not intended to reflect the importance or difficulty of the packages or tasks.)

8.1 Electra

8.1.1 NAOMI-A

· Prototype DRAMA interface for NAOMI-A.

8.1.2 NAOMI-B

· Produce DRAMA interface.

· Produce Electra internals.

· Produce partial system-UI.

8.1.3 NAOMI-C

· Revise/complete DRAMA interface.

· Revise/complete Electra internals.

· Revise/complete system-UI.

· Produce visualization system for NAOMI-C.

8.1.4 NAOMI-1

· Finalize all the above products.

· Deliver the product to RGO for final integration.

8.2 WFS detector

8.2.1 NAOMI-C

· Adapt the CCD controller to the chosen CCD.

· Produce, for NAOMI-C, command interface to Electra.

· Produce, for NAOMI-C, data interface to Electra.

8.2.2 NAOMI-1

· Finalize all the above products.

· Deliver the product to RGO for final integration.

8.3 WFS carriage

8.3.1 NAOMI-A

· Prototype the DRAMA interface and its link to EPICS.

8.3.2 NAOMI-B

· Produce the production DRAMA interface.

8.3.3 NAOMI-C

· Produce the control electronics and EPICS database.

· Revise/complete the DRAMA interface.

· Revise/complete all the above products for release.

8.3.4 NAOMI-1

· Finalize all the above products.

· Deliver the product to RGO for final integration.

8.4 OMC

8.4.1 NAOMI-A

· Prototype the DRAMA interface and its link to EPICS.

8.4.2 NAOMI-B

· Produce the DRAMA interface.

8.4.3 NAOMI-C

· Produce the control electronics and EPICS database.

· Revise/complete the DRAMA interface.

8.4.4 NAOMI-1

· Finalize all the above products

· Deliver the product to RGO for final integration.

8.5 CIA

8.5.1 NAOMI-A

· Prototype new interlocking table.

· Prototype new clients.

8.5.2 NAOMI-B

· Validate existing code for use in NAOMI.

· Extend existing ING CIA for NAOMI.

· Produce production locking table.

· Produce production clients.

· Produce any UIs not covered by the Electra work-package.

8.5.3 NAOMI-C

· Check compatibility of any changes since NAOMI-B.

8.5.4 NAOMI-1

· Finalize all the above products.

· Deliver the product to RGO for final integration.

8.6 Observation logging and DAsS

8.6.1 NAOMI-B

· Validate the DAsS for use with the new IR camera.

8.6.2 NAOMI-C

· Extend the logging system to support NAOMI.

8.6.3 NAOMI-1

· Finalize all the above products.

· Deliver the products to RGO for final integration.

8.7 IR camera (oversight)

8.7.1 NAOMI-B

· Formalize the DRAMA interfaces from the CIA to the sub-system.

· Validate existing code for use in NAOMI

· Obtain a conforming version of the sub-system to use in the experiment.

8.7.2 NAOMI-1

· Obtain a conforming version of the sub-system for integration at RGO.

· Check compatibility of any changes made since NAOMI-B.

8.8 TCS (oversight)

8.8.1 NAOMI-B

· Formalize the DRAMA interfaces from the CIA to the sub-system

· Obtain a conforming version of the sub-system to use in the experiment.

8.8.2 NAOMI-1

· Obtain a conforming version of the sub-system for integration at RGO.

8.9 Overall coordination

8.9.1 NAOMI-A

· Organize review of requirements.

· Plan the experiment.

· Conduct the experiment, using equipment supplied from other work packages.

· Organize the review of the experiment and the decisions arising from it.

· Plan the NAOMI-B experiment.

8.9.2 NAOMI-B

· Organize review of requirements.

· Revise the analysis and design.

· Conduct the experiment, using equipment supplied from other work packages.

· Organize the review of the experiment and the decisions arising from it.

· Refine the cost estimates for the project.

· Plan the NAOMI-C experiment.

8.9.3 NAOMI-C

· Finalize the requirements.

· Finalize the analysis

· Revise the design

· Conduct the experiment, using equipment supplied from other work packages.

· Organize the review of the experiment and the decisions arising from it.

· Finalize the cost estimates for the project.

· Determine the earliest reasonable commissioning dates.

8.9.4 NAOMI-1

· Finalize the design.

· Receive and validate the output of the other work-packages.

· Integrate the system at RGO.

· Arrange trials at the WHT.

· Manage any changes arising from trials at the WHT.

· Arrange commissioning of the system.

· Arrange support for the system in its warranty period.

8.10 Distribution of work

Initially, the distribution of work is as follows:

· Electra at Durham;

· WFSD and WFSC at RGO;

· OMC at ROE;

· all other work at RGO.

9. Standards

PSS-05 [2] is the generic standard for the process. Detailed standards for some key process areas will be defined by ING and these will be listed in a later issue of this document.

10. Milestones

10.1 NAOMI-A iteration

· Requirements reviewed and stable.

· Work-package teams deliver parts for the experiment.

· Experiment validates the communications technologies.

· Iteration written up and plans for NAOMI-B agreed.

10.2 NAOMI-B iteration

· Requirements reviewed and stable.

· Analysis checked against new/changed requirements.

· Design revised to match analysis.

· Work-package teams deliver parts for the experiment.

· Experiment shows system design to be functionally complete and appropriate.

· System design agreed to be affordable.

· Iteration written up and plans for NAOMI-C agreed.

10.3 NAOMI-C iteration

· Requirements adapted to include NAOMI-B results, reviewed and finalized.

· Analysis checked against new/changed requirements.

· Design revised to match analysis.

· Work-package teams deliver parts for the experiment.

· Experiment shows designs are valid for final implementation.

· Results of iteration written up and plans for NAOMI-1 agreed.

10.4 NAOMI-1 iteration

· Parts accepted from work-package teams.

· System integrated at RGO.

· System passes system tests at RGO.

· Initial tests at WHT complete.

· Revised system passes system tests at RGO.

· System passes acceptance tests at WHT.

· System provisionally accepted by ING.

· System finally accepted by ING.

11. Resource estimates

These are deferred until the basic structure of the project is agreed by all participating sites. Managers of the individual work-packages must supply the detailed estimates.

12. Scheduling

The sub-project’s schedule is deferred until the first resource-estimates are assembled for the work packages. It has been suggested that the NAOMI-A experiment should occur in July 1997 and that the other iterations should follow at roughly 6-month intervals leading to commissioning in 1999.

13. Quality control and assurance

Plans for quality issues are deferred until the basic plan is agreed. However, an initial list of perceived risks is included together with QC actions to limit or remove them. These plan-fragments, or some replacement for them, need to be incorporated in later versions of this document or in the more-detailed plans for the individual work-packages. Additions to the list are invited!

Any given sub-system may fail by not working at all; being statistically unreliable; having the ‘wrong’ external interfaces; being late. Candidates for failure are any sub-systems that haven’t yet been proven against SRs. Currently: Electra, WFSD, WFSC, OMC, TCS, SD, DAsS, CIA (i.e. everything, because nothing has documented quality yet...).

· Document SRs in detail for each sub-system.

· For each sub-system, document its external interfaces in detail in or before the SR phase of NAOMI-B.

· Write ICDs if the SRD doesn’t define the interfaces tightly enough.

· Check sub-systems at intervals for conformance to SRD & ICDs.

· Require ‘shells’ of new sub-systems to be produced first so that interfacing can be tested and validated early.

URs may be incomplete until late in project, leading to new flows that the architecture can’t handle.

· Allow no changes to URs after the review at the start of NAOMI-C.

· Review requirements at least once in each of NAOMI-A, B and C.

Analysis may be incorrect, leading to missing requirements.

· Use traceability matrices to check coverage of URs.

· Review SRD at least once per loop.

Analysis may be incorrect, leading to badly-specified interfaces.

· In the NAOMI-C design review, must check that target hardware is still appropriate.

The DRAMA messaging may not work.

· Discuss requirements (esp. bandwidth and latencies) with AAO before finalizing the architecture.

· Try to get AAO support for NAOMI’s particular requirements.

· Try again to get support funding for DRAMA aspects.

The system computer may not be fast enough.

· Think up some way of estimating the load before NAOMI-C.

· Try to do load tests with NAOMI-B; check again with NAOMI-C.

· Reserve money (or get it reserved by ING) for a CPU upgrade.

The Ethernet may not be fast enough.

· Make load estimates as part of analysis; test them in NAOMI-A. Check the timing in NAOMI-C.

· Examine multiple or faster networks..

· Reserve money for (say) 100baseT upgrades until position is clearer.

The mechanical bits in the {OMC|WFSC} may not move reliably.

· Define ‘reliably’ as part of analysis.

· Liase with mechanicals about requirements before {OMC|WFSC} is built. Establish what level of unreliability the control system is expected to deal with.

14. References

[1] Strategies for Software Engineering by M. A. Ould, pub Wiley, ISBN 0-471-92628-0

[2] ESA standards for Software Engineering. ESA document PSS-05.

[3] Design Study for an Observing System incorporating NAOMI. RGO document WHT-NAOMI-12 issue 2.1 by Guy Rixon.