systems engineering management · 2020. 1. 22. · systems engineering management pmcs-0102,...

Project Documentation Document PMCS-0102

Revision B

Systems Engineering Management

Editor: M. Warner Project Management Office

August 2017

Name Date

Released By : Joseph McMullin Project Manager 16 August 2017


PMCS-0102, Revision B Page ii

REVISION SUMMARY: 1. Date: November 2015

Revision: A Changes: Initial release

2. Date: August 2017 Revision: B Changes: Additional information on IT&C organization composition and flow.


PMCS-0102, Revision B Page iii

Table of Contents

Preface ........................................................................................................ 11. OVERVIEW OF PRODUCT SCOPE AND QUALITY ............................................ 22. LEVEL 0 - SCIENCE (CUSTOMER) LEVEL ........................................................ 32.1 SCIENCE REQUIREMENTS ......................................................................................... 32.2 SCIENCE VERIFICATION ............................................................................................ 33. LEVEL 1 - SYSTEMS ENGINEERING AND SYSTEMS IT&C ............................. 53.1 SYSTEMS ENGINEERING ........................................................................................... 53.1.1 Scope Description & Decomposition ............................................................................ 53.1.2 Supporting Analyses ...................................................................................................... 63.1.3 Environmental Safety and Health .................................................................................. 73.1.4 Engineering Standards and Common Practices ......................................................... 73.1.5 Configuration Management and Change Control ........................................................ 73.2 SYSTEMS INTEGRATION, TEST, AND COMMISSIONING ................................................. 83.2.1 Assembly and Testing .................................................................................................... 83.2.2 Environmental Safety and Health .................................................................................. 84. LEVEL 2 - SUBSYSTEM ENGINEERING AND SUBSYSTEM ACCEPTANCE

TESTING ............................................................................................................. 104.1 SUBSYSTEM ENGINEERING ..................................................................................... 104.2 SUBSYSTEM ACCEPTANCE TESTING ........................................................................ 115. LEVEL 3 - COMPONENT DESIGN & DETAILING, AND COMPONENT

QUALITY CONTROL .......................................................................................... 125.1 COMPONENT DESIGN AND DETAILING ...................................................................... 125.2 COMPONENT QUALITY CONTROL ............................................................................ 126. LEVEL 4 -PROCUREMENT & CONSTRUCTION AND PIECE PART QUALITY

CONTROL ........................................................................................................... 147. PROJECT SCOPE ............................................................................................... 157.1 PROJECT MANAGEMENT (WBS 1.2.1) .................................................................... 157.2 SYSTEMS ENGINEERING (WBS 1.2.2) ..................................................................... 177.3 INTEGRATION, TEST, AND COMMISSIONING (WBS 1.2.4) .......................................... 177.4 SCIENCE SUPPORT (WBS 1.2.5) ............................................................................ 187.5 OPERATIONS PHASE PREPARATION (WBS 1.2.6) .................................................... 187.6 EDUCATION & PUBLIC OUTREACH (WBS 1.2.7) ...................................................... 197.7 SUPPORT SERVICES (WBS 1.2.8) .......................................................................... 19


PMCS-0102, Revision B Page 1 of 19

Preface This document is an overview of DKIST Systems Engineering processes. It has been cast in the context of the so-call V-Diagram, a common visualization tool used within the Systems Engineering discipline. As such, it covers the topics of scope management, requirements development and management, and quality management.

There are two elements to the development of work scope. Each has a fundamentally different methodology for quality management.

The first scope element, and the subject of the early sections of this document, is generally referred to as “Product Scope.” This is the work product (in this case the DKIST observatory facility) that will be delivered to the customer at the end of the project. This element of scope is subject to requirements definition, and quality management and verification methods described herein this document.

The second element, which is described in Section 7, is “Project Scope.” It consists of all supporting project work required to facilitate and ensure delivery of the product to the customer. This scope includes things like project management and systems engineering which are more level-of-effort activities in contrast to Product Scope.



Figure 1.1. The V-Diagram

1. OVERVIEW OF PRODUCT SCOPE AND QUALITY

The V-Diagram (Figure 1.1) is a common way to visualize the process for defining Product Scope, developing requirements, and eventually verifying compliance at each step from fabrication through integration, test, commissioning, and final verification and delivery of the product.

