nasa planning for orion multi-purposecrew vehicle ground

-----------------------------

NASA Planning for Orion Multi-Purpose Crew VehicleGround Operations

Gary Letchworth Roland SchlierfNASA NASALX-Ol LX-Ol

Kennedy Space Center, FL 32899 Kennedy Space Center, FL 32899321-867-1215 321-867-5827

[email protected] [email protected]

Abstract-The NASA Orion Ground Processing Team wasoriginally formed by the Kennedy Space Center (KSC)Constellation (Cx) Project Office's Orion Division to define,refine and mature pre-launch and post-landing groundoperations for the Orion human spacecraft. The multidisciplined KSC Orion team consisted of KSC civil servant,SAIC, Productivity Apex, Inc. and Boeing-CAPPS engineers,project managers and safety engineers, as well as engineersfrom Constellation's Orion Project and Lockheed MartinOrion Prime contractor.

The team evaluated the Orion design configurations as thespacecraft concept matured between Systems Design Review(SDR), Systems Requirement Review (SRR) and PreliminaryDesign Review (PDR). The team functionally decomposed prelaunch and post-landing steps at three levels' of detail, or tiers,beginning with functional flow block diagrams (FFBDs). Thethird tier FFBDs were used to build logic networks andnominal timelines. Orion ground support equipment (GSE)was identified and mapped to each step. This information wassubsequently used in developing lower level operations steps ina Ground Operations Planning Document PDR product.

Subject matter experts for each spacecraft and GSE subsystemwere used to define 5th

- 95 th percentile processing times foreach FFBD step, using the Delphi Method. Discrete eventsimulations used this information and the logic network toprovide processing timeline confidence intervals for launchrate assessments.

The team also used the capabilities of the KSC VisualizationLab, the FFBDs and knowledge of the spacecraft, GSE andfacilities to build visualizations of Orion pre-launch and postlanding processing at KSC. Visualizations were a powerful toolfor communicating planned operations within the KSCcommunity (i.e., Ground Systems design team), and externallyto the Orion Project, Lockheed Martin spacecraft designersand other Constellation Program stakeholders during the SRRto PDR timeframe. Other operations planning tools includedKaizen/Lean events, mockups and human factors analysis.

The majority of products developed by this team areapplicable as KSC prepares 21 st Century Ground Systems forthe Orion Multi-Purpose Crew Vehicle and Space LaunchSystem.

TABLE OF CONTENTS

1.0 INTRODUCTION ••••••••••••••••.•••••••••••••••••••••••••••••• 12.0 CONSTELLATION ARES I/ORION/GROUND

OPS ELEMENTS 2U.S. Government work not protected by U.S. copyright

3.0 ORION GROUND OPERATIONS FLOW 34.0 ORION OPERATIONS PLANNING PROCESS

AND TOOLSET OVERVIEW 34.1 CONCEPT OF OPERATIONS .44.2 ORION PROCESS VISUALIZATION .44.3 FUNCTIONAL FLOW BLOCK DIAGRAMS .44.4 OPERATIONS TIMELINE DEVELOPMENT 54.5 DISCRETE EVENT SIMULATION (DES)

MODELING 64.6 GROUND OPERATIONS PLANNING

DOCUMENT DATABASE (GOPDB) 65.0 OPERABILITY IMPROVEMENTS USING

OPERATIONS PLANNING TOOLS 85.1 KAIZEN/LEAN EVENTS 95.2 MOCKUPS 95.3 HUMAN FACTORS ANALYSIS 105.4 ACTIVE TRACKING OF FLIGHT/GROUND

ISSUES 106.0. SUMMARY AND FORWARD PLAN 11REFERENCES 11BIOGRAPHIES 11

1.0 INTRODUCTION

This paper provides an overview of the Constellation AresVOrion/Ground Operations Elements and the Orion groundoperations flow. The Orion ground operations planningprocess is described including six tools the GroundOperatiuns team utilized during the planning process.These tools included concept of operations, functional flowblock diagramming, timelines, modeling, and the use of adatabase to identify and manage tasks and related resourcessuch as ground support equipment, safety hazards,personnel, and supporting systems. In order to maximizeoperability, Kaizen/Lean events, mockups, human factorsanalysis, and a watch list of operability issues were alsoutilized. The infusion of operability into the Orion flight andground designs using the processes and tools described inthis paper enabled the Orion flight and ground concepts anddesigns to move forward as NASA transitions to the threenew Exploration Systems Directorate ProgramsMPCV/Orion, Space Launch System (SLS), and 21 5t

