atst requirements flowdown - dkistwere outlined in the design and development proposal to the nsf2,...

Project Documentation SPEC-0066 Revision A

Advanced Technology Solar Telescope 950 N. Cherry Avenue Tucson, AZ 85719 Phone 520-318-8102 [email protected] http://atst.nso.edu Fax 520-318-8500

ATST Requirements Flowdown

Rob Hubbard

Systems Engineering

9 November 2006


SPEC-0066, Revision A Page ii

REVISION SUMMARY: 1. Date: 9 November 2006

Revision: A Changes: Initial Release


SPEC-0066, Revision A Page iii

Table of Contents

Preface ........................................................................................................1

1. THE FLOWDOWN PROCESS.............................................................................. 2 1.1 LEVEL 1 – OBSERVATORY REQUIREMENTS....................................................... 2 1.2 LEVEL 2 – SYSTEMS REQUIREMENTS ............................................................... 3 1.3 LEVEL 3 – SUB-SYSTEM REQUIREMENTS .......................................................... 3 1.4 LEVEL 4 – COMPONENT SPECIFICATIONS.......................................................... 3

2. THE SCIENCE REQUIREMENTS DOCUMENT................................................... 5 2.1 LEVEL 1 REQUIREMENTS................................................................................. 5

2.1.1 Wavelength Coverage .............................................................................5 2.1.2 Flexibility ..................................................................................................5 2.1.3 Lifetime.....................................................................................................5 2.1.4 Adaptability ..............................................................................................5 2.1.5 Availability................................................................................................5 2.1.6 Coordination ............................................................................................6

2.2 LEVEL 2 REQUIREMENTS................................................................................. 6 2.3 ADDITIONAL SPECIFIC REQUIREMENTS FROM THE SRD ..................................... 8 2.4 THE HANDOFF TO ENGINEERING ....................................................................... 8

3. FLOWDOWN TO SUBSYSTEM REQUIREMENTS............................................ 10 3.1 THE RELEVANCE MATRIX .............................................................................. 11 3.2 THE ERROR BUDGETS................................................................................... 12 3.3 ERROR BUDGET FLOWDOWN TO SUBSYSTEMS ............................................... 13 3.4 LEVEL 3 PROCESS AND RESPONSIBILITIES ..................................................... 15

4. COMPONENT SPECIFICATIONS ...................................................................... 16 4.1 FLOW DOWN TO COMPONENT SPECIFICATIONS ................................................ 16 4.2 TRACE BACK................................................................................................ 17

References................................................................................................19

APPENDIX A. THE SCIENCE REQUIREMENTS........................................................ 20 APPENDIX B. THE DIFFRACTION LIMITED ERROR BUDGET................................ 21


SPEC-0066, Revision A Page 1 of 20

Preface The flowdown of science requirements to engineering specifications is an essential step in modern telescope design and development. Gone are the days when large sums of money could be obtained to build new state-of-the-art research facilities without a clearly stated mission, promises of specific, critical scientific results not currently obtainable with existing facilities, and a demonstration that all of the salient features of the design can be traced back to that science.

The flowdown of requirements for the Advanced Technology Solar Telescope began with the earliest drafts of the ATST science requirements document, and proceeded through the Design and Development phase. Although the resulting specifications and the requirements from which they were derived were well understood by systems engineering and the various lead engineers, the flowdown process was only documented in presentation materials for various project reviews. This document is the first attempt to systematically capture the ATST flowdown process and some of the broad results. It also references and outlines other sources of detailed flowdown and trace-back tools and methods used within the ATST project.



1. THE FLOWDOWN PROCESS

The flowdown formalism and language used by the ATST project is taken largely from the text, The Design and Construction of Large Astronomical Telescopes.1 This source breaks the process into four levels, which proceed approximately in order. Each is described in the sections which follow, and shown diagrammatically in Figure 1.1.

1.1 LEVEL 1 – OBSERVATORY REQUIREMENTS Observatory requirements are the most fundamental requirements that serve to initiate the flowdown process. They define the science and programmatic goals of the observatory including the specific science mission, the anticipated lifetime, rough cost boundaries and schedule estimates. For ATST these were outlined in the design and development proposal to the NSF2, and also carried over into the science

1 Bely, Pierre Y., ed. The Design and Construction of Large Optical Telescopes, pp. 69-72. Springer 2003. 2 Advanced Technology Solar Telescope Design and Development Proposal to the National Science Foundation,

November 2002.

Figure 1.1. The Flowdown Process



