Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 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, 2009Used with Permission
  2. 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. 3. Characteristics of a Large Scale Space Program Large Scale Space Program Relevance to ISS Program CharacteristicsLarge geographically and • Teams (NASA and contractors) located all over the countryculturally diverse team • Multiple International Partners had to be engage across the globeSpace based systems • ISS had to address the complex and critical functions and needs inherent with space explorationHuman rated systems • Human rated systems can be complex and ISS had to integrate the human rated requirementsMix of existing and new • ISS had to balance the need for new technologies with existingtechnology technologyEvolving multiyear incremental • Incremental build up of capability over timecapability • 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. 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. 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. 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. 7. SYSTEMS INTEGRATIONOverarching Lesson: With the end in mind, plan and work the integration task from day Wood, PM Challenge 2010.ppt Michael one pg. 7
  8. 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 AsComponent 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. 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 DiagramsTrackingData 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. 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. 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 SupportVerification - IRD/ICD Detailed Verification Requirement NeedsA set of activities performed A logical collection of DVOs used toto ensure that facilities, prepare test plans, procedures,hardware & software demos, inspections, analyticalproducts, & assembly models, etc. with similar groupingprocedures are in Electronic characteristics, i.e. all passive thermalcompliance with program Database analysis DVOs for the samespecification 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. 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 OrbitalReplacement 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. 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. 14. ISS Lessons Leaned Digital Pre-Assembly Interface AssessmentView 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. 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 MatesAs-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 BAs-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. 16. Element and Stage Verification Supporting CoFRRequirements 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 VerificationLesson: 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. 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. 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. 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. 20. PROGRAM INTEGRATIONOverarching Lesson: Programs should be viewed and architected as a system Michael Wood, PM Challenge 2010.ppt pg. 20
  21. 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 PartnersWork Package 1 SSF to SE&I from ISS (MSFC/Boeing) (Reston/Grumman) Boeing • Applicable lessons learned occurred in bothWork Package 2 program environments(JSC/McDonnel) Subcontractors SubcontractorsWork 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. 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 integratorResult 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. 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. 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. 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. 26. Questions?Thank You Michael Wood, PM Challenge 2010.ppt pg. 26