A template for serializing the Space Mission Analysis & Design (SMAD) process using the hypothetical 'FireSat' space mission.

space_mission_firesat.yaml

# This yaml file is a (draft) template for serializing the Space Mission
# Analysis & Design (SMAD) process using the hypothetical 'FireSat' space
# mission from the SMAD handbook, by Wiley Larson & James Wertz (3rd edition).
#
# More info on yaml syntax and usage can be found here:
# https://learnxinyminutes.com/docs/yaml/
# yaml files can be validated on http://www.yamllint.com/

#####################
# Mission Statement #
#####################

mission_statement:
    # The hypothetical FireSat mission will used as the primary example for
    # illustrating the steps of the space mission analysis and design process.
    Because forest fires have an increasing impact on recreation and commerce
    and ever increasing public visibility, the United States needs a more
    effective system to identify and monitor forest fires. In addition, it would
    be desirable (but not required) to monitor forest fires for other nations;
    collect statistical data on fire outbreaks, spread, speed, and duration and
    provide other forest management data.

#####################
# Define Objectives #
#####################

define_objectives:
    ## Step 1: Define Objectives and Constraints (Section 1.3)
    mission_objective:
        # Unlike requirements, which specify numerical levels of performance, the
        # mission objectivs are broad statements of what the system must do to be useful.
        primary_objective:
            - To detect, identify and monitor forest fires throughout the United
                States, including Alaska and Hawaii, in near real time.
        secondary_objective:
            - To demonstrate to the public that positive action is underway to
                contain forest fires
            - To collect statistical data on the outbreak and growth of forest fires
            - To monitor forest fires for other countries
            - To collect other forest management data.

    ## Step 2: Estimate quantitative mission needs and requirements (Section 1.4)
    top_level_mission_requirements:
        # We typically subdivide these top-level requirements into more specific
        # requirements applicable to specific space missions.
        functional:
            # how well the system has to perform to meet its objectives.
            performance:
                # factors impacting this requirement include the primary mission
                # objective, payload size, orbit, pointing
                - 4 temperature levels
                - 30 m resolution
                - 500 m location accuracy
            coverage:
                # Impacting factors include orbit, number of satellites, scheduling
                Daily coverage of 750 million acres within continental U.S.
            responsiveness:
                # Impacting factors include communications architecture, processing
                # delays, operations
                Send registered mission data within 30 min to up to 50 users
            secondary_mission:
                # In FireSat example, this would include additional measurement
                # channels for forest management data (e.g. pest control)
                4 temperature levels for pest management
        operational:
            # - how the system operates
            # - how the users interact with the system to achieve the mission’s
            # broad objectives
            duration:
                # factors impacting this requirement include nature of the mission
                # (experimental or operational), level of redundancy, orbit
                # (e.g., altitude)
                Mission operational fat least 10 years
            availability:
                # Impacting factors include level of redundancy
                - 98% excluding weather
                - 3-day maximum outage
            survivability:
                # Impacting factors include orbit, hardening, electronics
                Natural environment only
            data_distribution:
                # Impacting factors include communications architecture
                - Up to 500 fire-monitoring offices
                - +2000 rangers worldwide (max. of 100 simultaneous users)
            data_content_form_format:
                # Impacting factors include user needs, level and place of
                # processing, payload
                Location and extent of fire on any of 12 map bases, average
                tempurature for each 30 m^2 grid
        constraints:
            # limitations imposed on system designer by cost, schedule, and
            # implementation techniques
            cost:
                # Impacting factors include manned flight, numbers of spacecraft,
                # size and complexity, orbit
                - < $20M/yr + R&D
            schedule:
                # Impacting factors include technical readiness, programme size
                - Initial operating capability within 5 yrs
                - Finial operating capability within 6 years
            regulations:
                # Impacting factors include law and policy
                NASA mission
            environment:
                # Impacting factors include orbit & lifetime
                Natural
            interfaces:
                # Impacting factors include level of user and operator infrastructure
                - Comm, relay, and interoperable through NOAA ground stations
            development_constraints:
                # Impacting factors include Sponsoring organisation
                - Launch on STS or expendable
                - No unique operations people at data distribution nodes

############################
# Characterize the Mission #
############################

