Project documentation specification #0002 Rev G

Project Documentation Specification #0002 Rev G
Document and Drawing Control Plan

Ruth A. Kneale
Systems Librarian April 24, 2009
Approved for release:
R. Hubbard Systems Engineer Original on file
4 May 2009 Date
Advanced Technology Solar Telescope Phone 520-318-8102
950 N. Cherry Avenue atst@nso.edu
Tucson, AZ 85719 Fax 520-318-8500
ATST Document and Drawing Control Plan
Version History:
1. Date: Revision: Changes: 2. Date: Revision: Changes: 29 October 2002 A Initial release 30 July 2003 B Addition of Physical System Interface descriptions and expansion of sections of the drawing appendix; tightening of assembly document requirements. 11 May 2004 C Revised sections to match construction WBS/N2 chart changes. Includes changes to subsystem breakdowns, ICD numbering, and drawing numbering schemes. 1 October 2004 D Major revisions and additions to each section. 1 March 2005 D.1 Revisions to include more information on the Systems Database, ICD packages, and ICD naming conventions, and updates to the Drawing and Subsystem lists. 1 March 2006 E Include new information on bibliographic format information; Reference vs. Related Documents; and updates to almost all other sections. 13 April 2006 E.1 Added information about internal revision numbering and process for revising released documents and drawings. 18 September 2006 F Updated all sections; now includes statement of purpose, expanded entries for review & approval process, and clarifications for file naming and locations. 24 April 2009 G Updated all sections to reflect changeover from Enterprise PDMWorks to PDMWorks, general updating otherwise.
3. Date: Revision: Changes:
4. Date: Revision: Changes: 5. Date: Revision: Changes:
ATST SPEC-0002, Rev G
Page i
Table of Contents
Preface............................................................................................................................................ 1 1. Standards ............................................................................................................................... 2
Electronic Documentation Locations .......................................................................................... 2 Paper Documentation Locations .................................................................................................. 2 Systems Change Tracking Log .................................................................................................... 3 Systems Database ........................................................................................................................ 3 2. Documents ............................................................................................................................. 5 2.1. Numbering ................................................................................................................................... 5 2.2. Types ........................................................................................................................................... 5 2.2.1. Related and Reference Documents ......................................................................................... 6 2.3. Tracking ....................................................................................................................................... 6 2.4. Completion and Distribution ....................................................................................................... 6 2.5. Formatting ................................................................................................................................... 6 2.5.1. Bibliographic Formats ............................................................................................................. 7 2.6. Revising a Released Document ................................................................................................... 7 3. Drawings ................................................................................................................................ 8 3.1. Numbering and Locations ........................................................................................................... 8 3.2. Reviewing and Releasing ............................................................................................................ 8 3.3. Drawing Formats ......................................................................................................................... 8 3.4. Interface Control Drawings ......................................................................................................... 8 3.5. Revising a Released Drawing ...................................................................................................... 9 4. Interface Control ................................................................................................................. 10 4.1. Interface Control Documents..................................................................................................... 10 4.1.1. Physical System Description ................................................................................................. 10 4.1.2. Software Description ............................................................................................................. 11 4.2. Interface Control Drawings ....................................................................................................... 11 4.3. Interface Document or Drawing Approval ................................................................................ 11 5. Revisions .............................................................................................................................. 12 5.1. Approved Documents ................................................................................................................ 12 5.2. Controlled Documents ............................................................................................................... 12 5.3. Change Requests ....................................................................................................................... 12 6. N2 Diagram .......................................................................................................................... 13 7. Enterprise PDMWorks....................................................................................................... 14 7.1. Review and Release Procedures ................................................................................................ 15 7.1.1. Workflow .............................................................................................................................. 15 7.1.2. Changing State via Transitions ............................................................................................. 16 7.2. Requesting Revisions to a File .................................................................................................. 16 Appendix A: Document Type Listing ....................................................................................... 17 Appendix B: Drawing Number Breakdowns .......................................................................... 18 Appendix C: N2 Subsystems...................................................................................................... 19 Appendix D: Proprietary Information..................................................................................... 22 Appendix E: Change Request Form ......................................................................................... 25 1.1. 1.2. 1.3. 1.4.
Page ii
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.
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, UCRLAM-133867, November 2004 3. DSMC Systems Engineering Management Guide, January 1990
Page 1 of 25
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.4. 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 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 Enterprise PDMWorks (EPDM) electronic document management system (formerly Conisio; see Section 6). 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). 1.2. PAPER DOCUMENTATION LOCATIONS
The Project Assistant will keep Business documentation. The Systems Librarian will keep Outcomes documentation. These two types of documentation are defined as follows: Business Documents Budgets Contracts and RFPs Meeting information MOUs Personnel Purchasing Outcomes Documents Drawings Interface Control Documents Reports (including MOU and Contract) Specifications (including Specification Documents) Technical Notes Reference documents
Page 2 of 25
Business Documents Travel
Outcomes Documents Contractor reports Review materials Other documents as needed
In addition, there is a Proprietary Information cabinet drawer in the Systems Librarians office. Any documentation removed from this drawer, whether as an original or a copy, must follow the appropriate procedures as set forth in the Directors Protection of Proprietary Information memo, dated February 12, 2003 (see Appendix D). The Project Assistant is the primary control person, and the Systems Librarian is the secondary control person. The Project Assistant and the Systems Librarian will have keys to each others filing cabinets, and the Assistant to the Director will also have a set of keys. If a hard copy of a document is needed, please see one of these three people. At this time, these document collections do not include anything from the Directors Office or the Project Scientists office, although this may change in the future. 1.3. SYSTEMS CHANGE TRACKING LOG
The System Change Tracking Log (aka syschange log) is a method by which Systems Engineering will track changes made to the system design. It is meant to serve as a paper trail for inquiry and design conflict resolution purposes. Each week, the Systems Librarian will send an inquiry to all lead engineers asking about any changes to the baseline design made that week. That engineer, or the Systems Engineer (or both), will send a summary of these changes and any decisions reached to the syschange log, at syschange@nso.edu. The entries in this log will be sorted to the appropriate EPDM directory (see Section 6 for more about Enterprise PDMWorks) as date and time stamped files, entries will be made into the Systems Database (see below), and notifications will be sent to the Engineering Team that the logs have been updated. They will also be made available on the web site in the appropriate Project Book section. 1.4. SYSTEMS DATABASE
The Systems Librarian maintains a Systems Database in Access. This database is accessible by the staff, and includes status reports for: Interface Control Drawings Documents Systems Change Logs Other information tracked by Systems Engineering, such as staff publications, contracts, etc.
Page 3 of 25
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.
Page 4 of 25
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) and update the web site appropriately. Please DO NOT assign a number to a document yourself! Some document numbering examples are: 2.2. ATST Technical Note #2 (Project Document TN-0002) ATST Report #12 (Project Document RPT-0012) ATST Specification #1 (Project Document SPEC-0001) TYPES
Appendix A lists the current general document types. More will be defined as the project progresses. A note on type distinction: Reports will generally be used for scientific material, and Technical Notes will generally be used for engineering material. In addition, there are up to four major documents that may be written for each identified assembly: An Operational Concept Design Definition, which includes information on the philosophy and concept that underpins a subsystem, trade studies, meeting notes and presentations, etc. A Specification 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). Interface Control Documents, which detail the specific ways in which two systems interact with each other, including mechanics, electronics, software, and safety interfaces. (See Section 4 for more on interface control.) 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.
Design Review documentation should include the following information:
Page 5 of 25
Charge to the Committee Report of the Committee Project Response to the Report Review Materials List of Deliverables Presentation files Related and Reference Documents
2.2.1.
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. Referenced documents are non-Project documents (i.e. journal papers, conference proceedings) that are called by a document. Bibliographic information is provided, but not a copy of the referenced document. This type of document is usually used only in papers written for publication, e.g. SPIE papers. 2.3. TRACKING
While working on a document any kind of document the file should be kept in the EPDM vault; Enterprise PDMWorks 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 files 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.4). 2.4. 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, 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 vendors report; and a controlled private document a contract. Upon final approval of a document, the Systems Librarian will be notified by Enterprise PDMWorks and will carry through public or private distribution appropriately, by posting a copy in PDF format on the web site for public or private access. At this point, a PDF copy of the current revision of the file is also stored in the Released Documents Archive. 2.5. 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.
Page 6 of 25
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.5.1. Bibliographic Formats
For a description of Reference and Related Documents, please see Section 2.1.1. Reference (i.e. Non-Project) documents: this follows 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: this follows 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.6. REVISING A RELEASED DOCUMENT
See Section 4.4 for revisions to a controlled document. See Section 6.2 for revisions to an approved but non-controlled document (like a Technical Note). 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 documents Version History.) A file does not go up to the next revision letter until after it has been appropriately reviewed and approved (as outlined in Sections 4.4 and 6.2).
Page 7 of 25
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 B. 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 ATSTs 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. Enterprise PDMWorks will manage version and revision 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.sld* or 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 6). The appropriate manager will be notified by EPDM, 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\ATST Solidworks Library\Templates. 3.4. INTERFACE CONTROL DRAWINGS
See Section 4.2.
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.
Page 8 of 25
3.5.
REVISING A RELEASED DRAWING
See Section 4.4 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. The designer would lock the existing PDF file in the vault, then overwrite it with the new PDF file. This keeps the version history in Enterprise PDMWorks, and with the Released Drawings Archive there is always a PDF copy of the earlier version available as well.
Page 9 of 25
4.
4.1.
INTERFACE CONTROL
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 5). Current subsystems are listed in Appendix C. 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. 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.1. 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.
Some definitions taken from NASA Reference Publication 1370, Training Manual for Elements of Interface Definition and Control, January 1997.
*
Page 10 of 25
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 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.2. 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. 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. This is also handled by the EPDM workflow, which routes the file for review sequentially to the lead engineers. Both engineers 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.
Page 11 of 25
5.
5.1.
REVISIONS
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 Enterprise PDMWorks (see Section 6.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 Engineers discretion whether documents are sent on to the Project Manager or the Change Control Board (CCB) for further review and approval. Upon final approval, the Systems Librarian will put a PDF copy of the document in the Released Documents Archive. 5.2. 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. Once the file is resubmitted for approval, the CCB is notified and will discuss any issues that may arise. Only after the CCB has approved the changes 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 document in the Released Documents Archive. 5.3. 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). These forms 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.
Page 12 of 25
6.
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 section showing the 3.1 Instrument Lab Facility 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.
Page 13 of 25
7.
ENTERPRISE PDMWORKS
Enterprise PDMWorks is the electronic document management system in use at ATST. It provides an electronic vault for all documentation reports, SolidWorks files, 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. Enterprise PDMWorks 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.
Page 14 of 25
There is an online How-To page on the ATST Intranet with tips, tricks, information and help files for Enterprise PDMWorks. The Systems Librarian is also available to handle any questions or problems. 7.1. REVIEW AND RELEASE PROCEDURES
Enterprise PDMWorks 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 Enterprise PDMWorks 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 Enterprise PDMWorks on the ATST Intranet, which is constantly being updated with new information (including details about the workflow, below). 7.1.1. Workflow
Below is a graphical representation of the full ATST workflow.
Every file begins in the Initiated state. From there the option available to all staff is Submit for Review, and to lead engineers also Freeze; after that, the file will follow a different path depending on what type of file it is, 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 Systems Engineer is notified that the file is now waiting for systems approval; the Systems Engineer has the same options as stated earlier, 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 6.2 below), and a PDF copy is put in the Released Documents Archive.
Page 15 of 25
7.1.2.
Changing State via Transitions
To change a files 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. 7.2. REQUESTING REVISIONS TO A FILE
If the need arises to edit a file thats 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 Approval state while the Change Control Board reviews the changes (see Section 4.4). 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.
Page 16 of 25
APPENDIX A: DOCUMENT TYPE LISTING

