second nasa technical interchange meeting (tim): advanced

NASA/CP—2005–214185

Second NASA Technical Interchange Meeting (TIM): Advanced Technology Lifecycle Analysis System (ATLAS) Technology Tool Box (TTB)D.A. O’Neil, Meeting ChairMarshall Space Flight Center, Huntsville, Alabama

J.C. Mankins, Meeting Co-ChairNASA Headquarters, Washington, DC

C.B. Christensen, Meeting FacilitatorThe Tauri Group, Alexandria, Virginia

E.C. Gresham, Proceedings AuthorThe Tauri Group, Alexandria, Virginia

October 2005

National Aeronautics andSpace AdministrationIS04George C. Marshall Space Flight CenterMarshall Space Flight Center, Alabama35812

Proceedings of a Technical Interchange Meetingsponsored by the National Aeronautics and SpaceAdministration held in Huntsville, Alabama,July 27–29, 2005

The NASA STI Program Office…in Profile

Since its founding, NASA has been dedicated tothe advancement of aeronautics and spacescience. The NASA Scientific and Technical Information (STI) Program Office plays a keypart in helping NASA maintain this importantrole.

The NASA STI Program Office is operated by Langley Research Center, the lead center for NASA’s scientific and technical information. The NASA STI Program Office provides access to the NASA STI Database, the largest collection of aeronautical and space science STI in the world. The Program Office is also NASA’s institutional mechanism for disseminating the results of its research and development activities. These results are published by NASA in the NASA STI Report Series, which includes the following report types:

• TECHNICAL PUBLICATION. Reports of completed research or a major significant phase of research that present the results of NASA programs and include extensive data or theoretical analysis. Includes compilations of significant scientific and technical data and information deemed to be of continuing reference value. NASA’s counterpart of peer-reviewed formal professional papers but has less stringent limitations on manuscript length and extent of graphic presentations.

• TECHNICAL MEMORANDUM. Scientific and technical findings that are preliminary or of specialized interest, e.g., quick release reports, working papers, and bibliographies that contain minimal annotation. Does not contain extensive analysis.

• CONTRACTOR REPORT. Scientific and technical findings by NASA-sponsored contractors and grantees.

• CONFERENCE PUBLICATION. Collected papers from scientific and technical conferences, symposia, seminars, or other meetings sponsored or cosponsored by NASA.

• SPECIAL PUBLICATION. Scientific, technical, or historical information from NASA programs, projects, and mission, often concerned with subjects having substantial public interest.

• TECHNICAL TRANSLATION. English-language translations of foreign

scientific and technical material pertinent to NASA’s mission.

Specialized services that complement the STI Program Office’s diverse offerings include creating custom thesauri, building customized databases, organizing and publishing research results…even providing videos.

For more information about the NASA STI Program Office, see the following:

• Access the NASA STI Program Home Page at http://www.sti.nasa.gov

• E-mail your question via the Internet to [email protected]

• Fax your question to the NASA Access Help Desk at 301–621–0134

• Telephone the NASA Access Help Desk at 301–621–0390

• Write to: NASA Access Help Desk NASA Center for AeroSpace Information 7121 Standard Drive Hanover, MD 21076–1320 301–621–0390

�

NASA/CP—2005–214185





October 2005

Nat�onal Aeronaut�cs andSpace Adm�n�strat�on

Marshall Space Fl�ght Center • MSFC, Alabama 35812

Proceed�ngs of a Techn�cal Interchange Meet�ngsponsored by the Nat�onal Aeronaut�cs and SpaceAdm�n�strat�on held �n Huntsv�lle, Alabama,July 27–29, 2005

ii

Available from:

NASA Center for AeroSpace Information National Technical Information Service7121 Standard Drive 5285 Port Royal RoadHanover, MD 21076–1320 Springfield, VA 22161301–621–0390 703–487–4650

Acknowledgments

The authors would like to acknowledge the assistance of those individuals who helped make this workshop possible: NASA Headquarters and John Mankins, Manager of Exploration Systems Research & Technology (ESR&T) Programs,

Dr. Chris Moore, Manager of the Advanced Space Technologies (ASTP) Program, and Doug Craig, Manager of the Advanced Studies Concepts and Tools (ASCT) for their sponsorship; The Tauri Group for their analytical support,

planning, and coordination; and Gloria Wortham, Universities Space Research Association (USRA), for her logistical support to the meeting. The workshop would not have been possible without the time and dedication given by all

of the participants, all of whom are listed in Appendix B. In addition, several of the conference participants provided narrative summaries of presentations and discussions. Contributors to this Conference Publication include Linda Brewster,

LaMonte Dent, Dr. Monica Doyle, Dr. Harvey Feingold, Wayne Goode, Joe Howell, Wayne Johnson, William Kahle, Jessica Kessler, Dr. Neville Marzwell, Jim McClanahan, Charles Morris, David O’Neil, Steve Patrick,

Don Perkinson, Jim Thomas, and Tim Sarver Verhey.

��

TABLE OF CONTENTS

1. INTRODUCTION .......................................................................................................................... 1

2. ATLAS APPLICATIONS ............................................................................................................... 2

3. WORKSHOP OBJECTIVES ......................................................................................................... 3

4. PREPARATION FOR WORKSHOP ............................................................................................. 4

5. PROCEEDINGS: OVERVIEW ..................................................................................................... 5

6. PROCEEDINGS: WEDNESDAY ................................................................................................ 6

6.1 Wednesday Plenary ................................................................................................................. 6 6.1.1 Open�ng Remarks From Headquarters ......................................................................... 6 6.1.2 ATLAS Overv�ew ........................................................................................................ 7 6.1.3 Technology Tool Box (TTB) ........................................................................................ 10 6.1.4 ATLAS Case Stud�es .................................................................................................... 12 6.2 Wednesday Models and Arch�tectures Work�ng Group .......................................................... 13 6.2.1 ATLAS Capab�l�t�es and Needs ................................................................................... 13 6.2.2 Subsystem Interact�on .................................................................................................. 15 6.2.3 Case Study Bu�lder Demonstrat�on .............................................................................. 16 6.2.4 Ptolemy II RangeReader and RangeWr�ter Objects .................................................... 17 6.2.5 Expans�on of Cost Model Capab�l�t�es ........................................................................ 20 6.3 Wednesday Technology Data Work�ng Group ........................................................................ 21 6.3.1 Data Collection and Vetting Process ............................................................................ 21 6.3.2 Data Sets from NGLT and SPST ................................................................................. 22 6.3.3 H�stor�cal Technology Data From Apollo and Skylab ................................................. 24

7. PROCEEDINGS: THURSDAY ..................................................................................................... 26

7.1 Thursday Plenary .................................................................................................................... 26 7.1.1 Integrated Vehicle Health Management ....................................................................... 26 7.1.2 Thermal Management Subsystem Technolog�es .......................................................... 28 7.1.3 Rendezvous and Dock�ng Mechan�sms ....................................................................... 29 7.1.4 Cryogen�c Propellant Management, Storage & Transfer ............................................. 30 7.1.5 Model�ng and Track�ng Technology Performance �n Autonomous Systems and Robot�cs ................................................................................................................. 34 7.1.6 System Model Presentat�ons ........................................................................................ 38 7.1.7 Headquarters Commentary .......................................................................................... 40

�v

TABLE OF CONTENTS (Continued)

7.2 Thursday Models and Arch�tectures Work�ng Group ............................................................. 40 7.2.1 Resolv�ng the Solver Problem ..................................................................................... 40 7.2.2 Technology Tool Box (TTB) Search Macros ............................................................... 41 7.2.3 Requirements Definition and Documentation .............................................................. 43 7.3 Thursday Technolog�es Work�ng Group ................................................................................. 44

8. PROCEEDINGS: FRIDAY .......................................................................................................... 46

8.1 Fr�day Plenary ........................................................................................................................ 46 8.1.1 Products From the Technology Work�ng Group .......................................................... 46 8.1.2 Products From Models and Arch�tectures Group ......................................................... 47

9. CLOSING DISCUSSION .............................................................................................................. 48

10. NEXT STEPS ................................................................................................................................ 50

APPENDIX A—AGENDA ................................................................................................................. 51

APPENDIX B—PARTICIPANTS ....................................................................................................... 57

v

LIST OF FIGURES

1. Proceed�ngs Structure ......................................................................................................... 5

2. Example Space Arch�tecture and Assoc�ated Scr�pt ........................................................... 8

3. Ava�lable Reports ................................................................................................................ 9

4. Web-Access�ble TTB Graph�cal User Interface ................................................................. 11

5. System Models Used �n Case Study Arch�tectures ............................................................. 13

6. Subsystem Interactions That Cause Ripple and Butterfly Effects ...................................... 16

7. Case Study Bu�lder—Campa�gn Bu�lder Interface ............................................................ 17

8. Case Study Bu�lder—M�ss�on Bu�lder Interface ................................................................ 18

9. RangeReader Actor �n a Ptolemy II S�mulat�on ................................................................. 19

10. RangeWr�ter Actor �n a Ptolemy II S�mulat�on .................................................................. 19

11. The L�fecycle S�mulator Des�gn ......................................................................................... 20

12. Data Certification Overview ............................................................................................... 23

13. QTEC Technology Tables Complet�on Est�mates .............................................................. 25

14. IVHM Hardware and Software Technologies .................................................................... 27

15. M�ss�on Env�ronment and Geometry .................................................................................. 28

16. System Mass Versus Radiator Effective Area Trade Study ................................................ 31

17. Roadmap for Increased Autonomy ..................................................................................... 37

18. Capsule Model’s Work Area ............................................................................................... 42

19. Recent Changes at NASA ................................................................................................... 49

v��

LIST OF TABLES

1. Recommendat�ons From November 2004 TTB TIM and ATLAS Team Act�ons ................ 4

2. Funct�onal Requ�rements for CPMST Related Technolog�es ............................................... 32

3. Technology Requ�rements for Long Term Cryo Storage ...................................................... 33

4. Capab�l�ty Area for Command of Control of Explorat�on M�ss�ons ..................................... 36

5. Capab�l�ty Area of Robot�c Systems Needed for Space Act�v�t�es ....................................... 37

v��

�x

LIST OF ACRONYMS

A2D Analog to D�g�tal

ACM Al�gnment Capture and Mate

ADBS Advanced Dock�ng Berth�ng System

ADM Apollo Dock�ng Mechan�sm

AHP Analyt�cal H�erarchy Process

APAS Androgynous Per�pheral Attachment System

API Appl�cat�on Programm�ng Interface

APIO Advanced Planning and Integration Office

ARC Ames Research Center

ASCT Advanced Stud�es Concepts and Tools

ASTP Advanced Space Technolog�es Program

ASTP Apollo Soyuz Test Project

ATLAS Advanced Technology L�fecycle Analys�s System

CBM Common Berth�ng Mechan�sm

CE&R Concept Exploration & Refinement

CEV Crew Exploration Vehicle

CLEM Cargo Lunar Excurs�on Module

CPMST Cryogen�c Propellant Management, Storage, & Transfer

CRAI Capab�l�t�es, Requ�rements, Analys�s, and Integrat�on

CSM Crew Serv�ce Module

DARPA Defense Advanced Research Projects Agency

DDT&E Des�gn Development Test & Evaluat�on

ECLSS Env�ronmental Control and L�fe Support System

EDL Entry, Decent, and Land�ng

x

LIST OF ACRONYMS (Continued)

EELV Evolved Expendable Launch Vehicle

ESAS Explorat�on Systems Arch�tecture Study

ESMD Explorat�on Systems M�ss�on D�rectorate

ESR&T Explorat�on Systems Research and Technology

ETO Earth To Orb�t

EVA Extra-Vehicular Activity

FSS Fl�ght Support System

GRC Glenn Research Center

GUI Graph�cal User Interface

HSRT Human Space Research Technology

HSSF Horr�ble Spreadsheet Format

IAAM Integrated Arch�tecture Assessment Model

ICD Interface Control Data

ICP Intramural Call for Proposals

IPA Isopropyl Alcohol

IPT Integrated Product Team

IR Infrared

ISHM Integrated System Health Management

ISRU In S�tu Resource Ut�l�zat�on

ISS InternationalSpaceStation

ISSI Internat�onal Space Systems, Inc.

ITAM Integrated Technology Analys�s Model

ITI Integrated Technology Index

IVHM Integrated Vehicle Health Management

JPL Jet Propuls�on Laboratory

x�


JSC Johnson Space Center

LAD L�qu�d Acqu�s�t�on Dev�ce

LEM Lunar Excurs�on Module

LEO Low Earth Orb�t

LH2 L�qu�d Hydrogen

LIDS Low Impact Dock�ng System

LLO Low Lunar Orb�t

LN2 L�qu�d N�trogen

LO Lunar Orb�t

LOX L�qu�d Oxygen

LUT Look Up Table

MASS Mass Analys�s System S�zer

MDG Model Developers Gu�de

MER Mars Explorat�on Rover

MLI Mult�-Layer Insulat�on

MSFC Marshall Space Fl�ght Center

MTBF Mean T�me Between Fa�lures

MTBUM Mean T�me Between Unscheduled Ma�ntenance

MTTR Mean T�me to Repa�r

NASA Nat�onal Aeronaut�cs and Space Adm�n�strat�on

NGLT Next Generat�on Launch Technolog�es

NSSTC Nat�onal Space Sc�ence and Technology Center

ODF Operational Difficulty Factor

OMS Orb�tal Maneuver�ng System

PCAT Phased Capab�l�t�es Advanced Technolog�es

x��


PoD Po�nt of Departure

POI Poor Obfuscat�on Implementat�on

PRM Propellant Re-supply Module

PVT Pressure, Volume, Temperature

R&D Research and Development

RASC Revolut�onary Aerospace Systems and Concepts

RCS React�on Control System

RMI Remote Method Invocat�on

RMS Remote Man�pulator System

RTM Rap�d Transfer Module

SAIC Sc�ence Appl�cat�ons Internat�onal Corporat�on

SAIM Scenar�o Integrat�on Arch�tecture Model

SBS System Breakdown Structure

SEP Solar Electr�c Power

SI Internat�onal System of Un�ts

SME Subject Matter Expert

SOA State of the Art

SOAP S�mple Object Access Protocol

SPST Space Propuls�on Synergy Team

SSM Space Segment Model

SSP Space Solar Power

SSTM Space Systems Technology Model

STI Scientific and Technical Information

STT Strategy Task to Technology

TCS Thermal Control System

x��


TDRSS Track�ng and Data Relay Satell�te System

TFU Theoret�cal F�rst Un�t

THREADS Technology for Human and Robot�c Explorat�on and Development of Space

TIM Techn�cal Interchange Meet�ng

TITAN THREADS Integrated Technology ANalys�s

TMM Thermal Math Models

TPS Thermal Protect�on System

TRL Technology Read�ness Level

TTB Technology Tool Box

USRA Un�vers�t�es Space Research Assoc�at�on

VBA Visual Basic for Applications

VRC Virtual Research Center

VTRE Vented Tank Resupply Experiment

WBS Work Breakdown Structure

XML eXtended Markup Language

ZBO Zero Bo�l-Off

CONFERENCE PUBLICATION

SECOND NASA TECHNICAL INTERCHANGE MEETING (TIM): ADVANCED TECHNOLOGY LIFECYCLE ANALYSIS SYSTEM (ATLAS)

TECHNOLOGY TOOL BOX (TTB)

1. INTRODUCTION

The Advanced Technology Lifecycle Analysis System (ATLAS) project team held a second Technical Interchange Meeting (TIM) to collect data for the Technology Tool Box (TTB). ATLAS is a suite of analytic tools that enables quick-result engineering trades, technology impact assessments, and evalua-tion of alternative design and development approaches for a wide range of space architectures and sys-tems. The TTB is a repository of information about diverse technologies; it provides data on current and anticipated performance metrics, programmatics, and operations factors for thousands of specific technologies. Technologists, model developers, and space architecture analysts gathered at the National Space Science and Technology Center (NSSTC), July 27th through July 29th 2005 in Huntsville, Alabama. Participants included members of the ATLAS development team, representatives from the Marshall Space Flight Center (MSFC) engineering directorate, regional aerospace contractors, and the NASA Headquarters project sponsor. This proceedings document provides background information about the project, explains accomplishments toward implementing recommendations from the first TTB TIM, narrates the presentations of guest technologists, and describes the consensus of discussions in technical breakout sessions.