Figure 1.1 shows the five levels within the V-Diagram, numbered L0 through L4. Work begins at the top left-hand side of the V in L0, proceeds downward to the bottom, where fabrication and procurement occurs, then begins the upward journey on the right branch. At each successive branch level on the right, the results are tested against the corresponding requirements established on the left branch.

The descriptions in the following sections will not proceed strictly temporally, but instead level by level on both sides of the V. This allows us to discuss quality verification methods in the context of scope development as the level of detail increases level by level. In the subsequent sections we identify the specific DKIST documents (or classes of documents) that are created in the process.



Figure 2.1. Level 0 V-Diagram elements

2. LEVEL 0 - SCIENCE (CUSTOMER) LEVEL

The two elements of Level 0 are shown in figure 2.1. The left box is about developing and documenting the “product” (telescope observatory and facilities) that the project is charged with delivering. On the right is the process we follow to verify that the Level 0 requirements have been met.

2.1 SCIENCE REQUIREMENTS For DKIST our “customer” is the solar-physics community that will ultimately use the DKIST facility. A subset of this community, some internal to the National Solar Observatory, some from the community at large, developed the science requirements. These persons were recruited to the effort because of their specific expertise in science goals that should be achievable with a 4-meter class solar telescope, operational experience at existing solar facilities, or instrument development capabilities. The result of this effort was a suite of 12 specific documents written by these collective scientific customers:

Top-level science and operational requirements:

1. SPEC-0001, the DKSIT Science Requirements Document. 2. SPEC-0036, the DKIST Operational Concepts Definition Document

Instrument science and operational requirements:

3. SPEC-0054 Visible Broadband Imager (VBI) Instrument Science Requirements Document (ISRD)

4. SPEC-0106 VBI Operational Concepts Definition 5. SPEC-0055 Visible Spectro-Polarimeter (ViSP) ISRD 6. 5263-RQ-9301 ViSP Operational Concepts Definition (HAO document) 7. SPEC-0056 Cryogenic Near-IR Spectro-Polarimeter (Cryo-NIRSP) ISRD 8. CN-0001-B Operational Concepts Document (IfA document) 9. SPEC-0057 Visible Tunable Filter (FTF) ISRD 10. (VTF OCD under development by Kiepenheuer-Institut für Sonnenphysik in Freiburg, Germany) 11. SPEC-0067 Diffraction Limited Near-IR Spectro-Polarimeter 12. DLNIRSP-DOC-000-OCD_RR (IfA Document)

2.2 SCIENCE VERIFICATION When the project ultimately reaches this point back on the right branch of Level 0, the telescope systems, including first-light instruments, have already been integrated and tested running under high-level software control (i.e., during the Level 1 Systems Engineering work). At this point the observatory will be capable of feeding sunlight to all five first-light instruments, each of which has been individually verified as being functional under observatory control. What remains at this point is to obtain science-quality data and verify that all Level 0 SRD and ISRD requirements are being met, and that the operational concepts specified are realized.



Science verification is conducted by a combination of scientist customers of each instrument’s data, working in conjunction with the DKIST Systems Engineering, Integration, test and Commissioning (SEIC) team acting as facilitators. Science verification plans will have been developed by the instrument science teams and approved by DKIST project scientists before this final verification stage begins. The DKIST project formally assigned this task to each instrument builder within the construction-phase statement of work for each instrument; an approved Science Verification Plan is a construction-phase deliverable.

Ultimately a compliance matrix will list all of the verification steps to be performed as part of science verification. Sign-off will be the responsibility of the science teams assigned to each instrument and combination of instruments. All items on the compliance matrix must be confirmed compliant, or formally waived by the DKIST project.




Figure 2.2. A model rendering that gives an overview of the DKIST scope. The cut-away view of the upper and

lower enclosures shows the telescope (in the upper enclosure) and the coudé lab at the bottom in the lower enclosure. To the left is the Support and Operations Building. At the extreme left is just a bit of the Utility Building, which is also part of the DKIST scope. All of this scope is formally documented in the DKIST Work Breakdown Structure.

3. LEVEL 1 - SYSTEMS ENGINEERING AND SYSTEMS IT&C

Figure 3.1 shows the scope definition steps on the left of the V-Diagram that are the responsibility of DKIST Systems Engineering versus the corresponding quality control step on the right.

3.1 SYSTEMS ENGINEERING

3.1.1 Scope Description & Decomposition

