SEER-H Space Guidance

Transcription

1 SEER-H Space Guidance Revision 2.0 April 25, 2016

2 Table of Contents 1. Introduction 2. Mapping SEER to NASA WBS 2.1. NASA Work Breakdown Structure 3. Starting a New Project 4. Project Structure in SEER 4.1. Building Structure 4.2. Complete Mission 4.3. Instrument-only Mission 5. Capturing System Level Costs 5.1. SLC for Complete Mission Mission Level Instruments Under Payload Level Spacecraft Bus Level 5.2. SEER Costs Mapping to NASA WBS for Complete Mission 5.3. SLC for Instrument-only Mission Mission Level Instruments Under Payload Level 5.4. SEER Costs Mapping to NASA WBS for Instrument-only Mission 5.5. Adjusting SLC 5.6. SLC Setup Differences between Complete Mission and Instrument-only Mission 5.7. SLC Application KBs 6. Heritage and Technology Readiness Level 7. Acquisition Category Knowledge Base 7.1. Determining an Element s Acquisition Category 7.2. Acquisition Categories 7.3. Specific Acquisition Category Recommendations 8. Risks 8.1. Risks in SEER 9. General Modeling 9.1. Sources of Information 9.2. Level of Element Modeling 9.3. SEER Three Point Input Distribution 9.4. Flight Units, Flight Spares, Engineering Models, and Protoflights 9.5. Modeling for Multiple (Identical) Spacecraft 9.6. Guidance by Element Type Mechanical Element Type Weight Material Composition Electronics Element Type Total Printed Circuit Board EOS Element Types EOS Optical Device Element Type Reflective Telescope, Refractive Telescope, and Optical Bench Reflective Telescope Standard versus Lightweight With or Without Scan Mirror Refractive Telescope Optical Bench Modeling Spares for Optical Elements Custom Integrated Circuit Element IC Element Structural Modeling Recommendations FPGA Modeling Guidance Side note on FPGAs 9.7. Contributed Hardware and Government Furnished Equipment GFE/Contribution can be modeled GFE/Contribution cannot be modeled but the cost is known 9.8. Common Parameters to Consider Design Complexity Certification Level / Reliability Standard 10. Modeling Instruments Instrument Modeling Discussion Instrument and Instrument Suites Instrument Examples Direct-sensing Instruments Field Instruments Mass Spectrometer Remote-sensing Instruments

3 Imager LIDAR or Laser Altimeter Radar Other Optical Processing 11. Modeling Spacecraft Spacecraft Modeling Discussion Spacecraft and Heritage Common Parameters Guidance for Spacecraft Design Complexity Other Parameters Guidance for Spacecraft Material Composition Clock Speed Specific Guidance by Spacecraft Subsystems Structures and Mechanisms Spacecraft Structure application KB Thermal Thermal application KBs Electrical Power & Distribution Attitude Determination and Control Attitude Determination and Control application KBs Propulsion Chemical Propulsion System Electric Propulsion System Space Propulsion Component application KB Communications Clock Speed Parameter Space RF Component application KB Command & Data Handling 12. Cubesat Modeling CubeSats Acquisition Category Parameters Certification Level / Reliability Standard Production Tools and Practices Production Learning Curve Element Types and Application KBs Mechanical/Structural Element Type Electronic Element Type EOS Element Types System Level Cost for CubeSats

4 1 Introduction This document was prepared to assist users in the cost modeling of space systems using the SEER product suite: SEER- H, SEER-SEM, SEER-IC, and SEER-EOS. The information which constitutes this document has been developed and created through modeling and the validation of hundreds of space systems of many types. This document also includes the practical knowledge of the Galorath staff with many years of experience in working with space projects. Most recently, this guidance has been enhanced through the efforts of various NASA-sponsored validation studies. These workshops have helped validate many of the modeling approaches as well as enhanced the current model and modeling practices. However, judgement should still be exercised when modeling to ensure that the recommendations are appropriate. This guidance will help to support a standardized approach in using SEER models for space projects. As the SEER tools have grown over the years in capability and features, the tools ability to model various situations has also evolved. Since the SEER products are component-level models, they are typically used to model at a low level of detail. The ability to model and characterize an element at such a detail provides much benefit as it allows the user to capture an element as closely as possible. However, this also means that more care needs to be exercised in handling all the inputs employed in SEER. The model includes many features to help the user in managing the many inputs. It includes knowledge bases which are element level parameter templates and many other supplementary files which can be found in the tool folder in the SEER directory. This guidance pulls together various areas of consideration when modeling space systems in order to aid the user follow a standard approach. It is meant to work in conjunction with the existing SEER help. This document is dynamic as it will continue to evolve as Galorath continues to gather more knowledge and feedback from the field. For better support and configuration control, the most current version of this document will be kept online with NASA Cost Analysis Division website, Galorath website, etc. This document will also reside in the SEER-H model. The models will include the latest available version at the time of model release major or maintenance release. It is recommended that the user go to the website to confirm that the latest version of this document is being used. Over time, many recommendations will change minimally or significantly based on an expanded set of data points and insight into the various space technologies. Modeling with a standardized approach will help to convey a cost picture properly to management, customers, or anyone else that receives an estimate. Note that this standardized guidance is also being used by both proposing and government entities. This document will help to ensure that the communication of cost between various entities is clear, consistent, and less subjective. This is valuable for all involved since it will help users convey the cost realism of their position and for customers to be able to better understand that position. Since many users determine their own model error bounds, it is important to use the models in a standardized manner to optimize model performance and clarity.

5 2 Mapping SEER to NASA WBS 2.1 NASA Work Breakdown Structure Figure 2.1 NASA Work Breakdown Structure Overview The NASA Space Flight Standard Work Breakdown Structure (WBS) has six elements in which SEER estimates. Figure 2.1 highlights the six elements. The following definitions is provided by NASA Procedural Requirements (NPR) , Appendix G and can be found in the NASA Work Breakdown Structure Handbook: WBS 01 Project Management (PM): The business and administrative planning, organizing, directing, coordinating, analyzing, controlling, and approval processes used to accomplish overall project objectives, which are not associated with specific hardware or software elements. This element includes project reviews and documentation, non-project owned facilities, and project reserves. It excludes costs associated with technical planning and management and delivery of engineering, hardware and software. WBS 02 Systems Engineering (SE): The technical and management efforts of directing and controlling an integrated engineering effort for the project. This element includes the efforts to define the project space flight vehicle(s) and ground system, conducting trade studies, the integrated planning and control of the technical program efforts of design engineering, software engineering, specialty engineering, system architecture development and integrated test planning, system requirements writing, configuration control, technical oversight, control and monitoring of the technical program, and risk management activities. Documentation products include requirements documents, Interface Control Documents (ICD), Risk Management Plan, and master Verification and Validation (V&V) plan. Excludes any design engineering costs. WBS 03 Safety & Mission Assurance (SMA): The technical and management efforts of directing and controlling the safety and mission assurance elements of the project. This element includes design, development, review, and verification of practices and procedures and mission success criteria intended to assure that the delivered spacecraft, ground systems, mission operations, and payload(s) meet performance requirements and function for their intended lifetimes. This element excludes mission and product assurance efforts directed at partners and subcontractors other than a review/oversight function.

6 WBS 05 Payload: This element includes the special-purpose equipment and normal equipment, e.g., Ground Support Equipment (GSE), integral to the spacecraft. This includes managing, and implementing the hardware and software payloads that perform the scientific experimental and data- gathering functions on board the spacecraft, as well as the technology demonstration for the mission. WBS 06 Spacecraft: The spacecraft that serves as the platform for carrying payload(s), instrument(s), humans, and other mission-oriented equipment in space to the mission destination(s) to achieve the mission objectives. The spacecraft may be a single spacecraft or multiple spacecraft/modules (i.e., cruise stage, orbiter, lander, or rover modules). Each spacecraft/module of the system includes the following subsystems, as appropriate: Crew, Power, Command & Data Handling, Telecommunications, Mechanical, Thermal, Propulsion, Guidance Navigation and Control, Wiring Harness, and Flight Software. This element also includes all design, development, production, assembly, test efforts, and associated GSE to deliver the completed system for integration with the launch vehicle and payload. This element does not include integration and test with payloads and other project systems. WBS 10 Systems Integration & Testing (I&T): This element includes the hardware, software, procedures, and projectowned facilities required to perform the integration and testing of the project's systems, payloads, spacecraft, launch vehicle/services, and mission operations.

7 3 Starting a New Project Before you begin your project, the top level settings for the project must be defined. Otherwise, the results of SEER estimates can be misleading relative to project requirements or other project estimates. For instance, set the project parameters to reflect the project base year, inflation rates, standard unit of measurement, etc. See Help for descriptions on these settings. The project parameters can be set in the Set Project Parameters under the Options menu. Note that when using a certain unit of measure, ensure that the repository matches. The repository can be selected in the Maintain Knowledge Bases under the Tools menu.

