i 

NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

TABLE OF CONTENTS

Paragraph Page

1. Introduction 1 

1.1 Purpose 1 

1.2 Scope 1 

2. Reference Documents 2 

3. Fundamentals of Life Cycle Logistics Support 3 

3.1 Life Cycle Logistics Support 3 

3.2 LCLS Implementation 3 

3.2.1 Maintenance Concept and Planning 4 

3.2.2 Design Interface 5 

3.2.3 Supply Support 6 

3.2.4 Support and Test Equipment 11 

3.2.5 Manpower, Personnel, and Training 14 

3.2.6 Technical Data 16 

3.2.7 Logistics Information Management 18 

3.2.8 Packaging, Handling, Storage, and Transportation (PHS&T) 18 

3.2.9 Facilities 19 

4. Life Cycle Logistics Support: Tightly Coupled Programs 20 

4.1 Life Cycle Logistics Support Roles and Responsibilities 20 

4.2 LCLS Program Functions 23 
ii 

NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

4.2.1 Formulation Phase 24 

4.2.2 Implementation Phase 26 

4.3 Project Functions 27 

4.3.1 Formulation Phase 27 

4.3.1.1 Pre-Phase A: Concept Studies 27 

4.3.1.1.1 Technical Activities 27 

4.3.1.1.2 Milestone Reviews 29 

4.3.1.1.3 Organizational Activities 29 

4.3.1.2 Phase A: Concept and Technology Development 30 

4.3.1.2.1 Technical Activities 30 

4.3.1.2.2 Milestone Reviews 30 

4.3.1.2.3 Organizational Activities 31 

4.3.1.3 Phase B: Preliminary Design & Technology Completion 31 

4.3.1.3.1 Technical Activities 31 

4.3.1.3.2 Milestone Reviews 34 

4.3.1.3.3 Organizational Activities 35 

4.3.1.4 Phase C: Final Design & Fabrication 35 

4.3.1.4.1 Technical Activities 35 

4.3.1.4.2 Milestone Reviews 36 

4.3.1.4.3 Organizational Activities 37 

4.3.1.5 Pre-Delivery Phase (Through DD250) (Phase D) 37 

4.3.1.6 Phase E: Operations & Sustainment 40 

4.3.1.7 Phase F: Closeout 41 

APPENDIX A: Supplier Viability Risk Management
iii

NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

APPENDIX B: Example Requirements

APPENDIX C: Example DRDs

APPENDIX D: Maintenance Level Identification Processes

APPENDIX E: PHS&T Checklist
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

1 

1. Introduction

1.1 Purpose

This guidebook is intended to provide general guidance and information on Life Cycle Logistics 

Support1 that will be useful to NASA Programs, Projects, and logistics community and should be 

used as a companion for implementing NPD 7500.1, Program and Project Life Cycle Logistics 

Support Policy. 

It provides a description of Life Cycle Logistics Support as it should be applied throughout 

NASA. A goal of the guidebook is to increase awareness and consistency across the Agency 

logistics community and advance the practice of Life Cycle Logistics Support. This guidebook 

provides perspectives relevant to NASA and data particular to NASA.

1.2 Scope

The Life Cycle Logistics Support (LCLS) activities and functions described in this guidebook 

apply to NASA Programs and Projects. This applicability includes both flight hardware systems, 

non-flight systems such as launch facilities and communication facilities, and ground support 

systems. As defined in NPD 7500.1 (Program and Project Life Cycle Logistics Support 

Requirements), the responsibility for developing and implementing the LCLS approach for each 

program or project resides with the Program Manager, Project Manager, or their designated 

LCLS Manager.2 Execution of some or all of these activities and functions may be delegated to 

contractor organizations when the Program/Project Manager and/or the LCLS Manager 

determine that doing so will result in the most efficient solution for the Government. 

These activities and functions apply to new Contractor Furnished Equipment (CFE) hardware 

projects or Government Furnished Equipment (GFE) or Government Developed Equipment 

produced by NASA or other government organizations and contractors for NASA. The overall 

effort begins at the Requirements Development Phase and progresses through the design phase 

consisting of the Preliminary Design Phase (through PDR); the Critical Design Phase (through 

CDR); and the Pre-Delivery Phase (which culminates with hardware DD250), the Operations 

and Sustainment Phase, and, finally, the Closeout Phase. 

 

1 As used in this document and in NPD 7500.1, the term "Life Cycle Logistics Support" is synonymous with the term 

"Integrated Logistics Support", and the term "Product Support" (used by the Department of Defense).

2 The person performing this function may have a different title – such as Logistics Manager, Product Support Manager, etc. 

– but the functional responsibilities are the same.
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

2 

2. Reference Documents 

NPD 7500.1C NASA Program and Project Life Cycle Logistics Policy

NPR 7120.5 NASA Space Flight Program and Project Management Requirements.

NPR 8735.1 Procedures For Exchanging Parts, Materials, and Safety Problem Data 

Utilizing the Government-Industry Data Exchange Program and NASA 

Advisories.

ASD S3000L International Procedure Specification for Logistics Support Analysis 

