Systems Engineering Implementation in the Preliminary Design Phase of the Giant Magellan Telescope

J. Maitena, M. Johnsa, G. Tranchoa, D. Sawyera, P. Madyb aGMTO Corporation, 251 S. Lake Avenue Suite 300, Pasadena, CA 91101;

bCognition Corporation, 213 Burlington Road, Suite 109Bedford, MA 01730-1468

ABSTRACT Like many telescope projects today, the 24.5-meter Giant Magellan Telescope (GMT) is truly a complex system. The primary and secondary mirrors of the GMT are segmented and actuated to support two operating modes: natural seeing and adaptive optics. GMT is a general-purpose telescope supporting multiple science instruments operated in those modes. GMT is a large, diverse collaboration and development includes geographically distributed teams. The need to implement good systems engineering processes for managing the development of systems like GMT becomes imperative. The management of the requirements flowdown from the science requirements to the component level requirements is an inherently difficult task in itself. The interfaces must also be negotiated so that the interactions between subsystems and assemblies are well defined and controlled. This paper will provide an overview of the systems engineering processes and tools implemented for the GMT project during the preliminary design phase. This will include requirements management, documentation and configuration control, interface development and technical risk management. Because of the complexity of the GMT system and the distributed team, using web-accessible tools for collaboration is vital. To accomplish this GMTO has selected three tools: Cognition Cockpit, Xerox Docushare, and Solidworks Enterprise Product Data Management (EPDM). Key to this is the use of Cockpit for managing and documenting the product tree, architecture, error budget, requirements, interfaces, and risks. Additionally, drawing management is accomplished using an EPDM vault. Docushare, a documentation and configuration management tool is used to manage workflow of documents and drawings for the GMT project. These tools electronically facilitate collaboration in real time, enabling the GMT team to track, trace and report on key project metrics and design parameters. Keywords: Giant Magellan Telescope, GMT, Systems Engineering

1. Introduction GMT is a 25-meter ground-based telescope being designed to conduct basic astronomical research at near UV through mid-infrared wavelengths. GMT will have both natural seeing and adaptive optics capabilities. A suite of instruments will be provided for imaging and spectroscopic capabilities at various wavelengths. The design, construction, and operation of the telescope is being undertaken by the GMTO Corporation consisting of an international group of educational and research organizations in the US, Korea, and Australia. The telescope will be installed at Las Campanas Observatory in Chile. The next generation of extremely large telescopes will all have segmented primary mirrors due to the difficulties of manufacturing and transporting mirrors larger than about 8 meters diameter. GMT is no exception. It is an alt-az telescope with a 7-segment primary mirror (M1) and 7-segment secondary mirror (M2) (See Figure 1). The six degrees of rigid body motion and the mirror figure of M1 are separately controllable by the Active Optics (AcO) System. The M2 segments are conjugated 1:1 with the M1 segments. Each segment has independent 6 DOF control for rigid body motion. There are two separate M2 mirror assemblies with the same optical prescription: a Fast Steering Mirror (FSM) and an Adaptive Secondary Mirror (ASM). The FSM consists of rigid monolithic segments with fast tip and tilt capabilities. It will be used as the commissioning secondary mirror and at times when the ASM is off the telescope for service. The ASM segments have a deformable front surface that provides wavefront control by the Adaptive Optics (AO) System. Each ASM segment has 672 actuators (4704 total). The ASM will be operated in both AO and natural seeing modes. The FSM and ASM assemblies are exchanged as separate complete top-end units. In addition to the two (2) segmented mirrors, there is a tertiary (M3) mirror (with tip, tilt and piston control) and (of course) the instruments.

Subsystems of the telescope, enclosure, and associated facilities are being designed both in the Pasadena Project Office and at member institutions and vendors widely distributed globally. Adaptive Optics development is also widely spread with teams in the U.S, Italy, Australia, and New Zealand. For example, the ASM is being designed in Italy by the group responsible for the MMT, LBT and VLT ASMs. The science instruments for GMT are all being developed at member institutions. The telescope and enclosure groups are also utilizing vendors around the globe for modeling, preliminary design, analysis, etc.

Due to the complex character of the GMT design and the geographically distributed project team and vendor network, highly developed systems engineering procedures and tools are vital for the success of the project. Key elements of this process include how information/configuration management is accomplished, how requirements are developed and managed, the development and management of interfaces and technical risk management. This paper describes the GMT Systems Engineering tools and procedures currently in place.