This step involves first understanding the scope of the project as defined in the Design and Development Phase Proposal to the NSF and refined a few years later in the Construction Phase Proposal to the NSF. While the scope did not change between the two proposals, our understanding of the design improved, and language and nomenclature evolved. The top-level scope of the DKIST construction appears in Figure 2.2.



Next, once the scope is defined, it is decomposed and documented into a work breakdown structure (WBS) containing manageable work packages, the scope of each being clearly defined by WBS Descriptions. This work-breakdown step was initially accomplished within the Construction Phase Proposal, but continued to be refined as the project developed designs and contracting strategies in light of ever-improving understanding of these designs and trade studies. Another step at this stage required that we identify interfacing needs and specifications between pairs of WBS elements. This step allows work-package managers to develop Interface Control Documents (ICDs), which is performed as part of Level 2 engineering efforts.

Decomposition:

• PMCS-0005 DKIST WBS specifies the DKIST work breakdown structure and includes both Product Scope and Project Scope. The information is presented in graphical form.

• PMCS-0006 WBS Descriptions - Gives general descriptions of each WBS elements, including both Product Scope and Project Scope.

The information contained in both of these documents is merged into a Work Authorization Document (WAD) maintained by Project Controls (an element of Project Management), which further subdivided the hierarchical work breakdown structure.

Error budgeting represents the decomposition high level science performance into constituent budgets that each subsystem must adhere to.

• SPEC-0009 DKIST Systems Error Budgets - This is both a document that describes the methodology and the error trees adopted, and also a suite of spreadsheets that develop three families of error budgets for different science use cases, and wavelengths.

o Example: DIQ_Case1_VBI-B-working.xlsx - This is the spreadsheet that shows the working Visible Broadband Imager instrument-specific error budget for use at Blue wavelengths.

• TN-0148 Error Budget Log - This document offers explanations for the current error budget values in the error trees and tracks the evolution of the values from initial top-down values, through analysis, components as specified, and finally as-built values.

Interface Control:

• SPEC-0138 DKIST Construction and Commissioning Interface Control Chart (N2 Diagram)

3.1.2 Supporting Analyses

A few analysis results are listed here as examples. This is by no means an exhaustive list.

Trade study examples:

• RPT-0013 ATST Enclosure Trade Study: Final Report

• TN-0028 M1 Thermal Tradeoffs

Telescope Optical Design Study examples:

• SPEC-0029 DKIST Optical Prescription (In addition to analysis, this is also a configuration-controlled document that establishes the DKIST optical design.)

• Stray and Scattered Light Analysis (Photon Engineering Contract Report).

• TN-0013 M1 Microroughness and Dust Contamination.



• TN-0121 Tolerance and Sensitivity Analysis of the ATST: Mirror Fabrication Errors and Placement Tolerances.

Other Studies and Analysis examples:

• Fluent Final CFD Report (prepared under contract for DKIST by Fluent, Inc., now ANSYS).

• TN-0031 ATST Support & Operations Building Optimal Orientation.

3.1.3 Environmental Safety and Health

Environmental Safety and Health is a Level 1 component, though it is now within the purview of the DKIST Safety Manager.

• SPEC-0060 System Safety Plan - This is a summary document that gives a top-level description of the “DKIST Safety Suite” which is made up of the following documents:

o SPEC-0086 DKIST Safety, Health, and Environmental Program Plan

o SPEC-0061 DKIST Hazard Analysis Plan - Our hazard analysis methodology is based on MIL-STD 882-D. It defines the term ‘Hazard’ to include personnel injury, damage to equipment and damage to the environment.

o SPEC-0031 DKIST Safety and Health Specification for Contractors

o SPEC-0035 DKIST Hazardous Material and Hazardous Waste Management Program

o SPEC-0030 Conditions for Working at the DKIST Project Site

o TN-0046 Assessment of Life-Safety and Other Code Requirements for the DKIST Facility

3.1.4 Engineering Standards and Common Practices

Examples:

• International Building Code;

• AISC American Institute of Steel Construction AISC Manual of Steel Construction, 9th ed. AISC Specification for the Design, Fabrication, And Erection of Structural Steel for Buildings

• AWS American Welding Society AWS D1.1-92 “Structural Welding Code – Steel”

• ASTM American Society for Testing and Materials

• ANSI American National Standards Institute

