Kevin Vipavetz Senior Systems Engineer Langley Research Center, NASA

INCOSE WMA SEDC 2014 Conference:New and Emerging Applications and Trends in Systems Engineering

Copyright © 2014 by Kevin Vipavetz LaRC, NASA Permission granted to INCOSE to publish and use.

Emerging Interface Management Approach from Two NASA Space Flight Projects

Kevin VipavetzSenior Systems Engineer

Langley Research Center, NASAEmail: [email protected]

Phone 757-864-3817



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

2



Examples from Two ProjectsMaterials International Space Station Experiment-X

(MISSE-X) Ares I-X

3



Project OverviewsMISSE-X• 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

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

4



What is an Interface?

5

• 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



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

o Examples: material, structure, mass, loads…

– The characteristic of what is crossing the interfaceo Examples: current, data, strain, sheer, fluid, heat…

– What is the media of the interactiono Examples: attachment bolts, wires, pipes, environment…

6



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

7



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

8



Starts with good requirements

• LMS-CP-5526 “Product Requirements Development and Management Procedure”

• Available on request, send me an email [email protected]

9



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

10



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

11



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

12



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

13



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

14



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

15



Interface Requirement vs. Interface DefinitionExample

16

• 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

System Requirements Document (SRD) contains interface requirements

Interface Control Document (ICD) contains the interface definitions



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)

17



SRD - Evolving ICD (Ares I-X)

18



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

19



SRD - Existing ICD (MISSE-X)

20



Using a Shadow ICD (MISSE-X)

21



MISSE-X Example

22



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

23



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

24



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

25



Verification



Integrate (Validation, Transition)

Verify interfaceVerify interface

Subsystem A Subsystem B

Integrate

Element A Element B

Integrate

System

Verify interface

Verify interface

Verify

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.



Questions?

28

Kevin Vipavetz Senior Systems Engineer Langley Research Center, NASA

Documents

Transcript of Kevin Vipavetz Senior Systems Engineer Langley Research Center, NASA