2. ATLAS APPLICATIONS An important theme throughout the TIM was the need to ensure that ATLAS is as useful as possible to NASA in achieving its new architecture and launch goals. NASA’s ambitious near-term goals for the development and deployment of new flight systems have re-ordered NASA’s priorities and changed the set of urgent problems. Sessions throughout the TIM addressed the usefulness of ATLAS in solving immediate problems by supporting near-term engineering trades for active programs at NASA field centers. There was widespread consensus that ATLAS has significant applications as a collaborative engineering tool that directly supports current objectives through trade studies and assessments. ATLAS provides the capability to assemble space exploration architectures from a library of Excel-based system models that represent systems and infrastructure. System model inputs include selections for subsystem or component technologies in the form of a technology profile. Space architects can use ATLAS to estimate the impact of technology decisions at the system-of-systems level. System engineers can use ATLAS to conduct trade studies of technologies at a system level. Technology portfolio analysts can use ATLAS to evaluate technology decisions over the life-cycle of a space exploration architecture. A technology database, known as the TTB plays an essential role within ATLAS. System and infra-structure model workbooks draw performance and operations data from the TTB to estimate the sizes of subsystems and workforces. In 2005, the ATLAS project will produce at least 25 Excel-based system models that represent systems and infrastructure within three types of space exploration architectures: Apollo, the Phased Capabilities and Technologies (PCAT) developed for the Exploration Research and Technology (ESR&T) program, and the Point of Departure (PoD) architecture developed by the Exploration Mission Systems Director-ate (ESMD) Requirements Division. Just a few examples of system model workbooks in the ATLAS library include: launch vehicles, upper stages, landers, rovers, space propellant depots, mission opera-tions, and ground infrastructure. To support these models, the ATLAS development team will populate the TTB with at least 35 technology records in areas related to: propulsion, materials, power generation, energy storage, thermal management, automated rendezvous & docking, environmental control & life support systems, and integrated vehicle health management.

2

3. WORKSHOP OBJECTIVES The primary technical objective of the TIM was to collect data to enhance the TTB. In addition to this, the workshop aimed to advance the TTB through addressing complex technical issues, incorporating the priorities and perspectives of the model developers into the data collection process, and to bring the team together to identify and maintain focus on high priority areas. Specific objectives for the TIM were:

• Collect state-of-the-art data performance, operations, & programmatic data about existing technologies. These included performance metrics for sizing subsystems (e.g., specific energy density), operations parameters for sizing workforce and facilities (e.g., mean time between failures), and programmatic parameters (e.g., Technology Readiness Level).

• Identify parametric equations that use the performance and operations metrics for sizing subsystems and workforces.

• Forecast technology performance and operations parameters for the next 30 years. • Certify existing data within the TTB through consensus and source citations. • Identify technology experts willing to participate in periodic model and data certification

activities.

3

4. PREPARATION FOR WORKSHOP In preparation for the TIM, potential participants received the draft agenda with the background, work-shop objectives, and expected products. In the opening plenary session, the ATLAS development team introduced the project, explained how to use ATLAS to analyze space exploration architecture portfo-lios, described the system models, and demonstrated the database. The meeting also built on the first TTB TIM, conducted in November 2004 in Huntsville, Alabama. More than 40 participants represented NASA field centers, Concept Exploration and Refinement (CE&R) teams, and the Advanced Studies, Concepts and Tools (ASCT) manager from NASA Head-quarters. Three break-out sessions discussed the format and content of the TTB, the use of the data and models to evaluate space architecture technology portfolios, and the relationship between ATLAS and other ASCT projects and activities. The meeting generated recommendations, documented in the confer-ence proceedings NASA/CP-2005-213900. Table 1 summarizes key recommendations and explains how the development team acted upon them.

Table 1 Recommendations From November 2004 TTB TIM and ATLAS Team Actions

Recommendation Action Taken

Certification process for models and data Defined process and created model certification form Include material options in system models Revised models to offer material technology options Incorporate integrated vehicle health management (IVHM)

Invited William Kahle, an IVHM expert, to present an overview related technologies and associated parameters at this TIM.

Create Apollo models and collect historical data to calibrate ATLAS and serve as a baseline comparison system for other architectures.

Models now exist for Lunar Rover Vehicle, Eagle Lander, Crew Service Module, and Saturn V. Historical data for subsystem and component technologies ready for entry into database.

Automated notification of TTB updates Reusable code is available from the Virtual Research Center (VRC) to implement this feature.

Establish multiple levels of access for the web-accessible TTB

Four access levels now in TTB: (1) view schema but not the data, (2) view data but no capability to modify, (3) capability to revise data and create records for a holding area, (4) administrative capability to move data from holding area to baseline database.

4

5. PROCEEDINGS: OVERVIEW The TIM was scheduled for two and a half days beginning on Wednesday, July 27th and concluding on Friday, July 29th. The meeting started with a plenary session in the morning. Presentations in the morning plenary sessions provided technical information about ATLAS, the TTB, space exploration architecture case studies, system models, and important technologies to be incorporated in future versions of the system. The meeting was organized to both share information among all the participants while allowing for more focused detailed working sessions. A combination of plenary sessions and break out working groups were used to achieve this goal. Proceedings are presented here by day, with a section of the report dedicated to each day of the TIM and a subsection for each presentation or major topic of group discussion.

PROCEEDINGS: WEDNESDAY

PROCEEDINGS: THURSDAY

PROCEEDINGS: FRIDAY

Wednesday Plenary Thursday Plenary Friday Plenary

Products from the Technology

Working Group Products from Models and

Architectures Group Closing Discussion and Conclusions

Opening Remarks from Headquarters ATLAS Overview Technology Tool Box (TTB) ATLAS Case Studies

Wednesday Models and Architectures Working Group

Integrated Vehicle Health

Management Thermal Management Subsystem

Technologies Rendezvous and Docking

Mechanisms Cryogenic Propellant

Management, Storage & Transfer Modeling and Tracking

Technology Performance in Autonomous Systems and Robotics

System Model Presentations Headquarters Commentary

Thursday Models and Architectures Working Group

ATLAS Capabilities and Needs Subsystem Interaction Case Study Builder Demonstration Ptolemy II Range Reader and Range Writer Objects Expansion of Cost Model Capabilities

Wednesday Technology Data

Working Group

Resolving the Solver Problem Technology Tool Box (TTB)

Search Macros Requirements Definition and

Documentation Thursday Technologies Working Group

Data Collection and Vetting Process Data Sets from NGLT and SPST Historical Technology Data from Apollo and Skylab

Figure 1 Proceedings Structure

5

6. PROCEEDINGS: WEDNESDAY

Wednesday began with a plenary session which introduced the participants to ATLAS and the TTB and set the groundwork for the remainder of the TIM. Wednesday afternoon participants broke the group into two working groups: the Technology Working Group, made up of technologists and those team members working directly on the TTB; and the Models and Architectures Working Group which con-tained modelers and team members who discussed issues of importance to the overall ATLAS models.

6.1 Wednesday Plenary Presentations in the Wednesday plenary session provided an introduction to and explained the motiva-tion behind ATLAS and provided a context for the afternoon discussions. The morning began with opening remarks from the Exploration Systems Research and Technology (ESR&T) program manager, John Mankins. Presentations that followed included a project overview by Daniel O’Neil, a system demonstration by Clara Welch, a database demonstration by LaMonte Dent, architecture case studies by Dr. Harvey Feingold. 6.1.1 Opening Remarks From Headquarters John Mankins provided context for discussions about the role of ATLAS and the TTB and the current direction of the Exploration Systems Research and Technology (ESR&T) Program. He emphasized the importance of physics based modeling in the decision processes, especially those early in the lifecycle of projects. System models use performance parameters from the TTB and generate a system summary used by development cost models. Technology performance forecasts in the TTB are coupled with pro-grammatic parameters like Technology Readiness Level (TRL) and required funding. This integration of technology forecasting and physics based cost estimating provides a powerful tool for R&D planning. It structures conversations about technology. For example, a system concept has solar arrays, by pulling kilowatt per Kg for competing technologies from the TTB into the model; one has a realistic means of comparing the impact of a technology decision. Technologist should appreciate ATLAS as a tool for building advocacy. John explained consensus based decision support tools such as the Analytical Hierarchy Process (AHP). The Requirements Division in the Exploration Systems Mission Directorate (ESMD) applied the Strat-egy to Task to Technology (STT) technique, a relentless process that produces an integrated set of “Houses of Quality” starting from the strategic things the user wants to accomplish and drilling down to the technologies he or she wants to develop and characterize. Consensus based tools serve to organize the debate about desirable features or figures of merit that are difficult to quantify within a short period. Results from consensus based decision support tools appear quantitative but they are not repeatable. If one conducts the exercise with a different group of people, the consensus may be different because of the strength of the opinions of the most influential people in that group. Illuminating the history of ATLAS and the TTB, John identified the lineage of technology analysis tools that laid the groundwork. Back in the 1980’s, the Office of Aeronautics and Space Technology

6

assembled a comprehensive document containing hundreds of space mission opportunities called Space Systems Technology Model (SSTM). Actually, the information was not a model because a user could not interact with it. It was in the SSTM where Stan Sadin brought the TRL into NASA technology assessments. In 1985, CRC Press published R. Michael Hord’s Handbook of NASA Future Missions and Payloads that was based on the SSTM. It was a big blue volume of technology descriptions. Essen-tially, the TTB is a living version of the SSTM. In the mid 1990’s, a team working with NASA devel-oped the Integrated Architecture Analysis Model (IAAM) and SAIC developed the Space Segment Model (SSM) to evaluate Space Solar Power (SSP) system concepts. Starting in 2002, a multi-center team began defining requirements for the Technology for Human and Robotic Exploration and Devel-opment of Space (THREADS) Integrated ANalysis (TITAN) model. In 2003, a team led by Daniel O’Neil, produced a prototype, which provided the team with the experience to develop ATLAS. John concluded his commentary with his perspective on the changing environment at NASA Head-quarters. He explained the processes underway in the Exploration Systems Architecture Study (ESAS), also known as the Sixty-Day study will drive many of the changes. The release of the study results was delayed due to the Shuttle launch but a few news sources have already published information about the proposed architecture. According to those sources, the proposed architecture includes a heavy lifter. Initially, the launch vehicle will send the Crew Exploration Vehicle (CEV) to the International Space Station (ISS). The schedule is aggressive; instead of a nine year schedule, the CEV will be deployed in five years. Efforts within the ESR&T and Human Space Research and Technology (HSR&T) programs will be deferred in favor of finding money for the near-term objectives. There will be a very significant planned reduction in Research and Development (R&D) of advanced technology. Support for tools related to technology development investment might be overcome by events. In a restructuring of Headquarters, twenty people were reassigned to field centers. There will be significant changes in the ESMD program management, as well as sweeping changes in roles and responsibilities at the field centers. There may be similarities between the new organizational structure and the NASA of the 1980’s when there were lead centers for technologies. John summed up the situation by saying there are dark clouds and lightning on the horizon for the ESR&T projects. He asserted that ATLAS and the TTB can help project managers in this new environment by providing the capability to compare currently available technologies and estimate the impact of those technology decisions at the system-of-systems level. 6.1.2 ATLAS Overview

A project overview was presented by Daniel O’Neil and a demonstration of the system was conducted by Clara Welch. While demonstrating the system, the two explained the underlying functionality of ATLAS how it can be used for architecture assessments as well as other analyses. Analysts can operate ATLAS in two ways: a script mode or a menu mode. In the script mode, the ATLAS controller opens a space architecture case study workbook and loads input data into several models from a script, collects the system model output data, and runs cost models for system development, operations, and lifecycle economics. In the single model mode, an analyst opens one model at a time, enters mission and configuration parameters, selects technologies, and generates mass and cost reports. When running in the single model mode, the ATLAS controller calls the system development cost model but it does not call the operations and economics models. A tool-bar in the ATLAS application provides buttons for loading case studies or models and s tart buttons to run the models to generate reports.

7

During startup, ATLAS loads a default case study workbook. A case study contains a worksheet named Script that lists a series of models and the input data for those models. Other worksheets in a case study workbook identify launch vehicles and launch dates for use by the operations, cost, and economics models. Figure 2 presents the Introduction sheet and the Script sheet of a case study workbook. A diagram on the introduction sheet depicts the architecture specified by the script sheet. Rows of the script worksheet specify the system model workbooks represented by the icons in the space architecture diagram on the introduction sheet. Columns in the Script worksheet identify the input data for those models. Column ‘C’, of the Script, identifies a “Manifest” column at the top of the worksheet. After running a model, the ATLAS controller returns the wet and dry masses of the system to the manifest column specified in the script. Input fields in subsequent models can use the data in the manifest fields. With this feature, the script serves as a patch-panel for passing the output data from one system model workbook to the input data of another system model workbook.

Figure 2 Example Space Architecture and Associated Script

8

The demonstration presented the reports generated from the default case study, which involves multiple launches for lunar exploration missions. Reports from a case study include a stacked bar-graph of subsystem masses for each of the systems specified in the script. Figure 3 presents a few of the charts generated by ATLAS. The upper stacked-bar graphs present the system masses and development costs for the collection of systems that comprise a space exploration architecture. Subsystems in the mass bar-graph are specified by a System Summary worksheet in each of the system model workbooks. These two charts are available in both modes. A System Summary worksheet has a standardized system breakdown structure. If a system model does not include a particular subsystem, the summary simply specifies a zero value for that subsystem. A few examples of subsystems in the System Summary include solar power generation, power management and distribution, energy storage, structures and pressure vehicles, thermal management, propulsion, crew accommodations, communications, command and data handling, and consumables. A System Costs stacked-bar graph presents the system development costs for Design Development, Test, and Evaluation (DDT&E) and Theoretical First Unit (TFU). The lower two charts in Figure 3 depict the life-cycle cost chart and technology portfolio forecasts. These two charts are only available in the script mode. An area chart presents the lifecycle costs such

System Mass System Costs

Space Architecture Lifecycle Cost

Note: LowerCharts OnlyAvailable In Script Mode

Note: LowerCharts OnlyAvailable In Script Mode

TechnologyPortfolio

Forecasts

Figure 3 Available Reports

9

as system development, production, and operations. Each system model includes technology options, the selected technologies go into a technology portfolio. Through an Integrated Technology Analysis Module (ITAM), ATLAS produces a technology portfolio from the technologies selected in each system model. The lower right chart in the figure depicts the improvement of a critical performance parameter versus Technology TRL. The technology forecast charts present estimated performance data over a 30 year period along with estimated TRLs for a given level of funding. This data comes from technology experts who participate in the TTB TIMs. Demonstrating the menu mode involved selecting the Eagle-Lander model via the ATLAS drop-down menu, selecting technologies and specifying the payload capacity. Daniel and Clara ran the model twice with different input data to demonstrate that the report generator would create a bar-graph with the results from each session. This feature provides the capability to conduct trade studies of different mission, configuration, and technology parameters for a system concept. 6.1.3 Technology Tool Box (TTB) Following the ATLAS demonstration, Daniel O’Neil and LaMonte Dent demonstrated the web-accessible version of the TTB. ATLAS uses an Excel workbook version of the TTB known as the Working TTB. Subroutines within the ATLAS controller search the Working TTB to find performance data for the system models and operations data for the infrastructure models. As a collection of run-time look-up tables for system models, the Working TTB is fine. As an application for collecting, searching, and reporting data to a community of technologists, system model developers, and project managers, the Excel version is not suitable. The web-accessible TTB provides a professionally designed graphical user interface (GUI) that presents a Work Breakdown Structure (WBS) for navigating through technologies associated with space exploration systems. Figure 4 depicts the web-accessible TTB GUI. A tree-view on the left side of the GUI presents the TTB schema or technology WBS. Through this tree-view, people can drill-down to a technology record. A location path at the top of the screen describes the current location within the database and provides a capability to navigate back up through the tree. A Search button above the tree-view provides another approach to finding records. Record information in the upper section of the central part of the screen identifies the WBS number, the name of the technology, and includes a description field. Below the record information, tabs provide access to fields for technology performance, operations, and research and development programmatic data. The screen image in Figure 4 presents the technology performance fields. These fields include data that describe the performance metrics, the values, a reference, and a status. In the reference field, a tech-nologist can cite the source of the performance value for the specific metric. A pull-down menu in the status field presents options to specify whether the data value is a place-holder, un-vetted, or vetted data. The back-ground color of the fields will change color based on the status. A red background indicates low confidence in the metric value, a yellow background indicates some confidence, and a green back-ground indicates high confidence in the data. A time-frame field in the upper right portion of the GUI identifies a year and buttons to the right and left of this field provide the capability to move to another time-frame. Each time-frame represents three years into the future; so, time-frame zero is the current year and time-frame 10 is thirty years from now.

10

Figure 4 Web-Accessible TTB Graphical User Interface