requirements document (SRD)3. In summary, the primary mission of the ATST is “to study the fundamental physical processes underlying solar magnetic activity at the spatial and temporal scales at which they naturally occur.”4 It is expected to “serve the international solar community for 30-40 years.”5

These level 1 priorities represent a contract, of sorts, between the scientific community, the NSF, and the ATST project as documented within the NSF proposal and the SRD.

1.2 LEVEL 2 – SYSTEMS REQUIREMENTS Systems Requirements are more specific. Typically this is where telescope aperture size is called out, along with such details as image quality, wavelength coverage, and the first-generation instrument suite. In our case even more details were provided, such as a strong likelihood that the optical configuration would need to be off-axis and Gregorian in order to meet all of the science requirements (pending design and trade studies).6

Level 2 priorities represent requirements placed on the engineering team by the science as documented within the SRD.

1.3 LEVEL 3 – SUB-SYSTEM REQUIREMENTS Sub-system requirements bring even more specificity to the process as the real engineering gets underway. Systems engineering is responsible for dividing the facility up into manageable subsystems, and the project assigns lead engineers to each of these. There may be changes to the subsystem definitions early in the process as early design concepts evolve into a baseline design and eventually a reference design. As time passes, the subsystem definitions become increasingly rigid.

The scientists are still participating during this period, performing studies to determine (for example) how to calibrate instrumentation to the required polarimetric accuracy. This in turn may (and in our case has) added additional requirements for ancillary calibration mechanisms that become part of the telescope design.

The engineering group is performing studies of their own, generally including design studies, trade studies, and analysis of the developing design. Systems engineering uses error budgets to place requirements on subsystems, and does performance modeling of groups of subsystems to test error-budget compliance.

1.4 LEVEL 4 – COMPONENT SPECIFICATIONS The last step in the flowdown process is individual “component” specifications. The ATST project considers a component to be an element of the design that is obtained through a single construction contract. The task of writing a component specification falls primarily to lead engineers responsible for given subsystem that includes that component with support from systems engineering, again to assure compliance with science requirements and error budget constraints.

For ATST our construction strategy is to contract most of the work, including final design verification. We provide manufacturing vendors with performance-based specifications, allowing them to make some modifications to our reference design where it allows them to substitute parts with which they have more experience or familiarity if it saves cost without compromising performance. For example, the mount vendor may choose to use rolling bearings rather than hydrostatic oil bearings if cost and performance

3 Thomas Rimmele and the Science Team, “ATST Science Requirements Document,” Project Document SPEC-

0001. 4 D&D proposal, Appendix 1, §2.1, Science Objectives Overview. 5 SRD, §2.8. 6 D&D proposal, §3.1, Optical Configuration.



goals can still be met. During this phase it is essential that each specification be traceable back to the fundamental requirements so that negotiations with vendors do not inadvertently cause non-compliance.



2. THE SCIENCE REQUIREMENTS DOCUMENT

The ATST Science Requirements Document (SRD) is at the heart of all requirements related to Level 1 and Level 2. It is the source of 25 specific requirements placed on ATST. In the discussion that follows they are identified with references to the SRD and numbered for future reference with an S- prefix to distinguish them from requirements derived from other sources (i.e., engineering, operational, or safety). All of the specific science requirements, in numerical order, are also listed in Appendix A of this document.

The role of systems engineering with regard to Level 1 and Level 2 requirements is relatively minor, beyond reading, understanding, identifying the requirements, and ultimately placing the document under change control.

2.1 LEVEL 1 REQUIREMENTS Section 2 of the SRD is entitled, “Top Level Science Requirements,” and Section 4 is entitled “Top Level Telescope Requirements.” These correspond well to the Level 1 Observatory Requirements outlined above. The following specific requirements are found therein.

2.1.1 Wavelength Coverage S-005 Wavelength Coverage: The ATST shall cover the wavelength range from 300nm to

28μm. (SRD §2.4)

2.1.2 Flexibility S-013 Simultaneous wavelengths: Simultaneous multi-wavelength observations in the visible

and IR must be possible. (SRD §4.7)

S-014 Simultaneous instruments: Simultaneous observations with different instruments must be possible. (SRD §4.7)

S-015 Visitor Instruments: An observing room environment with optical benches for user instrument setups must be provided. (SRD §4.7)

S-016 De-rotation: The solar image feed to the observing room has to be de-rotated. De-rotation without additional optics, e.g., a rotating coudé platform, is preferred. (SRD §4.7)

S-017 Fast Change: Maximum scientific productivity requires easy and fast (<30 min) switch between various facility instruments. (SRD §4.7)