(available at http://www.asd-stan.org/s3000L.html). 

GEIA-STD-0007 Logistics Product Data (available at https://standards.nasa.gov).

MIL-STD-1388-1A Logistics Support Analysis 

MIL-STD-1388-2B DoD Requirements for a Logistics Support Analysis Record 
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

3 

3. Fundamentals of Life Cycle Logistics Support

3.1 Life Cycle Logistics Support

Life Cycle Logistics Support (LCLS) comprises the planning, development, implementation, and 

management of a comprehensive, affordable, and effective systems support strategy. LCLS 

encompasses the entire life cycle including acquisition (concept studies, concept and technology 

development, preliminary design and technology completion, final design and fabrication), final 

production, support (system assembly, integration and test, launch, operations and sustainment), 

and closeout. The principal objectives of LCLS are to:

• Ensure Life Cycle Cost (LCC) is considered along with key design and performance 

parameters.

Influence product design so that the system can affordably attain required operational 

availability.

Design, develop, and implement a cost-effective support system.

Maintain and improve availability, improve affordability, and minimize the logistics 

footprint. 

•

•

•

In the case of a system such as a space vehicle that is used multiple times or is in continuous 

operation for an extended period, the majority of the system’s life cycle costs (typically 60-70%) 

can be attributed directly to operations and support costs, while in the case of a system such as a 

launch vehicle the majority of life cycle costs may be in design and production. Regardless of 

the type of system involved, because these costs are largely determined early in system 

development, it is important that system developers evaluate potential operational and support 

costs of alternative designs and factor these considerations into early design decisions.

3.2 LCLS Implementation

In order to achieve the LCLS objectives identified in the previous section, a set of LCLS 

elements have been established. The elements of LCLS are:

• Maintenance Concept and Planning

Design Interface

Supply Support 

Support and Test Equipment 

Manpower, Personnel, and Training 

Logistics Information Management 

Technical Data

Packaging, Handling, Storage and Transportation 

Facilities

•

•

•

•

•

•

•

•

All elements of LCLS should be developed in coordination with the system engineering effort 

and with each other. Acquisition logistics requirements must be established and clearly defined 

early in the life cycle and be a contributor to the development of the acquisition strategy in order 

to minimize total ownership costs. Tradeoffs may be required between elements in order to 
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

4 

acquire a system that is: affordable (lowest life cycle cost), operable, supportable, sustainable, 

transportable, and environmentally sound. 

The planning for LCLS for a system is contained in an Integrated Logistics Support Plan (ILSP). 

The ILSP is used to identify and define all logistics planning activities. The ILSP is used as a 

life cycle document to ensure logistics support over the product’s entire life cycle. 

The following sections provide a brief description of each of the LCLS elements, including key 

points to be included in the ILSP for each ILS element. In tightly coupled programs with 

subordinate projects, there will be an ILSP for the program and ILSPs for each of the projects. 

Discussion of the ILSP in the following sections covers both the program-level and project level 

documents. The program-level ILSP should address the broad program operational concept and 

operational requirements. It should be broad enough to encompass the various specific needs of 

all of the subordinate projects. The ILSPs of the subordinate projects should be consistent with 

the program-level ILSP and address the specific approaches to be employed by the individual 

project. It is left to the discretion of the program LCLS manager and the project LCLS managers 

to include the level of detail that is appropriate for them.

Depending on the relative roles and responsibilities of the Government’s program and project 

offices and respective contractor organizations, it may be appropriate or necessary for the 

contractor organizations to develop ILSPs as well.

3.2.1 Maintenance Concept and Planning

Maintenance Concept

The objective of the maintenance concept is to define an approach to system maintenance that 

will provide required system availability while controlling life cycle costs. The maintenance 

concept must be compatible with the mission profile or other operational requirements and 

constraints and is subject to such resource constraints as cost, crew time available for 

maintenance, mass/volume allocated for tools, spares, etc.

The maintenance concept is usually identified during Pre-Phase A development so that an 

estimate of the life cycle costs can be made during project formulation. It is especially important 

that the maintenance concept be defined at the earliest stages of development of hardware system 

designs and operational concepts. For systems where maintenance will be a significant activity 

and cost driver, early consideration can allow adjustment of hardware design to facilitate 

maintenance, optimize requirements for spares, and reduce total life cycle cost.

Maintenance Planning

Maintenance planning is the process of applying the maintenance concept to each hardware item 

and associated processes when making implementation decisions for the lifetime of the system. 

Maintenance planning applies the maintenance concept and decisional processes to define the 

level at which each item is maintained, how it is maintained, and the resources required to 

maintain it. 

Maintenance Plan

The Maintenance Plan documents the results of the maintenance planning effort. The 

Maintenance Plan and underlying maintenance concept should encompass all program life cycle 
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

5 

phases and address all applicable mission phases including development and test, ground 

operations, launch, in-space and destination surface operations, and post-flight turnaround. It 

defines acceptable levels of repair, what tasks will be performed, how those tasks will be 

conducted, the resources that are required, and the organization responsible for the various 

associated activities. Acquisition of support resources must be based on the Maintenance Plan. 

The supportability tasks included in maintenance planning identify the mission criticality of 

parts, authorized maintenance levels, and estimates of replacement rates and of part failures. A 

Level of Repair Analysis (LORA) should be conducted to determine the best value support 

policy for an item (considering all resources including cost, mass, volume, and crew time 

available for maintenance) and to help identify the appropriate time to make, repair, or discard 

the hardware item.

In simple programs the Maintenance Plan is often included as an appendix to the ILSP. In 

complex programs the Maintenance Plan is usually issued as a separate document and referred to 

in the ILSP. There is the potential to introduce document control issues if the Maintenance Plan 

is included in the ILSP – as changes to the Maintenance Plan will result in a reissue of the ILSP 

whether or not there was a logistics impact resulting from the change.

3.2.2 Design Interface

Design Interface Planning

The Design Interface element of LCLS is the process through which LCLS experts engage with 

hardware system designers to make the system supportable for the least possible resource 

demand. Resource demands include financial cost, support personnel time, quantity of spares, 

mass of spares, volume of spares, etc. It is unlikely that all resource demands can be minimized 

so those that are most tightly constrained or limited should be focused upon. For example, 

during ground operations the time required by ground personnel to support the flight vehicle 

system or the total financial cost of support activities might be far more important than the 

mass/weight of spares or their geometric volume. On the other hand, for in-space maintenance 

and repair operations, it may be more important to minimize the total mass and volume of spares 

- accepting that total financial cost may be of less importance. For maintenance of ground 

systems, driving considerations might be total sustainment cost or minimization of repair time if 

launch opportunities are severely time-constrained. 

In general, the life cycle logistics expert should strive to influence the design to facilitate 

maintenance, repair, and other support activities as much as possible. Ease of access to 

components for maintenance is critical. However, since it may not be possible to place all 

components for optimal access, those that are most likely to require attention (either because of 

frequent routine servicing requirements or inherent reliability that suggests a greater frequency of 

failure) should be prioritized for ease of access. Experience also suggests that it is desirable to 

design hardware in a way so that those specific components that are most likely to fail (such as 

bearings, valves, electronics subunits) can be replaced so that it is not necessary to replace a 

larger assembly. Another factor to consider is the testability of a system - that is, the ability to 

obtain information from the system to identify the specific items that have failed. Good 

testability can significantly increase the efficiency of repair operations by avoiding a trial-anderror approach to fault isolation. 
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

6 

Design interface is the relationship of logistics-related design parameters of the system to its 

projected or actual support resource requirements. These design parameters are expressed in 

operational terms rather than as inherent values and specifically relate to system requirements 

and support costs of the system. Programs such as "design for testability" and "design for 

discard" must be considered during system design. 

The primary items that need to be considered as part of design interface include:

• Reliability requirements

Maintainability requirements

Standardization requirements

Interoperability requirements

Safety requirements

Security requirements

Usability requirements

Environmental and hazardous materials requirements

•

•

•

•

•

•

•

3.2.3 Supply Support

Supply Support Concept

The objective of the Supply Support Concept is to define an approach to the identification, 

procurement, and management of initial and replenishment spare and repair parts. The Supply 

Support Concept is based on the approved maintenance concept and identifies the strategy of 

how required material will be acquired, who will provide the material, and where inventory will 

be held. These strategies can range from acquisition through the Prime Contractor, Direct 

Vendor Delivery from vendors, the use of Third Party Logistics providers, etc. 

Two primary objectives of supply support are to ensure that end items are delivered in a 

satisfactory state of readiness and to maintain readiness by fulfilling material replenishment 

requirements throughout the life cycle of the end item. Achieving these objectives is based on an 

appropriate Supply Chain Management strategy. In order to ensure supportability throughout 

the life cycle, NASA must have knowledge of all suppliers in the supply chain and be able to 

identify risks to the supply chain. 

Decisions affecting spares and the supply chain must be made very early in the life cycle of a 

system. As the program evolves, the project-level Government LCLS manager must issue 

provisioning technical documentation guidance, consistent with the system’s maintenance and 

support concepts, via the contract to ensure that project unique materials are promptly ordered 

and that the supply chain is responsive to NASA’s requirements. The project-level Government 

LCLS manager must also ensure that follow-on spare and repair parts are obtained in a costeffective manner. An effort should be made during design to minimize the use of proprietary 

materials and processes whenever possible. The project-level Government LCLS manager 

should obtain technical data, drawings, tools, etc. through contractual requirements, to enable 

competition among contractors for follow-on logistics support. In this way, the project can 

enhance the effectiveness of the supply chain throughout the system’s life cycle. Relying 

entirely on the original prime contractor for follow-on support material entails risks in the areas 
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

7 

of cost and availability of needed spare and repair parts, especially during the post-production 

support period. 

For single-use systems that are in a continuing production run, such as launch vehicles, the total 

pool of equipment should be considered. At any time, there will be a number of components in 

existence from the next vehicle in production to components that have been delivered for use in a 

production vehicle but not yet installed. Failures could occur at any point in production, and the 

use of production components for replacement on the vehicle closer to launch should be 

considered to avoid excessive spare component procurement.

The Supply Support Concept is documented in the ILSP. The ILSP should address the 

following: 

• The supply support concept and the strategies used to ensure effective support to the end item 

and responsiveness of the supply chain. 

The factors, risks and assumptions on which the supply support concept is based. 

How any anticipated commercial item acquisitions will affect the supply support system.

Any unique supply requirements that are being considered. 

Any Government Furnished Material (GFM) that will be used. 

The plan to include training, support and test equipment in the supply support system. 

Implementation of space-based inventory management system architecture and element-toelement inventory management system compatibility. Compatibility with the appropriate 

NASA logistics and inventory management system should also be addressed. 

•

•

•

•

•

•

∗

Initial Provisioning

Provisioning is the process of determining the range and depth of spares and repair parts and 

support and test equipment required to operate and maintain the end item for an initial period of 

service. The basic contract should define an initial provisioning period. This period must be 

specified in the major systems contract and be defined in terms of some significant event in the 

program cycle, e.g., assembly complete plus 2 years of continuous operation of four successful 

flights. The period should cover test and evaluation, plus a short period of operation, so that 

sufficient operational experience can be gained with the system to provide a basis for adjusting 

spares stock levels and fully competitive acquisition of follow-on spare parts. However, this may 

not be possible for production runs that are relatively short and when the program would incur 

manufacturing restart or requalification costs. Provisioning methodologies will be determined by 

the individual projects. 

Initial provisioning should be accomplished by the development contractor during the original 

phase of a major system program. A requirement covering procedures for the conduct of initial 

provisioning should be included in the synopsis and solicitation, with the contractor's obligations 

to perform initial provisioning set forth as a separately priced line item. Regardless of the type 

of program, all provisioning should be accomplished before the manufacturing lines are closed in 

 ∗

Much of the content from this section and the following sections on Replenishment, Life of Type Buys, SAIP, and 

Breakout draw extensively on content from the former NPR 5900.1, NASA Spare Parts Acquisition, which has been 

cancelled. 
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

8 

order to not incur manufacturing restart costs. Life of type buys would apply as well. On 

programs with short development production schedules, an SAIP process (discussed more fully 

below) should be considered. 

The product of initial provisioning assessments should include a list of proposed spare parts and 

related quantities needed to support the major system during the initial provisioning period. The 

recommended sparing strategy and schedules shall also be included. The list provides the basis 

for an assessment of the potential for breakout (describe below) and competition on reprocurement items. For each item, there shall be a unit price and identification of the OEM. 

Whenever possible, the specific spare parts and quantities proposed should be based upon 

probabilistic analyses using parameters such as predicted/designed consumption rates, any 

empirical data available, engineering estimates of predicted use of the spare parts, and the overall 

probability of sufficiency (POS) assumed. POS is the probability that the spare parts will be 

available when needed. 

The contractor submits the list of proposed spare parts and related quantities to NASA and 

participates in an initial provisioning conference in which NASA evaluates the contractor's 

recommendations and the data upon which they are based and makes initial purchase and 

inventory-stocking decisions. The contractor makes recommendations only. The decisions (a) on 

how to procure, (b) to purchase or not purchase an individual item suggested by the contractor as 

a spare part, and (c) on the quantity of each item to be purchased are made solely by NASA. For 

human spaceflight programs, the project-level Government LCLS Manager must consider spares 

for system development and testing, ground processing, prelaunch test and check-out, launch 

support, and In-Flight Maintenance (including support of systems on destination surfaces). 

Program managers or their designated Life Cycle Logistics Support Managers should process 

recommendations on spares make decisions on purchases in a timely manner in order to 

minimize procurement costs and to ensure that spare parts are available in time to support the 

need. 

To provide a vehicle for ordering spare parts during this period, the contract should include a 

separate line item, obligating the contractor to provide any parts identified during initial 

provisioning and ordered by the Government. Unless otherwise justified, prices shall be 

negotiated before the contractor begins work on an individual order. If possible, each order 

should be on a firm fixed-price basis with individual items separately priced. If experience can 

be gained with the operational system, the items selected as spare parts and the quantities needed 

may change. Individual item pricing will facilitate making these changes and provide a pricing 

history for later purchases. 

Program managers or their designated Life Cycle Logistics Support Managers should screen for 

parts availability from Government sources and obtain parts from those sources if available at a 

lower cost, provided that traceability standards can be maintained. To the maximum extent 

practicable, follow-on spares procurement should be purchased directly from the actual 

manufacturer, i.e., lowest-tier subcontractor, or from other qualified manufacturers to eliminate 

the layers of support costs at each tier (see discussion of "breakout" below). 

It may be cost effective to use existing prime or subcontractor personnel and processes to effect 

such procurements. Purchase requirements shall be consolidated upon completion of NASA 

decisions on the contractor's provisioning recommendations. 
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

9 

Replenishment

Replenishment begins prior to the conclusion of the initial provisioning period, i.e., when 

demand and usage patterns are becoming clearer. Requirements for replacement of parts used but 

not reordered during the initial provisioning period are considered replenishment requirements. 

Spares replenishment then continues throughout the life of the system. The key is to stock the 

right parts in the right quantities at the appropriate location(s). These factors seldom remain 

static during the system's useful life. Early in the initial provisioning period, NASA typically 

orders spare parts exclusively from the major systems contractor. As experience is gained, 

however, opportunities to break out items for competitive acquisition may become apparent. 

Before ordering spare parts under the major systems contract, the contracting office should 

examine the alternate sources. 

Replenishment may be accomplished by NASA or by a prime or support contractor. Any 

purchases of spare parts for replenishment, whether accomplished by NASA or a contractor, 

shall be separate from the major system development contract and shall comply independently 

with the requirements for full and open competition. The decision should be based on the lowest 

overall cost to NASA in a full- cost environment, including consideration of such factors as 

major system contractor total-system responsibility, inventory-stocking costs, overhead charges, 

and Government contract administration costs. In any case, NASA retains the final overall 

responsibility for replenishment, and program managers must ensure that periodic reviews and 

oversight are conducted and ensure that there is timely, efficient program support. The 

requirements for effective management and financial reporting of program stock, as specified in 

NPR 4100.1, NASA Materials Inventory Management Manual, may apply. This inventory 

control may be achieved by the use of NASA's supply management system. 

Life of Type Buys 

Life of type buy decisions will be driven by several factors. Hardware obsolescence notice can 

drive the decision to procure what is needed while stock/capability is still available. Limited 

production runs due to unique one-of-a-kind development programs, can drive the cost of trying 

to keep the vendor's production line open for limited spare buys at later dates.

Cost tradeoffs should be made on life of type buys based on such factors as the quantity required 

to support the life of the program, production schedules, cost for spares, keeping production lines 

open, retooling, and potential obsolescence. 

Spares Acquisition Integrated with Production (SAIP)

SAIP is a process whereby the Government combines spare parts orders with planned 

production. This approach is particularly effective when applied to limited initial production 

runs. Rather than extending a contract for the sole purpose of producing very low quantities of 

spares buying spares along with the initial production run may be more cost effective.
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

SAIP implementation is best applied to major programs that have distinct acquisition phases. 

Program managers should have the contractor provide development schedules and identify 

spares order decision dates to implement SAIP buy orders. On programs that combine 

acquisition phases, SAIP shall be implemented on items that are more mature and pose less risk 

of design changes. On items that still pose a risk of change, SAIP should be deferred until the 

design matures and implemented before production lines close.

Breakout

Breakout means the purchase of spare parts, either by the Government or a contractor, directly 

from the original equipment manufacturer (OEM) or another source close to the original 

manufacturer. The goal of breakout is to eliminate any added costs that can be incurred because 

of subcontractor tiers, when no value added or enhancements are made. Breakout is best used on 

re-procurements or replenishing initial spare stock levels to the probability of sufficiency as 

determined from history 

Breakout should be an ongoing consideration throughout the program or project life cycle. 

Program and project managers shall include breakout as a part of their logistics planning and 

analyses requirements. Individual breakout decisions shall be based on the results of the logistic 

support analysis required by NPD 7500.1, Program and Project Logistics Policy, or an economic 

analysis for non-program hardware that shall take into account the following considerations:

a. Design stability of the items of supply to be acquired.

b. Availability of drawings, technical data, hardware and software documentation, production 

process, test and quality specifications, tools, test equipment, and materials required to ensure 

competition.

c. Potential benefits of the competition compared to the cost to re-procure from the original 

source of supply. 

d. Liability assumed by the Government. 

Breakout shall be explicitly recognized in the structuring of major systems contracts. Contract 

provisions shall require prime contractors to identify actual hardware manufacturers and to 

furnish data for evaluating breakout benefits. Decisions to retain the original source of supply for 

the life of a program or project due to proprietary processes, quality considerations, safety, or 

cost will be documented for future audits. 

In rare cases, it may be possible to use initial spare parts to develop technical data for use in 

future spares replenishment by reverse engineering. While legal, the practice of reverse 

engineering can be difficult and costly and should be used only when other alternatives are not 

feasible

NASA personnel should identify, as early as possible in the development cycle, the technical 

data, and the attendant rights thereto that NASA needs to acquire. Such identification will 

facilitate the making and implementation of breakout decisions. The following specific actions 

should be taken: 

10 
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

11 

(a) Establishment of separate contract line items for technical data, normally broken down in 

terms of the subsystem, assembly, or subassembly to which the data relates and to individual 

parts and components. Also, to the extent feasible, the breakdown should include the pricing of 

such data if related to designs and developments first produced under the contract. 

(b) Identification by the contractor of any technical data that, if delivered, will be with 

limitations or restrictions on NASA's right to use it, or have others use it, for manufacture or reprocurement purposes. 

(c) Establishment of delivery schedules and/or options for delivery on a phased basis keyed to 

component design stability.

(d) Establishment of procedures for inspection of technical data needed for breakout, both for 

technical completeness and accuracy, as well as for any unauthorized limitations or restrictions 

on its availability for use for manufacture or re-procurement. Where Government expertise does 

not exist, a verification contract may be awarded to a manufacturing or production engineering 

firm with related experience.

(e) Requirements that the contractor correct any deficiencies in the technical data regarding its 

completeness and accuracy and revise the technical data regarding any engineering changes 

made during contract performance that affect the form, fit, and function of any spare part 

designated for breakout. 

(f) Contractual provisions and procedures to correct in a timely manner, and without cost to the 

Government, any unauthorized restrictions on the right to use the technical data for manufacture 

and/or re-procurement. 

3.2.4 Support and Test Equipment

Support Equipment Planning

Systems or other items of equipment normally require the use of additional equipment to support 

operations or maintenance. Any item of equipment required to support operation or maintenance 

is categorized as support equipment. The support equipment can be a special item designed for 

only one specific use, or it can be items that have multiple uses. The support equipment 

planning process should encompass all program life-cycle phases and address all applicable 

mission phases including development and test, ground processing including assembly and 

checkout, prelaunch, launch, in-space and destination surface operations, and post-flight 

turnaround. The following list is a summary of some of the different types of support 

equipment:

Ground Support Equipment (GSE)

GSE is non-flight equipment with a physical and/or functional interface with the flight hardware 

that is routinely required for the handling, servicing, inspection, testing, maintenance, alignment, 

adjustment checkout, vehicle assembly, repair, and overhaul of flight hardware.

Ground Support Systems (GSS) 
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

12 

GSS is non-flight infrastructure and equipment that provided functional and /or physical support 

to GSE. It does not physically interface with flight hardware but it may supply commodities, 

power, or data that eventually reaches flight hardware after it has been conditioned or controlled 

by GSE.

Flight Support Equipment (FSE)

Flight Support Equipment (FSE) is returnable hardware that provides the interface between the 

LRU/ORU or Shop Replaceable Unit (SRU) and the carrier. FSE supports loads during all 

applicable phases of flight and provides thermal conditioning for launch, landing and in-space 

operations, as required. For external hardware, FSE is compatible with EVA. For external items 

that are robotically compatible, the FSE is also robotically compatible such that translation, 

storage, removal and replacement can be conducted end-to-end without EVA intervention. 

Orbital Support Equipment (OSE)

OSE is similar to FSE, except that OSE remains on orbit.

Flight Crew Equipment (FCE) 

FCE consists of all crew-related equipment and includes space suits, extravehicular life support 

equipment, food, bioinstrumentation, personal communications equipment, photographic 

equipment, miscellaneous mission operational aids, and tools.

Surface Support Equipment (SSE)

SSE is equipment used on destination lunar, asteroid, and planetary surfaces to provide support 

for setup and sustainment of the surface infrastructure (habitats, production facilities, 

manufacturing equipment, maintenance facilities, power stations, communications, 

transportation, and launch and landing sites, etc.). SSE is equipment required for handling, 

servicing, inspection, testing, maintenance, alignment, adjustment checkout, repair, and 

overhaul. SSE is analogous to other types of support equipment that is designed specifically for 

use in the particular surface environment. For the design of this equipment key environmental 

variables include atmospheric pressure (or lack thereof) and gravitational acceleration.

Test, Measurement, and Diagnostic Equipment (TMDE) 

TMDE is any system or device used on the ground, in flight, or on a destination surface to 

evaluate the operational condition of an end item or subsystem thereof to identify and/or isolate 

any actual or potential malfunction. This TMDE includes diagnostic and prognostic equipment; 

semiautomatic and Automatic Test Equipment (ATE) to include Test Program Sets (TPSs) (with 

issued software); and calibration test or measurement equipment. (Note: When the term TMDE 

is used, it refers to both TMDE-GP and TMDE-SP.)
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

13 

Test, Measurement, and Diagnostic Equipment - General Purpose (TMDE - GP)

TMDE-GP is any TMDE that can be used to support multiple end items or systems without 

requiring modification. Addition of external special accessories, plug-in assemblies, logic 

probes, and attenuators (or TPSs for ATE) are not considered modifications. 

Test, Measurement, and Diagnostic Equipment - Special Purpose (TMDE-SP)

TMDE-SP is any TMDE designed specifically for support of and functionally restricted to one 

end item or system. To use this TMDE for support of another end item or system would 

necessitate modifications to the TMDE. Addition of external special accessories, plug-in 

assemblies, logic probes, attenuators (or TPS for ATE) are not considered modifications. 

Automatic/Automated Test Equipment (ATE) 

ATE is any TMDE that performs a predetermined program to test functional or static parameters, 

to evaluate the degree of performance degradation, or to perform fault isolation of unit 

malfunctions. As a minimum, ATE must be able to sequentially perform testing/measurements, 

compare the measurements to predetermined values or ranges, and based on the results of this 

comparison, branch to other tests without manual intervention. ATE is usually external to the 

prime device.

Test Program Set (TPS) 

The TPS is the combination of interface devices, software test programs (such as those residing 

in logic storage media or in permanent digital memory), and documentation that together allows 

the ATE operator to perform the testing/diagnostic action on the Unit Under Test (UUT).

Built-In Test Equipment (BITE) 

BITE is any identifiable device that is a part of the supported end item and is used for testing that 

supported end item. 

Calibration Equipment

Calibration Equipment consists of measurement standards and TMDE used in performance of 

calibration.
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

14 

The number of different tools and support equipment required for test, maintenance, assembly, 

servicing, handling, etc. should be kept to a minimum. Commonality should be stressed and 

multi-application tools should be used wherever possible. TMDE-GP should be utilized versus 

TMDE-SP, whenever possible. 

Support equipment factors may impact commercial item acquisitions (e.g., new calibration 

standards and procedures for related test equipment may not be available when a commercial end 

item is deployed). Additionally, rapid deployment of a commercial end item may necessitate the 

procurement of commercial support equipment or the need for interim contractor support. 

3.2.5 Manpower, Personnel, and Training

Manpower and Personnel Analysis

Manpower and personnel analysis is the process conducted to identify and acquire personnel 

with the skills required to support the system over its planned lifetime. Training includes the 

students, courses, instructors, equipment, facilities, curricula, and all other materials required to 

train personnel to support a system including individual and crew training; new equipment 

training; initial, formal and on-the-job training including any certifications, if required; and 

logistics support planning for training equipment. Because Manpower, Personnel and Training 

(MPT) costs are usually a major driver of support costs, planning for this element must begin at 

program initiation. Acquisition logistics efforts should strive to minimize the quantity and skill 

levels of manpower and personnel required to support the system over its planned lifetime. 

Training of flight crews for In-Flight Maintenance (IFM) is managed by NASA’s Mission 

Operations Directorate (MOD). Materials used during this training utilize source material 

developed during the logistics development process. This training may be performed in NASA 

training facilities, at other NASA facilities utilizing flight hardware, or at contractor facilities 

utilizing flight or training hardware.

System-specific training required for ground personnel should be defined by the project in 

collaboration with the ground processing organizations and documented in the projects’ ILSPs. 

The contractors’ role in the training of ground personnel should also be defined in the projects’ 

ILSPs and should address the following specific topics: 

• Safety

Skills or knowledge to be trained and any required certifications 

Recommended necessary duration of training 

Training facilities required

Training equipment or devices required

Training program content 

Training program implementation

Other resources required 

•

•

•

•

•

•

•

Additional details of the implementation and performance of functions by the contractor should 

be included in the contractors’ ILSPs. 
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

15 

Support of Training Equipment and Devices (TE&D) 

Training Equipment and Devices (TE&D) are model replicas of the end item (system) devoted to 

the training and instruction of personnel. Because the conduct of training frequently results in 

increased maintenance requirements (due to constant use from students performing operating and 

maintenance tasks), the project office may need to adjust the quantity of spare parts and other 

supply support normally provided. 

The ILSP should address the following, as applicable: 

• The procurement of data and documentation necessary to support and maintain TE&D.

Identification of the spare parts and Configuration Management considerations that may 

impact the TE&D acquisition strategy.

Identification of spares, repair parts and consumables required for the TE&D. 

Include discussion of tradeoffs and the impact on the acquisition strategy and the overall 

support structure (e.g., the decision to use [or not use] commercial hardware/software). 

•

•

•

Contractor/Factory Training

Contractor or factory training encompasses training that is provided by a contractor in the 

operation, maintenance, or activation of a system, equipment, or training device. It can be 

conducted at a contractor site or Government facility by contractor or other personnel. Factory 

training can be either initial or follow-on training, or both. 

The ILSP should address the following: 

• Whether ground and crew training for system maintenance will be required at the factory.

Any constraints related to its development and implementation.

Date, course title, description, developing organization, course developer, and trainee 

population. 

When identifying the trainee population, indicate if the training is designed for operators, 

operators/maintainers, (indicate level of training: Organizational, Intermediate, or DepotLevel maintainers), team training, Government and/or contractor personnel.

Whether training is for basic skills, skill progression, or other types of training. 

The rationale for the training of Government personnel (including flight crew) at facilities 

other than Government facilities.

•

•

•

•

•

On-Board Maintenance Training

On-Board Maintenance Training is provided to flight crews during a mission when necessary to 

support the performance of specific tasks that may be particularly complex or which require 

capabilities beyond those acquired by the crewmembers during pre-mission training. On-Board 

Maintenance Training may include Computer Based Training (CBT), Interactive Courseware 

(IC), and embedded training. 
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

16 

The ILSP should address the following: 

• The philosophy, relative scope and benefits of on-board maintenance training capability 

during a mission. 

• The type of training provided, such as: 

o Proficiency training

Maintenance training

Other on-board maintenance training packages and the location where the identified 

training will be accomplished.

o

o

3.2.6 Technical Data

Types of Technical Data and Documentation (TD&D) 

TD&D is recorded information, regardless of form or characteristic, of a scientific or technical 

nature. There are five categories of technical data:

1. Configuration Documentation (i.e., to include engineering drawings, interface requirements 

and control documents) 

2. Technical Procedures

3. Items Identification Data

4. Technical Reports

5. Other (imagery and video of hardware during fabrication and assembly, Problem Reporting, 

Analysis, and Corrective Action [PRACA]-type data acquired during testing, etc.)

The Supportability Analysis should include a detailed review of TD&D requirements and options 

for long-term support of NASA Program requirements. 

The ILSP should address the following: 

• The system to store TD&D and access/transfer plans for NASA.

Documentation of technical data management planning.

The acquisition strategy, and associated drivers, for technical manuals and engineering 

drawings. 

Compatibility of contractor data with existing Government data systems.

The process to mitigate/minimize proprietary data rights.

•

•

•

•

The technical data planning process should encompass all program life cycle phases and address 

all applicable mission phases including development and test, ground processing including 

assembly and checkout, prelaunch, launch, recovery, in-space and surface destination operations, 

and post-flight turnaround. 

Data Rights 

It is especially important to ensure that the Government has data rights to the delivered system. 

Data rights are a broad field that includes full data rights, limited data rights, intellectual property 
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

17 

rights, proprietary information rights, copyrights, and trade secrets. Without full or limited data 

rights to drawings and software procured for use in a system, NASA may not have the right to 

transfer the drawings, software and associated documentation to other Government agencies or 

other contractors to ensure the effectiveness of the supply chain for life-cycle support. If the 

contractor who developed the system considers the design techniques and algorithms in the 

software to be trade secrets or proprietary, they will not want the information to be released to 

competitors. The LCLS manager must determine if it will be necessary to release this 

information to another Government agency or contractor for support purposes during the life 

cycle of the system. If so, the Government must have either:

1. Full data rights which allow the Government to do anything with the drawings and 

algorithms, or 

2. Limited data rights authorizing release of the drawings and algorithms for support purposes 

only. 

Technical Data and Documentation (TD&D) Requirements for Commercial Equipment

In most cases, there is no longer a requirement to develop NASA-unique TD&D for commercial 

equipment. Commercial manuals should be used if feasible and if they satisfy the requirements 

of the program/project. The alternative is the commitment of spending considerable time and 

money converting the manuals. In the past, a major data problem has been the incomplete 

identification of data requirements and the lack of emphasis on procedures that ensure legible, 

complete and correct TD&D.

The ILSP should address the following: 

• Procedures for Technical Data & Documentation (TD&D) procurement including 

development of Data Requirement Description (DRD) language for application to 

agreements and contracts.

Roles and responsibilities of activities/contractors participating in the development of 

TD&D.

Risks and mitigations associated with the acquisition, timely delivery, and quality of TD&D.

•

•

Validation/Verification of TD&D

The validation process evaluates TD&D for technical accuracy, adequacy, comprehensibility, 

and usability. The validation is normally conducted at the development/test facility or 

operational site and involves the performance of operating and maintenance procedures, 

including test, checkout, calibration, alignment, removal, installation and disassembly. TD&D 

verification is performed by the Government to ensure that the TD&D is adequate to support the 

operation and maintenance of the end item. The verification is conducted using personnel with 

skill levels equivalent to those of the target operators or maintainers.

The ILSP should address the following: 

• The plan for TD&D review, validation and verification.
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

18 

• The validation process and provisions to ensure the validation method permits the 

performance of tasks in an environment that closely duplicates (or simulates) operational 

conditions.

3.2.7 Logistics Information Management

Logistics information is critical in all phases of life cycle management. The effective 

management of this information is vital to supporting knowledge-based logistics decisions 

throughout the life cycle. The content and format requirements for logistics information must be 

identified early in the life cycle.

Initial logistics data is derived from the results of the various Logistics Support Analyses 

(LSAs). In the case of an acquisition program utilizing a contractor, this requirement can be 

levied on the contractor; however, in the case of Government Furnished Equipment (GFE) 

developed in-house by NASA (or any other government agency) NASA will be required to 

develop/obtain this data. Additional logistics data will accrue during the life cycle of the 

program or project. Examples include lifetime or cycles to failure of specific hardware items, 

information about failure modes that are experienced, and time (and other resources) required for 

preventive and corrective maintenance. Regardless of the original source of the data, NASA 

must maintain this data in a compatible format throughout the equipment life cycle.

The ILSP should address the following: 

• The content and format of required logistics data.

The original source of the data.

Management of the data - e.g. where it will be stored, how it and access to it will be 

controlled, who will compile it, who will have access to it

•

•

3.2.8 Packaging, Handling, Storage, and Transportation (PHS&T)

Packaging, Handling, Storage and Transportation (PHS&T) planning must include all phases of 

end-item life cycle. This includes:

• Shipment from the Original Equipment Manufacturer (OEM).

Operations at intermediate and final assembly locations.

Packaging, handling and storage at the launch site and at test facilities.

Launch (including requirements for Flight Support Equipment [FSE]). 

In-space handling and stowage (with special attention to interfaces for the crew, robotics, and 

support equipment). 

Handling on destination surfaces. 

Launch from destination surfaces. 

Reentry and landing. 

Shipping from landing site to launch site.

Shipping from landing site to depot facilities for repair and refurbishment. 

•

•

•

•

•

•

•

•

•
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

19 

• Shipping from depots. 

The ILSP should address: 

• The plan for ensuring that PHS&T aspects of logistics operations are considered and 

integrated into engineering design and support subsystem design efforts.

The interaction with the design process is to ensure that end items can be handled with 

standard equipment and that the need for special handling and support equipment is 

minimized.

Specific requirements for responsibilities, surveillance, approvals, facility and equipment and 

personnel certifications, and procedural aspects of the PHS&T functions for Program Critical 

Hardware (PCH). 

Specific requirements for transportation manager training for required DOT and Hazardous 

Shipping Certifications. 

The PHS&T section must address all aspects of PHS&T that are the direct responsibility of 

the hardware developer and must define information, and the plan for providing that 

information, needed by other organizations that have responsibility for PHS&T operations 

during various phases of the life cycle. Examples include but are not limited to:

•

•

•

• Physical contact constraints

Load limits

Shock and vibration constraints 

Environmental constraints (i.e., temperature, humidity, etc.)

Contamination control

Commodity requirements and interfaces (i.e., power, purge gases, etc.) 

Required DOT permits for hazardous and oversized loads. 

Other safety documentation

•

•

•

•

•

•

•

The PHS&T planning and budgeting process should encompass all program life cycle phases and 

address all applicable mission phases including development and test, ground processing 

including assembly and checkout, prelaunch, launch, recovery, in-space and surface destination 

operations, and post-flight turnaround. 

3.2.9 Facilities

The role of facilities in Supportability activities must be considered. This includes facilities for 

storage, supportability activities associated with assembly and checkout as well as prelaunch 

processing, and depot repair. 

The ILSP should address the following: 

• Facilities necessary to enable the performance of supportability functions.

Specific requirements that facilities must meet to properly enable supportability functions 

(e.g., lighting, clean room conditions, temperature, humidity, and utilities such as electrical 

power and pressurized gasses). 

•
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

•

•

20 

Need for auxiliary equipment such as forklifts and cranes. 

Certification processes and requirements (including OEM facilities that are supporting postproduction repair activities).
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

21 

4. Life Cycle Logistics Support: Tightly Coupled Programs

4.1 Life Cycle Logistics Support Roles and Responsibilities3

The Program Manager (PM) is responsible for acquisition and support of the program’s systems 

throughout the program’s life cycle. The PM is also responsible for providing the needed LCLS 

capability to maintain the availability, supportability, and operational capability of a system. 

Emphasis is placed on increasing reliability and reducing the logistics footprint utilizing Systems 

Engineering concepts and providing for effective Product Support. Early in the design process, 

the PM must consider the relationship of supportability requirements to other trade-space 

requirements such as mass, safety, and mission success. Potential supportability requirements 

are discussed in Appendix B. 

Ultimate responsibility for LCLS rests with the Program Manager. The LCLS functions, 

described in subsequent sections of this document, are executed by the Program’s Life Cycle 

Logistics Support Manager. The Program Manager may choose to serve in this role if 

circumstances warrant (e.g. a small program with insufficient funding to support a dedicated 

LCLS Manager) or may designate a dedicated individual to perform this function. Hereafter in 

this document the term Life Cycle Logistics Support Manager (LCLS Manager) will be used to 

designate whoever performs this role. 

The LCLS Manager may establish a staff of LCLS specialists to perform the various LCLS 

functions. The composition of this LCLS team and the required capabilities of the individual 

team members are determined by the LCLS Manager. The size of this team and the required 

team member capabilities may change over the course of the program. 

In most programs the prime contractor will also have a counterpart LCLS team (as will 

subcontractors). The contractor LCLS teams will execute functions defined in the contract. 

Therefore, it is critical that the Program LCLS team participates in defining those specific 

contract requirements to ensure that expected functions are performed by the contractors and that 

necessary LCLS-specific deliverable products are developed by the contractors.

The Project Manager's LCLS responsibilities are analogous to those of the Program Manager but 

deal specifically with the needs of the Project. As such, emphasis is placed on meeting the 

project's specific support and sustainment needs in a manner that is consistent with the approach 

established for the overall program. At the same time, the various subordinate projects within a 

program should play in integral, collaborative role in defining the overall program LCLS 

concepts and approaches. Similarly, the Project Manager may directly oversee the project's 

LCLS activities or may delegate the execution of these activities to a dedicated LCLS Manager.

The purposes of LCLS are to (1) reduce life cycle costs by integrating support considerations 

into system and component design; (2) develop support requirements that are consistently related 

to readiness objectives, to design, and to each other; (3) acquire the required support; and (4) 

 3 Much of this content is derived from CxP 70064 Constellation Program Supportability Plan, and from Boeing 

International Space Station (ISS) Spares Management & Logistics Work Instruction for New Hardware 

Design/Development (Initial Release, March 2012).
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

22 

provide the required support during the operational phase at minimum life cycle cost. In order to 

ensure that the purpose of LCLS is achieved in large complex programs, Programs and 

subordinate Projects have specific, though interrelated, LCLS functions. The table below 

provides one example of how those roles might be distributed. The specific distribution of roles

and responsibilities must be determined uniquely for each Program and its subordinate Projects.

Program Project

Supportability 

Concept 

Development

Develops Supportability concepts 

and strategy -- documented in the 

Supportability Plan

Contributes to development of 

Supportability concepts and strategy

Reviews and validates Project 

supportability concepts documented 

in Project Integrated Logistics 

Support Plans

Develops Project concepts consistent 

with Program Supportability 

concepts -- documented in Project 

Integrated Logistics Support Plans

Supportability 

Requirements

Develops and manages requirements 

for Program requirements 

documents; flows down to Project

Reviews and critiques Program 

requirements 

Reviews System Requirements 

Document (SRD) requirements to 

ensure consistency of the SRD 

requirements with the overall 

program requirements

Develops Project requirements that 

satisfy Program requirements and 

allocates requirements to contractor

Defines and manages the Program 

verification requirements. Performs 

analysis to ensure compliance with 

Project requirements

Performs verification of Project 

requirements

Supportability 

Documentation

Develop supportability 

documentation. Provides 

supportability-related inputs to Level 

II program documentation such as 

operations concepts and Safety, 

Reliability, and Quality Assurance 

(SR&QA) requirements

Develops Project Supportability 

documentation (e.g., ILSP, LSA 

Reports)

Reviews Project ILSP for 

consistency with Program 

Supportability Plan, concepts, and 

strategy

Ensures Project and lower level (as 

appropriate) ILSP is consistent with 

Program Supportability Plan, 

concepts, and strategy

Supportability 

Data

Ensures consistency, as appropriate, 

and establishes the scope, contents, 

format, and guidelines of the LSA 

and LSA Reports, when applicable. 

Documented in appendix to Program 

Supportability Plan. Agrees to 

Project unique tailoring as 

appropriate

Participates in the establishment of 

the scope, contents, format, and 

guidelines of LSA and LSA Reports 

and develops the LSA and LSA 

Reports per established guidelines 

and standards, when applicable. 

Proposes Project unique tailoring

Ensures access to supportability data 

and information and Logistics 

Support Analysis Record (LSAR) 

data via Program data architecture 

system. These deliveries may 

include imagery, CAD models, and 

drawings. Supportability plan will 

address delivery of this source data. 

Program will review Data 

Requirements Documents (DRDs) 

for inclusion of this source data

Incorporates supportability data and 

information into Project information 

management systems and provides 

supportability information via 

Program data architecture system 

(Includes the source data 

deliverables in the DRDs)
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

23 

Program Project

Participates in LSAR reviews, when 

applicable. Produces an integrated 

schedule of reviews. Ensures 

consistency of scope, format, and 

style of LSAR content for maximum 

consistency with end user product 

format

Hosts and supports LSAR reviews; 

responds to reviewer comments and 

implements agreed-to changes; 

delivers corrected LSAR within 

agreed-upon time. Reviews are 

expected to occur at PDR, CDR, and 

L-18 months for first launch of a 

system. Collects, maintains and 

confirms closure of reviewer 

comments

Design 

Reviews

Participates in Project design 

reviews

Leads supportability participation in 

Project design reviews

Assesses Project designs for 

consistency with Program design 

policy for supportability, 

maintainability, and operability

Assesses the system design to ensure 

that supportability, maintainability, 

and operability requirements are 

realized

Provisioning of 

Spares and 

Inventory 

Establishes processes and guidelines 

for provisioning of spares, Program 

considerations of vendor stability, 

and resulting needs for initial 

lifetime buy vs. incremental 

procurement

Participates in the establishment of 

processes and guidelines for 

provisioning of spares, Program 

considerations of vendor stability, 

and resulting needs for initial 

lifetime buy vs. incremental 

procurement. Leads provisioning 

strategy for Project spares and 

unique support equipment 

procurement. Leads Provisioning 

Conference. 

Defines Program LRU/ORU 

selection guidelines including failure 

rates, criticality, packaging, and 

configuration 

Participates in definition of 

LRU/ORU selection guidelines. 

Implements the Program LRU/ORU 

selection criteria to provide program 

consistency for design of 

maintainable items

Manages obsolescence for Program 

common hardware items

Manages obsolescence for Project 

unique hardware

Defines common Source 

Maintenance and Recoverability 

(SM&R) code schema to designate 

reparability and location of repair of 

hardware items

Participates in development of 

SM&R code schema and implement 

SM&R code schema

Develops and implements inventory 

management system including 

program-provided GFE within 

Program Supply Chain

Contributes to development and 

implementation of inventory 

management system
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

24 

4.2 LCLS Program Functions

The following sections provide an overview of the responsibilities and functions of Programlevel logistics support organizations and Project-level logistics support organizations during the 

Formulation and Implementation Phases of tightly coupled programs

4

. The program phases and 

milestones that are mentioned are depicted graphically in Figure 4.X.

Figure 4.X. NASA Tightly Coupled Program Life Cycle (from NPR 7120.5E, Figure 2-3) 

 4 Per Appendix A of NPR 7120.5E, "tightly coupled programs" are " Programs with multiple projects that execute 

portions of a mission(s). No single project is capable of implementing a complete mission. Typically, multiple 

NASA Centers contribute to the program. Individual projects may be managed at different Centers. The program 

may also include other agency or international partner contributions."
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

25 

4.2.1 Formulation Phase

Program Support Objectives. At the earliest stages of a Program the Program's LCLS team 

should define the Program's life cycle support objectives. These objectives may include:

• Minimizing total life cycle support cost

Achieving specified operational availability levels

Supporting specified launch schedules 

Supporting the attainment of specified values of crew safety and mission success

•

•

•

The LCLS team must work with Program Management, Systems Engineering, Design 

Engineering, Safety, Reliability, and Operations to understand the Program's needs and 

objectives and to make sure that these other functional organizations understand that LCLS plays

an integral role in achieving these objectives.

Program Support Concept. Almost simultaneously with the definition of the LCLS objectives, 

the LCLS team must begin development of the support concept that will allow the achievement 

of these objectives. The support concept must be consistent with the Concept of Operations. In 

fact, in many cases the support concept will be an integral part of the Concept of Operations. As 

a result, the LCLS team must work closely with other disciplines in the development of these 

concepts. Without external constraints this would be a simple matter. However, there are 

always constraints that must be accommodated. Some constraints are absolute and fixed. Others 

may be negotiable and adjustable through various trade-offs. The LCLS team must develop a 

support concept that is achievable within the boundaries established by the constraints. 

However, they should freely challenge constraints that are identified to determine whether they 

are truly fixed or adjustable. Examples of relevant constraints include:

• Budget limitations

Inherent system reliability and redundancy

Mass and volume capacity for in-flight spares and other logistics-related equipment and 

supplies 

Crew time available to perform life cycle support functions

Crew capabilities

Resupply opportunities 

Failed hardware return opportunities 

Other operational concepts 

•

•

•

•

•

•

•

In addition to the primary focus on achieving the program objectives and support objectives, the 

support concept should also define the relative roles of Government personnel and contractor 

personnel in the execution of the concept. The appropriate assignment of roles may be different 

for various projects within a program. The Program LCLS team should define the role 

assignments at the Program level and what role assignments are acceptable - or what role 

assignments are not acceptable - at the Project level. With this guidance, the individual projects 

can select the approach that best meets their needs. It should be noted that these roles may shift 

over the course of the life cycle. If this is anticipated, it should be captured in the definition of 

the support concept. 
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

26 

Program Support Requirements. Once a support concept is defined, the LCLS team must 

develop technical requirements and programmatic requirements that will ensure that the system 

is designed so that it can be supported according to the support concept and that the 

infrastructure necessary to support the system will be established. Development of the technical 

requirements is, effectively, the beginning of the Design Interface element. These requirements 

must be developed collaboratively with the other functional areas to ensure that related and 

supporting requirement are compatible and that no conflicting requirements are introduced. 

These requirements must be developed by the time of the System Requirements Review (SRR).

The Program-level LCLS team is responsible for the process of allocating support requirements 

to subordinate projects for inclusion in their requirements sets. In the allocation process the 

Program-level LCLS team determines which Program-level support requirements are applicable 

to each project and, working collaboratively with the Project-specific LCLS teams, crafts 

applicable requirements statements specific to each project. In cases where a Program 

requirement specifies a summary quantity (e.g. total in-flight spares mass) that must be divided 

or distributed among two or more projects, the Program-level LCLS team leads the process of 

distribution in collaboration with the relevant projects.

From the SRR to the PDR, the LCLS team must work closely with the design team to make sure 

that the system hardware detailed design complies with the LCLS-related technical requirements 

that were baselined at the SRR. Additionally, the LCLS team must work closely with the 

designers to find design solutions that facilitate system maintenance in all operational 

environments (both during a mission and before launch) and consider total life cycle cost. A 

range of potential design solutions may be compliant with requirements but some might be more 

desirable than others. For example although a specific design may meet the technical 

performance requirements established for the specific system it may result in significantly 

greater life cycle support costs than alternative designs. 

Program Support Integration. In Programs that include multiple projects the Program-level 

LCLS team plays a critical role in coordinating with all projects to make sure that the Projects 

develop support concepts and requirements that do not conflict with each other and that the total 

resources required for complying with the concepts and requirements do not exceed those 

available to the Program as a whole.

The Program-level LCLS team also coordinates common needs and activities of LCLS functions 

and LCLS teams across the program. This includes:

• Working with projects to define roles and responsibilities at points of functional intersection5

Developing a common LCN scheme for use by all projects

Establishing tools and mechanisms to enable the implementation of commonality across 

designs from different projects 

Facilitating common or consolidated procurements

Facilitating the establishment of common or consolidated support facilities and other 

capabilities

•

•

•

•

 4 This refers to periods when hardware from two projects are physically integrated or when hardware form one 

project is located at another project's primary geographic location.
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

27 

Program Integrated Logistics Support Plan. During the period from SRR to PDR the LCLS 

team must develop the Program's Integrated Logistics Support Plan (ILSP) as discussed in 

Section 3. This document will be baselined at, or before, PDR. The ILSP defines the LCLS 

strategy that will be utilized in implementing the LCLS concept to meet LCLS objectives. The 

ILSP defines how the Program will address each of the LCLS elements through each phase of 

the Program. This should include the technical approaches as well as organizational aspects. 

Organizational aspects address the relative role of Program and Project LCLS organizations and 

the relative roles of Government and contractor LCLS teams. The ILSP is updated at subsequent 

Program milestones as appropriate. 

4.2.2 Implementation Phase 

During the Implementation phase of a tightly-coupled program the Program-level LCLS team 

provides information to the Program Manager on the status of overall LCLS efforts across the 

program. This includes: 

• Schedule and budget status of all LCLS activities.

Projected life cycle sustainment costs (e.g. spares, repairs, manpower).

LCLS-related risks to the Program such as unanticipated costs, supplier/vendor viability 

issues, and increases in mass or volume requirements for flight spares to meet availability 

requirements. 

•

•

The Program-level LCLS team performs an overall integration function to ensure that all Project 

LCLS team activities are consistent with the Program's LCLS objectives and implementation and 

with other Project LCLS efforts. At the same time, it is not necessary for the Program-level team 

to serve as an intermediary in all Project-to-Project LCLS activities - although they should 

maintain awareness of these interactions. Additionally, the Program-level LCLS team 

establishes and maintains LCLS infrastructure used by all of the Projects - such as LCLS data 

management systems, common depot repair facilities, and other facilities and capabilities that 

may be used by multiple Projects.

During the course of a Program it may become necessary to update operational concepts and 

associated system support concepts. The Program-level LCLS team updates the Program 

support concept as necessary when conditions require. 

The Program-level LCLS team ensures that processes are in place to monitor contractor viability 

throughout the supply chain. The processes should be implemented at the level at which 

Government contracts are established (i.e. at the Program level or the Project level). The relative 

roles of the Government and prime contractors in supply chain monitoring processes may vary 

depending upon the capabilities of the prime contractors. Therefore this function may be 

executed differently for the various subordinate projects. The topic of allocation of roles and 

responsibilities between the Government and the contractors in this area is addressed in much 

greater detail in Appendix X (this app is the LMI report). 
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

28 

4.3 Project Functions

The figure below is for individual projects. 

NASA Project Life Cycle (NPR 7120.5E, Figure 2-5) 

4.3.1 Formulation Phase

4.3.1.1 Pre-Phase A: Concept Studies

4.3.1.1.1 Technical Activities

LCLS Strategy. Develop a preliminary LCLS strategy for each life cycle phase, consistent with 

the Program support concept, to serve as the basis for estimating life cycle costs associated 

with LCLS, development of schedule baselines, and to serve as the basis for developing 
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

29 

associated programmatic and technical requirements. This preliminary support strategy may 

be documented in the MCR briefing package. 

The support concept should be defined such that it complements the overall mission architecture 

and Concept of Operations (ConOps). It should consider both ground operations and flight 

operations. Fundamental issues to consider for in-flight support include mission duration, 

system fault tolerance, inherent reliability, mass and volume capacity for spares, resupply 

opportunities, and crew time constraints. Additional considerations include defining appropriate 

levels of maintenance for in-flight operations and the potential benefits of system hardware 

commonality for reducing total spares requirements.

The LCLS team must develop a concept that is achievable within the boundaries established by 

existing constraints. Examples of relevant constraints include:

• Budget limitations

Inherent system reliability and redundancy

Mass and volume capacity for in-flight spares and other logistics-related equipment and 

supplies 

Crew time limitations

Crew capabilities

Resupply opportunities 

Failed hardware return opportunities 

Other operational concepts 

• 

• 

• 

• 

• 

• 

• 

Ground operations considerations should include both direct support of flight hardware and 

support of launch systems and other associated ground facilities. In the former case, the 

potential for flight hardware repair and refurbishment will lead to decisions about where these 

operations would be performed (e.g. at the launch pad, in hardware integration facilities, or in 

depot-level repair facilities - either on-site or remote) and whether they are performed directly by 

Government personnel or by contractors. 

Requirements Development. Requirements development begins in Pre-Phase A after 

Authorization to Proceed (ATP) and continues through the System Requirement Review (SRR) 

in Phase A. The LCLS goals during this phase are to influence the design for supportability 

through logistics requirements definition. 

The LCLS team develops preliminary LCLS requirements to be included in project management 

requirements and technical requirements. The support requirements must be must be developed 

in the context of the support concept and the larger Concept of Operations. Requirements may 

include life cycle cost, operational availability, constraints on in-flight spares mass and volume, 

design to specific accessibility demands, design to specific sets of tools and other support 

equipment that will be available, or others specific to the needs of the project. The objective of 

the requirements is to ensure that the hardware systems are designed so the support concept can 

be implemented. All support requirements should be clearly related to the achievement of 

program and project objectives and minimization of life cycle cost.

Minimizing LCC must be one of the primary objectives during development of requirements and 

during review of the concept of operations, specifications, drawings and other documents. These 
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

30 

documents will be canvassed to identify cost drivers for further scrutiny. Supportability cost 

drivers will be identified to the project team and the appropriate function (e.g. design 

engineering) so these cost drivers can be addressed and eliminated or at least minimized. Trade 

studies will be monitored and the LCLS team will use a tailored LCC tool (Refer to Appendix X, 

) to assess trade options and identify the most supportable option with the lowest life cycle cost. 

The LCLS team begins initial supportability assessments, ensures that supportability 

requirements and recommendations are considered in initial design activities, and that 

supportability constraints are addressed. The LCLS team continuously reviews the hardware 

architecture as it develops to identify and refine the maintenance concept for each hardware item. 

Not all parameters will be known at this early stage of project development so assumptions must 

be made and documented. Initial results will provide a Figure-of-Merit comparison between 

trade options and identify an anticipated life cycle cost for each option. Logistics 

recommendations will be presented to the project team so they can be addressed. Significant 

supportability LCC concerns should be identified as project risk - resulting in their inclusion on a 

watch list - and a risk mitigation plan developed. This process will be repeated throughout the

design cycle as the design matures and may result in periodic re-assessment of the LCC to refine 

the relative figure-of-merit cost of each option.

4.3.1.1.2 Milestone Reviews

Mission Concept Review (MCR). At the time of the MCR initial LCLS concepts should be 

available for review by all interested program participants. The LCLS team should also 

participate in the review of other plan and concepts that are available to ensure that there are not 

conflicts and that all concepts are consistent and supportive.

4.3.1.1.3 Organizational Activities

An important aspect of the support concept is definition of the roles and responsibilities of the 

participating parties. These parties may include government organizations (e.g. the Program 

Office, Project Office, line organizations of NASA field centers), the development contractor(s), 

and sustaining operations contractors - if applicable. It is also important to keep in mind that the 

roles of the participants may change and evolve over the course of the program/project life cycle. 

Early definition of these roles and responsibilities throughout the life cycle is important since the 

associated costs can be a significant component of the total life cycle sustainment cost. During 

the Concept Studies Phase the LCLS management should define expectations for contractor 

involvement since this can be a significant factor in contractors' proposals and the total projected 

Project cost.
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

31 

4.3.1.2 Phase A: Concept and Technology Development

4.3.1.2.1 Technical Activities 

Requirements Development. The process of defining end item support requirements and 

operational constraints continues as the design evolves. Project LCLS personnel should work 

closely with the corresponding Program LCLS personnel to ensure appropriate flowdown 

through the allocation process of LCLS requirements to the project. The logistics requirements 

for a particular system or piece(s) of hardware are significantly influenced by the system design 

(particularly the inherent reliability and maintainability of the design) and by the maintenance 

concept (e.g., repair by component replacement, repair in-situ, off-equipment repair in a depot 

facility, etc.). The appropriate trade-off decisions can be most effectively made early during 

concept development and design. Development of requirements should be completed by the 

SRR. Examples of LCLS requirements are included in Appendix B.

The LCLS team should maintain continuous awareness of all requirements as they are developed 

and matured since many requirements that are not "owned" by the LCLS team may have a 

significant influence on the LCLS concept and LCLS requirements. The LCLS team should 

actively engage with other discipline teams to address potential conflicts and impacts to arrive at 

a set of requirements that provides the best overall solution for the program or project. 

4.3.1.2.2 Milestone Reviews

Two milestone reviews occur during Phase A. These are the System Requirements Review 

(SRR) and the System Definition Review (SDR). These reviews and the role of the LCLS team 

in the reviews are discussed in the following sections.

System Requirements Review (SRR). The objective of this review is to ascertain the adequacy 

of the project's system requirements - including LCLS requirements. In addition, the LCLS team 

should perform an overall assessment of the project from the LCLS perspective. 

Specific life cycle logistics success criteria to be considered at SRR:

1. Have requirements for reliability, availability, commonality, maintainability, transportability, 

and standardization been identified? 

2. Are the requirements verifiable?

3. Have Logistics / Supportability and non-Logistics Requirements Been Accepted by the 

Project / Design?

4. Have Trade Studies / Analyses Included Supportability Requirements / Constraints?
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

32 

5. Has crew time for maintenance been predicted / identified?

6. Have opportunities to reduce logistics resource footprint been identified? 

7. Has system life cycle cost been estimated and have opportunities to reduce it been identified?

System Definition Review (SDR). The primary product provided by the LCLS for the SDR is 

the Preliminary ILSP. This document should be as complete as possible to allow all interested 

parties to review and comment on initial LCLS concepts and plans. It is of very limited value if 

it consists only of section titles and generic content. This is only a preliminary version so it 

should be expected that it will change significantly before it is baselined during the period 

leading up to the PDR. 

The LCLS team should actively participate in the SDR process - beyond just providing the 

preliminary ILSP. They should closely monitor concepts for system design as they develop to 

ensure that the support concept remains valid and that no unsupportable system concepts are 

introduced. Ideally, any issues will be identified and resolved during the daily course of 

business. Any remaining unresolved issues must be raised during the SDR comment and 

resolution process. 

4.3.1.2.3. Organizational Activities

LCLS Team. During this phase the LCLS manager should define the staffing requirements for 

the LCLS team. This includes defining functions to be performed by the team, the number of 

personnel required to perform these functions, and the schedule for when the personnel must be 

available. Staffing needs may change over the life of a project.

Contractor Interface. During this phase the LCLS relationship with the primary contractors 

should be clearly defined and implemented through contractual mechanisms. The roles, 

responsibilities, and functions of the contractors during the design, development, and operational 

periods of the project should be clearly defined. All data and other deliverables (both content 

and delivery schedule) required by the Government LCLS team from the contractors should be 

identified in detail and defined in the contract. 

4.3.1.3 Phase B: Preliminary Design & Technology Completion

4.3.1.3.1 Technical Activities

The design development phase begins after SDR and continues through successive design 

reviews until the final design is accepted for production. The goal of the LCLS effort is to 

complete supportability assessments and assure that supportability recommendations / solutions 

are considered and implemented into the design. The LCLS team will begin this process by 

having a thorough understanding of the specification requirements and helping the Project Team 

to ensure the requirements are consistent with the Concept of Operations. The LCLS team will 

review the hardware architecture as it matures and develop or refine the maintenance concept for 

each hardware item. As the Project progresses, the LCLS team will use the maintenance concept 

as the basis for development of plans and outputs that optimize supportability of the Project 

hardware at the least life cycle cost.
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

33 

ILSP. The ILSP should be finalized and formally baselined by PDR. During this phase the 

project LCLS team begins execution of the activities defined in the ILSP. Even prior to the 

official baselining of the ILSP, it is necessary that activities defined therein be initiated.

Design Support - Influencing Design to Reduce Life Cycle Cost. The LCLS team will 

continue to assess cost drivers as the design is refined. Several iterations of the Life Cycle Cost 

(LCC) assessment will be performed during the design phases of the projects. LCC assessments 

can also be used to support design trades. LCC results will be updated as required during 

development phases. 

Additionally, the processes used to identify candidates for in-flight Organizational-level 

maintenance and in-flight Intermediate-level maintenance (discussed further in following 

paragraphs) generate outputs that can identify opportunities for hardware redesign that may 

result in reduced cost for spares and reduced mass and volume demand for in-flight spares. 

As the system design is maturing the LCLS team must maintain continuous awareness of the 

system architecture and the components of which it is comprised. The LCLS team should 

engage with the designers when they identify situations where design modifications or 

alternative design solutions could enhance the supportability of the system and reduce total life 

cycle cost.

Maintenance Concept and Planning. For flight systems the LCLS team should begin 

identifying the preferred maintenance approach for each hardware item. Is the item an ORU and, 

thus, must be removed and replaced in its entirety? Is there an opportunity to repair the item 

during the mission - thus creating an opportunity for Intermediate-level maintenance? Must

maintenance actions be performed in situ? Examples would be replacement of connectors and 

repair of structure. Examples of the processes used to identify candidates for in-flight 

Organizational-level maintenance and in-flight Intermediate-level maintenance are included in 

Appendix ZZZZ. Consideration must also be given to requirements for preventive maintenance 

actions and servicing activities. All of these possibilities lead to determination and acquisition of 

required spares and replacement parts, materials, tools, support and test equipment, and 

maintenance procedures. 

For hardware items that fail during a mission, consideration should be given to whether it is 

possible and desirable to return them to the ground for repair and reuse. This is an unlikely 

possibility for missions other than Earth-orbital missions. However, when this is an option, 

plans must be defined for performing the repairs after the return of the failed items. Will this be 

done in a Government facility or will it be done in the facility of the OEM that produced the 

item? In either case, advance planning is required to establish the capability. 

The following are the key factors that need to be addressed in developing a Preliminary 

Hardware Ground Maintenance Approach and Recommendation:

• ORU/LRU Cost

Historical Cost to repair for same or similar HW (if applicable)

Repair frequency estimates for same or similar equipment (MTBF estimates if available)

Remaining life of the program or project (baselined and extended Program life durations 

being considered) 

Lifetime Buy of Spares (cost)

• 

• 

• 

• 
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

34 

• Level of HW failure Testing and Diagnosing required/desired: 

 ORU Level

Sub-ORU

Component Level





• Level of HW repair required/desired: 

 ORU Level

Sub-ORU

Component Level





• Depots/OEMs that can perform the work 

Skills required to perform Ground Repairs 

Procedures required to perform Ground Repair (cost) 

Certifications Required to perform Ground Repair (certification process and cost) 

Available Test Equipment and Tooling

Special Test Equipment (STE) or Tooling required (including identifying the cost of 

equipment not available) 

List of material(s) required to support Ground Repairs 

• 

• 

• 

• 

• 

• 

Additional analyses and trade studies to be completed include:

• Trade of Lifetime Spare buy vs. Estimated Cost to Repair for Program life (Repair costs to 

include cost of STE, Retention Contract, estimated Repair costs for ORUs, parts and SRU 

inventory, OEM/Depot Certification, Transfer of equipment, estimated TT&E costs and any 

other relevant repair costs). 

Repair and Retention Cost Trades for OEMs/Depots which could perform the work (Repair 

costs to include cost of STE, Retention Contract, estimated Repair costs for ORUs, parts and 

SRU inventory, OEM/Depot Certification, Transfer of equipment, estimated TT&E costs and 

any other relevant repair costs).

•

Supply Support. During this phase the LCLS team should determine their approach to 

acquisition of spares - the Supply Support element of LCLS. Will they purchase sufficient 

spares produced in conjunction with initial production (Spares Acquisition with Initial 

Production - or SAIP) to meet the projects needs for the duration of its service life or will they 

acquire spares throughout the life of the project. If the former, how will they deal with possible 

redesign of items for which they have already procured spares? How will they respond if failure 

rates are greater than expected and additional spares are needed in the future? These are the 

types of issues that must be considered and for which a clearly articulated strategy must be

developed. Various potential provisioning strategies are detailed in section 3.2.3.

Packaging, Handling, Storage and Transportation (PHS&T). The LCLS team should begin 

developing a PHS&T plan to support project hardware. Factors to consider include schedule 

constraints, potential transportation modes, and cost. 

The LCLS team should also begin performing a detailed PHS&T assessment of project 

hardware. Each item that will be shipped or stored should individually undergo a PHS&T 

assessment. The objective of the PHS&T process is to protect hardware items from damage 

and/or deterioration due to shock, vibration, thermal, vacuum, and other environmental 

conditions under nominal transportation and ground storage conditions. This assessment must

consider transportation constraints arising from inherent characteristics of the hardware such as 
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

35 

size, mass, sensitivity to environmental factors (e.g. shock, vibration, temperature) and 

hazardous materials. An example of a PHS&T checklist is provided in Appendix F.

Logistics Information Management. The LCLS team must establish the processes and 

capabilities that will be necessary to manage and control the various LCLS functions that will be 

implemented. This includes management of large quantities of information and data about the 

hardware that is necessary to enable execution of the planned logistics-related functions.

4.3.1.3.2 Milestone Reviews

Preliminary Design Review (PDR). The PDR demonstrates that the preliminary design meets 

all system requirements with acceptable risk, within cost and schedule constraints, and 

establishes the basis for proceeding with detailed design. It confirms that the correct design 

option has been selected, interfaces have been identified, and verification methods have been 

described. Full baseline cost and schedules, as well as risk assessments, management systems, 

and metrics are presented. The LCLS team plays an active role in the PDR.

Typical LCLS-related PDR success criteria include affirmative answers to the following exit 

questions: 

• Can the preliminary design, as disclosed, satisfy the draft logistics / supportability 

requirements? 

Have all opportunities for minimizing total life cycle cost been implemented?

Have long-lead items and key supply chain elements been identified?

•

•

The LCLS team provides the outputs listed below for the PDR. The intent is for the Project 

Team to review these outputs and accept them as part of the Project planning baseline. At this 

Phase, these outputs are consistent with the level of detail in the hardware design. They should 

have enough detail so that the Project Team has a good understanding of how the hardware will 

be supported, and the size / cost of the infrastructure that will be required.

• Recommended Design Changes / Considerations 

Preliminary Maintenance Concept 

Preliminary Levels Of Repair

Life Cycle Cost (LCC) Update 

Preliminary Hardware Ground Maintenance Approach Options and Recommendations

Performance Schedule 

Initial Functional Availability Assessment

Initial Spare Parts List 

Initial PHS&T Requirements and Plans

•

•

•

•

•

•

•

•

Supportability-related data needed for development of LCLS outputs include: 

• Design Safety

o Hazard Analyses

o Failure Modes Effects Analysis (FMEA)
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

36 

o Margins of safety between functional requirements and design provisions.

• Design Reliability

o Sources of failure rate data including predicted failure rates and duty cycles.

Reliability prediction methods.

Parts or components that have a critical life limit or require special consideration.

o

o

• Design Maintainability

o Preventive maintenance schedules.

Accessibility, testability, and ease of maintenance.

Provisions for diagnosing cause of failure and means for localizing the failure.

Degree to which the system has been optimized from a maintenance and maintainability 

viewpoint in order to ensure that the system is supportable utilizing the approved 

maintenance concept.

o

o

o

• System Availability / Supportability requirements

Assessment of adequacy of allocations (e.g., mass and volume for spares, tools, and test 

equipment; crew time required to perform maintenance, etc.) to meet availability / 

supportability requirements and provide an operational margin to deal with unanticipated 

failures while ensuring crew safety and mission success.

•

4.3.1.3.3 Organizational Activities

LCLS Team Collaboration. During Phase B the Government LCLS team and the contractor(s) 

LCLS teams should maintain a collaborative relationship. However, it is important that the 

Government team respects the need for the contractor team to implement the responsibilities 

defined in their contract without interference.

Supplier Viability Monitoring. An important issue to be addressed is the process for 

monitoring supplier viability to provide early awareness of supplier problems that could pose a 

threat to the project. A variety of approaches are possible. The choice of the preferred approach 

will largely be based on the maturity and capabilities of the primary contractor. This is detailed 

further in Appendix A. 

4.3.1.4 Phase C: Final Design & Fabrication

4.3.1.4.1 Technical Activities

Much of the technical activity during this phase is a continuation of that begun in previous 

phases. As the system's hardware design matures, new items are incorporated into the design 

and previously identified items become better understood and associated data and information is 

more complete.

Maintenance Concept and Planning. The LCLS team will refine the maintenance concept and 

repair levels as more data become available and as the design becomes more defined. The 

documented initial maintenance concept / repair levels will be updated. Also, the Preliminary 

Hardware Ground Maintenance Approach and Recommendation will be updated as new, more 

detailed information becomes available. This assessment will compare the OEMs / Depots 

capable of performing the required repair work (and address technical capabilities and projected 

costs); and, the Recommendation will identify the OEM/Depot selected for the repair work and 
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

37 

shall be the result of engaging participants with a vested interest (“stakeholders”) in a series of 

collaborative working group meetings.

Logistics Support Analysis. Logistics Support Analysis is initiated as early as possible in the 

design / development cycle and documented in the Logistics Support Analysis Record (LSAR). 

The process is iterative and the fidelity is consistent with the maturity of the design and release 

of the source data available. The methodology for performing the analysis is defined in: 

AeroSpace and Defense Industries Association of Europe (ASD) S3000L, 

International Procedure Specification for Logistics Support Analysis (available at 

http://www.asd-stan.org/s3000L.html). 

The specifications for documenting the LSA in the LSAR are contained in: 

Government Electronics Industry Association (GEIA) GEIA-STD-0007, Logistics 

Product Data (available at https://standards.nasa.gov).

Illustrated Parts Breakdown (IPB) Drawings. Once the hardware designs are completed and 

the Maintenance Task Analysis has been completed as part of the LSA, IPBs can be prepared. 

The IPBs are isometric drawings that illustrate components and key interfaces relevant to 

maintenance procedures. Generally, these will be produced by the contractor organization - and 

thus must be specified as a required deliverable.

4.3.1.4.2 Milestone Reviews

Critical Design Review (CDR). The CDR is the only milestone review during this phase. The 

LCLS team provides the products listed below for the CDR. It is intended that the Project Team 

will review these and accept them as part of the Project planning baseline. These outputs are 

consistent with the level of detail in the hardware design. They should have enough detail so that 

the Project Team has a full understanding of how the hardware will be supported, and the size / 

cost of the infrastructure that will be required.

• Maintenance Concept / Plan (Update from PDR)

Life Cycle Cost (LCC) (Update from PDR) 

Levels Of Repair (Update from PDR) 

Hardware Ground Maintenance Approach / Plan (Update from PDR) 

Functional Availability Assessment (Update from PDR) 

Indentured Parts List 

PHS&T requirements and plans (Update from PDR) 

Pre-production On-Orbit Supportability Data (LSAR/IPB)

Support Equipment Requirements

Facility Requirements

Initial Sparing Assessment

Initial Obsolescence Assessments

•

•

•

•

•

•

•

•

•

•

•

Typical CDR success criteria include affirmative answers to the following exit questions:

• Does the design provide the lowest supportability cost?
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

38 

• Has an integrated logistics assessment been identified and implemented? 

Are long-lead procurement plans in place and has the supply chain been assessed? 

Has LSA documentation been updated to reflect the most current engineering

Is the Level of Repair Analysis (LORA) complete or is an update required? 

•

•

•

4.3.1.4.3 Organizational Activities

The LCLS team should ensure that processes are in place for acquisition of spares and other 

materials, that plans for depot maintenance operations are defined and implemented, that all 

deliverables required from the contractor(s) are on schedule and of adequate quality. Team 

members should begin shifting their focus from development activities to operations. They 

should be working closely with their contractor counterparts to ensure that they are prepared to 

transition to the operational phase f the project.

4.3.1.5 Pre-Delivery Phase (Through DD250) (Phase D)

The primary objective of the Pre-Delivery Phase is to finalize and complete assembly, 

integration, test; closeout documentation; verify that project requirements have been met; and 

deliver production units. The contractor LCLS team may be required to support the system 

during these processes. An additional logistics objective of this phase is to ensure logistics 

elements are in place to support end-items (establish interim support provisions, as necessary).

Physical Configuration Audit (PCA). During this phase, the Physical Configuration Audit 

(PCA) is completed. The PCA is a technical examination of the designated system design 

configuration to verify that the physical, “as is” product conforms to all the technical 

documentation that describes it. The PCA is typically conducted on the first production article. 

After successful completion of the physical evaluation of the product design, the product 

baseline is frozen and all subsequent product changes should be incorporated only through the 

formal change board process. The PCA involves a detailed evaluation of the product technical 

documentation, engineering drawings, specifications, and parts listings that are utilized in the 

operation and logistical support of the product to verify that these documents accurately describe 

the “as is” product.

LCLS Output for the Pre-Delivery Phase (DD250). The LCLS team provides the updated / 

final outputs listed below prior to DD250. The intent is for the Project Team to review these 

outputs, and after review accept these as part of the Project completion baseline. At this Phase, 

these outputs support manufacturing and operations. Post DD-250 infrastructure should be fully 

defined, and in place to the extent necessary to support initial activation and sustaining 

operations.

• Maintenance Concept / Plan (Update from CDR) 

Hardware Ground Maintenance Baseline / Plan (Update from CDR)

Functional Availability Assessment (Update from CDR)

Parts List (Update from CDR) 

Final PHS&T requirements and plans (Update from CDR) 

Obsolescence Assessments (Update from CDR)

•

•

•

•

•
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

39 

• Requirements Closure 

• Baselined LSAR / IPB & Validation Records 

Conduct LSAR / IPB Reviews. The LCLS team reviews the LSAR and IPB provided by the 

contractor to ensure that the products meet the quality standards of the end user. This review is 

performed in conjunction with the NASA and contractor Subject Matter Experts (SME) within 

the contractor and/or NASA Engineering systems team, Safety, and subcontractor organizations.

Finalize LSAR / IPB Documentation. The finalization of the LSAR / IPB documentation is 

contingent on two major factors; 1) The release of required source data (drawings, imagery, test 

reports, fitchecks, etc) where initial analyses can be completed, and 2) The review and 

acceptance of the products by the NASA customer. The NASA customer accepts the 

maintenance data, which is the combination of the LSAR and IPB, by signing a Validation 

record. All participants in the external review sign the Validation record, which defines the 

ORUs and / or SRUs with their applicable maintenance tasks along with the IPB. The Validation 

Record can be signed with comments (open issues) so that the TD&D can be delivered to MOD 

for immediate utilization (source data for SODF development). 

Finalize Imagery. Available imagery is referenced within the LSAR as part of the RD&D. The 

imagery is documented and referenced to specific maintenance tasks in order to provide the 

crewmembers performing maintenance on-orbit any information that may help during those 

activities. Specific images are collected and maintained by the ISS program Imagery Working 

Group (IWG). 

Finalize PHS&T Planning. The initial PHS&T document is evaluated for updates at CDR-30 

days and submitted for final integration into the Logistics Supportability Analysis Record.

Finalize On-Orbit Maintenance Plan. The LCLS team performs on-orbit maintenance 

planning and manifesting in coordination with traffic models. This is in support of preventive 

maintenance and limited life requirements, resupply of consumable hardware, and return or 

disposal of hardware. 

Baseline Hardware Ground Maintenance Approach. The Product Support Depot 

Maintenance and Repair (DM&R) function is responsible for developing the Baseline Hardware 

(HW) Ground Maintenance Approach and Recommendation. This final HW Ground 

Maintenance Approach and Recommendation will be complete and comprehensive. The 

Recommendation shall be the result of engaging participants with a vested interest 

(“stakeholders”) in a series of collaborative working group meetings. The Recommendation shall 

also identify forward work to be completed if there are any “open items”, and contain a list of 

mutually agreed upon and “accepted” action items and completion dates.

Baseline Sparing Assessment. Determine the range and depth of spares needed to support the 

confidence levels defined in the Functional Availability Assessment. In addition, the Repair 

Level Analysis (RLA) results and the development of the maintenance concept are used to 

determine what level of sparing is required to support repairable vs. non-repairable philosophy. 

Develop Indentured Parts List (IPL). The development of an Indentured Parts List (IPL) is 

needed to breakdown the various levels of indenture which supports in the determination of what 
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

40 

parts are mapped to what sub-assembly. To the extent possible, the source control drawings for 

all parts will be broken down to the lowest possible level, identifying the true manufacturers’ 

generic part number. This will enable the Program to promptly identify obsolescence concerns, 

as well provide a record of single source suppliers.

Update Obsolescence Screening. Once developed, the IPL will be loaded into the obsolescence 

database and the data screened for any issues. A comprehensive obsolescence assessment will be 

performed with a goal of identifying any parts that have become obsolete during the design and 

build of the hardware. Additionally, parts that are nearing the end of their life cycle will be 

identified. 

Update Functional Availability Assessment. If there have been any changes to reliability data, 

spares data, or function or ORU confidence or POS target, then repeat simulations outlined in 

section 8.8 as needed to update results. 

Hardware Development Phases and Product Support Activities

SRR PDR CDR

Requirements 

Development Phase

Affect Design Influence

Critical 

Design 

Phase

ORU / SRU Candidates

Maintenance Concept to include Levels of Repair ( LORA) 

Establish and Verify Logistics Requirements

Develop and Deliver LSAR / IPB

Develop and Refine LCC Assessment

 Develop and Deliver Supply Support 

CR 

Impact

Pre-Delivery 

Phase

Preliminary 

Design

Phase

DD250
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

41 

TASK SUMMARY OUTPUT Requirements 

Development Phase

Preliminary 

Design Phase

Critical Design 

Phase

Pre- Delivery 

Phase

Set of Requirements X

Trade Study Findings X

LCC Assessment X X X

Recommended Design 

Changes/Considerations

X X X 

Functional Availability Targets / 

Assessments X X X 

RIDS/RID Closures X X X X

Maintenance Concept X X X

Repair Levels X X

Ground Hardware Maint. 

Approach/Plan

X X X 

Performance Schedule X X

Parts List/IPL X X X

PHS&T X X X

Pre-Production On-Orbit 

Supportability Data

X X 

Support Equip. Requirements X X

Facilities Requirements X X

Sparing Assessments X X

Obsolescence Assessments X X

Requirements Closure X

LSAR/IPB & Validation Records X

Figure 4-1 – Hardware Development Phases and Product Support Activities.

(Logistics Outputs are in no particular order) 

4.3.1.6 Phase E: Operations & Sustainment

During the Operations and Sustainment Phase the LCLS team implements the processes 

defined in the ILSP. Key activities include ongoing supply support efforts, overseeing 

depot maintenance operations, integrating with other project organizations to manifest 

spares for on-orbit systems, supporting in-flight maintenance, gathering performance data 

on operational systems to enable refined projections of logistics support resource needs, 

and implementing the ILS process for new hardware and systems.

 
NASA LIFE CYCLE LOGISTICS SUPPORT GUIDEBOOK

42 

4.3.1.7 Phase F: Closeout

When a project comes to the end of its life cycle, the LCLS team must support 

decommissioning and property disposal activities. Participation by the LCLS team is 

essential to ensuring that the proper disposal sequence is followed to be sure that items 

are not disposed of prematurely. The team can also be instrumental in helping to identify 

potential alternative uses for project hardware by other programs and projects.
1 

APPENDIX A: Supplier Viability Risk Management6

NASA Role in Supplier Risk Management. NASA has a mixture of programs that are 

managed by either NASA or a prime contractor. It is inevitable that NASA and its various prime 

contractors will have different approaches to supplier risk management and even different 

capabilities. Further, NASA’s primes may have supply management programs at different stages 

of development.

As such, NASA has three basic program structures: 

• Programs led by a prime contractor with a well-developed supplier management program, 

which we will define as a “mature prime”

Programs led by a prime contractor without a well-developed supplier management program, 

which we will define as a “novice prime”

Programs led by NASA. 

•

•

Being classified as “mature” does not mean a contractor has been in existence for a long time or 

has experience with large number of contracts. The classification is solely defined by the 

development and reliability of the contractor’s supplier management program.

 

The three basic program structures are important, because the approach to managing supplier 

viability and risk changes depends on the structure, as shown in Figure 3-1. 

Figure A-1. Risk Management by Program Management Type 

Mature 

Prime Novice Prime NASA Prime

NASA Role Monitor Mentor Manage 

Risk 

Management 

Responsibility

Prime Prime NASA

Level of 

NASA 

Involvement

Low Moderate High

A prime contractor has responsibility for supplier risk, since it holds the supplier contracts. The 

contractor may operate its own supplier risk management processes, but it must be able to 

provide NASA with the specific reports and metrics it requires. When the prime contractor is a 

novice prime (i.e., the contractor does not have a well-developed supplier management program), 

NASA should take more control over the monitoring of supplier viability to supplement the 

 6 The material in this Appendix is adapted directly from LMI Report NS106TI, Strategies for Mitigating NASA's 

Supplier Viability Risk, produced under contract.
prime contractor’s capabilities. Naturally, if NASA is the prime integrator for a program, then 

NASA must take full responsibility for supplier viability management.

Depth of Risk Mitigation. A common concern for a supplier risk management program is 

determining how deeply to monitor and mitigate supplier risk within the supply chain. Maximum 

risk mitigation would lead programs to engage with suppliers as deeply as possible within the 

supply chain; however, constraints stemming from privity of contract and program office 

resources will limit the feasible depth of engagement.

The challenge is that critical suppliers may be two, three, or more tiers into the supply chain, and 

NASA and its prime contractors may not have the ability to influence suppliers at that level. In 

addition, the number of suppliers can grow exponentially at each succeeding tier within the 

supply chain, thus creating severe workload limitations.

These limitations make it imperative for NASA to prioritize suppliers based on their criticality. 

Risk management resources should be focused on suppliers of critical items, where a disruption 

in the supply can significantly impact the program. 

Management of suppliers deeper in the supply chain should be consistent with the overall risk 

management program in terms of monitoring and mitigation methods, as well as the 

responsibilities for engaging the suppliers. NASA should consider the risk management expertise 

available within the supply chain and work with prime and sub-tier suppliers to ensure that risk is 

sufficiently managed without duplication of effort.

Methodology for Risk Quantification and Mitigation. Supplier viability risk can be defined in 

terms of "consequence" and "likelihood". Risk consequence measures the effect of a particular 

risk. In the case of supplier viability, risk consequence is synonymous with the impact of a 

supplier’s failure on a program. The consequence is directly related to the criticality of the items 

provided by the supplier to the program’s mission. In general, if the loss of supply for an item 

will affect the success of the mission, then the item is critical.

Supplier risk consequences can be assessed based on a decision tree, which considers the criticality 

of the part being supplied and the number of certified suppliers that can provide that part. This 

decision tree is shown in Figure 4-1. 

If a supplier is not critical or has multiple sources, then its consequence rating is 1. If the supplier is 

critical, then we use a metric that consists of the number of days of supply for the item that NASA 

has in its inventory, divided by the amount of time (in days) needed to certify and start receiving the 

same product from a new supplier. For items with significant technical complexity, the time to certify 

and start production with a new supplier should be multiplied by 1.2 to reflect uncertainty involved in 

complex production.

Figure A-2. Consequence Rating Decision Tree

2 
3 

If a supplier is not critical or has multiple sources, then its consequence rating is 1. If the supplier 

is critical, then a "criticality index" metric is used that consists of the number of days of supply 

for the item that are in inventory, divided by the amount of time (in days) needed to certify and 

start receiving the same product from a new supplier. For items with significant technical 

complexity, the time to certify and start production with a new supplier should be multiplied by 

1.2 to reflect un-certainty involved in complex production. 

The consequence rating for suppliers—on a 1-to-5 scale—is based on the schema defined in 

Table A-1. The rating represents the severity (or impact) of a supplier’s loss of viability.

Table A-1. Risk Consequence Rating Scheme 
4 

Consequence

Rating Qualitative consequence rating 

definition

Criticality 

index*

1 (Low) • Minor cost increase that can be absorbed 

•

within budget

Minor schedule variance with no >1.5 

milestone impacts

• Minimal reduction in technical 

performance

2 (Minor) • Cost exceeds budget, but sufficient funds 

available

• Schedule slip, no major delivery impact 1.2 to 1.5

• Minimal reduction in technical 

performance

3 (Moderate) •

•

Cost exceeds budget and funding increase 

may be necessary

Significant schedule slip that is partially 

recoverable at program level

1.0 to 1.2

• Some operational requirements may not 

be met

4 (Significant) •

•

Cost exceeds budget and funding increase 

is necessary

Significant slip in schedule and delivery 

likely to be impacted

0.8 to 1.0

• Mission success questionable

5 (Severe) • Large funding increase necessary <0.8

• Major impact to schedule

• Mission success unattainable

* Inventory (in days) /certification time (in days)

Risk likelihood is defined as the probability or frequency that a risk may occur. In terms of 

supplier viability, risk likelihood represents the level of certainty that a supplier will experience 

a loss of viability. Likelihood is based on the set of metrics that are defined in Table A-2 

Table A-2. Metrics for Assessing Risk Likelihood
5 

Metric Definition

Regulatory 

burden 

A qualitative assessment of suppliers operating in a highly regulated 

industry or working with highly regulated materials and products. 

Companies subject to multiple regulations are more at risk of 

disruptions caused by regulatory changes.

Supplier margin The net profit of the supplier. Companies with higher profit margin 

are less likely to experience financial failures. 

M&A postulated A qualitative assessment of the potential for a supplier to be involved 

in a merger or acquisition. Corporate priorities can change after a 

merger or acquisition, impacting the service to NASA. 

Percentage of 

off-shore 

suppliers 

The portion of suppliers used that are foreign in origin. Foreign 

companies are less likely to have readily available financial data and 

are a higher risk due to cultural differences in sharing risk exposure 

information. 

Percentage of 

small business 

suppliers

The portion of suppliers that are small businesses. Small busi-nesses 

tend to have a lower tolerance for financial problems and are more 

likely to experience a financial failure. 

Because the Altman Z-score is a proven predictor of financial failures, it is recommended to begin the 

supplier assessment with a Z-score calculation and assigning likelihood points based on the results, as 

shown in Table A-3. 

Table A-3. Z-Score Likelihood Points

Supplier type Z-score Likelihood points 

Public company

>2.99 0

1.81 - 2.99 5

<1.81 10

Private company

>2.90 0

1.23 - 2.90 5

<1.23 10

Suppliers can receive likelihood points of 0, 5, or 10 points based on their Z-score. If a supplier 

receives 10 points based solely on its Z-score, then the supplier is considered high risk, and no 

further evaluation is necessary. If a supplier receives a 0 or 5 based on their Z-score, it is still 

necessary to assess that supplier against the other metrics in Table A-2. 

If the financial data required for the Z-score calculation is unavailable, such as for a private 

company, assign at least 5 likelihood points for the Z-score metric. To anticipate the event when 

a supplier is unable to or will not provide the financial data necessary for the Z-score calculation, 

introduce a contract requirement for the supplier to provide the data. If the supplier cannot 

provide the data or is un-willing to agree to the contract term, NASA can purchase financial 

reports from financial monitoring companies, many of which provide reports on private firms. 

As an example, Dun and Bradstreet maintains “Private Company Insight Reports” that offer key 
6 

company data for more than 250,000 U.S. private companies, including financial data for up to 3 

years.

The Z-score for public companies is calculated per the following equation:

Z = 3.3 (EBIT/Total Assets) + 1.2(Net Working Capital/Total Assets) + 

1.0 (Sales/ Total Assets) + 0.6 (Market Value of Equity/Book Value of Debt) + 

1.4 (Accumulated Retained Earnings/Total Assets)

where, Z is the Z-score for the company and EBIT is earnings before taxes. 

The Z-score for private companies is calculated per the following equation:

Z = 0.717 (Net Working Capital/Total Assets) + 

0.847 (Accumulated Retained Earnings/Total Assets) + 3.107 (EBIT/Total Assets) + 

0.420 (Book Value of Equity/Total Liabilities) + 0.998 (Sales/Total Assets) 

Likelihood points are assigned to the remaining metrics based on low and high-risk criteria. If a 

supplier has a low risk for a particular metric, it receives 0 points for that metric; if a supplier has 

a high risk for the metric, it receives the corresponding points, as shown in Table A-4. 

Table A-4. Additional Metric Likelihood Points
7 

Metric Risk level Risk criteria Likelihood 

points

Program budget / 

schedule 

Low At or below budget, on time or ahead of 

schedule 0 

High >10% over budget or behind schedule 1

Percentage of 

business with 

NASA

Low <50% 0

High >50% 3

Regulatory 

burden

Low No 0

High Yes 3

Supplier margin Low >5% 0

High <5% 3

M&A postulated Low No 0

High Yes 1

Percentage of 

off-shore 

suppliers

Low <10% 0

High >10% 1

Percentage of 

small business 

suppliers

Low <25% 0

High >25% 1

Once points are determined for each of the nine metrics, the sum of the points for a supplier then 

becomes its total likelihood rating. This rating is converted into a 1-to-5 score using the scale in 

Table A-5. The score represents the likelihood a supplier will encounter a viability risk.

Table A-5. Risk Likelihood Rating Scheme 

Risk level Qualitative likelihood rating definition Likelihood rating 

Nearly 

certain = 5

Most always encountered; practically 

unavoidable event

Risk score of 10 or more

Highly likely 

= 4

Expected to occur; typically occurs in 

efforts of a similar nature

Risk score of 6 to 9

Possible = 3 Even likelihood of occurrence; often 

encountered in similar efforts

Risk score of 4 to 5

Unlikely = 2 Hypothetically possible, but uncommon in 

programs of similar type

Risk score of 2 to 3

Very 

unlikely = 1

Rarely encountered; standard practices will 

effectively avoid event

Risk score of 0 to 1

The risk consequence rating scheme in Table A-1 and risk likelihood rating in Table A-5 are 

intended to be a starting point for NASA’s risk assessment of its suppliers. This study did not 
8 

include a review of NASA programs to ensure that the ranges are appropriate for NASA’s 

suppliers. With additional analysis, the criteria provided can be tuned to allow an appropriate 

distribution of the suppliers into the various risk levels for consequence and likelihood. 

Risk Matrix. Consequence and likelihood together can be used to identify the risk each supplier 

presents to the program. Using the 1-to-5 ratings for consequence and likelihood, the risk of a 

particular supplier can be plotted on the matrix shown in Figure A-2. 

The matrix can be used to visualize the risks for individual suppliers in relation to one another, 

prioritize the order in which each is addressed, and plan ways to mitigate each risk. Based on its 

placement in the matrix, a supplier is determined to have a low, medium, or high risk of failure. 

Suppliers that fall into the green range are considered low risk; suppliers that fall into the yellow 

range are considered a moderate risk; and suppliers that fall into the red range are considered a 

high risk. However, note that a supplier with a low consequence rating will always be a low risk 

- no matter how likely the risk is to occur. For this reason, we calculate a supplier’s consequence 

rating first and can eliminate the likelihood rating calculations for suppliers in this category.

Figure A-2. Supplier Risk Matrix 

(1,5) (2,5) (3,5) (4,5) (5,5) 

(1,4) (2,4) (3,4) (4,4) (5,4) 

(1,3) (2,3) (3,3) (4,3) (5,3) 

(1,2) (2,2) (3,2) (4,2) (5,2) 

(1,1) (2,1) (3,1) (4,1) (5,1) 

For suppliers in the "high risk" category (red) corrective action should be implemented and 

monitoring should be increased. Supplier monitoring should be increased for those suppliers in 

the "medium risk" category (yellow). No specific action is necessary for suppliers in the "low 

risk" category (green).
1 

APPENDIX B: Example Requirements

Sample logistics-related requirements from several NASA programs appear below. The 

designation (e.g. ISS.X or CxP.X) are used to indicate the program of origin for the purposes of 

this document and are not the designations used in the original source requirements documents.

ISS Program (excerpted from SSP 41000 and SSP 50520)

ISS.1.1 On-Orbit Maintenance

The Hardware X shall be maintained on-orbit utilizing corrective, in situ, or intermediate 

maintenance.

ISS.1.1.1.1 Corrective Maintenance

On-orbit HARDWARE X corrective maintenance shall be performed by removal and 

replacement or by in-situ maintenance.

ISS.1.1.1.2 In situ Maintenance

When on-orbit removal and replacement is not applicable, HARDWARE X functionality shall be 

restored by in-situ maintenance.

ISS.1.1.1.3 ORU Intermediate Maintenance

The HARDWARE X equipment designated for on-orbit intermediate maintenance shall be 

packaged for the removal and replacement of Shop Repairable Units (SRU) and for other 

approved off-equipment repairs. 

ISS.1.1.2 Access for On-Orbit Maintenance (non-Logistics) 

The installation of HARDWARE X components shall not prohibit access to all IVA locations 

requiring on-orbit maintenance as specified in SSP 5005, paragraph 11.2.3.6. 

ISS.1.1.2.1 Access for On-Orbit Inspection

The installation of HARDWARE X components shall not prohibit access for the inspection of 

equipment located in the unpressurized environment and requiring on-orbit maintenance without 

the removal of other equipment. Removal or opening of protective covers is permissible.

Constellation Program

These requirements are excerpted from the Constellation Architecture Requirements Document 

(CARD), CxP-70000. This was the Program-level requirements document. The subordinate 
2 

programs each had their own requirements documents that contained flow-down requirements in 

response to the CARD requirements. Note: Some of these requirements may not immediately 

appear to be LCLS-related requirements (e.g. turnaround requirements). However, they are 

important constraining requirements that would drive subordinate requirements dealing directly 

with the LCLS infrastructure (e.g. flight rates), maintenance environment (i.e. on the launch pad 

or in an integration facility), and hardware maintainability design requirements.

CA5511-PO The nominal flight rate of CLV to ISS shall be 5 per year with a maximum rate of 

6 per year. 

CA5512-PO The nominal CLV Lunar flight rate shall be 2 per year with a maximum rate of 3 

per year.

CA5525-PO The EVA System shall accommodate flight rates necessary to sustain the ISS and 

human exploration programs, as stated in the System Flight Rate Table.

CA5539-PO Ground Systems shall provide the capacity to operate the missions as defined in 

the Systems Flight Rate table for ISS and human exploration programs.

CA0492-PO The CEV shall be capable of conducting a lunar mission within 26 (TBR-001-003) 

days following a missed lunar injection opportunity. 

CA4100-PO The CLV shall be capable of conducting a lunar mission within 26 (TBR-001-003) 

days following a missed lunar injection opportunity. 

CA0060-HQ The CEV shall remain docked to the ISS for up to 210 days. 

CA0123-PO The Constellation Architecture system shall have an 88% (TBR-001-021) 

probability of launch per crew launch attempt, starting at "LCC Call to Station'' and ending at 

close of day-of-launch window. 

CA0178-PO The CEV shall have a launch availability of no less than 98% (TBR-001-041) per 

launch attempt, starting at (TBD-001-505) hours for "LCC Call to Station'' and ending at close of 

day-of-launch window. 

CA1066-PO The CLV shall have a launch availability of no less than 98% (TBR-001-041) per 

crew launch attempt, starting at "LCC Call to Station" and ending at close of day-of-launch 

window. 

CA3064-PO Ground Systems shall have a launch availability of no less than (TBD-001-563)% 

per crew launch attempt, starting at "LCC Call to Station" and ending at close of day of launch 

window. 

CA0550-PO The Constellation Architecture shall be maintainable during each design 

reference mission within the limits of the maintenance resources shown in the Maintenance 

Resources table.

CA5710-PO The Constellation Architecture shall provide the infrastructure to maintain 

systems through their operational life cycles.
3 

CA5182-PO The EVA Systems flight hardware shall not require planned refurbishment or 

repair during a single ISS mission.

CA5184-PO The EVA Systems flight hardware shall be designed to allow for in flight 

maintenance, including replacement and repair of major end items.

CA5495-PO The CEV shall sustain in-space operations using only onboard equipment and 

spares without resupply or support from personnel other than the crew.
1 

APPENDIX C: Example DRDs

Data Requirement Description

(Based on JSC-STD-123) 

1a. DRD Title: Parts Obsolescence Monitoring

1b. Data Type: 3

2. Date of Current Version: -1/01/04 

3a. DRD No.: F-LM-04 

3b. RFP/Contract No.: NAS 15-1000 

4. Use: Obsolescence reporting and Single Source Supplier Analysis (SSSA) alerts the ISS 

Program that production is concluding for a specific part, and provides the identification of 

single source suppliers and plans methods to be used to provide for the continued support of the 

ISS through its operational life. 

5. DRD Category: Technical

6. References (SOW, Clause, etc.): Statement of Work (SOW); paragraphs 3.3.8.5.3 

7. Interrelationships (e.g. with other DRDs): None 

8. Preparation Information: The contractor shall prepare the DRD as follows:

SCOPE: Parts Obsolescence Monitoring shall consist of Parts Obsolescence and Single Source 

Supplier Analysis (SSSA). 

Parts Obsolescence Monitoring: The contractor shall identify and resolve hardware and 

component obsolescence issues and loss of failure analysis, production and repair capabilities in 

compliance with Program management and control requirements. Loss of capabilities includes, 

but is not limited to, loss of skills or a supplier going out of business. The contractor shall 

deliver parts provisioning data for all repairable parts and parts containing EEE parts to support 

management of parts obsolescence. The contractor shall obtain government approval for 

hardware changes as required by NSTS 07700 and SSP 41170. 

The contractor shall compile a list of their sole source, single source (where requalification may 

be required) "production" suppliers for essential consumable industrial materials, parts, 

components, systems, and critical facilities and perform an analysis of those suppliers to identify 

areas of concern relative to supporting the program mission. This analysis and plan shall address 

consumables, hardware (including flight hardware), and expendable items requiring recurring 

procurement over the Station's life. This analysis shall encompass all subcontractors regardless 

of tier. The contractor shall perform an analysis of those single source suppliers to identify area 

of concern relative to supporting program mission. The Contractor shall prioritize the analysis to 

ensure that any subcontractors / suppliers that are leaving the program near term are addressed 

first, with the remaining scheduled based on their contract completion dates. The contractor 
2 

shall identify those subcontractors / suppliers which have already completed their production 

requirements. 

CONTENT: The SSSA shall consist of the following:

A list of singe source suppliers (includes all subcontractors regardless of tier). 

The items that the single source suppliers provide.

Identify any risks associated with proprietary processes, environmental issues and foreign 

ownership of the resultant suppliers outside the continental United States.

Provide recommendations to protect the items from production stoppages and ensure availability 

of materials, consumables and facilities.

This report shall document items that have been previously identified as obsolete and the actions 

taken to ensure support for the life of the program (i.e. life of type procurements). 

FORMAT: Parts obsolescence and SSA content submittal shall be submitted in a format 

supported by the electronic library or as otherwise agreed to by NASA and the contractor. 

9. OPR: 

10. FIRST SUBMISSION DATE: 

 Frequency of submission: Quarterly Report 

 Additional Submissions: (blank) 

11. MAINTENANCE: Shall be maintained and updated electronically

12. COPIES/DISTRIBUTION:

 1 original/record (hard copy): Program Data Management 

1 electronic copy: to a Program authorized repository 

13. REMARKS: None
3 
1 

Appendix D: Maintenance Level Identification Processes7

The LCLS team will provide an initial assessment of the maintenance concept based on the 

hardware design and the Concept of Operations. The maintenance concept starts with an LSA 

Candidates List that is developed from an initial hardware list and analyzed against the Concept 

of Operations and Failure Mode and Effects Analyses. The LSA candidates list is composed of 

any hardware that requires operational logistics support. Ground maintenance / repair and / or 

discard candidates will also be identified and documented. 

Figure D-1. Flight Hardware Maintenance Concept / Repair Level Initial Definition

On-Orbit Maintenance Level (Organizational / Intermediate)

As data become available, the LCLS team will select the hardware from the LSA Candidates list 

and perform an analysis using the ORU Selection Criteria. Figure D-2 depicts the ORU 

Selection process. The I-Level Maintenance ORU Selection Process is depicted in Figure D-3. 

 7 adapted from Boeing International Space Station (ISS) Spares Management & Logistics Work Instruction for New 

Hardware Design/Development (Initial Release, March 2012).
2 

Figure D-2. Organizational (O) - Level Maintenance ORU Selection Process 
3 

SRU candidate

SRU candidate

SRU candidate

High failure rate

ORU

Low SRU to ORU 

volume / weigh 

ratio ?

High criticality 

function

SRU has Inherent 

failure modes ?

FMEA

SRU removable 

from ORU ?

Non-destructive

Accessible 

NHA removable 

from ORU ?

Yes

No Not Selected

No No Not Candidate

Subjective

Not Selected No

SRU significantly 

contributes to 

ORU failure rate ?

SRU failure 

causes loss of 

ORU function: No 

workaround or 

degraded 

performance 

option ?

Subjective

Not Selected

Yes

Yes

No No Not Candidate Not Selected

Evaluate NHA as 

SRU

Yes Yes Safety 

Assessment

SHA

Controls for all 

safety hazards ? No Not Candidate Not Selected

Can fault be 

isolated to SRU ?

List fault isolation 

method. No Not Selected

Is post 

maintenance test 

required ?

List required tests

No

Operations 

Assessment

Can test be 

performed with 

existing on-orbit 

equipment ?

Yes

Selected

Not Candidate Subjective

Not Selected No

Is I-level 

maintenance time 

acceptable ?

Yes

Subjective

Not selected

No

List maintenance 

steps

Skills required

Tools required

Consumables 

required

Unique skills / 

tools / 

consumables 

required on-orbit ?

No

SRU MTBF

Weight

Volume

AC Quantity

Not Candidate Subjective

Not Selected

Yes

I-Level Maintenance 

SRU Selection Criteria & Data 

Requirements

Time estimate

ORU MTBF

Weight

Volume

AC Quantity

Note: 

When any RED “Not Selected” terminator is reached, no 

further analysis of the SRU is required 

When any YELLOW “Subjective Not Selected” terminators are 

reached, provide rationale and continue on alternate path

BLUE indicates required Input / Output data 

Evaluate additional test 

equipment required for 

feasibility, cost , schedule

Evaluate unique skills, tools, 

consumables required for 

feasibility, cost , schedule

Low is arbitrarily defined as:

SRU < 25% of ORU (mass / 

volume)

LEGEND

FMEA – Failure Modes & Effects Analysis

SRU – Shop Replaceable Unit

ORU – Orbital Replaceable Unit

AC – Assembly Complete

NHA – Next Higher Assembly

SHA – Safety Hazard Analysis

MTBF – Mean Time Between Failure

Greg Demel

Boeing L&M

281-226-4553

Yes

Yes

Yes

Yes

Figure D-3. Intermediate (I) - Level Maintenance ORU Selection Process