• SSPC Steel Structures Painting Council, Good Painting Practice, Steel Structure Painting Manual Vol.1 Systems and Specifications, Steel Structures Painting Manual Vol. 2

• HIOSHA Title 12 Standards for General Industry and Construction

• SPEC-0005-Software and Controls Requirements

• (Other CEP are distributed and documented within subsystem specifications)

3.1.5 Configuration Management and Change Control

• PMCS-0103 Project Management Control System

• SPEC-0002 Documentation and Drawing Control Plan.



3.2 SYSTEMS INTEGRATION, TEST, AND COMMISSIONING Systems integration, test, and commissioning (IT&C) is the responsibility of DKIST Systems Engineering, Integration and Commissioning (SEIC) group. This is the right branch of Level 1 on the V-Diagram where compliance with systems level requirements is confirmed.

3.2.1 Assembly and Testing

Prior to the onset of IT&C factory or lab acceptance, tests of all subsystems have been performed and passed (in conformance to compliance matrices) or waivers granted prior to arrival of the subsystems at the observatory facility. These same tests will be performed again as part of site acceptance tests, but this time in the context of DKIST infrastructure (foundations, local power and utilities). Standards for factory, lab, and site acceptance test were established early by Systems Engineering, and documented in:

• PMCS-0024 DKIST Acceptance Test Standards.

The IT&C phase officially begins with the project’s acceptance of the Telescope Mount Assembly. This, however, only marks the time when ownership of integration passes to the SEIC team. SEIC has already been heavily involved in the sight acceptance of the enclosure, TMA, and other components delivered during the construction phase at Level 2 on the right branch of the V-Diagram. Consequently a significant fraction of the SEIC group will have already relocated to Maui well in advance of this ownership milestone.

IT&C planning preceded the onset of the IT&C phase of the project by many years. The scheduling during IT&C was accomplished with the usual project scheduling tools (Primavera in our case), becoming part of the Integrated Project Schedule (IPS) at an early date. SEIC added increasing levels of detail to the IPS as plans progressed. The SEIC group also identified work packages to build or procure specialized tooling and equipment for use during IT&C. At the highest level of detail the SEIC group prepared detailed procedures for each identified IT&C task.

Example: IT&C Task-0600-M1 Coating (Draft Work in Progress)

3.2.2 Environmental Safety and Health

Major subsystem vendors and the project’s internal hazard analysis team (HAT) performed hazard analyses during earlier phases of the DKIST project. Vendors did this looking exclusively at hazards associated with their specific subsystems that they had designed and built. Once identified it was their responsibility to mitigate the hazardous condition to the extent possible. The DKIST project reviewed the preliminary hazard analysis at PDR and the final version at FDR. The DKIST safety officer attended the factory acceptance tests to confirm that the proposed mitigations had been implemented.

DKIST management (project director, project manager, lead systems engineer, and the DKIST safety officer) then formally recognized the residual risks after mitigation and signed off that they are willing to accept the remaining risk levels. In extreme cases where the residual risk remained in the high category after mitigation, the director of the National Solar Observatory was also asked to sign off.

The analysis of systems-level hazards fell to the HAT. Many of these were hazards associated with procedures anticipated during the IT&C phase. Internally identified hazards were treated the same as subsystem hazards in terms of formal recognition of residual hazards after mitigation.

Many hazards that involved risk to personnel safety were mitigated using safety interlocks. These were generally implemented within the subsystems using Local Interlock Controllers (LICs) using project-specified components for compatibility observatory wide. But some subset of subsystem hazards also requires a more global response from other subsystems. For example, if the cooling fails at the prime-focus heat stop, the M1 mirror cover and the enclosure entrance aperture must respond by closing. Hazards in this class are mitigated through the Global Interlock System (GIS).



One important task during IT&C is putting the GIS into service. Until that system is installed and tested there may be a temporarily high residual risk to personnel safety. This will be handled using Job Hazard Analyses.

Example: DKIST_JHA_016_EnclShutterStartup_RevA which describes the basic steps and establishes correct and safe procedures for moving the enclosure shutter during the earliest phases of site installation of the upper enclosure.




4. LEVEL 2 - SUBSYSTEM ENGINEERING AND SUBSYSTEM ACCEPTANCE TESTING

At Level 2 the Subsystem Engineers are responsible for delivering subsystem designs on the left branch of the V-Diagram, and on the right, testing the designs and interfaces when manufacturing is complete.