2. Systems Engineering and the Issues GMTO Systems Engineering (SE) is responsible for overseeing the overall design of the Observatory from the site leveling through commissioning. SE manages and maintains a Document Tree (See Figure 2) to identify all documents (requirements, plans, etc.) needed by the project. The Document Tree also shows how different documents interact with one another in terms of requirement and verification flow. SE also maintains an NxN matrix for the identification of interface documentation that is needed and is an essential part of the development of the major system ICDs. This is kept separate due to the sheer volume of documents that it defines. Additionally, SE chooses and configures the tools that will be used for document control, requirements capture and flow down, and definition of the ‘common language’ of the project. The ‘common language’ is the project glossary (or definitions) and the acronyms that are used within the project. Implementation of the tools directly impacts how the GMTO collaboration will work; without visibility into the project, the partners/vendors might misinterpret the meaning of requirements or the needs of the project. Development teams at GMT member institutions have access to the SE tools and are expected to utilize them in their portion of the work on the project. Systems Engineering (SE) has generated the System Level Requirements based on the GMT Science Requirements, GMT Operational Concept Document, GMT Safety Plan and the Detailed Science Case. These requirements, in turn, flowdown to the subsystem requirements. SE is accountable for their development and works with the teams to make sure that the flowdown is complete and accurate. This includes Image Quality (IQ) budgets, pointing, thermal, structural, environmental conditions, health and safety, etc.

! !Figure 1. GMT Telescope and Pier (left) and M1/M2 configuration (right)

The Product Breakdown for GMT lists all of the systems, subsystems, assemblies and components and follows the numbering system of the Project Work Breakdown Structure (WBS). The top level of the Product Breakdown is shown in Figure 3. GMT is comprised of these seven (8) systems. These are all managed at the project office but teams around the globe will do much of the work below this level. For example, the Adaptive Optics System breakdown is further developed in Figure 3. The ASM is being designed in ADS/Microgate (Italy), the Visible Wavefront Sensor (WFS) System in the Australia National University (ANU), Arcetri Observatory (Italy), University of Arizona (UA) and the project office, the GLAO at the UA and the project office, the Laser Guidestar Facility in ANU, the AO Realtime System in ANU and the project office, the Phasing System is Ball Aerospace (USA) and project office, On-Instrument WFS System is based at ANU, and the AO Calibration Facility is also based at the project office. The project office must manage the work of these teams while the teams themselves must collaborate in order to deliver a product, the Adaptive Optics System, which meets the requirements of the Observatory.

Figure 3. GMT Top Level Product Breakdown

Figure 2. GMT Document Tree showing the flow of requirements and verification

SE is also responsible for managing the technical risks of the project (with coordination on these with project management). One of the major risks to manage is poor collaboration, or communication. This could lead to schedule delays, cost increases or unknown or unresolved design issues. Time zone differences, which can impact efficiency, are one of the larger issues to overcome. The Project teams span seven time zones. There is only an hour or two working hours of overlap each day for joint telecom or Videocon meetings between some of the teams. Efficiently relaying information to and from remote teams and the procedures for actively interacting on development when the participants are so widely separated needs to be addressed. Typically, e-mail is used to send files back and forth as people write, make comments and edit them. Not only is this inefficient, it can be dangerous. The wrong file can easily be used due to mislabeling or misplacing thus slowing down the process of development. GMTO has adopted the approach of adopting document systems and requirements tools that are accessible to everyone on the project teams to address this problem.

3. TOOLS GMTO has chosen a set of necessary software tools to aid in the systems engineering and development of the GMT Observatory including Xerox Docushare1, Cognition Cockpit2 and Solidworks Enterprise Product Data Management3 (EPDM). These tools each have unique functions and are used jointly for documenting and controlling the design and requirements; archiving analysis, obsolete documents and legacy items; and sharing information (collaborating) with partners and vendors. Each of these tools is accessible through the internet in some manner and has been set up for as much ease of use as possible.

