Page No. 1 ISS_CM_019 (Rev 09/2011) Pre-decisional, For Internal Use Only Payload Integration Template ISS-SRB-RSP-017 Date: January 28, 2014 Presenter’s Name: Ryan Prouty

Page No. 2 ISS_CM_019 (Rev 09/2011) Pre-decisional, For Internal Use Only Background In accordance with NASA Agency-level guidance, a Program Implementation Review (PIR) was scoped to focus upon Sustainment and Utilization of the ISS. The Standing Review Board spent ~5 months reviewing program operations. Face to Face meetings with each office were conducted at the Johnson Space Center from May 13-17, The board presented its findings to the ISS Program in June 2013

Page No. 3 ISS_CM_019 (Rev 09/2011) Pre-decisional, For Internal Use Only Payload Integration Template Length Issue 7 from the Standing Review Board outbrief: –The payload integration template is still too long to attract many users (including investigators and payload developers) and too difficult for them to navigate. The template length is not only costly to users, but it also results in many users not being interested in participating. In short: –Too Long –Too difficult to navigate –Costly to users

Page No. 4 ISS_CM_019 (Rev 09/2011) Pre-decisional, For Internal Use Only SRB Recommendation Even given the existing important efforts to shorten the integration template, the ISS Program needs to do more to address this problem and decrease the integration length to six months. The complete template should be subjected to a rigorous lean process improvement analysis and correction from end to end and across all contributing organizations. Each step in the process should be analyzed concerning its length and appropriateness and critical paths should be identified. In addition, the ISS Program needs to clearly identify all of the possible entry points for experiments or payloads with differing levels of maturity. The goal should be to meet the user on his schedule and not be a constraint. Payload software should be partitioned to minimize NASA integration.

Page No. 5 ISS_CM_019 (Rev 09/2011) Pre-decisional, For Internal Use Only Recommendations – broken out Decrease the integration length to six months*. Clearly identify all of the possible entry points for experiments or payloads with differing levels of maturity. Meet the user on his schedule and not be a constraint. Partition payload software to minimize NASA integration. *Note: Not all payloads require 6 month templates; more complex may require more, reflight, less. The activity will focus on allowing payload design/readiness define the template required for final integration.

Page No. 6 ISS_CM_019 (Rev 09/2011) Pre-decisional, For Internal Use Only Big Picture The Payloads Integration Template is a highly complex, integrated collection of individual processes and stakeholders. Over time, new processes and interfaces were established to produce the required products for each individual program office with the ease of program operations in mind. The new approach is one that intends to have the customer in mind – a shift in the paradigm from how we are doing business today.

Page No. 7 ISS_CM_019 (Rev 09/2011) Pre-decisional, For Internal Use Only Payload Integration Template Approach SRB-RSP-017 has been separated in to 5 areas of approach; 2* are highlighted separately as areas of emphasis for OZ –Generically assess entire template, identify areas of duplicity, unnecessary overhead, and inefficiency; rebuild those areas through cooperation with CAM stakeholders (OZ, OC, ON, OD, OB, OM, OE) –Solicit input and suggestions from the customer; merge this with changes from generic assessment (OZ, CASIS, Customer) –Perform Kaizan on the Payload Ops Integration Template (POIF, OZ) –Improve the safety process, including requirement applicability and hazard definition (OE, OZ, OB, EA)* –Improve the ICD process for generation and verification of requirement sets (OB, ON, OZ)*

Page No. 8 ISS_CM_019 (Rev 09/2011) Pre-decisional, For Internal Use Only Payload Integration Template: Areas of Approach P/L Ops and Int Safety Certification ICD Generation ICD Requirements Verification Payload Integration Template (OZ Charter Team-Internal; CASIS Team-External) PDR CDR Launch Payload Manifested Safety Phase II Safety Phase 0/I Safety Phase III TACTICALSTRATEGICOPS

Page No. 9 ISS_CM_019 (Rev 09/2011) Pre-decisional, For Internal Use Only Where to start? Navigation 101 You need to know where you are starting In order to get to where you want to go.

Page No. 10 ISS_CM_019 (Rev 09/2011) Pre-decisional, For Internal Use Only Evaluate and Rebuild OZ SRB Charter Team will assess and redefine template through kaizen activities. –SIPOC build of the current process to integrate a payload for launch –Will pull in stakeholders as required to understand the current template and areas where we can improve CASIS Co-leading payload customer evaluation of template –Input will focus on what the customer believes they need to provide in order to safely fly to and operate on the ISS Results will be assessed for disconnects and similarities –Implement/realize short term improvements/wins –Identify team and schedule to implement long term changes Changes to be communicated within the community through various means –POIWG, PIP, RICB, PIM/RIM Communications, in person site visits

Page No. 11 ISS_CM_019 (Rev 09/2011) Pre-decisional, For Internal Use Only Other Areas of Focus Based on feedback from existing PDs and stakeholders within the program, the following areas will have stand alone teams dedicated to improving the service to customers: –Safety Certification (Covered by T. Sang) –Payload Ops and Integration (POIF) (Covered by C. Price) –ICD Generation (Led by OB/P. Rathbun and Boe/D. Brueneman)

