Presentation - SEDC Conference 2014

Download Report

Transcript Presentation - SEDC Conference 2014

Emerging Interface Management Approach from
Two NASA Space Flight Projects
Kevin Vipavetz
Senior Systems Engineer
Langley Research Center, NASA
Email: [email protected]
Phone 757-864-3817
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.
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
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.
2
Examples from Two Projects
Materials International Space
Station Experiment-X (MISSE-X)
INCOSE WMA SEDC 2014 Conference:
New and Emerging Applications and Trends in Systems Engineering
Ares I-X
Copyright © 2014 by Kevin Vipavetz LaRC, NASA
Permission granted to INCOSE to publish and use.
3
Project Overviews
MISSE-X
Ares I-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
•
•
•
INCOSE WMA SEDC 2014 Conference:
New and Emerging Applications and Trends in Systems Engineering
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
Copyright © 2014 by Kevin Vipavetz LaRC, NASA
Permission granted to INCOSE to publish and use.
4
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
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.
5
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 interface
o Examples: current, data, strain, sheer, fluid, heat…
– What is the media of the interaction
o Examples: attachment bolts, wires, pipes, environment…
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.
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
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.
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
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.
8
Starts with good requirements
• LMS-CP-5526 “Product Requirements
Development and Management Procedure”
• Available on request, send me an email
[email protected]
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
15
Interface Requirement vs. Interface Definition
Example
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
•
Drawing 3-4 contains the connector, pin
assignments, and grounding information in
order to obtain power
•
Sys 2 shall operate on power obtained
from Sys 1 having the characteristics
defined in ICD 2345 Table 3.6
•
Table 3-6 contains power characteristics
such as voltage, current, noise, filtering
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.
16
Interface Attributes
• Interface Requirement
• Interface Definition
– Rationale (Justification)
– Trace (Identifies parent)
– Allocation (Points to child,
corresponding architecture link
one level down)
– Verification Method (Inspection,
Analysis, Demonstration, Test)
– Owner (Accountable person)
INCOSE WMA SEDC 2014 Conference:
New and Emerging Applications and Trends in Systems Engineering
– 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)
Copyright © 2014 by Kevin Vipavetz LaRC, NASA
Permission granted to INCOSE to publish and use.
17
SRD - Evolving ICD (Ares I-X)
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.
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
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.
19
SRD - Existing ICD (MISSE-X)
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.
20
Using a Shadow ICD (MISSE-X)
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.
21
MISSE-X Example
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.
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
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.
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
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.
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
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.
25
Verification
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.
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
Integrate
Verify interface
Subsystem A
Subsystem B
Verify interface
Verify interface
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.
Questions?
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.
28