Century Ground Systems that will launch astronauts tobeyond low earth orbit in the coming years.

2.0 CONSTELLATION ARES I10RION/GROUND

OPS ELEMENTS

This section provides a general description of KSC GroundOperations in support of the Constellation Program,including pre-launch preparations, landing, and retrieval.Figure I illustrates the conceptual flow of the Ares I/Orionthrough the Ground Systems. The Constellation GroundSystem includes the facilities, facility systems, GroundSupport Equipment, hardware, and software required toperform Ground Operations for spacecraft pre-launchprocessing, launch, landing, retrieval, and refurbishing atsites in support of the Constellation Program. The officialconfiguration for the Ground System is captured in CxP72197, Ground Systems Architecture Description Document(ADD). The Ground Systems Architecture for theConstellation Program is based on a clean pad concept. Inthis concept, the Launch Vehicle (LV) and SpacecraftSystems are processed in offline facilities in order to beoutside of the integrated vehicle critical path and thentransported to the Vehicle Assembly Building (VAB) forintegration and test. Some elements and systems, such asthe launch vehicle upper stage, are delivered to the launchsite ready for integration and thus taken directly to the VAB.In the VAB, the integrated stack is assembled vertically atopa mobile platform. Once the vehicle has been completelyintegrated and checked-out on the ML, the ML and AresI/Orion vehicle are moved to the Launch Pad at which final

cryogenic propellant servicing, launch countdown, andlaunch are performed.

NASA Roles and Responsibilities for Ground Operations

a. Providing government oversight and integration of theground processing contracts.b. Ensuring that appropriate Ground Operationsrequirements are attained before proceeding to the nextprocessing milestone.c. Performing project management, baseline managementand control, data management, budgeting, and scheduling.Responsibility also includes ensuring that contractors adhereto budgets and schedules.d. Planning and executing hands-on operations, as required(for example, cargo processing).e. Evaluating proposed changes to baselined groundoperations and providing impacts as required.f. Implementation of approved changes to ground operationsbaseline.

Kennedy Space Center Responsibilities for GroundOperations

a. Orion processing within the Multi-Payload ProcessingFacility (MPPF), VAB, Launch Complex (LC), and landingsites.b. Launch Abort System (LAS) integration with Orionwithin the VABc. Launch Vehicle processing within the Assembly andRefurbishment Facility (ARF); Rotation, Processing andSurge Facility (RPSF); VAB; Hangar AF; and ParachuteRefurbishment Facility (PRF).

u.s. Figure 1 - Ares I/Orion Conceptual Ground Systems Flow2

See reference [1] Ground Operations Planning Document:Volume 3: Operations; Document Number: CXP 72149-03for more details on KSC ground operations planning.

3.0 ORION GROUND OPERATIONS FLOW

Crew Module (CM)/Service Module (SM) IntegratedGround Processing

CM/SM ground processing includes:• Acceptance of an integrated CM/SM, transportation to

the MPPF• Portable Equipment, Payloads, and Cargo (PEPC)

Integration• CElT (Crew Equipment Interface Test)• Powered PEPC (Cargol FCE) to Orion Interface

Verification Tests• Un-powered Non-Time Critical PEPC (Cargo I FCE)

Installation• High pressure gas servicing (G02, GN2, GHe)• Ammonia servicing (NH3)• Propellant servicing (N204, MMH, N2H4)• Closeouts.

Orion/Launch Vehicle Integrated Stack Processing

Orion/Launch Vehicle Integrated Stack processing includesintegration of the Orion to the Launch Vehicle, interfacetesting, integrated testing, and preparation of the integratedstack for Launch. Lift and mechanical mate with the upperstage Instrumentation Unit (IV) is performed. This includeselectrical mates, T-O connections, and purge initiation. Thethe Launch Abort System (LAS) is lifted and mechanicallymated to the CM. LAS to CM electrical mates areperformed. LAS Interface Test & S&A rotation test(powered) can be performed at this time or after integrationis complete. Ordnance mates are also completed. Once theLAS has been integrated to the CM, the four Ogive panelsare installed, TPS is closed out, and internal white roomaccess is established. After access has been established, fullvehicle integrated testing is performed with a vehicle powerup and health status, Interface Verification Test (includingRF testing) and Countdown Demo Test (CDDT). A potablewater sample is also taken at this time.

Pad and Launch Ops

After rollout from the VAB and connections at the Pad areestablished, Orion communications testing begins. Orionpower-up and Pad IVT is performed along withcommunication system End-to-End testing. The LASantennas are used at this point. Late stowage, ordnanceoperations, and LAS arm inhibit removals (S&A pins) areperformed. Just prior to launch, crew ingress is performedalong with hatch seal leak checks, cabin leak checks, whiteroom seal retraction, and Crew Access Arm ( CAA)retraction. Final countdown and launch is then performed.

