SPIE Proceedings [SPIE SPIE Astronomical Telescopes + Instrumentation - Amsterdam, Netherlands...

Transitioning from Conceptual Design to Construction Performance Specification

Paul Jeffers*a, Mark Warnera, Simon Craiga, Robert Hubbarda, Heather Marshalla

aNational Solar Observatory / ATST, 950 N Cherry Avenue, Tucson, AZ, USA 85719.

ABSTRACT

On successful completion of a conceptual design review by a funding agency or customer, there is a transition phase before construction contracts can be placed. The nature of this transition phase depends on the Project’s approach to construction and the particular subsystem being considered.

There are generically two approaches; project retention of design authority and issuance of build to print contracts, or issuance of subsystem performance specifications with controlled interfaces.

This paper relates to the latter where a proof of concept (conceptual or reference design) is translated into performance based sub-system specifications for competitive tender. This translation is not a straightforward process and there are a number of different issues to consider in the process. This paper deals with primarily the Telescope mount and Enclosure subsystems.

The main subjects considered in this paper are:

• Typical status of design at Conceptual Design Review compared with the desired status of Specifications and Interface Control Documents at Request for Quotation.

• Options for capture and tracking of system requirements flow down from science / operating requirements and sub-system requirements, and functional requirements derived from reference design.

• Requirements that may come specifically from the contracting approach. • Methods for effective use of reference design work without compromising a performance based

specification. • Management of project team’s expectation relating to design. • Effects on cost estimates from reference design to actual.

This paper is based on experience and lessons learned through this process on both the VISTA and the ATST projects.

Keywords: ATST, VISTA, Telescope, Enclosure, Specification.

1 INTRODUCTION & CAVEAT The long journey from the start of a project to the point of successful allocation of construction funds is difficult and only a small number of telescope projects make it to this major milestone, herein referred to as conceptual design approval. In some ways this milestone of construction award funding is viewed as an end in itself, but there is then the reality of actually detailing and building that which has been demonstrated as conceptually possible. Projects generally follow one of two paths at this point: either build to print or performance specifications. The process for the build to print approach is relatively straightforward in that the project office fully develops the conceptual design through preliminary and final design stages prior to issuing contracts for manufacture and subsequent installation. The process following conceptual design for the project that chooses to use sub-system performance-based specifications is less straightforward. This paper is not about the pros and cons of these approaches but is focused on the transition from an approved conceptual design to issuing the sub-system performance specifications for competitive bid. This is not intended as an authoritative paper on the subject but is based on the authors’ experience on multiple telescope projects. The comments and conclusions draw upon the processes that worked well, but primarily are based on what could have implemented in a more effective manner.

*[email protected]; phone 1 520 318-8572; atst.nso.edu

Modeling, Systems Engineering, and Project Management for Astronomy V, edited by George Z. Angeli, Philippe Dierickx, Proc. of SPIE Vol. 8449, 84490B

© 2012 SPIE · CCC code: 0277-786X/12/$18 · doi: 10.1117/12.924501

Proc. of SPIE Vol. 8449 84490B-1

Downloaded From: http://proceedings.spiedigitallibrary.org/ on 04/08/2013 Terms of Use: http://spiedl.org/terms

An obvious place to begin is to look at the state of definition of the systems at conceptual design approval.

2 CONCEPTUAL DESIGN STATUS The purpose of the conceptual or reference design is primarily to:

- Demonstrate the technical feasibility of meeting science and functional requirements; - Produce credible cost estimates; - Produce a believable schedule; - Identify and develop interfaces between subsystems; - Determine performance and functional Specifications; and - Marketing.

These requirements are the main drivers of the level of detail to which the solution is taken during this phase. Figures 1, 2 and 3 show examples of different reference designs and their corresponding final performance based design. The Conceptual Design Stage was pivotal in the accomplishment of the VISTA (Visible and Infrared Survey Telescope for Astronomy, a 4-meter class IR Survey Telescope commissioned in 2009) project in two regards. The original ITT (invitation to Tender) was for a design and build contract. The UK Astronomy Technology Centre (ATC) did not feel confident in bidding the entire workspace and submitted an essentially non-compliant bid for a ‘Phase-A’ Conceptual Design and cost to completion. This revised contract was awarded and in the process of completion of this phase, the ATC developed the radical f/1 design that enabled the 4x4 IR detector focal plane. 2.1 Technical Feasibility

This is relatively self-explanatory and obvious. For example if the science requirements for the telescope necessitate a repeatable flexure in the telescope tube structure of 15μm over the full range of motion for the primary mirror cell, the reference design needs to demonstrate that this is possible. The level of analysis and detail in this technical feasibility demonstration directly affects the level of risk associated with the costs. If meeting the requirements depends on development of new technologies, the risk and contingencies on this aspect of the project need to be proportionally higher. 2.2 Cost Estimating

On telescopes as large and complex as ATST (Advanced Technology Solar Telescope, a 4-meter class Solar Telescope currently in progress), accurate and detailed cost estimates are vital to the project’s success. Funding agencies won’t consider the project ready unless accurate and defensible costs are produced for every single subsystem and area of the telescope. One of the chief means of producing these estimates is to base them on the reference design. On the ATST project, the initial reference design was used to produce cost estimates in three basic ways.

• The reference design was compared to the actual, as-built costs of similar telescopes and / or similar subsystems on other telescopes. For instance, the original ATST reference design assumed the use of hydrostatic bearings. The project used the general layout and size of the reference design bearing system as a basis of comparison to other large telescope project bearings (e.g., Gemini, Keck). The as-built bearing costs were then adjusted based on ATST’s unique requirements, and then assigned an initial place holder in the budget for bearings.

• Second, the ATST reference design was used for in-house, bottom-up cost estimates. For example, the 3d CAD model of the ATST mount design provided the engineers with weights and sizes of steel plates and members, lengths of welds, and the number of precision machined surfaces and critical interfaces. These then were used to calculate approximate costs, again based on historical prices paid for other large precision steel structures similar in size and complexity to the ATST design. While it was recognized that the future Contractor-designed mount for ATST would likely be significantly different in form and implementation, the approximate amount of steel needed and level of precision machining would be representative of the final design.

• Finally, a detailed reference design (and specification) can and should be used as a basis of discussion with potential contractors. This is required as a “sanity check” on the design and to identify potential cost drivers. These discussions improved later iterations of the concept design, supported requirements and error budget push-back, and informed separation of the design into subcontract packages, among other things. The ATST



project took this approach one step further and actually contracted with multiple companies to produce cost estimates and design feasibility studies for each major area of the project. These funded studies were based directly on the reference design.

2.3 Schedule Estimating

Without a developed design the estimation of the construction schedule carries high risk and can only be carried out in a top down approach by comparing the general size and complexity to other similar projects. This is usually not considered sufficient for conceptual design approval and a more detailed bottom up estimate of the off-site manufacturing and on-site construction is required. This is obviously based upon the reference design and approached in a similar way to cost estimating. The schedule is developed not only in house by the project, but also based on discussions with potential contractors, experienced scientists and engineers in the field. 2.4 Interfaces to Other Subsystems

A large, complex observatory that is constructed via multiple subcontracted work packages will result in an even larger number of complex, critical interfaces between these subsystems. Even relatively standalone items like an Enclosure will require a well-defined foundation/track interface, swept volume keep out envelopes, maintenance equipment requirements, and electrical and utility interfaces. More integrated subsystems, such as a telescope mount, may have dozens of these key interfaces to incorporate. The ATST telescope mount assembly, for instance, as 14 such interfaces, ranging from foundations and pier requirements, to optics and instrumentation mounts. Physical bolt patterns, allowable weights and volumes, deflections, electrical interfaces, optics through-path clearances, etc. all factor into these interfaces. The reference design serves the project as the basis for a) identifying; and b) defining each of these key interfaces. Appropriately for this phase, these are detailed ‘screen shots’ of the concept-level design sub-systems mating together. 2.5 Specifications