Page No. 12 ISS_CM_019 (Rev 09/2011) Pre-decisional, For Internal Use Only OB ICD Process Goals Goal 1: Provide requirements rationale for all payload Interface Requirements Documents (IRDs) and assess each for risk, perform requirements quality measurements, and review for recurring exceptions Goal 2: Assess format and content of payload specific ICDs and determine if Program tools (ORBIT/VERITAS) can be used to automate applicable requirement sets Goal 3: Assess and standardize criteria for when PDs need to formally assess and provide new verification for: –Requirements changes, –Re-flight of same or series hardware (re-flight), –On-orbit configuration changes (re-verification) Goal 4: Incorporate EXPRESS and ELC complement analyses into stage analysis Goal 5: Document payload system engineering processes in a Program level SSP document

Page No. 13 ISS_CM_019 (Rev 09/2011) Pre-decisional, For Internal Use Only Upcoming Activities DateActivity Sept 13 - Jan 14PIT Revision, Baseline for SRB Action Nov 2013Safety Requirement Mapping (JSC) Nov 2013Site Visit – KSC, Gathering Feedback Jan 2014Site Visit – Ames, Gathering Feedback Feb 2014Kick off ICD Teams Feb – Aug 2014Revamp Safety Documentation Feb 3-7POI Template Kaizen (MSFC) Feb 18-19PIT SIPOC Kaizen, Current State (JSC) March 3-5PD/CASIS TIM (Bioserve)

Page No. 14 ISS_CM_019 (Rev 09/2011) Pre-decisional, For Internal Use Only Let me hear from you… Opportunity exists to evolve the payload integration template to meet the needs of the payload customer and that of the Program. We can work to improve only what we know is not working.

Page No. 15 ISS_CM_019 (Rev 09/2011) Pre-decisional, For Internal Use Only Back Up

Page No. 16 ISS_CM_019 (Rev 09/2011) Pre-decisional, For Internal Use Only Area 2: Improve the Safety Process Description of Today’s State: Many payload customers are not familiar with the NASA safety culture and are not prepared to write safety products in the style to which NASA is accustom. –Customers experience feedback for numerous administrative edits and rewrites. –Customers view the safety process as lacking decisional, progressional accountability. –Current process entertains readdressing closed/resolved issues raised by anyone at any point in the process. Result is that customers “…can’t tell when they will get done”. –Payload hardware criticality rating is automatically increased by one level of severity, requiring it to have more controls than systems. –Requirements documentation is inconsistent between systems and payloads. –Customers are performing NASA integration between the PSRP, PSE’s and engineering SME’s.

Page No. 17 ISS_CM_019 (Rev 09/2011) Pre-decisional, For Internal Use Only Area 2: Improve the Safety Process The Vision: –Document one consistent set of ISS Safety requirements (SSP 50021) that applies to both systems and payloads with a transparent process that includes clearly defined gates and a measurable end. –PSRP take responsibility to answer questions that need to be vetted particularly within NASA. –Provide assistance to new developers to coach/valet them through the process. Items in Progress: –Mapping of system and payload safety requirements documentation; intention being to ensure payload safety requirements reflect the maturity of the program and are consistent with system requirements. –Assign SMEs to review, assess, and revalidate or update each requirement for proper applicability to the current vehicles; document requirement rationale –Provide safety product templates that are easy to fill out with examples to minimize administrative rework. Edit and sign products real time.

Page No. 18 ISS_CM_019 (Rev 09/2011) Pre-decisional, For Internal Use Only Area 3: Improve the ICD process Description of Today’s State: Multiple ICD owners across the program, each having different templates and processes for creating, reviewing, baselining, and updating requirement documentation. –Payload developers are required to provide duplicate inputs to numerous ICD’s (robotics, FRAM, external carrier, cargo vehicle, etc.). –ICD owners ping payload customers directly for the same data, in different formats at different times, increase the chance for error. –Processes are confusing and time consuming to the payload customer. –Visiting Vehicle ICD generation templates follow launch dates, not payload development; requirements are being defined after payload design is finalized. –The process to track ICD generation and updates is administratively burdensome

Page No. 19 ISS_CM_019 (Rev 09/2011) Pre-decisional, For Internal Use Only Area 3: Improve the ICD process The Vision: “The right engineering at the right time.” Items in Progress: –OB formed teams to meet 5 primary goals in the improvement of the payload specific ICD process Assess and improve Interface Requirements Documents (IRDs) Assess format and content of ICDs; automate as possible Assess and standardize criteria for when PDs need to formally assess and provide new verification (work reduction) Incorporate EXPRESS and ELC complement analyses into stage analysis Document payload system engineering processes in a Program level SSP document –ON accepted SpX proposal for streamlined SpX ICD generation –ON and OB data gathering formats and timing to be integrated

Page No. 20 ISS_CM_019 (Rev 09/2011) Pre-decisional, For Internal Use Only OD Software Stratification OptionTimeTitleCapability 1XPantry LaptopNo network, data via thumb drive 2X+JNetwork Pantry LaptopJSL Connect; JSL Testing required 3X+J+?Payload SSC-Single UserJSL/Operating System; minimal integration testing 4X+J+IPayload SSC-SharedMultiple Users on one SSC; Integration testing required to protect all users of the laptop 5X+J+I+PTraditional Facility (EXPRESS, WORK, HRF, SSC) Platform testing Laptop minimum lead time = X wks for SE&I to process a Certificate of Completion Laptop options: X plus time for each additional capability