Technologists can forecast the performance, operations, and required funding to support the forecast. For some technologies, the performance may be the same over multiple time-frames but the maturity, i.e., TRL advances from a four to a six or seven. In other cases, the TRL may be the same but the per-formance increases. Check boxes, not depicted in the screen image, provide a capability to enter the same data in multiple time-frames. Other important features of the web-TTB include individual account controlled access, content man-agement, and import and export functions. Each account has an access level. For a minimum access account, the GUI will present the WBS tree-view only. Access can be restricted to specific groups or users on each category of records or individual records. A content manager places all new or modified records in a “waiting for approval” state until reviewed and approved by an administrator. The adminis-trator has the capability to incorporate the records into the baseline database. Also, the administrator

11

account has an import function to read data from an Excel workbook and an export function to generate a Working TTB file. Near term plans for the web-TTB include the creation of a change log that tracks and dates all changes and can provide a history of the TTB, a discussion forum that allows for a text-based discussion to be attached to records in the TTB, and automated e-mail notifications to the user community about new and updated records. If approved for Phase II, the TTB developer will research Application Programming Interfaces (API) that provides remote access to TTB data directly from the server. Potential APIs for this capability include Simple Object Access Protocol (SOAP) and Remote Method Invocation (RMI), which is secured by 128-bit encryption. 6.1.4 ATLAS Case Studies Dr. Harvey Feingold presented an introduction to ATLAS cases studies and an analysis of recent pro-gress in this area. The presentation by Dr. Feingold showed that over the past two years, a total of nine ATLAS case studies have been developed representing seven different lunar mission architectures. In 2004 these architectures ranged from fairly simple Apollo analogies such as Case Study Lunar 1a and Case Study Lunar 1b which characterized fully expendable all-up and split (lander is launched separately) missions respectively; a highly reusable architecture (Case Study Lunar 3) which featured a Low Earth Orbit (LEO) propellant depot and Solar Electric Propulsion (SEP) tugs used to ferry the lander to the moon and back for refueling; and finally a complex, fully reusable architecture (Case Study Lunar 4) that augmented the SEP tugs and LEO depot with a propellant depot in Low Lunar Orbit (LLO) and a Reusable Lunar Lander used to transport the crew to the Lunar surface and back to LEO after refueling once in LEO and twice in LLO. In 2005, a more accurate representation of the Apollo architecture utilizing models for the Lunar Excur-sion Module (LEM) lander and Crew Service Module (CSM) was used to develop an Apollo case study that could be used for calibration purposes. Three case studies were eventually developed for the Phased Capability Advanced Technology (PCAT) architecture. The first two, Case Study PCAT I and Case Study PCAT A, were developed originally to represent, respectively, the PCAT Initial architecture which used near-term EELVs to transport cargo crew and propellant, and the evolutionary PCAT Advanced architecture which employed SEP tugs and reusable chemical stages to expand the overall reusability of the architecture. Those two architectures were eventually supplanted by the current PCAT architecture which resembles the earlier PCAT Advanced architecture but with less reusability. Finally, Case Study POD was developed on the basis of our best guess of the Point of Departure architecture coming out of the ESAS activity. All told, the nine case studies required a total of 27 different systems that were derived from 20 different Excel-based system models. The model usage for each case study is summarized in Figure 5. In this figure, parentheses indicate the case study used a different name for the model. For example, the Artemis model was used in the PCAT architecture, but referred to as LM within the ATLAS case study.

12

Model Name Model Description Luna

r 1a

Luna

r 1b

Luna

r 3

Luna

r 4

Apo

llo

PCA

T I

PCA

T A

PCA

T

POD

Artemis Artemis Reusable Lunar Lander x x x x (x)Atlas 5 Atlas Launch Vehicle Family x x x x x x (x)Capsule Crew Capsule w/ Crew Accommodations, ECLSS and EVA x x x x x x (x) xCenturion Heavy-Lift Launch Vehicle xCLEM PCAT Crew Launch & Entry Module (Capsule) xColossus Multi-Stage Heavy Lift Launch Vehicle x xCSM Apollo Program - Command and Service Modules xDelta 4 Delta Launch Vehicle Family x x (x) xEagle Apollo Program - Lunar Excursion Module (LEM) x (x)EDS Earth Departure Stage (Manticore) xEELV Heavy Evolved Expendable Launch Vehicle - Medium (Delta 4) xEELV Medium Evolved Expendable Launch Vehicle - Heavy (Atlas 5) xLEODepot Low Earth Orbit Propellant Depot x xLM PCAT Lander Module (Artemis) xLODepot Lunar Orbit Propellant Depot xLSAM Lander Stage & Ascent Module (Eagle) xManticore Chemical Propulsion Upper Stage x x x x x (x)MM PCAT Mission Module (ModHab) xModHab Modular Habitation System (x)Payloads Launched Mass for Propellant, Payloads, Consumables x x x xPPM Power and Propulsion Module x x x x xPRM PCAT Propellant Resupply Module xRLL Reusable Lunar Excursion (Lander) and Transportation Vehicle xRTM PCAT Rapid Transfer Module xSaturn Apollo Program Saturn V Launch Vehicle xSTM PCAT Solar Transfer Module xSWARM Solar Electric Tug x x x

Figure 5 System Models Used in Case Study Architectures

Dr. Feingold also presented comparative mass and cost results obtained from the 2005 case studies. These results were presented for different time frames to show the impact of advanced technologies. In comparing the results in the presentation package, it should be noted that the costs for the Apollo and POD architectures do not include the launcher costs whereas the costs for the PCAT architecture does.

6.2 Wednesday Models and Architectures Working Group On Wednesday afternoon, programmers, model developers, and space architects discussed the current capabilities and requirements for the ATLAS framework and models in the library during the Models and Architectures Working Group. Dr. Harvey Feingold moderated the session and Carissa Christensen and Paul Guthrie captured the consensus related to resolving technical issues, techniques for improving the models, and impressions of new ATLAS products. 6.2.1 ATLAS Capabilities and Needs Regarding the current state of ATLAS, Dr. Harvey Feingold reported that ATLAS is definitely opera-tional and can be used to roughly assess the impact of technology choices on a wide range of different systems, missions and campaign architectures in terms of their mass and cost. Furthermore ATLAS has shown that it has the capability to handle mission and campaign scenarios ranging from very simple (Apollo) to very complex (PCAT). However, he also pointed out that ATLAS is currently much more difficult to use (properly) than it should be.

13

One of the reasons that ATLAS is now so difficult to use is that it desperately needs a Working TTB that really works, i.e., one with sufficient technology data covering all timeframes, computed secondary metrics, and realistic programmatic information. Other ATLAS needs include:

• Integration of the Mission and Launch Operations models (and their required data sets) into the ATLAS economic models.

• A comprehensive check on consistency between terms and units use by the ATLAS system models and those used in the TTB.

• Implementation of certification processes for both models and technology data to inspire confidence in the results produced by ATLAS.

• Better, more up-to-date documentation for ATLAS developers, contributors and users • An overall shakedown and test of all the ATLAS functions and features to ensure their proper

operation. Dr. Feingold also suggested that in addition to mass and cost, the ATLAS development team should begin focusing attention on other performance metrics that are affected by technology choice, such as reliability, safety, and many different measures of mission effectiveness (e.g., traverse distance, information return, power, etc.). The group canvassed many potential enhancements to ATLAS. Many of the changes were ambitious and appropriate as part of a longer-term development approach. For example, the group advocated pro-viding a broader array of underlying ‘measures of goodness’ encompassing mass, cost, safety, and tech-nical performance factors that measure mission outcomes. The group also discussed enabling users to define their own novel or innovative elements to mission segment models– for example, using oxygen and water tanks as radiation shield. The group also converged on a number of relatively near-term changes. First, the group agreed that an ATLAS user should be able to define technology capabilities to support what-if analyses. This presents something of a challenge, because it raises the question of whether the user should be allowed to change the data in the Technology Tool Box, which could create version control problems. The solution the group agreed upon was to add a “user-defined technology” capability to the TTB. The group agreed to programming improvements. One change was to ensure that a query of the TTB that found no data reported as ‘none’ rather than reporting as an error. Another change was to allow the case study Script page to pass information other than mass (such as wet mass, dry mass, and volume) as well as enabling up to ten user-defined parameters. Finally, the group determined that it would be useful to provide more detailed data on mission scenarios by incorporating existing PowerPoint descriptions of missions into the sample case folder. This would enable users to more easily use the associated artwork as a starting point for creating future case studies, as PowerPoint artwork is easier to work with than the embedded Excel artwork.

14

6.2.2 Subsystem Interaction Evaluating the system-of-systems level impact of technology decisions at the subsystem or components level presents a considerable challenge to developing spreadsheet models. In developing models it is extremely important to provide for a means for communication of key parameters between models. Changes in one system or subsystem can have a ripple effect throughout the system in which they are used in or possibly affect other systems with which they interface throughout an entire architecture. Sometimes a very small change in a subsystem can ripple throughout an architecture and result in an overall large change in the architecture. Often, this phenomenon is referred to as the “Butterfly Effect”. Dr. Edward Lorenz defined the butterfly effect in his 1972 paper, “Predictability: Does the Flap of a Butterfly’s Wings in Brazil set off a Tornado in Texas?” at an American Association for the Advance-ment of Science meeting. As a developer of meteorological mathematical models, Lorenz learned that small changes in one part of a weather system can cause major changes in another part of the system. Within the context of ATLAS, the butterfly effect describes the possibility of significantly altering the life cycle cost through small changes in technology, mission parameters, or system configurations. A change in a system may affect the cost of operations, so the butterfly effect describes small changes that indirectly cause large differences in the life cycle cost. Like ripples in a pond caused by the plunking of a pebble, a change in one subsystem within a system affects the design of other subsystems. Achieving the ripple effect requires a network of equations where calculated values from one subsystem spreadsheet are variable inputs for equations on other spread-sheets. A ripple effect describes the level interconnectivity among sizing equations in multiple subsys-tems. Multiple sources of ripples in a pond cause interference patterns where the effect from one cause intersects the effect from another cause. Complex interrelationships can cause unexpected results in a spreadsheet model. The more interconnected the sizing equations of the subsystems the greater the possibility for non-intuitive changes in the system mass. Discovering non-intuitive relationships among system mission, technology, configuration and system mass and performance is one of the goals of modeling and simulation. To achieve the butterfly effect in a system model, where a small change affects everything, each system spreadsheet models must include common technology selections and interdependencies among the sub-system sizing parametric equations. These interdependencies will cause a ripple effect when an analyst selects a technology or changes a configuration or mission variable. Shrinking avionics provides an example of the ripple effect: Though smaller electronic packages reduce the mass and volume of the avionics, they increase the amount of heat to be rejected by the system. This increased heat affects the Thermal Control System (TCS) and the size of the radiators. Telemetry bandwidth provides another example: As the bandwidth and data rates increase, so do the size of the transmitters and receivers. These larger communications dishes affect the size of the supporting structure, which increases the overall mass of the system, which could require a larger engine or more propellant for the transportation system. These changes may be due to operational or physical design changes; however, they may be driven by changes in the technologies used in the system or subsystem. For this reason it is extremely important that the workbook models be designed with this type of interaction in mind. Figure 6 Subsystem Interactions That Cause Ripple and Butterfly Effects illustrates the interactions of a hypothetical system to demonstrate the potential degree of difficulty involved is assuring the adequate data is communicated between models.

15

Astronaut

ECLSS

PowerGenerator

PowerDistribution

Avionics

ThermalTransfer

Structures& Shields

Radiators

Propulsion

PressureVessels

EnergyStorage

ExternalEnvironment

R

F

M

Force

Matter(Fluids)

Radiation

Data D

Heat H

Power P

Network

PlumbingVenting

M

D

P

P

P PH

M

F

F

H

M

M

D

D

PP

P

M

HR

M

H

H

D

D

D

D

D H

Masssubsystem = f(D,F,H,M,P,R)Volumesubsystem = f(length,height,width)

P

D

D D

Costsubsystem = Σ technology_unit_cost/kg

Figure 6 Subsystem Interactions That Cause Ripple and Butterfly Effects

One example of this type of analysis was presented during the Kick-Off meeting in April 2005. Dr. Harvey Feingold presented the results of some analysis conducted with ATLAS. In his analysis of multiple space exploration architectures, Dr. Feingold discovered that adequate development and advancement of a solar array technology could save up to $100M over the lifecycle of the space architecture; these savings could pay for an additional launch. 6.2.3 Case Study Builder Demonstration Jessica Kessler presented her progress with the case study builder. The purpose of the Case Study Builder is to provide the capability to generate case study worksheets graphically, outside of Excel. This tool has been written in Java in order to be operational on both Windows and Macintosh operating sys-tems. The current version of the Case Study Builder is shown below in Figure 7 and Figure 8. Currently, the application is divided between two tabs which allow access to the campaign builder and the mission builder interfaces. The campaign builder interface (Figure 7) allows the user to arrange missions into a campaign. This interface has the ability to import mission data, save and open campaign data files formatted in XML, and save and show campaign Option data. The graphics window allows the user to zoom in and out of the view, scale the timeline, and redefine the dates on the timeline. The campaign builder also has an ‘Export to Excel’ option that allows the user to write to the ‘Mission’ and ‘Options’ sheets of the Case Study workbook in Excel.

16

Figure 7 Case Study Builder—Campaign Builder Interface

The mission builder interface (Figure 8) allows the user to arrange the events that are contained within missions, as well as set the models and parameters of the events. This interface has the ability to save and open mission data files formatted in XML, and also allows the user to import system models from the ATLAS model library. Events and models are added to the graphical timeline using a drag-and-drop operation. Near term plans for the Case Study Builder include fine-tuning the existing interfaces to make mission and campaign building easier for the user, adding the ability to export data to the ‘Script’ page in the Case Study workbook, and creating an interactive version of the campaign builder that interprets the “cartoon” version of the campaign. 6.2.4 Ptolemy II RangeReader and RangeWriter Objects Wayne Goode presented a review of progress on Ptolemy II for use with the discrete events simulator as well as future goals of the project. The Discrete Event Simulator version of ATLAS will need to read from Excel files to get data from the models. It will also need to write to Excel files to write the results of the simulation and possibly to write inputs to the models. The way to add capabilities such as this to Ptolemy, the Discrete Event Simulator, is to write custom actors in Java. These custom actors can then be used in models in the same way as the built-in actors. Two actors, RangeReader and RangeWriter, were written to read to and write from Excel files.

17

Figure 8 Case Study Builder—Mission Builder Interface

Apache Jakarta POI/HSSF provides a way to read and write Excel files from Java. A Java class, ExcelIO.java, was created. It uses POI/HSSF to read/write a value from/to a cell range in a specified sheet, row and column. RangeReader, which is a “source” actor, reads a value and sends it as a token. RangeWriter, which is a “sink” actor, writes the value that it receives as a token. These two actors use the ExcelIO class to read from and write to Excel files. The RangeReader (Figure 9) actor has the following inputs: Token (which is ignored), File, Sheet, Row, Column, Rows, and Columns. The Token is a port only. The others are ports and parameters. The only output is Value, the value read from the spreadsheet. The RangeWriter (Figure 10) functions in about the same way as the RangeReader, however, the input token is the value to be written and there is no output. A simple model for each Actor was created to test the actor. The models read/wrote several values to a spreadsheet. The tests showed that the actors operated correctly. The ATLAS model could use these actors to build larger composite actors. However, it is more efficient to write custom actors that use the ExcelIO class, similar to the way the RangeReader and RangeWriter classes do.

18

Figure 9 RangeReader Actor in a Ptolemy II Simulation

Figure 10 RangeWriter Actor in a Ptolemy II Simulation

19

The entire lifecycle will be simulated in Ptolemy as a Discrete Event model. The various phases of the lifecycle are actors in the simulation. Each element of the design will go through the model, from phase to phase (actor to actor) simulating its lifecycle from technology maturation to launch and operation. See Figure 11.

Data

Figure 11 The Lifecycle Simulator Design

A Java class will contain all the information needed to simulate an element of the model: name, the cost, cost profile and duration for production, etc. This information will be read by the Mission List object and a token containing the object with that element’s data will be created and passed through the model. A custom actor will be written in Java to represent the phases. Inheritance will be used to add additional features to specific phases where needed. The “phase” actor in the lifecycle simulator has two basic functions. It takes times and generates cost. For each time period in the simulation it must:

• Determine how much money is used for that time period • Decide if an event is finished. If so,

o Start another of the same event if needed o Trigger the next actor (project phase)

Each actor will send generated costs to the Accumulated Costs actor which will assemble the data and write it to an Excel file. This data can then be used by Excel or another application to generate the desired charts. 6.2.5 Expansion of Cost Model Capabilities Wayne Johnson led a discussion on the current state of cost estimating tools. He began with a discussion of the current acquisition cost model. He explained the WBS, noted those subsystems that were not

Trigger

Launch Ops DDT&E

Fixed Ops

Production

Accumulated Costs

Technology Maturation

Mission Ops

Mission List

Infrastructure