mission_characterization:
    ## Step 3: Define alternative mission concepts (Section 2.1)

    # elements_of_mission_concept_of_operations:
        # The 'mission concept' is a broad statement of how the mission will work in
        # practice. The 'mission operations' provide details of how people will
        # operate and control the mission.The 'mission architecture' is the mission
        # concept plus a definition of each of the manor elements of the mission.
        # data_delivery:
            # Definition: How mission and housekeeping data are generated or
            # collected, distributed, and used (FireSat example: How is imagery
            # collected? How are forest fires identified? How are the results
            # transmitted to the fire fighting teams on the ground?
            # - How is imagery collected?
            # - How are forest fires identified:?
            # - How are the results transmitted to the fire fighter in the field?
        # communications_architecture:
            # Definition: How the various components of the system talk to each other
            # - What communications network is used to transmit forest fire data to
            #     the users in the field?
        # tasking_scheduling_and_control:
            # Definition: How the system decides what to do in the long term and the
            # short term (e.g., Which sensors are active and when is data being
            # transmitted and processed?)
            # - What sensors are active and when is data being transmitted and
            #     processed?
            # - Which forested areas are receiving attention this month?
        # mission_timeline:
            # Definition: overall schedule for planning, building, deployment,
            # operations, replacement, and end-of-life
            # - When will the first FireSat become operational?
            # - What is the schedule for satellite replenishment?

    process_for_defining_mission_concept_of_operations:
        # Defining the mission concept consists of defining the various
        # options that are available and then selecting the most appropriate.
        step-1:
            definition: |
                Define data delivery process for
                * Mission and housekeeping data
            key-trades:
                - Space vs. Ground processing
                - Level of autonomy
                - Central vs. distributed processing
        step-2:
            definition: |
                Define tasking, scheduling, and control for
                * Mission and housekeeping data
                * Long term and short term
            key-trades:
                - Level of autonomy
                - Central vs. distributed control
        step-3:
            definition: |
                Define communications architecture for
                * Mission and housekeeping data
            key-trades:
                - Data rates bandwidth
                - Timeliness of communications
        step-4:
            definition: |
                Define preliminary mission timeline for
                * Concept development
                * Production and deployment
                * Operations and end-of-life
            key-trades:
                - Replenishment and end-of-life options
                - Deployment strategy for multiple satellites
                - Level of timeline flexibility
        step-5:
            definition:
                Iterate and document
            key-trades:
                - N/A

    mission_timeline:
        # Key milestones in the mission or project timeline
        planning_and_development:
            drivers:
                - Funding constraints
                - System need date
        production:
            drivers:
                - Funding constraints
                - Technology development
                - System need date
        initial_launch:
            drivers:
                - Funding constraints
                - System need date
        constellation_build-up:
            drivers:
                - Production schedule
                - Launch availability
                - Satellite lifetime
        normal_mission_operations:
            drivers:
                - Planned operational life
                - Satellite lifetime (planned or failure constrained)
        replenishment:
            drivers:
                - Production schedule
                - Launch availability
                - Satellite lifetime (planned or failure constrained)
        end-of-life_disposal:
            drivers:
                - Legal and political constraints
                - Danger to other spacecraft

    ## Step 4: Define alternative mission architectures (Section 2.2)

    # identify_alternative_mission_architectures:
    #     - Identify the mission elements subject to trade.
    #     - Identify the main options for each tradeable element.
    #     - Construct a trade tree of available options.
    #     - Prune the trade tree by eliminating unrealistic combinations.
    #     - Look for other alternatives which could substantially influence how we do the mission.

    tradeable_elements_of_mission_architecture:
        # Selecting FireSat elements which can be traded
        mission_concept:
            can_be_traded:
                Yes
            reason:
                Want to remain open to alternative approaches
        subject:
            can_be_traded:
                No
            reason:
                Passive subject is well defined
        payload:
            can_be_traded:
                Yes
            reason:
                Can select complexity and frequencies
        spacecraft_bus:
            can_be_traded:
                Yes
            reason:
                Multiple options based on scan mechanism and power
        launch_system:
            can_be_traded:
                Cost only
            reason:
                Choose minimum cost for selected orbit
        orbit:
            can_be_traded:
                Yes
            reason:
                Options are low, medium, or high altitude with varying
                number of satellites
        ground_system:
            can_be_traded:
                Yes
            reason:
                Could share NOAA control facility, use dedicated FireSat
                facility, or direct downlink to users
        communications_architecture:
            can_be_traded:
                No
            reason:
                Fixed by mission operations and ground system
        mission_operations:
            can_be_traded:
                Yes
            reason:
                Can adjust level of automation

    common_alternatives_for_mission_elements:
        # This table serves as a broad checklist for identifying the main
        # alternatives for mission architecture elements.
        mission_concept:
            option_area:
                - Data delivery
                - Tasking
            most_common_options:
                - Direct downnnk to user, automated ground processing,
                    man-In-the-Joop processing and transmission
                - Ground commanding, autonomous tasking, simple operations
                    (no tasking required)
            firesat_options:
                - Direct downlink or through mission control
                - Simple operation or ground control
        controllable_subject:
            option_area:
                - Selection
                - Performance
                - Steering
            most_common_options:
                - Standard ground stations, private TV receivers, ship or
                    aircraft transceivers, special purpose equipment
                - EIRP, G/T (See 13.3 for definitions)
                - Fixed or tracking
            firesat_options:
                - N/A
        passive_subject:
            option_area:
                - What is to be sensed
            most_common_options:
                - Subject itseH, thermal environment, emitted radiation,
                    contrast with surroundings
            firesat_options:
                - Heat or visible light, chemical composition; particles
        payload:
            option_area:
                - Frequency
                - Complexity
                - Size vs. sensitivity
            most_common_options:
                -   Communlcalions: normal bands
                    Observations: IR, visible, microwave
                    Radar: L, C, S bands, UHF
                - Single or multiPle frequency bands, single or multIple Instruments
                - Small aperature with high power (or sensitivity) or vice versa
            firesat_options:
                - IR, visible
                - Single or multiple bands
                -  Aperature
        spacecraft_bus:
            option_area:
                - Propulsion
                - Orbit control
                - Navigation
                - Attitude determination and control
                - Power
            most_common_options:
                - Whether needed; cold gas, monopropellant, bipropellant
                - Whether needed, onboard vs. ground
                - Onboard (GPS or other) vs. ground-based
                - None, splnntng, 3-axis; articulated payload vs. spacecraft
                    pointing; actuators and sensors
                - Soler vs. nuclear or other; body-mounted vs. 1- or 2-axis
                    pointed arrays
            firesat_options:
                - Determined by definition of payload and orbit
        launch_system:
            option_area:
                - Launch vehicle
                - Upper stage
                - Launch site
            most_common_options:
                - SSLV, Atlas, Della, STS, Titan, Pegasus, Ariane, other foreign
                - Pam-D, IUS, TOS, Centaur, integral propulsion, other foreign
                - Kennedy, Vandenberg, Kourou, other foreign
            firesat_options:
                - Determined by definition of spacecraft and orbit
        orbit:
            option_area:
                - Special orbits
                - Altitude
                - Inclination
                - Constellation configuration
            most_common_options:
                - None, geosynchronous, Sun-synchronous, frozen, Molnlya,
                    repeating ground track
                - Low-Earth orbit, mlcl-altitude, geosynchronous
                - 0°,28.5°,57",63.4°,90°,98"
                - Number of sateDites; Walker pattem, other patterns; number
                    of orbit planes
            firesat_options:
                - Single GEO satellite, low-Earth constellation
                - Min. inclination dependent on altitude
        ground_system:
            option_area:
                - Existing or dedicated
            most_common_options:
                - AFSCN, NASA control center, other shared system, dedicated system
            firesat_options:
                - Shared NOAA system, dedicated system
        communications_architecture:
            option_area:
                - Timeliness
                - Control and data dissemination
                - Relay mechanism
            most_common_options:
                - Store and dump, real-time link
                - Single or multiple ground stations, direct to user, user
                    commanding, commercial links
                - TDRSS, satellite-to-sateOite crossnnks, commercial
                    communications relay
            firesat_options:
                - Either option
                - 1 ground station; commercial or direct date transfer
                - TDRS or commercial
        mission_operations:
            option_area:
                - Automation level
                - Autonomy level
            most_common_options:
                - Fully automated ground stations, part-time operations,
                    full-time (24-hr) operations
                - Full ground command and control, partial autonomy, full
                    autonomy (not yet readily avaDable)
            firesat_options:
                - Any of the options listed

    # FireSat Trade Tree (WIP)

    # FireSat Mission Concepts
    mission_concept_options:
        option-1:
            mission_concept:
                IR detection of fires with results put on a map and transmitted
            subject:
                Characteristics defined by the specification
            payload:
                Small-aperture IR
            spacecraft_bus:
                Small, 3-axis
            launch_system:
                Pegasus
            orbit:
                Low-Earth, 2 satellites, 2 perpendicular polar planes
            ground system:
                Single, dedicated ground station
            communications_architecture:
                TDRS data downlink; commercial links to users
            mission_operations:
                Continuous during fire season, partial otherwise
        option-2:
            mission_concept:
                IR detection of fires with results put on a map and transmitted
            subject:
                Characteristics defined by the specification
            payload:
                Large-aperture IR
            spacecraft_bus:
                Mid-size, 3-axis
            launch_system:
                STS, integral propulsion
            orbit:
                Geosynchronous, 1 satellite centered over west coast of U.S.
            ground system:
                Single, dedicated ground station
            communications_architecture:
                Direct to station; results relayed to users via FireSat
            mission_operations:
                Continuous during fire season, partial otherwise

    ## Step 5: Identify system drivers for each (Section 2.3)
    common_system_drivers:
        # System drivers can frequently be Identified by examining the parameters in
        # this list.
        driver:
            size:
                what_limits_driver:
                    Shroud or bay size,available weight, aerodynamic drag
                what_driver_limits:
                    Payload size (frequently antenna diameter or aperture)
            On-orbit_weight:
                what_limits_driver:
                    Altitude, Incrmatlon, launch vehicle
                what_driver_limits:
                    Payload weight, survlvabrnty; largely determines design and
                    manufacturing cost
            power:
                what_limits_driver:
                    Size, weight (control Is secondary problem)
                what_driver_limits:
                    Payload & bus design, system sensitivity, on-orblt life
            data_rate:
                what_limits_driver:
                    Storage, processing, antenna sizes, limits of existing
                    systems
                what_driver_limits:
                    Information sent to user; can push demand for onboard
                    processing
            communications:
                what_limits_driver:
                    Coverage, availability of ground stations or relay
                    satellites
                what_driver_limits:
                    Coverage, timeliness, ability to command
            pointing:
                what_limits_driver:
                    Cost, weight
                what_driver_limits:
                    Resolution, geolocation, overall system accuracy; pushes
                    spacecraft cost
            number_of_spacecrafts:
                what_limits_driver:
                    Cost
                what_driver_limits:
                    Coverage frequency, and overlap
            altitude:
                what_limits_driver:
                    Launch vehicle, perlormance demands, weight
                what_driver_limits:
                    Performance, survivability, coverage (instantaneous and
                    rate), communications
            coverage:
                what_limits_driver:
                    Orbit, scheduing, payload field of view & observation time
                what_driver_limits:
                    Data frequency and continuity, maneuver requirements
            scheduling:
                what_limits_driver:
                    Timeline & operations, decision making, communications
                what_driver_limits:
                    Coverage, responsiveness, mission utility
            operations:
                what_limits_driver:
                    Cost, crew size, communications
                what_driver_limits:
                    Frequently principal cost driver, principal error source,
                    pushes demand for autonomy (can also save "lost" missions)

    ## Step 6: Characterize mission concepts and architectures (Section 2.4)
    identification_of_performance_drivers:
        # First-order algorithms are given to allow us to estimate the performance
        # drivers. Definition of performance drivers may change as we create more
        # detailed definitions of the system and system algorithms. Comparison of
        # columns two and three shows that the performance drivers may depend on the
        # mission concept used.
        key_parameters:
            observation_frequency:
                first_order_algorithm_low-earth-orbit:
                    (Number of spacecraft) / 12 hr
                first_order_algorithm_geosynchronous:
                    Scan frequency
                performance_drivers:
                    Number of spacecraft for low orbit
            time_late:
                first_order_algorithm_low-earth-orbit:
                    Onboard storage delay + processing time
                first_order_algorithm_geosynchronous:
                    Communications + processing time
                performance_drivers:
                    Storage delay (if applicable)
            resolution:
                first_order_algorithm_low-earth-orbit:
                    Distance x [(wavelength/aperture) + control error]
                first_order_algorithm_geosynchronous:
                    Distance x [(wavelength/aperture) + control error]
                performance_drivers:
                    Attitude, aperture, control accuracy
            observation_gap:
                first_order_algorithm_low-earth-orbit:
                    Cloud cover interval or coverage gap
                first_order_algorithm_geosynchronous:
                    Cloud cover interval or coverage gap
                performance_drivers:
                    None (weather dominated)

    # summary_of_concept_characterization_process:
        # Once we have established alternative mission concepts, architectures,
        # and system drivers, we must further define the mission concepts in
        # enough detail to allow meaningful evalnations of effectiveness. For
        # concept exploration, the steps in this process correspond to the space
        # mission elements.
        # - A Define the preliminary mission concept
        # - B Define the subject characteristics
        # - C Determine the orbit or constellation characteristics
        # - D Determine payload size and perlormance
        # - |
        #     E Select the mission operations approach
        #     * Communications architecture
        #     * Operations
        #     * Ground system
        # - F Design the spacecraft bus to meet payload, orbit, and
        #     communications requirements
        # - G Select a launch and orbit transfer system
        # - H Determine deployment, logistics, and end-of-1He strategies
        # - I Provide costing support
        # - J Document and Iterate

    summary_of_main_characteristics_of_space_mission_subjects:
        # If a mission interacts with user equipment. we must define the subject
        # characteristics either from known information for well-established
        # services or by a trade study involving the rest of the system. The
        # parameters for specifying passive subjects are largely the same as
        # those for specifying user elements, except that we don't have a
        # "receiver" to characterize, and the effective isotropic radiated power
        # (EIRP) specificationfor the transmitter is replaced by definition of
        # the object's emission intensity asa function of bandwidth.
        # This table summarizes the characteristics of both types of elements.
        controllable_subjects:
            - 1. Quantity
            - 2. Location or range
            - 3. Transmitter EIRP
            - 4. Receiver G/T
            - 5. Frequency and bandwidth
            - 6. Duty cycle
        passive_subjects:
            - 1. Quantity
            - 2. Location or range
            - 3. Emission intensity (W/sr) as a function of frequency spectral band
            - 4. Needed temporal coverage (duty cycle)

    summary_of_orbit_constellation_characteristics:
        # The following outlines parameters for the mission and transfer orbits,
        # propellant requirements, and constellation characteristics.
        - 1 Altitude
        - 2 Inclination
        - 3 Eccentricity
        - 4 Argument of perigee for noncircular orbits
        - 5 delta_V budget for orbit transfer
        - 6 delta_V budget for orbit maintenance
        - 7 Whether orbit will be controlled or uncontrolled
        - 8 Number and relative orientation of orbit planes (constellations)
        - 9 Number and spacing of spacecraft per orbit plane (constellations)

    summary_of_mission_payload_characteristics:
        # The following outlines the key parameters to be specified for multiple
        # payloads.
        physical_parameters:
            - Envelope dimensions
            - Mass properties
        viewing_and_pointing:
            - Aperture size and shape
            - Size and orientation of clear field of view required
            - Primary pointing dlrections
            - Pointing direction range and accuracy required
            - Tracking or scanning rate
            - Pointing or tracking duration and duty cycle
        electrical_power:
            - Voltage
            - Average and peak power
            - Peak power duty cycle
        telemetry_and_commands:
            - Number of commend and telemetry channels
            - Commend memory size and time resolution
            - Data rates or quantity of data
        thermal_control:
            - Temperature limits (operatlnglnon-operatlng)
            - Heat rejection to spacecraft (average/peak wattage/duty cycle)

    summary_of_mission_operations_characteristics:
        # We next select and size the elements needed to support communications
        # and control of the spacecraft and payload. Table 2-14 gives the key
        # parameters. Typically a mission operations control center commands and
        # controls the spacecraft and delivers data to the user.
        communications_architecture:
            - Number and distribution of ground stations
            - Downlink and uplink path design
            - Crosslink characteristics, if used
            - Relay satellites used
            - Communications link budget
            - Space-to-ground data rates
        ground_system:
            - Use of existing or dedicated facillities
            - Required transmit and receive characteristics
            - Required data handling
        operations:
            - Level of automation
            - Software lines of code to be created
            - Fun-time or part-time staffing
            - Number of personnel
            - Amount of commanding required
            - Timeliness of data distribution

    # summary_of_spacecraft_characteristics: |
        # 1. General arrangement including payload fields of view (deployed and stowed)
        # 2. Functional block diagram
        # 3. Mass properties, by mission phase (mass and moments of inertia)
        # 4. Summary of subsystem characteristics
        #     4.1 Electrical power (conversion approach; array and battery size; payload power
        #         available, average/peak overall spacecraft power, orbit average, peak)
        #     4.2 Attitude control (attitude determination and control components; operating modes;
        #         ranges and pointing accuracy)
        #     4.3 Navigation and orbit control (accessing requirement, use of GPS; onboard vs. ground)
        #     4.4 Telemetry and command (command/telemetry format; command and time resolution;
        #         telemetry storage capacity; number of channels by type)
        #     4.5 Computer (speed and memory; data architecture)
        #     4.6 Propulsion (amount and type of propellant; thruster or motor sizes)
        #     4.7 Communications (link margins for all links; command uplink data rate; telemetry
        #         downlink data rates)
        #     4.8 Primary structure and deployables
        #     4.9 Unique thermal requirements
        #     4.10 Timing (resolution and accuracy)
        # 5. System parameters
        #     5.1 Lifetime and reliability
        #     5.2 Level of autonomy

