SEER-H Space Guidanceseer-university.galorath.com/.../06/SEER-H_Space_Guidance_v2.0.pdf · This...

GALORATH SEER-H SPACE GUIDANCE APRIL 25, 2016

SEER-H

Space Guidance Revision 2.0

April 25, 2016


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

5.1.1. Mission Level 5.1.2. Instruments Under Payload Level 5.1.3. Spacecraft Bus Level

5.2. SEER Costs Mapping to NASA WBS for Complete Mission 5.3. SLC for Instrument-only Mission

5.3.1. Mission Level 5.3.2. 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

9.6.1. Mechanical Element Type 9.6.1.1. Weight 9.6.1.2. Material Composition

9.6.2. Electronics Element Type 9.6.2.1. Total Printed Circuit Board

9.6.3. EOS Element Types 9.6.3.1. EOS Optical Device Element Type – Reflective Telescope, Refractive Telescope, and Optical Bench

9.6.3.1.1. Reflective Telescope 9.6.3.1.1.1. Standard versus Lightweight 9.6.3.1.1.2. With or Without Scan Mirror

9.6.3.1.2. Refractive Telescope 9.6.3.1.3. Optical Bench 9.6.3.1.4. Modeling Spares for Optical Elements

9.6.4. Custom Integrated Circuit Element 9.6.4.1. IC Element Structural Modeling Recommendations 9.6.4.2. FPGA Modeling Guidance

9.6.4.2.1. Side note on FPGAs 9.7. Contributed Hardware and Government Furnished Equipment

9.7.1. GFE/Contribution can be modeled 9.7.2. GFE/Contribution cannot be modeled but the cost is known

9.8. Common Parameters to Consider 9.8.1. Design Complexity 9.8.2. Certification Level / Reliability Standard

10. Modeling Instruments 10.1. Instrument Modeling Discussion 10.2. Instrument and Instrument Suites 10.3. Instrument Examples

10.3.1. Direct-sensing Instruments 10.3.1.1. Field Instruments 10.3.1.2. Mass Spectrometer

10.3.2. Remote-sensing Instruments


10.3.2.1. Imager 10.3.2.2. LIDAR or Laser Altimeter 10.3.2.3. Radar

10.3.3. Other 10.3.3.1. Optical Processing

11. Modeling Spacecraft 11.1. Spacecraft Modeling Discussion 11.2. Spacecraft and Heritage 11.3. Common Parameters Guidance for Spacecraft

11.3.1. Design Complexity 11.4. Other Parameters Guidance for Spacecraft

11.4.1. Material Composition 11.4.2. Clock Speed

11.5. Specific Guidance by Spacecraft Subsystems 11.5.1. Structures and Mechanisms

11.5.1.1. Spacecraft Structure application KB 11.5.2. Thermal

11.5.2.1. Thermal application KBs 11.5.3. Electrical Power & Distribution 11.5.4. Attitude Determination and Control

11.5.4.1. Attitude Determination and Control application KBs 11.5.5. Propulsion

11.5.5.1. Chemical Propulsion System 11.5.5.2. Electric Propulsion System 11.5.5.3. Space Propulsion Component application KB

11.5.6. Communications 11.5.6.1. Clock Speed Parameter 11.5.6.2. Space RF Component application KB

11.5.7. Command & Data Handling 12. Cubesat

12.1. Modeling CubeSats 12.1.1. Acquisition Category 12.1.2. Parameters

12.1.2.1. Certification Level / Reliability Standard 12.1.2.2. Production Tools and Practices 12.1.2.3. Production Learning Curve

12.1.3. Element Types and Application KBs 12.1.3.1. Mechanical/Structural Element Type 12.1.3.2. Electronic Element Type 12.1.3.3. EOS Element Types

12.1.4. System Level Cost for CubeSats


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.


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) 7120.5, 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.


• 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 project-

owned facilities required to perform the integration and testing of the project's systems, payloads, spacecraft, launch

vehicle/services, and mission operations.


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.


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


