1. Application of ISS
Lessons Learned
to Systems Integration
Michael G. Wood
Program Manager
The Boeing Company
281-226-6276
Project Management
Challenge 2010
February 9-10, 2009
Used with Permission

2. Discussion Topics
• Large scale integration can be very complex
– As program size grows and the complexity of the system being integrated
increases, the challenges for integration grow exponentially
– These challenges were prevalent on the International Space Station (ISS)
program
• Systems Integration
– System Definition & Synthesis
– Requirements and Interface Definition & Management
– Verification and Validation
• Program Integration
– The Program as a System
– Space Station Freedom Lessons
– ISS Lessons
• Summary & Conclusions
• Q&A
Michael Wood, PM Challenge 2010.ppt pg. 2

3. Characteristics of a Large Scale Space Program
Large Scale Space Program Relevance to ISS Program
Characteristics
Large geographically and • Teams (NASA and contractors) located all over the country
culturally diverse team • Multiple International Partners had to be engage across the
globe
Space based systems • ISS had to address the complex and critical functions and
needs inherent with space exploration
Human rated systems • Human rated systems can be complex and ISS had to
integrate the human rated requirements
Mix of existing and new • ISS had to balance the need for new technologies with existing
technology technology
Evolving multiyear incremental • Incremental build up of capability over time
capability • Concurrent development, operations and sustainment
• Multiple budget cycles, changes in administration, budgets
and direction.
The ISS approach to systems and program integration may offer insight and
lessons for other large, complex programs or projects
Michael Wood, PM Challenge 2010.ppt pg. 3

4. More than 100,000 personnel from over 500 contractor
facilities in 37 States and 16 Countries
Michael Wood, PM Challenge 2010.ppt pg. 4

5. ISS Assembly
On orbit today
Ready to be added
P5
ESP3
ELC1
ELC3
P3/4
ELC2
S6
ELC4
Starboard S5
SPDM JEM ELM-PS
Photovoltaic
Arrays S3/4
ELC5 JEM RMS & ISS Percent
MT/CETA Stbd
Exposed Facility Complete
Rails • 95% by Mass
JEM PM
Node 2 • 80% by
Node 3
Pressurized
Cupola Volume
Columbus
ULF-3 19A ULF-4* 20A ULF-5*
ELC1, Node 3 ELC3, Node 3, Stbd
ELC2 Outfitting ELC4 Cupola MT-CETA
Rails
*Contingency Flight
MHG06 75013.ppt
Michael Wood, PM Challenge 2010.ppt pg. 5 | 5

6. The Program as a System
• Integration of the functional and physical system is necessary but
insufficient for successful program execution
• The Program itself should also be
viewed as a system
– Do the organizations and work packages Program
map to the system elements
– Does data and information flow easily
between the systems developers and the
program/system integrator
System Data System
– Do budgets align with authority and Provider A I/F Provider B
accountability
– Are contract interfaces defined
– Are program and project plans, process and
practices aligned
– Do key program tools work together
Lesson: Interchange of data (Cost, Schedule & Technical) is key to
successful baseline management and program execution
Michael Wood, PM Challenge 2010.ppt pg. 6

7. SYSTEMS INTEGRATION
Overarching Lesson: With the end in mind, plan and
work the integration task from day Wood, PM Challenge 2010.ppt
Michael
one pg. 7