########################
# Evaluate the Mission #
########################

mission_evaluate:
    ## Step 7: Identify critical requirements (Section 3.1)
    most_common_critical_requirements:
        coverage_or_response_time:
            Number of satelJltes, altitude, incDnation, communications
            architecture, payload field of view, scheduling, staffing
            requirements
        resolution:
            Instrument size, altitude, attitude control
        sensitivity:
            Payload size, complexity; processing, and thermal control; altitude
        mapping_accuracy:
            Attitude control, orbit and attitude knowledge, mechanical
            alignments, payload precision, processing
        transmit_power:
            Payload size and power, altitude
        on-orbit_lifetime:
            Redundancy, weight, power and propulsion budgets, component selection
        survivability:
            Altitude, weight, power, component selection, design of space and
            ground system, number of satellites, number of ground stations,
            communications architecture

    ## Step 8: Evaluate mission utility (Section 3.3)
    representative_performance_parameters:
        # By using various performance parameters, we get a better overall
        # picture of our FireSat design.
        determined_by_analysis:
            - Instantaneous maximum area coverage rate
            - Mean time between observations
            - Ground position knowledge
        determined_by_simulation:
            - Orbit average area coverage rate
                (takes into account forest coverage, duty cycle)
            - System response time (See Sec. 72.3 for definition)

    representative_measures_of_effectiveness:
        # These Measures of Effectiveness (MoE) help us determine how well
        # various designs meet our mission objectives.
        goal:
            detection:
                MoE:
                    Probability of detection vs. time (milestones at 4, 8, 24 hours)
                how_estimated:
                    Simulation
            prompt_knowledge:
                MoE:
                    TIme late = time from observation to availability at
                    monitoring office
                how_estimated:
                    Analysis
            monitoring:
                MoE:
                    Probability of containment
                how_estimated:
                    Simulation
            save_property_and_reduced_cost:
                MoE:
                    Value of property saved plus savings in firefighting costs
                how_estimated:
                    Simulation + Analysis

    # Figure. Forast Fire Warning Time for Inhabited Areas. (WIP)
    # Figure. HypotheticaJ Animation Output for FireSat MIssIon Utility Simulator. (WIP)

    # Typical Sequence Flow of a Time-Stepped Mission Utility Simulation.
    # Following this sequence for many runs, we can create statistical measures
    # of effectiveness that help us evaluate our design.
    # Phase I - Data Generation
    #     Advance time step
    #     Compute changes In target or background characteristics
    #     Update satellite positions
    #     Update viewing geometry parameters
    #     Schedule observations or operations
    #     Compute pointing changes
    #     Compute and seve performance statistics
    #     Update setellite consumables
    #     Save data for this time step
    #     Go to next time step
    # Phase II - Output Generation and Statistics Collection
    #     Compute scenario statistics
    #     Compute measures of effectiveness for the Individual run
    #     Prepare output plots and data tor the individual run
    # Phase III - Monte Carlo Runs
    #     Set new scenario start time
    #     Repeat Phase I and II
    #     Collect multi-run statistics
    #     Compute statistical measures of effectiveness
    #     Prepare Monte Carlo output plots and data

    # Figure. Results of FlreSat AltItude Trade (WIP)

    # Creating a mission utility simulation for your specific mission or mission
    # concept is both time consuming and expensive. It is not uncommon for the
    # simulation to be completed at nearly the same time as the end of the
    # study, such that there is relatively little time to use the simulation to
    # effectively explore the multitude of options available to the innovative system designer.

    # Table. Commercial Space Mission Analysis and Design Software (WIP)

    ## Step 9: Define mission concept (baseline) (Section 3.4)
    mathematical_model_of_hypothetical_decision_process:
        # This section is concerned not with the detailed engineering decisions
        # for a space mission, but with the broad trades involved in defining
        # the overall mission-whether to proceed with it and what concept
        # to use. Decision for space missions fall into broad categories:
        # (1) go/no-go decision on proceeding with the mission;
        # (2) selection of the mission concept;
        # and (3) detailed engineering decisions.
        # The following table shows how we might try to quantify a decision.
        # Numerically, we would choose B or A' if it were available.
        # Realistically, any of the choices may be best depending on the
        # decision criteria.
        current_cost:
            $500M
        potential_savings_if_improvement_is_successful:
            $300M
        option:
            A:
                cost_of_improvement:
                    $35M
                probability_of_success:
                    70%
                total_cost_if_successful:
                    $235M
                total_cost_if_failed:
                    $535M
                expected_total_cost:
                    $325M
                expected_savings:
                    $175M
            B:
                cost_of_improvement:
                    $100M
                probability_of_success:
                    99%
                total_cost_if_successful:
                    $300M
                total_cost_if_failed:
                    $600M
                expected_total_cost:
                    $303M
                expected_savings:
                    $197M
            C:
                cost_of_improvement:
                    $200M
                probability_of_success:
                    99.9%
                total_cost_if_successful:
                    $400M
                total_cost_if_failed:
                    $700M
                expected_total_cost:
                    $400.3M
                expected_savings:
                    $99.7M
            A':
                cost_of_improvement:
                    $35M
                probability_of_success:
                    80%
                total_cost_if_successful:
                    $235M
                total_cost_if_failed:
                    $535M
                expected_total_cost:
                    $295M
                expected_savings:
                    $205M
    # Figure. HypotheUcal Coverage Data for FireSat (WIP)

