Document and Drawing Control Plan - DKIST · July 2012 Reviewed By: R ... o All 3d parts and...

Project Documentation Document SPEC-0002

Revision H

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

Document and Drawing Control Plan

Ruth Kneale Systems Engineering Group

July 2012

Reviewed By: R. Hubbard

25-Sep-2012

Systems Engineer

Date

Approved for release: S. Craig

25-Sep-2012

Sr. Systems Engineer

Date


SPEC-0002 Rev H Page ii

REVISION SUMMARY:

1. Date: 29 October 2002

Revision: A

Changes: Initial release

2. Date: 30 July 2003

Revision: B

Changes: Addition of Physical System Interface descriptions and expansion of sections of

the drawing appendix; tightening of assembly document requirements.

3. Date: 11 May 2004

Revision: C

Changes: Revised sections to match construction WBS/N2 chart changes. Includes changes

to subsystem breakdowns, ICD numbering, and drawing numbering schemes.

4. Date: 1 October 2004

Revision: D

Changes: Major revisions and additions to each section.

5. Date: 1 March 2005

Revision: D.1

Changes: Revisions to include more information on the Systems Database, ICD packages,

and ICD naming conventions, and updates to the Drawing and Subsystem lists.

6. Date: 1 March 2006

Revision: E

Changes: Include new information on bibliographic format information; Reference vs.

Related Documents; and updates to almost all other sections.

7. Date: 13 April 2006

Revision: E.1

Changes: Added information about internal revision numbering and process for revising

released documents and drawings.

8. Date: 18 September 2006

Revision: F

Changes: Updated all sections; now includes statement of purpose, expanded entries for

review & approval process, and clarifications for file naming and locations.

9. Date: 24 April 2009

Revision: G

Changes: Updated all sections to reflect changeover from Enterprise PDMWorks to

PDMWorks, general updating otherwise.

10. Date: June 2012

Revision: H

Changes: Major updates to all sections; added new CCB review and voting procedure;

added section on contracts documentation management. Moved ePDM section to

before revision section. Expanded document type definitions, and added a new

document type.


SPEC-0002 Rev H Page iii

Table of Contents

PREFACE ....................................................................................................................... 1 1. STANDARDS ........................................................................................................ 2 1.1 ELECTRONIC DOCUMENTATION LOCATIONS ............................................................... 2

1.2 PAPER DOCUMENTATION LOCATIONS ....................................................................... 2 1.3 SYSTEMS DATABASE ............................................................................................... 3 2. DOCUMENTS ....................................................................................................... 5 2.1 NUMBERING ............................................................................................................ 5 2.2 TYPES .................................................................................................................... 5 2.2.1 Related and Reference Documents ................................................................................ 7 2.3 CONTROLLED DOCUMENTS ...................................................................................... 7 2.4 TRACKING .............................................................................................................. 7

2.5 COMPLETION AND DISTRIBUTION .............................................................................. 7 2.6 FORMATTING .......................................................................................................... 8 2.6.1 Bibliographic Formats ..................................................................................................... 8 2.7 REVISING A RELEASED DOCUMENT ........................................................................... 8 2.8 RELEASED DOCUMENTS ARCHIVE ............................................................................ 9 3. DRAWINGS ......................................................................................................... 10

3.1 NUMBERING AND LOCATIONS ................................................................................. 10 3.2 REVIEWING AND RELEASING .................................................................................. 10

3.3 DRAWING FORMATS .............................................................................................. 10 3.4 INTERFACE CONTROL DRAWINGS ........................................................................... 10 3.5 REVISING A RELEASED DRAWING ........................................................................... 10

4. INTERFACE CONTROL ...................................................................................... 11 4.1 INTERFACE CONTROL DOCUMENTS ........................................................................ 11 4.1.1 Numbering .....................................................................................................................11 4.1.2 Naming Convention .......................................................................................................11 4.1.3 Physical System Description .........................................................................................11 4.1.4 Software Description .....................................................................................................12 4.2 INTERFACE CONTROL DRAWINGS ........................................................................... 12 4.3.1 Naming Conventions .....................................................................................................12 4.3 INTERFACE DOCUMENT OR DRAWING APPROVAL ..................................................... 12 5. ENTERPRISE PDMWORKS ............................................................................... 13 5.1 REVIEW AND RELEASE PROCEDURES ..................................................................... 14 5.2 WORKFLOW .......................................................................................................... 14

5.3 CHANGING STATE VIA TRANSITIONS ........................................................................ 16 5.4 REQUESTING REVISIONS TO A FILE ......................................................................... 16 6. CHANGE CONTROL........................................................................................... 17

6.1 CHANGE CONTROL BOARD .................................................................................... 17 6.2 APPROVED DOCUMENTS ........................................................................................ 17 6.3 CONTROLLED DOCUMENTS .................................................................................... 17 6.4 CHANGE REQUESTS .............................................................................................. 17 6.4.1 How to Use a Change Request .....................................................................................17 6.4.2 Extra Useful Information ................................................................................................18 6.5 REQUESTS FOR WAIVER ........................................................................................ 19 6.5.1 How to Use an RFW: .....................................................................................................19


SPEC-0002 Rev H Page iv

6.6 CCB ACTIONS ON CRS AND RFWS ........................................................................ 19 6.6.1 CR Tracking and Status Reports ...................................................................................20 6.6.2 RFW Tracking and Status Reports ................................................................................20 7. ICD/N2 DIAGRAM ................................................................................................ 21 APPENDIX A: DOCUMENT TYPE LISTING ................................................................. 22

APPENDIX B: DRAWING NUMBER BREAKDOWNS ................................................. 23 APPENDIX C: N2 SUBSYSTEMS ................................................................................ 24 APPENDIX D: PROPRIETARY INFORMATION .......................................................... 29 APPENDIX E: CHANGE REQUEST FORM .................................................................. 32 APPENDIX F: REQUEST FOR WAIVER FORM .......................................................... 33


SPEC-0002, Rev H Page 1 of 33

PREFACE†

The purpose of this Document and Drawing Control Plan is to identify and maintain documentation for

ATST, and ensure that this documentation remains consistent with the design requirements of the project.

This is done by:

Identifying types of and specific documentation;

Storing identified documentation;

Controlling, tracking and retrieving documentation;

Review and approval of documentation, changes and revisions;

Distribution.

The following document is the primary management overview for configuration management (CM); this

document is a guideline for how to actually use the CM tools.

PMCS-0018, Revision Control and Configuration Management

† References:

1. NASA Reference Publication 1370, “Training Manual for Elements of Interface Definition and Control”,

January 1997

2. ES&H Volume IV, Part 41, Document 41.2, “Configuration Management Program Description”, UCRL-

AM-133867, November 2004

