Upload
vananh
View
215
Download
0
Embed Size (px)
Citation preview
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
Document and Drawing Control Plan
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.
Document and Drawing Control Plan
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
Document and Drawing Control Plan
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
Document and Drawing Control Plan
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
Document and Drawing Control Plan
SPEC-0002, Rev H Page 2 of 33
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.
Document and Drawing Control Plan
SPEC-0002, Rev H Page 3 of 33
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.
Document and Drawing Control Plan
SPEC-0002, Rev H Page 4 of 33
Document and Drawing Control Plan
SPEC-0002, Rev H Page 5 of 33
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.”
Document and Drawing Control Plan
SPEC-0002, Rev H Page 6 of 33
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.”
Document and Drawing Control Plan
SPEC-0002, Rev H Page 7 of 33
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
Document and Drawing Control Plan
SPEC-0002, Rev H Page 8 of 33
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
Document and Drawing Control Plan
SPEC-0002, Rev H Page 9 of 33
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”.
Document and Drawing Control Plan
SPEC-0002, Rev H Page 10 of 33
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.
Document and Drawing Control Plan
SPEC-0002, Rev H Page 11 of 33
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.
Document and Drawing Control Plan
SPEC-0002, Rev H Page 12 of 33
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.
Document and Drawing Control Plan
SPEC-0002, Rev H Page 13 of 33
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.
Document and Drawing Control Plan
SPEC-0002, Rev H Page 14 of 33
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.
Document and Drawing Control Plan
SPEC-0002, Rev H Page 15 of 33
Th
e A
TS
T W
ork
flo
w
Document and Drawing Control Plan
SPEC-0002, Rev H Page 16 of 33
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.
Document and Drawing Control Plan
SPEC-0002, Rev H Page 17 of 33
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
the Released Documents Archive.
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
the Released Documents Archive.
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:
Document and Drawing Control Plan
SPEC-0002, Rev H Page 18 of 33
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).
Document and Drawing Control Plan
SPEC-0002, Rev H Page 19 of 33
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
Document and Drawing Control Plan
SPEC-0002, Rev H Page 20 of 33
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).
Document and Drawing Control Plan
SPEC-0002, Rev H Page 21 of 33
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.
Document and Drawing Control Plan
SPEC-0002, Rev H Page 22 of 33
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.
Document and Drawing Control Plan
SPEC-0002, Rev H Page 23 of 33
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
Document and Drawing Control Plan
SPEC-0002, Rev H Page 24 of 33
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
Document and Drawing Control Plan
SPEC-0002, Rev H Page 25 of 33
1.5.1.5 M4 Blank
1.5.1.6 M4 Grind, Polish
1.5.1.7 M4 Mount
1.5.1.8 M5 Blank
1.5.1.9 M5 Grind, Polish
1.5.1.10 M5 Mount
1.5.1.11 M6 Blank
1.5.1.12 M6 Grind, Polish
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.2 M7 Grind, Polish
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.9 M8 Grind, Polish
1.5.2.10 M8 Mount
1.5.2.11 M9 Blank
1.5.2.12 M9 Grind, Polish
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
Document and Drawing Control Plan
SPEC-0002, Rev H Page 26 of 33
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
Document and Drawing Control Plan
SPEC-0002, Rev H Page 27 of 33
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
Document and Drawing Control Plan
SPEC-0002, Rev H Page 28 of 33
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
Document and Drawing Control Plan
SPEC-0002, Rev H Page 29 of 33
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.
Document and Drawing Control Plan
SPEC-0002, Rev H Page 30 of 33
Document and Drawing Control Plan
SPEC-0002, Rev H Page 31 of 33
Document and Drawing Control Plan
SPEC-0002, Rev H Page 32 of 33
APPENDIX E: CHANGE REQUEST FORM
Document and Drawing Control Plan
SPEC-0002, Rev H Page 33 of 33
APPENDIX F: REQUEST FOR WAIVER FORM