20

being utilized (propellants/consumables), and showed how some sections (particularly thermal) need to be handled when making analogous system choices. He also pointed out that Apollo era system analo-gies were added for additional modeling flexibility. After the acquisition cost model discussion, Wayne talked about the status of the operations costs model. He explained how the newly developed mission operations cost model was to be integrated into the current operation cost model. In addition, he pointed out that there are only a handful of launcher options in the database and besides shuttle analogy, all choices are actually closer to pricing option and not cost. This approach was sufficient for initial devel-opment. However, as architectures expand in scope (i.e., to accommodate point of departure or 60 Day study-type elements) the need to cost launchers (and their variants) increases. This led to a discussion of the need for additional launcher cost modeling. Wayne recommended that a new launcher cost model be incorporated into the Atlas framework. He demonstrated a prototype model that will allow new launchers to be costed at a system or subsystem level. The user will have the option of selecting “pre-configured” launchers from a list. The list will include such options as ATLAS, Delta, and Shuttle derived (inline and sidemount). Wayne will work in the near future to finish the launcher prototype model and incorporate the mission operations model into the operations cost model.

6.3 Wednesday Technology Data Working Group The Technology Data Working group gathered on Wednesday afternoon to bring together technologists and ATLAS team members to focus on collecting data for the TTB and enhancing the database. Wednesday’s breakout session including presentations from Dr. Monica Doyle of SAIC on the data collection and vetting process; Jim Thomas of ISSI on their efforts to integrate data from the Next Gen-eration Launch Technology and Space Propulsion Synergy Team projects; and Dr. Randy Humphries of QTEC on their project to collect technology information from the Apollo and Skylab projects. 6.3.1 Data Collection and Vetting Process Dr. Monica Doyle opened the session with a presentation on the data collection process, and the process for vetting technology data inputs for the TTB. The value of ATLAS as a decision support tool lies in the accuracy of the data in the TTB. The primary source of data is the community of experts active in research and development in a particular area. This data is initially collected during ATLAS Technology Interchange Meetings (TIMs) which bring together technologists, modelers and end-users. Follow-up interviews will be conducted with technologists to obtain updated information as well as potential contacts for further technology data.

Additional data is collected from reports documenting previous study results. For example, the Revolu-tionary Aerospace Systems Concepts (RASC) and the Capability, Requirements, Analyses and Integra-tion (CRAI) team reports have provided a considerable amount of data to the TTB. Finally, time frame 0, or state-of-the-art, data can also be found in published specifications.

The primary site for data entry is the web-based TTB. Users can apply for an account by visiting https://atlas.vrc.nasa.gov/ and selecting “Create Account”. Once their account has been approved, technologists can submit new data or data corrections to the TTB for any time frame. Data submitted for inclusion in the TTB must adhere to the following requirements:

21

https://atlas.vrc.nasa.gov/

• Metric values are specified in SI units. • Metric values must not include contingency or margin. • All data submitted must contain a reference. (In order to protect proprietary data, these

references and the names of data providers will not be visible to everyone.) • All records have the same pre-defined Tech R&D metrics. (A data provider cannot add a Tech

R&D metric.) • All records have pre-defined Operations metrics. (A data provider cannot add an Operations

metric.) • New performance metrics can be added to any technology. • Existing technologies can be modified or updated. • Data can be submitted for any time frame.

Once the data is submitted to the TTB, it must be approved by the TTB administrator before it will be available to the modelers. The data in the TTB is color-coded to represent its level of maturity. These color codes are described as follows:

• Green: data that has been validated or certified. • Yellow: data has some legacy either from comparison with (very) similar technologies,

preliminary studies or consensus at TTB workshops. • Red: This data is usually inserted to eliminate “TBD” in order to test ATLAS models.

Interactive TIMs provide a forum for discussing and vetting this data in order to raise the maturity level from red to green. Using this data and comparing the resulting ATLAS output with results from previous studies or actual missions provides insight into data validity. A formal process for certifying the data is outlined in Figure 12. 6.3.2 Data Sets From NGLT and SPST Jim Thomas from International Space Systems, Inc. (ISSI) presented a summary of their ongoing research project for the TTB. The ISSI team conducted engineering analysis of technologies applicable to Earth-to-orbit, in-space, and lunar/Mars vehicle and propulsion systems. The ISSI effort focused on TTB work breakdown structure (WBS) element 2.6 Space Transportation and sub-elements 2.6.2. Vehicle Airframe, to identify technologies for structures and materials for 2.6.2.1 Primary Vehicle Structures, 2.6.2.2 Pressurized Structures and 2.6.2.3 Secondary Structures and Appendages for earth-to-orbit vehicle systems. The TTB WBS is a generic non-configuration oriented WBS. The Next Generation Launch Technologies (NGLT) System Breakdown Structure (SBS) is a configuration oriented SBS that is used to identify and track the various major components and systems during a study. A hardware program converts the configuration oriented SBS to a configuration oriented WBS to identify and track each major component, system and subsystem for the design, development, test and evaluation (DDT&E) program. In order to identify technology areas applicable to the TTB WBS elements, ISSI laid out the NGLT SBS elements for comparison to the TTB WBS elements. However, due to the significant differences between the two matrices they were not directly comparable. In order to compare the

22

ImplementWeb accessible

TTB

Identify sources forcurrent data andexplain rationale

for forecasted data.

NASA &Contractor

Technologists

Technology Tool Box (TTB) Integrator

Data CertificationFacilitator &

Database Developer

NASA & Contractor Subject

Matter Experts

ATLASPrinciple

Investigator

Check data formsfor completeness

& request additionalinformation

Review TTB datarecords via Web

or Excel workbook.

Check data values,sources, assumptions,

and compare with other values &

sources.

Identify issues ordiscrepancies andrequest clarification

if necessary.

Work with ATLASmodel developers tomap technology data

to models.Incorporate

data intoofficial TTB.

Fill out SystemSection of data

certification form.

DevelopTechnology

Description Form Documentcertification status

and caveats.Request

clarification ifnecessary.

Invite a group oftechnologists &

model developersto a TTB Workshop.

Work with verificationfacilitator to publish

proceedings

ConductInterviews with

NASA &Contractor

Technologists

Revise

Fill out TechnologyData form in Excel

or via Web withperformance,operations, &programmatic parameters.

Pass

Yes

Revise

PassClarify

YesClarify

Participate inTTB Workshop

Resolve issues &facilitate consensuson data veracity at

Workshop PassClarify

Yes

Enter

Enter

Publish currentversion of TTB.


TTB



NASA &Contractor

Technologists



Database Developer


Matter Experts

ATLASPrinciple

Investigator




or Excel workbook.



sources.


if necessary.





certification form.

DevelopTechnology


and caveats.Request





proceedings


NASA &Contractor

Technologists

Revise



Pass

Yes

Revise

PassClarify

YesClarify




Yes

Enter

Enter



TTB



NASA &Contractor

Technologists



Database Developer


Matter Experts

ATLASPrinciple

Investigator




or Excel workbook.



sources.


if necessary.





certification form.

DevelopTechnology


and caveats.Request





proceedings


NASA &Contractor

Technologists

Revise



Pass

Yes

Revise

PassClarify

YesClarify




Yes

Enter

Enter


Figure 12 Data Certification Overview

technology areas in the NGLT arch a conceptual study to applicable technology areas in the TTB WBS, ISSI used its ValuStream risk assessment process to establish a dual-matrix WBS that has turned out to be a very useful tool in our comparison of technology areas applicable to the TTB WBS and the devel-opment of technologies. The dual-matrix WBS provided ISSI with the tool to lay-out the NGLT launch vehicle subsystem SBS configuration oriented and the non-configuration oriented TTB WBS side-by-side for a direct comparison of the two with the technology areas ISSI evaluated for the development of technologies applicable to the TTB WBS. When ISSI laid out the NGLT SBS for comparison to the TTB WBS, it became evident that there were technology areas associated with structures and materials that would be applicable to a booster-stage and upper-stage elements. The dual-matrix comparison of the technology areas also provided ISSI with insight into other NGLT SBS launch vehicle elements associated with vehicle subsystems, e.g. mechani-cal, electrical and thermal; and vehicle facilities, e.g. launch infrastructure, manufacturing, and opera-tions. ATLAS contains similar WBS elements but not to the detail of the NGLT SBS. These areas will be evaluated during the next several months to determine if they contain technologies applicable to the TTB WBS and which can be used to populate the ATLAS TTB database. Through the middle of July, ISSI reviewed 231 technology areas and determined 115 structural and material technologies were applicable to the TTB WBS booster-stage launch vehicle elements. The 115 technologies identified for the booster-stage element were entered in the ISSI interim ATLAS TTB form to support the entry of the data in the ATLAS TTB database and provided to the Tauri group. In addition to reviewing the technical data to develop the technologies, ISSI established a methodology and developed a review process of the structural and material technologies for the booster-stage element permitting ISSI to establish operational difficulty factors (ODFs) metric values from 0.1 to 10 and

23