3. DSMC “Systems Engineering Management Guide”, January 1990



1. STANDARDS

Project information will follow these established application standards:

Word processing documents: either Microsoft Word or Rich Text Format.

o For documentation such as reports, technical notes, etc., the document shall be formatted

as defined in Section 2.6.

Spreadsheets: Microsoft Excel.

Presentations: Microsoft PowerPoint.

Layouts and detailed engineering drawings: o All drawings will conform in general to ANSI Standards 14.24 “Types and Applications

of Engineering Drawings”, 14.35M “Revision of Engineering Drawings and Associated

Documents”, and 14.100 “Engineering Drawing Practices”.

o All 3d parts and assemblies will be created in SolidWorks.

o All 2d drawings created from these 3d parts and assemblies, and schematics and piping

diagrams, will be created and saved in Portable Document Format (PDF).

o All drawings will use metric dimensioning where feasible.

o All drawings will incorporate geometric dimensioning and tolerancing per ASME

Y14.5M-1994, “Dimensioning and Tolerancing”.

o All welding specifications shall be per ANSI/AWS Standard D1.1/D1.1M, “Structural

Welding Code – Steel”.

o All drawings will have a border and title block per the ANSI Standards listed above.

Optical drawings: Zemax.

Software drawings: TBD.

Electronics drawings: Altium Designer.

Graphics: TIFF, PNG or JPEG format.

Preliminary or draft work can use any application, but upon finalization and submission to Systems

Engineering, the work must be changed to one of the standard formats.

1.1 ELECTRONIC DOCUMENTATION LOCATIONS

Electronic files will be managed by the SolidWorks PDMWorks Enterprise (ePDM) electronic document

management system (aka the Vault; see Section 5). Staff will be trained on checking files into and out of

the ePDM vault. File locations will match the Telescope Systems subset of the Work Breakdown

Structure (WBS) structure (see Appendix C).

The Business Manager will keep all business documentation digitally, in the Vault. The Contracts

Manager will keep all signed contracts, and other active contracts documentation will be kept digitally in

the Vault.

1.2 PAPER DOCUMENTATION LOCATIONS

The Systems Librarian will keep archival documentation such as review materials, archived proposals,

reference sets, etc. in a series of filing cabinets. At this time, these archives do not include anything from

the Director’s Office or the Project Scientist’s office, although this may change in the future.

In addition, there is a Proprietary Information cabinet drawer in the archives. Any documentation

removed from this drawer, whether as an original or a copy, must follow the appropriate procedures as set

forth in the Director’s “Protection of Proprietary Information” memo, dated February 12, 2003 (see

Appendix D). The Business Manager is the primary control person, and the Systems Librarian is the

secondary control person.



1.3 SYSTEMS DATABASE

The Systems Librarian maintains a Systems Database in Access. This database is accessible by the staff

from within the vault, and includes status reports for:

Interface Control

Drawings

Documents

Books

Other information tracked by Systems Engineering, such as staff publications, reference papers,

etc.

Status reports can be generated at any time by the staff by selecting the appropriate button. Systems

Engineering maintains a separate data-entry level within the database, for use only by the Systems Group.



2. DOCUMENTS

Documents require a number for tracking, revision control, and database purposes. All ATST documents

will have a number assigned by Systems Engineering; to obtain a number, or for other documentation

questions, contact the Systems Librarian. Documents will be kept in the appropriate EPDM file vault

folder, called “docs”, with subdirectories of “drd”, “sow”, “icd”, etc., as appropriate. When saving the

electronic copy of the file, the number is used as part of the filename, such as SPEC-XXXX_Title.doc,

into the appropriate ePDM vault directory.

2.1 NUMBERING

Document numbering is very straightforward: ATST, followed by the document type, and finishing with

a sequential numbering of the document within the document type. When a new document is started,

staff should contact the Systems Librarian to get a document number; she will select from and enter it into

the Systems Database (see Section 1.4). Please DO NOT assign a number to a document yourself!

Some document numbering examples are:

ATST Technical Note #2 (Project Document TN-0002)

ATST Report #12 (Project Document RPT-0012)

ATST Specification #1 (Project Document SPEC-0001)

2.2 DOCUMENT TYPES

At this time, the current document types in use at ATST are:

Change Requests (CR). A CR is used whenever a proposed change affects the scope, budget,

schedule or configuration of the observatory. See Section 6.4 for more.

Compliance Matrices (CMX). Used to verify that all numbered requirements in a system’s

Configuration Specification are met.

Contractor Reports (CON). These are deliverable outcomes from vendors. An example is CON-0093,

“Ground Penetrating Radar Survey Summary Report of Findings.”

Drawings (DWG). 2D drawings used for contractual and construction purposes. Note this document

type does not include 3D CAD models. See Section 3 for more.

Interface Control Documents (ICD). These detail the specific ways in which two systems interact

with each other, including mechanics, electronics, software, and safety interfaces. See Section 4 for

more.

Memorandums of Understanding (MOU). A document describing a bilateral or multilateral

agreement between parties; a letter of intent. An example is MOU-0002, “PanSTARRS Electrical

Reroute MOU.”

Procedures (PROC). A written document or instruction detailing all relevant steps and activities of a

process or procedure. An example is PROC-0012, “Enclosure Vent Gate Look Up Table Calibration

Procedure.”



Project Management Control System (PMCS). These documents provide information on planning,

budgeting, and authorization for an integrated cost, schedule, and technical baseline for the Project.

An example is PMCS-0014, “ARRA Risk Analysis Methodology and Rationale.”

Reports (RPT). A detailed account or statement of an event or situation, as a result of observation or

inquiry. Used for scientific purposes. An example is RPT-0045, “Inference of telescope polarization:

Dunn Solar Telescope using Facility Infrared Spectropolarimeter Observations."

Requests for Waiver (RFW). An RFW is used to obtain authorization to deviate from a specification;

it is submitted by the Contractor via the COTR. See Section 6.5 for more.

Reviews (REV). This document type is for both the collected material provided at a design review,

and for the review reports themselves. For example, REV-0085 is for the material provided to

reviewers at the 2012 Safety Review; REV-0086 is the “2012 Safety Review Committee Report.”

Design review documentation should include the information defined in PMCS-0022, Design Review

Guidelines.

Specifications (SPEC). For ATST, there are two categories of SPEC documents: configuration, and

non-configuration.

Non-configuration Specifications comprise information essential to the construction and management

of the Observatory and its assemblies, but are not detailed engineering requirements. Some examples

of this type are:

• This document, SPEC-0002, “Document and Drawing Control Plan”;

• SPEC-0050, “Procurement Management Plan”;

• SPEC-0130, “ATST Relocation Policy”;

• A Preliminary Design Definition Document, which details the assembly’s optical,