2.1.3 Lifetime S-018 Lifetime: The ATST is expected to be the major ground-based facility for a minimum of

two decades. The useful lifetime of ATST is expected to exceed 40 years. (SRD §4.7)

2.1.4 Adaptability S-019 Adaptability: The ATST shall be designed with a minimum of limitations for future use

and in a way that allows future upgrades and the addition of new instruments. (SRD §4.7)

2.1.5 Availability S-020 Availability: Engineering and maintenance time should not exceed 15% of the total

daylight hours available. (SRD §4.7)



2.1.6 Coordination S-021 Coordination: The ATST shall be operated in a way that allows coordinated and

simultaneous observations with space missions and other ground based observatories. (SRD §4.7)

2.2 LEVEL 2 REQUIREMENTS Section 3 of the SRD includes 18 example science cases “spanning the critical functions” of ATST from which the authors derive specific systems requirements. These lead to most of the Level 2 systems requirements. For each science case the SRD authors listed the requirements in terms of eight parameters:

1. Spatial Resolution

2. Time Resolution

3. Field of View (FOV)

4. Wavelength (WL)

5. Spectral Resolution

6. Polarimetry Sensitivity

7. Scattered light

A matrix of the science cases and the requirements parameters appears in Table 2.1 below.

Table 2.1. The sciences cases (left column) and the requirements imposed on eight observational parameters (top

row). The most extreme values within the table body are highlighted.



The column headings taken individually and in combination justify 12 additional science requirements, all of which are also codified in Section 4 or 5 of the SRD:

S-001 Image Quality

Constraint columns: spatial resolution.

Result: Three delivered image quality error budgets including seeing limited coronal mode, seeing limited on-disk mode, and diffraction-limited on-disk mode (see also section 3.2 below). (SRD §5.1.1 and §5.1.2)

S-002 Aperture

Constraint columns: spatial resolution, time resolution, spectral resolution, polarimetric sensitivity.

Result: Aperture ≥ 4 meters (SRD §4.1 and §4.2)

S-003 High-order Adaptive Optics

Constraint columns: spatial resolution.

Result: The Adaptive Optics system must have ≥ 1000 DOF. (SRD §5.0) S-004 Field of View

Constraint columns: field of view.

Result: Coronal ≥ 5 arcmin, on-disk ≥ 2 arcmin (square). (SRD §4.5) S-005 Wavelength Coverage

Constraint columns: Wavelength.

Result: 300nm to 12μm. (SRD §2.47) S-006 Operational Modes

Constraint columns: spatial resolution, field of view, wavelength coverage, spectral resolution, scattered light.

Result: The science cases cleave neatly into two distinct classes. The first requires a large field of view, minimum reflections, somewhat reduced image-quality performance, instrumentation with relatively fast beam speeds, and good performance in the UV. These observations are best performed at a Nasmyth observing station. The second class requires diffraction limited performance over a somewhat reduced field of view from the visible to the thermal IR. These observations are best performed in a large coudé lab.

S-007 Instrumentation

Constraint columns: spatial resolution, time resolution, field of view, wavelength, spectral resolution, polarimetry.

Result: The first-generation instrument suite (in priority order) will consist of a Visible Broadband Imager (VBI), a Visible Spectro-polarimeter (ViSP), a Near IR

7 This is superseded by the Level 1 requirement for wavelengths as red as 28 μm.



Spectro-polarimeter for coronal work (NIRSP-N), and a Visible Tunable Filter (VTF). (SRD §6.3)8

S-008 Scattered Light

Constraint columns: scattered light.

Result: < 25 millionths of on-disk irradiance. (SRD §4.4) S-009 Polarimetric Sensitivity

Constraint columns: polarimetry.

Result: Polarimetric sensitivity must be 10-5 of the I signal in Q, U, and V. (SRD §4.3 and §5.5)

S-010 Polarimetric Accuracy


Result: Polarimetric accuracy must be 5×10-4 of the I signal in Q, U, and V. (SRD §4.3 and §5.5)

S-011 Polarimetric Stability


Result: Calibration stability shall not change by more than 5×10-4 over 15 min. (SRD §5.5)

S-012 Polarimetric Crosstalk


Result: Crosstalk between Stokes Q, U, and V shall be limited to < 5%. (SRD §5.5)

2.3 ADDITIONAL SPECIFIC REQUIREMENTS FROM THE SRD Four additional requirements also appear in the SRD at Level 2, but differ from the previous 12 only in that they cannot be derived from the values in Table 1.