4.1 SUBSYSTEM ENGINEERING The DKIST project has utilized several different strategies for obtaining subsystem designs, but the primary difference is simply who does the work. For example, some of our high-level software is designed and manufactured (coded) entirely by project personnel, as is one first-light instrument and other subsystems. Alternately, many of our other major subsystems are designed and built to our requirements by contractors. In the case of some of our first-light instruments partner institutions are actually contracted to write their own design requirements subject to the constraints spelled out in the Level 0 ISRD for that instrument.

No matter who does the work, this subsystem engineering level accomplishes the following key things:

1. Design Requirements. These must be uniquely numbered, verifiable, and traceable (flowing down from higher level sources). DKIST Systems Engineering specifies guidelines for writing requirements in PMCS-0023 Requirement Definition.

• Example: SPEC-0011 Telescope Mount Assembly Specifications Document

2. Reference Designs, Studies, and Analyses (RDSAs). In many cases, even when the intent was to contract out the designing of subsystems, DKIST Engineers developed RDSA. This was done because the DKIST project was divided into two distinct phases: design and construction. During the design phase we were asked to demonstrate that there was at least one engineering solution that met the design requirements, and did so within the budget envelope. The RDSA was then typically supplied to potential vendors as supporting documentation with the understanding that they were to do their own design that would meet our specifications.

• Example: TN-0044 Reference Design Studies and Analyses (RDSA) Document for the Telescope Mount Assembly (TMA)

3. Interface Requirements. Systems engineering identified the necessary interface documents between

pairs of subsystems at Level 0. At Level 2, the subsystems engineers must draft the actual Interface Control Documents (ICDs) and negotiate the details with their counterparts in the other relevant subsystems. • Example: ICD 1.1 / 1.2 Telescope Mount Assembly to M1 Assembly (K. Gonzales / P. Jeffers)

4. Request for Proposal (RFP). For subsystems that will be designed by vendors, Level 1 tasks also includes assembling a bid package in the form of an RFP and a set of supporting documents.

• Announcement of Opportunity;



• Instructions to Offerers; • Statement of Work; • Design Requirements Document; and • Other required legal documents assembled by our contracts officer (e.g., elements of the NSF-

AURA Cooperative Agreement).

4.2 SUBSYSTEM ACCEPTANCE TESTING On the corresponding right branch of Level 2 we (the DKIST project) ensure compliance of the subsystem against the design requirements, item by item. We call this a Factory Acceptance Test (FAT) in most cases; for instruments developed by partner institutions we call this a Lab Acceptance Test (LAT).

DKIST Systems Engineering has provided standards for conducting FATs and LATs (PMCS-0024 DKIST Acceptance Test Standards). These standards apply to acceptance testing of DKIST elements provided by commercial vendors, instrument partners, and components produced within the DKIST project. It applies to both hardware and software elements. Final stage acceptance testing of subsystems as described frequently establishes a milestone to define transition of equipment into the process of integration, testing and commissioning stage of the project.

The burden of creating a FAT plan typically falls to the manufacturer of the subsystem, subject to review and approval by DKIST. The tests are based on the verification method specified in the design requirements. As noted earlier, the tasks are always the same, but the actors who perform the tasks may vary. Following the TMA example highlight so far, the commercial vendor develops the test plan, and it is reviewed and approved by the Contract Officer’s Technical Representative (COTR), generally the same engineer who led the activities on the corresponding left branch of Level 2. This lead engineer is generally assisted by DKIST Systems Engineering and other project personnel as required.

• Example: ATST-PLA-50002-01-01 1.1-0010 TMA to M1 Assembly IF (authored by Ingersoll Machine Tools, reviewed by P. Jeffers, COTR, and selected project personnel).

For subsystems manufactured internal to the DKIST project (e.g., our VBI or our high level software), the details change due to potential conflicts of interest. In cases like these, Systems Engineering assumes the primary role of reviewing and approving test plans. PMCS-0024, referenced above, also establishes these shifting responsibilities for the various design and construction strategies that the project has adopted.

Another responsibility of the manufacturer is the generation of a compliance matrix, again to be reviewed and approved by the project. It calls out each requirement (including those documented in ICDs) and references a test procedure. Project representatives (the specific individuals depending on the internal versus external manufacturing) note pass or fail. If some tests cannot be completed successful even after modifications or adjustments then the manufacturer may apply for a waiver, subject to approval by the DKIST Configuration Control Board (CCB). When all tests are passed or waivers granted by the CCB, Systems Engineering can close out the FAT.




