The document discusses two concepts of operation (ConOps) related to product data and lifecycle management (PDLM) challenges for NASA projects: 1) An in-flight anomaly scenario where a critical component fails and the project needs specific product data within 4 hours to diagnose and address the issue to prevent mission loss. This scenario illustrates the need to plan for accessing fragmented product data from multiple sources created over a long development period. 2) The large volumes of documentation, CAD models, test data, and other product information created and used during design, development, testing and evaluation phases which can number in the hundreds of thousands of files and terabytes of data. Effective PDLM is needed to manage this "data deluge"

1. NASA PM Challenge 2011
Product Data & Lifecycle
Management (PDLM) --
Project Management Implications
Paul Gill
NASA Marshall Space Flight Center, Huntsville, AL
Paul.gill@nasa.gov
Lisa Murphy
Atura Integration, Huntsville, AL
Lisa.d.murphy@gmail.com

2. Goals
• NASA space flight programs and projects are now expected to plan for
Product Data and Lifecycle Management (PDLM).
• PMs will understand more about
• what PDLM is,
• why they are being asked to address it,
• how to exploit it, and
• where to go for information and support.
• Give two ConOps: IFA and DDT&E
• Use actual experience from CxP to illustrate challenges
[Content below to be addressed after rest of presentation is done.]
• While no PM wants to pay more than needed for manufacturing, the likelihood that proactive
management of product definition data can avoid the cost, time, and risk of recreating data for
analysis, modeling, simulation, training, dependent designs (e.g., GSE), and facilities modifications
may provide a more cogent motivation to exploit PDLM.
• Finally, we will review the current state of PDLM services at NASA and identify how PMs, lead
engineers, designers, systems engineers, and procurement personnel can go about finding the
support they need.

3. Concept of Operation 1:
Generic In-Flight Anomaly (IFA)
• 10 years ago we developed a Flag Ship Class spacecraft.
• Nearing the end of a very long cruise mode, the
vehicle must be configured for planetaryarrival
While coming out of cruise, a critical
component experiences an operational anomaly.
• Mission team has 12 hours to fix the problem
prior to entering into orbit or the mission will be lost.
Built-in monitoring system on the central electronics unit indicates a
device on the processor card is not functioning properly.
The Question at hand: What data will be needed, and how do
we plan for it a decade or more beforehand?

4. IFA Data Needs <4 hrs: Partial List
• As-designed/as-purchased/as-tested/as-built/as-flown
product structure and definition
• Circuit card schematic
• Specifications (e.g., materials, acceptance testing)
• Where (else) used
• Location and status of spares
• Firmware, software, parameters
• Circuit card testing and failure history
• Impact analysis of failure (e.g., FMEA)
• Failure history of components in similar settings
• History of component/card/sub-system behavior over
course of mission
• Trades/Design Rationale