At this time, the current document types are: Contractor Reports (CON) Drawings (DWG) Interface Control Documents (ICD) Project Management Control System (PMCS) Reports (RPT) Reviews (REV) Specifications (SPEC) Technical Notes (TN) Vendor Evaluations (VE)
Other document types will be specified as needed.
Page 17 of 25
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) 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
Page 18 of 25
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.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.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.5 Feed Optics 1.5.1 Transfer Optics 1.5.2 Coude' Optics 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 Wavefront Correction 2.1 Wavefront Correction - Coud (WFC-C)
Page 19 of 25
2.1.1 Adaptive Optics - Coud (AO-C) 2.1.2 Active Optics (aO) - Coud 2.1.3 Context Viewer 2.1.4 Common Items 2.1.5 Coud Tools and Equipment 2.3 Wavefront Correction Control System 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.4 Instrument Control System 3.1.5 Coud Environmental System 3.2 Visible Broadband Imager (VBI) 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 Cameras 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) Enclosure 5.1 Carousel 5.2 Carousel Drive System 5.4 Enclosure Thermal Systems 5.5 Ancillary Mechanical Equipment 5.6 Enclosure Control System 5.7 Enclosure GIS Interface 5.8 Enclosure Tools and Equipment Support Facilities and Buildings 6.1 Site Infrastructure 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 Building 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
Page 20 of 25
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 Facility Control System 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 Remote Operations Building (ROB) 7.1 Building (Lease) 7.2 Building Outfitting
Page 21 of 25
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 Purcell 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.
Page 22 of 25
Page 23 of 25
Page 24 of 25
APPENDIX E: CHANGE REQUEST FORM
Page 25 of 25