mechanical, electrical and software configurations. It provides insight on the design

methodology and rationale supporting the chosen configuration as well as safety issues

associated with the chosen configuration. An example is SPEC-0093, “PA&C PDD.”

• A Critical Design Definition Document, which details the assembly’s optical,

mechanical, electrical and software configurations. It provides insight on the design

methodology and rationale supporting the chosen configuration as well as safety issues

associated with the chosen configuration. An example is SPEC-0107, “VBI CDD.”

Configuration Specifications (or requirements) are a translation of high-level requirements placed on

an assembly into specific, detailed engineering requirements. These specifications are descriptions or

assessments of requirements, dimensions, materials, etc., that define how the assembly is to be built.

Some examples of configuration Specification documents, which use words like “shall” and “will”,

are:

• An Operational Concept Design Definition, which includes information on the

philosophy and concept that underpins a subsystem. An example is SPEC-0106, “VBI

Operational Concepts Definition.”

• A Design Requirements Document, which specifies the 'build to', 'code to', and 'buy to'

requirements for products. It includes the Functional Requirements (which are necessary

tasks, actions, or activities that must be accomplished by a system) and Performance

Requirements (which quantitatively state the extent to which a system function must be

executed). For example, SPEC-0010, “Enclosure Specification Document.”



Technical Notes (TN). A technical note provides supplementary information on a subsystem,

assembly or application, or describes a problem or feature beyond the scope of other documentation.

Written by engineers for engineers, they are usually in the form of short, focused documents that

supply technical details that inform, but do not contain any requirements. They use words like

“should” and “can”. An example is TN-0097, “The GOS Optical Environment.”

o TNs include Reference Design Studies and Analyses, a document or document set that includes

one plausible design option, developed in enough detail to allow cost and performance analysis.

The analyses and studies are supporting documents prepared in house or externally. An example

is TN-0102, “Instrument Control System RDSA.”

Other document types will be specified as needed.

2.2.1 Related and Reference Documents

Related documents are Project documents called by other Project documents. For example, an ICD may

call a Specification as a related document; copies of this document would be provided to ICD recipients,

as would revisions to that related document. Or, a Specification could call a Technical note as a related

document. There are also Related Drawings in ICDs that are treated the same way.

Related documents are required by the main document.

Referenced documents are documents (i.e. journal papers, conference proceedings) that are called by a

document but are not a required reference in that document. Bibliographic information is provided, but

not a copy of the referenced document.

Referenced documents are for further information, but are not required by the main document.

2.3 CONTROLLED DOCUMENTS

It's important to understand there are two kinds of controlled documents that exist in the vault system:

Revision Controlled - documents that do not affect the configuration of the observatory (i.e. do not affect

the budget, schedule, scope, or performance). These are typically items like reports and technical notes, or

contract items like SOWs; they are controlled in as much as responsible engineers or scientists should be

aware when they are changed, but they do not need to go through the Change Control Board (CCB) for

approval of changes.

Configuration Controlled - documents that do affect the configuration of the observatory. Anything that

impacts budget, schedule, scope, or performance is a configuration controlled document, and any changes

to it must be requested via a Change Request (CR) and CCB. Configuration Items (CIs) include items not

necessarily in a typical document, such as a schedule milestone change, a budget change (either a transfer

between WBS elements or a request on contingency), a change to scope, etc.

2.4 TRACKING

While working on a document – any kind of document – the file should be kept in the ePDM vault; it

provides for version control of a document even without it being a released document, and it provides a

central and backed-up repository for working files. A file’s history can be reviewed on-demand, and

earlier versions can be restored if needed. The status of documents is summarized in the Systems

Database (see Section 1.3).

2.5 COMPLETION AND DISTRIBUTION



When a document is completed, it should be submitted for review using the ePDM system (see Section

6). After review and approval by the appropriate lead engineer and the appropriate group manager, the

document will be sent to Systems Engineering for review. The Systems Engineer will determine if the

document is controlled or not, and whether it is private or public. An example of a controlled public

document would be an ICD; an approved public document would be a report; an approved private

document a vendor’s report; and a controlled private document a contract.

Upon final approval of a document, the Systems Librarian will be notified by ePDM and will carry

through the appropriate processing. This may include updating headers, footers and revision letters,

adding signature dates, etc. At this point, a PDF copy of the current revision of the file is also stored in

the Released Documents Archive.

2.6 FORMATTING

Project documentation will use an established cover sheet and follow a modified SPIE manuscript format

(a template of which is available on the internal web site in Word format, and in the Templates directory

of the vault):

1” margins on all sides, with 0.5” headers and footers.

Headers will include the title of the document, flush right, in Arial 10pt italic.

Footers will include version or revision number, flush left, and page numbers, flush right, both in

Arial 10pt italic.

Normal or body text: Times New Roman, 11pt

1st Header: Arial, 12pt, bold, flush left, Level 1 numbering (i.e. 2.)

2nd

Header: Arial, 11pt, bold, small caps, flush left, Level 2 numbering (i.e. 2.1)

3rd

Header: Arial, 11pt, bold, flush left, Level 3 numbering (i.e. 2.1.1)

4th Header: Arial, 10pt, bold, flush left, Level 4 numbering (i.e. 2.1.1.1)

If there are any questions, contact the Systems Librarian.

2.6.1 Bibliographic Formats

For a description of Reference and Related Documents, please see Section 2.2.1.

Reference (i.e. Non-Project) documents: these follow SPIE manuscript format.

Paper: Author(s), “Title”, Journal, Volume, Inclusive pages, Year of publication.

Proceedings or book: Author(s), “Paper or chapter title”, Volume Title, Editor(s), Volume, Inclusive

Pages, Publisher, City of publication, Year of publication.

Related (i.e. Project) documents: these follow a modified SPIE manuscript format.

Author(s), “Title”, ATST Project Document <Document Number>.

Should a Project Document be used as a Reference Document, use the above format but add the

appropriate inclusive page numbers before the year of publication.

2.7 REVISING A RELEASED DOCUMENT

For internal revisions to a document (such as may occur when two people are revising the file and

shipping it back and forth), use the current revision letter and a version number. For example, if a file is

at the official released revision of B but is on the third iteration of an update, it would be labeled “B3” in



the Version History of the file. (You can see a working example of this in this document’s Version

History.)

A file does not go up to the next revision letter until after it has been appropriately reviewed and

approved. See Section 6 for details on change control processes.

2.8 RELEASED DOCUMENTS ARCHIVE

The Systems Librarian keeps a PDF copy of all versions of all released documents, drawings, and ICDs in

an archive folder in the vault (Vault\Library\Archives). The most recent version of documents will be in

the higher level folders, and earlier versions will be in subfolders called “Previous Versions”.