8. ISS Macro Process
Integrated Verification
System AIRD Requirements and Logic
Stage Analysis
Spec
•FxF/DAC Operation
Arch Safe, Survivable,
•SIR/SAR Procedures,
Doc. 2 Operable Architecture •VAC/Safety Performance
IP and
and Review/R&M
USOS Architecture IP Design and
Ground Analysis/M&P
Segment Doc. 1 Verification Data
Segment COFR 2
Ground Design and
Verification Data
Integration
SMC/
Physical
End Item NCS Launch
End Item B End and
Test Requirements
A Item Requirements On Orbit Vehicle
Baseline Integration
Test Results
)
(Including Pt 1 ICDs
Assembly/
Manufacturing
and
Component S/W Component Sequencing
Spec Spec Spec
Secondary
As
Component Code Structural Utility Part 2 Designed
Structural
Design Design Drawing Drawing ICDs Baseline
Drawing
(FCA)
Integrated
Testing
Mission Assembly Acceptance As-Built
Subsystem and
Software Components and Data Baseline Shuttle
End Item Tests
Checkout Package Integration
(PCA)
Lesson: The macro-process, which takes the program from mission statement to launch,
needs to be defined and communicated to all program participants 2010.ppt pg. 8
Michael Wood, PM Challenge

9. System Definition Process
Reboost Scenario A
Con Ops & Changes?
Utilization Funct
All C
Decomp
Scenarios
F F F
Application Teams
Functional Analysis &
Ops Functional Description
F F F
Block Diagrams
B
A
Mode Transition
Timelines
Changes?
States,
Modes Mode C
Functional
Reboost Decomp Resource Analysis
Power
Thermal
F F F Functional Sequence Diagrams
Tracking
Data F F
F
System System
Spec Spec
Mode Definitions 3.2.1 3.7.X Functional Interconnect Diagrams
B Segment Segment
Spec Spec
Change to 3.2.1 3.7.X
Functionality
Impacts Scenarios IRDs/ICDs
End Item End Item Traceability
Spec Spec to Segment &
3.2.1 3.2.1 PIDs
Lesson: Multiple views and interactive feedbackWood, PM Challenge 2010.ppt
Michael
loops pg. 9
are needed to define a complex system

10. System Cube – Vertical, Horizontal and Temporal View
• Analysis and Integration Teams (AITs) were adopted during the system
definition phase
• One key characteristic of the AITs was that they “owned” the requirements from
establishment through verification
STAGES FxF Stage Block
AIRDs
ADDs
S
U C&DH
B C&T
S ECLS
Y EPS
S Z
S1
T SM&C P
E TCS L6 6
N Elements
M N1 A
S 2 B
C&DH (End Item
C&T Specs)
The Cube Slices
ECLS LAB
ADDs – Architecture Description Documents EPS
(Horizontal End to End Subsystem Architecture)
Stage FxF - Flight by Flight Stage functionality SM&C
End Item - End Item functionality TCS
Lesson: Functionality needs to be addressed vertically, horizontally and temporally
Michael Wood, PM Challenge 2010.ppt pg. 10

11. Verification Five Step Process
STEP 1 STEP 2 Detailed Verification Objective
A detailed statement defining the
IDENTIFY ALL DEFINE
verification activity for each
REQUIREMENTS CLOSURE requirement.
STRATEGY Verification Logic Network
A set of DVOs that depicts the
- System Develop: conditional sequence of verification
- Segment - DVOs activities necessary to show that a
- End Item - VLNs “capability” or an “associated
- Associated - DVRs requirement” is verified.
- Reference Define Support
Verification - IRD/ICD Detailed Verification Requirement
Needs
A set of activities performed A logical collection of DVOs used to
to ensure that facilities, prepare test plans, procedures,
hardware & software demos, inspections, analytical
products, & assembly models, etc. with similar grouping
procedures are in Electronic characteristics, i.e. all passive thermal
compliance with program Database analysis DVOs for the same
specification requirements configuration end item should be
(Auditable/
grouped in the same DVR.
Traceable Trail)
STEP 3
STEP 5 STEP 4 EXECUTE
VERIFICATION
PREPARE DEVELOP
ACTIVITIES
VERIF CLOSURE VERIF
DOCUMENTATION REPORTS
- Analysis
Develop Reports - Test
- Specification Compliance - Analytical - Inspection
Reports - Test - Demo
- VCN’S - Inspection
- Demo
Lesson: Verification logic should be thought out and documented during
requirement development and allocation process Challenge 2010.ppt pg. 11
Michael Wood, PM

12. Building Block Test and Verification Approach
Integrated Verification
Lower End Item Assembly AIRD
Drawing (System an d
Level Spec Spec Segm en t Spec)
Test/ Test/ Analysis with
Test Analysis Subsystem Test
Inspection
Box Level End Item (EI) Stage
Verification Testing & Cargo Element Verification/
Verification Checkout/ Subsystem
FCA/ Integration Integration
PCA
Orbital
Replacement
Unit (ORU)
A A B A B C
End Item Cargo Element Stage
ORU
Product Groups
B • Imp lem en t v erific ation
ab ove en d item leve l
• Ro lls u p ve rificatio n to
sy stem lev e l
End Item • As ses s an d ap pro ve
GFE
Internt’l Partners ad eq ua cy of low er level
verifica tio n ap pro ac h es
Lesson: Apply rigorous building block approach to all phases of integration
Michael Wood, PM Challenge 2010.ppt pg. 12

13. ISS Digital Pre-Assembly (DPA) Lessons
• Digital Pre-Assembly (DPA) was one of the lessons learned on ISS for program
risk reduction and integration for interface verification and validation
• DPA used to assess interfaces of modules before they were mated on orbit
(assessed early in design phase & later in production)
Model Measure As-built interface
evaluation
Develop EI #1 I/F
CAD model
Measure E/I #1
I/F against E/I #1
I/F CAD model*
Conduct Electronic
mate of
As-designed Conduct electronic mate of
CAD models As-built CAD models
Measure E/I #2
Develop EI #2 I/F I/F against E/I #2
CAD model I/F CAD model
Lesson: Continually assess interfaces in all development phases
Michael Wood, PM Challenge 2010.ppt pg. 13

14. ISS Lessons Leaned
Digital Pre-Assembly Interface Assessment
View showing photogrammetry camera,
tripod, and console
View showing FGB
measurement session
View showing FGB Dynamic Test
Article model Michael Wood, PM Challenge 2010.ppt pg. 14

15. Interfaces – Cable/Fluid Assessment
(Physical Integration)
As Mated Process
E/I in Flight Modify
Configuration Conduct Fit Check/Cable Mate Conduct Drawing/
Issue Resolution Assembly/ICD
Develop Fit Verify: w/ PG/IP as
Check/Cable Mate Prepare • Connector plug and receptacle Required
Procedures Manufacturing Plan properly mate
• End-Item receptacle pin count, pin
type, receptacle keying, part number
• Close-out Photos
Prepare
Jumper/Umbilical
Fit Check/Cable Mate
Cables Available Report
MOD Flight Crew Personnel Support*
Procedures (Gloved Hand at Crew Discretion) * - Mandatory for EVA
Mates
As-Built Physical Audit Process
Conduct As-Built Audit Activities: Conduct Conduct Modify Drawing/
Develop As-Built Audit Issue Resolution Assembly/ICD as
As-Built Audit Prepare H/W to Drawing Inspection: H/W Integrity Inspection: Comparison w/ PG/IP Required
Procedures Manufacturing Plan • Receptacle & Connector: • Receptacle & Connector:
- Pin Count - Bent Pins
- Pin Type - Loose Contact
- Keying - Loose Lever
- Clocking - Corrosion Prepare
- Part Numbers • Cable As-Built
• Verify Cable Length - Torn sheathing Audit Report Prepare As-Built
As-Designed Audit
• Close-out photos - Loose spot ties Interface A Audit Report
Report
Interface B
As-Designed Audit Process
Conduct Conduct Modify Drawing/
Conduct As-Designed Audit Activities: As-Designed
Cable Drawing Evaluation: Receptacle Evaluation: Issue Resolution Assembly/ICD as
ICD Part II • Cable components • Pin Functionality Audit w/ PG/IP Required
• Cable • Wire Type
• Materials conforms to ICD Comparison
configuration • Wire Size
meets: • Dimensions • Receptacle Part
• Conn. Pin
- Requirements • Cable Clocking Number conforms to
Qty. & Type
- Schematics • Connector Keying ICD
• Expected test • Back shell • Receptacle clocking & Prepare Prepare
Cable, Wiring, & results spacing As-Designed
Prepare As-Designed
Schematic Drawings • Pin count, pin type Audit Report
As-Designed Audit Report
Available Interface A
Audit Report
Interface B
Lesson: Consistent, cyclical assessment of interfaces avoids many late issues
Michael Wood, PM Challenge 2010.ppt pg. 15

16. Element and Stage Verification Supporting CoFR
Requirements Development End Item Development Stage 4A
Functional
ISS Hardware / Interface Certification
Configuration
Rqmnt Assy Comp Software Compatibility of Flight
Rqmnt and Physical
(SM, Lab, S0, (DPA, CA, Readiness
Configuration FA) Stage 7A
P1, Soyuz…)
Audit
Assy End
Comp Item
USOS “A” Stage 15A
& Spec Test
Data
IP&P Unique
Rqmnt Rqmnt
Verification DVOs Integrated
AIRD Verification
Closure TDSs Analyses
Stage Report
Strategy (DAC/VAC)
Rqmnt
(n) Verification
Logic
Network ITVR/LTVR
Integrated
Unique Verification Tests
Rqmnt Planning/Requirements (SVF, HSI,
AIRD Joint)
Stage
Rqmnt
n... Integrated Stage
Verification
Lesson: Iterative Design Analysis Cycle (DAC)/Verification Analysis Cycle (VAC) process
ensured the evolving assembly sequence was supportable
Michael Wood, PM Challenge 2010.ppt pg. 16

17. Systems Integration
Other Lessons Learned
• Not only is there a need to integrate analysis using a Design
Analysis Cycle or Verification Analysis Cycle, but also a need to
cyclically check to assure all aspects of integration are in
concert with each other
– Interface implementation (physical integration)
– Verification logic implementation (verification integration)
– Functional implementation
• Software design
• Human interface design
• Operational Sequence Diagrams
• Requirements
• Processes that do not work or are not efficient should not be
thrown out but changed over time to a more efficient, better
process
• Implementation of a strong change board that builds agreed-to
integrated schedules is mandatory to get to a successful flight
Michael Wood, PM Challenge 2010.ppt pg. 17

18. Systems Integration
Other Lessons Learned (Cont’d)
• Requirements Development
– Firm up requirements as early as possible (drive out TBDs)
– Use operational scenarios to uncover/validate requirements
– Manage requirements & interfaces via disciplined processes
• Design Integration
– Validate interfaces early using end-to-end digital pre-assembly processes
– Perform end-to-end simulation throughout lifecycle
– Incrementally develop; build on success
– Touch and integrate physical hardware early
• Analytical Integration
– Analytical models and tools may not accurately reflect the “true” reality
– Need to follow a basic and proven process
– Skilled analysts are a critical asset
• Integrated Testing
– Plan for Integrated test capability from the start
– Program level definition of integrated test requirements
– Verify command and data capability using actual flight software and flight
hardware.
18
Michael Wood, PM Challenge 2010.ppt pg. 18

19. Systems Integration
Other Lessons Learned (Cont’d)
• Software and Data Management
– A single development, build, test and deliver process should be developed for each major
program phase
– System managers and software developers must be jointly accountable for requirements
and validation
– Provide common software development/test platform based on an open architecture for all
developers
– Define “operational scenarios” for testing to augment discrete requirements based “Shall”
tests
• Architecture
– Critical elements and components of vehicles and modules should be standardized and
interchangeable
– Functionality should be carefully consolidated in modular components
– Maximize commonality and reuse
– Employ open systems approach
• Design
– Design for Lifecycle
– Avoid sub-optimization and over-optimization to facilitate reuse
– Often it’s the “simple things” that get you (ubiquitous items, simple at the time, can be
continual irritant)
– Do not short cut established processes without documenting rationale
19
Michael Wood, PM Challenge 2010.ppt pg. 19

20. PROGRAM INTEGRATION
Overarching Lesson: Programs should be viewed and
architected as a system
Michael Wood, PM Challenge 2010.ppt pg. 20

21. ISS Has Gone Through PM Changes
Space
Station Freedom
Transition
RDT&E
International Space Station
RDT&E O&S
Transition
Space Station Freedom ISS
NASA NASA International
• The program experienced a significant transition Partners
Work Package 1 SSF to SE&I
from ISS
(MSFC/Boeing) (Reston/Grumman) Boeing
• Applicable lessons learned occurred in both
Work Package 2
program environments
(JSC/McDonnel) Subcontractors
Subcontractors
Work Package 4 Subcontractors
Subcontractors
(Rocketdyne) Subcontractors
Non-prime GFE
Non-prime GFE
Non-prime GFE
Non-prime GFE
Non-prime GFE
Michael Wood, PM Challenge 2010.ppt pg. 21

22. Lessons from Space Station Freedom (SSF)
Environment No Contract Vehicle
Between Developers/Integrator
• Program structure for SSF was
challenging for effective program
and systems integration
– Independent developers
– Inconsistent requirements
development and flow down
– Lack of data deliverables to L2
integrator
Result Data Flow to
Integrator & Across
• Challenges in managing program
Developers
and technical baseline
Disconnected
– Minimal collaboration across
development work packages
– Lack of program/technical health
status
– Inconsistent interfaces at program
PDR/CDR
Michael Wood, PM Challenge 2010.ppt pg. 22

23. ISS Lessons Learned
Program Integration
• Program Design
– Establish and manage to realistic scope NASA International
Partners
– Build capability incrementally
Boeing
– Implement clear and streamlined decision
Subcontractors
authority Subcontractors
Subcontractors
Subcontractors
– Ensure subordinate contracts and Subcontractors
associated contract deliverables (cost, Non-prime GFE
Non-prime GFE
schedule, technical) map to and support the Non-prime GFE
Non-prime GFE
Non-prime GFE
integration effort
• Organization
– Establish Clear Responsibility, Authority
and Accountability roles
– Organize around products, not functions
– Distributed development is a fact of life --
good communication is essential
• Leadership and Staffing
– Right people at the right time
– Ensure staffing plans are realistic
– Develop and maintain momentum
– Continuously work communication at all
levels
23
Michael Wood, PM Challenge 2010.ppt pg. 23

24. ISS Lessons Learned
Program Integration (Cont’d)
• Integrated Program/Project Management
– Manage with logically-linked integrated schedules, supported by estimating models &
metrics
– Establish realistic program milestones & managed with regular, timely data
– Control the baseline
Opportunities
– Budget with adequate program reserve • Partnering • Cycle Time Reduction
• Affordability • Pre-planned Product Improvement
• Product Maturity • Innovation and New Developments
• Technology Insertion • Cost Reduction Initiatives (CRIs)
• Risk and Opportunity Management • Plan Changes
• Environmental
– Intentional opportunity management Changes
• Technical, Schedule,
Cost Trends
– Continually work mitigation and Issues • Independent Reviews Risks
• Concurrency
 Realized Risks  Risks Built-in to the Plan
opportunity plans  Failed Tests or Qualifications •Conditions Out of • Elements requiring
qualification,
 Discoveries/Findings Sight (Suppliers,
Customers) testing, etc.
 Constrained
Budgets
• Data and Process Management
– Readily Accessible/Interoperable among partners/tools
– Minimize transaction costs in moving data and information
– Exercise and refine systems and processes early
– Continuously capture knowledge over program lifetime
24
Michael Wood, PM Challenge 2010.ppt pg. 24

25. ISS Integration Lessons Learned
Summary and Conclusions
• As program size grows and the complexity of the system being
integrated increases, the challenges for integration grow exponentially
– ISS program faced and addressed those integration challenges and continues
to face integration challenges today
• The Space Station Program provides a wealth of valuable lessons for
– Large geographically and culturally diverse teams
– Program design and execution
– Design, development, test and integration
• ISS lessons can serve to validate future program design and integration
principles
Overarching Lesson: Programs should be viewed and
architected as a system
Michael Wood, PM Challenge 2010.ppt pg. 25

26. Questions?
Thank You
Michael Wood, PM Challenge 2010.ppt pg. 26