System Engineering Plan

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

System Engineering Plan

Rob Hubbard, Jeremy Wagner, Larry Daggert,

Larry Stepp, Christoph Keller

Systems Engineering / Project Management

REVISION SUMMARY:

1. Date: 5 October 2006

Revision: A

SPEC-0064, Revision A iii

Table of Contents

Preface ... 1

1.

SYSTEMS ENGINEERING ... 2

1.1

D

R

F

D

... 2

1.2

C

D

... 2

1.3

I

... 2

1.4

E

B

... 3

1.5

S

... 3

1.6

S

D

... 4

1.7

P

M

... 4

1.8

Q

A

P

... 4

1.9

A

T

P

... 5

1.10 I

P

... 5

1.11 D

C

... 5

2.

SYSTEMS ENGINEERING DELIVERABLES... 8

2.1

P

S

D

... 8

2.2

C

D

R

D

... 8

2.3

P

D

R

D

... 8

2.4

C

D

R

D

... 9

3.

SYSTEMS ENGINEERING DURING CONSTRUCTION AND IT&C ... 10

3.1

C

M

C

C

... 10

3.2

Q

A

Q

C

P

E

... 10

Preface

The genesis of the first two sections of this document dates back to the writing of the ATST Design and Development proposal to the National Science Foundation. Its original title was “Systems Engineering Deliverables”. It has now been recast as part of a project “specification” (SPEC) document and designated the “Systems Engineering Plan” as it continues to accurately reflect systems engineering activities to date as well as those anticipated in the near future. Only a few minor changes have been made to the original document during this recasting, mostly modifying terminology slightly to maintain consistency with the nomenclature subsequently adopted by the ATST project.

Section three of this document is new. It describes systems engineering during the construction phase, as the scope of the original “Systems Engineering Deliverables” was limited to the Design and Development phase of the project. The roles and responsibilities of systems engineering during the construction phase are summarized here, including references to other project documents that describe these aspects of systems engineering in detail.

SPEC-0064, Revision A Page 2 of 11

1. SYSTEMS ENGINEERING

Designing a facility as complex as the ATST requires concurrent engineering, i.e. the design and development activities must proceed in parallel. As the designs evolve, there must be continuous adjustment of requirements and rebalance of the interfaces between different subsystems. Also, during the design and development phase the project will need to prepare procedures and plans that will be required for the construction phase. To accomplish these goals in an efficient manner that ensures technical success and controls cost and schedule, the project will have a strong systems-engineering program. Systems engineering staff will work with project management, the scientific staff, and the other engineers to accomplish the activities described below.

1.1 D

R

F

D

The design of the ATST must meet the needs of the scientific programs for which the facility will be built. Systems engineering will support the scientific staff as they define system performance requirements in terms of image quality, field of view, control system interfaces, data management requirements, allowable downtime, specific needs of the scientific instruments, etc. These requirements will be developed into a formal Science Requirements Document1.

Systems engineering will then work with the scientists and engineers to flow down2 these science requirements into the design requirements of individual subsystems, including the post-focus instruments. This flow down will occur over a period of time as the conceptual designs evolve, leading to a formal Design Specifications Document for each subsystem.

1.2 C

D

Various conceptual designs of the facility already exist. These conceptual designs will be further refined during the initial phase of design and development. During this process, systems engineering will work with other engineering staff to develop a logical breakdown of the telescope into hardware and software subsystems with clearly defined interfaces3. Error budgets will be developed to help define appropriate tradeoffs of cost vs. performance in each subsystem and to maximize the overall telescope performance within the allocated budget and schedule.

1.3 I

Project Management will set up a division of responsibilities for the project. Based on the conceptual designs, systems engineering will develop a matrix to define where interfaces exist between responsible groups. Then interface control documents (ICDs) will be developed for each interface4.

An ICD is an agreement, essentially a contract, between two or more groups in the project. It may be between two groups of project staff, or it may be between the project and a contractor or partner organization. The document must not only define the interface, but also identify who does what. Each ICD must be negotiated much like a contract would be. If a contractor will perform the work, the ICD becomes part of the contract.

