The document discusses modeling mission operations to reduce risk for NASA's Constellation Program. It begins with defining the goals of incorporating new technologies into operations while controlling risk and cost. It then discusses challenges like the need for increased automation and streamlined systems. The solution involved a collaboration between JSC and ARC to develop a simulation of shuttle operations using BRAHMS modeling tools. This prototype showed benefits like reducing time spent on mirroring tasks from over 5% to under 0.5% of a shift. The conclusions were that BRAHMS feasibility for automating complex MCC tasks was verified and could provide insights into processes while assessing risk.

1. OPERATIONS TECHNOLOGY :
RISK REDUCTION THROUGH
MODELING AND SIMULATION
OF MISSION OPERATIONS
Thomas E. Diegelman
Maarten Sierhuis
William Clancey
Chin Seah
NASA Johnson Space Center
Partnering with NASA Ames Research Center
March 26-28, 2007
Agent-Directed Simulation 2007

2. Talk Overview
• Big picture – the goals and rationale
• Defining the problem
• Evolving a solution – a brief history
• The first steps: small, deliberate, measurable
• How was it done?
• What were the results?
• Conclusions
2 2

3. We need to look at the operations “big picture”
to define:
•Goals of technology insertion in the operations of
the Constellation Program
•Rationale and measurement of the technology
insertion into the Constellation Program operations
Why?
•Because with out a clear, distinct path to risk and cost
control defined for Constellation, the program viability will be
called into question.
•Constellation Program is an opportunity for NASA to
incorporate into its operations tasks, the benefits derived
from NASA research and demonstrate the compatibility of
“cutting edge” technology with risk and cost management. 3
3

4. Challenges to Development of New Mission
Operations Concepts
“A government human spaceflight system must be designed to be cost
effective at the half-dozen or so flights per year that we can expect to
fly.”
Michael D. Griffin, “Human Space Exploration: The Next 50 Years”, March, 2007
• Automation is a keystone of the Constellation Program:
– Technology infusion program for NASA - first new NASA program in 30 years
– Opportunity for re-organization of functionality and allocation of operations:
– On-board
– Ground based
– Automated and distributed
• Expectation for Constellation is significant opportunity for change in
program structure from ISS or Shuttle:
– Reduction in processing of vehicle, data, etc., and attendant costs
– Streamlined flight management systems with increased, measurable robustness
– Measurable performance within the defined bounds of mission risk requirements
• Risk Management is a program priority above all other considerations:
– Controlled, bounded, and reduced mission risk, hence cost
4
– Measurable processes, with continual assessment, aided by available technology
4

5. Vehicle Based
Remote Based Operations
Earth Based Operations
Operations MARS
MARS GROUND
VEHICLE BASE
EXPERIMENT
ISS ROVER
FACILTY
MCC
KSC ISS FUEL
JSC EARTH
PRODUCTION
JPL FACILITY MOON
MSFC EARTH
GSFC Ames ISS JSC KSC
JPL MSFC
GSFC Ames MOON
Shuttle / ISS MARS
Control Center
JUPITER
Moon / Mars
Control Center
Planetary
Deep Space
A Potential MCC Operations Strategy for the
Constellation Program and Beyond 5 6

6. Relationship: Research and Operations
ARC JSC
Developed engineering approach
based upon modeling and simulation
in distributed system development
Collaborated with JSC / MOD on a
CDDF funded project as a proof of
concept
Developed a simulation for a
shuttle launch to docking to ISS for
flight control team
Generate statistics and metrics of
the current work practice
Built “proof of concept” for a
specific problem – OCA mirrored
LAN (OCAMS)
Results of OCAMS are currently in
the installation phase in the ISS
MCC
6

7. 7

8. It took 15 years to go from lab at
TRL 2 into full functionality at TRL 8:
- We must do technology transfer faster
- But not force it – that is elevates risk and won’t help cost metrics
No Modeling and Simulation Tools for
Mission Operations and Work Practice widely
in use in any industry today. 8
10

