System Engineering Plan

Project Documentation Document SPEC-0064 Revision A System Engineering Plan Rob Hubbard, Jeremy Wagner, Larry Daggert, Larry Stepp, Christoph Keller Systems Engineering / Project Management 5 October 2006 Advanced Technology Solar Telescope 950 N. Cherry Avenue Tucson, AZ 85719 Phone 520-318-8102 atst@nso.edu http://atst.nso.edu Fax 520-318-8500

REVISION SUMMARY: 1. Date: 5 October 2006 Revision: A Changes: First release as a specification SPEC-0064, Revision A ii

Table of Contents Preface...1 1. SYSTEMS ENGINEERING... 2 1.1 DESIGN REQUIREMENTS FLOW DOWN... 2 1.2 CONCEPTUAL DESIGNS... 2 1.3 INTERFACES... 2 1.4 ERROR BUDGETS... 3 1.5 STANDARDS... 3 1.6 SPECIFICATIONS DOCUMENTS... 4 1.7 PERFORMANCE MODELING... 4 1.8 QUALITY ASSURANCE PLAN... 4 1.9 ACCEPTANCE TEST PLANS... 5 1.10 INTEGRATION PLANS... 5 1.11 DOCUMENT CONTROL... 5 2. SYSTEMS ENGINEERING DELIVERABLES... 8 2.1 PROJECT STARTUP DELIVERABLES... 8 2.2 CONCEPTUAL DESIGN REVIEW DELIVERABLES... 8 2.3 PRELIMINARY DESIGN REVIEW DELIVERABLES... 8 2.4 CRITICAL DESIGN REVIEW DELIVERABLES... 9 3. SYSTEMS ENGINEERING DURING CONSTRUCTION AND IT&C... 10 3.1 CONFIGURATION MANAGEMENT AND CHANGE CONTROL... 10 3.2 QUALITY ASSURANCE AND QUALITY CONTROL PLAN EXECUTION... 10 3.3 INTEGRATION TEST AND COMMISSIONING... 10 SPEC-0064, Revision A iii

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 1 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 DESIGN REQUIREMENTS FLOW DOWN 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 Document 1. Systems engineering will then work with the scientists and engineers to flow down 2 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 CONCEPTUAL DESIGNS 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 interfaces 3. 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 INTERFACES 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 interface 4. 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 N 2 Chart 4 ICD Status Report SPEC-0064, Revision A Page 2 of 11

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 ERROR BUDGETS A number of error budgets will be required for this project 5. 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 budgets 6. 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 STANDARDS Systems engineering will work with the other engineering staff to develop hardware and software design standards, documentation standards 7, and standardized terminology 8. 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-0012 Glossary and Acronym List, Ruth Kneale SPEC-0064, Revision A Page 3 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 SPECIFICATIONS DOCUMENTS The engineering staff will develop a specification document for each subsystem, including each postfocus 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 PERFORMANCE MODELING 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 QUALITY ASSURANCE PLAN The quality assurance plan 9 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 guidelines 10. 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 SPEC-0065, QA/QC Requirements, Mark Warner and Rob Hubbard SPEC-0064, Revision A Page 4 of 11

The project quality assurance plan will be written by systems engineering, with technical assistance from other engineering staff. 1.9 ACCEPTANCE TEST PLANS 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 INTEGRATION PLANS Carefully prepared plans will be needed to guide the integration of subassemblies into the complete ATST facility 11. 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 DOCUMENT CONTROL Systems engineering will coordinate the collection and control of technical documents, including: Science Requirements Document Interface Control Documents Specifications Documents 11 SPEC-0038 ATST Commissioning Plan, Eric Hansen SPEC-0064, Revision A Page 5 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 SPEC-0064, Revision A Page 6 of 11

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 7. Project Standards and Specifications SPEC-0064, Revision A Page 7 of 11

2. SYSTEMS ENGINEERING DELIVERABLES The following sections identify the specific deliverables required at the time specific project milestones are reached. 2.1 PROJECT STARTUP DELIVERABLES 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 CONCEPTUAL DESIGN REVIEW DELIVERABLES 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 PRELIMINARY DESIGN REVIEW DELIVERABLES 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 SPEC-0064, Revision A Page 8 of 11

hardware and software compatibility standards initial performance evaluations and their comparison to error budgets and science requirements 2.4 CRITICAL DESIGN REVIEW DELIVERABLES 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 performance evaluations and their comparison to error budgets and science requirements SPEC-0064, Revision A Page 9 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 CONFIGURATION MANAGEMENT AND CHANGE CONTROL 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 QUALITY ASSURANCE AND QUALITY CONTROL PLAN EXECUTION 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 INTEGRATION TEST AND COMMISSIONING 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: On site acceptance test documentation for all subsystems SPEC-0064, Revision A Page 10 of 11

Integration procedures and reports System calibration procedures and reports System performance Optimization procedures and report SPEC-0064, Revision A Page 11 of 11