1

SPEC-0001 – The ATST Science Requirements Document, Rimmele, et al. 2

SPEC-0066 – Requirements Flowdown, Rob Hubbard 3

ICD N2 Chart 4

In general, ICDs cover optical, mechanical, electrical and software interfaces, as appropriate. All the ICDs for a given subsystem should be controlled by the time of the preliminary design review (PDR) for that subsystem.

A formal revision process will be set up to control changes to the ICDs. There will often be situations where a change in an ICD affects the plans of several groups, including ones that may not have been part of the original agreement. Therefore, as changes in ICDs are required, it is important that these changes be communicated with all affected groups. In some cases, when an ICD is changed, a revision of schedules, budgets or error budgets may be required.

1.4 E

B

A number of error budgets will be required for this project5. A preliminary list of potentially useful error budgets might include the following:

• image quality in various wavelength bands • pointing and tracking accuracy

• scattered light

• instrumentally induced polarization

The image quality error budgets will be among the key error budgets6.

The initial error budgets will be “top-down” budgets. They will divide up the allowable error into individual contributions and assign portions of the budget to each subsystem, based on educated guesses of performance feasibility.

As the conceptual designs develop to the point that performance predictions can be made, the results of these analyses will be used to replace these values with “bottom-up” entries. As further understanding is gained about which aspects of the error budget are easy to attain and which are difficult, the error budgets will be adjusted in order to minimize costs and risks while still meeting performance requirements.

1.5 S

Systems engineering will work with the other engineering staff to develop hardware and software design standards, documentation standards7, and standardized terminology8.

A simple example of a design standard is the need to define whether designs will be in English units or metric units. Standards will be developed for both hardware and software to ensure the use of common components, compatible subsystems, and a modular approach wherever possible. This is important to help control life-cycle costs for the facility. These include operating costs, maintenance costs such as staffing requirements and the quantity of spare parts required, and the cost to upgrade systems as new technology becomes available.

Documentation standards will include standard drawing formats and file types, as well as standard templates for project documents such as ICDs, integration plans, etc. Systems engineering will also

5

SPEC-0009 – ATST System Error Budgets, Rob Hubbard 6

DIQ CASE 1a, Diffraction Limited 500 nm; DIQ CASE 1b, Diffraction Limited 630 nm; DIQ CASE 2, Seeing Limited On-disk; DIQ CASE 3, Seeing Limited Coronal

7

SPEC-0002 – Document Drawing and Control Plan, Ruth Kneale 8

SPEC-0064, Revision A Page 4 of 11

compile a listing of standardized names and definitions. When writing ICDs or contracts it is very important that the terms used are clearly defined in a manner that is consistent across the entire project.

1.6 S

D

The engineering staff will develop a specification document for each subsystem, including each post-focus instrument. Systems engineering will coordinate these efforts and provide guidance on general requirements such as environmental conditions. The design specifications will cover subsystem performance, dimensional and weight limits, compatibility issues, reliability, maintainability, and environmental conditions. They will reference the appropriate ICDs. Where a contractor will perform the work, the specification document will be part of the contract. The specifications documents will be reviewed at a Systems Design Review which will be held during the preliminary design phase before the preliminary design review (PDR).

At the preliminary design review and critical design review (CDR) for each subsystem, the designs will be judged against the requirements specified in the specifications documents

1.7 P

M

The engineering staff and contractors will develop analytical models to predict the performance of the subsystems of the telescope and the post-focus instruments. Systems engineering will coordinate these efforts and to the extent possible will integrate these analyses to provide end-to-end modeling of the total system performance. These analyses will be repeated as the designs develop to provide improved performance predictions and to allow adjustments in error budgets, interfaces, and design requirements.

1.8 Q

A

P

The quality assurance plan9 will define quality control procedures to be used in the construction phase of the project to ensure manufactured and purchased parts meet specified requirements. The subjects covered in the quality assurance plan will include:

• configuration control procedures for drawings, DRDs, and ICDs used for the fabrication of parts or subassemblies