Project documentation specification #0002 Rev G

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Project documentation specification #0002 Rev G

Uploaded by

Copyright:

Available Formats

Project Documentation Specification #0002 Rev G

Document and Drawing Control Plan

Approved for release:

R. Hubbard Systems Engineer Original on file

4 May 2009 Date

Advanced Technology Solar Telescope Phone 520-318-8102

950 N. Cherry Avenue atst@nso.edu

Tucson, AZ 85719 Fax 520-318-8500

ATST Document and Drawing Control Plan

3. Date: Revision: Changes:

4. Date: Revision: Changes: 5. Date: Revision: Changes:

6. Date: Revision: Changes:

7. Date: Revision: Changes:

8. Date: Revision: Changes:

9. Date: Revision: Changes:

ATST SPEC-0002, Rev G

ATST Document and Drawing Control Plan

ATST SPEC-0002, Rev G

ATST Document and Drawing Control Plan

ATST SPEC-0002, Rev G

ATST Document and Drawing Control Plan

ATST SPEC-0002, Rev G

ATST Document and Drawing Control Plan

Business Documents Travel

Outcomes Documents Contractor reports Review materials Other documents as needed

ATST SPEC-0002, Rev G

ATST Document and Drawing Control Plan

ATST SPEC-0002, Rev G

