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


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


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


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


SYSTEMS INTEGRATION

Overarching Lesson: With the end in mind, plan and work the integration task from day one


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


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


• 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


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


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


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


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


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


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


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


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


• 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


• 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)


• 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)


PROGRAM INTEGRATION

Overarching Lesson: Programs should be viewed and architected as a system


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


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


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

http://i10.photobucket.com/albums/a114/Sir_Stinkalot2525/IMG_5097.jpg�


• 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



Subcontractors

InternationalPartners

Non-prime GFENon-prime GFENon-prime GFENon-prime GFENon-prime GFE


• 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)


• 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


Questions?

Thank You

wood.michael

Technology

system integration

systems iss

pm challenge

validation program integration

program size

program participants

program executionmichael

complex system