5. LEVEL 3 - COMPONENT DESIGN & DETAILING, AND COMPONENT QUALITY CONTROL

At Level 3 the detailed design of a subsystem and its components begins on the left branch. Depending on the design and fabrication strategy, this may be an activity internal to the DKIST project or it might be performed by a contractor (or subcontractor). On the corresponding right branch the quality of the manufactured components is tested against that design.

5.1 COMPONENT DESIGN AND DETAILING The Level 3 effort on the left branch involves the designer’s further decomposition of the subsystem, leading to component and subcomponent drawings and specifications. The engineering and drafting team designs and details the components. Depending on the construction strategy, the design engineers may develop requests for quotations (RFQs) during this phase in preparation for identifying subcontractors or vendors to perform some of the work or find sources to procure some of the parts.

For software components of the subsystem the corresponding work of the design team’s software engineers involves developing specifications for application programming interfaces (APIs) and Human Machine Interfaces (HMIs) during this phase. Software developers generally perform tests and simulations at this stage to show that the software methods and that the selected computing hardware will be able to meet the software performance requirements.

The DKIST project reviews a preliminary design at a formal Preliminary Design Review (PDR). At the end of the project conducts a Final Design Review (FDR) which must be closed out by DKIST systems engineering prior to proceeding with construction. (Exceptions to this strict rule are sometimes made in the case of low-risk, long lead-time items with the permission of the DKIST project.) The standards for conduction these reviews and the design teams design review deliverables is established in PMCS-0022, DKIST Design Review Standards.

Returning to the Telescope Mount Assembly example, the contractor who submitted the successful proposal was MT Mechatronics GmbH in Mainz, Germany, and a contract was put in place. They began the design effort at this stage, and their work was subjected to first a Preliminary Design Review (PDR) and then a Final Design Review (FDR) conducted by the DKIST project. Under review at those times was compliance with the design requirements, established by the analyses performed by the design team at MT Mechatronics. Reviewers also careful analyzed specifications of the off-the-shelf components selected such as the Heidenhain encoders that would be critical to meeting the performance requirements.

5.2 COMPONENT QUALITY CONTROL On the corresponding right-hand side of the V-Diagram at Level 3 the subsystem components that have been manufactured or procured are assembled and tested against drawings and specifications. For large or even moderate sized manufacturing contractors there is generally an independent quality control (QC) branch of the organization that can perform this function. For small contractors without an independent CQ branch, this function is performed by DKIST project personnel or is subcontracted out by the project to independent 3rd party inspectors.



The DKIST TMA is an interesting example because MT Mechatronics subcontracted the manufacturing of this subsystem to Ingersoll Machine Tool in Rockford, Illinois. Ingersoll is also a large firm and has its own QC department operating independently of their manufacturing managers. But in this case the designers from MT Mechatronics were also able to supplement the internal QC activities at Ingersoll, along with the DKIST project’s COTR and others DKIST personnel.




6. LEVEL 4 -PROCUREMENT & CONSTRUCTION AND PIECE PART QUALITY CONTROL

At the very bottom of the V-Diagram the left branch is where the fabricators produce shop drawings and detailed instructions for fabrication. On the right branch, quality control consists of first vetting those shop drawings and instructions, then once fabrication begins, QC turns into the careful inspection of each manufactured part against those shop drawings and instructions. Form, fit, and geometrical tolerances are typically verified at this step, as are things like material quality (documented in material certifications), weld samples and tests, and the like for large mechanical structures.

For the DKIST Telescope Mount Assembly the independent QC department at Ingersoll Machine tools performed this function. They were also supplemented as before by members of the MT Mechatronics design team and DKIST personnel. The DKIST involvement at the QC level is performed as part of Manufacturing Inspection Points (MIPs) defined in the Statement of Work in the following way:

3.10. MANUFACTURING INSPECTION POINTS

The purpose of the Manufacturing Inspection Points (MIP) is to review the main TMA components after manufacturing but prior to start of assembly such that any corrective action necessary can be initiated with minimized required re-work. Inspection and metrology reports and relevant quality assurance information shall be made available to AURA during the MIPs, and shall be of sufficient detail and substance for AURA to verify the form, fit, and function of the components and subsystems of the TMA as they are procured and fabricated. In particular, metrology reports that include data confirming the compliance of the mechanical ICD’s shall be included within all MIPs.