U.S. Government work not protected by U.S. copyright

3

Landing and Recovery

During descent updated landing coordinates are transmittedfrom Mission Control Center (MCC) at the Johnson SpaceCenter (JSC) to the pre-staged recovery crew. Auto-safingof pyros & fluid systems are performed. A CM beacontransmits the location to the recovery crew. The CM isremoved from the water with the crew on board. Crewegress is after the CM is secured on a well-deck ship. Thepyrotechnics are manually safed and time critical PEPC isremoved on the ship. Data retrieval may also be performedas early as on the ship if required. Data retrieval may alsobe performed at the port or at the deservicing location if nottime critical. Upon arrival at the port, the CM is transferredto the dock and prepared for transportation back to KSC.The CM is then transported to the MPPF for deservicing.

CM Deservicing

Upon arrival at the MPPF, deservicing preparations aremade. The CM is cleaned and moved into the MPPFdeservicing stand. Once in the stand, the seats, and nontime critical PEPC are removed. Data retrieval is performedand deservicing is initiated. Deservicing includes thepropulsion system, ammonia system, and high pressuregases that were servicing pre-flight. After the deservicing iscompleted, the CM is moved from the deservicing stand,configured for transport, and transported along withremoved components to the O&C. A transfer of the CMand components from NASA back to Lockheed Martin(LM) is performed at this time and LM dispositions itemsfor re-flight or disposal.

4.0 ORION OPERATIONS PLANNING PROCESS

AND TOOLSET OVERVIEW

The primary objective of the Orion ground operationsplanning process was to optimize the "operations design" inconjunction with the flight and ground systems designs. Inorder to achieve this, high level operational concepts weredeveloped during initial Program Formulation usingconceptual models, deterministic timelines, and historicalcomparisons.

As the Program matured, task level operational concepts,detailed FFBDs, and off nominal events were defmed usingsubsystem/task level modeling and design-informedprobabilistic simulations. Many of these Orion groundprocessing products will carry over to the new 21 st CenturyGround Systems Program with some modifications toaccommodate any new requirements. As the Orion Programand new 21 sl Century Ground Systems Program progressforward to Initial Operational Capability (IOC), the moredetailed operations requirements, procedures, LaunchCommit Criteria (LCC), and detailed mission schedules will

4.1 CONCEPT OF OPERATIONS

4.2 ORION PROCESS VISUALIZATION

Cx Ground Ops Project required tools to collect, assess, andconcisely communicate all of the Orion ground operationssteps including servicing, integration, landing and recoveryand de-servicing. One simple but effective tool wasfunctional decomposition, using Functional Flow BlockDiagrams (FFBDs), prepared with participation throughoutthe organization at KSC and JSC. Orion Ground Operationsproject led the FFBD effort and maintained theconfiguration control of the product. The first FFBD wasdeveloped in 2006 and updated on a regular basis dependingon significant changes to the vehicle or ground systems.The use of FFBDs is a standardized practice per NASASystems Engineering Handbook NASAlSP-2007-6105. TheFFBD will continue to be updated periodically because itprovides the simplest method of developing andcommunicating Orion operational tasks among differentproject and engineering organizations. It is a time basedsequencing of the Orion ground operations flow in oneproduct and enables functional decomposition of tasks asthe flight and ground designs evolve and the relatedoperations are better understood. The FFBD was also usedto develop multiple/ lower level GOP products such as thenominal timelines, derived requirements, the Orion portionof Ground Operations Planning Document (GOPD), and theOrion portion of the Ground Operations Timeline AnalysisReport integrated timeline. The FFBD and timelines werealso used as input to Orion Ground Ops discrete eventsimulations, visualization tools and to resource planningefforts for future O&M.

FFBD Lessons Learned

4.3 FUNCTIONAL FLow BLOCK DIAGRAMS

The Ground Ops Project team leveraged powerfulvisualization capabilities to plan operations at KSC. Theteam utilized Pro E and Catia models of spacecraft, GSE,facilities and personnel from spacecraft flight hardwaredesigners and ground systems designers. The visualizationteam imported the models into Delmia to enable operationsand systems design interaction in a virtual realityenvironment. This capability was used many times toinfluence the design process, and make flight and groundsystems more operable. The visualizations of the spacecraftoperations in facilities (i.e., VAB platforms, launch abortsystem assembly, spacecraft servicing in MPPF) were alsopowerful communications tools for engineeringdevelopment and milestone reviews such as GOP PDR.

