1 / 28

Kevin Vipavetz Senior Systems Engineer Langley Research Center, NASA

­­­­­­­­­­­­­­­­­­­­­­­­­­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. Agenda. Ares I-X and MISSE-X overview Interface Definition

odin
Télécharger la présentation

Kevin Vipavetz Senior Systems Engineer Langley Research Center, NASA

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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?

More Related