3. DRAWINGS

Drawing numbers (for all types of drawings) follow a number structure based on the Telescope Systems

subset of the Work Breakdown Structure (WBS), as outlined in Appendix C. Previous to this structure

definition in July 2002, some site survey drawings used a different structure; that is also noted at the end

of Appendix B.

NOTE that in ATST’s context, “drawings” means any 2D drawings used for contractual and construction

purposes, not 3D SolidWorks files.

3.1 NUMBERING AND LOCATIONS

The construction of the drawing number is a straightforward, sequential 5-digit number, in the form

ATST-DWG-XXXX. When a new drawing is needed, staff should contact the Systems Librarian to get a

number; she will select from and enter it into the Systems Database. Please DO NOT assign a number

to a drawing yourself!

The revision letter will not be a part of the drawing number but will be in the title block of the drawing,

and in the filename. ePDM will manage internal version information. When saving the electronic copy of

the file, the drawing number is used as part of the filename, such as ATST-DWG-XXXX_Title-

RevX.pdf‡, into the appropriate ePDM vault directory. Drawing status reports in a variety of ways are

available from the Systems Database, such as all drawings, drawings by subassembly, etc.

3.2 REVIEWING AND RELEASING

When a drawing is completed, the author should submit the document for review using the ePDM system

(see Section 5). The appropriate lead engineer and group manager will be notified, and will review and

approve the drawing. Upon final approval, the Systems Librarian will store a PDF copy of the current

revision of the drawing in the Released Drawings Archive.

Drawings must be reviewed and approved before being sent out with a contract or work order.

3.3 DRAWING FORMATS

A drawing format based on the ANSI Y14.1M standard will be used on every drawing. Both 2d drawing

and 3d SolidWorks templates for each size of drawings B through E are available from within the ePDM

vault, in \SysDocs\SW Library\Solidworks Templates.

3.4 INTERFACE CONTROL DRAWINGS

See Section 4.2.

3.5 REVISING A RELEASED DRAWING

See Section 6 for the process to request revisions on a released drawing.

Since drawing files are kept in PDF format, a slight change to the process is required; rather than editing

the PDF file, a new PDF file is generated from the appropriate SolidWorks drawing file.

‡ A note regarding file type: 2D drawings are generated via the 3D models; in order to maintain consistency in

drawings (especially interface drawings) so they do not change as the models change, the 2D drawing file will be

saved in PDF format.



4. INTERFACE CONTROL

4.1 INTERFACE CONTROL DOCUMENTS

An interface control document (ICD) defines the physical and software interactions between two

assemblies (or subsystems), along with any other relevant information. An ICD does not duplicate a

specification, but should clearly identify and control interfaces between designs and enable compatibility

to be demonstrated; at a minimum, it should define and illustrate physical and functional interface

characteristics.

The main areas to be addressed within the document are:

1. Subsystem Descriptions

2. Related Documents and Drawings

3. Physical System Description

Mechanical

Optical

Electrical

Mass/Balance

Thermal

4. Software Description

5. Safety Issues

The identified nodes for ICDs are shown on the N2 diagram (see Section 7). Current subsystems are

listed in Appendix C.

4.1.1 Numbering

ICDs will always follow a “lowest first” numbering scheme; for example, an interface between the

Telescope Control System (4.4) and the Telescope Mount Assembly (1.1) will have an ICD number of

1.1/4.4. This scheme will be used throughout interface control.

4.1.2 Naming Convention

ICD documents should follow the naming convention of “A.B-X.Y Title.doc”, where A.B is the first

subsystem assembly and X.Y is the second. Using the above example, the file would be called “1.1-4.4

TMA to TCS.doc”. ICD files will be “shared” between the two assemblies in the ePDM vault.

4.1.3 Physical System Description*

The mechanical section is used to define and control the mechanical features, characteristics, dimensions,

and tolerances of any equipment design that affect the design of another subsystem. They also define

force transmission requirements where a static or dynamic force exists. The features of the equipment that

influence or control force transmission are also defined in this section. Mechanical interfaces include

those material properties that can affect the functioning of mating equipment, such as thermal and

galvanic characteristics. As such, this section should also include any relevant information about supplied

services that a piece of equipment needs to function.

The optical section should include appropriate descriptive information about the optical elements as they

are relevant to the interrelated systems.

Electrical descriptions are used to define and control the interdependence of two or more pieces of

equipment when the interdependence arises from the transmission of an electrical signal from one piece

* Some definitions taken from NASA Reference Publication 1370, “Training Manual for Elements of Interface Definition and

Control”, January 1997.



of equipment to another. The functional mechanizations of the source and receiver of the interface

electrical signal are defined, as well as the transmission medium. The interface definition includes the

data and/or control functions and the way in which these functions are represented by electrical signals.

4.1.4 Software Description

A software interface defines the actions required when there is an interchange of information. As such,

one may exist where there is no direct mechanical or electrical interface.

4.2 INTERFACE CONTROL DRAWINGS

An Interface Control Drawing illustrates the physical interactions between two assemblies or

subassemblies. Similar to ICDs, these files will be “shared” between the two assemblies in the ePDM

vault.

*A note regarding file type: 2D drawings are generated via the 3D models; in order to maintain

consistency in drawings (especially interface drawings) so they do not change as the models change, the

2D drawing file will be saved in PDF format. See Section 3.2 for more information.

4.3.1 Naming Conventions

Interface Drawing files (whether they are assembly, part or PDF files) should follow the same naming

convention as a regular drawing, “ATST-DWG-XXXX_Title.pdf”.

4.3 INTERFACE DOCUMENT OR DRAWING APPROVAL

Unlike regular documents or drawings, interface documents and drawings require approval by the lead

engineers on both ends of the interface, and the appropriate group managers at both ends as well. This is

also handled by the EPDM workflow, which routes the file for review sequentially. Both engineers and

both managers must approve the file before it goes to Systems Engineering.

An Interface Control Package consists of an Interface Control Document and all related Interface Control

Drawings. All ICD Packages will be under a formal change control system, implemented and managed

by Systems Engineering. Once an ICD formally completes this process, it becomes the official document

defining interface design requirements. At this point, the Systems Librarian will put PDF copies of the

documents in the Released Documents Archive.

ICDs must be reviewed and approved before being sent out with a contract or work order.



5. ENTERPRISE PDMWORKS

Enterprise PDMWorks, aka ePDM and/or the Vault, is the electronic document management system in

use at ATST. It provides an electronic “vault” for all documentation – reports, spreadsheets,

presentations, images, and more. The majority of files are in the Systems Documentation directory,

which is structured to match the WBS.

The vault interface looks like this:

The file vault is accessed via Windows Explorer or any Microsoft Office application. Files are locked