S-022 Blind Pointing: Absolute blind pointing shall be accurate to < 5 arcsec. (SRD §5.6)

S-023 Offset Pointing: Offset pointing shall be accurate to < 0.5 arcsec. (SRD §5.6)

S-024 Tracking Stability: Tracking stability shall be < 0.5 arcsec for > 1 hr. (SRD §5.6)

S-025 Coronal Off Pointing: In coronal observing mode it must be possible to observe out to 1.5 Rsun from disk center in all directions. (SRD §5.6)

2.4 THE HANDOFF TO ENGINEERING Figure 2.1 shows the state of affairs upon completion of the SRD. Most Level 2 work was complete, though not all. For example, neither the SRD nor the instrument science requirements documents (ISRDs) had much to say about data rates and data storage requirements. Information of this sort is gained through continuing interactions between the project, the project scientist, his science working group, and the instrument partners. This situation is not unique to data handling, but only serves to demonstrate that the “handoff” to the engineering group is not a hard line represented by a key date or

8 The SRD goes on to list (still in priority order) a near-IR tunable filter, a thermal IR polarimeter and spectrometer,

a visible/near-IR high-dispersion spectrograph, and a UV polarimeter. Only the previous four listed in the text have been proposed for the construction phase of ATST.



milestone. The closest thing to an identifiable date is the day upon which the SRD was put under change control (11 August 2003). Changes to the SRD can and have continued, but formal change orders, subject to review by the change control board, have been required from that point forward.9

All subsequent steps performed by the ATST engineering team are subject to scientific review. The primary responsibility for this falls to the Project Scientist with the support of the Science Working Group (SWG). The SWG meets at least annually, reviews the project’s progress, and allows systems engineering to seek clarification on key points. These discussions sometimes result in revisions to the SRD.

9 For more information about ATST change control, see SPEC-0040, the ATST Integrated Change Control Plan

noted in the references at the end of this document.

Figure 2.1. The division of labor between the SRD and engineering activities.



3. FLOWDOWN TO SUBSYSTEM REQUIREMENTS

Systems engineering plays a vital role during the development of Level 3 requirements. The task begins with the formal division of the telescope system into appropriate subsystems, each managed by a lead engineer. ATST has been divided into seven top-level subsystems:

1. Telescope Assembly 2. Wavefront Correction 3. Instruments 4. Controls and Software 5. Enclosure 6. Support Facilities and Buildings 7. Remote Operations Building

These top-level divisions were driven largely by the anticipated ATST contracting strategy, representing the largest possible divisions such that each could be (though may not be) constructed by a single contractor. In all cases, however, these top-level subsystems are further subdivided at logical boundaries, again keeping contracting possibilities in mind. Smaller contracts may increase the management burden and complexity of interface control, but these disadvantages may be more than offset by increasing the pool of interested vendors and the resulting improved competition during the bid process. The Telescope Assembly, for example, is further divided as follows:

1.0 Telescope Assembly 1.1 Telescope Mount Assembly 1.2 M1 Assembly 1.3 Heat Stop Assembly 1.4 M2 Assembly 1.5 Feed Optics 1.6 [no longer used] 1.7 System Alignment 1.8 Acquisition System

One more division is allowed when required at the system engineering level as, it is for the Telescope Mount Assembly:

1.0 Telescope Assembly 1.1 Telescope Mount Assembly

1.1.1 Mount Structure 1.1.2 Mount Drive System 1.1.3 Coudé Rotator Structure 1.1.4 Coudé Rotator Drive System 1.1.5 Nasmyth Rotator Structure 1.1.6 Nasmyth Rotator Drive System 1.1.7 Ancillary Mechanical Equipment 1.1.8 Mount Control System 1.1.9 TMA Local Interlock Controller 1.1.10 Telescope Pier Assembly 1.1.11 TMA Tools and Equipment

These subsystem definitions carry into the ATST work breakdown structure, Interface Control Chart (the N2 diagram), and construction-phase budget numbers. Once the subsystems have been established and responsibility assigned, the formal flowdown of requirements to subsystems (Level 3 flowdown) can begin.



3.1 THE RELEVANCE MATRIX The next essential step is to assess the relevance of a particular science requirement to a specific subsystem. This is done at the deepest (most detailed) level of the subsystem tree. The matrix is populated by asking the deceptively simple question, does the design of component x have a direct impact on meeting science requirement S-0YY? For example, can the design of 1.1.2, the Mount Drive System, impact image quality? Yes it can since drive jitter will blur the image. The result of this process for the telescope mount assembly is shown in figure 3.1.