3.1. GMTO Document Management System Xerox Docushare, a document management tool (DMT), is the main repository for GMT documentation and its configuration control. DMT is accessible via a secure http site. There is also a client for PC users that can be installed allowing them to have a Windows Explorer feel to their interactions with DMT. The DMT client has the capability to upload multiple files at once, an added benefit that is not available with the web interface. At the top level of the GMTO DMT, the project has defined Workspaces for different types of documentation (See Figure 4 – right). Each Workspace has different access rights depending on the needs of the user and the permissions granted by the project. For example, the GMT Corporate Workspace is highly restricted as there is no need for the documentation there to be accessible by all GMT teams. The GMT Configuration Control Workspace is where all change requests (CR), problem reports (PR), waivers and risk management documentation is located. There are registers maintained for each of these types of configuration items with separate counters (for example, a change request could have the number GMT-SE-CR-0002). In the example given, the CR is a request from Systems Engineering. Each item has a collection containing all relevant information for the item. Open and closed items are tracked and arranged accordingly. As an item is completed and considered closed, it would move from the ‘Open’ collection to the ‘Closed’ collection. An important point here is that nothing is deleted. Even if an item is rejected or obsoleted for some reason, the documentation for that item will remain in the repository as part of the history of the Observatory. This is true for all Workspaces, but one of the most important aspects of configuration items. The Document Control Administration Workspace contains all of the registers (CRs, PRs, Waivers). One of the most important items available here is the Master Controlled Document List (MCDL) that is a list of documents issued numbers within the project (even to vendors). This list also tells the users where to find the document; it even gives the user a link to where it is either in DMT or the other tools. This list is managed in excel by the Documentation Specialist (DS). The access to this workspace is very limited to read-only for most of the project. 1 http://docushare.xerox.com/ 2 http://www.cognition.us/ 3 http://www.solidworks.com/sw/products/data-management-software-pdm.htm

The GMT Corporate and Management Workspaces contain documentation encompassing the business management and technical management of GMTO, respectively. These include request for the Founders Agreement, proposals, contracts, schedules, high level reviews, etc. Access to these areas, even for read-only access is severely limited due to the proprietary and sensitive nature of the documentation contained there. The GMT Library contains reference documents such as the industry standards that GMTO are using. It also houses all GMTO templates, forms and software users guides (such as those for DMT and Cockpit). GMT Library is also used to store legacy documentation. This is documentation from other projects that has been or might be useful as a reference and documentation that is from early in the life of the GMT project (Concept Design Review and earlier). Access to this workspace is granted to the entire GMTO Project Office team. The Workspace titled GMT Documents is the largest area of our DMT library. Each GMT group has a collection under their control (See Figure 5). Each of these collections is split into two sub-collections: Working Documents and Controlled Documents (See Figure 6). This is where the majority of files will be archived. Controlled documents are those released through the GMT Configuration Management (CM) process. These are accessible for anyone in the project to read but are not editable. The DS manages these items and, with the SE team, oversees the process of changing them (CR process) as laid out in the CM Plan. Controlled documents are only available in the form of PDFs in DMT. They can include plans, procedures, requirements documents, interface control documents, and drawings. Released 3-D models are not maintained in DMT due to their size and complexity (See the EPDM discussion below). The Working Documents collections are for each team’s use and can be organized in any number of ways. Figure 7 is an example of how Systems Engineering has used their Working area. Documents in these areas are uncontrolled (unreleased) or in work. Many of these documents will never receive GMT document numbers. They include technical notes and memos, analyses, working error budgets, collaborative documents (such as review presentations), etc. This area is also being used by many groups to store information about meetings that will/have been held. These collections contain agendas, presentations, minutes taken and action items when needed. This working area can have documents of any format used.

Figure 4. GMTO DMT site home page

The last, but definitely not least important Workspace, is GMT External. This is the collaborative space. Here, controls are strict. Each group can set up collections that are visible for certain outside vendors or partners to have access to. This allows both for GMTO sharing with vendors/partners and for vendors/partners to share with GMTO. The point here is that the external groups that have access can only see what GMTO wants or needs them to see. The external groups can make their software/documentation deliveries through these areas as well. The control of this area is very specific for each collection and, in reality; these are really virtual collections of areas that are really within the group’s collections so there are no duplicate files.

There are several important points in how the DMT has been set up for use at GMTO. It is very easy to be haphazard about how files are uploaded causing duplicates of the same file in the system. The DMT has revision capability that allows the user to upload a new revision of a document on top of an older version. This preserves the history of the file so that what was done earlier can be seen while keeping the newest documents ‘on top’ and therefore easily accessible. Another thing that is utilized is the metadata for a file, if the file is assigned a document number that is entered into the database. Periodically, the DS will scan to make sure the controlled documents are not duplicated in the system. For uncontrolled documents, GMTO has left it up to the users (or group leads) to patrol this but, by following the guidelines on uploading of file revisions that the project has set forth, searches in the system for the documents become much easier.