To VAll...

...AIllIllOni>Son'JcIrlJ.NH3...Hit" ,.,....ure Ga. semcq

-002. GN2. GHe.

b. A framework within which system design andimplementation alternatives can be evaluated

a. An operational context for the development of technicalrequirements

c. Reference data for evaluating the completeness of thetechnical requirements

d. A mechanism to communicate long term goals and nearterm plans in context to support lower level design trades.

A sample Concept of Operations spacecraft flow subsectionis shown in Figure 2.

be produced usmg yet to be developed certifiedrequirements verification models and operationscontractor/government partnered manifest assessments.

The Concept of Operations formed the basis for groundoperations planning by describing the Ground Systemarchitecture in an operational context. It provided acommon understanding of ground operations and thesupporting infrastructure to all relevant Government andcommercial stakeholders. This included characteristics ofthe ground system, interfaces between the ground systemand other projects, nominal and contingency operationalscenarios, and system performance expectations. Theconcept of operations is not intended to provide specificimplementation constraints to Ground System designers, assystem design and operational requirements are levied onlythrough technical requirements documents. Rather, theconcept of operations is part of the overall architecturedefmition which facilitates the development of technicalrequirements documents by providing:

Figure 2 - Sample Concept of Operations (Spacecraft) I) Decide on level of detail up front2) Decide on ground rules on what's in and out3) Keep the level of detail at the functional level4) Keep it simple5) Establish some type of configuration control


4

4.4 OPERATIONS TIMELINE DEVELOPMENT

Subsystems level ground processing expertise from Shuttleand ISS were used to estimate timeline durations andresource loading for Orion and the new Program. TheDelphi method was used to develop durations based onmultiple experts per subsystem. The timelines were thenused to develop preliminary schedules. The schedulesadded learning curve, work shifting and special testing.Integrated operations at the VAB and Pad, and hazardousoperations at the MPPF, were based on five days/three shiftsper week and the remaining offline operations are based onfive days/two shifts per week. The learning curve wasbased on ISS, Shuttle and Apollo historical data. This dataset indicated that up to four times the estimated nominalsteady state may be required to prepare for the first flight,and that the timeline duration could be reduced with eachsubsequent flight, until full learning was accomplished afterthe third flight.

;;;s:,-:=.::.r"_._._>1.

"...,.,...CCClCS'froCSOSCl'

Figure 5 - FFBD Tier 3 Example

_.~fionecm:1Ji.~""bei'ls1alecl'....-Examples

Figure 3 - Tier 1 Orion Ground Ops Functional Flow

6) Keep a reference version for the community to use (i.e.GOPD) and develop working versions for continualupdate and refmement as needed

7) Get the larger community involved early (Safety,Engineering, Operations, Logistics, Institution, etc.)

8) Use an application that everyone can use. Our teamused MS Powerpoint.

9) Expect numerous changes.

Our team began with a very high level Tier 1 FFBD (Figure3). As the operations became more understood, Tier 2 andTier 3 levels were developed (Figures 4 and 5). For ourteam, the next level was the GOPD and the actual detailedprocedures. The Constellation Program (CXP) did not reachthe detailed procedure level before the program wascanceled. Many of our FFBD and GOPD details willdirectly apply to the new Exploration Orion groundoperations FFBD and GOPD. Procedure level details willevolve from these in the future.

Ground Operations Timeline Analysis Report (GOTAR)

"'-IJO....Md_--

Figure 4 - FFBD Tier 2 Example

The purpose of the GOTAR was to demonstrate the progressmade by the Ares/Orion!GO Projects towards meeting theProgram requirements. One requirement was to conductground operations for a single Ares VOrion mission within athreshold critical path timeline of 879 hours. FromGOTAR 1 to GOTAR 12 this time was reduced from 920hours to 867 hours. Another requirement was to achieve a45 calendar day launch interval once the Orion!Ares Isystem enters steady-state operations. The report providedthe current assessment status of, and recommendedimprovements for, the overall ground operationsresponsiveness of the Orion!Ares I system. In order toaccomplish this, the report officially documented theallocation of the 45 calendar day requirement into sequentialsegments. These segments were defmed in serial workhours as follows:

1. Mobile Launcher (ML-1) Refurbishment2. Mobile Launcher (ML-1) Preps in VAB High Bay 3


5

3. First Stage Stacking on Mobile Launcher (ML-l)4. Upper Stage Stacking5. Orion CEV/LAS Installation6. Orion/Ares I Integrated Test and Closeouts7. Orion/Ares I Pad Operations

