Kevin Vipavetz Senior Systems Engineer Langley Research Center, NASA

1. ­­­­­­­­­­­­­­­­­­­­­­­­­­Emerging Interface Management Approach from Two NASA Space Flight Projects Kevin Vipavetz Senior Systems Engineer Langley Research Center, NASA Email: Kevin.G.Vipavetz@nasa.gov Phone 757-864-3817

2. Agenda • Ares I-X and MISSE-X overview • Interface Definition • Systems Engineering Management Plan and Interface Working Group • Starts with good requirements • Seven Step Approach • Interface requirements, What goes in the SRD and ICD • Accountability • Interface Document Baseline Process • Verification and Transition

3. Examples from Two Projects Materials International Space Station Experiment-X (MISSE-X) Ares I-X

4. Project Overviews MISSE-X Ares I-X Test project within the NASA Constellation Program First stage prototype in a series of flight tests to develop a new crew launch vehicle to replace the Space Shuttle Won the 2009 Time magazine Invention of the Year Award LaRC was awarded the NASA’s prestigious Systems Engineering Award of Excellence • MISSE-X is an external ISS platform for space environmental studies in the post-Shuttle era to advance the technology readiness of materials and devices critical for future space exploration • Capitalizes on eight prior missions • MISSE-8 is currently still in operation on ISS • Fined tuned Ares I-X interface management approach

5. What is an Interface? • An Interface is a common functional or physical boundary between two systems of interest where they interact • Each interface can be considered to have a source, destination, and some means to allow interaction Reference: Louis S. Wheatcraft, Compliance Automation, Inc. “Everything you wanted to know about interfaces, but were afraid to ask” http://www.reqexperts.com/requirements-whitepapers.html

6. What is an Interface Definition • The interface definition defines the boundary between the two sides • To develop an interface definition each side must know: • The characteristics of each system at the interface • Examples: material, structure, mass, loads… • The characteristic of what is crossing the interface • Examples: current, data, strain, sheer, fluid, heat… • What is the media of the interaction • Examples: attachment bolts, wires, pipes, environment…

7. Systems Engineering Management Plan (SEMP) • The Lead Systems Engineer should develop the SEMP as soon as possible to manage the technical side of the project • The NPR 7123.1B “NASA Systems Engineering Processes and Requirements”, is a good outline for SEMP development • The SEMP should be a baseline document during project formulation stage • How interfaces are to be managed by the project are captured in this document

8. Interface Working Group (IWG) • Essential to interface development • Involves the appropriate parties and subject matter experts • Used to plan development and control of interface processes • Used to help identify interfaces • Used to define interface definitions • Review change requests • Lays the groundwork for binding agreements between all applicable organizations

9. Starts with good requirements • LMS-CP-5526 “Product Requirements Development and Management Procedure” • Available on request, send me an email Kevin.G.Vipavetz@nasa.gov

10. Good Requirements • Good requirements are critical to having successful verifications • Requirements should be: • Feasible, technical achievable • Product oriented • Concise, using the “Who shall do What “ format • Single statement • Measureable / Verifiable • Contain rationales (key to defining good verification activities and success criteria) • Traceable

11. Ares I-X Seven Step Approach 1. Identify • Perform interface analysis to identify interface boundaries 2. Capture • Capture interface requirements in requirement documents • Place under configuration control 3. Define • Develop interface definitions or determine applicable interfaces for pre-existing interface documents • Place under configuration control 4. Allocate • Flow down any interface requirements to next level

12. Seven Step Approach cont… 5. Verify • Define interface verification activities and success criteria • Conduct verification activities • Place results under configuration control 6. Comply • Write up verification compliance reports • Responsibility of the interface requirement owners • Interface requirement owners start the configuration control process for closeout and approval 7. Integrate • After assembly and testing of an interface side, flow up to next level and checkout integrated interfaces • Repeat steps five through seven until system is complete