Figure 5. GMT Documents Collection

Figure 6. Telescope Group's Documents Collection

3.2. GMTO Requirements Management Tool Cognition Cockpit is a requirements management tool (RMT), but it can be used for much more. GMTO use of Cockpit will evolve over the lifetime of the project. Currently, GMTO is using it for requirements, interfaces, risks, product breakdown and more. See Figure 8 for a view of the RMT window.

3.2.1. Current Uses of the GMTO RMT Currently, GMT has organized the RMT to manage information that is relevant to all groups, such as the Project Glossary, Acronym list, Reference document list, and Product Breakdown Structure (PBS or product tree). See Figure 9 for the directory structure. The Documentation collection is broken down into several folders. The first is the GMT Architecture (See Figure 9 – left) that includes the list of reference documents, the Project Glossary and Acronyms, the Document Tree, the Product Tree Document and the GMT Architecture Document. The Project

Figure 7. Systems Engineering Working Documents Collection (as an example)

Figure 8. Document Structure as viewed in the GMTO RMT

Glossary and Acronyms define the GMT common language. The Product Tree Document is the full Product Breakdown Structure (PBS) from the top level down. In the GMTO RMT, the user can also view the PBS (seen at the bottom of Figure 9 –left) in a graphical format. The Reference Documents is a list of the internal and external documents being used as reference throughout the project and is derived from the MCDL. (It is not a published document by itself.) The GMT Architecture Document is descriptive documentation of the GMT Observatory, including functional and mechanical breakdowns. These documents give an overview of GMT and provide a quicker means of understanding the overall system to new users and a place for those who have been around longer to review other areas of the design.

The next set of information is the GMT Budgets. This houses error budgets and requirements allocations such as, Image Quality (Natural Seeing and Adaptive Optics), the Pointing, Efficiency, Power and Thermal budgets as well. This allows users to view the budgetary breakdowns in one location (versus distributed throughout the requirements documents) to help understand the overall system picture. The next collection is the Requirements Area (Figure 9 – center). This is broken down by level according to the Document Tree (See Figure 2). The Science Requirements Document (SRD) and Operations Concept Document (OCD) are in Level 1; though technically, the OCD informs the requirements but is not written as a requirements document itself. Level Two consists of the System Level Requirements and several Common Documents, including the Environments Document, Electrical Power and Grounding Requirements, GMT Compliance Codes and Standards, etc. Some of these documents are requirements documents and some are documents that give information in support of requirements. At Level 3 and below, documents are broken down into collections for each group, subsystem, assembly, and component (as the breakdown becomes more complete). Figure 9 (center) and Figure 10 (left) show the structure of a document in the RMT and that the user can see all levels down to the requirements (denoted by the icon with an “R”). In Figure 10, the default document view of a document in shown in RMT and looks like the document would when exported for printing or release. In Figure 11, the view is one defined by GMTO and is designed for ease of use for creating new requirements, editing ones that already exist and seeing the relationship between parent and child requirements. There are several other views (as can be seen at the top of the left side window of Figures 10 and 11) that simplify the creation of links between parent and child requirements and assigning verification details (such as location, level and method). The concept of view definitions is extremely useful because it allows GMT to create requirements, define the various properties of the requirements, and create traceability to child requirements, its associated risks and tests without having to remember to run a command. The view definitions have been custom defined by GMT making it fit and adapt to the GMT information workflow process rather than having to adopt an alien process to fit the needs of the tool.

Figure 9. Cognition Cockpit GMTO Implementation (Directory Structure)

There are a number of characteristics that are possible to specify for requirements in RMT. Some of these have been included in the “Define Requirements” view; others must be specified on the requirements home page (See Figure 12). Parent and child relationships can be formed with links much like other Requirements Management Tools. Interacting requirements can also be linked to one another. This can be important to understand how even a small change can sometimes ripple through the entire project. Any rationale needs to be specified and is shown in the views in Figures 11 and 12.

In the RMT, another advantage is the capability to specify the type of requirement of which there are four (4) choices: Pass/Fail, Numeric, Text, and Date. The majority of GMT requirements will be of type Pass/Fail or Numeric.

Figure 10. GMTO Requirements Document Structure and Default View in the GMTO RMT

Figure 11. User View for defining, reviewing and editing requirements.