The work described above was to be accomplished within45 calendar days, inclusive of any contingency timeaccounting for: holidays, weekends, shift differentials,accumulation of unplanned work, and other variances.

The GOTAR report was an integrated source of detailedtimeline allocations that provided more detailed Level IIIproject information to guide the Level III Projects. Inaddition, the report provided timeline assessments againstthe currently known state of the flight and ground systemdesigns, as well as quantifying timeline margin (deltas)between the assessments and the allocations. The GOTARalso provided recommendations for closing the gap betweenthe assessment and the allocated requirements.

at the level of detail required to provide the answer, and tocomplete the DES analysis in time to be useful. The inputanalysis sources were Shuttle historical data, expert opinion,CxP documentation, and literature reviews. The Output Fileand output analysis products were designed to matchrequested analysis. DES analysis was performed for groundoperations needs as follows:• Maximum flight rate analysis for integrated operations

at the Vehicle Assembly Building (VAB), MobileLauncher, Pad, and for Orion offline operations at theMPPF

• Transporter study• VAB Highbay selection study• 90-Minute Launch separation study• Probability of Meeting Planned Milestones Study• Launch Probabilities and Launch Distributions for

Preliminary Design Review (PDR)• Hypergolic scrubber study.

Example

4.6 GROUND OPERATIONS PLANNING

DOCUMENT DATABASE (GOPDB)

The GOTAR example, shown in Figure 6, shows 7 daywork week shifting would meet the 45 day requirement andthat from September 2009 to January 2010 the integratedteam leaned out 2 Y2 days of additional efficiency in theintegrated timeline.

0.0 t----l..._.J-~--.L-.L-__.__--.L-.L-___4

60.0,.-------- ___.

GOPD

The GOPD (example shown in Figure 7) provides groundoperations planning information to ground systemsdevelopers, flight system developers, ground operators andthe KSC institution. It also provides lower-level operationsconcepts supporting ground system/subsystem development.Ground operators are provided with a framework foroperational procedure development, requirementsassessment, and workforce/budget planning. Also, theinstitution is informed of the capabilities and servicesrequired to support ground processing. Details managedwithin the GOPD are information such as tasks, related highlevel work steps, hazardous operations, requiredsubsystems, required support services, required GSE, andtimelines.

Example

--Goa'

_S.dllywork.....

--+- Trendlne

TotIlWoJk

Do"

-l-dlVWOl'1<....._6·dlywork.....

•.1

GOTAA-121115'10

• .1

GOTAR-l111106'09

31.1

GOTAA-l009103109

30.0

10.0·

Figure 6 - GOTAR Example

~O.O

20.0

50.0

4.5 DISCRETE EVENT SIMULATION (DES)

MODELING

Discrete Event Simulation (DES) is a computer-basedmodeling technique for complex and dynamic systemswhere the state of the system changes at discrete points intime and whose inputs may include random variables. Therelated planning products used in our DES efforts included,integrated timelines, FFBDs, manifest scenarios, and projectdirected assumptions. The modeling guidelines were tomodel at the level of detail for which there is data, to model


6

--.........~1•.,.o-.-.or,o_~o--""'-J~

------------------------

GOPDb

U.1.6 O_-'_(CMfS.'lfS'l~A<nn...S.rrim>

AclNityT.,.: N.w\"

_....a.~~rs for riM .:..,.,.01 .... vehicN.,.. prowid.c 11'14 • td.., dw Orion

Pt.jettprier"U-fw~l"i.tMD0250..

.. Est:at.ilt'l&-dantled*,ttwn,tatfonft.tothe .YeMr,..,Qnrc::e~_ -:fI~

.....-•. Muh-e:a1, HwIcIIi"l MNI Aa:au-(;Sf

'-1. MoftJlcM-w an4 SC'CIIf'R ut:tm pt..ttorms Il"OUM st.rt Stxk. ~eorify~ p;p

dCWMCZ"'." fromShonSitadl'sOMLOSKAIftUirftJ,l:fft ""'p,il:lliKhu.1. f_eic,. 0ItjK1 Debris (fOD) caw." apqIU for plMfomtll'" dose proaimity to f'f:ch1:

ft'

Figure 7 - GOPD Example.

The GOPDb is a custom web application that facilitatescollaborative development of the GOPD. The GOPDbprovides user-friendly data entry, review, approval andreporting of the GOPD task listings, resource listings, andnominal timelines. The GOPDb reduces costs anddevelopment time through real-time data integration, datagovernance, access control, and revision tracking of groundoperations planning data. The use of the GOPDb eliminatedthe use of a separate application for capturing the concept ofoperations (ConOps) for ground operations planningdocuments and associated timelines.

