# Presentation: 271239

## A Generic Simulation Environment for Modeling Future Launch Vehicles Operations (GEM-FLO)

**Martin Steele, Ph.D.**
**Grant Cates**
- NASA/KSC
**Mansooreh Mollaghasemi, Ph.D.**
**Ghaith Rabadi, Ph.D.**
- Productivity Apex, Inc.

## Agenda

- History
- GEM-FLO
- Future Directions
- Shuttle Macro Level Model
- GEM-FLO
- AutoGenSim
- Conclusions

## History

## Annual Flight Rate

## Schlagheck and Byers Model

- “Simulating the Operations of the Reusable Shuttle Vehicle”
- 1971 Paper at Summer Computer Simulation Conference
- Used General Purpose Simulation System (GPSS) II language
- Did not correctly model the space shuttle architecture
- Modeled a _Fully Reusable_ Orbiter and Booster
- Booster evolved to become External Tank plus Solid Rocket Boosters
- In June of 1971 NASA decided upon the External Tank concept, initially for LH2 and then later for both LH2 and Liquid Oxygen.
- Shuttle not actually approved for development until January 1972.
- In March of 1972, NASA decided upon the use of reusable SRBs
- Input Analysis was Optimistic
- Based upon design goal of 14-day turnaround, used a range of 14 to 28 days.
- Authors noted that more realistic time estimates would become available later.
- Output provided Optimistic Results
- Produced flight rates of 50 to 100 flights per year.

## Mission Profile (March 1972)

**Mission Profile (March 1972)**

## Shuttle Traffic Evaluation Model

- “Analysis of Space Shuttle Ground Operations”
- June 1982 edition of *Simulation, *by* *Wilson, Vaughan, Naylor, and Voss
- Used SLAM language
- Correctly modeled the _existing_ space shuttle architecture
- Input was based upon projections (no historical data)
- Turnaround goal had changed from 14 to 28 days.
- Assumed that initial flows would take greater than 28 days.
- Used projections for hardware delivery dates and facility activations.
- Output of model was influential
- Model demonstrated that flight rate projections were optimistic. Late delivery of hardware and the facility activation schedule were the primary constraints.
- NASA adjusted flight rate and budget projections for the next few years.

## Shuttle 2000 Model

- Input analysis based on historical data

**Shuttle 2000 Model**

## Slide 9

## Example of Historical Data

## Simulation Input Analysis

- Example of Probability Distribution Selection using Expert Fit:
- OPF Roll-in to SSME Removal

## Valid Inputs Yielded Valid Output

## Flight Rate Experiments

## Overview of GEM-FLO

##  Project Objectives

- 	Develop a generic modeling environment to aid in the rapid development of simulation models that can objectively and accurately predict the operational characteristics of future space transportation systems,
*	** **during the entire project lifecycle*.

## Why Use Simulation?

- 	Simulation is a widely accepted tool for modeling complex systems because it can:
- model things to the desired level of detail,
- account for the randomness inherent in any real-world system,
- model the time dynamic behavior of systems,
- compress  or  expand  time  to  allow  you to  speed  up  or  slow  down  phenomena  so  that  you  can thoroughly  investigate  them,
- perform what-if analysis.

## Simulation is a labor intensive and time consuming process.

There are similarities between first (space shuttle system) and second generation RLVs. 

A generic modeling environment allows us to reduce the development time of models by capitalizing on the commonalities that exist among the various designs.  

Additionally, a generic environment allows one to fairly evaluate one proposal versus another. 

- There are similarities between first (space shuttle system) and second generation RLVs.
- A generic modeling environment allows us to reduce the development time of models by capitalizing on the commonalities that exist among the various designs.
- Additionally, a generic environment allows one to fairly evaluate one proposal versus another.

**Why Use A *****Generic***** Simulation?**

## Common Launch Vehicle Processes 

- FHE Ground Processing
- Integration
- Launch Processing
- Ascent
- Staging
- On-Orbit
- Descent
- Landing
- Post-Flight Safing
- Transportation
- Post-Flight Processing
- Depot Maintenance

## Generic RLV Flow Diagram 

## Sample of Input Parameters

- Number and type of flight hardware elements (FHEs)
- Order in which each FHE is integrated into the vehicle
- Ascent time for each FHE
- Time on-Orbit
- Location of landing site(s)
- Probability of landing at each possible landing site
- Descent time for each FHE
- Processing time, and processing facility for post flight safing
- Type and number of transporters and duration for each transportation activity
- Frequency and location of depot maintenance activity
- Location of pre and post depot maintenance activity
- Location and duration of normal ground operations
- Location and duration of integration activity
- Location and duration of launch activity
- Facility in which payload in integrated into the vehicle

## GEM-FLO