• procedures for incoming inspection of purchased parts to ensure they meet specifications • procedures for identification and control of parts in inventory

• requirements to be imposed on contractors who are manufacturing parts or subassemblies for the project

Each contract will be required to have its own quality assurance plan that meets project guidelines10. The contractor’s quality assurance plan will cover:

• acceptance test plans;

• inspection methods and calibration of inspection equipment • disposition of discrepant parts

• traceability of critical materials

9

SPEC-0025, ATST Quality Assurance and Quality Control Plan, Rob Hubbard 10

The project quality assurance plan will be written by systems engineering, with technical assistance from other engineering staff.

1.9 A

T

P

During the construction phase, each contractor will be required to prepare an acceptance test plan that will ensure that the part or subsystem it manufactures will comply with the requirements specified in the contract. Among other things, the acceptance test plan will define tests and inspections to ensure:

• compliance with all dimensional and tolerance accuracies, surface properties, weld qualities, material qualities and coatings

• proper form, fit and alignment of all components

• compliance with all interface requirements including weight limits • test procedures

• verification of requirements on operating conditions such as power dissipation, electromagnetic compatibility or vibration levels

The contractor will submit its acceptance test plan to the project for approval in advance. In addition, project staff will develop acceptance test plans for any subassemblies or equipment items that will be manufactured or assembled under their supervision.

Systems engineering will work with the engineering staff to define standards for the acceptance test plans, review plans submitted by contractors, and develop acceptance test plans for any subassemblies produced by the project.

1.10 I

P

Carefully prepared plans will be needed to guide the integration of subassemblies into the complete ATST facility11. For each subassembly or separate piece of equipment a formal integration plan will be prepared. The integration plans will cover:

• required equipment and tools

• safety precautions for personnel and equipment

• step-by-step procedures to define the proper sequence of tasks • test procedures to verify that the subassembly is functioning properly • time estimates of tasks required

Systems engineering will work with project staff to develop these integration plans during the latter portion of the design and development phase.

1.11 D

C

Systems engineering will coordinate the collection and control of technical documents, including: • Science Requirements Document

• Interface Control Documents • Specifications Documents

11

SPEC-0064, Revision A Page 6 of 11

• Error Budgets • Technical Reports • Drawings

• Quality Assurance Plan • Acceptance Test Plans • Integration Plans

In addition to the responsible engineer and engineering manager, systems engineering will sign approval for release and revision of:

• Interface Control Documents • Specifications Documents • Drawings

• Quality Assurance Plan • Acceptance Test Plans • Integration Plans

Systems engineering will also coordinate the collection and control of documents required for reviews. The following is a possible document set required for ATST reviews. This set should also be created for every major system (telescope, each instrument, facility) review. Every subsystem should have the same document set (and associated review) if possible, especially if the plan includes sending the design or the development out for contract.

A. Design Review Generated Documents

1. Introduction/Committee/Charge/List of Deliverables 2. Design Review Product Overview

3. Committee Report

4. Response to the Committee B. Systems Engineering Deliverables

1. Design Requirements Document (final at CoDR) 2. Interface Control Documents (final at PDR) 3. Test Plan and Procedures (final at CDR) 4. Error Budgets (final at CDR)

C. Engineering Team Deliverables 1. Design Document

(CoDR=Conceptual Design, PDR=Preliminary Design, CDR=Detailed Design) 2. Trade Studies

3. Prototypes

D. Project Management Deliverables 1. Work Breakdown Schedule

2. System Development Plan 3. Budget

E. Reference Materials (created at the beginning of the project) 1. Proposal

2. Science Case and Justification 3. Science Requirements

4. Documentation Standards and Templates

5. Systems Definition Document (w/Interface Matrix) 6. Project Plan

SPEC-0064, Revision A Page 8 of 11

2. SYSTEMS ENGINEERING DELIVERABLES

The following sections identify the specific deliverables required at the time specific project milestones are reached.

2.1 P

S

D

• a nearly fully or fully developed Science Requirements document for the Instruments and Telescope • define telescope system

• define instrument system

• define instruments/telescope interface • define telescope subsystems

• define instruments subsystems