9. The first steps in this journey must be small steps:
•Affordable – able to explore several approaches
•Risk bounded – ideally decrease risk
•Verifiable by adaptation on ISS or shuttle
•Subject to evaluation – analogous to “Cooper-Harper” scale
The JSC / ARC challenge was to demonstrate a robust
and adaptable process tool set that provided an
incremental, evolutionary path from:
•CEV missions to ISS
•CEV / LSAM missions
•Humans and robotic Lunar Operations
•Human to Mars with robotic agents
After an operational assessment on shuttle or ISS
application, at least one approach would emerge
that could become a operations standard for 9
Constellation

10. THE POINT OF DEPARTURE: INTEGRATED OPERATIONS
Requirements
Risk And
Management? Evaluation?
• Simplicity – System complexity, required interfaces,
• Margin – Availability of performance, resources and environment
• Flexibility – Recon, data loads, DOLILU, etc.
• Robustness – Timely automated vehicle response, ability to utilize, etc.
• Situational Awareness – Telemetry, Caution & Warning capabilities, etc.
• Controllability – availability of necessary commands, control
techniques,scripting capabilities, etc.
How to
De-coupling
Who owns For
The Processes? Re-engineering?
10

11. Assessment and Metrics: Measuring Success
• Simplicity – System complexity, required interfaces,
• Margin – Availability of performance, resources and environment
• Flexibility – Recon, data loads, DOLILU, etc.
• Robustness – Timely automated vehicle response, ability to utilize, etc.
• Situational Awareness – Telemetry, Caution & Warning capabilities, etc.
• Controllability – availability of necessary commands, control
techniques,scripting capabilities, etc.
No
No
No
No
No
No
11

12. POTENTIAL FUTURE MISSION OPERATIONS
CONTINUOUS IMPROVEMENT / WORK EVOLUTION FOR EFFECTIVENESS THROUGH
DECISION SUPPORT PROCESS FOR OPERATIONS ASSESSMENT
How might you
EXPLORATION
No
organize and
MISSION work be more
effectively or
CONCEPT efficiently?
BRAHMS MODEL
“C-H” Scale
EXPEDITION EXPEDITION EXPEDITION
EXPLORATION
REQUIREMENTS TRAINING EXECUTION MISSION
& COMPLETION
PLANNING
“Cooper-Harper” Scale
Safety of
flight
No
Key
Program
Expedition / Flight
12
New / proposed

13. Analysis Mission: Shuttle Launch to Rendezvous
and Docking with ISS
OMS 2 @ Approx Rendezvous with ISS at
Ascent – 8:30 OMS 1 + 40:00 approx 48:00:00 MET
Cargo Bay Doors open and
Active Thermal Control
OMS 1 @
MECO + 2:00
Ground Ascent Orbit Maneuver Prox Ops
13

14. Constellation Mission:
CEV Launch to Rendezvous and Docking with ISS
Ground Ascent Orbit Maneuver Prox Ops
14

15. The OCA System: The Components
• People & Organizations
– Computer Systems
– Communication Media
– Space Comm Network
• Geographic Distribution
• Regulations
• Work practices & protocols
15

16. Problem: OCA Console
Operations
And, oh by the way…log everything you do!!!
And, oh by the way…log everything you do!!!
OCA
MAS Servers (KFX)
Laptop
Ops LAN (ISS)
MAS OCA
PC PC Mirror LAN
Laptop
OCA Console
Mirror LAN 16
(MCC)

17. Solution: OCAMS – OCA Mirroring
System
OCA
MAS Servers (KFX)
Laptop
Ops LAN (ISS)
MAS OCA
PC Mirror LAN
PC
Laptop
OCAMS - OCA
Mirroring System
OCA Console
During STS flight #118, files manually transferred:
During STS flight #118, files manually transferred:
Uplinked = 2,513 files or 268 MB
Uplinked = 2,513 files or 268 MB
Downlinked = 8,411 files or 29.4 GB
Downlinked = 8,411 files or 29.4 GB
Mirror LAN 17
(MCC)