Specifying a requirement type as numeric is seen to be advantageous when the flow down of high-level requirements is quantified by transfer functions. The transfer functions facilitate the roll up of nominal and variation values allowing the RMT to compute and report the satisfaction of a requirement using statistical metrics. This numerical analysis allows the GMT team to do predictive design engineering helping by tracking the progress of NUD (i.e. New, Unique or Difficult) requirements as to when they are complete because the satisfaction becomes apparent. The satisfaction metrics of a requirement are also color-coded, marking requirements (icons) that are satisfied and complete as green, the requirements that are incomplete as grey, the ones that are not satisfied as yellow or red depending on the value of the satisfaction metric and the requirements that are overdesigned as blue. For instance, the SRD specifies a certain image quality of the telescope. This breaks down into system level requirements further flowing down into all of the subsystems. For each of these child requirements, when they are made numeric and quantified by transfer function models using formulae from first engineering principles or Matlab or MS Excel models, the RMT is able to calculate and rollup nominal and variation values. Then, the RMT will calculate the design, short or long term process values of the SRD requirement. By comparing the design (process or test values) against the required target value of the SRD, the RMT computes and reports back on how well the SRD requirement has been satisfied (See Figure 12 – Satisfaction “meter”). Using the requirements home page, design values can be entered as well tested values later on to determine how well the requirement is being satisfied.

The Interface Control Documents (ICDs) collection (Figure 9 – right) is broken down by group owned; this is determined by to whom the item is delivered (or installed). Therefore, the Telescope group owns the vast majority of ICDs. GMT has made a decision that every interface drawing will have a wrap around document and that ICDs are to be written at the lowest feasible level to keep them manageable. Though it is not seen in Figures 8 or 9, The RMT can also be used for Risk Management (RM). Requirements in the GMTO RMT are very tightly integrated to their associated risks (failure modes). Just as requirements can be flowed down into subsystem, subassembly and component requirements, the risks in the RMT can be flowed down to their causes and eventually their mitigations. The control requirements are defined to realize mitigation feed back into the requirement flow down. The integrated, unified data model of the Cockpit facilitates all aspects of risk management such as Fault Tree Analysis, Design and Process, FMEA Analysis, and Hazard Analysis. The RMT has custom defined

Figure 12. A requirement's home page showing all the characteristics of the requirement.

severity and probably of occurrence settings. In addition, GMTO has also defined the way in which risk scores are calculated using a simple calculation method (Likelihood*Probability) or using “look-up tables”. GMTO is using a Likelihood/Probability risk scoring method. The RMT uses the GMTO definitions to color code the risks as red, yellow and green depending on the risk score thresholds. In the case of GMTO, the Risk Management is being done in a separate project from the development of requirements due to the proprietary nature of some of the issues. GMTO uses the Cockpit’s capability to define the risks, identify one or more causes of the risks and eventually articulate their mitigations using predefined out of the box FMEA templates and in some cases using a proprietary risk template that GMTO has created (according to the GMTO Risk Management Plan) and stored as an additional template in the RMT. The top risks are reported out along with their possible mitigation actions for the project management to review and update at regular intervals. When control requirements are defined for the mitigations of the high level risks, these are linked back to the different subsystems, assemblies and components giving the team a clear traceability to the high level program risks and the control requirements that are in place in order to mitigate them. Action Items are a very useful tool in the RMT. They can be used on any container or object. GMTO uses Action Items when reviewing and editing documents collaboratively (See Figure 11). For instance, while developing the SLR, there were inputs from many of our team leads and within our own SE team. Placing an action item for someone on a section or requirement within the document gave the user the specifics that were needed to help complete the requirements successfully. With every team having access to work in the areas that their team needs to in the RMT, documents can be edited and reviewed by all of the teams at any time. The collection called Project Status Reports (Figure 9 – left) is an area for information gathered from documents within the RMT. For instance, a report can be generated for each document that tells the user how many requirements are in the document, how many have defined targets, rationales, verification methods, etc. These statistics can give a the SE and Project Management team a good idea of how the requirements development is going and where work needs to be focused to move the design in the right direction. Later, reports will be created to show requirement satisfaction and where appropriate the design or test values. View Definitions define the different documents views that are being used in a document, such as ‘Define Requirements’. The Templates collection holds all of the document templates (structures) that are being used in the GMTO RMT for various document types. The TEMP collection is a temporary directory that is used to upload tables that have certain properties. The final item in the RMT directory is the Product Breakdown Structure, seen in Figure 9 (left). The RMT provides a graphical view for entering and reviewing the GMT PBS. In Figure 13, the PBS for the Adaptive Optics is shown as an example. This type of breakdown exists for each system. One thing to note is that this PBS is not complete and will continue to evolve. The GMTO RMT is where working versions of requirements documents and ICDs exist and are updated. The released versions are exported, signed off by the appropriate authorities and placed in a controlled collection in the Document Management Tool.

