Innovation You Can Count On™

1

Payload Payload IntegrationIntegration

Wendi Otto

Systems Engineer, Pegasus and Taurus Launch Vehicles

October 4, 2007

All Information Approved for Public Release.

04 October 2007 2

Payload Integration

All Information Approved for Public Release

What is a Payload?

● Payload: Any mission-specific hardware or software Any customer provided hardware or software for which the service is being

supplied For a spacecraft, the “payload” is usually the instruments, sensors, or

something less tangible For a launch vehicle, the “payload” is the spacecraft

Spacecraft Payload Launch Vehicle Payload

04 October 2007 3

Payload Integration

All Information Approved for Public Release

What is Payload Integration?

● Payload Integration: Incorporating the payload items (hardware or software) into the standard vehicle

● For every mission, an integration team is created with representatives from all customer and contractor organizations Technical team is made up generally of representatives with “big-picture”

knowledge of their particular component Integration team pulls on knowledge from all organizations and disciplines to

ensure that all payload needs are met An integration team is always present at various times during the life of a

program, with additions as contracts are awarded Launch vehicle integration teams generally start about two years prior to

expected launch

● Payload integration is considered a responsibility of either Systems Engineering or Integration and Test (I&T) Relies on experience, expertise, and the ability to learn from past mistakes Integrators play a dual role: being the voice of the payload and the voice of

the vehicle

04 October 2007 4

Payload Integration

All Information Approved for Public Release

Phases of Payload Integration

● Phase 1: Learn Your Payload● Phase 2: Define Requirements● Phase 3: Design the Interface● Phase 4: Build and Implement the Interface● Phase 5: Test, Test, Test● Phase 6: Operations

04 October 2007 5

Payload Integration

All Information Approved for Public Release

Learn Your Payload

● First few months (or more) is the time to learn about and understand the payload For a spacecraft, this starts during the initial

proposal process Extremely involved process as the

spacecraft’s purpose is to run the payload For a launch vehicle, this starts after contract

award (generally around spacecraft PDR time) In depth knowledge can be limited to

interfaces of interest

● Understand the payload purpose, objectives, and mission

● Understand what is critical, what is needed, and what is wanted

● Understand the most important items and what can be traded

04 October 2007 6

Payload Integration

All Information Approved for Public Release

Define Requirements

● Take the payload’s needs and wants and turn them into verifiable requirements

● Requirements are documented in Interface Control Documents (ICDs) Usually consists of a main document and a series of mechanical, electrical,

and/or software subdocuments ICDs, when used together, should completely define the interface to be

provided Approved by all customer and contractor parties

● What is a requirement? A statement of need Defines what the product must achieve Communicates expectations

● Why are requirements important? Identifies required functionality Guides design decisions and helps prioritize work to be done Completion shows that the final product will meet mission goals

04 October 2007 7

Payload Integration

All Information Approved for Public Release

Define Requirements (cont.)

● What makes a good requirement? Clear, concise, and unambiguous States a single result Specifies functionality – not implementation Attainable Verifiable Clear assignment of responsibility

● Bad Requirement: Launch vehicle hardware must be clean. Does not specify hardware to be cleaned, the level of cleanliness, or how the

cleanliness will be verified

● Good Requirement: Launch vehicle hardware surfaces within the fairing encapsulated volume shall be cleaned to VC-HS+UV level per JSC-SN-C-0005D. Specifies the exact surfaces to be cleaned, gives a level of cleanliness, and

points to a document that describes verification

04 October 2007 8

Payload Integration

All Information Approved for Public Release

Types of Requirements

● Requirements can be written for: Any flight subsystem or non-flight provision Either the payload or the vehicle

● Requirement categories include: Mission Design

Orbit Requirements Mission Operations Separation Dynamics Special Maneuvers

Mechanical Interfaces Coordinate Systems Fastener Patterns and Tolerances Critical Dimensions Isolation Mounting Mass Properties

Electrical Interfaces Command, Telemetry, or Pyro Connections Wire Diagrams and Interface Connector Pin-Outs Connector Types

Spacecraft Subsystems

04 October 2007 9

Payload Integration

All Information Approved for Public Release

Types of Requirements (cont.)

● Requirement Categories Include (cont.): Software Interfaces

Command, Telemetry, Communications Formats and Protocols

Contingency Operations Environments

Vibration Shock Acoustics Pressures RF Thermal and Humidity Contamination

Operations Facility Requirements for Integrated

Activities Provisions of Non-Flight Hardware (GSE)

04 October 2007 10

Payload Integration