8 4 Project Structure in SEER 4.1 Building Structure The structure of a SEER project is completely up to the user's discretion. However, a logical and standardized approach in structuring the model will make the process of creating an estimate more organized and clear. The following points are general tips for creating an effective SEER project. SEER models should have a logical WBS structure. Use rollups to organize the project by significant assemblies and/or organizations. This allows the model to be clearly understood by the user and those reviewing the file. If possible, do not model your elements under a single rollup. Placing all elements under a single rollup creates a chaotic view of the project and will probably not represent the project s key assemblies or subsystems. Using a single rollup will also make the model much more difficult for the cost modelers and reviewers to comprehend. Note all ground rules, assumptions, and sources of data using SEER s element and parameter note features. This will allow the user and reviewer to understand the cost model and supporting documents. This will also help to remove any confusion and misunderstanding. This is especially important when calibrating the model, as there needs to be a concrete basis for doing calibration. Generally, when working with space missions, there are two types of structure setup in SEER. SEER designates these two types of missions as 1) complete mission and 2) instrument-only mission. The structure is based NASA WBS 05 and WBS 06 which are the payload and the spacecraft bus, respectively. The payload contains the one or more instruments. The spacecraft bus contains, at most, seven subsystems: structures & mechanisms, thermal, electrical power and distribution, propulsion (utilized depending on mission), attitude determination and control, communications, command and data handling. Additionally, WBS 01, 02, 03, and 10, which are the project management, systems engineering, safety & mission assurance, and system integration & testing, respectively, are captured at the mission level using SEER s SLC parameters. 4.2 Complete Mission Figure 4.1 SEER Complete Mission Model Structure The first structure type is a Complete Mission, which includes a payload and a spacecraft bus level. The Work Breakdown Structure (WBS) for a Complete Mission has three main levels: the mission level (1.1), the payload level (1.1.1), and the spacecraft

9 bus level (1.1.2). The payload level includes one ( ) or more instruments ( , N). The spacecraft bus level includes the structure & mechanisms ( ), thermal ( ), electrical power & distribution ( ), propulsion (situational) ( ), attitude determination & control ( ), communications ( ), and command & data handling ( ) subsystems. Figure 4.1 shows the basic structure for a complete mission which can be used as the starting point to build the WBS. 4.3 Instrument-only Mission Figure 4.2 SEER Instrument-only Mission Model Structure The other structure type is an Instrument-only Mission in which the mission proposed only includes the payload. These are types of missions in which a mission s payload is hoisted onto a host spacecraft rather than onto its own individual spacecraft. The Work Breakdown Structure (WBS) for an Instrument-only Mission has two main levels: the mission level (1.1) and the payload level (1.1.1). The payload level includes one ( ) or more instruments ( , N). In most cases, an Instrument-only Mission only has one instrument ( ). However, if more than one instrument is included in the payload, then a new instrument level (1.1.1.N) under the payload level should be created. Figure 4.2 shows the basic structure for an Instrument-only Mission which can be used as the starting point to build the WBS.

10 5 Capturing System Level Costs The System Level Costs (SLC) are activated in SEER to capture the overhead of a project or mission at the various levels. The activation of SLC is indicated by the yellow icon of a rollup element. See Figure 4.1 and 4.2 in Project Structure in SEER section. The setup in Figure 4.1 and 4.2 are SEER recommendations when setting up the SLC. This setup reflects overhead at the project or mission level, payload level, and spacecraft level. Note that this setup is based on the two space mission structures types described: complete mission and instrument-only mission. 5.1 SLC for Complete Mission SEER s SLC for a Complete Mission are activated at three levels: the mission level (1.1), the instrument level (1.1.1.N), and the spacecraft bus level (1.1.2). See Figure 4.1 which shows the yellow rollup icon that represents the activation of SLC. The SLC settings have been created to reflect the system level efforts in each of the three levels Mission Level SEER s SLC settings at the mission level are used to reflect the project management (WBS 01), systems engineering(wbs 02), safety and mission assurance (WBS 03), and the systems integration & testing (WBS 10) of the NASA WBS. WBS 01, 02, and 03 are reflected by SEER s Systems Engineering and Integration (SEI) and Systems Program Management (SPM) system level categories. The settings assume a team with successful experiences with similar projects, good understanding of the technology, and efficient processes to perform the tasks. The overall project is small to midsized with considerable inheritance of existing hardware and the goals to achieve mission success are clear and reasonable with little or no changes in the goals. WBS 10 is reflected by SEER s Systems Test Operations (STO) and Systems Support Equipment (SSE) system level categories. Because a mission is commonly characterized by uniqueness, the settings assume a competent team with some experience with pulling all the necessary elements together. Mission SLC for Complete Mission Least Likely Most SEI Development Complexity Low Nom Hi SEI Development Experience Nom Nom Nom+ SEI Production Complexity Low Nom Hi SEI Production Experience Nom- Nom Nom+ IAT Development Complexity IAT Development Experience IAT Production Complexity IAT Production Experience SPM Development Complexity Low Nom Hi SPM Development Experience Nom- Nom Nom+ SPM Production Complexity Low Nom Hi SPM Production Experience Nom- Nom Nom+ STO Complexity Nom Nom Nom STO Experience Nom Nom Nom SSE Complexity Nom Nom Nom SSE Experience Nom Nom Nom Table 5.1 Mission SLC for Complete Mission

11 5.1.2 Instruments Under Payload Level Each instrument within the payload level (WBS 05) includes local system level efforts. The settings assume an exceptional team, strong understanding of the instrument(s) technology, and efficient processes to complete the instrument tasks. The project is assumed to be small due to the scale of individual instruments. The instrument(s) is well-understood and the goals for the instrument(s) are clear and reasonable to achieve success. Because of instrument uniqueness and complexities, the settings assume a capable team with some or extensive requirements in integrating, assembling, and testing. Payload Level SLC for Complete Mission Least Likely Most SEI Development Complexity VLO LOW- NOM- SEI Development Experience HI HI HI SEI Production Complexity VLO LOW- NOM- SEI Production Experience HI HI HI IAT Development Complexity NOM+ HI- VHI- IAT Development Experience NOM NOM NOM IAT Production Complexity NOM+ HI- VHI- IAT Production Experience NOM NOM NOM SPM Development Complexity VLO LOW- NOM- SPM Development Experience HI HI HI SPM Production Complexity VLO LOW- NOM- SPM Production Experience HI HI HI STO Complexity STO Experience SSE Complexity SSE Experience Table 5.2 Payload Level SLC for Complete Mission Spacecraft Bus Level The spacecraft bus level (WBS 06) includes local system level efforts on the spacecraft bus subsystems. The settings assume an exceptional team, strong understanding of the spacecraft subsystems, and efficient processes to complete the spacecraft tasks. The scale of the spacecraft project is assumed to be small and its technologies well-understood. The goals for the spacecraft are clear and reasonable to achieve success. Because of mission and instrument(s) uniqueness, the settings assume a capable team with some or significant requirements in integrating, assembling, and testing of the spacecraft subsystems.

12 Spacecraft Bus Level SLC for Complete Mission Least Likely Most SEI Development Complexity VLO+ LOW NOM- SEI Development Experience HI HI HI SEI Production Complexity VLO+ LOW NOM- SEI Production Experience HI HI HI IAT Development Complexity NOM- NOM+ HI IAT Development Experience NOM NOM NOM IAT Production Complexity NOM- NOM+ HI IAT Production Experience NOM NOM NOM SPM Development Complexity VLO+ LOW NOM- SPM Development Experience HI HI HI SPM Production Complexity VLO+ LOW NOM- SPM Production Experience HI HI HI STO Complexity STO Experience SSE Complexity SSE Experience Table 5.3 Spacecraft Bus SLC for Complete Mission

13 5.2 SEER Costs Mapping to NASA WBS for Complete Mission SEER Mission level to NASA WBS 01, 02, & 03 and 10 The activation of SEER s SEI and SPM at the mission level maps to NASA s WBS 01 Systems Engineering, 02 Project Management, and 03 Safety & Mission Assurance. The activation of SEER s STO and SSE at the mission level maps to NASA s WBS 10 Systems Integration & Testing. SEER Payload level to NASA WBS 05 The development and production subsystem total of the payload and the activation of SEER s SEI, IAT, and SPM at the instrument level (shown in red) maps to NASA s WBS 05 Payload. SEER Spacecraft Bus level to NASA WBS 06 The development and production subsystem total of the spacecraft bus and the activation of SEER s SEI, IAT, and SPM at the spacecraft bus level maps to NASA s WBS 06 Spacecraft. NASA WBS SEER Costs Mapped to NASA WBS for Complete Mission SEER WBS Level Project Payload Spacecraft WBS 01 Project Management WBS 02 Systems Engineering SEI + SPM WBS 03 Safety & Mission Assurance WBS 10 Systems Integration & Testing STO + SSE WBS 05 Payload Subsystem Total + SEI + IAT + SPM Subsystem Total + SEI + WBS 06 - Spacecraft IAT + SPM Table 5.4 SEER Costs Mapped to NASA WBS for Complete Mission