bus level (1.1.2). The payload level includes one (1.1.1.1) or more instruments (1.1.1.2, 1.1.1.N). The spacecraft bus level includes

the structure & mechanisms (1.1.2.1), thermal (1.1.2.2), electrical power & distribution (1.1.2.3), propulsion (situational) (1.1.2.4),

attitude determination & control (1.1.2.5), communications (1.1.2.6), and command & data handling (1.1.2.7) 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 (1.1.1.1) or more instruments (1.1.1.2, 1.1.1.N). In most cases, an Instrument-only

Mission only has one instrument (1.1.1.1). 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.


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.

5.1.1 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.

Table 5.1 Mission SLC for Complete Mission

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


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.

Table 5.2 Payload Level SLC for Complete Mission

5.1.3 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.

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.3 Spacecraft Bus SLC for Complete Mission

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 - - -


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.

SEER Costs Mapped to NASA WBS for Complete Mission SEER WBS Level

NASA WBS Project Payload Spacecraft

WBS 01 – Project Management

WBS 02 – Systems Engineering

WBS 03 – Safety & Mission Assurance

SEI + SPM

WBS 10 – Systems Integration & Testing STO + SSE

WBS 05 – Payload Subsystem Total + SEI + IAT + SPM

WBS 06 - Spacecraft Subsystem Total + SEI + IAT + SPM

Table 5.4 SEER Costs Mapped to NASA WBS for Complete Mission


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.

5.3.1 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.

Table 5.5 Mission SLC for Instrument-only Mission

5.3.2 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-

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


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.

SEER Costs Mapped to NASA WBS for Instrument-only Mission SEER WBS Level

NASA WBS Project Payload

WBS 01 – Project Management

WBS 02 – Systems Engineering

WBS 03 – Safety & Mission Assurance

SEI + SPM

WBS 10 – Systems Integration & Testing STO + SSE

WBS 05 – Payload Subsystem Total + SEI + IAT + SPM

Table 5.7 SEER Costs Mapped to NASA WBS for Instrument-only Mission


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 7.3.29 which contains the settings shown

above. Go to Post SEER-H 7.3.29 Kbases (Pending Release) to download the created KBs.

Created SLC Application KBs post model 7.3.29 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.


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.


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.


Specific Acquisition Category guidance on Application KB

Application KB Element Type Acquisition Category Basis

Camera Optical Assy or Optical

Bench EOS Optical Device 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.

Space Harness Mechanical Make Due to unique mission requirements, most harnesses are custom designed.

Space RF Components Mechanical Make

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.

Space Propulsion Parts Mechanical Make

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.

Spacecraft Structure Mechanical Modification – Major

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.

Mechanical/Electronics Space Procure to Print

ADCS components are typically COTS and require only engineering effort to fit into the system configuration. Attitude

Determination and Control* Other Modification –

Average 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


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.


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.


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

Quantity Production

Quantity Definition

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 1.5 0

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


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


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.

9.6.1 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.


9.6.1.1 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.

9.6.1.2 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.

9.6.2 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.

9.6.2.1 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.


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.

9.6.3.1 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.

9.6.3.1.1 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.

9.6.3.1.1.1 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.


9.6.3.1.1.2 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.

9.6.3.1.2 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.

9.6.3.1.3 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.

9.6.3.1.4 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.


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.

9.6.4.1 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

9.6.4.2 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


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 100,000 150,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.

9.6.4.2.1 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.

9.7.1 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.


251664384

9.7.2 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.


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.

9.8.1 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.

9.8.2 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 8705.4 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


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.

10.1 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.

10.2 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.


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.

10.3 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.

10.3.1 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.

10.3.1.1 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.

10.3.1.2 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.


10.3.2 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.

10.3.2.1 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 “non-

imaging” parameters to reflect the optical elements contained in an imager.

10.3.2.2 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.

10.3.2.3 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.

10.3.3 Other

10.3.3.1 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.


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.

11.1 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


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.

11.2 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.

11.3 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.

11.3.1 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

11.4.1 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


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 Recommendation

Material Composition

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

11.4.2 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.