13. Interface Requirement vs. Interface Definition • Interface requirements are placed in the systems requirement documents • The interface requirements do not belong in ICDs • There are no “shall” statements in an ICD • Interface definitions are the design solutions to the interface requirements and the success criteria of the verification requirements

14. Interface Requirement vs. Interface Definition cont … • Interface requirements state what the interface needs to do • Never say, “ shall interface with …” (very vague) • Interface requirements point to what ICD will be used and where it is found in the ICD • Interface requirements can share ICDs at different levels

15. Interface Requirement vs. Interface Definition cont … • Interface requirements should mirror the definitions in the ICD table of contents • Have a one–to–one correspondence to a category or definition • Interface requirements should be resource loaded via requirement owners (a requirements attribute) • Consider how you want to have interfaces managed and verified • Assign requirement owners accordingly for each interface requirement

16. Interface Requirement vs. Interface DefinitionExample System Requirements Document (SRD) contains interface requirements Interface Control Document (ICD) contains the interface definitions • Sys 2 shall obtain power from Sys 1 per the connections defined in ICD 2345 Drawing 3-4 • Sys 2 shall operate on power obtained from Sys 1 having the characteristics defined in ICD 2345 Table 3.6 • Drawing 3-4 contains the connector, pin assignments, and grounding information in order to obtain power • Table 3-6 contains power characteristics such as voltage, current, noise, filtering

17. Interface Attributes • Interface Requirement • Rationale (Justification) • Trace (Identifies parent) • Allocation (Points to child, corresponding architecture link one level down) • Verification Method (Inspection, Analysis, Demonstration, Test) • Owner (Accountable person) • Interface Definition • Rationale (How it was defined) • Trace (Link to interface requirement) • Agreement (Used to bind the agreeing parties, not covered in contracts, on who will cover what in the interface development)

18. SRD - Evolving ICD (Ares I-X)

19. Ares I-X Evolving ICD Baseline Process • An ICD can be an evolving document • Rank interface definitions as Draft, Pending, or Baseline within the ICD • Use this to handle independently evolving definitions • Reduces delays in interface implementation by allowing sections that are baselined to proceed with development without waiting for the whole ICD to be completed

20. SRD - Existing ICD (MISSE-X)

21. Using a Shadow ICD (MISSE-X)

22. MISSE-X Example

23. Accountability (Ares I-X) • Accountability is different from responsibility • The team is responsible for helping develop interfaces, only one is accountable • Assign Interface Custodians for each interface document • Maintains documentation (“book manager”) • Accountable for ensuring the interfaces are complete, are following processes, helps track changes, and herds the cats • Essential in developing interface agreements between external partners • Assign Interface Requirement Owners for each interface requirement or group of requirements

24. Requirement Owners • Requirement owners are key to getting the good requirements developed and verified • They are not the requirement manager • They are part of the whole project life cycle • Accountable for lifecycle development, verification, implementation, and compliance of the assigned interfaces • Requirement owners will define the verification activities, success criteria, develop compliance reports, and start the signature process for verification approval

25. Verification Requirement Definition Sheet (VRDS) • An Ares I-X tool used to manage product verification from planning to closure • One per corresponding requirement • The collection of sheets forms a Verification Compliance Document • The Requirement Owner manages each sheet • VRDS includes: • Verification requirement (shall statement) • Summary of planned measurement activities with rationale and success criteria • References/pointers or links to verification artifacts • Captures closeout information (compliance statement and signatures) • Owner of parent requirement confirms planned activities

26. Verification

27. Integrate (Validation, Transition) System Interface complete • Not necessary to wait for the other side to complete their interface verification to begin compliance closeout (acceptance) • After closeout at a lower level, each side can move up for checkout (validation) and integration (installation) at the next level up • Transition is delivery, installation, and acceptance • Note: All validation, transition, and acceptance plans are made during design. Verify System Integrate Verify interface Element A Element B Verify interface Integrate Subsystem A Subsystem B Verify interface Verify interface

28. Questions?