14 5.3 SLC for Instrument-only Mission SEER s SLC for an Instrument-only Mission are activated at two levels: the mission level (1.1) and the instruments (1.1.1.N) under the payload level. The SLC settings have been created to reflect the overhead effort in each of the two levels. The Instrument-only Mission excludes the spacecraft bus level seen in a Complete Mission Mission Level SEER s SLC settings at the mission level are used to reflect the project management (WBS 01), systems engineering (WBS 02), safety and mission assurance (WBS 03), and the systems integration & testing (WBS 10) of the NASA WBS. WBS 01, 02, and 03 are reflected by SEER s Systems Engineering and Integration (SEI) and Systems Program Management (SPM) system level categories. The settings assume a team with successful experiences with similar projects, good understanding of the technology, and efficient processes to perform the tasks. The overall project is small to midsized with considerable inheritance of existing hardware and the goals to achieve mission success are clear and reasonable with little or no changes in the goals. WBS 10 is reflected by SEER s Systems Test Operations (STO) and Systems Support Equipment (SSE) system level categories. Because a mission is commonly characterized by uniqueness, the settings assume a competent team with some experience in the support of ATLO activities. Mission SLC for Instrument-only Mission Least Likely Most SEI Development Complexity Low Nom Hi SEI Development Experience Nom- Nom Nom+ SEI Production Complexity Low Nom Hi SEI Production Experience Nom- Nom Nom+ IAT Development Complexity IAT Development Experience IAT Production Complexity IAT Production Experience SPM Development Complexity Low Nom Hi SPM Development Experience Nom- Nom Nom+ SPM Production Complexity Low Nom Hi SPM Production Experience Nom- Nom Nom+ STO Complexity Nom Nom Nom STO Experience Nom Nom Nom SSE Complexity Nom Nom Nom SSE Experience Nom Nom Nom Table 5.5 Mission SLC for Instrument-only Mission Instruments Under Payload Level The SLC settings on the instruments reflect the instrument s I&T and the integration, or rather, the support to integrate to the host (WBS 10). Because of instrument uniqueness and complexities, the settings assume a capable team with some or extensive requirements in integrating, assembling, and testing. Payload SLC for Instrument-only Mission Least Likely Most SEI Development Complexity VLO LOW- NOM- SEI Development Experience HI HI HI SEI Production Complexity VLO LOW- NOM- SEI Production Experience HI HI HI IAT Development Complexity NOM+ HI- VHI-

15 IAT Development Experience NOM NOM NOM IAT Production Complexity NOM+ HI- VHI- IAT Production Experience NOM NOM NOM SPM Development Complexity VLO LOW- NOM- SPM Development Experience HI HI HI SPM Production Complexity VLO LOW- NOM- SPM Production Experience HI HI HI STO Complexity STO Experience SSE Complexity SSE Experience Table 5.6 Payload SLC for Instrument-only Mission 5.4 SEER Costs Mapping to NASA WBS for Instrument-only Mission SEER Mission level to NASA WBS 01, 02, & 03 and 10 The activation of SEER s SEI, IAT, and SPM at the payload level maps to NASA s WBS 01 Systems Engineering, 02 Project Management, and 03 Safety & Mission Assurance. The activation of SEER s STO and SSE at the mission level maps to NASA s WBS 10 Systems Integration & Testing. SEER Payload level to NASA WBS 05 The development and production subsystem total of the payload and the activation of SEER s SEI, IAT, and SPM at the instrument level (shown in red) maps to NASA s WBS 05 Payload. NASA WBS SEER Costs Mapped to NASA WBS for Instrument-only Mission SEER WBS Level Project Payload WBS 01 Project Management WBS 02 Systems Engineering SEI + SPM WBS 03 Safety & Mission Assurance WBS 10 Systems Integration & Testing STO + SSE WBS 05 Payload Table 5.7 SEER Costs Mapped to NASA WBS for Instrument-only Mission Subsystem Total + SEI + IAT + SPM

16 5.5 Adjusting SLC Due to variations in programs as well as uniqueness of missions, it is understandable that adjustments are made to reflect the proper characterizations of a program and its mission. The SEER SLC settings are based on a large and diverse set of actual missions and were created to give users a standard approach in modeling system level efforts. The settings reflect an average system level effort out of the data set. But, again, due to the uniqueness of space projects, it is recommended that SEER s settings are used as a baseline, and then, if needed, make the necessary adjustments to reflect the proper system level effort required by a program. For example, if the management of the program is predicted to be more difficult than commonly seen, the SPM complexity should be increased. If it is difficult due to the management team being fairly new, then the SPM experience should be reduced to reflect that. However, adjustments should be made after SEER s recommended settings have been applied so that the adjustments are made from a standard approach in which the system level effort captured is the average amount seen for a mission. If a program is structurally unique, then the user should activate SLC at different rollups beyond the current SLC setup recommendation. For example, if one of the subsystems of the spacecraft bus is built by a different vendor than the prime, it may be necessary to activate the SLC for that subsystem to capture the system level efforts performed by that specific party. 5.6 SLC Setup Differences between Complete Mission and Instrument-only Mission As you can see, there are differences in the way SLC is structured between a complete mission and instrument-only mission. In a complete mission, when viewing the project from top down, you can see that the program is responsible for two systems: payload and spacecraft bus. This usually means that there is a team dedicated for each system as well as a team for overseeing the project. In an instrument-only mission, when viewing the project from top down, you can see that the program is responsible only for the instrument or instruments. 5.7 SLC Application KBs Application KBs for the Rollup element type has been created post model which contains the settings shown above. Go to Post SEER-H Kbases (Pending Release) to download the created KBs. Created SLC Application KBs post model Unmanned Mission Space CubeSat Mission Payload/Instrument - Space Spacecraft Bus Table 5.8 Created SLC Application KBs These KBs will be officially released in the next maintenance release. Note: Set Platform KB to!no Knowledge when using these application KBs.

17 6 Heritage and Technology Readiness Level Heritage is inherited hardware (or software) subsystems or components that have flight history and are being utilized for a new mission. Technology Readiness Level (TRL) refers to the level of technological maturity of a particular component or system. It is a common misperception that high heritage equates to high TRL. In actuality, using high heritage technology from previous flights may actually be low TRL when used in other missions. The use of mature technologies is emphasized by programs in order to reduce the cost of a project. However, it should not be automatically assumed that the use of high heritage will lower the cost of the project. In actuality, there have been many more cases than not in which the project incurred overruns even with the use of high heritage components or systems. The circumstances in the use of a mature technology can alter its original applicability in which it was used previously. In other words, high TRL designation applied to the mature technologies may not be accurate. For example, the environment in which the mature technology was used previously may be different. The different environment can require new specifications, more development, more testing, etc. Other examples of circumstances can include different interfaces, accommodation, thermal requirements, manufacturer, documentation, and many more. A Space Procure to Print acquisition category may be appropriate for a high heritage and high TRL element in an applicable mission. However, if the mission is unique or different, which it commonly is, from the mission in which the high heritage element was flown, the applicability of the high heritage element may change. There are two common scenarios of the inapplicability. First, the high TRL designation of the high heritage element may no longer be appropriate as new mission specifications may have altered the maturity of the element when integrated into the configuration of the new mission. However, the heritage of the component may still have some value in reducing the amount of redevelopment needed. And, so, a Modification Average acquisition category may be appropriate to reflect the modifications or engineering effort required on the high heritage element. Second, the high describing heritage may not be applicable at all if the mission uniquely differs from the previous mission in which the heritage part was flown. In this scenario, the heritage element may have some designs used for the new mission, but the element used in the new mission may be majorly different from the heritage part from being suitable for the unique circumstances of the new mission. In this case, a Modification Major or Make acquisition category will need to be used to appropriately reflect the amount of engineering effort and development required on the element to be flight-ready for the new mission. Also optimism may be conceived due to usage of mature technologies and can lead to inadequacies in planning for the circumstances. This can result in cost and schedule growth. To better incorporate high heritage technologies in the model, the circumstances should be taken into consideration using technical and nontechnical data, risks, and other data sources.

18 7 Acquisition Category Knowledge Base An element s estimate in SEER goes beyond than just the cost of the part. It also includes the engineering effort to get the element flight-ready. SEER s acquisition category KBs are used to characterize the level of readiness of elements in the aspect of design, development, documentation, analysis, and testing required. Table 7.1 shows SEER s acquisition categories defined for space scenarios at different levels of readiness. 7.1 Determining an Element s Acquisition Category When determining the appropriate acquisition category for an element, the user must look at the element level as well as the subsystem/system assembly level. When only looking at the element, it is simple to determine its readiness relative to itself. However, because the element is part of a system, the user must also investigate the element s readiness relative to the system. In other words, will the element (or system) work when the element is assembled and configured into the system? For example, a fully developed propulsion system that was previously used on Spacecraft A may not necessarily be ready for flight on Spacecraft B. Spacecraft B may have changed configuration-wise which means that the existing propulsion system from Spacecraft A may have to undergo redevelopment, testing, and analysis in order for that system to fit into Spacecraft B s configuration. This type of scenario is common as space mission requirements and circumstances tend to be unique and change regularly. Unless otherwise specified, the recommended baseline approach is to use modification average. This was based on the common practice in which existing parts are used on unique missions and, so, have to go through some of that engineering effort or redevelopment presented in the example above. 7.2 Acquisition Categories The user should not be confined to the limited scope of acquisition categories below. However, these specific acquisition categories were used to model general cases of different levels of readiness. Users should use the most applicable acquisition categories based on element information at hand. Acquisition Categories Approach Definitions adjusted for Space elements Build to Print* Adjust to as required Existing design that requires the bare minimum engineering effort to fit into the system configuration. Space Procure to Print Adjust to as required Existing design but requires engineering effort to fit into the system configuration. Modification Minor Adjust to as required Existing design but requires minor changes and engineering effort to fit into the system configuration. Modification Average Baseline Nominal changes, updates, or engineering effort required on existing design to fit new mission requirements. Modification Major Adjust to as required Significant changes, updates, and engineering effort required on existing design to fit new mission requirements. Make Adjust to as required Substantial engineering effort and extensive changes or updates bordering or equaling a new design. Table 7.1 Acquisition Categories Overview *Note that the Build to Print acquisition category should really only be used for CubeSats. Space components (that are not for CubeSats) do require some engineering effort at minimum even if it assumed to be a built to print of an existing design. In other words, Space Procure to Print should be used for components that are viewed as build to print but that are not for CubeSats. 7.3 Specific Acquisition Category Recommendations Table 7.2 contains specific acquisition category recommendations of select individual components and components of particular subsystems. Specific guidance were established due to commonality in scenarios and properties of the select components below. The basis explains the reasoning why the acquisition categories selected were used and can be used as examples of applying appropriate acquisition categories.

