Wood.michael
-
Upload
nasapmc -
Category
Technology
-
view
13.635 -
download
0
Transcript of Wood.michael
Application of ISSLessons Learned
to Systems IntegrationMichael G. Wood
Program ManagerThe Boeing Company
281-226-6276
Project Management Challenge 2010
February 9-10, 2009
Used with Permission
Michael Wood, PM Challenge 2010.ppt pg. 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. 3
Large Scale Space Program Characteristics
Relevance to ISS Program
Large geographically and culturally diverse team
• Teams (NASA and contractors) located all over the country• 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 technology
• ISS had to balance the need for new technologies with existing technology
Evolving multiyear incremental capability
• Incremental build up of capability over time• Concurrent development, operations and sustainment• Multiple budget cycles, changes in administration, budgets and direction.
Characteristics of a Large Scale Space Program
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. 4
More than 100,000 personnel from over 500 contractor facilities in 37 States and 16 Countries
Michael Wood, PM Challenge 2010.ppt pg. 5MHG06 75013.ppt | 5
ISS Assembly
JEM PMNode 2
P5
StarboardPhotovoltaicArrays
S6
S3/4
JEM ELM-PSSPDM
P3/4
On orbit today
Ready to be added
ULF-3ELC1,ELC2
JEM RMS & Exposed Facility
ELC1
ELC2
20A Node 3, Cupola
ISS PercentComplete• 95% by Mass
• 80% by Pressurized Volume
19A Node 3
Outfitting
ULF-5*Stbd
MT-CETARails
Columbus Cupola
Node 3
S5
ESP3
ELC3
ELC4
MT/CETA Stbd Rails
ELC5
ULF-4*ELC3,ELC4
*Contingency Flight
Michael Wood, PM Challenge 2010.ppt pg. 6
The Program as a System
• Integration of the functional and physical system is necessary but insufficient for successful program execution
Program
System Provider A
System Provider B
DataI/F
Lesson: Interchange of data (Cost, Schedule & Technical) is key to successful baseline management and program execution
• The Program itself should also be viewed as a system– Do the organizations and work packages
map to the system elements– Does data and information flow easily
between the systems developers and the program/system integrator
– Do budgets align with authority and accountability
– Are contract interfaces defined– Are program and project plans, process and
practices aligned– Do key program tools work together
Michael Wood, PM Challenge 2010.ppt pg. 7
SYSTEMS INTEGRATION
Overarching Lesson: With the end in mind, plan and work the integration task from day one
Michael Wood, PM Challenge 2010.ppt pg. 8
ISS Macro Process
Ground Design and Verification Data
Operation
AIRD
IP and
RequirementsBaseline(Including Pt 1 ICDs)
ArchDoc. 2
ComponentSpec
S/WSpec
ComponentSpec
As-BuiltBaseline
(PCA)
ComponentDesign
CodeDesign
StructuralDrawing
SecondaryStructuralDrawing
UtilityDrawing
AsDesignedBaseline(FCA)
Test Requirem
ents
Test Results
Launchand
Integration
Subsystem and End Item Tests
MissionSoftware Components
Assemblyand
Checkout
Procedures,Performance
AcceptanceData
Package
Phys
ical
In
tegr
atio
n
End Item B
Integrated VerificationRequirements and Logic
USOSSegment Ground
Segment
Integrated Testing
SystemSpec
IP and
Safe, Survivable, Operable Architecture
COFR 2
End Item A
ArchitectureDoc. 1
IP Design and Verification Data
On Orbit VehicleAssembly/
Manufacturing and
Sequencing
Part 2 ICDs
ShuttleIntegration
SMC/NCSEndItem
Stage Analysis•FxF/DAC•SIR/SAR•VAC/Safety Review/R&M Analysis/M&P
Lesson: The macro-process, which takes the program from mission statement to launch, needs to be defined and communicated to all program participants
Michael Wood, PM Challenge 2010.ppt pg. 9
System Definition Process
TrackingData
Mode Definitions
System Spec3.2.1
System Spec3.7.X
Segment Spec3.2.1
End Item Spec3.2.1
Segment Spec3.7.X
End Item Spec3.2.1
Traceabilityto Segment &
PIDs
Functional Sequence Diagrams
Functional Interconnect Diagrams
IRDs/ICDs
Con Ops & Utilization
Ops Functional Block Diagrams
States,Modes Mode
Reboost
C
F F F
F F F
FunctDecomp
Change toFunctionality
Impacts Scenarios
B
B
F F F
F F F
FunctionalDecomp
C
A
Changes?
A
Changes?
Application TeamsFunctional Analysis &
Description
Reboost Scenario
AllScenarios
Resource AnalysisPowerThermal
TimelinesMode Transition
Lesson: Multiple views and interactive feedback loops are needed to define a complex system
Michael Wood, PM Challenge 2010.ppt pg. 10
• 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
FxF Stage Block
N2
LAB
N 1
S6
Z1
SUBSYSTEMS
STAGESAIRDs
ADDs
ECLS
SM&C
C&DHC&T
EPS
TCS
(End Item Specs)
LAB
ElementsP6
ADDs – Architecture Description Documents(Horizontal End to End Subsystem Architecture)
Stage FxF - Flight by Flight Stage functionalityEnd Item - End Item functionality
The Cube Slices
System Cube – Vertical, Horizontal and Temporal View
Lesson: Functionality needs to be addressed vertically, horizontally and temporally
C&DHC&T
EPS
TCS
ECLS
SM&C
Michael Wood, PM Challenge 2010.ppt pg. 11
Verification Five Step Process
ElectronicDatabase
(Auditable/ Traceable Trail)
IDENTIFY ALLREQUIREMENTS
- System- Segment- End Item
- Associated- Reference
- IRD/ICD
DEFINECLOSURE STRATEGY
Develop:- DVOs- VLNs- DVRsDefine Support Needs
EXECUTEVERIFICATION
ACTIVITIES
- Analysis- Test- Inspection- Demo
DEVELOPVERIF
REPORTS
Develop Reports- Analytical- Test- Inspection- Demo
PREPAREVERIF CLOSURE
DOCUMENTATION
- Specification ComplianceReports
- VCN’S
VerificationA set of activities performed to ensure that facilities, hardware & software products, & assembly procedures are in compliance with program specification requirements
Detailed Verification ObjectiveA detailed statement defining the verification activity for each requirement.Verification Logic NetworkA set of DVOs that depicts the conditional sequence of verification activities necessary to show that a “capability” or an “associated requirement” is verified.Detailed Verification RequirementA logical collection of DVOs used to prepare test plans, procedures, demos, inspections, analytical models, etc. with similar grouping characteristics, i.e. all passive thermal analysis DVOs for the same configuration end item should be grouped in the same DVR.
STEP 1 STEP 2
STEP 3STEP 4STEP 5
Lesson: Verification logic should be thought out and documented during requirement development and allocation process
Michael Wood, PM Challenge 2010.ppt pg. 12
Building Block Test and Verification Approach
End Item Cargo Element
FCA/PCA
ORU
BA
End Item (EI)Testing &
Verification
Box LevelVerification
Stage
OrbitalReplacement
Unit (ORU)
Lower Level Spec
End ItemSpec
AIRD(System and
Segment Spec)
Test Test/Analysis
Analysis withSubsystem Test
Integrated Verification
• Implem ent verificationabove end item level
• Rolls up verification tosystem level
• Assess and approveadequacy of lower levelverification approaches
AssemblyDrawing
Test/Inspection
Cargo ElementCheckout/Integration
StageVerification/SubsystemIntegration
BA CA
BEnd ItemProduct Groups
GFEInternt’l Partners
Lesson: Apply rigorous building block approach to all phases of integration
Michael Wood, PM Challenge 2010.ppt pg. 13
ISS Digital Pre-Assembly (DPA) Lessons
Conduct electronic mate of As-built CAD models
As-built interfaceevaluation
Measure
Measure E/I #1I/F against E/I #1 I/F CAD model*
Measure E/I #2I/F against E/I #2 I/F CAD model
• 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
Develop EI #2 I/FCAD model
Develop EI #1 I/FCAD model
Conduct Electronicmate of
As-designedCAD models
Lesson: Continually assess interfaces in all development phases
Michael Wood, PM Challenge 2010.ppt pg. 14
ISS Lessons LeanedDigital 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. 15
Interfaces – Cable/Fluid Assessment(Physical Integration)
Modify Drawing/
Assembly/ICD as
Required
Cable, Wiring, & Schematic Drawings
Available
Cable Drawing Evaluation:• Cable configuration meets:- Requirements- Schematics
• Expected test results
• Cable components• Materials• Dimensions• Cable Clocking• Connector Keying• Back shell
• Wire Type• Wire Size• Conn. Pin Qty. & Type
Receptacle Evaluation:• Pin Functionality conforms to ICD
• Receptacle Part Number conforms to ICD
• Receptacle clocking & spacing
• Pin count, pin type
Conduct Fit Check/Cable Mate Develop Fit
Check/Cable Mate Procedures
Prepare Manufacturing Plan
MOD Procedures
ConductIssue Resolution
w/ PG/IP
PrepareFit Check/Cable Mate
Report
Flight Crew Personnel Support*(Gloved Hand at Crew Discretion)
PrepareAs-Designed Audit Report
Prepare As-Designed Audit ReportInterface B
Prepare As-DesignedAudit ReportInterface A
E/I in Flight
Configuration
Jumper/Umbilical
Cables Available
* - Mandatory for EVA Mates
Verify: • Connector plug and receptacle
properly mate • End-Item receptacle pin count, pin
type, receptacle keying, part number• Close-out Photos
Interface B
As-Built Physical Audit ProcessConduct As-Built Audit Activities:
H/W to Drawing Inspection:• Receptacle & Connector:
- Pin Count- Pin Type- Keying- Clocking- Part Numbers
• Verify Cable Length• Close-out photos
H/W Integrity Inspection:• Receptacle & Connector:
- Bent Pins - Loose Contact- Loose Lever- Corrosion
• Cable- Torn sheathing- Loose spot ties
DevelopAs-Built Audit
ProceduresPrepare
Manufacturing Plan
ConductIssue Resolution
w/ PG/IP
Prepare As-Built Audit Report
Modify Drawing/Assembly/ICD as
Required
As-Designed Audit Process
ICD Part II
Conduct As-Designed Audit Activities:
ConductAs-Built AuditComparison
Modify Drawing/Assembly/ICD as
Required
ConductAs-Designed
AuditComparison
ConductIssue Resolution
w/ PG/IP
As-Designed Audit Report
Prepare As-Built
Audit ReportInterface A
As Mated Process
Lesson: Consistent, cyclical assessment of interfaces avoids many late issues
Michael Wood, PM Challenge 2010.ppt pg. 16
Element and Stage Verification Supporting CoFR
Certification of Flight
Readiness
InterfaceCompatibility(DPA, CA,
FA)
Hardware /Software
(SM, Lab, S0, P1, Soyuz…)
VerificationClosureStrategy
DVOsTDSs
End Item DevelopmentRequirements Development
Verification Planning/Requirements
Integrated StageVerification
IntegratedAnalyses
(DAC/VAC)Verification
Report
IntegratedTests
(SVF, HSI, Joint)AIRD
Stage Rqmnt
n...
AIRDStage Rqmnt
(n)
USOS&
IP&PRqmnt
ISSRqmnt
End Item“A”
Spec
Assy CompRqmnt
AssyComp
UniqueRqmnt
UniqueRqmnt
TestData
Verification Logic Network ITVR/LTVR
Functional Configuration and Physical Configuration
Audit
Lesson: Iterative Design Analysis Cycle (DAC)/Verification Analysis Cycle (VAC) process ensured the evolving assembly sequence was supportable
Stage 4A
Stage 7A
Stage 15A
Stage 4A
Stage 7A
Stage 15A
Michael Wood, PM Challenge 2010.ppt pg. 17
• 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
Systems IntegrationOther Lessons Learned
Michael Wood, PM Challenge 2010.ppt pg. 1818
• 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.
Systems IntegrationOther Lessons Learned (Cont’d)
Michael Wood, PM Challenge 2010.ppt pg. 1919
• 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
Systems IntegrationOther Lessons Learned (Cont’d)
Michael Wood, PM Challenge 2010.ppt pg. 20
PROGRAM INTEGRATION
Overarching Lesson: Programs should be viewed and architected as a system
Michael Wood, PM Challenge 2010.ppt pg. 21
ISS Has Gone Through PM Changes
Space Station Freedom ISS
NASA
Work Package 1(MSFC/Boeing)
SE&I(Reston/Grumman)
Work Package 2(JSC/McDonnel)
Work Package 4(Rocketdyne)
NASA
Boeing
SubcontractorsSubcontractors
SubcontractorsSubcontractors
Subcontractors
InternationalPartners
Non-prime GFENon-prime GFENon-prime GFENon-prime GFENon-prime GFE
SpaceStation Freedom
International Space StationRDT&E
RDT&E
O&STran
sitio
n
Transition
• The program experienced a significant transition from SSF to ISS
• Applicable lessons learned occurred in both program environments
Michael Wood, PM Challenge 2010.ppt pg. 22
Lessons from Space Station Freedom (SSF)
Environment• 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• Challenges in managing program
and technical baseline– Minimal collaboration across
development work packages– Lack of program/technical health
status– Inconsistent interfaces at program
PDR/CDR
No Contract VehicleBetween Developers/Integrator
Data Flow toIntegrator & Across
Developers Disconnected
Michael Wood, PM Challenge 2010.ppt pg. 2323
• Program Design– Establish and manage to realistic scope– Build capability incrementally– Implement clear and streamlined decision
authority– Ensure subordinate contracts and
associated contract deliverables (cost, schedule, technical) map to and support the 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
ISS Lessons LearnedProgram Integration
NASA
Boeing
SubcontractorsSubcontractors
SubcontractorsSubcontractors
Subcontractors
InternationalPartners
Non-prime GFENon-prime GFENon-prime GFENon-prime GFENon-prime GFE
Michael Wood, PM Challenge 2010.ppt pg. 24
• 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– Budget with adequate program reserve
• 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
• Risk and Opportunity Management– Intentional opportunity management – Continually work mitigation and
opportunity plans
ISS Lessons LearnedProgram Integration (Cont’d)
• Plan Changes• Environmental
Changes• Technical, Schedule,
Cost Trends• Independent Reviews• Concurrency Risks Built-in to the Plan
• Elements requiring qualification, testing, etc.
Constrained Budgets
RisksRisksIssuesIssues
OpportunitiesOpportunities
• Partnering• Affordability• Product Maturity• Technology Insertion
Realized Risks Failed Tests or QualificationsDiscoveries/Findings
• Cycle Time Reduction• Pre-planned Product Improvement• Innovation and New Developments• Cost Reduction Initiatives (CRIs)
•Conditions Out of Sight (Suppliers, Customers)
• Plan Changes• Environmental
Changes• Technical, Schedule,
Cost Trends• Independent Reviews• Concurrency Risks Built-in to the Plan
• Elements requiring qualification, testing, etc.
Constrained Budgets
RisksRisksIssuesIssues
OpportunitiesOpportunities
• Partnering• Affordability• Product Maturity• Technology Insertion
Realized Risks Failed Tests or QualificationsDiscoveries/Findings
• Cycle Time Reduction• Pre-planned Product Improvement• Innovation and New Developments• Cost Reduction Initiatives (CRIs)
•Conditions Out of Sight (Suppliers, Customers)
Michael Wood, PM Challenge 2010.ppt pg. 25
• 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
ISS Integration Lessons LearnedSummary and Conclusions
Overarching Lesson: Programs should be viewed and architected as a system
Michael Wood, PM Challenge 2010.ppt pg. 26
Questions?
Thank You