This step accomplishes two things. First, it forms the basis for initial discussions between systems engineering and the lead engineers. Second, it forms a rudimentary compliance checklist when systems engineering reviews the component specifications document prior to the bid process.

Figure 3.1. The TMA relevance matrix.



3.2 THE ERROR BUDGETS One clear result from the relevance analysis is the dominant impact of the image quality. There are 85 subsystems down to the third level in the ATST work breakdown structure, and 56 of these will directly impact image quality. Even the orientation of the support and operations building with respect to the telescope enclosure is driven by image quality considerations. Image quality is an obvious candidate for error budgeting, as it is with most modern telescope projects.

The SRD gives very specific guidance on either the allowed degradation of images by the telescope systems, or on the bottom-line performance including the atmospheric degradation. Three image quality requirements were selected from the available SRD observational use cases because they are the most demanding, and span the maximum number of subsystems:

• Coronal seeing limited – This error budget value is specified for observations of the sun’s corona at a wavelength of 1μm. Observations are performed at Nasmyth, so there is no deformable mirror available to correct wavefront errors. It is not possible to generate error signals for tip tilt corrections10, closed loop M1 figure control, or quasi-static alignment. (The latter two are slowly changing image-degradation issues that will be controlled to some extent with look-up tables that allow repeatable errors to be corrected.)

• Seeing Limited on-disk – This error budget value is specified for observations on the disk of the sun at 1.6μm. Observations are performed at coudé. The tip-tilt, M1 figure and quasi-static alignments loops are closed. The high-order AO system is off, but the deformable mirror is available for use in correcting repeatable wavefront errors that result from telescope and coudé room orientations via lookup tables. This SRD requirement is also stated in terms of the allowed degradation of the image by the telescope and instrument systems.

• Diffraction Limited on Disk – This error budget value is specified for observations on the disk of the sun at 500nm. Observations are performed at coudé. The fast tip-tilt, M1 figure and quasi-static alignments loops are closed. The high-order AO system is also running closed loop. This SRD requirement is stated in terms of delivered Strehl ratios in the image plane, so residual atmospheric errors after AO correction are also factored in.

The three error budgets are summarized in Table 3.1. Note that the last column – allowed image size at 50% encircled energy – is slightly misleading as they are specified at different wavelengths, and the first two error budgets exclude residual atmospheric effects. Still, there is an obvious progression, each budget requiring better and better performance. At first glance the coronal error budget might be expected to place the maximum number of constraints on the raw telescope performance, the second showing what is expected from the fast steering mirror that corrects tip tilt and the aO system that corrects M1 mirror figure and quasi-static misalignment. The diffraction-limited error budget obviously places requirements on the AO portion of the wavefront correction system.

In practice the situation is somewhat more complex. A naive pass through the error budgets performed on the progressive assumption places unrealistic requirements of the wavefront correction subsystem, and this sends requirements back up the chain toward uncorrected telescope performance. For example, it is the residuals after high-order AO correction that places optical polishing requirements on the uncorrectable high spatial frequency components of M1. Performance limits on the fast tip-tilt subsystem push requirements all the way back to mount stiffness and resonance frequencies. In the final analysis it is the middle error budget (seeing limited on disk coudé observations) that is the most demanding on telescope performance.

10 It may be possible for the NIRSP instrument to correct image motion in one dimension, but for the purposes of

this error budget, worst-case assumptions have been made.



Active Optics Loop Tip-Tilt Loop High-order AO 50% EE

Seeing limited coronal

Open

(Lookup Table) Open Open 0.70 arcsec

Seeing limited on-disk Closed Closed Open 0.15 arcsec

Diffraction limited on disk Closed Closed Closed 0.03 arcsec

Table 3.1 Error Budget Comparison

The development of the ATST error budgets is documented in SPEC-0009, “The ATST System Error Budgets.” The error budgets are constructed by first generating an error tree, which specifies all factors in the telescope and instrumentation that can contribute to image degradation. There is not a one-to-one correspondence between relevant subsystems and the error tree. Such an error tree would be too large and unwieldy, and would inhibit rather than facilitate communication. The error tree is instead organized by error source (atmosphere, telescope, or instrument), then by dynamic versus static effects.

Next, top-down initial error budget values are assigned to each element of the error tree, often based on the performance of similar telescope systems already in operation. Over time these are replaced by bottom-up values as the reference design develops and analysis is performed specific to the ATST design. As an example, a version11 of the diffraction limited error budget is reproduced in Appendix B.