before editing (which checks the file out of the vault to the person who locked it); are read-only if not

locked; and automatically update through the entire system when a file is unlocked (which checks the file

back into the vault). A preview of the file is seen in the lower center preview window, while file

information is in the lower right window. Different windows are accessible from tabs that show the file

data card or the version details of the file itself.

ePDM provides automatic version control on files; each time a file is unlocked you will be prompted to

add a comment, but even without a comment the system will treat each unlock as a new version. These

versions can be thought of as the working drafts between revisions. To increment revisions, a file must

go through a review and approval process. ICDs and drawings must be reviewed and approved

before being sent out with a contract or work order.



5.1 REVIEW AND RELEASE PROCEDURES

ePDM provides a workflow process that enables the approval procedure to be done in a smooth manner.

For files that require approval, the author would simply request approval on the file. The system would

contact the appropriate lead engineer for review, and that engineer would then tell the system if the file is

approved or not. Upon approval, the system would mail the author with an approval notice, and change

the state of the file to “approved”. Once a file is in the approved state, it cannot be edited again without

an approved request for further editing, granted by the appropriate lead engineer.

Training in the ePDM system will be provided by the Systems Librarian to all staff, and refreshers are

available at any time. There is also a How-To page for ePDM on the ATST Intranet, which is constantly

being updated with new information (including details about the workflow, below).

5.2 WORKFLOW

Every file begins in the Initiated state. From there the option available to all staff is “Submit for Review”;

after that, the file will follow a different path depending on what type of file it is (ICD or non-ICD), to

end up in one of four final “Approved” states.

When a file transitions through “Submit for approval”, a notification will be sent to the appropriate

responsible engineer(s), and the file enters the “Waiting for Approval” state. At this point, the

responsible engineers can either request more editing (“Editing Required”), or approve the file (“Passed

Engineering Approval”). Once the responsible engineers have approved the file, the responsible Group

Manager(s) are notified, and they have the same options. After that step, the Systems Engineer is notified

that the file is now waiting for systems approval; the Systems Engineer has the same options, to either

request more editing or approve the file. If the Systems Engineer requests further editing, the file must go

back through the Engineering Approval process.

Once all relevant approvals have been obtained, the file passes into one of the “Approved” states

(depending on whether it is public or private, and controlled or not controlled). At this point, it becomes

read-only until the “Request Further Editing” transition is selected (see Section 5.2 below), and a PDF

copy is put in the Released Documents Archive.

The workflow is shown in the next figure.



Th

e A

TS

T W

ork

flo

w



5.3 CHANGING STATE VIA TRANSITIONS

To change a file’s state via the transitions mentioned above, first, the file must be unlocked. Then, select

the file and use the right-click pop-up menu within the vault; look for “Change State”. All selectable

options for the file will appear (i.e. if the file is in “Initiated” state, then “Submit for Approval” will

appear). Select the option you require and the system will go from there.

For engineers, to approve a file you would also go to the Change State pop-up menu, but you would

choose the appropriate “Passed Engineering Approval” option.

5.4 REQUESTING REVISIONS TO A FILE

If the need arises to edit a file that’s in an approved or controlled state, select the file and choose “Request

Further Revisions” from the Change State menu, and add appropriate comments in the box provided. At

this time, an email is sent to Systems Engineering and the appropriate lead engineer notifying them that a

change has been requested. The lead engineer will need to approve or deny the state change request; at

that point, an email is sent to the requestor with the result, and the file is moved into the “Editing” state.

After the file has been edited, choose “Resubmit for Approval” from the Change State menu to re-enter

the file into the review and approval process, and include an appropriately detailed description of changes

in the box provided. This can be the same information as entered in the Revision History of the

document, but in both places, it should be descriptive enough to explain the changes made. These

comments become part of the Change Request revision history of the file.

If the document is a controlled document, it will be put in a “Waiting for CCB Review” state while the

Change Control Board reviews the changes (see Section 6). If it is a regular approved document, the

appropriate lead engineer will need to review and approve the changes. At that point, the review and

approval process starts over again, with the same steps and end states.



6. CHANGE CONTROL

6.1 CHANGE CONTROL BOARD

The Change Control Board (CCB) is comprised of the Project Manager, the Project Scientist, and the

Systems Engineer. They are the final arbiters of whether changes to controlled documents are acceptable

or not. See PMCS-0018, Revision Control and Configuration Management, for more information.

6.2 APPROVED DOCUMENTS

In order to revise an Approved document, a request must be made to edit it, then the document must be

resubmitted for approval.

The reviser must request further editing on the document using ePDM (see Section 5.2). This notifies

Systems Engineering that the document is being updated; the appropriate lead engineer is also notified of

the change, and must approve the document moving into the Editing state from the Controlled state.

(Sometimes the reviser and the lead engineer are the same person; in this case the reviser can immediately

approve the state change after requesting further revisions.) Once changes have been made, the document

is resubmitted for approval and then, similar to the first time a document goes through, the lead engineer

must approve it, unless this is an interface control file, in which case both lead engineers must approve it.

Then it goes to Systems Engineering for review, approval and redistribution. It is at the Systems

Engineer’s discretion whether documents are sent on to the Project Manager or the CCB for further

review and approval.

Upon final re-approval, the Systems Librarian will put a PDF copy of the new revision of the document in


6.3 CONTROLLED DOCUMENTS

In order to revise a Controlled document, the requester must request editing on the file, but then only the

Systems Engineer is notified, as the chair of the CCB. The Systems Engineer must approve further edits

to the document, and can do so either before or concurrent with discussions of the CCB. This also

requires the use of a Change Request (see Section 6.4 below).

Once the file is resubmitted for approval, it will wait until the associated CR has been reviewed. Only

after the CCB has approved the CR does the file move to the next revision. At this point, this new

revision then becomes the official document.

Upon final approval, the Systems Librarian will put a PDF copy of the new revision of the document in


6.4 CHANGE REQUESTS

In order to modify the WBS, which includes any subsystem names, or to rearrange a WBS structure, or to

make any changes that affect budget or schedule (such as increasing or decreasing the scope of a

controlled document), a Change Request form must be submitted (see Appendix E). CRs are also used

when Requests for Waiver (RFWs) are requested by a vendor (see Section 6.5).

These forms (and any associated documentation) are then reviewed by the CCB, and only after they are

approved are any changes implemented. The change history of these CRs can be found in the Systems

Database, or in the Systems Librarians’ files.

6.4.1 How to Use a Change Request

1) For a document, request changes on the document noting the CR number in the comments:



2) Request a CR number from systems engineering.

3) Create your CR using the template in the vault (Templates -> ChangeRequest_Template), initially

including only an abstract or sketch of the change you are proposing. This allows Systems

Engineering to gain an early understanding of the nature of the request.