technology readiness levels (TRL) values from 1 to 9 for each structural and material technology identified. ISSI also supported Russ Rhodes of KSC and the SPST sub-team’s view, development and reporting of operational technologies for both liquid and solid chemical propulsion systems. The review evaluated 9 earth-to-orbit and 7 in-space rocket engines and identified 28 operational requirements that established metric values for operational difficulty factors, operational reliability factors and operational environment ratings. The technology review process developed a methodology that established a structured and documented engineering process that is defendable and repeatable, and will produce a technology database based on NASA’s and the aerospace industry’s historical database. The ValuStream process provides an addi-tional structured process that uses the dual-matrix WBS to identify, compare, record, and track the technologies and the derived metric values. ISSI has spent much time reviewing the internet and visiting a college library to research the aerospace and aircraft material publications and handbooks to locate material properties that are not proprietary, ACI or ITAR controlled data. All of the data used by ISSI to populate the ATLAS TTB database is in the public domain. 6.3.3 Historical Technology Data From Apollo and Skylab Dr. Randy Humphries presented an overview of the research underway by QTEC to capture Apollo and Skylab technology data for inclusion in the TTB. The QTEC team identified Apollo and Skylab subsystem technologies, and developed data sets based on these two NASA flight vehicle systems. These data sets, at a minimum, included resources (especially weights), performance parameters, and other pertinent operating conditions, which would facilitate technology state identification and later parameterization. Identification of the references for data sources was also an important feature of the task. The object was for ATLAS personnel to use the compiled data to validate the model and use the results as the basis for comparisons. As an additional product, QTEC supplied an SBS to use as the basis for construction of the tabular documents. The approach for this effort was to use QTEC subject matter experts (SMEs) to produce a Technology Table data set to identify technology states and indicate where the data sources are located. From this, the derived objective was to collect detailed data that would allow complete definition down to the assembly or sub-assembly level (and in some cases, component level). At the beginning of the task, SMEs conducted a literature survey and, based on a cursory review, a streamlined reference set was selected. In parallel, the SMEs identified tabular data for pertinent assembly and subassembly. The basis of the tabular format was the structure of the SBS tree and the content of the Technology Tool Box, provided by the customer. The data gathering for the tables occurred in three overlapping cycles (roughly bi-monthly for the 6-month period this effort spanned (i.e. Oct 2004 thru March 2005.) The primary data produced was an Excel Technology Table with tabs representing all significant assemblies and subassemblies included in this table set, addressing both the Skylab and the Apollo vehicles. Not all tabs (assemblies and subassemblies) were completed but the preponderance was

24

addressed. The generated data far exceeded the minimum goals stated at the outset. In addition, a valuable SBS tree was detailed. Consistent with the primary desire to gather data, in lieu of attendant management or integration, most of the effort was expended in raw data tabulation. SMEs had the latitude to decide individual subsystem details sufficient to define the technology state of their assigned subsystem. Even though some data scatter occurred, consistency and uniformity of this data was reasonable. Good subsystem definition and depth were achieved for Primary Power, Main Propulsion, ECLSS, Crew Accommodations, Consumables, Propulsion, Mechanisms, Reaction Control System (RCS), Rocket Motors, Passive Thermal, Thermal Protection Systems (TPS) and Thermal Management. Of these, sig-nificant weight data were collected for ECLSS, Main Propulsion, Rocket Motors Primary Power, and Crew Accommodations. However, each subsystem’s data depth is different because the data granularity depends not only on reporting by the element designers but also the quality of the data sources used and the experience and contacts available to the data miners. One hundred twenty-three tables have been defined with over 100 populated with some data and 50 to 70 at what is considered a high level of completion. Figure 13 summarizes the assessment status. Green indicates the subsystem definition was achieved. Yellow indicates the need for additional research to define the subsystem adequately. Red indicates the subsystem was not adequately defined. “N/A” indicates the subsystem was not addressed in the study.

S1-C

S-II S-IV B

IU CSM LEM LRV SLA AM OWS MDA IU CSM ATM DS

1. System 60% 60% 60% 40% 40% 30% 60% 10% 70% 70% 70% 20% 40% NAd 10%

2. Power Generation 70% 70% 70% 50% 60% 50% 60% N/A 80% 80% 80% 50% 60% NAd N/A

3. PMAD 50% 50% 50% 60% 30% 30% 40% N/A 40% 40% N/A 60% 40% NAd N/A

4. Wireless Distribution N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A NAd N/A

5. Thermal Management N/A N/A N/A 80% 70% 70% N/A N/A 80% 80% 80% 80% 70% NAd N/A

6. Primary Propulsion 40% 40% 40% N/A 40% 40% N/A N/A N/A N/A N/A N/A 40% NAd N/A

7. RCS / Aux Motors 80% 80% 80% N/A 80% 10% N/A N/A N/A 80% N/A N/A 80% NAd N/A

8. Rocket Motors 80% 80% 80% N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A NAd N/A

9. Primary Structures 70% 70% 70% 70% 30% 40% 50% 0% 70% 70% 70% 0% 50% NAd 0%

10. Pass. Thermal Ctrl. 60% 60% 60% 60% 30% 40% 80% 0% 80% 80% 80% 0% 50% NAd 0%

11. Thermal Protection N/A N/A N/A N/A 60% N/A N/A N/A N/A N/A N/A N/A N/A NAd N/A

12. Mechanisms 20% 20% 20% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% NAd 0%

13. GN&C 0% 0% 0% 0% 0% 0% 0% N/A 0% 0% N/A 0% 0% NAd N/A

14. C&DH 40% 40% 40% 40% 0% 0% 0% 0% 0% 0% 0% 0% 0% NAd 0%

15. Comm. & Tracking 40% 40% 40% 0% 0% 0% 0% N/A N/A N/A N/A N/A N/A NAd N/A

16. Crew Accom. N/A N/A N/A N/A 80% 0% N/A N/A 90% 90% 80% N/A 80% NAd N/A

17. ECLSS N/A N/A N/A N/A 80% 0% N/A N/A 90% 90% 90% N/A 90% NAd N/A

18. Consum. and Propell. 80% 80% 80% 80% 80% 80% N/A N/A 90% 90% 90% 90% 80% NAd N/A

19. Infrastructure NAd NAd NAd NAd NAd NAd NAd NAd NAd NAd NAd NAd NAd NAd NAd

Figure 13 QTEC Technology Tables Completion Estimates

25

7. PROCEEDINGS: THURSDAY

On Thursday morning, participants reconvened in another plenary session in the morning, and again broke into the same working groups in the afternoon. The groups rejoined on Thursday afternoon for a brief group discussion, before adjourning for the day.

7.1 Thursday Plenary

Thursday morning the participants re-convened to delve into more detail on ATLAS and the TTB. Specifically Thursday’s plenary provided technical information for the modelers in the room as well as ATLAS model library background for the technologists present. Speakers in the Thursday morning plenary session gave catalytic presentations about the state of the art in important key technologies, requirements for concept definition, and overviews of existing models in the ATLAS model library. Catalytic presentations by the technologists provided the ATLAS modeling team with an insight into the types of available technologies and parameters to incorporate into the spreadsheet models. Concept developers provided an overview of the types of trade studies that preliminary design teams must per-form. System model developers provided the technologists a context for the performance and operations data. Bill Kahle presented an overview of Integrated Vehicle Health Management (IVHM). Linda Brewster presented a history of docking mechanisms and descriptions of current capabilities. Joe Howell presented an overview of a recent cryogenic depot definition study, and Neville Marzwell presented the state of the art in robotics and mission related issues in man versus machine decisions. 7.1.1 Integrated Vehicle Health Management A recommendation from the November TTB TIM was to incorporate cross-cutting technologies into the systems and operations models within the ATLAS library. Integrated Vehicle Health Management (IVHM) is an important cross-cutting technology because it can reduce the size of the “standing army” required to monitor the health of space exploration assets. During the plenary session, William Kahle, from the Advanced Sensors & Health Management Systems Branch of the Marshall Space Flight Center (MSFC) Engineering Directorate, presented an overview of IVHM technologies and associated parameters. William explained that a number of definitions exist for Integrated System Health Management (ISHM) or IVHM. Earlier efforts emphasized vehicle health monitoring technologies. A definition of IVHM from the Next Generation Launch Technologies (NGLT) program was: “Integrated Health Management is not a single technology, but rather an integrated suite of technologies, which are in turn, integrated with other flight and ground operations technologies.” Health management fundamental technologies include: hardware technologies, such as sensors, their power, and communications; algorithms and soft-ware technologies, such as signal processing, feature extraction, diagnostics and prognostics, model based reasoning, and system and mission level state modeling. Figure 14 IVHM Hardware and Software Technologies, depicts types of IVHM technologies.

26

A2D Remote Health Node

analog digital

wireless

DSPfeature extraction

anomaly detection

temporal analysis

MBR prognostics

expert systemsdigital bus

diagnostics

neural net system models

impact analysis recovery

Figure 14 IVHM Hardware and Software Technologies

Another view of IVHM developed by the Defense Advanced Research Projects Agency (DARPA) con-sists of layers of application components. Technologies integrated across hardware elements involve health assessment, prognostics, decision support, and presentation. Technologies mapped into individual hardware elements include condition monitors, signal processors, data acquisition, sensor modules, transducers, and infrastructure services. These two views of IVHM architectures can be integrated such that a few subsystems have sensors, analog-to-digital (A2D) converters, and nodes that process the data to hand off to another subsystem that contains the artificial intelligence for prognostics, diagnostics, and recovery. Other subsystems may have this intelligence integrated into assemblies and components. Analytical tool development activities at Ames Research Center (ARC) involve the Simple Object Access Protocol (SOAP) to acquire input variables and generate reports. William presented lists of the input and output variables for these IVHM technology analysis tool development projects. A few of the input files include mission simulation profiles, timelines, process dependencies, and fault trees. Data for the processes include WBS number, name, duration, process failure rates, labor costs, and fixed costs. Outputs from these tools include Mean Time Between Failures (MTBF), Mean Time To Repair (MTTR), and Mean Time Between Unscheduled Maintenance (MTBUM). These outputs could become values for operations parameters in the TTB. Operations models in the ATLAS library could use these parameters to size workforce and facilities for the operations cost models. While IVHM rates high among safety and reliability technologies, it also provides opportunities to reduce lifecycle costs. William presented the results of a Northrop Grumman study of the cost benefits of IVHM based on one vehicle and seven flights per year at 40,000 pounds per mission with a 30 year operational service life. By reducing the maintenance and trouble shooting, the study indicated that a 610 million dollar investment could save 4.3 billion dollars over 30 years or a 7.0 benefit to cost ratio. Investing in IVHM could lead to a 52% reduction in support costs.

27

7.1.2 Thermal Management Subsystem Technologies

Protecting the people, payloads, propellants, and avionics from external and internal heat sources requires integration of thermal management technologies. Ramona Cummings, a thermal expert, presented an overview of thermal manage-ment requirements, design considerations, technologies, and spreadsheet modeling techniques. Typically, thermal management design requires a knowledge or iterative determination of heat rejection and/or generation for mission and vehicle processes. Requirements must specify allow able temperatures for operations, survival, and safe mode. Mission plans generate requirements for tracking (or avoid-ance) of Sun, Star, Earth, Moon, or other planets and their moons. Subsystem articulations such as servicing and payload viewing also generate thermal management requirements. NOT TO SCALE

Figure 15 Mission Environment and Geometry

Configuration design considerations include detailed geometry, masses, and subsystem connectivity. A thermal model ought to determine orbital, albedo, and Earthshine heat loads for the vehicle at nominal and articulated configurations. Where appropriate, a thermal model should incorporate insulation effec-tiveness, such as Multi Layer Insulation (MLI) e-star or foam core e-star, coolant loop fluid properties, mass flow rates, area shapes, line losses, and convection coefficients, latent heats of vaporization and sublimation, and ablation temperature regime and latent heat of ablation. Spreadsheet analyses typically involve specific geometric shapes, (only a few at any one time) and bulk temperature responses (typically determined per shape). Look Up Tables (LUTs) can be used for view factors between specific shapes. Also, averaged or LUTs for orbital, earthshine, and albedo heat rates are also used. Single values or LUTs can also be used for surface properties, material thermo-physical properties, convection coefficients, ablation properties, coolant loop area shapes, MLI e-stars and foam core e-stars. Variables for thermal modeling involve surface properties as function of temperature and angle of incidence. These variables include: solar absorptivities, infrared (IR) emissivities, solar and IR transmissivities, solar and IR specularities, and refractive indices. Thermo-physical properties, or per-formance parameters, of materials include: conductivities (as a function of temperature, pressure, and/or constituent lay up orientation), specific heats (as a function of temperature and where appropriate, of fusion criteria.), and densities as a function of temperature. Thermal analysis spreadsheets can estimate steady state and transient temperatures based on the system configuration, mission environment, and material properties. Spreadsheets with driving thermal math models (TMM) do have serious limitations. Although TMM entity dimensions can be adjusted from the spread sheet interface, re-meshing will not be conducted. This limitation means that entity size and aspect ratios could exceed limits affecting accuracy. Additional logic can be added to the spreadsheet such that out-of-range requests are rejected. Requested parameters can be illogical. However, more

28

software logic on spreadsheet side can mitigate this. In addition, Ramona suggested a few technology specific options for possible incorporation in a system spreadsheet model:

• Insulation: MLI, foam, advanced Aerogel, or offset honeycomb vacuum insulation • Tailoring surface properties: heaters, louvers, or thermo electric coolers • Heat pipes: conventional or solid state • Open loop flow control: vaporization • Refrigeration: Peltier (thermo-electric) or dynamic • Radiators: passive or active

7.1.3 Rendezvous and Docking Mechanisms Automated assembly and in-space infrastructure depends on rendezvous and docking mechanisms. Linda Brewster presented a historical overview of docking mechanisms and identified a few of the subsystem technologies. Her presentation addressed many of the important events related to docking mechanisms, including:

• 1966: Gemini 8 performs the first dock in space • 1969: Soyuz 4 performs a manual dock with Soyuz 5 • 1969: Apollo 9 docks in Earth orbit • 1971: Soyuz 11 docks to Salyut 1 • 1973: Skylab’s first dock • 1975: Apollo and Soyuz docked • 1981: First shuttle launch • 1986: MIR begins construction • 1990: Hubble Space Telescope begins operation • 1998: International Space Station construction begins

The Gemini program was used to test the planned docking mechanism for the Apollo flights, which included a probe and drogue system. The Apollo Docking Mechanism (ADM) consisted of a probe housed at the forward end of the command module's apex, inside a docking tunnel, that engaged with a dish shaped drogue in the upper docking hatchway of the lunar module. On insertion of the probe into the drogue, three capture latches engaged with a hole in the drogue's apex to form a “soft dock”. Firing a helium gas charge operated a retraction mechanism of the probe which pulled the two craft together with a corresponding ring in the lunar module to form a ‘hard dock’. Crew transfer between the two spacecraft was possible through the docking tunnel after removal of the command module’s forward hatch, the probe and drogue and the lunar module’s upper hatch. The Apollo Soyuz Test Project (ASTP) occurred in 1975, bringing together and docking an Apollo and Soyuz spacecraft in Earth orbit. Differences in the Apollo and Soyuz environmental and docking mechanisms required the design of a separate docking module that would have to be interspaced between the two craft. The Soyuz test project used an androgynous universal docking mechanism instead of the standard NASA male mechanism.

29

The Shuttle has demonstrated the ability to perform robotic capture of payloads, such as the Hubble Space Telescope, and directly dock with both the Mir and the International Space Station (ISS) using the Orbiter Docking System, which uses a modified version of the Russian docking mechanism, the APAS (Androgynous Peripheral Attachment System).The APAS system components include an extensible docking ring with three inward facing guide pedals with capture latches mounted on the active side. These soft capture latches require some force to engage. Also on the active side is a dynamic load attenuation that is used to dampen or burn off the post capture energy left in the system. Once captive, the ring extends to equalize the ball screw actuators to align the vehicles and then retracts to engage structural latches mounted on the APAS base structure. An orbiter can carry several docking mecha-nisms. Maintenance on the Hubble Space Telescope has been carried out by attaching Hubble to the orbiter using a Flight Support System (FSS) which attaches to a three-point docking mechanism on the aft end of the Space Telescope. The FSS platform was adapted from an FSS used during the 1984 Solar Maximum repair mission. It has a U-shaped cradle that spans the rear of the cargo bay. A circular berthing ring with three latches secures the Telescope to the cradle. The shuttle can also use a robot arm to grasp and move payloads. On the tip of the robot arm is an End Effector, a wire-snare device designed to fit over a special prong, or grapple fixture, attached to the payload that it handles. The grapple fixture can have a foothold attached which allows it to move astronauts in position during Extra-Vehicular Activities (EVAs). The Space Station’s robot arm is a longer (55’) and more versatile mechanism, capable of more accurate placement. It can also move along its mount structure. The Space Station’s Common Berthing Mecha-nism (CBM) is used to attach many of the space station’s modules. The CBM system is separated into two halves, consisting of active and passive rings. The rings are universal in design so that any passive CBM ring can be berthed with any active CBM ring. Once placed in proximity for berthing by an astro-naut using a Remote Manipulator System (RMS), the CBM active latches pull the two rings together. Next, bolts tighten the berth and compress the seals for an air-tight connection. Several mechanisms are currently in the design phase, or undergoing preliminary testing:

• Orbital Express (light payload) • Hubble Rescue Vehicle (3-point latch) • Advanced Docking Berthing System (ADBS, formerly LIDS) • Alignment, Capture and Mate (ACM) Automated Docking System

Linda Brewster also answered questions about autonomous rendezvous and docking mechanism and approaches and led the group in an animated discussion on this topic. 7.1.4 Cryogenic Propellant Management, Storage & Transfer Today, we have filling stations around the world that provide the capability to extend the range of travel for our vehicles. Tomorrow’s space infrastructure ought to include propellant depots for the same reason. Joe Howell presented an overview of cryogenic propellant management, storage, and transfer technologies. A Cryogenic Propellant Management, Storage & Transfer (CPMST) capability has crosscutting applications to virtually all missions requiring in-space operations with pre-positioned cryogens. The primary functions include: fluid transfer and long-term storage. Combinations of passive and active thermal control (refrigeration) ensure long-term cryogenic storage with minimal losses.

30

Preliminary technology experiments have been conducted. Technology development roadmaps and cost estimates have been constructed (see CRAI data). As a result of the ESR&T Intramural Call for Proposals (ICP), there are three CPMST related projects:

• Ultra light Zero-Boil-Off Cryogenic Propellant Storage System (JPL) • In-Space Cryogenic Propellant Depot (MSFC) • Experimentation for the Maturation of Deep Space Cryogenic Refueling (GRC)

Three dimensional (3D) computer aided design modeling is critical to reducing heat loads into propel-lant tanks. Several configurations must be identified and iterated upon. Key attributes for a “good” concept: (1) obtain view of deep space, (2) minimize tank view of spacecraft bus, (3) protect tanks from solar arrays, and (4) minimize strut heat into Liquid Hydrogen (LH2) tank. To determine final configuration and component designs, sensitivity trades must be performed to evaluate system performances for varying MLI layers, varying radiator area, and varying cryocooler power levels.

Figure 16 System Mass Versus Radiator Effective Area Trade Study

Some technology development will be addressed though ground testing; however, an orbital flight dem-onstrator is recommended to mature the full compliment of cryogenic fluid management and fluid trans-fer technologies from a systems integration standpoint. This is a long lead, high cost item. More architectural trade studies need to be performed to determine pay-off. The following table presents the functional requirements, the state-of-the-art, near-term, and far-term technologies with their TRL.

31

Table 2 Functional Requirements for CPMST Related Technologies

Figures of Merit Required Capability Now Near Term Long Term TRL

Pressure Control Propulsive settling Controlled within +/ 0.5 psia in zero-g Zero boil-off 4

Liquid Acquisition Propulsive settling 98% expulsion efficiency w. LOX, CH4, & Xenon

98 % expulsion efficiency w. LH2 3

Mass gauging Propulsive settling Bookeeping

3 -5% accuracy in zero-g w.o. settling 1% accuracy in zero g 2-4

Transfer and Distribution None being worked Not TRL = 6 until flight experiment performed

92-94% o-g transfer efficiency 3

Competing approaches for in-space propellant transfer include:

• Zero-g fluid transfer • Burning an integrated gaseous Reaction Control System (RCS) thruster(s) before and during

transfer to settle and provide some milli-g during transfer. • Inducing a rotational rate in the vehicle stack (this would require a long acquisition tube running

from the fluid transfer interface to the far end of each tank) • Changing architecture element to handle function by transferring fuel by tank exchange

Fluid transfer systems can be subdivided into three components, the supply tank, the transfer line, and the receiver tank. The supply tank must be emptied of liquid without ingesting vapor and maintain a level of pressure sufficient to accomplish the transfer quickly. The transfer line must connect the two tanks with a minimum of fluid loss, be conditioned to the required operating parameters, and maintain a low pressure drop. Hardware challenges include reliable docking mechanisms; and transfer line disconnects capable of sealing against the vacuum of space and low heat leak transfer systems. The filling of receiver tanks poses the most technical challenges including the uncertainty of liquid and vapor distributions in a tank in low gravity, the need to keep maximum tank pressure low to reduce tank mass, and for cryogenic liquids the large rate of generation of vapor from the residual energy stored in tank walls. Presently, the transfer of storable propellants in low-g is done routinely using a flexible bladder to separate liquid and vapor. Liquid helium transfer was demonstrated on-orbit but relies on the unique properties of superfluid helium to achieve its results. No suitable bladder material for cryogenic propellants has ever been found but ground testing at GRC and MSFC has shown that thermodynamic techniques such as No-Vent Fill will work. The Vented Tank Resupply Experiment (VTRE) demon-strated some alternate transfer approaches using liquid acquisition devices with a storable fluid with similar behavior to cryogenic propellants One of the technology barriers the CPMST community must overcome is the development of automated couplings & disconnects for fluid transfer. Today, commercial ground cryogenic couplings are available in sizes as large as 14” in diameter. Several flight storable couplings have been bench tested. Designs exist for flight superfluid helium couplings. However, no flight qualified couplings are available. Rec-ommendations from the CPMST projects are to contract with current coupling manufacturers to flight rate existing design and conduct flight demonstrations in conjunction with other technologies.

32

Liquid acquisition presents another challenge to the CPMST community. Liquid Acquisition Devices (LADs) have been used effectively for storable propellants for more than 30 years. Early designs of the space shuttle used cryogenic LADs but budget and schedule issues forced the designers to use storable propellants (N2O4 & hydrazine). Environmental concerns led to a desire to move away from current (toxic) storable propellants. Currently, NASA’s goals for space exploration require the use of cryogenic propellants. Cryogenic data is limited to bench testing with screen samples. No flight experience exists. A design database of cryogenic LADs will aid engineers in choosing the correct screen and channel geometry. The first step in developing this database is testing screen bubble points for IPA, liquid nitro-gen (LN2), and LH2. The next step is to broaden the database for liquid oxygen (LOX) and other fluids. Another technology barrier to cross is fluid management: pressure control/long term cryo storage. Long term cryogen storage technology has crosscutting application to virtually all missions requiring in-space operations with cryogens. The primary long term storage technology elements are insulation, tankage, and passive and active cooling. Mitigating the risk of this technology barrier involves producing advanced models to design configuration of architecture elements to prevent high tank heating rates and minimize expected losses. Developing Zero Boil-Off (ZBO) technologies as proposed in “In Space Cryogenic Propellant Depot”, and developing Liquid Hydrogen (LH2) cryocoolers. The following table lists the technology requirements, state-of-the-art, near-term, far-term performances, and associated TRL.

Table 3 Technology Requirements for Long Term Cryo Storage

Figures of Merit

Required Capability Now FY 2009 Long Term TRL

Passive Storage 3%/month 1%/month 0.5%/month 5

Active Storage (Cryocooler) Not SOA 5-10 yrs LOX storage 5-10 yrs LH2

storage

LOX, CH4, Xenon = 4; LH2

=3

Pressure Control Propulsive settling

Controlled within +/- 0.5 psia in zero g Zero boil-off 4

Measuring cryogenic liquid quantity in low-gravity without resorting to propellant settling is one of the goals of the CPMST community. Potential applications of this capability include: Shuttle Orbital Maneuvering System (OMS)/Reaction Control Systems (RCS) upgrades, cryogenic upper stages for expendable launch vehicles, and a next generation launch vehicle. Presently, three concepts under parallel development: a compression gauge, a Pressure-Volume-Temperature (PVT), gauge, and an optical gauge. Ground tests will demonstrate the proof-of-concept and advance the TRL but all of these methods will require a low-g validation. With these technologies, the avionics and ground systems can monitor propellant consumption during on-orbit maneuvers and detect leaks. Accurate gauges can reduce the propellant margins, which leads to greater payload-to-orbit capability. In-space demonstra-tion of these gauges will validate their accuracy claims. Systems for cryogen propellants such as liquid hydrogen and liquid oxygen have unique challenges. The large scale of the systems for which these propellants are attractive makes any in-tank structure large and complex. No membrane material that can be used at cryogenic temperatures has been found. Elastomeric membranes have poor cycle life in liquid oxygen and hydrogen diffuses through at an

33

unacceptable rate. At these low temperatures metal membranes suffer from poor flexibility and limited life due to cracking. This presentation identified a number of technologies to fill the gaps between current capabilities and system requirements to fill mission needs. A few of the technologies addressed in this presentation were automated cryogenic fluid couplings, transfer line chill, tank chill/fill in low gravity, cryogenic liquid acquisition in low gravity, alternative options to screen-channel LADs (risk reduction), long-life space environment compatible cryogenic insulation and coatings (no thermal performance degradation), LH2 flight cryocooler (sufficient scale, high efficiency, long life), and various zero-g mass gaging concepts for high accuracy (risk reduction). 7.1.5 Modeling and Tracking Technology Performance in Autonomous Systems and Robotics Dr. Neville Marzwell presented a broad perspective view of autonomous and robotic systems and how to model and track their performance. The Autonomous Systems, Robotics, and Computing Systems capability roadmap details the information technology and robust hardware and computing technology required for NASA spacecraft, robots, and human/robotic teams to explore harsh dynamic environments safely and affordably. Associated technologies include autonomous operations, Integrated Systems Health Management (ISHM), vehicle control, process control, robotics for solar system exploration, robotics for lunar and planetary habitats, robotics for in-space operations, software validation and verifi-cation, and avionic systems (incomplete). According to the NASA Advanced Planning and Integration Office (APIO), autonomous systems, robotics and computing does not include: supercomputing, data archiving and analysis, computer networks and grid computing, Robotic hardware (except as required to develop and benchmark software), much of “classic” computer science – compilers, programming languages, databases, etc. (except in limited cases as driven by the capabilities above). Assessing, modeling, predicting, forecasting technology evolution has challenged system developers, researchers, and users for centuries. System developers measure system performance and capabilities in terms of functions, operabilities, and “quality of life.” Technologists feel more comfortable with focused granularities which they create and understand within their communities…”jargon”, e.g., resolution, pixel density, Isp, power density per mass or volume, i.e., “physical parameters.” Measuring technology correctly becomes too complex and requires experts and specialists, which reduces its value as a tool for non-experts, mangers, cost accountants, bean-counters, market developers, and system users, which it is supposed to serve in the first place “dollars per capabilities.” Exploration is a contact sport. To understand our universe and to search for life, NASA robots and spacecraft will be: on and under the surface of Mars, on cliffs and in caves, on asteroids and taking samples on comets, on the surface and in the clouds of Venus, under the clouds of Titan, under the ice on Europa, and on the moon searching for resources and preparing for a long-term human presence. Manned and unmanned missions will be carrying out increasingly challenging tasks far from Earth including: habitat construction and long-term habitation, in-space construction of spacecraft and obser-vatories, mining and in-situ resource utilization, and deep drilling (lunar, Mars, Europa, etc.), spacecraft constellations (interferometry, gravity wave detection, Earth-Sun connection, etc.), scientific laboratory tests currently done only on earth, and biological and habitability analysis will augment the missions. These missions create pacing NASA challenges in autonomy, robotics, and computing.

Autonomy, robotics and computing are heavily cross-cutting. Most capabilities are relevant to multiple missions and mission classes. For purposes of the roadmap we have listed the first major driver. In many

34

cases these technologies provide control and execution software for hardware developed by other capability roadmaps (e.g., drilling, EDL, nuclear reactors, life support, etc.). Conversations with these capability roadmap teams have begun and will increase once all teams have full packages. Numerous autonomy and robotic capabilities have applications in superficially very different missions (e.g., control and execution software shared between rovers, drilling, life support, and interferometry). Such sharing can reduce costs, shorten schedules, and reduce risks. This is an important lesson of agency-level analysis. Common themes include:

• Communication latencies create pacing NASA challenges • Surface exploration drives autonomy and robotics • The other driver is challenging manipulative tasks (construction, drilling, ISRU, constellations,

science experiments, etc.)

Visual learning and recognition- Although advances in vision are consistent and of great practical use, especially recent object recognition work in the vein of spatially invariant feature detection, break-through advances in the areas of visual recognition of human-made and natural objects across extreme environmental variation, coupled with learning, enabling fielded humans to explain and identify what characteristics to look for and how to categorize what is seen for interpreted perception, would signifi-cantly lower the cost and risk associated with robotic inspection and robotic manipulation of structures. This capability has the potential to trigger one to rethink the costs of long-duration stays on the moon and on Mars. Robotic tactile dexterity - Best forecasts will project that robotic dexterity will approach that of an EVA-suited human in the near future. If revolutionary advances in robotic tactile, feedback-based manipulation enable robots to achieve human naked hand-level dexterity and specific energy with human-level tactile feedback, this would completely change the regime of tasks that will be performed by robots during surface habitation activities. This revolutionary progress, requiring both changes in both muscle motor technology and surface sensing technology, would dramatically lower the cost of in-space and surface assembly and maintenance activities by more than an order of magnitude. All-Planetary Vehicle - Current rovers are limited to exploring small sections of relatively benign terrain. However, the most interesting science sites lie in relatively inaccessible and inhospitable locations (on the sides of cliffs/craters, up in the mountains, in deep valleys). It would be a breakthrough in robotic exploration to have rovers that could go essentially anywhere on a planet that the scientists want to go. Besides the obvious need for advances in mobility, this capability would require significant advances in perception, planning, control, monitoring, and safeguarding. Self-Aware, Self-Correcting Robots - By its very nature, exploration involves dealing with the unknown and unexpected. Current robots have limited capabilities for understanding when they are outside their limits and, if they are, how to get back to a nominal mode of operations. This is especially apparent when things go wrong internal to the robot (such as sensors or actuators malfunctioning). It would be a breakthrough in robotic exploration to have a capability that monitors the robot at all times for these situations, recovers from (or compensates for) such failures, and learns from past mistakes to avoid making them in the future.

35

Crew-Centered and Autonomous Operations - This capability area, shown in Table 4, defines the evolution of command and control for both manned and unmanned science and exploration missions. This includes: crew-centered planning (activity sequences created by crew rather than ground person-nel). Autonomous mission operations involve health and safety monitoring, analysis and anomaly recovery, science analysis and optimization, dynamic planning, onboard robust execution, logistics and inventory, multi-system coordination and collaboration, human automation interaction, and multi-modal interfaces for collaborative execution.

Table 4 Capability Area for Command of Control of Exploration Missions

Metric Technology / Sub-Capability SOA Target

Value Need Date

Distance traveled per day Autonomous Navigation Aerial Traverse

100m 1km

1km 10km

2009 2015

Difficulty of terrain that is accessible Autonomous Navigation VL1 >VL2, cliffs,

craters 2015

Drilling depth Sub-Surface Access 10’s cms 10-20 ms 2013 Autonomously controlled manipulator degrees of

freedom

Instrument Placement, Human-Robot Interaction 7 10’s 2020

Command cycles per sample acquired

Instrument Placement, Field Science 3-6 1 2009

Command cycles per sample processed Field Science Dozens 1-2 2013

Command cycles to survey/characterize site Field Science >100 <20 2020

Percent of interactions interpreted correctly by

robot

Multi-modal communication Behavior tracking

80% 70%

95% 95% 2020

# robots supervised per human

Human-Robot Field Science Co-located Interaction <<1 3-5 2020

Operation of crewed missions (Station and Shuttle) is presently a manually intensive process: Station flight controllers uplink ~500,000 individual commands per year to fly and maintain the craft. A team of 50 Station mission planners manually develops a timeline for each crew member, which takes 2 weeks for each day’s activities. Safety and feasibility constraint checking is not automated, but is handled through the knowledge of these experts. The Russians (who do not have constant communi-cation via TDRSS as we do) upload some automated procedures. Operation of unmanned vehicles is done via ground based sequence generation with some low level task automation and automated constraint checking; onboard automated safety procedures are routinely implemented. Robotics for In-Space Operations - This capability area, shown in Table 5 defines the robotic systems needed for assembly, inspection and maintenance, and human-robot interaction in space. This capability includes:

• Assembly - mass manipulation (large, medium, small, fragile), preparation (unpack, identify, order …), connecting (align, mate, verify), self assembly (deployment, docking, etc...)

• Inspection - structural (mechanical damage, air leaks, deterioration), access ( under thermal blankets, delicate surfaces, confined space locations), component/system failure detection (fault detection, non-destructive evaluation)

36

• Maintenance - mass manipulation (medium, small), locomotion (moving to points along fragile structures), staging, (protection removal, temporary stowage, connector removal, etc…), human rated interface manipulation (crew and robots use same interface to manipulate objects), dexterous manipulation

• Human-robot interaction - multi-agent teams (assistants, surrogates), intent communication (feedback, task verification, …), and time delay compensation

Table 5 Capability Area of Robotic Systems Needed for Space Activities

Metric Technology / Sub-Capability SOA

Target Value

Figure of Merit

Need Date

# human interventions per task Site development & maintenance > 10 < 3 2012

Structural connections per hour Site development < 10 > 30 2015

Average distance navigated per human intervention

Field logistics and operations support <100m 1000m+ 2020

Proportion of navigation goals achieved

Field logistics and operations support 96% (MER) 99% 2020

% reduction of human cognitive load Human-robot interaction << 10% 25% 2008 (OASIS)

Maximum parallel human-robot supervisions Human-robot interaction ~ 1 3+ 2020 (Mars)

Cubic meters excavation per hour Robotics for ISRU ? ? 2015

Figure 17 Roadmap for Increased Autonomy

37

7.1.6 System Model Presentations

After the technologists and concept developers explained the history, state-of-the art, and future fore-casts for important technologies, the ATLAS modeling team presented an overview of the spreadsheet system models in the library. Dave Young, from Georgia Institute of Technology, presented an overview of the transportation models and explained their model development process. Craig Schafer, from Sci-ence Applications International Corporation (SAIC), presented an overview of the Capsule model. Don Perkinson, from Jacobs Sverdrup, presented the Low Earth Orbit (LEO) and Lunar Orbit (LO) propellant depot models. David Young presented an overview of the transportation models developed by the Space Systems Design Laboratory at the Georgia Institute of Technology. The Georgia Tech models fall into three different transportation categories; earth-to-orbit transportations systems, the in-space transportation systems, and the excursion transportation systems. The transportation models are derived from individ-ual design activities involving integrated product teams. These models are physics based and derived from single point designs using NASA standard conceptual design tools. These single point designs are then adapted to be parametric and incorporate the standard ATLAS model template. When the models are created the IPT explores a selection of technologies that could affect the model. The team then selects the top technologies that affect the model and these technologies are incorporated into the ATLAS model. The models are then verified by the IPT at different historical design points. Once these models are verified they are sent to the ATLAS integration team to be incorporated into the newest version of ATLAS. Before the TIM, Georgia Tech delivered 18 transportation models to the ATLAS Integration Team. These models are parametric, and depend on design decisions (such as time on surface, number of crew, etc.) as well as technology choices (such as structure type and engine performance). Some models such as Rapid Transfer Module (RTM) and Propellant Re-supply Module (PRM) were created for a particular lunar campaign, while most are general enough to be used for any campaign. A summary of each of the inputs and outputs to the transportation models is included in the Model Compendium. Craig Shafer presented an overview of the Capsule model. Capsule is a multi-subsystem, physics-based analytical model for simulating manned spacecraft. It is derived from the Mass Analysis System Sizer (MASS) model developed by D. Fletcher (NASA/JSC). It has been altered to simulate capsule-like spacecraft (as opposed to lifting bodies or shuttle-like aerodynamics) and to communicate with the rest of ATLAS. Inputs are received from the ALTAS user through the User Choices Sys and User Choices Tech selections. Capsule interrogates the Technology Tool Box (TTB) for the current information on technology selections. The output masses are reported in the System Summary worksheet. The Configu-ration worksheet was developed to drastically reduce the number of inputs required from over sixty to a more manageable number. The Configuration worksheet holds the pre-selected inputs for a number of spacecraft. The following subsystems are modeled:

• Avionics (communications, computers and displays, guidance, reentry avionics) • Crew accommodations (galley, hygiene facilities, crew health systems, housekeeping systems) • Structure (physical structure of the vehicle) • Attitude control system

38

• Environmental control and life support systems (atmosphere supply & regulation, ventilation and thermal conditioning, fire detection, trace contaminant control, water management)

• Thermal control system (single or dual loop heat exchange system) • Power system (primary and secondary) • Extra Vehicular Activity (EVA) (space suits, tools, and airlocks) • Landing systems (parachutes, parasails, landing gear) • Mechanisms (hatches and other mechanisms) • Thermal protection system (heat shields)

All subsystems report mass, and most report volume and power when applicable. Some iteration is required, and is accomplished with circular references. Capsule requires over 60 additional inputs, which are controlled by the Configuration worksheet. The Configuration worksheet is a lookup table of the inputs for several pre-configured vehicles. The outputs are selected by the vehicle selection in the User Choices Sys worksheet. There are also additional inputs in the ECLSS, Thermal Protection System, and Thermal Control System models that are not currently alterable by the user or addressed with the Configuration worksheet. Such a capability may appear in future versions of Capsule as the TTB is filled, provided there is interest in the user community.

It should be noted that the PCAT CLEM’s power is drawn from a companion Mission Module, which generates power from solar arrays. The CLEM’s batteries only provide power during reentry. In order to properly simulate this, ATLAS must pass the power requirement to the Mission Module model during runtime. This is accomplished by providing the power requirement in the Output ICD table in the ICD worksheet. It is also understood that Capsule presently overestimates the dry and gross masses of the Apollo Command Module by about 23%. This is due to an overestimation of the structural mass (the error bars of the structural mass estimation algorithm is +/- 35%), and a lack of historical mass data for its various subsystems. These discrepancies will be resolved as better structural mass estimation techniques become available.

An Integrated Products Team was formed at the TTB TIM to aid in improving and further developing Capsule. Future work includes:

• Improve Thermal Control System (TCS) spreadsheet(s) by adding a heat pump and the capability to change working fluids, number of thermal arrays, thermal array materials, etc.

• Add regenerative ECLSS systems. • Add selectability of TPS materials and improve TPS mass calculation. • Add Crew Exploration Vehicle (CEV) vehicle to Configuration Table. • Determine what additional variables need to be user-controlled. Find the right balance of user

inputs. • Implement auto-resizing based on size of crew and duration of inhabitation. • Perform volume checking and auto-resizing or issue warnings if volume exceeds limit. • Radiation shielding

After Craig Schafer presented, Don Perkinson, from Jacobs Sverdrup, introduced the group to the Low Earth Orbit (LEO) and Lunar Orbit (LO) propellant depot models. The lunar orbit depot is based on the growth Centaur, modified for long-term storage. It is assumed that transfer vehicles will have about the

39

same ratio of hydrogen to oxygen requirements as the Centaur, and will require roughly the same pro-pellant load in the early phase of exploration being addressed here. Growth was allowed to three tank sets, thus providing propellant capabilities of 20,000 kg, 40,000 kg, and 60,000 kg. While the Centaur uses nested tanks, these could be separated, much additional insulation added, and a fill and drain sys-tem included. Information was obtained on cryogenic cooler masses, and a generic cryocooler option was included that is a function of insulation capability and number of tank sets. A power system is included, interfaced to the TTB for both solar array technology and battery technology. No reboost system is included since it is assumed to be in a lunar orbit high enough to not require reboost between re-supply visits, at which time the re-supply vehicle can perform reboost maneuvers. A Low Earth Orbit Depot is also included in ATLAS. This is a more complex model that includes an electrolyzer to convert water into cryogenic oxygen and hydrogen for use as propellants. Since it is orbiting the Earth, in includes additional logic to handle orbital altitude and inclination, and orbit reboost frequency and decay limits. The storage capability is continuously variable over a wide range. 7.1.7 Headquarters Commentary John Mankins provided his perspective on the progress of ATLAS and the TTB. He recommended establishing short-duration Integrated Product Teams (IPTs). In this workshop, modelers have been in one working group and the technologists in another group. With technologists and model developers working together, an IPT can focus on integrating data from the TTB into the models. Presently, ATLAS only transfers masses among workbook models. As an area for improvement; the system should pass a variety of parameters. In addition to costs, the system should present other campaign-level or system-level benefits. Examples of system-level benefits include: improved performance values, dis-tance traveled on the lunar surface, or reliability. A technology could reduce cost, even though it does not decrease weight. One possible example is a decrease in operations cost resulting from greater com-ponent and/or system reliability. ATLAS and the TTB should provide the capability to define a new technology so an analyst can see whether the systems or architectures which employ this technology are sensitive to a particular parameter. For example, if we could reach the theoretical limit of a tech-nology’s performance is reached, would it significantly affect the system or architecture? Additional questions that remain include:

• How is the current TRL reflected in the overall development/maturation cost of a given technology?

• How should learning curves be applied in computing costs? John Mankins recommended that the team think methodologically about applying ATLAS to examine these issues.

7.2 Thursday Models and Architectures Working Group 7.2.1 Resolving the Solver Problem The group discussed an on-going challenge in model development – the use of the Excel Solver tool. Solver is an Excel optimization tool for complex formulas. Typically, Solver seeks an optimal value for a target cell by varying, within constraints, adjustable cells specified by the user. Solver serves

40

an important modeling function, but its implementation has caused problems. For example, it is not always reliable in its indication that it has closed on a value; in some cases, additional iterations have been required to generate an optimum result, despite a Solver indicator that showed it had converged on a value. Many of the calculations for which modelers have used Solver can be completed using carefully struc-tured circular references. This approach was preferred by much of the group, because the modeler has more insight into its implementation and operation. However, Solver does provide a capability for cer-tain types of problems (min/max problems with constraints) that are significantly more difficult to replace with an alternative implementation. The recommendation of the group was that modelers use the circular reference approach where possible. The group recommended that modelers rely on Solver in the near term only where necessary to avoid significant additional programming. When Solver is used, modelers are to incorporate a dialog box to indicate when Solver has not converged. The group expressed a preference to evolve ultimately to a hybrid solution employing a combination of the built-in Excel goal seek function and Excel’s VBA capabilities for this type of constrained problem solving. 7.2.2 Technology Tool Box (TTB) Search Macros Clara Welch presented to the Models and Architectures Working Group a summary of search functions and macros within the TTB. Currently ATLAS retrieves data from the TTB for two purposes. The first aim is to populate system model workbooks with technology “performance” parameters used in calcu-lating mass. The second aim is to populate the ITAM with “programmatic” metric data for two main purposes, 1) calculating the Integrated Technology Index (ITI) associated with the “TechPortfolio” of a given scenario (case study), and 2) generating “Technology Forecast” charts which plot perfor-mance parameters and TRLs vs. time for technologies associated with a given scenario (case study). To retrieve the data from the TTB workbook, three pieces of information are necessary:

• The worksheet in which the data is stored (there are 80 worksheets in the TTB workbook). • The row on which a particular metric is located (there are multiple rows per technology). • The column corresponding to the time frame for which the data is requested (there are 12 time

frames per sheet). The current naming convention in the TTB is such that each three digit WBS number (e.g. 2.10.1) is assigned its own worksheet. That sheet then contains the technical information for all of the technologies grouped under that technology element. An individual technology can be found on a sheet by searching for the unique five digit WBS number. The first occurrence of the number will correspond with the first line of the technology record. In order for the Excel models to find the exact row of a particular technology record, the “metric name” must be matched, and to find the column, the time frame must be matched. Currently the use of mnemonics is different depending on whether the models are being populated or ITAM is being populated. Search macros developed to populate the ITAM use the TableID and the TechID (including those of assumed technologies) to find the WBS number. It is important that the correct TableID appear

41

in the units column of the model’s UserChoices_Tech sheet. If the model is called out in the Script for a given case study, this same TableID must appear in the units column of the case study ICD sheet. The search macros used for populating the technology data in the system models depend on entries in the TableID and TechID columns of the model’s WorkArea sheet. These search macros used the sLookup WBS function in the SIAM_Controller to map TechIDs to WBS numbers. They then use the exact metric name (also in the model’s WorkArea) and the timeframe (carried along in a variable during ATLAS execution) to locate the exact row and column within the TTB. If a name is entered in the TechID column of the WorkArea, and it isn’t a valid TechID for the TTB, it will be assumed to be user defined, and must have entries in a user defined column in the WorkArea, otherwise an error will result (and be logged first to the model’s error sheet, and then to the SIAM_Accumulator Errors sheet during ATLAS execution). The testing of retrieval of data from the TTB into the WorkArea sheet can be performed using just the SIAM_Controller, the model workbook, and the WorkingTTB. The following screen shot shows the Capsule model’s WorkArea, Figure 18, with the TableID and TechID columns, and an example user defined technology (AIRLOCK is the TableID and None is the TechID).