3.3 ERROR BUDGET FLOWDOWN TO SUBSYSTEMS The image-quality error budgets are abundant sources of subsystem requirements. As with most aspects of the Level 3 flowdown, systems engineering is central to the activity, at least during the initial phases.

The work of flowing down requirements begins in a way very similar to the relevance matrix population, taking a systematic pass through the error budgets. Seven steps are typically required:

1. Look at each cell of the three error budgets (75 cells in all).

2. Compare the cell against each subsystem called out in the work breakdown structure asking, “Can this error be exacerbated or mitigated by this subsystem?”

3. Compile a list of all relationships between budget cells and subsystems.

4. Write a brief explanation of the relationship for each.

5. Resort by subsystem.

6. Discuss with appropriate lead engineers.

7. Assist with conversion to “engineering units” as required.

When this process is performed on, for example, error cell “2.1.2 M1 Figure Error” the impacted subsystems are as shown in Figure 3.2. The multipliers that appear in the figure are a reminder that this same error is repeated in three different error budgets and any or all of them may impact a given subsystem. After re-sorting all results by subsystem rather than by error cell it is possible to answer the question on the mind of each lead engineer, “How do the systems error budgets constrain my design?” The result for a sample subsystem (WBS element), “1.1.1 Mount Structure” appears in figure 3.3.

11 This “version” is a snapshot on a given day, and is reproduced in the appendix for reference only. Error budgets

are rebalanced as needed through the life of the project.



Figure 3.2. The subsystems impacted by the M1 Figure Error budget value.

Figure 3.3. Error cells impacting the Mount Structure.



The last step in the procedure is often the most challenging: converting to “engineering units.” It is rare that a budgeted error in units of either 50% encircled energy or Strehl ratio is very useful to a design engineer. Typically at this juncture it is useful sit down with the responsible engineer and mutually agree on which aspects of the design are affected by the error budget constraint. For the case of the mount structure the mapping from error tree element to an engineering specification would look something like the following:

1.1.1 Mount Structure

Quasi-static optical alignment ⇒ Allowed gravity flexure

Mirror Seeing ⇒ Free airflow goals

Dynamic Optical Alignment ⇒ Allowed wind-induced flexure

Wind Shake ⇒ Allowed wind-induced flexure

In many cases the specific constraints on the design can only be determined by modeling and other forms of analysis. This process must be performed for each element of the WBS.

3.4 LEVEL 3 PROCESS AND RESPONSIBILITIES While the flowdown process is a joint effort on the part of systems engineering and the lead engineers, systems engineering is responsible for communicating the scientific requirements and ensuring compliance. The project scientist also closely monitors and participates in this process, as he has the ultimate responsibility for compliance. Another check is performed annually by the science working group, which conducts annual “science reviews” of the design.

Systems engineering performs its functions in several ways. First, and most obvious, the science requirements document is made available to all. This step is clearly necessary, but far from sufficient. It is more important to translate these into engineering terms as described in the preceding sections.

Another critical function of systems engineering in this process is the close monitoring of the subsystem designs from concept, through baseline, to the reference design. This is done through weekly systems engineering meetings that include all senior engineers, systems engineering, and the project scientist. These meetings start with a request for updates from lead engineers on significant changes made to the design since the last meeting. These are recorded and documented in a web-based systems change log. This log is invaluable for tracing the motivation for incremental design changes. Prior to the change log there were instances where an important change was made to solve a critical problem, and then changed back when the problem went out of mind. This “systems change” aspect of the weekly meeting only takes five minutes or so.

The rest of the weekly systems meeting is devoted to a presentation by one of the lead engineers. The topics vary, but will generally consist of an overview of design progress, or a discussion of recent analysis results. The presentations rotate through the engineering staff, including the systems engineer, allowing an opportunity for mini reviews of each subsystem at an interval of a few months.

Systems engineering also provides some of the performance analysis of multiple subsystems to test design compliance or rebalance error budgets.



4. COMPONENT SPECIFICATIONS

As noted previously, the ATST construction strategy depends on contractors to build components that meet the project’s requirements. In a perfect world the contractors who will build ATST components would have been full participants in the design process. A number of complex factors and circumstances prevent this, however:

• Projects like the ATST are divided into two distinct and exclusive phases: the design and development (D&D) phase and the construction phase. The funding for these two phases comes from different sources within the NSF.

• An NSF project in the D&D phase is not yet approved for construction, and there is a possibility that it never will be.

• Many potential subsystem vendors are not interested in designing something for which construction funds are not guaranteed, especially when the construction start date cannot even be specified.