#######################
# Define Requirements #
#######################

requirements_definition:
    ## Step 10: Define system requirements (Section 4.1)
    # The mission objectives and system concepts we have adopted have involved
    # five basic measures: (1) required performance,.(2) cost, (3) development
    # and deployment schedule, (4) implicit and explicit constraints, and (5)
    # risk. The same measures continue to apply during the entire system
    # engineering process, from concept to implementation. Through this process,
    # we decompose and allocate the central system-derived requirements
    # (sometimes expressed as system specifications) to individual segments or
    # system elements, interfaces between these as well as interfaces external
    # to the system.

    # --Evolution of Requirements Activities and Products--
    # Needs Analysis:
    # • Defining mission requirements
    # • Defining environment
    # • IdenUfying mission drivers and constraints
    # • Technology programs
    # Concept Development:
    # • Identifying critical driving requirements and associated risks
    # • Developing operations and design concepts
    # • Cost estimetes
    # • Functional analysis and major interfaces
    # • System studies and simulations
    # • Prototyping and assessing technoiogy
    # Concept Validation:
    # • Tailored system and segment definitions
    # • Preliminary internal interface requirements
    # • Preliminary system standards
    # • Preliminary requirements fiowdown
    # • integrated system validation inciuding test planning
    # • Transition planning
    # • Validating technology
    # Design and Implementation:
    # • Detailed requirements fiowdown
    # • Deveioping forrnaI design documentation and Interface control
    # • Integrating and testing the system
    # • Demonstrating and verifying the system
    # • Test procedures and reports

    # While there are several structured approaches to developing requirements
    # from the customerluser needs, the most commonly used tool is "Quality
    # Function Deployment", or QFD. Its application is not product limited; we
    # also use it in developing of requirements for processes and services.
    # Quality Function Deployment derives from three Japanese words or
    # characters meaning (1) quality or features, (2) function or mechanization,
    # and (3) deployment or evaluation. Symbolically we define the combination
    # as "attribute and function development. "It involves a series of matrices
    # organized to define system characteristics and attributes and can be
    # applicable over multiple areas of decomposition. The first level,
    # connecting customer needs or requirements to technical attributes or
    # requirements, we often called the House of Quality. We often call the left
    # hand colunm the "Whats' (at this first level, this is called the "voice of
    # the customer") and we call the horizontal attributes the "Hows". This
    # relationship will become apparent as the "Hows" define the means for
    # fulfilling the "Whats".
    simplified_qfd:
        # This limited set of needs and responding technical attributes would be
        # expanded significantly for the complete design process.
        # Welghting:
        # 9: Highest Importance
        # 3: Medium Importance
        # 1: Lowest Importance
        customer_needs:
            30m_resolution:
                weighting:
                    3
                technical_attributes:
                    low_attitude:
                        3
                    large_optics:
                        3
                    satellite_communication:
                        Null
                    constant_look_geosat:
                        Null
                    data_relay_satellite:
                        Null
                    multi-spectid:
                        Null
            daily_coverage:
                weighting:
                    9
                technical_attributes:
                    low_attitude:
                        Null
                    large_optics:
                        Null
                    satellite_communication:
                        9
                    constant_look_geosat:
                        9
                    data_relay_satellite:
                        Null
                    multi-spectid:
                        9
            30mim_response:
                weighting:
                    3
                technical_attributes:
                    low_attitude:
                        Null
                    large_optics:
                        Null
                    satellite_communication:
                        3
                    constant_look_geosat:
                        3
                    data_relay_satellite:
                        3
                    multi-spectid:
                        Null
            98%_availability:
                weighting:
                    9
                technical_attributes:
                    low_attitude:
                        Null
                    large_optics:
                        Null
                    satellite_communication:
                        9
                    constant_look_geosat:
                        9
                    data_relay_satellite:
                        Null
                    multi-spectid:
                        9
            location_accuracy:
                weighting:
                    9
                technical_attributes:
                    low_attitude:
                        9
                    large_optics:
                        9
                    satellite_communication:
                        Null
                    constant_look_geosat:
                        Null
                    data_relay_satellite:
                        9
                    multi-spectid:
                        9

    ## Step 11: Allocate requirements to system elements (Section 4.2-4.4)
    # We must decompose every system requirement into progressively lower levels
    # of design by defining the lower-level functions which determine how each
    # function must be performed. Allocation assigns the function and its
    # associated performance requirement to a lower level design element.
    # Decomposing and allocating starts at the system level, where requirements
    # derive directly from mission needs, and proceeds through segment,
    # subsystem, and component design levels. This process must also ensure
    # closure at the next higher level. Closure means that satisfying
    # lower-level requirements ensures performance at the next higher level,
    # and that we can trace all requirements back to satisfying mission needs.
    # This emphasizes the iterative character of the requirements development
    # process.
    allocation_from_mission_requirements_through_component_design:
        geopositioning_error:
            - design_margin
            - spacecraft:
                - spacecraft_bus:
                    - attitude_control:
                        - star_sensors
                        - gyros
                        - control_dynamics
                    - structure:
                        - alignments
                        - thermal_distortion
                        - mechanical_dynamics
                    - processors:
                        - star_catalog
                        - quantization/timing
                - payload:
                    - internal_alignment
                    - measurement_errors
                    - internal_dynamics
            - mission_control:
                - operations_facility:
                    - earth_ellipsoid_estimation
                    - payload_calibration
                    - attitude_estimation_and_control
                    - position_estimation_and_control
                - communications:
                    - error_detection_and_control
                    - data_compression_and_expansion
            - mission_data_processing:
                - data_processing:
                    - data_registration
                    - data_compression_and_expansion
                - data_dissemination:
                    - error_detection_and_control
                    - data_compression_and_expansion

    # Figure. Functional Flows Generating GeoposlUonlng Information for FlreSat Mission. (WIP)

    # Figure. Typical Options In Error Budgets for Attitude and Position. (WIP)

    elements_frequently_budgeted_in_space_mission_design:
        # Primary budgets are directiy related to mission requirements or
        # ability to achieve the mission (e.g., weight). These primary
        # requirements then flow down into secondary budgets.
        primary:
            weight:
                secondary:
                    - subsystem weight
                    - power
                    - propellant
            geolocation_or_system_pointing_errors:
                secondary:
                    - pointing & alignment
                    - mapping
                    - attitude control
                    - attitude determination
                    - position determination
            timing:
                secondary:
                    - coverage
                    - communications
                    - operations
                    - processing
            availability:
                secondary:
                    - reliability
                    - operations
            cost:
                secondary:
                    - development cost
                    - deployment cost
                    - operations & maintenance cost

    impact_of_response-time_requirement:
        #  The assumed requirement Is for fire data to be registered to a map
        # base and delivered to a user within 30 min of acquisition.
        impact_on_space_segment:
            - Spacecraft constellation accessibility to specified Earth coordinates
            - Command load accept or Interrupt timelines
            - Communication timellnes to ground segments
            - Satellite avallability
        impact_on_ground_segment:
            - Time to determine and arbitrate satellite operations schedule
            - Manual Interrupt of scheduled operations
            - Command load generation and constraint checking time
            - Availability of mission ground segments and communications
            - Image processing timelines
            - Image sorting and distribution timelines

    # Figure. Mission Data Timeline and Requirements Budget (WIP)

    # Figure. Iterative Performance Budgeting and Validation (WIP)

    # Figure. Requirements Documentation Hierarchy or System Specification (WIP)

    # --Steps to Developing a Requirements Baseline--
    # 1. Identify the customer and user of the product or services. A customer
    # may be a procuring agent but not the ultimate user and both must be
    # understood.
    # 2. Identify and prioritize customer/user objectives and needs for the
    # mission to be accomplished.
    # 3. Define internal and external constraints.
    # 4. Translate customer/user needs Into functional attributes and system
    # characteristics. Quallty Function Deployment is one tool to do this.
    # 5. Establish functional requirements for system and provide for
    # decomposition to elements.
    # 6. Establish functional flow and representative for its performance of
    # functions.
    # 7. Translate functional attributes Into technical characteristics which
    # will become the requirements for the physical system.
    # 8. EstabDsh quantifiable reqUirements from all the above steps.
    # 9. Through the use of block diagrams expressing Interfaces and
    # hardware/software/data relationships for the system level.
    # 10. From the architecture expressed by step 9 at the system level,
    # decompose the functional requirements and characteristics sets to
    # successive lower levels, I.e., the next level defining the basis of the
    # elements of the system.
    # 11. At all the ~ps above, iteration with preceding activities Is necessary
    # both to test the assumptions made and to reconcile higher levels of
    # requirements and functional implementation.