Figure 18 Capsule Model’s Work Area

42

The following code snippet shows how the WBS number is found for a given TechID:

Select Case sTechID Case "MachMech": sLookupWBS = "2.1.1.4.1" Case "MachDM": sLookupWBS = "2.1.1.4.2" Case "CoreDrill": sLookupWBS = "2.1.2.3.1" Case "UltSonicDrill": sLookupWBS = "2.1.2.3.2" Case "SCMBG": sLookupWBS = "2.2.1.1.1" Case "ThinFilm": sLookupWBS = "2.2.1.1.2" Case "SLA": sLookupWBS = "2.2.1.1.3" Case "AdvHT": sLookupWBS = "2.2.1.1.4" Case "Rainbow": sLookupWBS = "2.2.1.2.1" Case "QuantDot": sLookupWBS = "2.2.1.2.2" Case "Brayton": sLookupWBS = "2.2.1.4.1" Case "SNRPS": sLookupWBS = "2.2.2.1.1" Case "TOPAZII": sLookupWBS = "2.2.2.1.2" . Case "CAESTank": sLookupWBS = "2.10.2.6.2" Case "GESHydro": sLookupWBS = "2.10.2.7.1" Case Else sLookupWBS = "" End Select

The above code snippet is semi-auto-generated from a TTB by Steve Patrick each time a new TTB is released, and can easily be integrated into ATLAS to add, remove or change TechIDs as they are added, removed or renamed within the TTB. Note that all that is required to find a WBS number for a given technology is the TechID (incidentally, the TableID field is only used as a flag to indicate that the variable is a technology to be retrieved from the TTB). One potential improvement to the TTB would be to organize the technologies into sheets (with the TableID mnemonic instead of using the first three WBS numbers as sheet names, and TechIDs as row identifiers rather than the full five WBS numbers. Somewhere on each TechID row, the WBS number could be recorded for any necessary cross-referencing. This would allow the TTB to function independently of the vagaries of the NASA budget WBS. 7.2.3 Requirements Definition and Documentation Charlie Morris concluded Thursday’s Models and Architectures working group by leading a discussion on requirements definition and documentation, and what enhancements can be made to the reporting for ATLAS. Application of good systems engineering practices calls for an update to the articulation of requirements and other key documentation. This is intended to ensure good communication between the developers and the customer/user as ATLAS development continues. After review of an expanded set of requirements statements, a streamlined, higher-level set is being crafted for approval. The latest set of zero-level requirements covers four considerations:

1. Performance – “A desk-top-computer-based tool will allow assessment of the impacts of technology and architecture for space systems.” (Level-1 requirements address: interactions with other tools, output parameters, run time, model/technology-set compatibility, etc.)

2. Ease of operations – “Easily available documentation, training, support and operations characteristics will make the code easy to use.”

43

3. Confidence of use – “Configuration management, data management and testing will ensure a high level of user confidence in results.”

4. Schedule and budget – “Agreements with the funding sponsor will define both schedule and budget.”

Some discussion addressed achieving greater near-term utility and confidence by: (a) focusing on a lim-ited number of model and technology sets; (b) conducting a well coordinated process of certifying, test-ing and documenting to form a core of approved models and technology data; then (c) adding new model and technology sets to the approved list by giving them the same rigorous treatment. This may require a change in programmatic metrics to promote certifying, testing and documenting rather than creating a larger number of models and technology sets. This approach should promote more confident use of ATLAS by keeping the user clearly aware of factors such as the limits of applicability for a given model as well as relative strengths and weaknesses among the models.

7.3 Thursday Technologies Working Group On Thursday, the Technology Working Group reconvened to further discusses enhancements to the TTB and data collection strategies. At the beginning of Thursday’s technology working group breakout ses-sion, Elaine Gresham from The Tauri Group presented the ongoing data collection process for the TTB. The presentation included a summary of previous data collection efforts such as the filtering of RASC and CRAI datasets as well as a status of the ongoing effort. The presentation outlined the goals for the technology working group to accomplish in the breakout session. Specifically, she discussed how best to coordinate the data needed by the modelers with the ongoing data collection effort. Some time was also spent addressing questions from the working group about how to utilize the online version of the TTB and, an introduction to gaining access was presented by Dr. Monica Doyle. After Ms. Gresham’s presentation, the working group split into simultaneous sessions, with one group meeting to discuss changes to the TTB and other big-picture technology issues, while smaller splinter sessions engaged in tactical discussion between modelers and technology data providers to find the best overlap of useful and available data for the TTB. During the larger group discussion, Dr. Monica Doyle presented a summary of changes made to the TTB as a result of the inputs received during the previous TTB in November of 2004. Each of the items from her presentation generated discussion among the group to better understand the subtleties of the TTB in its current form. Specifically, the group discussed several field and definitional changes in the database (e.g. technology R&D maturation paths, goal and threshold values, data maturity ID); changes to the way the TTB operates (e.g. data processing in the TTB, the TTB workbook split); and improve-ments to the format and user interfaces in the database. While this discussion was ongoing, several of the groups providing data to the TTB were able to meet with ATLAS modelers to exchange ideas and data. The idea for integrated product teams (IPTs) was proposed on Thursday morning by John Mankins, to consist of ATLAS modelers and data providers to coordinate data collection priorities and identify model sensitivity areas utilizing TTB data. A prototype of the IPT was implemented in the afternoon technology working group break out session. In these groups, ATLAS modelers Dave Young and Craig Schafer reviewed the possible sources of data avail-able and how this data could fit within their ATLAS models. Each modeler met with: Dr. Randy

44

Humpries from QTEC regarding the potential uses for Apollo and Skylab data; Jim Thomas from ISSI on the utilization and provision of structures and propulsion data; Bob Lovell from MSFC to discuss structural models and related data; and Robyn Carrasquillo from MSFC regarding the use and provision of ECLSS-related data. In addition, Tim Sarver Verhey met with Monica Doyle to discuss data Glenn Research Center (GRC) is providing to the TTB. This data includes solar power generation and electric propulsion performance and development data compiled and provided by the Power and Electric Propulsion Division at NASA Glenn Research Center for use in the ATLAS Technology Toolbox. The data were compiled for the following technologies:

• Single Crystal Multi-Band Gap Solar Cell Based Photovoltaic Arrays • Thin Film Solar Cells on Flexible Substrates Based Photovoltaic Arrays • Stretched Lens Array (concentrator) Photovoltaic Arrays • Rainbow Multi-Band Gap Solar Cell-Based Photovoltaic Arrays • Quantum Dot-Based Solar Cell-Based Photovoltaic Arrays • Solar Dynamic with Brayton conversion Power Generation

Array Arc Prediction and Mitigation data were also provided. Additionally, the propulsion technologies added to the TTB include:

• Electrostatic Ion Thrusters • Hall Effect Thrusters • Magnetoplasmadynamic Thrusters

The data provided covered four time frames: 2005-2006, 2015, and 2025. The intervening time gaps will have to be filled in via extrapolation. This data is in addition to some Power Management & Distribution data provided last year. Comparable information on energy storage systems will be sought out for inclusion into the TTB. Thursday’s Technology Working Group session was concluded with a review of the topics discussed and the opportunity to share perspectives on priority areas and possible improvements in the TTB and the data collection process.

45

8. PROCEEDINGS: FRIDAY On Friday the group shared conclusions and recommendations in a joint plenary session before adjourning the TIM mid-day. Each of the sessions and the accompanying presentations from the TIM are detailed below; in addition, Appendix A contains the detailed TIM agenda.

8.1 Friday Plenary To kick off the Friday plenary, Carissa Christensen gave a brief presentation on a twenty-year NASA technology forecast from 1976. The top-level summary highlighted the findings of the NASA report A Forecast of Space Technology 1980-2000, released in January 1976 as an element of a NASA planning study, “Outlook for Space,” initiated by Administrator James C. Fletcher in 1974. The technology fore-cast was conducted by JPL and supported by NASA centers. The presentation described selected forecasts for technology in 2000 drawn from the 1976 study. The presentation noted that in general, where forecasts were driven by expectations of NASA funding and activity, the level of technology advancement had been appreciably overestimated. A telling example is ETO launch prices, which the forecast predicted would be about $50/kg (or $23/lb) in 1975 dollars. That translates to about $80 per lb in today’s dollars. Of course, today’s actual launch prices are nowhere near that low, but are about 200 times higher – around $4,000/lb to LEO. On the other hand, where forecasts were driven by expectations of a moderate to significant level of commercial demand, forecasts were more accurate or even underestimated the degree of technology advancement. A dramatic example is in the area of data storage, where the NASA forecast predicted significant advances, anticipating that by 2000, it would be possible to achieve about 125 GB per cubic meter for computer memory. A stack of a few laptop hard-drives easily exceeds that capacity, in a volume far less than a cubic meter. 8.1.1 Products From the Technology Working Group Friday’s summary presentation of the two days of progress from the Technology Working Group break-out session was given by Elaine Gresham. Ms. Gresham summarized the presentations given and major topics of discussion in the working group, and explained the conclusions reached and next steps for the group. During her presentation the group participated in a discussion about the recommendations from the TIM in November, 2004. Although the TTB team had addressed the recommendations from the pre-vious TIM in changes to the format and substance of the TTB, there was no formal reporting process for tracking those recommendations. It was suggested that for the next working session that it would be beneficial to re-visit the recommendations and report on progress made. This suggestion is planned for implementation in the next group meeting.

46

8.1.2 Products From Models and Architectures Group Dr. Harvey Feingold presented a summary of the activities and products of the Models and Architectures Working Group sessions as well as some conclusions from those sessions. Dr. Feingold opened his pres-entation with a summary of the current status and future needs of ATLAS, which were discussed in detail during Wednesday’s Models and Architectures Working Group. He explained that ATLAS is an operation tool that can roughly analyze the impact of technology choices on a variety of systems, missions, and architectures in terms of mass and cost. Although ATLAS is flexible to handle simple and complex analyses, it will remain difficult to use until some of its needs are addressed. Most impor-tantly, ATLAS needs a working TTB with significant technology data, technology forecasts, and realistic programmatic information. Other ATLAS short-term needs include a check on consistency of terms and units between the TTB and the ATLAS system models; a certification process for models and technology data; more documentation for the ATLAS team; and an overall test of ATLAS functions and features for operation. Specifically the working group addressed the TTB, model accuracy needs and strategies, and improvements and suggestions for model usability. In addition to presentations and discussion on ATLAS status and needs, the working group also addressed the future business case for the ATLAS models and systems during Wednesday’s session. Dr. Feingold followed this with a presentation on Thursday’s progress in the Models and Architectures Working Group. He summarized the session that was moderated by Clara Welch and included presenta-tions by Don Perkinson, Clara Welch, Harvey Feingold and Charlie Morris, which were summarized previously. Specifically Thursday’s major topics of discussion during the working group included problems and strategies for Solver; a demo of impairments to and techniques associated with the TTB; a discussion of Script Reader and case study development; and documentation for developing ATLAS system models with the model developers guide. This presentation led to an additional group discussion on the importance of documentation and short and long-term goals for documenting ATLAS programs and procedures.

47

9. CLOSING DISCUSSION The meeting ended with a group discussion of near-term actions needed to ensure that ATLAS is as useful as possible to NASA in achieving its new architecture and launch goals. These new goals are embedded within a new NASA context (depicted in Figure 19) that has moved toward engineering-oriented, rather than process-oriented, leadership under the new Administrator, Dr. Michael Griffin. Dr. Griffin has defined ambitious, near-term goals and has instituted a focused, headquarters-led study process to define a new launch vehicle and architecture to meet these goals. Efforts to ensure critical path success in launching a new vehicle as early as 2010 appear likely to rely extensively on experienced hardware contractors. This near-term operations focus has re-ordered NASA’s priorities and changed the set of urgent prob-lems. ATLAS, in order to be relevant and useful in this new context, must be demonstrably useful in solving immediate problems. The primary role of ATLAS will shift from that of a tool to help HQ man-agers plan long-term technology investments to that of a tool to support nearer-term engineering trades for active programs at the field centers. The group agreed that ATLAS has significant applications as a collaborative engineering tool that directly supports current objectives through trade studies and assessments. (An example discussed was characterizing the new NASA exploration architecture in ATLAS and showing the driving technology and cost differences from Apollo missions.) ATLAS should interact with other collaborative engineering tools to be fully useful. Figure 19 is a chart presented by Carissa Christensen to summarize some of the recent changes at NASA. The chart generated discussion and helped focus the ATLAS team towards aligning future efforts with NASA’s highest priorities. The group also discussed longer-term future activities, including the development of new models, collecting additional data for mature technologies, and developing new metrics that extend beyond mass and cost, to explicitly address mission performance. Group members commented on the importance of communicating with relevant technologists, engineers, and managers (especially the payload community) and urged all participants in the TIM to share their knowledge about ATLAS. Several said they intended to present conference papers on aspects of ATLAS. The group discussed the TIM format, and how it could be enhanced at future meetings. Suggestions were to, at the next TIM, further expand the discussion of progress since the last TIM and provide updates on action items. The group also agreed that the ATLAS project should continue to use inte-grated product teams, as piloted at this TIM, throughout the project as needed. There was discussion of having more focused TIMs, separately addressing the database, the models, or the software. Finally, it was agreed that the most efficient schedule for TIMs would be to start at noon on Tuesday and end on Thursday afternoon.

48

Previous New Process-oriented

leadership

Competition-based selection of new launch vehicle

Wide range of contractors

Long-term technology focus

Long-term technology planning for HQ

Support nearer-term engineering trades for Centers

Near-term operations focus (human launch in 2010)

Experienced hardware contractors

HQ-defined new launch vehicle

Engineering-oriented leadership

Figure 19 Recent Changes at NASA

49

10. NEXT STEPS The next ATLAS milestone is the project review, scheduled for August, 2005. A draft of this publication will be presented at the review, along with a performance scorecard and programmatic metrics. The ATLAS development team will also discuss the potential of ATLAS in advancing NASA’s new exploration architecture. TIM participants were asked for specific recommendations on future actions and activities to ensure that the investment NASA has made in ATLAS continues to yield benefits across the agency. Participants identified several key applications for ATLAS in the new NASA context, including its value to near-term evaluation and assessment of alternatives. For example, ATLAS can aid NASA in evaluating system/technology performance and cost claims in contractor proposals. ATLAS also enables quick evaluation of the performance impact of using different technologies in proposed payloads and systems for both lunar-based and in-space applications (both crewed and robotic missions). During a program’s development phase, ATLAS would enable a user to quickly evaluate the effect of various system changes, e.g. growth, on a mission or a full campaign. ATLAS is also a useful tool for improving communication and consistency among the many organiza-tions and individuals that will be involved in design, development, engineering, test, manufacturing, launch, and operation of a variety of systems and payloads. ATLAS can be used to ensure top-level analyses are drawing on models making the same assumptions, so that alternatives can be meaningfully assessed. In addition, the TTB could serve as a stand-alone technology reference for NASA as well as all NASA contractors. Finally, participants offered process-oriented recommendations, such as an annual technology review, and development recommendations, such as increasing the ease of use of ATLAS to ensure the broadest range of users. Based on the outcome of the ATLAS mid-term review and guidance from NASA leadership, the ATLAS development team will tailor its program plan and activities to ensure that ATLAS continues to fulfill its potential to be a valuable aid to the NASA community in meeting the exciting and ambitious challenges we face.

50

APPENDIX A—AGENDA

Technology Tool Box (TTB) Technical Interchange Meeting (TIM)

National Space Science and Technology Center (NSSTC) July 27th through July 29th 2005

Agenda Outline Wednesday, July 27, 2005 Plenary Session, Room 1010, Capacity: 44 people Objectives: Provide context for ATLAS project and present a status of the project and tools. Topic Presenter8:00 a.m. Safety and Logistics Daniel O’Neil 8:15 Opening Remarks John Mankins

ESRT Program Overview Motivation for ATLAS and the TTB

8:45 ATLAS and TTB Project Overview Daniel O’Neil

Project Objectives Model and Data Score Card

9:15 ATLAS Demonstration Daniel O’Neil

Running a Case Study or Model Clara Welch Technology Forecasts from ITAM

9:45 Coffee Break 10:00 Technology Tool Box Demonstration (TTB) LaMonte Dent

Establishing an account Exporting from MySQL to Excel

10:40 Architecture Case Studies Dr. Harvey Feingold

Apollo - for calibration Bob Thompson Phased Capability And Technology (PCAT) Point of Departure (PoD)

11:20 Lunch ALL

12:40 Working Group Objectives Daniel O’Neil

Room Locations, Moderators, and Facilitators Expected Products for Thursday and Friday

12:50 Move to Working Group Sessions

51

Wednesday, July 27, 2005 (Continued) Technology Working Group Conference Room 1010, Seating Capacity: 44 people Presentation Presenter12:50 State of the Database Monica Doyle (SAIC)

Current content and level of certification Elaine Gresham (Tauri Group) Approach to Programmatic Data collection

1:40 Material and Structures Data Jim Thomas (ISSI)

2:30 Apollo & Skylab Historical Technology Data David O’Neil (QTEC) Dr. Randy Humphries (QTEC)

4:00 Plan for entering data into TTB ALL Models & Architectures Working Group, Conference Room 4068, Seating Capacity: 24

Discussion Topics Moderator12:50 ATLAS Capabilities and Needs Dr. Harvey Feingold (SAIC)

Models & technologies required for future architectures Bob Thompson (GT) 1:40 Subsystem Interaction Steve Patrick (Sverdrup)

Getting the Ripple Effect Don Perkinson (Sverdrup) Currently available subsystem sizing equations Craig Schafer (SAIC)

2:20 Case Study Builder Demonstration Jessica Kessler (DCI) 2:40 Ptolemy II Excel Interface Demonstration Wayne Goode (SAIC) 3:10 Expansion of Cost Model Capabilities Wayne Johnson (SAIC)

Using the cost model options in System Summary What is the full cost of technology? For example, technology integration

4:50 Adjourn Both Groups

52



Agenda Outline Thursday, July 28, 2005 Plenary Session, Conference Room 1010, Capacity: 44 people Objectives: Present an overview of technologies and existing ATLAS system models.

Catalytic Presentation Presenters

7:45 Breakfast ALL 8:00 Introduction to plenary presentations Daniel O’Neil

Technology overview presentations System model presentations

8:05 Integrated Vehicle Health Management (IVHM) Bill Kahle 9:30 Thermal management subsystem technology Ramona Cummings 8:55 Historical overview of Docking Mechanisms Linda Brewster 9:30 Cryogenic Fluid Management, Storage, and Transfer Joe Howell 9:55 Future Concepts for Robotics Dr. Neville Marzwell

10:20 Transportation models overview Dave Young (GT)

Bob Thompson (GT) 10:45 Capsule models Craig Schafer (SAIC) 11:10 Space Depots Don Perkinson 11:30 Perspectives on the evolving role of ATLAS & TTB John Mankins 12:00 Lunch ALL

1:00 Move to Working Group Sessions ALL Technology Working Group, Conference Room 1010, Seating Capacity: 44 people Objectives: Explain data certification process and describe forecasting methods. Presentation Presenter1:10 Technology Data Certification Process Dr. Monica Doyle

Establishing consensus and citing sources Elaine Gresham 1:40 Technology Forecasting Carissa Christensen

53

Thursday, July 28, 2005 (Continued) Technology Working Group, Conference Room 1010

Discussion Moderator2:05 Review of red fields in TTB and technology forecasts for TBDs Dr. Monica Doyle

Energy storage technology Elaine Gresham Power generation technology Propulsion system

3:10 Capture consensus on existing data Elaine Gresham

Dr. Monica Doyle

3:30 Discuss improvements to database and data collection process Elaine Gresham Adjusting to new work breakdown structures Dr. Monica Doyle Impacts to the database design

5:00 Adjourn Models & Architectures Working Group, Conference Room 4068, Seating Capacity: 24 Objectives: Discuss issues and potential improvements to the ATLAS software and database. Discussion Moderator1:10 Resolving the Solver Problem Don Perkinson

Creating a macro within the controller to replace Solver Creating a utility to seek out Solver on the local computer Replacing Solver calls with circular references

2:00 Technology Tool Box (TTB) Search Macros Clara Welch

Eliminating the need for the WBS numbers Developing an independent interoperable ITAM module

2:50 Revising the Script Reader to transfer power and other data Dr. Harvey Feingold

Adding additional rows above the scripts Improvements to the case study script Requirements for Case Study Builder

3:40 Model Developer’s Guide (MDG) Improvements Dr. Harvey Feingold

What do developers need from this guide? Charlie Morris Supporting documentation requirements Model Certification Process

4:20 Capture consensus recommendations to system and documents Tauri Group 5:00 Adjourn

54



Agenda Outline Friday, July 29, 2005 Plenary Session, Conference Room 1010 7:45 Breakfast Presentation or Discussion Presenter / Moderator 8:00 Products from the Technology Working Group Elaine Gresham

Data sets collected before or during the workshop Consensus on existing data marked with red fields Plans for follow-on data certification activities

8:50 Products from Models and Architectures Group Dr. Harvey Feingold

Recommendations for resolving Solver problem Recommendations for TTB Search independence from WBS Plans for increased interactions among subsystem models Plans for follow-on model certification activities

10:15 General discussion about the workshop and certification process Carissa Christensen

Capture audience recommendations for workshop improvement Capture audience ideas for follow-on activities to engage technologists

10:45 Closing Remarks Daniel O’Neil 11:00 Adjourn

55

APPENDIX B—PARTICIPANTS

Last Name First Name Org. Session Role Brewster Linda MSFC Technologist Participant

Christensen Carissa Tauri Architectures Faciltator Cummings Ramona MSFC Technologist Participant

Dent LaMonte UAH Technologist Presenter Doyle Monica SAIC Technologist Faciltator

Feingold Harvey SAIC Architectures Presenter Goode Wayne SAIC Architectures Presenter

Gresham Elaine Tauri Technologist Faciltator Guthrie Paul Tauri Technologist Support Howell Joe MSFC Technologist Presenter

Humphries Randy QTEC Technologist Presenter Johnson Wayne SAIC Architectures Presenter

Kahle Bill MSFC Technologist Presenter Kessler Jessica DCI Architectures Presenter Lovell Bob MSFC Technologist Participant

Mankins John NASA HQ Project Presenter Marzwell Neville JPL Project Participant

McClanahan Jim Boeing Architectures Participant Morris Charles MSFC Technologist Participant Myers George MSFC Architectures Participant O'Neil Daniel MSFC Project Presenter O'Neil David QTEC Technologist Presenter Patrick Steve Sverdrup Architectures Presenter

Perkinson Don Sverdrup Architectures Presenter Reeves David GA Tech Architectures Participant

Sarver Verhey Tim GRC Technologist Participant Sanders Jim ISSI Technologist Participant Schafer Craig SAIC Architectures Presenter

Skoniecznys Steven ISSI Technologist Participant Thomas Jim ISSI Technologist Presenter

Thompson Robert GA Tech Architectures Presenter Tickles Virginia MSFC Technologist Participant Welch Clara MSFC Architectures Presenter Young David GA Tech Architectures Presenter

57

xv

REPORT DOCUMENTATION PAGE Form Approved

OMB No. 0704-0188

Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintain-ing the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operation and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office of Management and Budget, Paperwork Reduction Project (0704-0188), Washington, DC 20503

1. AGENCY USE ONLY (Leave Blank) 2. REPORT DATE 3. REPORT TYPE AND DATES COVERED

4. TITLE AND SUBTITLE 5. FUNDING NUMBERS

6. AUTHORS

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORGANIZATION REPORT NUMBER

9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSORING/MONITORING AGENCY REPORT NUMBER

11. SUPPLEMENTARY NOTES

12a. DISTRIBUTION/AVAILABILITY STATEMENT 12b. DISTRIBUTION CODE

13. ABSTRACT (Maximum 200 words)

14. SUBJECT TERMS 15. NUMBER OF PAGES

16. PRICE CODE

17. SECURITY CLASSIFICATION OF REPORT

18. SECURITY CLASSIFICATION OF THIS PAGE

19. SECURITY CLASSIFICATION OF ABSTRACT

20. LIMITATION OF ABSTRACT

NSN 7540-01-280-5500 Standard Form 298 (Rev. 2-89)Prescribed by ANSI Std. 239-18298-102

Unclassified Unclassified Unclassified Unl�m�ted

Second NASA Techn�cal Interchange Meet�ng (TIM): Advanced Technology L�fecycle Analys�s System (ATLAS) Technology Tool Box (TTB)

D.A. O’Ne�l, J.C. Mank�ns,* C.B. Chr�stensen,** and E.C. Gresham**

George C. Marshall Space Fl�ght CenterMarshall Space Fl�ght Center, AL 35812

Nat�onal Aeronaut�cs and Space Adm�n�strat�onWash�ngton, DC 20546–0001

*Headquarters **The Taur� GroupPrepared for the Advanced Projects Team, Future Concepts Office, Space Systems Programs/Projects Office

Unclassified-UnlimitedSubject Category 12Ava�lab�l�ty: NASA CASI 301–621–0390

The Advanced Technology L�fecycle Analys�s System (ATLAS), a spreadsheet analys�s tool su�te, appl�es parametr�c equat�ons for s�z�ng and l�fecycle cost est�mat�on. Performance, operat�on, and pro-grammat�c data used by the equat�ons come from a Technology Tool Box (TTB) database. In th�s second TTB Techn�cal Interchange Meet�ng (TIM), technolog�sts, system model developers, and arch�tecture analysts discussed methods for modeling technology decisions in spreadsheet models, identified specific technology parameters, and defined detailed development requirements. This Conference Publication captures the consensus of the d�scuss�ons and prov�des narrat�ve explanat�ons of the tool su�te, the data-base, and appl�cat�ons of ATLAS w�th�n NASA’s chang�ng env�ronment.

72

M–1147

Conference Publ�cat�onOctober 2005

NASA/CP—2005–214185

analyt�cal spreadsheets, system model�ng, space explorat�on, arch�tectures, technology assessment

The NASA STI Program Office…in Profile

Since its founding, NASA has been dedicated tothe advancement of aeronautics and spacescience. The NASA Scientific and Technical Information (STI) Program Office plays a keypart in helping NASA maintain this importantrole.

The NASA STI Program Office is operated by Langley Research Center, the lead center for NASA’s scientific and technical information. The NASA STI Program Office provides access to the NASA STI Database, the largest collection of aeronautical and space science STI in the world. The Program Office is also NASA’s institutional mechanism for disseminating the results of its research and development activities. These results are published by NASA in the NASA STI Report Series, which includes the following report types:

• TECHNICAL PUBLICATION. Reports of completed research or a major significant phase of research that present the results of NASA programs and include extensive data or theoretical analysis. Includes compilations of significant scientific and technical data and information deemed to be of continuing reference value. NASA’s counterpart of peer-reviewed formal professional papers but has less stringent limitations on manuscript length and extent of graphic presentations.

• TECHNICAL MEMORANDUM. Scientific and technical findings that are preliminary or of specialized interest, e.g., quick release reports, working papers, and bibliographies that contain minimal annotation. Does not contain extensive analysis.

• CONTRACTOR REPORT. Scientific and technical findings by NASA-sponsored contractors and grantees.

• CONFERENCE PUBLICATION. Collected papers from scientific and technical conferences, symposia, seminars, or other meetings sponsored or cosponsored by NASA.

• SPECIAL PUBLICATION. Scientific, technical, or historical information from NASA programs, projects, and mission, often concerned with subjects having substantial public interest.

• TECHNICAL TRANSLATION. English-language translations of foreign

scientific and technical material pertinent to NASA’s mission.

Specialized services that complement the STI Program Office’s diverse offerings include creating custom thesauri, building customized databases, organizing and publishing research results…even providing videos.

For more information about the NASA STI Program Office, see the following:

• Access the NASA STI Program Home Page at http://www.sti.nasa.gov

• E-mail your question via the Internet to [email protected]

• Fax your question to the NASA Access Help Desk at 301–621–0134

• Telephone the NASA Access Help Desk at 301–621–0390

• Write to: NASA Access Help Desk NASA Center for AeroSpace Information 7121 Standard Drive Hanover, MD 21076–1320 301–621–0390

NASA/CP—2005–





October 2005

National Aeronautics andSpace AdministrationIS04George C. Marshall Space Flight CenterMarshall Space Flight Center, Alabama35812

Proceedings of a Technical Interchange Meetingsponsored by the National Aeronautics and SpaceAdministration held in Huntsville, Alabama,July 27–29, 2005

second nasa technical interchange meeting (tim): advanced

Documents