11.5 Specific Guidance by Spacecraft Subsystems

11.5.1 Structures & Mechanisms

11.5.1.1 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


11.5.2 Thermal

11.5.2.1 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.

11.5.3 Electrical Power & Distribution

Currently, no specific guidance exists for EP&D.

11.5.4 Attitude Determination and Control

11.5.4.1 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.

11.5.5 Propulsion

11.5.5.1 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’

11.5.5.2 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

11.5.5.3 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.


11.5.6 Communications

11.5.6.1 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.

11.5.6.2 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.

11.5.7 Command & Data Handling

Currently, no specific guidance exists for C&DH.


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 cm3. 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 12.1.

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.

12.1.1 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.


Space Procure to Print Baseline Existing design but requires little to some engineering effort to fit into the system configuration.

Modification Average Adjust to as required Elements requiring significant effort to fit into the system configuration. Acquisition categories beyond Modification – Average are not recommended.

Table 12.1 Acquisition Categories Overview

12.1.2 Parameters

12.1.2.1 Certification Level / Reliability Standard

CubeSats are classified as Class D missions and share similar level of difficulty in development requirements. It is

recommended to follow section 9.8.2 and adjust to the following inputs:

Certification Level / Reliability Standard Class Recommendation

D, CubeSats Nom+

12.1.2.2 Production Tools and Practices

The environment of producing CubeSat components is more efficient than standard space production environments.

Therefore, the following settings are recommended:

Parameter Least Likely Most Production Tools & Practices Low- Low Low+

12.1.2.3 Production Learning Curve

There are situations where a CubeSat mission can have a high volume of flight units. In situations where these missions

can benefit from greater learning, then use the following setting:

Parameter Least Likely Most Production Learning Curve for

high volume mission 85%

12.1.3 Element Types and Application KBs

Some application KBs have been found not to be appropriate for CubeSat missions. Use the following recommendations

when modeling CubeSat missions.

12.1.3.1 Mechanical/Structural Element Type

Mechanical/Structural Element Type application KB

Parameter Least Likely Most

• Use for minor structure or mechanisms, such as mounts, hinges, etc. Complexity of Form Hi- Hi+ VHi-

Complexity of Fit Nom- Nom+ Hi- Secondary Structure

Construction Process Hi VHi- VHi Primary Structure,

Complex • Use for payload major structures

• Use for space radiators or heat pipes Thermal Control – Active • DO NOT use Space Radiator/Heat Pipe application KB

• Use for inertial measurement units Gyro • DO NOT use Space Inertial Measurement Unit application KB • Use for star trackers and sun sensors • DO NOT use Star Tracker – Standard or Complex application KB Star Sensor • DO NOT use Space Sun Sensor application KB


12.1.3.2 Electronics Element Type

Electronics Element Type application KB Parameter Least Likely Most

All* • Use “least” default value and apply to “likely” and “most” inputs for the Integrated Circuits per PCB

parameter • *Exception: Power Supply, Low Voltage application KB

12.1.3.3 EOS Element Types

KB Recommendation

Acquisition Category for all EOS application KBs Modification – Average

12.1.4 System Level Cost for CubeSats

The Complete Mission SLC settings (section 5.1) can be used for CubeSats. For each instrument under the CubeSat

Payload, apply the settings recommended in section 5.1.2. For the CubeSat Spacecraft Bus, apply the settings recommended in

section 5.1.3. However, note that for the CubeSat Mission level, calibration adjustments were made to the Mission level settings

(section 5.1.1) which are captured in the newly created “Space – Mission Level SLC for CubeSat” application KB. Go to Post SEER-

H 7.3.29 Kbases (Pending Release) to download this created KB. This KB will be officially released in the next maintenance release.

Note: Set Platform KB to ‘!No Knowledge” when using this application KB.

SEER-H Space Guidanceseer-university.galorath.com/.../06/SEER-H_Space_Guidance_v2.0.pdf · This...

Documents

Transcript of SEER-H Space Guidanceseer-university.galorath.com/.../06/SEER-H_Space_Guidance_v2.0.pdf · This...