19 Application KB Camera Optical Assy or Optical Bench Specific Acquisition Category guidance on Application KB Acquisition Element Type Basis Category EOS Optical Device Modification Major Space Harness Mechanical Make Space RF Components Space Propulsion Parts Spacecraft Structure Mechanical Mechanical Mechanical Make Make Modification Major The optical configuration on the optical bench is based off of existing design but generally requires customization which requires significant effort in development. Due to unique mission requirements, most harnesses are custom designed. This KB can be used to model a configuration design. Since most communication systems are unique to the mission, the assembly of the RF parts are custom. This KB can be used to model a configuration design. Since most propulsion feed systems are unique to the mission, the assembly of the propulsion parts are custom. Architecture may be reused, but the structure is unique to mission; see section 11.2 Spacecraft and Heritage. Thermal* Mechanical Modification Major Thermal characterization and requirements unique to mission. Attitude Determination and Control* Mechanical/Electronics Other Space Procure to Print Modification Average ADCS components are typically COTS and require only engineering effort to fit into the system configuration. There may be uses of special elements that are unique to ADCS i.e. detectors. *Applies to components within the particular subsystem. Table 7.2 Specific Acquisition Categories Recommendations

20 8 Risks Risks are inherent in a project s life cycle. They are major concerns for programs in which cost overruns can result from these risks. There are two types of risks: known and unknown. 1. Known risks are risks that are identifiable and can be planned and accounted for. These risks can be caused by internal and external factors which affect programmatic or technical factors. For example, an instrument is known to go through design changes during development. Contingencies can be applied to this instrument in the case that this risk does occur, minimizing its effect on the project. 2. Unknown risks are risks that are not identifiable until it occurs. These risks are usually caused by external factors which affect the programmatic or technical specifications. For example, the instrument may exceed the design growth accounted by the contingency due to an engineering change. An engineering change is an external factor that is unexpected to a program. 8.1 Risks in SEER 1. Known risks It is up to the user to capture the programmatic and technical known risks in the model. This is done by adjusting the settings for least/like/most categories. System Level Costs are used to represent the programmatic factors. The element s parameters are used to represent the technical factors. If known risks are not captured in SEER, these known risks are an addition to the SEER model. 2. Unknown risks SEER s database does not include the unknown risks that may occur in a project s life cycle. SEER focuses on modeling the programmatic and technical aspects to estimate the project as-is. The intention of SEER is to capture a project as-is without external factors and to estimate the cost to execute to the plan. This approach leads to an estimate that is traceable to a project s programmatic and technical specifications. In other words, traceable to the proposed plan and design.

21 9 General Modeling This section covers general modeling practices used in building SEER Models. These recommendations are of a general nature and can be applied throughout the various sections of a SEER space cost model. This section and subsequent sections on instruments and spacecraft subsystems have been prepared to enhance the internal guidance and focus it onto the space cost estimation domain. SEER already contains extensive help on how to handle specific model features, parameters, and knowledge bases (KBs). Use the help system to gain better understanding of each feature, parameter, and knowledge base. SEER also includes example project files which provide insight into applying these recommendations. 9.1 Sources of Information Modeling with SEER requires insight into the structural details of the system being modeled. SEER has great flexibility, it being a component-level model, and is capable of modeling many different designs. But to make the best use of this capability, a good understanding of what is being estimated is needed. Below is a list of commonly-found documents which can be used when structuring a model in SEER. Master Equipment List (MEL): This document will list the key elements of an instrument or spacecraft subsystem, usually down to a component level. For example, the MEL for an imager might show the key optical elements, the structure of the optical device, detector and electronic components, etc. In this document, you can get the mass per element shown as the current best estimate (CBE), contingency, and margin. It will also include the number of flight units, spares and engineering models. All of this information is used within the SEER model. Bill of Materials (BOM): This source of information shows a list of parts for a given element. For example, a BOM for an electronics board might list resistors, capacitors, microcontrollers, FPGAs, etc. This document tends to be available once the design is a bit more mature and so might not be present at the start of a project. If available, this document will provide SEER with information about the nature of the components and the presence of more expensive custom items. Work Breakdown Structure (WBS) Dictionary: This document provides information on the scope of effort for elements or systems. This can aid the user in selecting the most applicable SEER KBs. Instrument Technical Description: This source of information explains key elements at a technical level and provides a system description of how these elements come together. It can include block diagrams for electronics and mechanical/structural elements, process flow diagrams of the system, optical diagrams showing the layout of the optical elements, etc. This can help the cost modeler understand the project and create a proper SEER model. Some items that are not broken out in the MEL may show up in this section in more detail. Examples of this might include electronics boards and custom electronics. Testing Description: This document gives in-depth information on the engineering models and flight units, quantifying how many of each are made (typically shown in the MEL) and the level of fidelity of the engineering models. For instance, it may list structural prototypes versus full form-fit-function units, or explain when development will be done on flight units as opposed to engineering development units, etc. This information can help set SEER s prototype number, acquisition category and model structure. Software Description: This document provides sizing and other technical and nontechnical information about the software effort. SEER-SEM can use this data to produce a software estimate. Heritage Description: This source of information describes the design and use heritage of the component, assembly or system design. For example, a component may have flown before in another project, and so the current project might use that design to reduce development efforts. This data may also be present in the MEL or other sources. This will aid the user in selecting the best Acquisition Knowledge base.

22 9.2 Level of Element Modeling The SEER project file can model costs at various WBS levels (Level 1, 2, 3, etc.). At one extreme, it would be possible to lump many components into a single SEER work element, then select appropriate settings for this overall collection. The other extreme might be to create separate work elements for each piece, down to the last nut and bolt. The first approach, however, is likely to be too general, while the other will consume too much time. The most effective approach is to identify all of the key components, and create separate work elements for each of those components. This approach makes it easier to include complete and accurate technical and heritage descriptions of those components in the work elements. Examine the files located in the SEER model project file directory for examples of common ways to use levels of element detail. For example, while many electronic elements are modeled at the board level (counting the number of ICs), key custom microelectronics are broken out (FPGAs, ASICs, RFICs, etc.), since they can individually carry significant effort. 9.3 SEER Three Point Input Distribution SEER uses a three-input PERT distribution labeled least, likely, and most to incorporate parameter uncertainty. See Ch. 10 in SEER for Hardware Detailed Reference in SEER s tool folder for more information. There are different approaches in setting these three inputs; whichever approach is used, it is important to follow it consistently in order to produce a consistent and credible estimate. For example, some users prefer to enter the current best estimate (CBE) for least, likely, and most. Others use the CBE for the least and likely, and the CBE + contingency for the "most" input. Below are settings that SEER recommends when inputting for the mass parameter. The additional 30% factor is applied to account for mass growth. Least Likely Most Current Best Estimate (CBE) CBE + Contingency 1.3 * (CBE + Contingency) Table 9.1 SEER Mass Parameter Recommendation 9.4 Flight Units, Flight Spares, Engineering Models, and Protoflights Parameters Units Prototype Production Definition Quantity Quantity Flight Unit 0 1 A flight-ready producible part. Flight Spare 0 1 Viewed in SEER as parts that are flight-ready and available if the flight unit needs to be replaced. Engineering Model x 0 Unit used during development efforts. See Help for rules of thumbs when reflecting prototypes. Protoflight A flight unit that goes through hardware prototyping before it becomes a flight-ready part. This part begins as an engineering model and evolves into a flight unit. This has prototype count of greater than 1 to account for testing and additional work needed to get this part flight ready. This category is also discussed in SEER help as a qualification test unit. Table 9.2 Unit Type Overview 9.5 Modeling for Multiple (Identical) Spacecraft The following are recommendations for modeling multiple identical spacecraft (instrument and spacecraft buses) for Earth or Deep Space missions: 1. Earth The multiple spacecraft is considered as additional flight units or 1 in production quantity. In other words, increment the production quantity parameter to represent the multiple spacecraft. See Figure 9.1. Note that one prototype quantity shown in the figure reflects the common prototype for both spacecraft. 2. Deep Space The multiple spacecraft for non-earth missions should be modeled as two groups of SEER elements. See Figure 9.2. However, prototypes or protoflights are dropped for the second spacecraft as all the prototyping is done on the

23 first spacecraft. The second spacecraft should reflect the proper amount of flight units in the production quantity parameter. Figure 9.1 Earth Space Multiple Spacecraft Figure 9.2a Deep Space Multiple Spacecraft