3.2.2. Future Requirements in the RMT are tightly integrated with tests. Tests contain the information about setup, test execution instructions and test results. The RMT allows GMTO to define project level milestones (or test runs) and even test specific milestones. A unique feature of the RMT allows storage of test results for every test run or milestone. Test results are reported out for the project team and management at regular intervals to determine how many requirements have failed their tests (and hence need to be tested again), how many requirements have passed their tests, how requirements have no tests defined or have incomplete tests, etc. This gives the project team a clear picture as to the stability of their requirements and the test results trends when nearing a milestone completion.

As the project progresses, GMT will be used to identify and develop test definitions and procedures within The RMT and link the tests and the results to the requirements to show the satisfaction of the requirements. This will allow verification to be tracked via reports created in The RMT, working up from the lowest levels to the highest (Figure 2).

3.3. GMTO CAD Management Tool GMTO has chosen Solidworks EPDM to be its’ CAD Management Tool (CMT) for configuration management of technical CAD documentation and is currently in the process of implementing the server, configuring the CMT structure, and defining the workflows. Because GMTO uses SolidWorks for in-house mechanical design, EPDM was a natural choice for an integrated solution. In addition, EPDM offered two key functional attributes that are essential for our application. First, EPDM supports replicated servers at geographically different locations so that configuration control of drawings that are being developed along with external collaborators can be maintained. The replicated sites allow remote locations to efficiently access and edit drawings without the inconveniences of network delays and outages. It eliminates the overhead of manually transferring files, provides the functionality and convenience of being on-site, and eliminates the risk of losing revision control.

Second, EPDM allows multiple workflows to be developed within a single vault [an instance of the CMT]. At GMTO, different workflows are being implemented depending on whether the technical documents are internally developed CAD files that are revision controlled by GMTO; externally developed CAD files that are delivered as a product and not revision controlled by GMTO; or technical documents that are not CAD files (e.g. datasheets). Each of these workflows enforces a different level of configuration control that is commensurate with the type of technical document that is being managed. Access to the CMT is through Windows Explorer on the users machine, it is a client that logs into the CMT server. So, the CMT has the feel of being another folder on the user’s computer. Figure 14 shows the view that a logged in user will see before entering any of the collections. A web client for remote access is also available.

Figure 13. Adaptive Optics PBS from RMT

The GMTO CMT is comprised of four (4) directories. Each one serves a different purpose. The GMT collection houses working documents broken down by PBS (See Figure 15). It will also contain files received from or uploaded by partners and vendors. By breaking down the system by PBS, the user is given a logical method of finding (and placing) work in the CMT.

The Legacy collection is to be used similarly to the collection of the same name in the Document Management Tool (DMT). All old drawings (dating as far back as are still available) will be housed here. These files may or may not be eventually incorporated into the current design. If a file does get incorporated, a copy will be generated and placed in the GMT collection and that file will be used as the basis for further development. This will preserve the project history.

The Library folder will house the Solidworks toolbox that GMTO chooses. These are things like material properties, finishes, and etcetera. Also, the Library will hold any hardware models that are received from vendors such as McMaster-Carr for things like pins, washers, nuts, bolts, and etcetera. The Published collection is only for the Documentation Specialist’s use. It is a portal for releasing drawings and placing them in the correct controlled collection in the DMT. The Templates collection houses the Solidworks templates that have been defined for the GMT project’s use.

Figure 15. CMT Sub-Directory View

Figure 14. Windows Explorer view of GMTO CMT directory.

The CMT allows the user to see a lot of information about the files before ever opening them in Solidworks. As seen in Figure 16, for each file, the user can see in the directory area whether the file is checked out and by whom, the state of the file, the date it was last modified, the part number and the revision. There is also a description field. By looking at the icon of the file, the user can tell if it is a CAD model, assembly, drawing or part. In the Preview window, the user can see the file in e-drawings (a simple viewer) along with the information about the file (on the right). The Bill of Materials can be viewed, as well as other files in the model and where it is used in the system. This gives the user quick access to information without the overhead of opening the file.