4) Save the CR in the vault in the \SysDocs\SysEng\Configuration Management\Change Requests\

folder. Be sure to include the CR number at the front of the filename.

5) Complete the CR (within the Change Requests vault folder) with an appropriate level of detail in the

description. It is not sufficient to just say something like "Changed the requirements" or "Updates to

ICD". What requirement is to change, and why? If it's a budget change, be sure to include supporting

spreadsheets or files illustrating the before and after budgetary impacts, etc. If you changed a

drawing, what changed and why?

6) Once Systems Engineering has approved changes to your document, request further edits on it and

make the appropriate changes to it in its home directory, with "Track Changes" selected.

7) Add any supporting documentation for your CR into the CR home directory. Be sure to add the CR

number into the filename so it is grouped with the form itself, using the same naming convention as

mentioned earlier.

8) Both the CR and the document need to be approved at the engineering level prior to being

submitted to the CCB. All files need to be in the "Waiting for Systems Engineering" state before

going before the CCB (see below). Once they've been submitted to Systems Engineering, that gets it

on our radar; if it passes SysEng review, it will be placed in a "Waiting for CCB Review" state and

will be added to the next CCB meeting agenda.

9) The CR will be reviewed by the CCB; if approved, then systems engineering will proceed with the

approval and processing of the related documents. Systems Engineering will accept your marked-up

changes; check to verify that all headers, footers and revision notes are appropriate; and place the new

revision back under configuration control.

6.4.2 Extra Useful Information

The Reason and Description are the keys to a swift approval:

Technical Changes: All CRs need explanations for the technical change and should include

assessments done to date. This will guide what analysis is required (and will be initiated through the

CCB) to conclude the evaluation.

Schedule Changes: Outline level of impact and include modified schedule.

Budget Change: If there is one, the CR must have a time-phased spreadsheet explaining the impact to

aid in the evaluation (this will be done by Bill who will report the results for consideration).



If any of these needed areas are lacking, it will delay the process as the CCB will request more

information; one criticism of the process has been that inadequate information on the reason for the

rejection has been provided. We'll work hard to be as specific as possible on what is needed for the

evaluation; these will be documented in comments on the individual CR pages.

6.5 REQUESTS FOR WAIVER

A Request for Waiver (RFW; see Appendix F for the form) is submitted by the persons(s) requiring the

waiver, i.e. the Contractor, via the COTR; either may draft the request, but both the COTR and the

Contractor must approve it. It is used to obtain authorization to deviate from a specification. It must be

submitted when analysis performed during the design phase has shown that the requirement cannot be

met, or during manufacture or acceptance testing if an item is found to depart from specified

requirements.

Note that RFWs are implemented in the Compliance Matrix for the affected assembly.

6.5.1 How to Use an RFW:

1) Request an RFW number from systems engineering.

2) Create your RFW using the template in the vault (Templates -> RFW_Form), initially including only

an abstract or sketch of the change you are proposing. This allows Systems Engineering to gain an

early understanding of the nature of the request.

3) Save the RFW in the vault in the \SysDocs\SysEng\Configuration Management\Waivers\ folder,

creating a new sub-folder for each. Be sure to include the RFW at the front of the filename.

4) The RFW needs to be approved at the engineering level prior to being submitted to the CCB. All

files need to be in the "Waiting for Systems Engineering" state before going before the CCB (see

below). Once they've been submitted to Systems Engineering, that gets it on our radar; if it passes

SysEng review, it will be placed in a "Waiting for CCB Review" state and will be added to the next

CCB agenda.

5) The CR will be reviewed by the CCB; if approved, then systems engineering will proceed with the

approval and processing of the related documents. Systems Engineering will accept your marked-up

changes; check to verify that all headers, footers and revision notes are appropriate; and place the new

revision back under configuration control.

6.6 CCB ACTIONS ON CRS AND RFWS

Please note that Systems Engineering does not assume that the author of the form is the lead

engineer/approver for it, so sometimes multiple submit-and-approve steps are required.

1) CRs and RFWs are submitted for review, and electronically approved, just as any other document in

the vault is. If the preparer of the form is also the lead engineer, then after submitting for approval the

lead engineer should also approve it. If a CR is for an ICD, then both lead engineers will have to

approve it, just as with the ICD itself.

2) Once a document reaches the "Waiting for CCB Review" state it will stay there until after the CCB

votes on it. If the form was approved, then it will be processed with the necessary vote and discussion

results. If the form was denied, the originator will be notified.

3) Note that certain CR threshholds (level 1 milestones, budget changes over $150K) require further

approval by the NSO and NSF.

4) Once all approvals are in place and the form has been processed, the originators of the form are

notified via email that their form has been approved. Additional emails are sent to notify the

originators that processing on affected CR-related documents has been completed. The CR or RFW

has the electronic signature information appended to the footer. CRs (and all supporting



documentation) are moved into the appropriate sub-directory in the vault (these are read-only

directories); RFWs are left in their Waiver folders.

6.6.1 CR Tracking and Status Reports

In addition to the Systems Database (\SysDocs\SysEng\systems.mdb, available read-only for on-the-spot

CR report generation anytime) there is also a set of web pages that track the status of CRs as they go