24 Figure 9.2b Deep Space Multiple Spacecraft 9.6 Guidance by Element Type This section provides element type modeling recommendations. These recommendations are element type-specific, but are used throughout a space mission model, that is when modeling payload instruments or spacecraft subsystems. The recommendations in this section are intended to provide a clear set of standards for modeling Mechanical, Electronics, EOS, and IC work elements. Refer to Chapters 10 and 11 for recommendations that are specific to either instrument modeling or spacecraft modeling Mechanical Element Type This element type covers a wide variety of mechanical, structural, mechanism, and hydraulic applications. The Mechanical element type is weight-based, and one of the most versatile elements used in SEER. Below are some general recommendations. Use the most precise application KBs for a given element. For instance, instead of using an application KB of mechanical general use Primary Structure to describe primary structures. Several Application KBs may be available for modeling a given element. It is important to use the Help to identify and select the most appropriate Application KB. For example, SEER s Mechanical Element type has application KBs for a variety of enclosures (ruggedized, space electronics, RF, etc.). Understanding the actual enclosure requirements can help the user identify and select the most appropriate enclosure Application KB. Some SEER Mechanical element Applications KBs can model components also covered by other SEER element types. For example, the Mechanical element type includes an Electro-Optical Sensor Application KB, which can be used to model EOS detectors. The EOS-Detector element type, however, was made to specifically cover various types of EOS detectors; using it will result in a more accurate representation of the detector being modeled. The Mechanical element type's EOS detector can still be used to cost items when little is known about the detector, for example, when the only information known is mass. Under these circumstances, it can help approximate a value.

25 Weight For mechanical elements, weight is a key sizing parameter and a strong driver of cost. This is one parameter for which the KBs do not provide a default entry. See section 9.3 for a common distribution of weight across the least, likely and most parameter inputs for mechanical elements Material Composition The material composition can also play a significant role in driving element costs. This is an especially important parameter, as it plays a major role in an accurate estimate. It may be set either by the Application KBs or the user. The type of material selected can heavily impact both the material cost and the associated development effort. While not all mechanical/structural elements may have material composition data, the material composition parameter should be set whenever possible. The Application KBs listed below are examples of those for which material composition can carry significant cost. Spacecraft Structure Space Propulsion Tankage It is recommended to use the actual material allocation for a given work element. However, if this is not available, distribute the material allocation equally among the applicable material types. For example, If only aluminum is given, set the material composition parameter for aluminum to 100% within SEER, and set all other material percentages to zero. For two materials, set each one to 50%, and all others to zero. If three materials are given, each should be set to 33.3%, with all other materials zeroed out, etc. If no material percentage composition is given, use the default values set by the SEER KB Electronics Element Type This work element type models electronic circuit boards of various types, including computational, communication, RF, electromagnetic, control/display, and navigation. Below are general recommendations, followed by a more in-depth look at a key parameter. This work element type is designed for modeling at the board level. The parts that make up the circuit or board can be captured using the parameters listed under Product Description. These parts include resistors, capacitors, microcontrollers, integrated circuits, etc. Integrated circuits such as FPGAs and ASICs can carry significant costs in themselves. We recommend using SEER IC to model these types of integrated circuit rather than modeling them within Electronics work element type Total Printed Circuit Board The total printed circuit board parameter reflects the number of board designs within a single Electronics work element. This parameter is a major cost driver as it attempts to capture the complexity of an element of multiple board designs (assuming that it is not set to one). For space electronics, it is typical to have one unique circuit board design per work element, so the total printed circuit board parameter would be set to one. There are, however, situations where a space electronics element may include more than one board design. Note that the total printed circuit board parameter is not the same as the quantity of boards produced for the work element, which is represented by a separate set of Production Quantity inputs. This parameter is used to drive the recurring cost of producing the number of boards of a given element.

26 9.6.3 EOS Element Types The Electro Optical System (EOS) model is made up of various work element types: Optical Device, Detectors, Cooler, Mechanism, Calibrator, Integration & Test, and Laser. Each of these element types has its own set of Application KBs. EOS elements are ideal for estimating imaging instruments, spectrometers, interferometers, IR instrumentation, and many other applications that use the electromagnetic optical spectrum. Refer to the SEER model example project files, which contain examples of these EOS element types. As noted previously, the Mechanical and EOS element types include some Application KBs which can be used to estimate similar items. For example, a CCD detector can be modeled using the Mechanical Element s Electro-Optical Sensor Application KB, but it is a general KB to reflect a wide variety of detectors. The EOS Detector Element, on the other hand, is geared towards modeling specific detectors, which include CCD detectors EOS Optical Device Element Type Reflective Telescope, Refractive Telescope, and Optical Bench The SEER EOS Optical Device Element Type includes several different technologies. Certain Application KBs in this element type are designed to capture the assembly of an optical system. These Application KBs are Reflective Telescope, Refractive Telescope, and Optical Bench. So, rather than modeling piece-wise of the individual optical pieces, e.g. mirrors, lenses, filters, etc., and the structure of the optical assembly, these three applications KBs and their parameters are used to capture an optical assembly in one element., These three technologies share some parameters which are key to proper estimation: imaging element, non-imaging element, and aperture/largest optical element size. Imaging elements in SEER are defined as optical elements that change the optical image size. Non-imaging elements in SEER are optical elements that do not change the size of the image but rather redirect it. For example, a grating is considered an imaging element in SEER. Slits, beam splitters, dichroic filters, and other filters are examples that are considered non-imaging elements. Some difficulty can arise when trying to determine whether a mirror or lens is an imaging or non-imaging element. One way to do this is to examine an optical flow diagram. Such a diagram is often used to illustrate paths of the optical signal beams as they move through the various optical elements. If a light beam appears to diverge or converge, then the element producing this change is considered an imaging element. On the other hand, if the beam appears to be of comparable width before and after the optical element, then this element can be considered a non-imaging element. See Example project file attachment and how the attachment led to the model inputs. Another key parameter in the EOS Optical Device element is the one that determines the size of the element. SEER reflective and refractive optical device technologies use the largest element diameter to assess the relative size of the telescope element. The optical bench technology uses the aperture size parameter. Both of these parameters uses the largest imaging element in the optical assembly to gauge the relative size of the optical system being modeled. Below are detailed descriptions of these technologies Reflective Telescope Reflective telescopes use mirrors to capture and collect optical signals. There are separate Reflective Telescope Application KBs based on the use of lightweight or standard materials and the presence or absence of a scan mirror. Note that the term telescope in this context is a general term used to describe optics assemblies such as the imager, transmitter, or scanner assembly, etc. Reflective Telescope Application KBs include the cost for the telescope enclosures and mounting elements. See Help for further details Standard versus Lightweight For a reflective telescope built with standard materials such as aluminum, use one of the "Standard" Reflective Telescope Application KBs. For a telescope built with beryllium, composites, or other complex materials, use one of the "Lightweight" Reflective Telescope KBs.

27 With or Without Scan Mirror If the telescope includes a scan mirror, use one of the Reflective Telescope Application KBs labeled With Scan Mirror. This captures the scan mirror assembly. The scan mirror itself will need to be reflected in the imaging elements parameter Refractive Telescope Refractive telescopes use lenses to capture and collect optical signals. SEER includes separate Refractive Telescope Application KBs for Infrared (IR) and Visible wavelengths; select the KB based on the wavelength targeted by the telescope. The term telescope in this context is a general term used to describe optical assemblies such as a camera. Refractive Telescope Application KBs include the cost for the telescope enclosures and mounting elements. See Help for further details Optical Bench The Camera Optical Assembly or Optical Bench Application KB is generally used to capture the portions of the instrument doing optical processing on the incoming light, such as spectrometers, interferometers, etc. If it is known that the optical elements will be placed on one structure (or bench), consider modeling them as a single Optical Bench element rather than multiple SEER elements. Due to the multiple optical paths being modeled, such an element will contain a higher count of imaging and non-imaging elements than would be found with a less complex optical work element. If the optical processing section is separated into compartments or split into multiple sections for separate wavelength processing, it may be more appropriate to model it as separate elements Modeling Spares for Optical Elements Within the EOS Optical Device element there are many technologies and Application KBs dedicated to capturing just the costs of individual components such as mirrors, lenses, gratings, etc. These are used to estimate the cost of spare optical components. For spares, it is assumed that all engineering design has been done, and that the model is estimating only the cost of purchased components along with some minor engineering effort. Note that these estimates do not account for the design of optics, mounting hardware, or the effort to incorporate the items into an assembly (alignment, testing, etc.). Use the technologies such as Reflective Telescopes, Refractive Telescopes, Optical Bench, etc. to estimate full integrated costs of the optical components.