The CMT controls the use of the files by requiring a file to be checked out by a user for modification and it will show others that the file is checked out so that two users cannot edit the same file at the same time. When a file is checked out, another user can view it but not edit. When the user is done with their modifications or it is time to go home for the day, then the file is checked back in to the system (without changing its state) and saved for later use or for someone at another location to continue work on. Workflows are being established for drawing/model development, review and sign off. Signed-off drawings are turned into PDFs and stored in the controlled collections of the GMT DMT. As can be seen in Figures 15, and 16, a file that is released shows this in its “State”. Due to the size of 3-D models, they will remain in the CMT exclusively. GMTO is implementing several workflows to deal with the different types of files that will be received from outside sources as well as our internal files.

4. Getting Ahead of the Problem GMT is organized around a centralized but relatively small project office that directs and coordinates the work of a number of dispersed project teams and consultants. Good communication tools are essential to manage this effort. There is always the risk that a team may not communicate the dependencies of its designs (and their changes from baseline) to the others. This is where good Systems Engineering procedures for configuration management and change control are crucial. Once requirements are defined and flowed down, a baseline design is agreed upon, and interfaces defined and drawings released even a seemingly small change in one aspect of the design may ripple across groups. Understanding how one item interacts with another with the help of linking, helps us keep track of interdependencies and perform the trade studies that are needed to be certain that the impacts of changes are agreeable to all parties affected. Understanding how each subassembly interacts with the rest of the system and managing changes across the project helps avoid incompatibilities and ensures the project can achieve its system performance requirements.

Figure 16. GMTO CMT Preview Screen

The project is addressing this issue through its selection of system engineering tools and procedures. The tools that have been established for GMTO are accessible to all of our partners and vendors as needed through web access. This allows a higher level of collaboration. Through the Document Management Tool (DMT), teams can share files of any size. It is also possible to tightly control access to files, which is important when the information contained is proprietary, procurement sensitive, or preliminary material prior to release. Using the Requirements Management Tool (RMT), work on architecture, requirements, risks and interfaces can be reviewed and edited in a timely manner and dependencies can be seen easily. The GMTO CAD Management Tool (CMT) also allows timely editing and review of files by the internal and remote team members using the workflow controls built into the system. Eventually, some of our distributed teams will create mirror sites for the CMT synchronized with the main site at the GMTO Project Office on a regular schedule. Until then, remote sites will be set up with web client access to the CMT. All users will enter their requirements and ICDs into the RMT so that items that need linking can be and dependencies can be established and understood by all. Throughout the development process, it is important to be able to pass information (requirements, interfaces, changes, designs, etc.) back and forth efficiently with the remote teams. The tools that we have selected allow us a high degree of flexibility and openness, allowing communication to flow more smoothly and at the same time ensure that the system configuration is preserved. Having the level of information available to the external team members, GMTO enables them to truly understand the entire concept and design and fully participate in the project. Also, by opening up the tools to the external teams, GMTO allows them and itself to respond to questions, issues, concerns, requests, etc. more agilely. These procedures for information and configuration management are essential for the operation of a distributed engineering effort such as GMT.

Acknowledgements This material is based in part upon work supported by AURA through the National Science Foundation under Scientific Program Order No. 10 as issued for support of the Giant Segmented Mirror Telescope for the United States Astronomical Community, in accordance with Proposal No. AST-0443999 submitted by AURA.

References [1] Johns, M. (2011, July 17), GMTO Systems Engineering Management Plan. GMT-SE-DOC-00002, GMTO

Corporation. [2] Maiten, J, (2012, March 12), GMTO Document Tree. GMT-SE-DOC-00009, GMTO Corporation. [3] Maiten, J., Trancho, G., (2012, January 25), GMT Product Tree. GMT-SE-DOC-00023, (GMTO Corporation. [4] Maiten, J. (2012, April 23), GMTO Information and Configuration Management Plan. GMT-SE-DOC-00003,

GMTO Corporation. [5] Raybould, K. (2011, July 19), GMTO Risk Management Plan. GMT-PM-DOC-00111, GMTO Corporation. [6] Trancho, G., Espeland, B., Bouchez, A., Conan, R., Hinz, P., and van Dam, M. “GMT AO System Requirements

and Error Budgets in the Preliminary Design Phase,” SPIE Proc. 8447-202 (2012).