5. IFA Support Requires Multiple Streams
Only one stream is Product Data
Part/assy object Data from ADP for
on current this specific
mission (“as object on this
flown” flight
Part/Assembly Part/Assembly
Object Object
(As-flown)
Assembly &
DDT&E data
Verification –
Mission for this
this instance
Vehicle design
Instance
ADP
Object |
Description
System or Communication
Function & Control
Design and
analysis data
Other for design
instances history
Fabrication
& (e.g., prior
Procurement Deliveries
or flights)
Data about
other
Data from handling or Delivered data instances of
operations conducted from site that this part and
after DD250, e.g., VAB manufactured experience on
PRACA items this specific other missions
part

6. IFA ConOpConsiderations
• Data created by different groups at different
physical locations, at different times, in different
formats, and for other purposes
 And, it’s ten years later
• Need a small, particular subset of all data about this
part – and need it in context
 From different contractors, different centers
 From different points in a long development cycle
 From communities with different vocabularies
 From tools now superseded by later versions
How many IFA scenarios does your Project have?

7. Q: What is 13 GB?
A: The amount of memory required to open the top-level 3D
CAD model of the Crew Module (only) at Orion’s Preliminary
Design Review (PDR)
Here’s a hint

8. ConOp 2: Development Data Deluge
• Before we have an IFA, have to get through DDT&E
• We are seeing some very large amounts of data created
during Design & Testing alone
 Scale of product, types of analysis & testing, procurement
strategy all affect this – but no one is immune
• Illustrative Cases from CxP
 Core Input for Analysis: OML
 Analysis, Testing & Simulation Deluge
 Sample Documents & CAD Models: Ares & Orion at PDR
Documents: Ares 1 PDR reviewed ~500 documents and two drawings
With ~38,000 documents in Ares Windchill Project Folders
CAD: 16 months later at Orion PDR, LMSSC delivered ~11,000 discrete 3D models for
Service Module, Crew Module, Launch Abort System
LMSSC had ~250,000 versions, iterations, or variants in their Windchill vault

9. ConOp 2: DDT&E
Reviews
 Data does nothing but grow over phases
Integrated Stack OML
 Challenging to integrate CAD models from different
suppliers
 Designs at different maturities
 Not a design object; uses pre-release models
 Requires special CAD settings and practices
Analysis, Testing & Simulation
 Volumes of data created for and used for analysis,
verification, and testing

10. DDT&E: Ares/Orion OML
MSFC Ares Vehicle Integration responsible for
integrated stack OML 3D CAD envelope model
• in Low-, Medium-, and High-Fidelity versions for each
Design Analysis Cycle (DAC)
Proliferation of demand for OML or data from
OMLfor other design & analysis uses, including:
J2 LH2 blade ejection cone Sensor locations
Acoustic wind tunnel 4% model GNC node points
Clearance analysis simulation Inboard profile
IU/SA compartment for Human Factors IS-gimbal
Protuberance dimensions Thrust oscillation models
Fairing panel separation dynamic RoCs nozzle placement
Re-entry configuration for US Antenna locations
Source: list of requested models or data from OML CAD models in DAC 2 for Ares 1.

11. Ares1 OML Data Exchange:
Multiple Sources & Heavily Manual
LM Upper
Orion Boeing
SSC Stage
Ares Vehicle
Integration
(@MSFC)
JSC DDMS
ATK
First
ESMD ICE Stage
Project Folders
MSFC DDMS
CxP LvlII
DIO (@ JSC)
Ground KSC DDMS
Design Ops KSC
Interactions
Manual Processing Source: CxP CAD WG May 2009

12. More Things to Do With CAD Models
• 3D prototyping
• Verify/analyze design for requirements or standards compliance
• Conduct “-ilities” analyses
• Create motion models (oscillation, rotation)
• Create time-based visualizations (e.g., of assembly processes)
• Use in models and simulations (e.g., VRML)
• Plan verifications & validations; prepare before & after comparisons
• View, manipulate, annotate, mark-up, e.g., for TIMs, Reviews
• Mass properties: mass, CG, surface area, volume, Parts lists, used-on
• Produce illustrations, “viewables” or other representations
• Communications, Public Affairs, General Information
• Training & Procedures, Documents, & Manuals
• ICDskeleton models • Dynamics models
• Flat pattern for sheet metal parts • Pipe Assembly Models
• Bulk items, (e.g. Spray-on Insulation, • Harness subassembly models 12
Propellant • Layout models
• Deployed models • Mass properties models

13. A Taste: Analysis & Testing
• LMSSC test plans included telemetry ranging from
5 MB/sec (slow) to 20 MB/sec (fast) per channel
• Engineering Task Description Sheets (from CAIT) show
dependencies on 507 different data packages
• Ares initiated a risk that they would not have enough
storage for the testing data expected
• [&&&CHECK NOTES RE SIZE OF STORAGE]
• And there would be much, much, more:
• Imagery
• Simulation data sets (inputs/outputs), simulation testing
set-up/configurations
• Assembly, Installation, & Interference checking

14. Why Product Data & Lifecycle
Management?
Because we need to answer questions such as:
1. How much should we risk (conversely, how much are
we willing to pay) to ensure the relevant data exist and
are accessible, discoverable, and understandable to
support an IFA?
2. Where should we invest our attention and resources to
manage data during development?
a. What data do we need from our contractors?
b. In what formats do different users need the data?
These concerns led to changes to NPD 7120.4 to include Product
Data and Lifecycle Management, and development of
PDLM NPR.

15. What’s Happened:
In 2008, Office of Chief Engineer takes lead on PDLM
1. In 2009, updated to NPD 7120.4 to include PDLM
2. Started working on PDLM NPR (approved 1/2011)
3. Interoperability work (CAD, model exchanges)
4. PDLM Steering Committee formed

16. Definition….
• Product Data Management (PDM). A framework that enables
organizations to manage and control engineering and
technical information, specifically data surrounding the
product's design, definition, and related engineering, test,
manufacturing, and logistics processes and is a key element of
PLM…
• Product Life-cycle Management (PLM). The process of
managing the entire life cycle of a product from its
conception, through design and manufacture, to service and
disposal. PLM integrates people, data, processes, and
business systems and provides a product information
backbone for companies and their extended enterprise…

17. Scope & Coverage
• Single Project & Tightly Coupled Space Flight Programs
• Entire lifecycle for all types of product-related data
• [See NPR}
Recent experience has shown:
• 3D CAD powerful, but requires special attention
• Cannot wait until ADP to get models if you have insight-oversight
• Collaborative design requires robust, frequent data exchange
• Requiring same version, build of same tool not sufficient
• Must look at who is doing what
• Ask who needs it, why and when
• Data exchange standards lag industry practice
• So far, proprietary models only sure why to get all of data
• Need to consider software along with hardware in product
definition

18. PDLM NPR Summary (a)
Projects & Programs
Responsible for Process and Data Architecture
Write a Plan and update often
• Authoritative data are identified, captured, cataloged
• Agile, flexible, sound practices for data management
• Critical product data receives timely attention to acquire what is
needed, assure integrity, reflect maturity state(s) and authority
• Know who needs what, when, format – across lifecycle
• MDAA is responsible for seeing the PMs meet requirements

19. PDLM NPR Summary (b)
Information Systems/Infrastructure (OCIO, Center Director)
Assure that infrastructure adequate
• Seek to effectively re-use solutions to common problems, improve
performance
Tools are known and providers committed to support
Security has received due attention
Project Manager – not center– is responsible for producing plan,
building commitments
• Work with Center or other providers to come to agreement on what
services, for whom, and how
Continues for now distributed PDM/PLM tool model
• No one group assigned to provide agency-wide PDLM

20. Practical Matters: Plans, Tools & Data
Acquisition
Content of PDLM Plan overlaps traditional Project plans
such as CM, DM, Records Management, SEMP,
program/project plans
• Multiple uses of same applications/similar data
• Must initiate plan early and then update regularly
• Identify needs, project future needs, coordinate with IT supplier
Data acquisition is critical to PDLM
• Challenging to write DRDs that support CAD data exchange
• Need to consider the data needed during design and IV&V
• Also what is at physical delivery of product, engineering changes
Few NASA personnel have hands-on experience with the
new data-centric, model-centric, technology direction

21. Generally, NASA Projects Face:
Distributed Production & Use over an Extended Lifecycle
• Need to exchange and use PRE-RELEASE product data
• Mixture of internal and external sources – Centers, primes,
partners, universities
• High analysis demands, high
volumes of ancillary data
• Long project life cycles
• Need for IFA reach-back
• Ten independent Centers
with local solutions
• NASA cannot dictate
how things are done
at primes

22. Rockets as Products
Different Specifications Needed
to Get Data for Different Needs
• Do derivative designs such as
tooling, test stands
• Sub-contract part of design
work
• Do design integrations
• Conduct design review
• Take over design change
authority
• Do modeling and simulations
• Do physical integration &
verification (e.g., at test site
or VAB)
• Re-bid production

23. More Reasons to Care
• 2D drawings from NASA’s standard CAD tool (PTC Pro/Engineer
Wildfire) are made from 3D models
• To integrate the design of the 787 Dreamliner from their four design
groups, Boeing
• Had 16 Terabytes of data in their master repository
• Packaged and delivered quarterly 150 applications for the distributed
design teams to use
• Some of the 24 different extensions to CAD models identified by
MSFC CAD standard (only some of which are released):
• Interface Control Document (ICD) skeleton • Deployed models
models • Dynamics models
• Envelope part models(e.g., OML) • Pipe Assembly Models
• Flat pattern for sheet metal parts • Harness subassembly models
• Bulk items, (e.g. Spray-on Insulation, • Layout models
Propellant • Mass properties models
• Generic of family table part instance

24. Questions?