28 9.6.4 Custom Integrated Circuit Element Standard off-the-shelf ICs can be modeled in SEER as parameter entries within individual board elements. Custom ICs, however, should be modeled separately, due to their complex nature and the significant engineering effort which they often require. SEER-IC is designed specifically for modeling custom ICs, including Application Specific Integrated Circuits (ASICs), Field Programmable Gated Arrays (FPGAs), Radio Frequency Integrated Circuits (RFICs), Monolithic Microwave Integrated Circuits (MMICs) and Mixed Signal Devices. All of these technologies are captured by SEER-IC's ASIC and FPGA work elements; the ASIC element includes the RF technologies listed above. Note that there is a major difference between designing a new ASIC or FPGA for an instrument and using an existing ASIC or FPGA. A new IC design will generate a much larger non-recurring cost, which needs to be modeled carefully. For FPGAs, even when an IC is supposed to simply be reused, it is important to determine if there are any changes in the electronic design which could affect the IC. If this is the case, and Acquisition Category KB such as "Modification - Minor" may be warranted. See the SEER IC help system for further guidance on these technologies IC Element Structural Modeling Recommendations FPGAs and ASICs are, of course, designed to be integrated onto an electronic circuit board. To capture that integration, a dedicated rollup for the board and the chip should be created with SEER s System Level Cost Integration, Assembly & Test activated, as shown in the screen shots below. Figure 9.1 FPGA Model Structure Figure 9.2 FPGA SLC Recommendation FPGA modeling guidance The SEER-IC FPGA element includes a variety of Application KBs. including several for the two most common types of FPGA application, signal processing and control. Size is critical to an FPGA element. While SEER mechanical elements use weight for sizing, and SEER for Software generally uses lines of code or function points, SEER IC FPGA elements use logic cell count (a common sizing metric within the industry) as the key sizing parameter. As with any sizing input, it provides a way to scale the magnitude of the development effort. Because the logic cell count is so crucial for sizing, it should reflect the requirements of the specific chip in question; typically, the more functionality a chip must carry, the higher the number of logic cells. The actual logic cell count is broken out into

29 several parameters, representing new, IP (reused logic), and several specialized logic cell categories. It s important to note the count of new logic cells, as this has a strong effect on cost. The FPGA logic cell count inputs are in the standard SEER "Least", "Likely", and "Most" format, and as always, it is important to establish and maintain a consistent method for determining these values. The Most input, for example, might include a certain amount of growth, which is typical of new designs. Whenever possible, it is important to include actual sizing information, since it is one of the key methods for determining chip costs for FPGAs. When no sizing information can be found, however, the following settings can be used to reflect general space science projects. IC Element Type Parameter Least Likely Most Logic Cells 100, , ,000 Table 9.3 FPGA Sizing Recommendation Use the MEL, BOM, engineering interviews, and technical documents to extract the key information needed for these elements Side note on FPGAs: FPGAs are composed of many programmable logic blocks that carry out logic functions. The terms used to describe these blocks vary by manufacturer. Some common terms used to describe various combinations of these logic blocks include logic cells, logic elements, and system gates. All of these options are available in SEER-IC models to describe a chip s development size. Furthermore, these chips can be purchased with a large variety of reconfigurable capacity. They can vary from small glue logic functions to extremely large fabrics capable of carrying out a large amount of digital processing. The chip s capacity refers to the amount of resources that a user can utilize when designing or configuring a chip. The larger the resources purchased, the more functionality the chips can carry, but at an increasing cost. It is important to note that designers typically do not use all of the resources or the full capacity of a chip. It is common to see only 50-70% utilization, due to a variety of constraints, as well as the allowance of room for expansion. In the SEER-IC model, utilization higher than 70% will generate a penalty in cost due to the increasing challenges in producing a functional chip 9.7 Contributed Hardware and Government Furnished Equipment Hardware contributions are items given to a prime developer for integration into their system. In Space Science projects these could range from lower level items like parts/components up to full instruments, or other higher level assemblies. The items are typically given at no cost to the prime integrator. Government Furnished Equipment (GFE) is similar to a Space Science hardware contribution, only it is provided by the government. In both cases, the cost analyst might not need to estimate the cost of the contribution, but might still need to capture the cost of integrating and testing the items into the final system or subsystem. There are several ways in which SEER can be configured to account for such costs GFE/Contribution can be modeled This represents a case where the GFE/Contribution can be modeled in SEER. Although the actual cost of the contribution is not needed, modeling it will make it easier to understand the overall complexity and any related issues. When modeling contributed hardware or GFE, set "Use in System Level Calculation" to YES and Include in Subsystem Total to NO. This means that the cost of the contributed hardware or GFE is not included in the estimate, but the cost of the responsibility of managing, working requirements and integrating it into the system is captured in SEER and included in the estimate. Both of these settings are listed under "Engineering Inputs (Optional)" at the bottom of a work element's Parameters tab; you will need to make these settings for all work elements that are GFE/Contribution. Below is an example showing contributed detectors, along with the associated Engineering Inputs settings.

30 GFE/Contribution cannot be modeled but the cost is known There may be cases in which the description of the contributed hardware or GFE is not provided but the cost is known. This is not an ideal situation, but the following can be done to capture some of the costs of incorporating these items into the system. 1. Use an Add-in element where the cost of the Hardware is converted into hours or material costs. 2. Set the Include in Subsystem Total parameter to NO. This will ensure that this element does not add the contributed costs to the system. 3. As before, set the Use in System Level Calculation setting to YES.

31 9.8 Common Parameters to Consider The parameters below are shared between the various element types. Due to the scale and complexity of payload instruments and spacecraft subsystems, these parameters may be important in characterizing many elements Design Complexity The Design Complexity parameter measures the design difficulty for a given element and can drive the element's overall development effort. The default setting is nominal, which represents a typical middle-of-the road case. There may be times when the design of an element will be more complex than usual due to highly challenging requirements not attempted before. This may be a factor to apply a higher setting to the Design Complexity parameter. Higher Design Complexity settings can also be used for designs that go beyond state-of-the-practice or have poor TRLs. Note that this parameter should not be confused with the New Design parameter. For example, even though a power supply is a 100% new design for your project, the difficulty in designing the element can vary Certification Level / Reliability Standard Mechanical, Electronics, and IC element types have a Certification Level parameter. In the EOS model, there is a comparable parameter called Reliability Standard. These two parameters are closely related in that they capture the rigor in the requirements imposed on an element. The level of requirements can be dependent on the operational environment for a given element (space, air, ground, etc.) but both parameters can also be driven by other considerations. The Platform KBs will set these parameters for the user. The KBs, for example, set a space mission element to a higher level due to more stringent requirements, while a ground system might have lower requirements. While the Platform acquisition category sets the Certification Level/Reliability Standard appropriately based on the type of mission, the user can adjust these settings for the mission being modeled. For example, if a component used in an unmanned space mission needs to operate in an environment with higher than usual radiation, will require more analysis, characterization, and testing efforts, its Certification Level/Reliability Standard might be higher than its default High setting. NASA Procedural Requirements discusses the risk classification of NASA missions which represent the amount of risk acceptable for a mission. Based on this, there are different levels of requirements that each class must meet. There are four classes: A, B, C, and D. By default, the certification level/reliability standard preloaded settings for space missions reflect a class C mission. Table 9.4 below offers general recommendations when modeling for space missions other than class C. Certification Level / Reliability Standard Class Recommendation A, B Increase C No change; default settings reflect class C payloads D Nom+ Table 9.4 Certification Level / Reliability Standard Parameter Recommendation

32 10 Modeling Instruments Instruments are the devices that perform the primary mission functions. An instrument or instruments make up a payload which can carry out different types of functions. Instrument types include surveillance, field, imaging, radar, etc. This section focuses on the modeling of instruments and the common pitfalls to avoid when modeling instruments in SEER. The user should also reference the General Modeling chapter for guidance and recommendations when modeling instruments Instrument Modeling Discussion The main difficulty in modeling instruments is attributable to the large arsenal of instruments that exist to carry out the many different types of functions. This is further exacerbated by the range of selectable components available to use to build an instrument. In other words, an instrument can form from different combinations of components which ultimately can result in numerous configurations for an identical or similar function. For example, the telescope of an imager can be of many different configurations, the material of the telescope can vary, the size of the telescope can range from small to large, etc. SEER provides an array of application knowledge bases to reflect the components that are being used for instruments. It is imperative for the user to identify (use the Help) and apply the most correct application knowledge bases for an accurate estimation. This means that the user should look beyond the mechanical and electronics element type and use the EOS and IC element types as appropriate. For example, a CCD detector can be modeled using the Electro-Optical Sensor application KB in the mechanical element type, but the user should consider using the Si CCD application KB within the EOS-Detector element type for a better approximation. The Electro-Optical Sensor application KB can be viewed as a general KB encompassing a wide array of detectors whereas the Si CCD application KB is specifically geared towards estimating CCD detectors. SEER has been used and validated for many instruments. In using the SEER tool to model instruments, there are general guidance to follow to help the user model instruments in the most cleanest and logical way possible in order to produce a good SEER project file. To capture a proper reflection of an instrument, all significant pieces that make up the instrument should be modeled in SEER. This is the best method to adequately capture the technical and heritage details that describe each component. Modeling the instrument components at an assembled level may not be a true reflection of that instrument due to missing proper technical and heritage details, and modeling the instrument at the lowest level, e.g. nuts and bolts, may be too time-consuming. Use rollups to organize the instruments into major sections. For example, an instrument may be composed of an optics section, detector section, electronic section, structural section, etc. Organizing the model into major sections reflects the project in a structured manner and makes the model clear to the user and audience. Do not focus only on the Master Equipment List (MEL). The MEL is a great starting point when starting to build your model. The MEL usually contains the key components required to make the instrument. However, there are situations in which the MEL is limited in information. The user will need to look beyond the MEL and look at other documentation that discusses the instrument, includes block diagrams or other images, or any other relevant information. Piecing the information from the documentation and MEL can provide the best picture of the actual instrument which ultimately lead to a better reflection and approximation of the instrument in the model. In the case that indirect sources of information is inadequate, the user must work closely with the engineers or managers to obtain as much of a complete view of the instrument as possible Instrument and Instrument Suites A payload can consist of a single instrument or multiple instruments. A single instrument payload or a multiple instruments payload would include the hardware unique to the instrument or instruments. However, there may also be other hardware that is considered common such as the electronics and mechanical components such as an enclosure. The multiple instruments payload is called a suite. A suite may share common electronics, sometimes called the data processing unit. In other words, there may be a single assembly of electronics in which the instruments of a suite will utilize.

