1. Innovation You Can Count On™ 1 Payload Integration Wendi Otto Systems Engineer, Pegasus and Taurus Launch Vehicles October 4, 2007 All Information Approved for Public Release.

2. Payload Integration All Information Approved for Public Release 04 October 20072 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 PayloadLaunch Vehicle Payload

3. Payload Integration All Information Approved for Public Release 04 October 20073 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

4. Payload Integration All Information Approved for Public Release 04 October 20074 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

5. Payload Integration All Information Approved for Public Release 04 October 20075 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

6. Payload Integration All Information Approved for Public Release 04 October 20076 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

7. Payload Integration All Information Approved for Public Release 04 October 20077 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

8. Payload Integration All Information Approved for Public Release 04 October 20078 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

9. Payload Integration All Information Approved for Public Release 04 October 20079 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)

10. Payload Integration All Information Approved for Public Release 04 October 200710 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.

11. Payload Integration All Information Approved for Public Release 04 October 200711 The “V”

12. Payload Integration All Information Approved for Public Release 04 October 200712 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.

13. Payload Integration All Information Approved for Public Release 04 October 200713 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

14. Payload Integration All Information Approved for Public Release 04 October 200714 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

15. Payload Integration All Information Approved for Public Release 04 October 200715 Sample Spacecraft I&T Activity

16. Payload Integration All Information Approved for Public Release 04 October 200716 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

17. Payload Integration All Information Approved for Public Release 04 October 200717 Sample Spacecraft Test Flow

18. Payload Integration All Information Approved for Public Release 04 October 200718 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

19. Payload Integration All Information Approved for Public Release 04 October 200719 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