• outlines for Functional Performance Requirements Documents • outlines for Interface Control Documents

In order to accomplish the effort listed above by project startup, it is assumed a fulltime systems engineer is onboard and works closely with the project scientist and telescope scientist for four months prior to project start. Their efforts are supported by instrument scientists, as well as part-time support from an administrative assistant and optical, mechanical and controls engineers as required.

2.2 C

D

R

D

• a fully developed Science Requirements document

• Functional Performance Requirements Documents with traceable flow down of requirements from science to technical

• telescope and instrument systems and sub-systems defined • standards for interchangeability of instruments

• standards for documentation and manuals • outlines for Interface Control Documents • top-down system error budgets

• initial hardware and software compatibility standards

2.3 P

D

R

D

• a fully developed Science Requirements document

• Functional Performance Requirements Documents with traceable flow down of requirements from science to technical

• standards for interchangeability of instruments • standards for documentation and manuals • fully developed Interface Control Documents • bottom-up system error budgets

• hardware and software compatibility standards

• initial performance evaluations and their comparison to error budgets and science requirements

2.4 C

D

R

D

• a fully developed Science Requirements document

• Functional Performance Requirements Documents with traceable flow down of requirements from science to technical

• Interface Control Documents • system error budget

• standards for interchangeability of instruments • standards for documentation and manuals • hardware and software compatibility standards

SPEC-0064, Revision A Page 10 of 11

3. SYSTEMS ENGINEERING DURING CONSTRUCTION AND IT&C

During the construction and integration test and commissioning phases, systems engineering plays critical roles in several areas. The systems engineering group during this period is part of the Project Management Office. The specific roles and responsibilities within various areas are described in the sections that follow.

3.1 C

M

C

C

Systems engineering will continue to be responsible for configuration management and change control as outlined in SPEC-0002 and SPEC-0040 respectively. The systems engineer will also serve on the change control board with the project manager, the project scientist, and the project director. This group will be expanded to include the lead IT&C systems engineer during IT&C, and the operations scientist and operations manager as commissioning transitions to operations.

3.2 Q

A

Q

C

P

E

The details of executing the quality assurance and quality control plan are described in the document SPEC-0025_QAQC. In summary, systems engineering will assume responsibility for overall compliance with QA/QC plans, including acceptance testing. In support of this, systems engineering will also refine, and continuously maintain and rebalance the error budgets for the ATST system as required, initiating change orders if necessary. The error budget document (SPEC-0009) will be kept up to date by systems engineering as changes are made.

The specific requirements that will be placed on contractors and vendors are outlined in SPEC-0065_QAQC_Requirements. Systems engineering will work with the contract officer’s technical representative (COTR) to enforce these requirements within each contract, with the systems engineer having ultimate responsibility for compliance.

3.3 I

T

C

The details of the IT&C plan are described in SPEC-0038, the ATST Commissioning plan. In summary, the goal of the integration, test and commissioning (IT&C) stage of construction is to convert a series of subsystems into a single instrument capable of delivering high quality science as specified in the ATST Science Requirements Document (SRD) and Operational Concepts Definition Documents (OCDDs) then verified by both commissioning tests as well as a science verification program. As the commissioning period is limited, it is important that the tasks and sequence of commissioning be carefully planned and executed. IT&C begins when elements from two sources, separately contracted by ATST or provided by the Project are integrated on site. This event creates the potential for conflict in areas of facility access, support staff resources, etc. As the IT&C schedule progresses and more subsystems are being integrated into the observatory, the task of orchestrating and supporting these activities becomes more complex. The Project Manager will delegate responsibility for day-to-day activities of integration, testing and commissioning to systems engineering. To execute that responsibility the systems engineering group will be staffed with skills required to perform orchestration of on-site activities, systems testing and optimization, documentation and management reporting. There are three major categories of IT&C management responsibility that fall to systems engineering. They are the orchestration of on site activities, tracking of observatory predicted performance, and status reporting.

There are four specific commissioning deliverables:

• Integration procedures and reports

• System calibration procedures and reports

• System performance Optimization procedures and report