through the process (available via http://atst.nso.edu/syseng/cm).

The various status levels are:

Pending - A CR number has been assigned but a form has not been created yet.

Draft - a CR form exists in the Change Requests directory, but is still being edited or reviewed for

information and/or supporting material.

Open - Engineering Approval - The CR has been submitted for engineering approval, but not yet

approved.

Open - Submitted to CCB - The CR has been approved at the engineering level and is in the "Waiting

for Systems Engineering" state, when it is presented to the CCB for discussion.

Open - Awaiting NSO/NSF Approval - the CR has passed the CCB but requires further review and

approval.

Approved - Awaiting Implementation - the CR has passed the CCB but the changes requested have

not yet been made.

Implemented - The CR has passed the CCB and the requested changes have been made.

Rejected - The CR has been denied by the CCB.

Cancelled - the CR was cancelled by the originator.

Held by CCB for Further Discussion - The CR has been discussed by the CCB but they require

further clarification before proceeding.

Returned by CCB for Re-work - The CR has been discussed by the CCB but they require further

supporting information or documentation before proceeding.

6.6.2 RFW Tracking and Status Reports

In addition to the Systems Database (\SysDocs\SysEng\systems.mdb, available read-only for on-the-spot

RFW report generation anytime) there is also a web page that tracks the status of RFWs as they go

through the process (available via http://atst.nso.edu/syseng/cm).



7. ICD/N2 DIAGRAM

Initial selection of interfaces generally begins with listing all pieces of equipment in the system and then

identifying the interactions between then. A tool used to help in this process is the N2 diagram. This

diagram is a visual indicator of the main assemblies of the observatory, and based on the WBS. It is used

primarily to indicate interface control nodes, and secondarily to track major project documentation. The

N2 diagram is available from the Systems Engineering web page on the Online Project Book.

A view showing the “3.0 Instrument Systems” section is shown:

As ICDs are started, their nodes are colored yellow on the chart; once an ICD is approved and under

change control, its node is colored green.



APPENDIX A: DOCUMENT TYPE LISTING

At this time, the current document types are:

Change Requests (CR)

Compliance Matrix (CMX)

Contractor Reports (CON)

Drawings (DWG)

Interface Control Documents (ICD)

Memorandums of Understanding (MOU)

Procedures (PROC)

Project Management Control System (PMCS)

Reports (RPT)

Requests for Waiver (RFW)

Reviews (REV)

Specifications (SPEC)

Technical Notes (TN)

Other document types will be specified as needed.



APPENDIX B: DRAWING NUMBER BREAKDOWNS

With the change to a sequential drawing numbering type, this appendix was removed in 2008.

Previous to December 2007:

Numbering Structure: ATST-A1A2-B-C-DXXX (where DXXX is a unique ID). These drawings were

migrated to the new drawing structure; a list showing their previous assigned numbers is available in the

Vault, in SysDocs\SysEng\ Drawing Renumbering List-Final.pdf.

Previous to July 2002:

100000 - Site Survey

101000 - S-DIMM

102000 - Shabar

102100 - Micro-Telescope

103000 - Tower

103100 - Foundation

104000 - Pre-Site Survey

105000 - Miscellaneous

105100 – Alignment Tool

106000 - Electronics

107000 - Software

108000 - Documentation

108100 - Requirements / Specifications

108200 – Statements of Work

108300 - Operations & Maintenance Manual

108400 – Software Users Manual



APPENDIX C: N2 SUBSYSTEMS

Telescope Systems WBS Section:

1 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.7 Ancillary Mechanical Equipment

1.1.8 Mount Control System

1.1.9 Telescope Mount Assembly GIS Interface

1.1.11 Telescope Mount Assembly Tools & Equipment

1.2 M1 Assembly

1.2.1 M1 Mirror

1.2.1.1 M1 Mirror Blank

1.2.1.2 M1 Mirror Grind, Polish, Ship

1.2.2 M1 Cell Assembly

1.2.2.1 M1 Support System

1.2.2.2 M1 Cell Structure

1.2.2.3 M1 Thermal Control System

1.2.2.4 M1 Safety Restraint System

1.2.2.5 M1 Control System

1.2.2.6 M1 Ancillary Equipment

1.2.8 M1 Tools and Equipment

1.2.9 M1 Assembly Vendor Design

1.3 Top End Optical Assembly

1.3.1 Heat Stop Assembly

1.3.1.1 Reflector Assembly

1.3.1.2 Occulter Insert

1.3.1.3 Heat Stop Control System

1.3.2 M2 Assembly

1.3.2.1 M2 Mirror

1.3.2.1.1 M2 Mirror Blank

1.3.2.1.2 M2 Mirror Grind, Polish, Ship

1.3.2.2 M2 Positioning System

1.3.2.3 M2 Thermal Control System

1.3.2.4 M2 Control System

1.3.2.5 M2 Ancillary Equipment

1.3.2.6 Lyot Stop

1.3.2.7 M2 Tools and Equipment

1.3.3 TEOA Control System

1.3.4 TEOA Ancillary Equipment

1.5 Feed Optics

1.5.1 Transfer Optics

1.5.1.1 M3 Blank

1.5.1.2 M3 Grind, Polish

1.5.1.3 M3 Alignment Stage

1.5.1.4 M3 Mount



1.5.1.5 M4 Blank


1.5.1.7 M4 Mount

1.5.1.8 M5 Blank


1.5.1.10 M5 Mount

1.5.1.11 M6 Blank


1.5.1.13 M6 Mount

1.5.1.14 M6 Alignment Stage

1.5.2 Coudé Optics

1.5.2.1 M7 Blank


1.5.2.3 M7 Mount

1.5.2.4 M7-Cryo-NIRSP Blank

1.5.2.5 M7-Cryo-NIRSP Grind, Polish

1.5.2.6 M7-Cryo-NIRSP Alignment Stage

1.5.2.7 M7-Cryo-NIRSP Mount

1.5.2.8 M8 Blank


1.5.2.10 M8 Mount

1.5.2.11 M9 Blank


1.5.2.13 M9 Mount

1.5.3 Feed Optics Thermal Control System

1.5.4 Feed Optics Control System

1.5.5 Feed Optics Tools and Equipment

1.7 System Alignment

1.8 Acquisition System

1.8.1 Acquisition Unit

1.8.2 Acquisition Unit Control System

2 Wavefront Correction

2.1 Wavefront Correction - Coudé (WFC-C)

2.1.1 Adaptive Optics - Coudé (AO-C)

2.1.1.1 High Order Adaptive Optics

2.1.1.1.1 AO Wavefront Sensor System - Coude

2.1.1.1.1.1 Fold Mirrors & Mounts (F2,F3)

2.1.1.1.1.2 Air Spaced Achromat

2.1.1.1.1.3 Field Stop

2.1.1.1.1.4 Lens to Focus Pupil on Lenslet Array

2.1.1.1.1.5 Lenslet Array

2.1.1.1.1.6 Lens to Collimate Subaperture Images

2.1.1.1.1.7 Filters

2.1.1.1.1.8 Misc. Hardware

2.1.1.1.1.9 Zoom Lens

2.1.1.1.1.10 Camera

2.1.1.1.2 Real Time System - Coudé

2.1.1.2 Fast Tip-Tilt Mirror System - Coudé

2.1.1.2.1 Mirror

2.1.1.2.2 Tip-Tilt platform

2.1.1.2.3 Cooling system



2.1.1.2.4 Tip/tilt mount to tower

2.1.1.2.5 Cable from driver to tip-tilt platform

2.1.1.2.6 Rack, cooled for Driver, cooling system

2.1.1.3 Deformable Mirror System - Coudé

2.1.1.3.1 Deformable Mirror (DM)

2.1.1.3.1.1 Cables from drive electronics to DM

2.1.1.3.1.2 DM & Cooling Cart

2.1.1.3.1.3 Drive Electronics

2.1.1.3.2 DM Mount

2.1.1.3.3 DM Monitor computer

2.1.1.3.4 Spare DM and Driver Cards

2.1.1.3.5 Test flat with mount

2.1.2 Active Optics (aO) - Coudé

2.1.2.1 aO Wavefront Sensor - Coudé

2.1.2.1.1 Fold Mirror (F4) Beamsplitter (S3), Mounts

2.1.2.1.2 Air Spaced Achromat

2.1.2.1.3 Field Stop

2.1.2.1.4 Lens to Focus Pupil on Lenslet Array

2.1.2.1.5 Lenslet Array

2.1.2.1.6 Lens to Collimate Subaperture Images

2.1.2.1.7 Filters, mount and stage

2.1.2.1.8 Mounting rail, misc items

2.1.2.1.9 Zoom Lens

2.1.2.1.10 Camera

2.1.2.2 Real Time System

2.1.3 Context Viewer

2.1.3.1 Image Sensor

2.1.3.1.1 Beam Splitter, (S2) & Mount

2.1.3.1.2 Air Spaced Achromat

2.1.3.1.3 Filters

2.1.3.1.4 Mounting rail, misc items

2.1.3.1.5 Zoom Lens, Motorized

2.1.3.1.6 Camera & Display

2.1.3.2 CV Real Time System

2.1.4 Common Items

2.1.4.1 Intentionally Left Blank

2.1.4.2 Optical Bench & Legs

2.1.4.4 Main Beam-splitter (S1) & Mirror (F1), Mounts

2.1.4.5 Main beam splitter cooling system

2.1.4.6 OAPs & Mounts

2.1.4.7 Fold Mirrors & Mounts

2.1.4.9 Rack for DM driver, HOAO Real Time System

2.1.4.10 Motor Controllers, Actuators, Stages, Mounts

2.1.4.11 Monitor, Keyboard, Switch: for Local Computer/Controller use

2.1.4.12 Rack for aO controller, CT controller, CV controller, motor controllers

2.1.4.13 Instrument Tip/Tilt Sensors

2.1.4.14 Hilltop Lab Equipment

2.1.5 Coudé Tools and Equipment

2.3 Wavefront Correction Control System

2.3.1 Computer

2.4 Wavefront Correction Subsystem Integration & Test



2.4.1 Adaptive Optics - Coudé (AO-C) - IT&C

2.4.2 Active Optics (aO) - Coudé - IT&C

2.4.3 Context Viewer - IT&C

2.4.4 Common Items - IT&C

2.4.5 Wavefront Correction Control System - IT&C

2.5 Wavefront Correction Limb Tracker

3 Instrument Systems

3.1 Instrument Lab Facility

3.1.1 Polarimetry Analysis and Calibration

3.1.2 Master Clock & Synchro Network

3.1.3 Coudé Station

3.1.3.1 Imaging Optics

3.1.3.3 Optical Benches

3.1.3.4 Additional Lab Items

3.1.4 Instrument Control System

3.1.5 Coudé Environmental System

3.2 Visible Broadband Imager (VBI)

3.2.1 VBI Blue Channel

3.2.2 VBI Red Channel

3.3 Visible Spectropolarimeter (ViSP)

3.4 Near-IR Spectropolarimetry (NIRSP)

3.4.1 Diffraction Limited Near-IR Spectropolarimeter (DL-NIRSP)

3.4.2 Cryogenic Near-IR Spectropolarimeter (Cryo-NIRSP)

3.5 Visible Tunable Filter (VTF)

3.6 Camera Systems

3.6.1 Camera Hardware

3.6.2 Camera Software

4 High-Level Controls and Software

4.1 Common Services

4.2 Observatory Control System (OCS)

4.3 Data Handling System (DHS)

4.4 Telescope Control System (TCS)

4.5 Global Interlock System (GIS)

5 Enclosure

6 Support Facilities and Buildings

6.1 Construction Services

6.1.1 Geotechnical Testing

6.1.2 Demolition and Clearing

6.1.3 Major Earthwork

6.1.4 Roads and Driveways

6.1.5 Utilities

6.1.6 Utility Chase

6.1.7 Soil and Structural Reinforcement

6.1.8 Construction Infrastructure

6.2 Buildings

6.2.1 Support and Operations Building

6.2.2 Utility Building

6.2.3 Lower Enclosure

6.2.4 Telescope Pier Assembly

6.3 Facility Equipment

6.3.1 General Outfitting and Furnishings



6.3.2 Environmental Monitoring

6.3.3 Generator

6.3.4 Uninterruptible Power Supplies (2)

6.3.5 Special Mechanical Equipment

6.3.6 Tools and Special Equipment

6.3.7 Moved to 6.7.3

6.4 Coating and Cleaning Facilities

6.4.1 Cleaning Station, Fixtures, Tooling

6.4.2 Coating Chamber

6.5 Handling Equipment

6.5.1 Platform Lift

6.5.2 Handling Cranes

6.5.3 Personnel Access Equipment

6.6 Interconnects and Services

6.6.1 System Interconnects

6.6.2 IT Infrastructure

6.6.3 Grounding and Lightning Protection System

6.7 Facility Thermal Systems

6.7.1 Facility Plant Equipment

6.7.2 Thermal Sub-Systems

6.7.3 Facility Management System

6.7.4 Facility Control System

7 Remote Operations Building (ROB)

7.1 Building (Lease)

7.2 Building Outfitting



APPENDIX D: PROPRIETARY INFORMATION

(Excerpted from S. Keil Memo, “Protection of Proprietary Information”, February 12, 2003)

Purpose: The purpose of this policy is to establish specific guidelines and instructions for all staff to

follow in order to ensure the protection and privacy of Proprietary Information.

Policy:

Proprietary Information must always be kept in a locked file cabinet. One person should be

assigned to maintain control over the original (if applicable) and any copies.

o One person will maintain the documents in a locked cabinet, with one other person

having a spare key.

NSO / ATST Tucson Primary: Jennifer Ditsler

NSO / ATST Tucson Secondary: Ruth Kneale

All copies must be controlled using a formal sign out sheet (see attached).

o There will be one original, plus one copy for sign-out use for each document.

o The original and each copy will have a number assigned for tracking purposes.

o Individuals will need to sign for any copies of documents that are removed.

Duplication of proprietary information will be closely tracked.

o Only designated staff will be authorized to make copies.

o Proprietary information must be kept separate from non-proprietary information (i.e.

meeting materials).

o Each copy will be assigned a document number and records will be kept as to who

receives copies (names, address, telephone number).

o If the document is to be sent outside of the office, the responsible manager must sign to

authorize the release.

o All copies will have the “Proprietary Information” cover sheet (see attached), which will

list the responsible manager, document number and date.

Exceptions: None.



APPENDIX E: CHANGE REQUEST FORM



APPENDIX F: REQUEST FOR WAIVER FORM

Document and Drawing Control Plan - DKIST · July 2012 Reviewed By: R ... o All 3d parts and...

Documents

Transcript of Document and Drawing Control Plan - DKIST · July 2012 Reviewed By: R ... o All 3d parts and...