To meet the scientific goals set forth in science requirements documents, the various engineered subsystems of an observatory have to meet their own performance and functional requirements. These are set forth in the specification and / or design requirements documents. Prior to securing construction funding, the project may also be required to demonstrate readiness to start construction by having the specifications, Interface Control Documents (ICDs) and contract documents in an advanced state ready to issue Requests for Proposal. These contract documents, however, tend to be a lower priority compared to technical feasibility, cost, and schedule estimates, and as such are likely to be formed around specifics of the conceptual design. This means that the only solution that can meet the sub-system specifications and interfaces is the conceptual design itself, creating a circular logic both proving the feasibility and justifying the cost and schedule estimate.

2.6 Marketing

Engineers and scientists may bristle, but a well laid out three-dimensional reference design model, complete with realistic colors, surface finishes, and mountaintop backgrounds is indispensable to the marketing of a new project. This is particularly true during the transition from seed-money funded design studies to the fully-funded phase of a project. Said simply, brochures, posters, images, movies, and physical scale models of a reference design serve an important role in convincing non-technical funding personnel of the validity of feasibility and a project’s readiness to move forward. The reference design also serves as the basis of many of the images and pictures used in the actual proposal presented to a funding agency or potential contributing partners. Pictures truly are worth a thousand words (and millions of dollars) during this critical phase of a new project.