All Information Approved for Public Release

Requirements Verification

● All requirements must be verifiable!● Four classically accepted verification methods

Inspection Examination of documentation or direct examination of the attribute Examples: review of vendor documentation, inspection records, etc.

Analysis Using generally accepted analytical techniques to show proper results or margins Examples: GN&C orbit analyses, separation simulations, loads modeling, etc.

Test Operation of all or part of the system under controlled conditions to determine that

quantitative requirements have been met Examples: electrical interface verifications, vibration testing, etc.

Demonstration Operation of all or part of the system under controlled conditions to determine that

qualitative requirements have been met Examples: target testing, component fit checks, etc.

04 October 2007 11

Payload Integration

All Information Approved for Public Release

The “V”

04 October 2007 12

Payload Integration

All Information Approved for Public Release

Design the Interface

● With the requirements documented, determine the appropriate implementation with the following considerations: Satisfy the Requirement Verification Method (especially inspection and test)

Consider last-chance verification for inspection Consider test setups, procedures, and practices No configuration changes after final verification

Cost and Schedule Budget constraints or long-lead items

Flight History Implement the same or similar designs that have been used previously Signification deviations could require a new qualification

Ease of Implementation Time = $$$

Safety All designs must be approved by internal, customer, and Range safety organizations

Budget Constraints Mass and power budgets are controlled by Systems Engineering and delegated over all

subsystems Subsystems have other budgets such as RF link, propellant, computer processor, etc.

04 October 2007 13

Payload Integration

All Information Approved for Public Release

Design the Interface (cont.)

● Designs implemented for payload items are subject to customer reviews● Typical reviews include

Mission Unique Requirements Review (MURR) Present complete listing of payload requirements to ensure all parties are working to

the same expectations Mission Unique Preliminary Design Review (MUPDR)

Top level design for payload provisions to demonstrate that requirements can be met

Mission Unique Critical Design Review (MUCDR) Detailed design for payload provisions to show satisfaction of all requirements

before procurement or manufacturing of hardware Mission Unique Systems Acceptance Review (MUSAR)

Final review of all as-delivered and tested hardware to show readiness for launch

04 October 2007 14

Payload Integration

All Information Approved for Public Release

Build and Implement Interface

● For procured components (from outside vendors) Write subrequirements documents, hardware specifications, and contractual

statements of work Track progress of hardware and complete periodic verifications as required Accept hardware when complete

● For manufactured components (made internally) Ensure that manufactured hardware meets requirements through all stages of

build process Test all items at component level prior to acceptance of item

● All components or subsystems must be verified at the subsystem level prior to installation into a larger system

04 October 2007 15

Payload Integration

All Information Approved for Public Release

Sample Spacecraft I&T Activity

04 October 2007 16

Payload Integration

All Information Approved for Public Release

Test, Test, Test

● “Test as You Fly, Fly as You Test” A slogan born from 50 years of long, heartbreaking history All tests should directly verify the item at hand in a flight configuration No functionality should be unverified at time of flight No science experiments on flight hardware

● Test and/or demonstration are the best verifications possible because actual functionality under the appropriate conditions has been shown As many requirements should be test verified as possible Some Military and NASA standards define the types of subsystems that require

test and the margins associated with these testing However, overall test scenarios are constructed on a Program specific basis

depending on the needs of the vehicle Payload interface items are included in baseline vehicle testing

● Testing should start at the lowest possible subsystem level and occur at each level of system build-up Want to catch issues as early as possible with minimal chance of bringing down

another system

04 October 2007 17

Payload Integration

All Information Approved for Public Release

Sample Spacecraft Test Flow

04 October 2007 18

Payload Integration

All Information Approved for Public Release

Operations

● To demonstrate flight readiness, all requirements must be checked off as verified by the designated method

● End of payload integration is capped by a series of internal and customer reviews to evaluate results

● “Operations” are planned well in advance, but this phase technically begins when the flight hardware integration and testing is complete

● Ground Operations Payload processing and transfer to launch site Transport and/or Pad Operations Pre-flight preparations

● Flight Operations Definition of launch constraints Definition of launch checklist steps Remove before flight items and flight closeouts

● The payload integrators goal: get a payload to launch day with the highest possible confidence in the interface provisions

04 October 2007 19

Payload Integration

All Information Approved for Public Release

Wendi’s Unwritten Rules of Payload Integration

1. You can not defy the laws of physics

2. Mistakes will be made

3. Details will be forgotten until the worst possible time

4. Tempers will flare

5. Payloaders will never let go