GOPDb Enhancements

Recent GOPDb enhancements allow the smarter use ofcomputing resources for data processing by utilizing bothclient-side and server-side resources. This greatly reducedthe amount of IT hardware needed to host the applicationand provided greater flexibility in deploying the application.It now supports 200 concurrent users. Since GOPDb usesweb-based software, no additional software installations arerequired. The system uses a RIA (Rich InternetApplication) interface (Figure 8), which removes allbrowser incompatibilities. The GOPDb also provides realtime custom reporting with output to a variety of formatsincluding Word, PDF, HTML and Microsoft Project XMLformat. The GOPDb allows comparison of two versions of adocument side-by-side highlighting the difference betweendocuments. This "versions" capability allows for "what-if'operational scenarios to be developed, reviewed, and

SldMat' tw... 10...... · ..........1.1 · .."

I 4.1.1.1 · .."I 4.J.J 2 · 'All

1.&.1.l.3 · .6.414.........]: · .....I 4.142..J · .. ,GI 4.1...2:.2 • """1 "L2J · 'All

....... 1.:1 · ....• 4.llJ · ""20I 4.t.l.2 · ""2l

•launch Abort S~tan llslent;lly, Inteq;lbon. "nil T~t'9fln(lll"

Lilunch Abort 5)"1tcm ~ce"ng om In~):Ir'tbv VC!ndor(5~one)

UUfKh Abort Sonten A5Se.II'CIY.I"t~bon .Jnd felt In Qna.il!r~ban~.ty ('St"olnd31ontJ

l3undt Abort S,.stan TO'oflIe.r Tr

~ sw.'ko:s Notel T,.,klng

~Iuo

--- t

Figure 8 - Example of GOPDb Enhanced Screen Shot with Timeline and Related GOPD Data Fields


7

compared to the baseline operational scenarios.

5.0 OPERABILITY IMPROVEMENTS USING

OPERATIONS PLANNING TOOLS

Operability, in general, can be thought of as the extent towhich the maximum mission objectives can be achieved atthe lowest cost over the program lifecycle. Often, improvingoperability means optimizing several competing figures ofmerit. Operability figures of merit specific to GroundOperations include the following:

1) Improvement of safety to personnel and/orhardware

2) Maximization of throughput or flexibility to meetdynamic manifest needs, and minimization ofprocessing critical path

3) Minimization of facility/industrial "footprint"required to support operations

4) Maximization of capability to launch on time5) Minimization of touch labor.

Some examples of Orion ground operability successes thatwere achieved, by teamwork between the Cx Orion andGround Operations Projects, are identified in Figure 9:

A) The Orion design was changed to add an integratedlift capability. With this capability contingency

G. SM Fairing removal capabilitywithout de-lntagratlon of tha CM

H. Aras/Orlon SAnU IntartacaExterior (versualnternal) mating of fastenersThermal closeout with preformad materialAlignment cues for stacking

destacking will be much faster as an Orionintegrated vehicle compared to de-integration andintegration in the critical path with multiple cranelifts.

B) One piece ogive lift capability allows the complexintegration of the four ogive pieces to be performedoffline out of the integrated vehicle critical path.Contingency de-integration is also much fasterwith less chance for hardware damage

C) With the elimination of full vehicle power up forpost flight de-servicing, the operation is muchquicker and less GSE and personnel are requiredfor this task

D) With the Composite Overwrap Pressurized Vessel(COPV) design updated to meet the 100 dayrequirement before depressurization, integratedcontingency schedules became more realistic.Without this capability, contingency operationswould have become increasingly difficult toaccomplish.

Additional significant operability successes were alsoachieved in: E) propulsion systems; F) Pyrotechnics,T-O interfaces, and servicing panels; G) SM Fairingremoval capabilities; and H) Launch Vehicle to Orioninterfaces.

C. Elimination of fullVehicle Power-up forPost..fllght Deservlclng

D. Orion COPVs now meet CARD 100day requirement withoutdaprassurlzlng

E. Orion propulsion systamsoptimized for offllna servicing

Figure 9 - Orion Operability SuccessesU.S. Government work not protected by U.S. copyright

8

5.1 KAIZENILEAN EVENTS

Lean/Six Sigma (LSS) principles were used to improveoperability and affordability in flight and ground systemsdesigns. Certified LSS Black Belts led teams in focusedstreamlining and Kaizen events on a number of occaSIons.Such events sought to reduce non-value added activity,reduce waste and sources of variability, and improveprocessing efficiencies.

One example is the Launch Abort System (LAS) assemblystreamlining event, where LAS processing and hardwareimprovements were offered by preassembling the ogiveenclosure, reducing re-assembly and reducing fastenercount.

Another example is the identification of improvements toproject-to-project flight hardware delivery schedules.ImprovetiIents were identified that could reduce productionto launch timelines, including hazardous commodItyservicing streamlining, parallel operations, and use ofpathfmders to reduce initial test flights' learning curveimpacts.

5.2 MOCKUPS

Mockups are an invaluable tool in any new developmentprogram. Mockups provide a low cost alternative to priceyflight hardware. Mocks also provide the development teama quick and easy way to prove or disprove a design oroperations. Mockups used early in the development cyclenot only improve the [mal design, but also help reducecostly changes later in the design cycle.

Examples

KSC Ground Operations has used mockups extensively inthe development of both the Orion flight system interfacesand the related ground operations systems. KSC usedmockups of both the KSC "White Room" and JSC OrionCrew Module (Figure 10) to help demonstrate the interfacebetween the "White Room" and the Ogive fairing. This ledto a redesign of this interface.

KSC also was able to demonstrate Crew emergency egressfrom the Crew Module to the "White Room" (Figure 11).This was done with the Astronauts in their new prototypesuits and KSC Fire and Rescue in their new prototype firesuits. This demonstration led to many improvements of theOrion Crew Module, Astronaut suits, Fire and Rescue suits,and "White Room".


9

Figure 10 - "White Room" to Ogive Fairing Interface

Figure 11 - CM Emergency with Fire Rescue

Another demonstration was the use of a full scale OrionService Module mockup to help show that Orion could beserviced with existing KSC Ground Support equipmentinstead of more expensive new equipment. This gave theKSC Operations team confidence that if funding for newequipment wasn't available, they could still support anOrion flight. Lastly the full scale SM mockup was also usedto show if servicing of the SM/CM could be done usingtemporary scaffolding (Figure 12). This proved thattemporary scaffolding was not adequate from a safetystandpoint. This was used to help justify better platformsfor access to Orion.

Figure 12 - SM with Scaffolding Access

5.3 HUMAN FACTORS ANALYSIS

A Human Factors Team was formed consisting of qualifiedhuman factors engineers, experienced spacecraft operationsengineers, design engineers, and the design visualizationteam. This visualization team reviewed the flight andGround Support Equipment (GSE) designs for humanfactors. By following the processing timeline, each Orionground operation was analyzed in the KSC DesignVisualization Lab with human factors and operationsexperts focusing on the hardware to human interactionsaffecting the human performance during assembly,maintenance, and inspection of Orion.

These important meetings with the operations and designengineers using the actual flight and ground designs loadedinto the design visualization tools were a great help duringthe Human Factors Operability Engineering Analysis(HFOEA). The team used a modified version of a HumanFactors Engineering Analysis (HFEA) tool developed by theKSC Engineering Directorate by re-arranging the analysisspreadsheet to show the timeline of Orion operations. Foreach of the operations, five data fields in the tool werepopulated, including: Human Interfaces, Issue, ProcessingPhase, Risk Analysis, and Recommendations.

When an issue was discovered in a specific operation,applicable human factors standards were identified andreferenced with the issue. These standards mainly camefrom the Federal Aviation Administration (FAA) HumanFactors Design Standards (HFDS). For each issue, designengineering was brought into the process in order to addressthe issue for human factors design improvements.


10

Example

The task of moving the Orion short stack pallet into and outof the servicing bay was evaluated (Figure 13). Alignmentof pallet into the servicing bay was considered an issue thatrequired further evaluation. An action was taken to assure amethod is put in place to prevent contact and misalignmentof pallet with existing bay structure during installation!removal of short stack pallet. A human factors requirementwas evaluated and applied to the task that states "Users shallbe protected from making errors to the maximum possibleextent". A recommendation was provided to the designteam to install guide rails on the floor. See reference [2]"Human Factors Operability Timeline Analysis to Improvethe Processing Flow of the Orion Spacecraft" for moredetails on KSC ground operations human factorsassessments.

Figure 13 - Orion Short Stack Pallet at servicing bay ofMulti Payload Processing Facility (MPPF) building.

Human Factors Lessons Learned

Early collaboration and planning between the flight andground hardware designers for human factors operabilityengineering analysis (HFEA) is necessary. The programlevel NASA Constellation human factors requirementsdocument (HSIR) greatly promoted better human factorsSystems Engineering and Integration. This improved theintegration between ground systems and crewed vehicledesigns for ground processing. Timeline analysis is greatway to analyze and improve the design of ground and flighthardware interfaces for ground processing of the groundequipment, and the flight and ground hardware interface.Also, the use of qualified human factors engineers on the

design team was critical.

5.4 ACTIVE TRACKING OF FLIGHT/GROUND

ISSUES

A Microsoft Access database tool was developed in house tomanage an integrated watch list of issues that affectedground operations cost, schedule and performance. Watchlist database fields included a title, initiator, priority rating

of 1 thru 5, impact description, assigned subject matterexpert, and status. A priority rating of 1 was high-impact toGround Systems for cost, schedule and performance andrequired immediate management attention. A priority ratingof 5 had minimum impact to GS in cost, schedule andperformance. The database was set-up to allow the FlightSystems, Systems Engineering & Integration and otherProject Office functions to evaluate the impacts againstother disciplines. It provided management a quick-look ofissues that affected or had the potential of affecting theProject Office. The database exported output reports toPower-point in order to provide easy reporting for multipleuser needs.

Example

Title: Propellant GSE port sizes to prevent crossconnections (ID 221)Initiator: LX-C organizationPriority Ranking: 3Impact Description: Currently the SM fuel & SMoxidizer service carts have the same size outlet ports.There is a requirement to prevent misconnection ofcommodities. Propellant GSE design needs to accountfor potential cross connection of commodities. Thiscan be accomplished with different size outlets.Status: 10/8/1 0 - Design is planning to modify the SMFuel service panel outlets so that they are different fromSM oxidizer. However, waiting for final GSE-to-FlightInterface definition to close.

6.0. SUMMARY AND FORWARD PLAN

The Ground Operations team was able to bring the Cx Orionspacecraft infrastructure to Preliminary Design Reviewreadiness level in 2010, using a combination of tools. FFBDdecomposition, timeline development, discrete eventsimulation modeling, detailed GOPD planning and mockupswere powerful tools in planning for operations as well asdeveloping more operable ground and flight systems.

In the 2010 - 2011 timeframe, Constellation was cancelled,NASA formed the Exploration Systems Directorate, and theOrion Multi-purpose Crew Vehicle (MPCV), Space LaunchSystem, and 21 51 Century Ground Systems Programs wereinitiated. The Orion MPCV design is very similar to the preexisting design, so NASA plans to leverage existingoperations, ground and flight systems designs and plans asmuch as possible. Designs will be updated and modified asneeded for the new launch vehicle and flight raterequirements.

The 21 Century Ground Systems Program will use theoperations development tools mentioned previously; theyhave proven their effectiveness in preparing for safe,operable human exploration missions in the 21 51 century.


11

REFERENCES

[lJ Ground Operations Planning Document: Volume 3:Operations; Document Number: CXP 72149-03

[2J Human Factors Operability Timeline Analysis toImprove the Processing Flow of the Orion Spacecraft byRoland Schlierf & Damon B. StambolianNASA Kennedy Space Center (KSC)Constellation Ground Operations ProjectJFK Space CenterKSC, FL 32899I IEEEAC paper #1021, Version 3, Updated January 12,2011

BIOGRAPHIES

Gary Letchworth is currently Chiefofthe Spacecraft Branch in the NASAKennedy Space Center's 21" CenturyGround Systems Program. Gary hasover 25 years experience in launchsystems and spacecraft developmentand operations. His previousemployers include NASA GoddardSpace Flight Center, LockheedMartin at KSC, Skunk Works, and

JSC, Rockwell International at JSC, and the US Air Forceat Eglin AFB. His programs and projects include Orion,small launch vehicles and payloads, Space Shuttle,Shuttle upgrades, Airborne Laser, Orbital Spaceplane, X33 and Venturestar, Crew Return Vehicle, and Heavy LiftLaunch Vehicle concepts. Gary has a B.SI.E fromAuburn University, M.SM.E. from Georgia Tech andM.S, Engineering Management from the University ofCentral Florida.

Roland Schlierf is currently theOffline Spacecraft ElementOperations Manager (EOM) in theSpacecraft Branch in the NASAKennedy Space Center's 21 s1

Century Ground Systems Program.Roland has over 27 years experiencein spacecraft, payload, andexperiment development and

operations. His programs and projects include Orion,International Space Station, Space Shuttle, and Spacelab.Roland has a B.SE.E from the Florida Institute ofTechnology.

nasa planning for orion multi-purposecrew vehicle ground

Documents