Figure 1a & 1b: ATST Concept Design and Performance Based Detailed Design

Figure 2a & 2b: VISTA Telescope Conceptual Design Model and As-Built Telescope



Figure 3a & 3b: ATST Enclosure Conceptual Design and Performance-Based Detailed Design

3 PERFORMANCE SPECIFICATION Although it may appear to reduce project momentum and challenge results of previously conducted trade studies, a main reason to use performance specifications is to optimize the potential for industry to propose cost-effective and technically suitable solutions to meet the sub-system requirements. To enable this, the specification and ICD requirements need to be performance-based not solution-based. Figure 4 shows an example of a performance rather than solution based requirement. In contrast to a requirement for a precise exterior enclosure shape, requirements for thermal performance along with a maximum envelope in conformance with environmental impact study and permitting requirements are given.

Figure 4: Enclosure Requirement 3.2-0090: The exterior shape, size, and configuration of the [Enclosure] Carousel shall be designed to minimize the number and sizes of surfaces that receive direct, near-normal incident insolation during sun-tracking operations. The Carousel shall conform to the shape, size and configuration presented in drawing ATST Enclosure General Arrangement.



There are areas that the particular solution in the concept design continue as implicit requirements, though they may be overlooked as ‘givens’ whilst in the midst of contractual document composition. This usually occurs due to:

• Interface requirements, e.g., optical path, allowable swept volumes of Mount and Enclosure; • Fundamental requirements solutions, e.g., type of mirror, site-specific requirements; and / or • Project-wide component standardization, e.g., safety interlock system all using one brand of hardware.