33 There may be cases in which the user may want to expand the use of the System Level Costs (SLC) in SEER. If there are any instruments of a suite that are built, not by the primary, but by a subcontractor, then there may be justification to activate SLC to reflect any extra system level efforts for that instrument Instrument Examples Below are some common instrument types in which the SEER tool was utilized to model and validate. While this list may be specific to an instrument, the user can generalize the information to relatable instruments as there are instruments which share common elements in between. Understand that the examples below focuses on the hardware that is unique to the instrument and so discussion on modeling common elements such as the electronics, software, or mechanical e.g. enclosures of an instrument has been omitted Direct-sensing Instruments Direct-sensing instruments are instruments in which they take direct measurements of the intended target and does not manipulate the measurement into a different form. Examples include field instruments, mass spectrometers, etc. Examples below exclude the electronics, software, or mechanical e.g. enclosures that may be associated with each instrument example. These components or assemblies will need to be modeled separately. Modeling recommendations are presented below but users should use the most correct options whenever possible Field Instruments Field instruments include magnetometers, search coil sensors, dust sensors, electric field sensors, etc. Essentially, these are instruments that are used to measure the target s direct physical characteristics like the magnetic field, electric field, etc. When modeling field instruments, the sensors of the field instruments are viewed as standalone components. This means that there aren t multiple components to model to reflect the sensor piece of a field instrument. For example, a magnetometer sensor is viewed as its own component in SEER and so using one element to model the magnetometer sensor is sufficient. For field instrument sensors, it is recommended to use the Space Field Sensor application KB under the mechanical element type. Note that the Space Field Sensor Help states that associated electronics are not included and so will need to be modeled separately if applicable Mass Spectrometer Mass spectrometers are instruments that measure the mass of ionized particles or molecules to identify the amount and type of the measured samples. They come in different configurations: quadrupole, time-of-flight (TOF), ion trap, and more. There may be differences in the components that are used depending on the various mass spectrometer configurations. However, the basic building blocks of a mass spectrometer are defined by these subassemblies: sample introduction, ion source, mass analyzer, and detector. These subassemblies are mainly built out of mechanical pieces that are complex in fit and form. It is recommended to use the Precision Mechanism, Optical, and Primary Structure, Complex application KBs under the mechanical element type as it reasonably captures the mechanical pieces. Use the Help to identify which application KB is best fit when modeling the components of a mass spectrometer. Again, while these are recommendations, other applications KBs may offer a better characterization of mass spectrometer components. It is also recommended to raise the complexity of fit, complexity of form, and construction process to a level that reflects the development and fabrication of the mass spectrometer components. For the detector of a mass spectrometer which include electron multipliers, faraday cups, microchannel plate, etc., it is recommended to use the Space Photon Detector application KB under the mechanical element type. Note that the Space Photon Detector Help states that any associated high voltage power supply is not included and so will need to be modeled separately if applicable. Mass spectrometers may also have another subassembly which is the electronics that processes the data produced from the mass spectrometer. These electronics will need to be captured and modeled as separate elements.

34 Remote-sensing Instruments Remote-sensing instruments are instruments in which the measurements taken are processed or characterized to output indirect information about the source. Examples include imagers, LIDARs, radars, etc. Examples below exclude the electronics, software, or mechanical e.g. enclosures that may be associated with each instrument example. These components or assemblies will need to be modeled separately. Modeling recommendations are presented below but users should use the most correct options whenever possible Imager An imager captures and direct the light to another section of the instrument. These optical devices include cameras, telescopes, microscopes, etc. In SEER, the type of imager will determine which application KB under the EOS-Optical Device element type to use. Within the EOS-Optical Device element type, there is the Reflective telescope application KB and Refractive telescope application KB with variations of both. A general rule of thumb is that if a telescope uses mirrors, it is a reflective telescope; if a telescope uses lenses, it is a refractive telescope. For example, a Cassegrain telescope is a two mirrors optical configuration. Cassegrain telescopes are modeled using the reflective telescope. A Galilean telescope is a two lens optical configuration. Galilean telescopes are modeled using the refractive telescope. The optical elements, e.g. mirrors, lenses, filters, etc., within an imager is modeled in the imager element. The Reflective and Refractive application KBs have the imaging and nonimaging parameters to reflect the optical elements contained in an imager LIDAR or Laser Altimeter LIDAR (Light Detection and Ranging) or laser altimeter are instruments that target an object using laser light to generate an image of the target based on the backscattered data. These instruments typically contains several major assemblies which includes a laser assembly, transmitter optics assembly, and scanner optics assembly. SEER offers several laser types and can be found within the EOS-Laser element type. For the transmitter optics and scanner optics assemblies, SEER recommends the use of the reflective and refractive telescopes under the EOS-Optical Device element type. These optics assemblies include optical elements, e.g. mirrors, lens, filters, beam expanders, beam splitters, etc., and must be captured in the optic assemblies work elements Radar A radar (Radio Detector and Ranging) is an instrument that uses radio waves to measure the characteristics about a target. The antenna is a major element of a radar instrument. Antennas can be found within the Mechanical element type and SEER offers different variations of antennas. Use the Help to identify which antenna application KB is best fit Other Optical Processing An imager instrument is commonly configured in combination with an optical processing section. This section can be a spectrometer, interferometer, etc. The optical processing section performs the measurement of the electromagnetic radiation. In short, the imager captures and directs the electromagnetic radiation into the optical processing section in which the radiation is then processed. The configuration has the imager being at the forefront of the instrument and the optical processing section placed after the imager. Usually this separation is evident by a slit, which divides the imager and the optical processing section. (The slit is part of the optical processing section when modeling in SEER.) The optical processing system is modeled using the Optical Bench application KB within the EOS-Optical Device element type. The optical processing system contains optical elements e.g. mirrors, lens, filters, gratings, etc. The optical elements contained in an optical processing system will need to be reflected in the modeled optical bench element which has the imaging and non-imaging parameters.

35 11 Modeling Spacecraft The spacecraft is the lifeline to the payload. It is the infrastructure in which it supports and accommodates the payload. Depending on the needs of the payload, there are usually seven subsystems of the spacecraft identified: structures & mechanisms, thermal, electrical power & distribution, attitude determination and control, propulsion, communications, and command & data handling. The following provides brief description of each subsystem and specific modeling guidance I. Structures & Mechanisms: provides the structure and support for the other spacecraft subsystems and the accommodated payload. II. Thermal: provides the necessary hardware to maintain the desired temperature for the other spacecraft bus subsystems and the accommodated payload. III. Electrical Power & Distribution: provides the source, regulation, control, distribution, and storage of electrical power to the other spacecraft bus subsystems and the accommodated payload. IV. Attitude Determination and Control: provides the actuation, stabilization, and pointing required by the spacecraft and payload. V. Propulsion: provides the necessary force to adjust and maneuver the spacecraft. (This is the only subsystem which might not be required depending on mission requirements.) VI. Communications: provides the communication support for the spacecraft to the ground or other orbiting stations. VII. Command & Data Handling: handles and distributes commands to the other spacecraft subsystems and the accommodated payload Spacecraft Modeling Discussion Modeling the spacecraft is more straightforward than modeling instruments in the sense that each spacecraft includes the subsystems described above and that each spacecraft subsystem contains hardware that are common between spacecraft busses. For example, the attitude determination and control subsystem usually contains reaction wheels, inertial measurement unit, sun sensors, and star trackers. If it is an Earth mission, the ADCS could also contain torque rods, magnetometers, etc. The point is that the spacecraft subsystems are usually routine in the components that they contain. This is contrasting to the instruments in which the instruments can contain many different combinations of hardware which can be difficult to consistently model. When modeling spacecraft systems, one can usually see a pattern in the elements used and the types of elements used. Generally, the spacecraft subsystem is built using the mechanical, electronics, and the IC-FPGA element types. It is uncommon to see EOS elements or other IC elements used in the spacecraft. As previously discussed, the spacecraft subsystems contain common hardware. SEER contains application KBs to reflect the common hardware. For example, a reaction wheel is reflected using the space reaction wheel application KB. However, this does not mean that there is an application KB for every hardware of a spacecraft. But it is straightforward to find an application KB to capture a spacecraft hardware element albeit the application KB may have a general description. For instance, a command board element can be modeled using the data processor application KB within the electronics element type. They might not match in the name, but they match in functionality. The points below are general tips to follow when modeling spacecraft systems. Use rollups to organize the spacecraft into the subsystems shown above. Since each subsystem is a major group, organizing by subsystem reflects a logical structure and flow in reflecting the spacecraft system. Do not focus only on the Master Equipment List (MEL). The MEL is a great starting point when starting to build your model. The MEL usually contains the necessary ingredients that make up a spacecraft system. However, there are situations in which the MEL may lack substance in the ingredients it provides. For example, a power distribution unit that weights 20kg is a line item in a MEL. On the surface, it seems appropriate to use the power supply application KB to reflect the power distribution unit. However, the user should notice that weight of the power distribution unit is more than just one electronics card. It may contain multiple electronics card. The user will need to look beyond the MEL and look at other documentation that discusses the spacecraft, includes block diagrams or other images, or any other relevant