18. Approach: Simulation to
Implementation Workflow
Tool
Work
System
Current Ops Design
Simulation Future Ops
Simulation
Metrics
& Data
Observation Implementation
Operations
18

19. Future Ops Simulation:
OCAMS Prototype Tool
OCA MAS PC Word
Outlook OCA CA Handover Log
CA
Messages
- Personal
Agent NB: Future Ops
CA Model running on
CA a single laptop was
Excel
OCA Officer
delivered October
Mirror Log
Agent ‘07
LEGEND:
KFX Machine = Brahms Agent
CA =
Communication
Agent (Java)
Mirroring Text
CA
KFX Log =
External System
or Document
= Simulated File
Folders & Files
System
To/From ISS
/ Mirroring
Staging
Machine
FTP
MirrorLAN
CA
Monitoring
MirrorLAN 19
Folders & Files Staging
Folders & Files

20. MODAT UML
Model Development
20

21. Current Ops: A Full Day
Simulation
Orbit 1 Shift
OCA officer arrives
arrives at JSC home
Orbit 2 Shift
21
Orbit 3 Shift

22. Statistics: Manual (current) vs.
Automated (future) OCA
Mirroring
Checking
Verifying 25%
24%
Communicating
10%
Moving
Deleting
35% Configuring 3%
Resource
3%
Future Operations (with OCAMS):
Mirroring Activities
≈ < .5% shift time
Current Operations:
Mirroring Activities
≈ > 5% shift time 22

23. Optimal Machine H/W Needs
2.0 GHz CPU
2 GB RAM
200+ MB Disk Space for OCAMS software load OCA MAS Client PF1 Server
10 GB Disk Space for mirrored files + logs
-- OCAMS (Brahms &
Video: SXGA 1280x1024 or WSXGA 1680x1050 Derby & Java v5) File Copy/Move/Delete
Network: 100Mb -- FTP Server
-- E-mail Client
-- Windows XP Prof.
-- MS Word/Excel 2003
Mirror LAN
OCA Machine N … Agent IIOP/TCP/IP Com.
OCA Machine 1 File FTP -Allow Virtual Drive
Mapping from
- - - OCAMS (Brahms &
OCAMS Mirroring Staging
(Brahms & Java) v5)
Derby & Java Machine
File FTP
- FTP Server
-- KFX software Agent IIOP/TCP/IP Com. (R/W ability)
-- Windows XP Prof.
OR
New Network Connections
File Copy/Move/Delete
- KFX Log -Mirrored
files
-Up/Down
Files
Agent IIOPTCP/IP Com.
Machines Need File Copy/Move/Delete
File FTP.
to be upgraded
-- OCAMS (Brahms &
Derby & Java v5)
- FTP-ed - FTP Server (Secure)
files to
be mirrored -- Vitrual Drives to Mirror LAN
-- Windows XP Prof.
Mirroring Staging Machine 23
New Machine
(new machine)
That is Needed

24. Conclusions
• Feasibility of the BRAHMS modeling tool technology for automation of
complex tasks found in MCC with acceptable risk and measurable
attributes is verified.
• Results showed:
• Automation of processes analyzed by BRAHMS / MODAT feasible
and can provide excellent insight into intricate team dynamics
• BRAHMS provided insightful assessment of “time utilized” in OCA
• Brahms Modeling system performed very well modeling the complexity of
the OCA tasks:
• Orbiter Communications Adapter (OCA) is being completed by
early 2008 for testing and verification of model.
• OCA model evaluation will be completed by mid 2008.
• MODAT / Brahms team is poised to take Brahms to the next level –
implement an enhanced BRAHMS tool set that would enable wider
application modeling, with less training required for the modeler.
• Post tool upgrade, BRAHMSwould be available for commercialization and
as a as a transferable technology to risk sensitive operations in industry.
24