ATST Document and Drawing Control Plan

Design Review documentation should include the following information:

ATST SPEC-0002, Rev G

ATST Document and Drawing Control Plan

ATST SPEC-0002, Rev G

ATST Document and Drawing Control Plan

ATST SPEC-0002, Rev G

ATST Document and Drawing Control Plan

See Section 4.2.

ATST SPEC-0002, Rev G

ATST Document and Drawing Control Plan

REVISING A RELEASED DRAWING

ATST SPEC-0002, Rev G

ATST Document and Drawing Control Plan

ATST SPEC-0002, Rev G

ATST Document and Drawing Control Plan

ATST SPEC-0002, Rev G

ATST Document and Drawing Control Plan

ATST SPEC-0002, Rev G

ATST Document and Drawing Control Plan

ATST SPEC-0002, Rev G

ATST Document and Drawing Control Plan

ATST SPEC-0002, Rev G

ATST Document and Drawing Control Plan

Below is a graphical representation of the full ATST workflow.

ATST SPEC-0002, Rev G

ATST Document and Drawing Control Plan

Changing State via Transitions

ATST SPEC-0002, Rev G

ATST Document and Drawing Control Plan

APPENDIX A: DOCUMENT TYPE LISTING

Other document types will be specified as needed.

ATST SPEC-0002, Rev G

ATST Document and Drawing Control Plan

APPENDIX B: DRAWING NUMBER BREAKDOWNS