These areas need to be identified and care taken to ensure that the specifications explicitly reflect these solution-based requirements without unnecessarily limiting the design in other respects. Projects in the telescope industry have a relatively long gestation period considering the financial size of the projects, funding agency priorities, and wider political and economic realities. This has an effect on technological solutions which are available on the market for the project and can therefore affect the manner in which a proof of concept design is compiled; over time advances in technology are likely to provide new possibilities. Examples of this would be VISTA and ATST, wherein both concept designs used hydrostatic bearings as this was thought to be the only option available to meet the performance requirements. This solution choice was based on the experience of the project teams whose main experience had been on the William Herschel Telescope in La Palma, Spain and the Gemini Projects in Mauna Kea, Hawaii and Cerro Pachón, Chile. In the final implementation, VISTA utilized a very effective high-precision rolling-element bearing similar to a crane slewing ring bearing, based on the selected contractor’s previous experience. The ATST project, which has a telescope mount similar in scale to an 8-meter class due to its off-axis optical design, is utilizing a bearing truck-on-rail design, similar to that utilized in the large precision machine tool industry. In the last 5 years, this solution has come to replace hydrostatic bearings in that industry, and as such provided a timely alternative technical solution to meet the ATST requirements. In addition to the performance requirements which flow down from the science requirements, there are functional requirements that need to be clearly documented. These generally do not flow directly from the science requirements but are equally important in order to ensure an operable and useful the telescope. For example there should be access platforms and handling equipment such as cranes with sufficient load carrying capacity to ensure that various subsystems can be accessed and maintained. 3.1 Requirements capture and tracking

Performance Requirements such as pointing are flowed down from the science requirements, through the error budgets, and finally to the reference design. Functional requirements however are more likely to be inherently captured in the reference design as part of the conceptual design process in a less formal manner. For example cranes are a normal part of an enclosure design but are not necessarily called out in or directly traceable to the science requirements. Quite often the subsystem requirements or performance specifications are then derived from the combination of the reference design and the error budget / science requirements. This approach, which is shown in Figure5, works well during the conceptual design even though it does not follow the traditional systems engineering definition of systems decomposition.



b6LtOLUJ.

Figure 5: Requirements Flow down Conceptual Design to Subsystem Performance Specification.

Capturing and tracking of requirements, especially the functional requirements that are designed into the concept but do not direct flow down from the science requirements can be troublesome. Ideally there should be an intermediate stage during this transition or earlier where the top-level requirements are converted into systems level technical requirements as seen in the more traditional system engineering V-Diagram in Figure 6. This stage of the requirements de-composition was absent on both VISTA and ATST. Did this matter? Initially in terms of defining the sub-system performance specifications and ICDs it did not, as the conceptual design had already fleshed out most of these issues. An equally important function of all specifications is that of establishing the criteria for acceptance of that system or sub-system as fit for purpose. The V-Diagram has its shape to show the interdependency between each level of de-composition and the corresponding level of assembly, integration, and verification (AIV). Without a system level requirements document, how can the project demonstrate it meets the performance required as a system, and that the top-level science and operational requirements are achievable? In short, how do you know it is fit for purpose? Undoubtedly this can be achieved using the reverse of the process that produced the sub-system specifications, but this approach would be qualitative rather than quantitative and will very likely result in an extremely extended tail end to the AIV process. In VISTA the decision to site the telescope at Paranal and to be a fully integrated European Southern Observatory (ESO) facility made quantifiable verification necessary for acceptance. The only recourse was to backwards-engineer a ‘VISTA Technical Requirements’ document which was subject to iteration, review and sign-off by the Project, the Principal Investigator, and ESO before being recognized as the document that deliverables would be evaluated against. Fortunately this happened during the Conceptual Design stage so capturing these requirements did not occur too late in the process, and to some degree requirements effectively flowed down into the sub-system specifications, though the process flow was largely in reverse. With the ATST we are faced with a similar issue but much later in the project. Most sub-system contracts are now issued and we are beginning to develop a ‘Systems Technical Requirements’ document to meet the hole in system