36 information. Piecing the information from the documentation and MEL can provide the best picture of the full spacecraft system which ultimately leads to a better reflection and approximation of the spacecraft system in the model. In the case that indirect sources of information is inadequate, the user must work closely with the engineers or managers to obtain as much of a complete view of the spacecraft system as possible Spacecraft and Heritage It is common to see spacecraft systems take heritage from previously flown spacecraft systems. As such, much of the technical information on spacecraft systems would indicate a build-to-print characteristics of the spacecraft hardware. However, generally this is not the case. It is common for programs to use the architecture of spacecraft systems for their own but the effort to build their spacecraft system which would be unique to their program is much more than the effort of a build-to-print. A program s spacecraft system would be unique because of the instruments that it is carrying, unique requirements, the destination factors, environment factors, etc. For example, the spacecraft bus structure is a common element that gets claimed to be a build-to-print. However, if the existing design carried only one instrument but the proposed design carries two instruments, the spacecraft bus structure has changed to accommodate the other instrument. However, because it needs to accommodate the other instrument, the configuration to fit this second instrument has changed. Because of this new configuration, the configuration for the spacecraft subsystems have changed. So to summarize, just because a spacecraft system shares the architecture of an existing design, this does not mean that the proposed design is automatically a build-to-print, but, instead, may require engineering effort. To illustrate an electronic, a command board may be claimed to be a build-to-print. However, if the environment of the existing design differs from the proposed design, new tests will have to be performed to stress the proposed design in the relevant environment. This is effort on the claimed build-to-print which does not reflect that effort. Even configuration changes can impact the effort required. A configuration change in which components are placed differently from an existing design may alter the temperature of the component, requiring effort to run additional thermal analysis to make sure the configuration of the proposed design works. To be succinct, be hesitant about an element s readiness as it may require more effort than what is initially perceived Common Parameters Guidance for Spacecraft The common parameters below correspond to the common parameters discussed in the Modeling in SEER chapter. Refer to the chapter for more information Design Complexity Select components in the spacecraft utilizes advanced materials or designs which increases the engineering effort for said components. Below are the spacecraft subsystems in which components utilize advanced technology is common and the recommended settings: Electrical Power & Distribution This recommendation is mainly for solar arrays in which solar array designs are able to utilize advanced materials such as advanced triple junction diodes, optoreflectors, etc. Propulsion It is recommended that all components under propulsion apply the settings below in which dual mode (bipropellant and monopropellant system) or other advanced propulsion systems are used. All components are affected when using an advanced propulsion system due to the increased complexity in design. Recommended Settings Parameter Least Likely Most Design Complexity Hi- Hi Hi+ Table 11.2 Design Complexity Recommended Settings 11.4 Other Parameters Guidance for Spacecraft Material Composition There are mechanical/structural components which can be heavily affected by the material makeup. For example, a spacecraft bus made of composite will be more expensive to build than a spacecraft bus made of aluminum. Aluminum is a material

37 in which the process of using said material is common and well-defined whereas composite is a material that requires more effort in its use. Below are the spacecraft subsystems in which components can be significantly affected by the material composition: Structure & Mechanisms Propulsion These two spacecraft subsystems are composed mainly of mechanical/structural components which is why material composition can play a huge role in their final value. The recommendation below is how to use the material composition parameter if data is known but not clear and if no data is known: Parameter Material Composition Recommendation Use the following if actual allocation is unavailable: If only one material is stated, that material in the material composition parameters should be set to 100% while zeroing the non-used materials. If two materials are stated, each respective material should be set to 50% while zeroing the non-used materials. If no materials are stated, use SEER s default values. Table 11.3 Material Composition Recommendation Clock Speed This parameter is applicable to all electronic boards and should be inputted if possible. It characterizes the speed of digital boards or the frequency of analog boards. However the frequency of RF boards can vary greatly and so this can be a defining parameter for RF boards. The user should define the operating frequency S-band, X-band, K-band, etc. for RF boards, which are mainly in the communication subsystem Specific Guidance by Spacecraft Subsystems Structures & Mechanisms Spacecraft Structure application KB 1. Components identified as a primary structure or secondary structure should be combined mass-wise and modeled as one element using the Spacecraft Structure (mechanical element) application KB. The Spacecraft Structure KB was created and calibrated to this technique. 2. The recommended baseline acquisition category for the Spacecraft Structure KB is Modification Major. See section 11.2 Spacecraft and Heritage. 3. The Complexity of Form parameter should be adjusted to account for the number of payload instruments. The increasing number of payload instruments increases the complexity of the spacecraft bus structure to accommodate the payload. See table below for settings. # of instruments Least Likely Most 8 VHI VHI VHI+ 7 VHI VHI VHI 6 VHI- VHi VHi 5 VHI- VHI- VHI- 4 VHI- VHI- VHI- 3 HI+ VHi- VHi- 2 HI+ HI+ HI+ 1 HI HI HI Table 11.4 Spacecraft Structure Complexity of Form Recommendation based on # of Instruments

38 Thermal Thermal applications KBs The recommended baseline acquisition category for any thermal components, which includes Thermal Control, Active, Thermal Control, Passive, MLI, Painting, Coating, or Space Radiator / Heat Pipe, is Modification Major. See section 11.2 Spacecraft and Heritage Electrical Power & Distribution Currently, no specific guidance exists for EP&D Attitude Determination and Control Attitude Determination and Control application KBs The recommended baseline acquisition category for any ADC common components, which includes Space Sun Sensor, Space Field Sensor, Space Inertial Measurement Unit, Space Reaction Wheel, Star Tracker Complex or Standard, or Reaction Wheel Control Space, is Space Procure to Print. The components under this subsystem is majorly similar from mission to mission as these components are widely known and used Propulsion Chemical Propulsion Systems It is recommended to raise the Design Complexity parameter to Hi-/Hi/Hi+ for a Dual Mode (bipropellant and monopropellant) propulsion system. This parameter should be raised for the following application KBs: Space Propulsion Tankage, Space Propulsion Component, and Thruster, Space Electric Propulsion System When using the Space Propulsion Tankage, Space Propulsion Component, and Thruster, Space application KBs, use the following settings: Recommended Settings for Electric Propulsion System Parameter Least Likely Most Complexity of Form VHi+ EHi- EHi Complexity of Fit VHi+ EHi- EHi Construction Process Hi+ VHi- VHi Space Propulsion Component application KB 1. Propulsion parts, which includes lines, fittings, valves, filters, transducers, etc., can be combined mass-wise and modeled as one element using the Propulsion Components KB. The Propulsion Components KB was created and calibrated to this technique. 2. The recommended baseline acquisition category is Make. Due to unique mission requirements, the configuration of the propulsion system may change, requiring a custom design.

39 Communications Clock Speed Parameter The operating frequency of RF boards can vary greatly and so this can be a defining parameter for RF boards. The user should define the operating frequency S-band, X-band, K-band, etc. for RF boards Space RF Component application KB 1. RF components, which includes diplexers, switches, couplers, etc., can be combined mass-wise and modeled as one element using the RF Components KB. The RF Components KB was created and calibrated to this technique. 2. The recommended baseline acquisition category is Make. Due to unique mission requirements, the configuration of the RF system may change, requiring a custom design Command & Data Handling Currently, no specific guidance exists for C&DH.

40 12 CubeSat CubeSats are miniaturized satellites of limited mass that have a cube-shape standard form. Standard physical dimension is indicated by U and each 1U is about 10 x 10 x 10 cm 3. They can be deployed as 1U, 1.5U, 2U, 3U, 6U, and higher. CubeSats are a subset of Nano/Microsatellites in terms of weight which in turn are a subset of the Small Satellite family. See Figure According to NASA, CubeSats are classified as Class D missions. The benefits of using CubeSat are fewer part count, short mission durations for fast results, short development to launch cycle, and lower cost. They can be used for a variety of objectives including science investigations, science experiments, technology demonstrations, or educational purposes. The following guidance for CubeSats is intended for science investigations. Caution: Due to CubeSats being relatively new technology applications for NASA science investigations, the recommendations in this chapter may change considerably in the future. Figure 12.1 CubeSat in the SmallSat family 12.1 Modeling CubeSats CubeSats follow the Complete Mission structure. A CubeSat consists of a payload to perform science measurements and a spacecraft bus to support the payload Acquisition Category CubeSats are prevalently built from COTS components. Due to their level of simplicity in design and development requirements, the acquisition category baseline is Space Procure to Print. The acquisition category definitions are redefined below to reflect the CubeSat development. The user should not be confined to the limited scope of acquisition categories below. However, these specific acquisition categories were used to model general cases of different levels of readiness. Users should use the most applicable acquisition categories based on element information at hand. Acquisition Categories Approach Definitions adjusted for CubeSat elements Build to Print Adjust to as required Existing design that requires the bare minimum engineering effort to fit into the system configuration.