• Even where vendors are willing to undertake design-only contracts, the project cannot afford multiple designs of the same components. Hence, it would be necessary to down-select to one vendor very early before the design is sufficiently mature to determine the cost of construction. This leaves no practical way to compete the construction contract since one vendor is unlikely to take responsibility for the performance of another vendor’s design. This is likely to increase the cost in many cases.

The project’s strategy for overcoming these difficulties is to internally produce detailed “reference designs” of individual subsystems. These designs are done in sufficient detail to allow accurate costing and detailed performance modeling. When completed they represent one possible solution to the design challenges presented by a particular component that meets the project’s requirements and can be completed within budgetary constraints.

The reference designs and accompanying analyses and study results will be made available to potential vendors at the time that the bid package is released. They do not, however, represent component specifications. The contractors will be held to performance-based specifications; the designs provided are for reference only.

In this construction model, Level 4 of the flowdown process takes subsystem requirements and changes them to the detailed specifications documents that become the performance-based specs. These specifications documents (sometimes called design requirements documents informally) become part of the bid packages.

4.1 FLOW DOWN TO COMPONENT SPECIFICATIONS Science requirements are not the only source of component specifications. They actually come from one of four sources:

1. Science requirements as outlined in the preceding sections. The image quality requirement is an obvious example.

2. Operational requirements. Data rates and storage capacities are an example of these, as they are not called out in the SRD or ISRDs.

Operational requirements are compiled in Operational Concepts Definitions (OCD) documents. They capture the needs of our users, and are often obtained through analysis of detailed use cases. The information is gleaned through interactions with instrument development partners, science working group members, and users of the present generation of solar instrumentation. The OCD



documents serve as a vehicle to obtain formal consensus between scientists and designers for items outside of the scope if the SRD and ISRDs.

3. Engineering Requirements. An example of an engineering requirement would be cable wraps and their ranges of travel. The rotating structures in the telescope system require some means of getting utilities across moving boundaries even though such implementation details are far beyond the scope of SRD or the OCD documents.

4. Safety Requirements. The requirement for non-skid flooring surfaces would be an example of a safety requirement. Some of these requirements can be taken from existing standards and codes. The ATST project has documented its specific safety requirement sources in the ATST System Safety Plan12 and other documents referenced therein.

In addition to collecting and documenting the project’s system safety requirements, systems engineering takes primary responsibility for formal hazard analysis of the ATST design as outlined in MIL-STD-882D. In summary, systems engineering works with lead engineers to identify hazards within the design and mitigate them to achieve an acceptable mishap risk.

The end result of this process is specifications documents, one for each contract for the construction of a component. Some significant examples include (but are by no means limited to) the following:

WBS 1.1 – SPEC-0011 Telescope Mount Assembly Specifications Document

WBS 1.2 – SPEC-0007 M1 Assembly Specification

WBS 1.3 – SPEC-0003 Heat Stop Specification

WBS 4.1 – SPEC-0017 Common Services Specification

WBS 5.0 – SPEC-0010 Enclosure Specification

These documents are placed under change control as soon as they have been reviewed and approved for inclusion in bid packages.

4.2 TRACE BACK Unfortunately the process does not end with the completion of the specifications documents. There are a variety of reasons why the specifications may have to be changed even after the documents are reviewed and “frozen.” For example,

• Future analysis may show that an error budget target cannot be met, causing error budgets to be rebalanced.

• A vendor may take exception to a specification.

• A specification may be tight enough to increase the cost of the component beyond anticipated ranges, again causing error budgets to be rebalanced.

Changes to specifications can, and likely will, have ramifications far beyond the narrow context in which they are encountered. It once again falls to systems engineering to trace back to the original source of the requirement and understand its dependencies. For example, if there is pressure to reduce the cross section of the exhaust tunnel that connects the telescope enclosure (as specified in an interface control document), this impacts fan sizes, the capacity of the lower enclosure cooling, air scavenging systems, thermal control of the Support and Operations mechanical room, and ultimately could impact image quality via the enclosure seeing error budget.

12 R. Hubbard, “ATST System Safety Plan,” Project Document SPEC-0060.



The lowest level of trace-back information is provided within the specifications documents. All individual specifications associated with a component include a comment on how compliance will be verified and the requirement origin. For example, SPEC-0011 has the following specifications for the telescope mount assembly’s static flexure and personnel access:

1.1.1-XXXX Static Flexure

As the OSS rotates from zenith to horizon and back, and the mount base rotates in azimuth, some amount of flexure of the structure is expected to occur. As a result, the optic assemblies shown in Table 2 will likely displace and rotate discrete amounts from their nominal initial-aligned positions. It is critical to the operational performance of ATST that these displacements and rotations do not exceed pre-defined allowable amounts…