-   Generic Simulation Environment for
-   Modeling Future Launch Operations
-  Developed in Visual Basic & Arena
- Visual Basic – User Interface (RLV Questionnaire)
- Arena – Discrete Event Simulation package
-  Process Focused Operations Analysis

## GEM-FLO Architecture 

**User**

**User Interface in Visual Basic**

**Generic Simulation Environment**** **

**Model Validation and Verification**** **

**Report Generation**** **

- What-if
- Analysis

## Data Sources

- Lessons learned from first generation shuttle
- Vehicle/technology designers

## GEM-FLO Demonstration

## SLI Sample TSTO Values: Re Code B69

- No Orbital Ops
- Input is 2 RLV boosters only

**Stage 1 - From AATe**
- Launch=~17 days
- Land=~0.5 days
- Turnaround=~41 days
- Integration=~5 days
- Flight rate capability ~5.8 flights per year per vehicle
_**e,.g. To meet 10 launches per year wanted,**_
_**Require 1**__**st**__** stage-2 vehicles**_
- Require 1 pad
- Require 1 runway
- Require 2 bays
- Require 1 integration cell

**Stage 2 – From AATe**
- Launch=~18 days
- Land=~0.5 days
- Turnaround=~42 days
- Integration=~5 days
- Flight rate capability ~5.8 flights per year per vehicle
_**e,.g. To meet 10 launches per year wanted,**_
_**Require 1**__**st**__** stage-2 vehicles**_
- Require 1 pad
- Require 1 runway
- Require 2 bays
- Require 1 integration cell

**Notes**
- For post integration functions the higher of the values is used in GEMFLO.
- Values not accounted for in AATe such as ascent etc were placed in GEMFLO as constants

- 3 minutes

- 30 minutes

- 0.99 to KSC

- 0.01 to Emergency Site

- 2 to 4 days

- 2 to 4 days

- None

- 2 to 4 days

- 2 to 4 days

- 60 to 120 days

- 10 flts

- AATe values, Triangular distributions, +/- 25%

- None (booster elements only)

- 1 day payload integrate

- 4 hrs payload deploy

- None (booster elements only)

## Validation and Verification

- GEM-FLO was validated using the shuttle data from 1992-1997
- Several other architectures are now being tested

## Impact of GEM-FLO

- Allows vehicle designers to better understand the cycle time drivers by looking at facility & flight hardware utilization percentages and identifying potential bottlenecks
- Fosters the development of additional operations knowledge as it “forces” operations experts to investigate the activities that new technologies require.

## Why GEM-FLO ?

- A tool to assist in the quick assessment of new RLV designs
- By the means of a Simulation Study
- Generic Simulation
- More abstract than system specific simulation models
- Faster study results
- Eliminates simulation model structural development time
- Does not eliminate the need for good simulation study practices
- Common platform to analyze disparate RLV designs
- From an operational perspective
- With all the benefits that come from a DES study

## Tool or Technique

-    “Perceiving that simulation is a software tool (in the manner of, say, a spreadsheet), practitioners and their managers sometimes insist on quick, “easy” answers to complex, high-dollar problems. But _simulation is __*not *__a software tool_. It is a _multidisciplinary technique_ that requires a fair amount of training, skills, and experience to perform effectively. Furthermore, complex systems sometimes require complex solutions.”
- Daniel T. Brunner
- Systemflow Simulations, Inc.
- Brunner, D. T. (2000). Simulation in the Future. In J. A. Joines, R. R. Barton, K. Kang, and P. A. Fishwick (eds.) _Proceedings of the 2000 Winter Simulation Conference_, 1568 - 1576.

**Notes:**
Sim – A mechanism around which to focus discussions of system operability

A technique or methodology, not a tool
Takes a lot of thought & consideration
In its construction
In the assumptions taken in the construction

## What can we learn ...?

-   ... from a _simulation study_ using GEM-FLO
- Span of System Capability
- Number of Flights/Year
- Turnaround/Cycle Time
- Resource Utilization
- Ability to determine whether program goals are met
- Bottlenecks to system effectiveness
- Performance measures that are Sensitive to variability
- How the proposed system differs from the baseline
- Using Shuttle as a reference (validation) point

## Coming Soon !

-   To a Spaceport near you ...
- Upgrades to
- Shuttle DES Model
- Generic RLV Simulation Model
- Enhance Usability
- Include more system Information & Details

**Notes:**
Shuttle Model Upgrades
Input & Output Forms
Upgrade to Arena 6.0
Cost & Resource Modeling Features

## Conclusions

- Discrete Event Simulation is the right methodology for ops analysis
- GEM-FLO solves the “changing architecture” problem
- Confidence in results requires:
*Valid* input data (common to all modeling tools)
- Proper simulation study methods