2¿sugs(

Z0utAgt'

zj9llg3L(

Eu&iussuu&

2AarGUJ

pcuyIcs,

obcrsFio

gc!su

ycccb.cs:

Zbscq,c4

2a246Ú1

acceptance testing. Unlike in the ESO Organization, there is no demand for this particular document from the customer; in many ways the project team is embedded with the customer so it could be argued, and indeed has been, that this stage is unnecessary. To ensure this process adds value, the project is using the development of the technical specification as a method of confirming that all project requirements are captured and are verifiable.

System De‐com

position

Asse

mbl

y, In

tegr

atio

n an

d

Verif

icatio

n

Figure 6: ATST System Engineering V-Diagram

The normal process during the sub-system design phase for checking and tracking compliance with the sub-system requirements document is to maintain a compliance matrix. This matrix is quite often only initiated after the sub-system design contract has been placed. In hindsight a useful exercise to validate the sub-system performance specification and check for omissions is to create a compliance matrix from it and review the reference design for compliance. 3.2 Project Design Team unwritten requirements

As the project team proceeds past conceptual design approval and into subcontract detailing, typically with some staff turnover, a common refrain in the project office hallways is:

Project Team Member A: “What happened to the space for my widget? In the reference design it was there! Project Team Member B: “Is it in the ICD?” Project Team Member A: “No, but it was there in the reference design”

… and so on it goes! This is a major risk in the development process in that having lived with the reference design for so long there is an unspoken and subconscious certainty that the conceptual design will be built even though a performance specification



SM 2

SECTION A -ASCALE 1 : 30

has been issued. This can lead to oversights in the specification and other contract documents due to assumptions about the solution that will be selected to meet a certain requirement. An understanding of the evolution and path that the concept design has taken is extremely useful in identifying these types of unwritten assumed solutions in the design. An example of this from ATST is the conceptual design for Nasmyth instruments. There were a number of different optical / mechanical designs considered that allowed for a Nasmyth instrument. These designs changed as the design matured and also as the cost estimates informed what was feasible. In the design that was the basis for the funding approval, the solution did not have a Nasmyth optical pathway but did contain structure in the telescope mount that could be used to support the Nasmyth opto-mechanical elements as a future upgrade path. However as the Nasmyth instrument had been de-scoped there was no related ICD or specification to address this possibility. When the proposals were received and initial concept solutions looked quite different from the concept design, the question was raised “How do we adapt for the Nasmyth instrument?” The response was of course “What Nasmyth instrument?” Thorough review of the concept design development and clear communication of what is NOT included in the performance specifications helps to prevent these discussions after contracts have been signed.

4 INTERFACE CONTROL DOCUMENTS What is an ICD? An Interface Control Document at its basic level is a defined boundary between subsystems. Each subsystem usually has a number of these defined boundaries or ICDs that need to be considered. The manner in which these ‘boundaries’ are defined has almost as much effect on the subsystem design as does the specification with respect to defining the solution or leaving it open for options. The information that is normally required covers the component’s allowable volume, mass, and dynamic properties; its position in space; the manner of attachment and location and flavor of utilities supplied and / or demanded. When creating the ICD from the concept design it is temptingly easy to use the existing solution and fully define the interface based on specifics of the solution used on either side of the interface. A basic example of this solution-driven ICD is shown in Figure 7. This is an electronics rack mounted in the middle of the ATST Telescope Optical Support Structure.

Figure 7: ATST OSS Electronics Reference Design ICD

It takes time and thought to distill an ICD down so that it allows the detailed design contractors on either side as much flexibility as possible to adopt whatever solution best meets the requirements. The time to do this at the point of funding approval is seldom available and review committees rarely spend long looking at the endless list of ICDs. So, the work



uN

,1

1If

1200

1898

SECTION A-ASCALE 1: 30

xz KANE

of updating and distilling the ICD has to happen in the Transition period. In Figure 8 is a distilled, requirements driven version of the same ICD drawing.

Figure 8: ATST OSS Electronics Refined ICD.

The main differences are that the volume is defined as opposed to dimensioning the concept design. The position of the subsystem volume is defined in terms of the co-ordinate system rather than to structural features in the concept design. The attachment is reduced to a simplified mechanical connection without detail of the supporting structure that is separately defined in terms of deflection requirements as opposed to size and orientation of steel sections. Ultimately, the ICDs need to describe and bound the interface requirements, including some margin, while allowing other solutions for the subsystem rather than limiting to only the conceptual design solution. In some cases, it will be necessary to detail interfaces at a point further into the detailed design, for example the access platform provided by the enclosure for maintenance of the top end optical assembly could not be designed until the telescope truss system had been defined.

5 LEVERAGING THE CONCEPTUAL DESIGN WORK There has normally been a huge amount of preparatory work carried out in the conceptual phase; trade studies have been carried out and choices made in technologies. This work and the informed decisions that come from it are essential in compiling a realistic budget for funding approval. A temptation with a de-solutionized performance specification is to discard the benefit of the initial work and its prior consideration of numerous possible solutions. The dilemma of how best to leverage this excellent body of work needs to be addressed prior to seeking proposals. The prima facie answer is that project could provide the concept solution along with the performance specification, and then the contractor could adopt the conceptual solution. In this instance there is the distinct possibility that when the subtleties (read: difficulties) of implementing the requirements in a fully detailed and assembled system become apparent there could be contention about the ‘reasonableness’ of the specification when the concept solution does not perform. On the other hand, by looking objectively at the conceptual designs and analyses, a contractor can evaluate the different aspects of the design and use it as a guide to their approach. In doing so they may avoid initial developments that lead to dead ends.



Of course every project believes that their concept design will meet the requirements as they have typically spent multiple years studying, analyzing, and developing it. This belief in the concept can however limit the options that might be offered from industry which provide more technically- or cost-effective solutions. So how do you give the concept design to your potential contractors without giving it to them? The options seem to be:

- Give it directly to the winning bidder; - Give it to all potential or qualified bidders; or - Make it available through a release to the general public.

From the contractual point of view and based on experience the best option is to release the concept into the public domain. Further, the RFP package should make no reference to the concept design documents, even explicitly stating they are for reference only. This provides protection to the project from future concerns of the concept design’s ability to meet the requirements as it has not been referenced or provided directly to the contractor. It also provides potential contractors with a head start in considering and costing a proposal for contract; contractors may reuse as much or as little as appropriate for their level of experience and type of solution offered. The other main issue is what information the project releases. This depends not only on what is commercially confidential but also the level of development in the design and analysis. It is a good idea to consider whether the information to be released is coherent with the performance specification or whether there are discrepancies. If for instance your analysis document shows the concept design after 3 years of refinement has a first natural mode of 5Hz and you release a specification with a first natural mode requirement of 8 Hz – what message does this communicate? Generally this could be viewed by potential contractors as a soft ‘wished for’ requirement or goal and therefore promote the idea that all or parts of your specification can be treated as negotiable

6 REQUIREMENTS AND PROCESSES ORIGINATING FROM THE CONTRACTING APPROACH

An intended (or unintended) side effect of developing ICDs is that contracting packages are defined. There are several clear trades to be considered in the scoping of work packages. Ideally, interfaces should be as simple as possible; however, in large and complex projects there will certainly be large and complex interfaces. It must also be considered that there is an inverse relationship between number of potential subcontractors and scope of work packages. By creating larger and more technically complex work packages, the project is able to transfer risk to the contractor but pays a price to do so. Technically narrower work packages reduce total contract cost to the project, but increase internal manpower and coordination costs while also increasing the project risk in final integrated system performance. Inevitably, a problem that arises from the performance-based contracting approach is that after detailed design and analysis and presentation of alternative solutions, ICDs will need to be revised and some specifications may need to be addressed by waivers on non-compliance. At this juncture it is critical that ICDs and specifications have accurately captured the design intent, not the concept solution. In some cases revisions are unavoidable; for example, a change from hydrostatic to mechanical bearings in the telescope affects numerous other subsystem designs in that the hydrostatic oil pumps, coolant, and distribution systems became superfluous. The project must have in place a timely configuration review process in place to determine permissible change requests as well as dispensation on requests for waiver, particularly if solution-based or ‘goal’ requirements, not directly derived from science, operational, or maintenance requirements become design drivers. The contract documents, primarily the Statement of Work (SOW) must be structured according to both the nature of the work package in question, but also the contracting approach. These documents must establish clear contractual bounds for delivery, areas of project process mentioned above such as Change requests as well as progress reporting, review process etc. Although engineers do not generally view these as ‘requirements’ they are equally important for smooth execution of the contract. An example of this is the review process of the contractors design, the scope and depth of this review will be different for a build to print design versus a performance based contract. The projects requirements for review process should be documented and provided to prospective contractors at the proposal phase so this can be taken



into account This avoids later disagreements centered on different expectations regarding the design reviews. Contract documentation which has not been tailored appropriately to the contract method inevitably leaves the project in a weaker position when difficult issues arise. Another equally important part of the ‘requirements’ based on the contracting approach which must be addressed during the transition phase is the buildup in staff to manage these work packages. It is normal that after conceptual design approval the project team must grow to prepare for contract awards and also to manage the contracts. The skill sets and experience of the work package managers must be appropriate to whether the project approach is build to print or performance based specifications.

7 TRANSITION AND COST ESTIMATE Funding and manpower limitations inherent in the concept design development stage imply that not all subsystems can be fully engineered and analyzed. Engineers in small teams, operating on tight schedules with shoestring budgets must be ‘jacks-of-all-trades’ focused on addressing the highest risk areas from a system-level view. This necessarily reduces already scarce resources available to dedicate to detailed engineering analysis of every subsystem by every discipline. Consequently, the provision of a more technically developed conceptual design has the drawback that a highly detailed, though not fully engineered, solution may provide a high-precision but low-accuracy cost estimate. For example, an estimate of structure cost by tons of steel can be given with high confidence. However, if the concept structure has not been vetted according to all of site-specific seismic conditions, building code requirements, and scientific motion and dynamic requirements, the conceptual design steel mass may be underestimated. This problem can be mitigated using the three-pronged cost estimating approach described in Section 2.2, in particular the funded study approach. The time taken to get from conceptual design approval to signing design, fabrication, and construction contracts have a dramatic effect on approved budgets not only to due to known unknowns such as inflation and volatility in raw material prices, but also unknown unknowns such as macroeconomic labor market and economic conditions, entry / exit of potential subcontractors, and project staff turnover. All these factors create significant pressure to move quickly from the concept design approval milestone to signed contracts.

8 CONCLUSIONS As in all good conclusions this is just a recap of some of the ideas / processes highlighted in the body of the paper. In essence these are seen as the key items in streamlining the transition and beyond.

- Ensure that the project has a System Level Technical Specification prior to issuing the sub-system level specifications.

- Check that the reference design does comply with the sub-system specifications that are to be used in the construction phase or at least understand and document why they do not.

- Establish effective communication channels within the project and to contractors during both conceptual and detail design phases.

- Take the time to appropriately de-solutionize the subsystem specifications. - ICD’s which are presented as ‘snapshots’ of the reference design will lead to additional iterations during the

design process unless contractors are tied to the solution used in the areas surrounding the ICD. The work involved in separating the ICD’s from the reference design is paid back numerous times over during the following phases.

- Consider cost and schedule contingency for revision and completion of ICDs between performance-optimized subsystems, and establish contractual milestones for completion thereof.



9 ACKNOWLEDGMENTS The National Science Foundation (NSF) through the National Solar Observatory (NSO) funds the ATST Project. The NSO is operated under a cooperative agreement between the Association of Universities for Research in Astronomy, Inc. (AURA) and NSF. The ATST represents a collaboration of 20 plus institutions, reflecting a broad segment of the solar physics community. The NSO is the Principal Investigator (PI) institution, and the co-PI institutions are the High Altitude Observatory, New Jersey Institute of Technology’s Center for Solar Research, University of Hawai‘i’s Institute for Astronomy, and the University of Chicago Department of Astronomy and Astrophysics.



Date post:	08-Dec-2016
Category:	Documents
Upload:	heather
View:	212 times
Download:	0 times