• Example: head ring N00085-9-10-001 prepared by Ingersoll Machine Tools and reviewed by the DKIST (AURA) COTR.



7. PROJECT SCOPE

Project Scope, unlike Product Scope, consists primarily of level of effort activities, or in some cases just items at the control account level. There are seven of these, listed below with their WBS descriptions taken from PMCS-0006.

7.1 PROJECT MANAGEMENT (WBS 1.2.1) The Project Management WBS element is comprised of the following major areas: WBS, schedule, budget, project infrastructure, administrative support, staffing, planning, tracking and reporting.

7.1.1 Project Management Control System (PMCS)

The design, development and implementation of the Project Management Control System will be used as a management tool for the project and external EVMS reporting. This includes outsourced services of Sr. PMCS Consultant. The PMCS personnel support was estimated using direct experience from other projects and comparison to other MREFC scale projects such as ALMA, IceCube, LIGO, etc. 1.1.1.1 EnvironmentalHealthandSafety(EH&S)

The Environmental Health and Safety WBS component includes a fulltime Safety Officer through the run out of the project. The Environmental Health and Safety WBS component also includes safety materials and supplies, such as hard hats, vest, first aid equipment, back boards, lanyards, etc. as well as an allowance for hiring off-duty paramedics to be on-site during identified critical construction periods. Safety Equipment: hard hats, auxiliary safety gear: loves, vests, etc., boots, safety harnesses, lanyards, self-retracting harness equipment, connection devices, safety related training, first aid equipment/support, safety equipment kits, restock lock out tag out kits, spill prevention kits, hearing protection, rescue and retrieval system, respiratory protection, fit testing, medical evaluations, allowance for off-duty paramedics. 1.1.1.2 QualityAssurance/QualityControl(QA/QC)

The Quality Assurance/Quality Control WBS component includes an allowance for QA/QC consultants from construction start through on-site construction. The project intends to contract for QC from vendors (e.g., TMA and Enclosure) and provide QA through a combination of the project’s Systems Engineering team (lead QA), COTRs, and independent QA/QC consultants as required. The Quality Assurance/ Quality Control WBS component also includes a travel allowance for the QA/QC consultants and an allowance for independent testing – the combined total is the estimate for the QA/QC consultants contract(s). The consultants will not be part of the project team directly, but act in an independent capacity to advise the project regarding QA/QC best practices and make recommendations and conduct tests as appropriate through the vendor shop and on-site construction effort. 1.1.1.3 Travel

The travel budgets for project staff, the Science Working Group, various reviews and committees, recruitment of new hires, and costs associated with the rental house in Maui. 1.1.1.4 ComputersandSupplies

The budgets for computers and supplies.



1.1.1.5 Relocation

The budgets for the relocation expenses associated with DKIST team members that are relocating to Hawaii. This budget also includes re-location of new hires to any of the project office locations. 1.1.1.6 GeneralConstructionEquipment

The General Construction Equipment WBS component includes vehicles (vans, trucks), and their associated fuel, maintenance, and registration costs. The General Construction Equipment also includes an allowance for supplemental/additional crane leases during construction, scissor lift lease, off-road fork lift lease, indoor electric/propane forklift, facility tools, office equipment, and materiel and supplies to support the construction effort on-site. The General Construction Equipment WBS component also includes an allowance for temporary housing for the team and securing warehouse space. 1.1.1.7 SpecialEvents

Special events such as Dedications, Groundbreakings or special reviews. 1.1.1.8 NationalParkServiceSpecialUsePermit(SUP)

This work package is to fund the biological mitigations and monitoring required by the National Park Service for issuance of a Special Use Permit to use the historic road in Haleakala National Park. 1.1.1.9 LegalFees

Contract for AURA's attorney fees in Hawaii to support CDUA process, project labor agreements, excise tax exemptions and other items as required. Legal fees associated with the University of Hawaii's (IFA) application for a Conservation District Use Permit (CDUP) for the project. As per sub award number C22024S and DKIST Cooperative Agreement, the DKIST project is committed to reimbursing all of University of Hawaii's expenses relating to the CDUP process. 1.1.1.10 ProjectPermittingandEnvironmentalCompliance