Verification: Analysis & Factory Test Requirement Origin: Science Requirement

1.1.1-XXXX Mount Structure Personnel Access – Locations At a minimum, access (including, where necessary, access platforms, ladders, etc) shall be provided for the following areas on the mount structure: • Interior of the mount base; • The two mount access platforms at the +X and –X-sides of the mount columns. There shall be an

access ladder to each of these areas. The design of the –X platform shall be sufficiently stiff such that three persons working on this platform will not displace or rotate the Nasmyth payload beyond the static flexure requirements of this document;

… Verification: Design Review & Inspection Requirement Origin: Engineering, Safety, Operational Requirement

While this does not give sufficient detail to trace back to find additional dependencies, it does broadly classify the nature of the requirement, eliminating possibilities in some cases.

Facilitating full trace back of specifications is a relational database problem as it is necessary to establish relationships between various intricately related pieces of information:

• Science requirements: S-001 through S-025 • Operational concepts: OC-XXX… • Specification elements: 1.1.1-XXX… • Error budget values: DL-1.1.1… • Interface control information: ICD5.0/6.1 §3.1… • Explanations

Reports can be generated that answer questions like the following:

• If an error budget value cannot be met, what subsystems are impacted? • If the vendor cannot meet a specification, where did it come from in the first place? • If an error budget is rebalanced, what manufacturing specifications must be changed?

The existence of such a database reduces reliance on incomplete or faulty memory and also reduces exposure in the event of loss of key personnel.



References

Bely, Pierre Y., ed. The Design and Construction of Large Optical Telescopes, pp. 69-72. Springer 2003.

Thomas Rimmele and the Science Team, “ATST Science Requirements Document,” Project Document SPEC-0001.

J. Wagner, R. Hubbard, R. Kneale, “Integrated Change Control Plan,” Project Document SPEC-0040.

R. Hubbard, “ATST System Error Budgets,” Project Document SPEC-0009.

R. Hubbard, “ATST System Safety Plan,” Project Document SPEC-0060.



APPENDIX A. THE SCIENCE REQUIREMENTS

S-001 – Image Quality a. Diffraction limited coudé i. Strehl > 0.3 at 500 nm ii. Strehl > 0.6 at 630 nm b. Seeing limited on-disk coudé: EE50 < 0.15 arcsec at 1.6 μm c. Seeing limited coronal Nasmyth: EE50 < 0.70 arcsec at 1.6 μm

S-002 – Aperture: ≥ 4 meters

S-003 – High-order AO: required, ≥ 1000 DoF needed

S-004 – Field of View a. Nasmyth: 5 arcmin circular b. Coudé: 2 arcmin square = 2.8 circular

S-005 – Wavelength Coverage: 0.30 to 28 μm

S-006 – Operational Modes: Nasmyth (Coronal & UV) and Coudé (diffraction limited)

S-007 – Instrumentation: Specific instruments named and prioritized

S-008 – Scattered Light: < 25 millionths of on-disk irradiance at 1.1 Rsun

S-009 – Polarimetric Sensitivity: 10-5 of Intensity in Q, U, and V

S-010 – Polarimetric Accuracy: 5×10-4 of Intensity

S-011 – Polarimetric Stability: Changes < 5×10-4 of Intensity over 15 minutes

S-012 – Polarimetric Crosstalk: < 5% between Stokes Q,U, and V

S-013 – Simultaneous Wavelengths: Over the full wavelength range

S-014 – Simultaneous Instruments: Required

S-015 – Visitor Instruments: Must be accommodated

S-016 – Image De-rotation: Must be achieved at Nasmyth and coudé

S-017 – Fast Instrument Change-over: Accomplished in < 30 minutes

S-018 – Lifetime: 20 to 40 years of anticipated operation

S-019 – Adaptability: Minimize limitations for future use

S-020 – Availability: Engineering and Maintenance < 15% of total time

S-021 – Coordination: Simultaneous observations with space and ground-based observatories

S-022 – Blind Pointing: Accurate to < 5 arcsec

S-023 – Offset Pointing: Accurate to < 0.5 arcsec

S-024 – Tracking Stability: Errors < 0.5 arcsec for > 1 hour

S-025 – Coronal Off Pointing: Accurate to < 0.5 arcsec



APPENDIX B. THE DIFFRACTION LIMITED ERROR BUDGET

atst requirements flowdown - dkistwere outlined in the design and development proposal to the nsf2,...

Documents