OPERATIONS TECHNOLOGY :RISK REDUCTION THROUGH MODELING AND SIMULATION OF MISSION OPERATIONS

Thomas E. Diegelman Maarten SierhuisWilliam Clancey

Chin Seah

NASA Johnson Space CenterPartnering with NASA Ames Research Center

Agent-Directed Simulation 2007March 26-28, 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

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

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– Measurable processes, with continual assessment, aided by available technology

4

5A Potential MCC Operations Strategy for the

Constellation Program and Beyond

MCC

Shuttle / ISSControl Center

Earth Based Operations

Remote Based Operations

Moon / MarsControl Center

Vehicle Based Operations

PlanetaryDeep Space

EARTH MOON

MARS

JUPITER

6

JSC

JPL

GSFC Ames

ISSKSC

ISS

MSFC

JSC

JPL

GSFC Ames

MSFC

KSC

EARTH

GROUNDBASE

ROVER

FUEL PRODUCTION

FACILITY

MARS

MARSVEHICLE

EXPERIMENTFACILTY

MOON

ISS

6

ARC

Relationship: Research and Operations

JSC

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

Developed engineering approach based upon modeling and simulation in distributed system development

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

7

8

No Modeling and Simulation Tools for Mission Operations and Work Practice widely in use in any industry today.

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

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 Constellation

10

Who ownsThe Processes?

How toDe-coupling

For Re-engineering?

THE POINT OF DEPARTURE: INTEGRATED OPERATIONS

RiskManagement?

RequirementsAnd

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.

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.

NoNo

No

No

No

No

12

EXPEDITION REQUIREMENTS

&PLANNING

EXPEDITION TRAINING

EXPEDITION EXECUTION

EXPLORATIONMISSION

COMPLETION

EXPLORATIONMISSIONCONCEPT

POTENTIAL FUTURE MISSION OPERATIONSCONTINUOUS IMPROVEMENT / WORK EVOLUTION FOR EFFECTIVENESS THROUGH

DECISION SUPPORT PROCESS FOR OPERATIONS ASSESSMENT

KeyProgramExpedition / FlightNew / proposed

No

“C-H” ScaleBRAHMS MODEL

No

“Cooper-Harper” Scale Safety offlight

How might you organize and work be more effectively or efficiently?

13

Analysis Mission: Shuttle Launch to Rendezvous and Docking with ISS

Prox OpsOrbit ManeuverAscentGround

Ascent – 8:30

OMS 1 @ MECO + 2:00

OMS 2 @ Approx OMS 1 + 40:00

Cargo Bay Doors open and Active Thermal Control

Rendezvous with ISS at approx 48:00:00 MET

14Prox OpsOrbit ManeuverAscentGround

Constellation Mission: CEV Launch to Rendezvous and Docking with ISS

15

The OCA System: The Components

• People & Organizations– Computer Systems– Communication Media– Space Comm Network

• Geographic Distribution• Regulations• Work practices & protocols

16

Problem: OCA Console Operations

MAS Servers

Mirror LAN (MCC)

Ops LAN (ISS)MAS PC

OCAPC Mirror LAN

Laptop

OCA (KFX) Laptop

OCA Console

And, oh by the way…log everything you do!!!And, oh by the way…log everything you do!!!

17

Solution: OCAMS – OCA Mirroring System

MAS Servers

Mirror LAN (MCC)

Ops LAN (ISS)MAS PC

OCAPC Mirror LAN

Laptop

OCA (KFX) Laptop

OCA Console

OCAMS OCAMS -- OCA OCA Mirroring SystemMirroring System

During STS flight #118, files manually transferred: Uplinked = 2,513 files or 268 MB

Downlinked = 8,411 files or 29.4 GB

During STS flight #118, files manually transferred: Uplinked = 2,513 files or 268 MB

Downlinked = 8,411 files or 29.4 GB

18

Approach: Simulation to Implementation

Implementation

Future OpsFuture OpsSimulationSimulation

Metrics& Data

Current OpsSimulation

WorkSystemDesign

WorkflowTool

Observation

Operations

19

Future Ops Simulation:OCAMS Prototype Tool

LEGEND:

CA

= Brahms Agent

= CommunicationAgent (Java)

= External Systemor Document

= Simulated FileSystem

OCA MAS PC

KFX Machine

MirroringStagingMachine

KFX LogCA

/

StagingFolders & Files

CA

CA

Mirror LogOCA OfficerAgent

CA

CA

CAHandover Log

-MessagesOCA

PersonalAgent

Mirroring

Monitoring

Word

Excel

Outlook

FTP

Text

Folders & FilesTo/From ISS

NB: Future Ops Model running on a single laptop was delivered October ‘07

MirrorLAN Folders & Files

MirrorLAN

20

MODAT UML

Model Development

21

Current Ops: A Full Day SimulationOrbit 1 Shift

Orbit 2 Shift

Orbit 3 Shift

OCA officer arrives at JSC

arrives home

22

Statistics: Manual (current) vs. Automated (future) OCA

Mirroring

Current Operations:Mirroring Activities≈ > 5% shift time

Future Operations (with OCAMS):Mirroring Activities≈ < .5% shift time

Checking25%

Communicating10%

ConfiguringResource

3%

Deleting3%

Moving35%

Verifying24%

23

OCA Machine N …

- - OCAMS (Brahms & Java)

- FTP Server

OCA MAS Client

-- OCAMS (Brahms & Derby & Java v5)

-- E-mail Client

-- Windows XP Prof.

-- MS Word/Excel 2003

OCA Machine 1- OCAMS (Brahms &

Derby & Java v5)

-- KFX software

-- Windows XP Prof.

Mirroring Staging Machine (new machine)

-- OCAMS (Brahms & Derby & Java v5)

- FTP Server (Secure)

-- Vitrual Drives to Mirror LAN

-- Windows XP Prof.

Mirror LAN

-Allow Virtual Drive Mapping from

Mirroring Staging Machine

(R/W ability)

- KFX Log

-Up/Down Files

- FTP-ed files to be mirrored

-Mirroredfiles

Optimal Machine H/W Needs2.0 GHz CPU2 GB RAM200+ MB Disk Space for OCAMS software load10 GB Disk Space for mirrored files + logsVideo: SXGA 1280x1024 or WSXGA 1680x1050Network: 100Mb

Agent IIOP/TCP/IP Com.

Agent IIOP/TCP/IP Com.

Agent IIOPTCP/IP Com.File FTP.

PF1 Server

-- FTP Server

File FTP

File FTP

File Copy/Move/Delete

File Copy/Move/Delete

OR

File Copy/Move/Delete

Machines Need to be upgraded

New Machine That is Needed

New Network Connections

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.