Consultant services to support environmental compliance and permitting. 1.1.1.11 HabitatConservationPlan

The Habitat Conservation Plan (HCP) is devised to address anticipated impacts to state and federal threatened, endangered, and listed species from the construction of the DKIST at HO on Maui, Hawaii. The purpose of the HCP is to offset any takes on the endangered species (petrels) and is a condition of the issuance of the CDUP. Several mitigations including a conservation fence to restrict movement of the feral goats in the area, predator control and biological monitoring will be funded through the HCP which has been committed to by the National Science Foundation, approved by the Endangered Species Recovery Committee and will be presented to the Board of Land and Natural Resources for approval at their February 25, 2011 meeting. HCP will be in place for approximately 6 years. 1.1.1.12 ProgrammaticAgreement

The funding for the Cultural Specialist will help ensure protection of existing historic properties and their traditional cultural values at the DKIST Project Site during construction of DKIST on Haleakala, Maui, Hawai’i.



1.1.1.13 RemoteOperations-OfficeSpace

This is for office space on Maui for remote facilities. There is a Building line item that will either be used to continue a lease or for payment on a Building that AURA or UH would build. Lease of the remote operations office space off the mountain, currently in Pukalani. Wages to complete a design requirements document for the Remote Operations Building to be built to support off-site operations in Maui.

7.2 SYSTEMS ENGINEERING (WBS 1.2.2) The Systems WBS element encompasses the following systems engineering activities: design requirements flow-down, error budgets, interface control, standards, design requirements documents, performance predictions, acceptance test plans, integration plans, and documentation control. The Systems Engineering WBS component includes a fulltime Systems Engineer, Optical-Systems Engineer (also lead IT&C engineer), and Documentation Coordinator through the run out of the project. The travel, computers, materials and supplies, and relocation required to support the Systems Engineering team are held in the Project Management WBS component. The Systems Engineering WBS component includes the following: Payroll and Benefits, Systems Engineer, Optical Systems Engineer (also lead IT&C engineer), and Documentation Coordinator.

7.3 INTEGRATION, TEST, AND COMMISSIONING (WBS 1.2.4) 1.2.4 The Integration, Test & Commissioning WBS element encompasses several, overlapping phases: • Sub-system Acceptance: assembly and testing of the various telescope components after fabrication. • Assembly, Integration and Verification (AIV): incremental acceptance testing of integrated

components; within AIV, there are several components: o Strategic: Off-summit planning team who focuses on the continuous elaboration of the activity

planning and procedures development; the Tactical team reviews and participates in both plan and procedure development.

o Tactical: On-summit team who focus on the day-to-day execution/implementation of the AIV plan; they adapt the plan to conditions on site (weather, resourcing, etc) and feedback that information to the Strategic team for incorporation into the updating planning.

o Quality: On-summit team leader who focuses on incremental verification and acceptance of AIV activities.

• Commissioning and Science Verification (CSV): testing and verification of the high-level science, operational and instrument requirements along with the individual instrument science verification plans.



7.4 SCIENCE SUPPORT (WBS 1.2.5) The Science Support WBS element encompasses the activities of the DKIST Science Working Group (SWG) and its interactions with the Project Scientist. These activities include SWG meetings and workshops.

7.5 OPERATIONS PHASE PREPARATION (WBS 1.2.6) Support is provided throughout IT&C in preparation for the handoff to the operations phase. It includes, for example, manuals, maintenance procedures, and training of operations staff as construction ramps down and operations ramps up.



7.6 EDUCATION & PUBLIC OUTREACH (WBS 1.2.7) A public outreach employee was paid out of this WBS element during the project’s design phase, but that was discontinued at the start of construction. No public outreach is planned until the operations phase.

7.7 SUPPORT SERVICES (WBS 1.2.8) The Support Services WBS element is comprised of overhead areas such as purchased support services from NOAO (e.g., accounting, purchasing, and facilities maintenance) as well as the AURA management fee. Business Services Fees are paid to AURA/NOAO for all business services in support of the project. These include accounting, payroll, human resources, and procurement. A Facilities Use Fee is paid to AURA/NOAO to support employees housed in Tucson for all expenses related to office space including space, maintenance, network, phone, etc. The AURA Fee is the financial and administrative rates charge by the AURA Corporate Office for providing fiscal and management oversight.