SlideShare une entreprise Scribd logo
1  sur  56
Télécharger pour lire hors ligne
L. Cordova, C. Kovich, M. Sargusingh
Agenda
• Introduction
• Model Based Requirements Development & Management Approach
      –    Ops Con/models
      –    Environments
      –    Architecture
      –    Interfaces
      –    Functions
      –    Decomposition
      –    Performance Measures
      –    Requirements / Verification
      –    Functional Analysis
      –    Technical Planning
      –    Documentation
• Conclusion
3/2/2012                             NASA PM Challenge 2012   2
Introduction
• What is Model-Based Systems Engineering?
      – Model-Based Systems Engineering (MBSE) is the formalized application of
        modeling to support system requirements, design, analysis, verification and
        validation activities beginning in the conceptual design phase and continuing
        throughout development and later life cycle phases (INCOSE-TP-2004-004-
        02, Version 2.03, September 2007)

• Why is it important?
      – Ensures traceability and completeness of systems engineering products
        (e.g., Ops Con, Requirements, Verifications, etc.)
      – Is an approach to systems engineering where information about the system
        is defined, standardized, and interdependent during the lifecycle process
      – Is a key step in moving from a “document-based” configuration
        management approach to a “data object or model-centric” approach


3/2/2012                           NASA PM Challenge 2012                           3
Overview
• The NASA Johnson Space Center EVA Office Systems Engineering
  and Integration (SE&I) team utilizes MBSE to develop and manage
  requirements for an evolving, complex system that spans multiple
  programs                               •Seated vehicle operations
                                                                •Occupant protection
  The space suit architecture must          Crew Escape
                                                                •Post-landing suited ops
  meet various and often conflicting         & Survival
                                                                •Contingency crew survival
      mission objectives while                                     •Fire & Tox protection
             optimizing                                            •Water survival
    mass, volume, reliability, and                                 •Rapid cabin depress
           maintainability                                         •Unpressurized 144 hr return

 •Pressurized -g mobility
 •Environmental protection
 •Vehicle supported or                                                      •Mobility to perform
                             Microgravity                       Surface
  independent life support                                                   partial-g surface EVA
                                 EVA                             EVA
 •Vehicle Maintenance/                                                      •Environmental protection
  Reconfiguration                                                           •Independent Life Support

3/2/2012                               NASA PM Challenge 2012                                           4
Space Suit System (EVA System Reference 2)

• The original design solution developed for Constellation involved a
  modular, reconfigurable, component-based architecture
                        LEA/Microgravity EVA Suit*                             Lunar Surface EVA Suit
                              (aka Configuration 1)        Interchangeable       (aka Configuration 2)
   Common Components:                                        Components:
                                                                                                         Modular Components
   Suit Multiple Connector                                  Helmet, Visor                                 Torso Assemblies
   (not shown)                                               Assemblies
                                                                                                                Gloves
   Vehicle Multiple Connector                                  Pressure
   (not shown)                                                Garment
                                                              Segments
   Pressure Garment
   Materials & Design
                                                              Emergency
                                                               Oxygen

                                                              Life support
                                                               umbilicals


* Notional picture does not                                    Thermal
include: Life Preserver and                                 Undergarments
Emergency Breathing systems
3/2/2012                                              NASA PM Challenge 2012                                                 5
Lunar Crewed Mission
• In the Constellation Program Lunar Design Reference Mission (DRM), the
  suited crewmember, and therefore the space suit, is in involved in all
  phases and interfaces with multiple systems
                                                                 MOON

                    Lunar Surface IVA
  Suit Config 2




                    Lunar Surface EVA


                  LLO

                    Microgravity EVA
                    Microgravity IVA
  Suit Config 1




                  ERO




                                           LEA Configuration
                        EARTH

3/2/2012                                NASA PM Challenge 2012             6
Space Suit Interfaces
• The space suit interfaced with every crewed vehicle included in the
  Constellation architecture




3/2/2012                    NASA PM Challenge 2012                  7
MODEL BASED REQUIREMENTS
       DEVELOPMENT & MANAGEMENT
       APPROACH




3/2/2012          NASA PM Challenge 2012   8
Implementation of the SE Engine
                            Model-centric approach helps to
                            keep this as robust yet nimble as
Agency, Center, & Program                possible
Requirements
                                                                         The integrated system
                                                                         will have to be
                                                                         evaluated to verify that
                                                                         the hardware will be
                                                                         safe enough for EVA
• Ops cons will be used
  to help determine
  D&C spec
  applicability;
• DRM derived
  functionality will be
  used to support
  agency mission
  architecting activities


                                                                           Occurs in Hardware
Hardware specs, and the                                                    Team and below (i.e.
necessary ICDs;                                                            prime contractor)
additional levels of
                               Perform and/or support
documentation will be
                              hardware trades & analysis
created if needed
                              such as mass assessments
                                and design compliance


                                                                Figure: NASA/SP-2007-6105 Rev1
  3/2/2012                     NASA PM Challenge 2012                                         9
EVA Systems Integrated Data Infrastructure

Model Based Data Infrastructure
                                                                  Allows us to better trace the
                                                                  requirements synthesis process and
                                                                  logic (i.e. why we have the          Makes data accessible to
                                                                  requirements we have)                 various stakeholders

                                                                                                                     Program
                                                                                                                    Management


                                                                                                                      Designers


                                                                                                                       Mission
                                                                                                                      Architects
Maintains data and traceability to
support future analysis and
requirements development efforts
                                                                                                                        Safety

                                                                                                                     Contractors


                                                                                                                    Mission Ops
   Provides Data & Documentation to support EVA
   Systems Operations and Hardware Development




3/2/2012                                                  NASA PM Challenge 2012                                                   10
System Model Framework
• The Space Suit System
  Model includes definitions
  of the three basic parts of
  the technical baseline (aka
  the Tri-Force):
  operational concepts,
  architecture/design, and
  requirements

• By capturing all of the
  connections between the
  technical baseline, we
  experienced a significant
  efficiency improvement in
  analysis and identification
  of change impacts

3/2/2012                        NASA PM Challenge 2012   11
Operational Concepts
                  Generic tech baseline would be available for basic families of hardware

                                Design & Construction Specs
           DRM               Capabilities                 Function A                 Class A




                  Program Specific
                    Capabilities

                                               Function A                            Arch A
           Ops
           Con
                                                 Perf 1                                          Config 1

                                                   Perf 2                                        Config 2

           Env.
                                                                           Req A.1


                                                                           Ver A.1


                                                                       Allocated       Derived       Relational
3/2/2012                                    NASA PM Challenge 2012                                                12
Operational Models
• The Space Suit DRM decomposes
  program-level operations into suit-
  focused activities and adds
  contingency operations/transitions
        Long Delay
                                                                                                                      Return to CSUF                                Simulations
                 Fit Checks
                                                                                                                            14                                           13
                       3
                                                                                                                             Launch Countdown Call-to-Stations                CDDT
     Arrival
                                                         Launch Site Receipt            CSUF             Vehicle          Uncrewed                     Transfer       Ingress
       of            Testing        Shipping                                                                                             Suit Up
                                                            of Hardware               Processing        Assembly           Testing                    to Vehicle       Orion
    Hardware
                       2               5                                                                                                   10
                                                                 6                        7                8                 9                            11             12
        1

                  Training
                                                                                                                                                                      Prepare
                       4                                                                                                                                            for Launch
                                       Pad Emergency Egress
                                                                                                                                                                         15
                                                    29
                                                                                                                                                                                     Launch
                                                                                 Pad Abort                                                                                            Scrub
                                       Launch Abort                                                                                                                      OR
                                                                                 Ascent Abort                                                                                          28
                                            30                                                                                                                     Liftoff
                                                                                                                                                                       Ascent
                                                                                                        Contingency On
                                                                                                         Orbit Events                                                    16
                               Contingency Landing
                                   and Rescue                                                                  31
                                                                                                                                                                    Microgravity
                                       33                                                                                                                               IVA
                                                                                                               ISS Contingencies                                    Operations

                                                                                                                      32                                                 17


      Ship to                                                                                                                                                        ISS RPOD
                         Recovery           Egress               Post           Water                            Don Suit and
    Processing                                                                                  Entry                                  Checkout       Doff Suit
                        Processing          Orion              Landing         Landing                         Ingress Vehicle
      Facility                                                                                                                                                           18
                                                                                                 22                                      20              19
                               26              25                24              23                                  21
       27




3/2/2012                                                                                                NASA PM Challenge 2012                                                                13
Operational Concepts
• The Space Suit Operational Concepts (Ops Con) serve as the basis
  for communication between our stakeholders and designers
      – Stakeholders help us to understand their expectations on what the suit
        capabilities are and how it will be used
      – Designers provide information on how the suit is expected work
• Operational concepts are currently presented in document format:
      – Multi-Purpose Crew Vehicle (MPCV) Flight Suit Element Operational Concept
        provides Ops Con associated with Block 0 and Block 1 MPCV operation
      – International Space Station (ISS) Detailed Test Objective (DTO) Design
        Reference Document contains Ops Con associated with the Extravehicular
        Mobility Unit (EMU) Demonstrator
      – Advanced EVA Operations will contain the Ops Con associated with the
        Capability Driven Framework DRMs



3/2/2012                           NASA PM Challenge 2012                        14
Environments
                  Generic tech baseline would be available for basic families of hardware

                                Design & Construction Specs
           DRM               Capabilities                 Function A                 Class A




                  Program Specific
                    Capabilities

                                               Function A                            Arch A
           Ops
           Con
                                                 Perf 1                                          Config 1

                                                   Perf 2                                        Config 2

           Env.
                                                                           Req A.1


                                                                           Ver A.1


                                                                       Allocated       Derived       Relational
3/2/2012                                    NASA PM Challenge 2012                                                15
Environments
• The system model framework included several aspects of the space
  suit environments:
      –    Definition of environments to which the hardware could be subjected
      –    Definition of environments in which the hardware needs to operate
      –    Definition of environments to which the hardware would be optimized
      –    Requirements specifying the environments to be created by the space suit
• The space suit environments definitions were scattered across
  several documents with no mapping to operational
  concepts, requirements or capabilities
      – We were able to publish the definitions in 1 document
• Environments map to specific operations from the Ops Con model
      – Using the definition to Ops Con mapping, the environments could be traced
        to requirements and verifications

3/2/2012                             NASA PM Challenge 2012                           16
Architecture
                  Generic tech baseline would be available for basic families of hardware

                                Design & Construction Specs
           DRM               Capabilities                 Function A                 Class A




                  Program Specific
                    Capabilities

                                               Function A                            Arch A
           Ops
           Con
                                                 Perf 1                                          Config 1

                                                   Perf 2                                        Config 2

           Env.
                                                                           Req A.1


                                                                           Ver A.1


                                                                       Allocated       Derived       Relational
3/2/2012                                    NASA PM Challenge 2012                                                17
Hardware “Classes”
• The “class” hierarchy
  defines the scope of the
  project                                                                         Space Suits
• A “class” of hardware
                                                Class
  defines a generic technical
  baseline                                                              Flight Suits             EVA Suits
      – Default set of standards &
        specifications
      – Supports a generic set of            Generic
        operational scenarios                Physical                     MPCV                   ISS DTO
                                                                        Flight Suit                Suit
           • Generic functions             Architecture
           • Generic hardware
• Provides a platform for                  Configurable         MPCV                 MPCV
  mission specific systems                   Physical         Flight Suit          Flight Suit
                                           Architecture        Block 1              Block 2
  engineering

3/2/2012                             NASA PM Challenge 2012                                                  18
Interface Management
• The Architecture is further defined with Physical Architecture
  Diagrams (PADs) showing the system interfaces
                                                               * Flight Crew Equipment (FCE) *



                                  FCE/LEA LEA/FCE    FCE/LEA      FCE/LEA     LEA/FCE     FCE/LEA LEA/FCE FCE/LEA
                                  Structures Loads    Loads        Human      Nutrition   Nutrition Medication Medication
                                                                  Factors


                * Flow notation is From/To *


                                                                                                                     Orion/LEA Breathing Gas

                                                                                                                     LEA/Orion Breathing Gas
                     LEA/GS Audio
                                                                                                                            Orion/LEA Audio
                     GS/LEA Audio
                                                                                                                            LEA/Orion Audio
                      LEA/GS Size
                                                                            MPCV                                      Orion/LEA Cooling Fluid
         *
                                                                            Flight
      Ground         GS/LEA Power
                                                                              Suit                                    LEA/Orion Cooling Fluid
      Systems                                                                                                                                   * Orion *
                     LEA/GS Loads                                           Element
       (GS)                                                                                                                 Orion/LEA Loads
         *
                     GS/LEA Loads                                             *1*                                           LEA/Orion Loads

                                                                                                                             LEA/Orion Data
                     LEA/GS Thermal
                                                                                                                            Orion/LEA Potable
                  GS/LEA Breathing Gas
                                                                                                                            LEA/Orion Size

                                                                                                                        Orion/LEA Power
                                                                                                                              Water



3/2/2012                                                       NASA PM Challenge 2012                                                                       19
Functions
                  Generic tech baseline would be available for basic families of hardware

                                Design & Construction Specs
           DRM               Capabilities                 Function A                 Class A




                  Program Specific
                    Capabilities

                                               Function A                            Arch A
           Ops
           Con
                                                 Perf 1                                          Config 1

                                                   Perf 2                                        Config 2

           Env.
                                                                           Req A.1


                                                                           Ver A.1


                                                                       Allocated       Derived       Relational
3/2/2012                                    NASA PM Challenge 2012                                                20
Functional Decomposition
• Functions provide the link between operations, architecture, and
  requirements (Tri-Force)
• Functions were created using two methods:
      1.   Decomposition from Program allocated “capabilities” through a
           hierarchical approach
      2.   Derivation from the operations

                                   Capabilities                    Function A


                           Program Specific
                                                            1
                             Capabilities

             Ops
             Con              2                             Function A


3/2/2012                           NASA PM Challenge 2012                       21
Decomposition from Capabilities
• Capabilities are high level/programmatic functions
      – Capabilities decompose into lower level functions specific to the system of
        interest
      – Capabilities were included to show traceability to Program allocated
        functionality

                                                                                  Return
     Capability                                                                   crew to
                                                                                   Earth



                                                                                                     Protect
                                                                                                                  Minimize
                                                    Distribute       Provide                           the
                                                                                                                  effects of
                                                   launch and        hearing                          crew
                                                                                                                 orthostatic
                                                  landing loads     protection                        from
                                                                                                                 intolerance
                                                                                                       flail

       Function                             Distribute
                                                               Limit
                            Distribute        loads                                          Provide        Provide
                                                            vibration     Limit chest
                           loads within      between                                          head            neck
                                                              to the      deflection
                             the suit      the suit and                                     protection     protection
                                                               crew
                                               seat



3/2/2012                                  NASA PM Challenge 2012                                                           22
Derivation from Operations
Operation    FFBD                                                                                                                     Performance
 Suit Up                                                                            Operation       Function        Interface
                                                                                                                                        Measure
                               Indicates a specific      Mobility to mate
   10                        range of motion and           an umbilical
                                                                                                    Indicates a leak
                                torque at 1.0 psid        unpressurized
                                                                                                  threshold at 2.0 psid
                                                                                                                            Mobility to demate
                                                                                                      Leak check
                                                         Provide mobility                                                     an umbilical
                                                                                                       pressure
                                                                                                                             unpressurized



                                                                                                       Maintain               Perform
               Don                                                                   Pressurize
                            OR                 OR         AND         AND     AND                        total               controlled
               suit                                                                     suit
                                                                                                       pressure           depressurization

                                                                                      Maintain
                        If cooling is                          Connect to              relative
                          required                              services              humidity
                                                                                                                                AND          Provide
                                                                                                                                             mobility
                                                                                       Provide adjustable
                                            Provide                                   temperature control
                         Provide
                                           adjustable
                         portable                                                                                               AND
                                          temperature
                          cooling                                     J
                                            control                                  Maintain breathing air
                                                                                        concentrations                                   Disconnect
                                                                                                                                            from
                                                                                        Provide two-way                                   services
               GS/LEA           LEA/GS                GS/LEA         LEA/GS            communication to
               Power         Breathing Gas            Audio           Audio              crewmember


  3/2/2012                                                        NASA PM Challenge 2012                                                                23
Requirements
                  Generic tech baseline would be available for basic families of hardware

                                Design & Construction Specs
           DRM               Capabilities                 Function A                 Class A




                  Program Specific
                    Capabilities

                                               Function A                            Arch A
           Ops
           Con
                                                 Perf 1                                          Config 1

                                                   Perf 2                                        Config 2

           Env.
                                                                           Req A.1


                                                                           Ver A.1


                                                                       Allocated       Derived       Relational
3/2/2012                                    NASA PM Challenge 2012                                                24
Requirements – SRD Structure
• The class hierarchy produces a
  requirements set that is easily
  extensible to future suit
  developments
      – Establishes a set of generic space
        suit reqs/standards
      – Builds upon generic reqs by
        allowing for vehicle/mission
        specific reqs to be captured
• Linking requirements to higher
  level classes limits “starting from
  scratch” when new programs are
  stood up
• This structure was created to
  maintain horizontal integration
  across all suited efforts
3/2/2012                             NASA PM Challenge 2012   25
Derived Requirements

       Design & Construction Specs                                  Standard:
                                               Class A
                                                                       The WMS shall prevent
                                                                     direct contact of contained
                                                                      urine with the crew’s skin

                                               Arch A


                                                         Config 1


                                                         Config 2


                                     Req A.1




                                                                                                   26
Derived Requirements

       Design & Construction Specs                                  Standard:
                                               Class A
                                                                       The WMS shall prevent
                                                                     direct contact of contained
                                                                      urine with the crew’s skin
                                                                    Physical constraint:
                                               Arch A
                                                                       The 12-hr MAG shall fit
                                                         Config 1
                                                                         within the allocated
                                                         Config 2
                                                                          stowage volume.
                                     Req A.1


                                     Ver A.1




                                                                                                   27
Derived Requirements

                    Design & Construction Specs                                        Standard:
DRM              Capabilities              Function A             Class A
                                                                                          The WMS shall prevent
                                                                                        direct contact of contained
       Program Specific
         Capabilities
                                                                                         urine with the crew’s skin
                                                                                       Physical constraint:
                                Function A                        Arch A
 Ops
 Con                                                                                      The 12-hr MAG shall fit
                                  Perf 1                                    Config 1
                                                                                            within the allocated
                                    Perf 2                                  Config 2
                                                                                             stowage volume.
                                                        Req A.1
                                                                                       Functional/Performance:
                                                                                         The MPCV Flight Suit shall
                                                                                         contain urine for 12 hours
                                                                                        during Flight Test Missions




                                                                                                                      28
Derived Requirements

                     Design & Construction Specs                                        Standard:
DRM               Capabilities              Function A             Class A
                                                                                           The WMS shall prevent
                                                                                         direct contact of contained
        Program Specific
          Capabilities
                                                                                          urine with the crew’s skin
                                                                                        Physical constraint:
                                 Function A                        Arch A
 Ops
 Con                                                                                       The 12-hr MAG shall fit
                                   Perf 1                                    Config 1
                                                                                             within the allocated
                                                                             Config 2
                                                                                              stowage volume.
 Env.
                                                         Req A.1
                                                                                        Functional/Performance:
                                                                                          The MPCV Flight Suit shall
                                                                                          contain urine for 12 hours
                                                                                         during Flight Test Missions
                                                                                        Environment Definition:
                                                                                           The WMS shall function
                                                                                         after stowage in the Orion
                                                                                             pressurized volume

                                                                                                                       29
Requirements Validation
• Requirements were initially developed from Subject Matter Expert
  (SME) input and decomposition/flow down of program allocated
  requirements
      – Though the Ops Con was used to derive some requirements, they were not
        initially linked
• Audits were used to show that program allocated requirements
  were answered in our requirements set (traceability report)
• The “Tri-Force” allowed for validation of the requirements set from
  a functional perspective (did we have the right requirements)
• After developing the MBSE framework, the requirements were
  linked to the System level models through the functional analysis
  and interface definitions
      – This aided in identification of impacts for a proposed change to the technical
        baseline
3/2/2012                            NASA PM Challenge 2012                          30
Verification
• Verification planning
      – Begins early in the project life cycle
      – Updates to verification planning will continue throughout the logical
        decomposition and design development phases, especially as design reviews
        and simulations shed light on items under consideration in the requirements
        development phase
• Our verifications were drafted along with the requirements to
  ensure that we had verifiable requirements
      – All verifications are linked to their respective requirement
      – The Environments map to specific operations from the Ops Con model which
        was intended to support the verification planning
           • Certification is a classification applied to environments if the verification for the
             requirement calls for ‘certification’ in a specified environment
   Without a verifiable baseline and appropriate configuration controls, later modifications
   could be costly or cause major performance problems for your system
3/2/2012                                 NASA PM Challenge 2012                                  31
Verification Roles & Responsibilities
• A need to clarify verification roles and responsibilities was realized
  during discussion regarding requirements that were applicable to
  the prime contract:
      – Which party is responsible for developing detailed verification objectives
        (DVO)
      – Which party is responsible for executing per the DVO
• Approach
      – Responsibility categories were developed to group verifications of similar
        scope and complexity. Establishing categories (buckets) ensured that
        approaches were consistently applied and that any exceptions to the
        philosophy were noted
• Assumptions
      – Requirements/children sharing equivalent scope will not duplicate
        verification efforts (this is based on similar/equal requirements residing at
        multiple levels)
      – Requirements sharing equivalent scope and functionality (noun changes)
        need to share a verification approach
3/2/2012                            NASA PM Challenge 2012                              32
Technical Planning
• We also used Issues and Actions to aid in technical planning
      – Issues were comprised of those items considered To Be Determined (TBD)
        and To Be Resolved (TBR)
      – Actions were items used to track open work that was not part of the
        TBD/TBRs but were necessary to update the technical baseline
      – Both Issues and Actions were associated with the following items:
           •   Ops Con
           •   Architecture
           •   Functions
           •   Requirements
           •   Verifications
           •   Environments




3/2/2012                          NASA PM Challenge 2012                         33
Documentation
• Templates were created to generate documents with particular
  formatting
      – Templates were hardcoded to pull in particular document sections with
        associated linked data
• Documents were generated by printing out specified items based
  on the associated links (e.g. requirements linked to architecture
  items)
      – Without changing our current structure, the linkages also allowed us to
        create documents for specific DRMs or suit configurations (e.g.
        SRD, ERD, contract applicable requirements)
• Data can also be extracted using a query
      – Exports can be performed in csv, rtf, or HTML formats



3/2/2012                           NASA PM Challenge 2012                         34
Other models
• Several models have been used to develop and validate system
  requirements
      –    Wissler Model
      –    Thermal Desktop CFD Model
      –    Excel Pressure Drop / Flow Model
      –    Macroflow Pressure Drop Model
      –    EVA System Mass Tracker
• These models are configuration managed (i.e. data managed) by
  the analyst (except Wissler)
      – Model descriptions and results are presented to peers and stakeholders as
        part of analysis process
      – Results are evaluated and used to support requirements validation or
        change package
• There are no direct links between analytical models and SE
  Database
3/2/2012                            NASA PM Challenge 2012                          35
THE SPACE SUIT MBSE APPROACH
       PUT TO THE TEST
       In response to the announcement of the cancellation of Constellation
       (2/1/10), the EVA Systems Engineering & Integration team was given the
       challenge to reduce contract scope commensurate with the redirection
       and minimize overhead associated with engineering the system



3/2/2012                           NASA PM Challenge 2012                       36
Initial Scope of the Mission




3/2/2012           NASA PM Challenge 2012   37
Updated Scope


    After the 2/1/11, the EVA System scope was reduced to include only ISS Missions




3/2/2012                              NASA PM Challenge 2012                          38
EVA System Re-Architecting
• An SE&I Tiger Team was stood up and given three weeks to update
  the technical baseline per the reduced scope:
      – Update to the operational concepts
      – Identify the relevant requirements from Level 2 (CARD), Level 3 (SRD), Level
        4 (ERDs), HSIR, and IRDs
      – Updating the deliverable components list
      – Update to technical resource allocations (mass, volume)
      – Update verification responsibility
      – Update the Applicable Documents List
• Reports of requirements with mission phase applicability and
  parent-child relationships identified helped to expedite this
  process
• Existing models defining mass helped to expedite update to mass
  allocations
3/2/2012                           NASA PM Challenge 2012                          39
Model Updates
• Changes to the model instigated by this effort:
      – Implemented linkage of requirements to hardware configurations instead of
        mission phase “technical points of contact”
      – Separating out of functional requirements with mission / configuration
        dependent performance specs
• Documents can be generated by printing out requirements linked
  to certain architecture items
• Without changing the current structure, these additional links will
  allow creation of LEA-focused documents:
      – J-19
      – SRD
      – ERDs



3/2/2012                          NASA PM Challenge 2012                        40
Requirements Streamlining Effort
• In order to minimize systems engineering overhead, a restructuring effort
  was undertaken to reduce the number of requirements in the EVA
  System requirements set; this would save resources by reducing
  unnecessary requirements management and verification activity
      – Delete redundant requirements
      – Merge related requirements where appropriate
      – Goal was to maintain each “requirement” only once in the entire technical
        baseline; i.e. Do not duplicate an Interface Requirement Document (IRD)
        requirement in the SRD
• At this time, the requirements were also leveled
      – We took the existing SRD and 2 Element Requirement Documents (ERDs) and
        combined them into one document. Goals of this effort included the following:
           • Levied the requirements at the level appropriate for verification, i.e. pushed Contract
             End Item (CEI) specific requirements down to the CEI Specification Documents
• We updated the model framework to produce a requirements set that is
  easily extensible to future suit developments
      – Established a set of generic space suit standards in the EVA SRD
3/2/2012                                 NASA PM Challenge 2012                                    41
Requirements Leveling Approach
• EVA SRD System-level requirement
      – Functions that include multiple elements
      – Standards that apply to multiple suit developments
• EVA SRD Element-level requirement
      – Decompositions specific to suit development
      – Allocations where Project-level margins are desired
      – Requirements necessary to bound contract scope
• LEA Suit ERD-level requirement
      – Decompositions that are appropriate for the Element-level
      – Element-level details where contractor ownership is desired
• Subsystem-level requirement
      – Section removed; allocation directly to CEIs from the Element-level
      – Rely on the assignment of technical owners to track responsibility for applicable
        requirements


3/2/2012                               NASA PM Challenge 2012                               42
Push to Data-Centric
• The EVA Systems Engineering Model inherently captures the SE
  definition in a data centric manner (as opposed to document-
  centric)
• Through use of publishing software, this data is sorted and
  presented in document format per the customers requirements
• A data-centric configuration management approach was developed
  but never implemented by the EVA Office due to resource
  constraints
• Things yet to be considered
      – Linkage to applicable documents
      – Implementation of document-centric requirements and other systems
        definition artifacts applied by the Program or other authoritative sources



3/2/2012                            NASA PM Challenge 2012                           43
NEXT STEPS



3/2/2012            NASA PM Challenge 2012   44
Develop “Generic” Models
• Utilize the system model developed for Constellation to develop a
  generic space system model
• Development of a generic model would reduce “start-up” cost and
  time and time for a new program
      – Basic operational concepts, capabilities and even requirements would
        already be defined
      – The time to establish the data infrastructure would be significantly reduced
• A generic system model would aid in mission architecting studies
      – Basic capabilities would be defined to support high level functional analyses
      – Basic operational concepts would be defined to support high timeline
        analyses
      – Resource utilization could be defined to support trade studies and help size
        supporting systems
• Capturing basic design features will help lead to suit design
  standards
3/2/2012                            NASA PM Challenge 2012                             45
Generic-EVA System
Generic Operational Models                                                               Flight Suit Class
                                                                                         EVA Suit Class
       Mission                                                Transportation
                                     Launch
     Preparation                                              to Destination
                   CDDT                  Crew Worn                          Stowed
                   Flight Ops
                                              Stowed                          Stowed
                    Training




                                                                                                       Unpressurized
                                                                  Destination




                                                                                                        cabin survival
   Assembly, Test,                                                 Activities
    Fitcheck, etc.                       Emergency                            Stowed




                                                                                               Contingency EVA
                                        Vehicle Egress
                                                                                EVA

    Post-Landing                   Earth Entry /                  Return
     Processing                      Landing                  Transportation
                                         Crew Worn                          Stowed
Generic model overlaid by
Generic flight suit and EVA suit              Stowed                          Stowed
operational models
3/2/2012                                 NASA PM Challenge 2012                                                      46
Update Model to Capitalize on Class Definitions

                                                                                    MPCV
Flight Test                                                                       Flight Suit
   DRM
                                                               Pressure                                   Crew
                                                                            LSS                 PAS
                                                               Garment                                   Survival
              ISS DRM
                                                                     PGA    Vent Kit              CCA        LPU
                        Lunar Transit
                           DRM                                              Thermal
                                                                   Helmet                         AIU        EBA
                                                                              Kit

                                            Fcn: Contain           Gloves                       Biomed
                                               Waste

                                                                    MAG
              … for 12 hrs                                                        12-hr MAG
                                                                    LCVG
                             … for 48 hrs                                         48-hr MAG
                                                                    FRCL
                                      … for 144 hrs                               144-hr WMS

3/2/2012                                         NASA PM Challenge 2012                                             47
Performance Items to be Implemented
• We realized that multiple requirements were required for each
  function based on the specific performance required for a particular
  mission / program
• We are currently exploring the best method for implementing
  performance items
      – Performance items would link to functions in accordance with specific ops con
      – Functions would continue to link to architecture items, and performance
        specifications would be linked to specific configurations
           Basic Suit Function   Waste Mngmt                    WMS


               Flight Test DRM      12 hr                                     MAG


             ISS Transport DRM        48 hr                               Long Duration
                                                                              WMS
                                                     Req A.2

                                                                Req A.1
                                                     Ver A.2

3/2/2012                               NASA PM Challenge 2012   Ver A.1                   48
Data-centric Configuration Management
• Control data not documents
• Allows contextual data (e.g. concepts of operations, functional
  analysis, etc) to be reviewed along with controlled data such as
  requirements
• Data objects can be published in various reports customized to the
  stakeholder without compromising the integrity of the data
• Allows for more comprehensive stakeholder review
• Shifts emphasis on content of the data instead of the scope of a
  document




3/2/2012                    NASA PM Challenge 2012                 49
LESSONS



3/2/2012         NASA PM Challenge 2012   50
Lessons Experienced…
• Tools and processes for complex systems need to be architected
  just as carefully as the hardware being developed
      – Want to implement something before folks get comfy
• Fancy tools are only useful if people use them
      – Grandfathered processes
      – Parallel processes
• Data-centric is great… in theory
      – People think in documents
      – Determination of what data needs to be controlled is not as intuitive as with
        documents
• Communication interfaces are just as important as the data being
  provided
      – Not everyone needs to handle the data in its native/source environment
      – We need to show it the way that people can read it
                                             … time will tell if these lessons were learned
3/2/2012                           NASA PM Challenge 2012                                     51
QUESTIONS



3/2/2012           NASA PM Challenge 2012   52
BACK-UP



3/2/2012         NASA PM Challenge 2012   53
Mass Tracker Spreadsheet
                                                MEL and MGA multipliers feed the component
                                                Mass spreadsheet




     Mass Spreadsheet feeds manually
     assembled configuration spreadsheets


                            Configuration totals feed a page
                            which contains historical data
                                                            TPM graph is generated from
We want to get this in the SE database as soon as
                                                            the historical data worksheet
we can get it to do math!!!
3/2/2012                                NASA PM Challenge 2012                               54
Design Compliance
• Requirements Design Compliance purpose is to objectively determine if
  the preliminary design can be expected to meet requirements to an
  acceptable level of risk
• The objectives of requirements design compliance include
      – Identify and establish resolution paths for architectural performance/design
        issues as early in the design cycle as possible
           • Proactively manage ‘acceptable level of risk’
           • Early issue resolution/prevention reduces cost and schedule impacts
           • End-to-End mission perspective
      – Utilize objective design evidence to determine success of design cycle, from
        architecture perspective of the design reference mission (DRM) and operations
        concepts (ops con)
      – Facilitate vertical integration of design compliance data with Projects and
        horizontal integration across level II
      – Report and track significant design compliance issues (design compliance matrix
        is only one part of design compliance)
      – Engage architecture requirement owners in design aspects in preparation for
        requirement verification (‘get our hands dirty’)
3/2/2012                                NASA PM Challenge 2012                         55
Verification Logic Network (VLN)
• VLN is:
      – A strategy to provide evidence of closure for each Detailed Test Objective
        (DTO)
      – Bottoms-up plan by which verification events can be efficiently executed
        (ensures efficient grouping of requirements)
           • Will logically group multiple requirements that can be verified with one activity
           • Verification event can be a DAC cycle closure, MEIT, FEIT, DSIL event, Flight
             Test, Mission Sim
      – Graphical representation of the verification events to close out the
        applicable requirements set (i.e. CARD, IRD, SRD)
      – Aid in identifying gaps and/or any overlaps in the verification planning
        process
           • Schedule conflicts
           • Delivery conflicts with hardware or software
           • Clarify test configurations and processes
• In summary, a VLN is an integrated system verification activity
  network
3/2/2012                               NASA PM Challenge 2012                                    56

Contenu connexe

Tendances

Introduction To OSGi
Introduction To OSGiIntroduction To OSGi
Introduction To OSGiccustine
 
Xen summit 2010 extending xen into embedded
Xen summit 2010 extending xen into embeddedXen summit 2010 extending xen into embedded
Xen summit 2010 extending xen into embeddedThe Linux Foundation
 
Paul Roman Nps Summit
Paul Roman Nps SummitPaul Roman Nps Summit
Paul Roman Nps SummitPaulRoman
 
Ca partner day - application lifecycle optimization - milano e roma
Ca partner day - application lifecycle optimization - milano e romaCa partner day - application lifecycle optimization - milano e roma
Ca partner day - application lifecycle optimization - milano e romaCA Technologies Italia
 
Vmug da-wm-vplex-vmware
Vmug   da-wm-vplex-vmwareVmug   da-wm-vplex-vmware
Vmug da-wm-vplex-vmwaresubtitle
 
z/VM 6.2: Increasing the Endless Possibilities of Virtualization
z/VM 6.2: Increasing the Endless Possibilities of Virtualizationz/VM 6.2: Increasing the Endless Possibilities of Virtualization
z/VM 6.2: Increasing the Endless Possibilities of VirtualizationIBM India Smarter Computing
 
Intelligent Buildings Workplace Tech10 Final
Intelligent Buildings Workplace Tech10 FinalIntelligent Buildings Workplace Tech10 Final
Intelligent Buildings Workplace Tech10 Finalrichpower
 
Sc Physics 2 12 9 09 Webinar Final Web
Sc Physics 2 12 9 09 Webinar Final WebSc Physics 2 12 9 09 Webinar Final Web
Sc Physics 2 12 9 09 Webinar Final Webguest92278a
 
TSM 6.4 Technical updates
TSM 6.4 Technical updates TSM 6.4 Technical updates
TSM 6.4 Technical updates Solv AS
 

Tendances (13)

Introduction To OSGi
Introduction To OSGiIntroduction To OSGi
Introduction To OSGi
 
Xen summit 2010 extending xen into embedded
Xen summit 2010 extending xen into embeddedXen summit 2010 extending xen into embedded
Xen summit 2010 extending xen into embedded
 
Paul Roman Nps Summit
Paul Roman Nps SummitPaul Roman Nps Summit
Paul Roman Nps Summit
 
Ca partner day - application lifecycle optimization - milano e roma
Ca partner day - application lifecycle optimization - milano e romaCa partner day - application lifecycle optimization - milano e roma
Ca partner day - application lifecycle optimization - milano e roma
 
Introduction to OSGi
Introduction to OSGiIntroduction to OSGi
Introduction to OSGi
 
Cisco ios versions
Cisco ios versionsCisco ios versions
Cisco ios versions
 
+15 team v3
+15 team v3+15 team v3
+15 team v3
 
Vmug da-wm-vplex-vmware
Vmug   da-wm-vplex-vmwareVmug   da-wm-vplex-vmware
Vmug da-wm-vplex-vmware
 
z/VM 6.2: Increasing the Endless Possibilities of Virtualization
z/VM 6.2: Increasing the Endless Possibilities of Virtualizationz/VM 6.2: Increasing the Endless Possibilities of Virtualization
z/VM 6.2: Increasing the Endless Possibilities of Virtualization
 
Intelligent Buildings Workplace Tech10 Final
Intelligent Buildings Workplace Tech10 FinalIntelligent Buildings Workplace Tech10 Final
Intelligent Buildings Workplace Tech10 Final
 
Scrum Overview
Scrum OverviewScrum Overview
Scrum Overview
 
Sc Physics 2 12 9 09 Webinar Final Web
Sc Physics 2 12 9 09 Webinar Final WebSc Physics 2 12 9 09 Webinar Final Web
Sc Physics 2 12 9 09 Webinar Final Web
 
TSM 6.4 Technical updates
TSM 6.4 Technical updates TSM 6.4 Technical updates
TSM 6.4 Technical updates
 

En vedette

Open Data Conference - Sören Auer - Linked Open Data
Open Data Conference - Sören Auer - Linked Open DataOpen Data Conference - Sören Auer - Linked Open Data
Open Data Conference - Sören Auer - Linked Open DataOpening-up.eu
 
System Architect and Rhapsody
System Architect and RhapsodySystem Architect and Rhapsody
System Architect and RhapsodyMartin Owen
 
INCOSE UK: MBSE - is there any substance behind the hype?
INCOSE UK:   MBSE - is there any substance behind the hype?INCOSE UK:   MBSE - is there any substance behind the hype?
INCOSE UK: MBSE - is there any substance behind the hype?James Towers
 
Enterprise architecture for complex system of-systems contexts
Enterprise architecture for complex system of-systems contextsEnterprise architecture for complex system of-systems contexts
Enterprise architecture for complex system of-systems contextsBoxer Research Ltd
 
Matthew Hause Building Bridges between Systems and Software with SysML and UML
Matthew Hause Building Bridges between Systems and Software with SysML and UMLMatthew Hause Building Bridges between Systems and Software with SysML and UML
Matthew Hause Building Bridges between Systems and Software with SysML and UMLINCOSE Colorado Front Range Chapter
 
Matthew Hause: The Smart Grid and MBSE Driven IoT
Matthew Hause: The Smart Grid and MBSE Driven IoT Matthew Hause: The Smart Grid and MBSE Driven IoT
Matthew Hause: The Smart Grid and MBSE Driven IoT EnergyTech2015
 

En vedette (6)

Open Data Conference - Sören Auer - Linked Open Data
Open Data Conference - Sören Auer - Linked Open DataOpen Data Conference - Sören Auer - Linked Open Data
Open Data Conference - Sören Auer - Linked Open Data
 
System Architect and Rhapsody
System Architect and RhapsodySystem Architect and Rhapsody
System Architect and Rhapsody
 
INCOSE UK: MBSE - is there any substance behind the hype?
INCOSE UK:   MBSE - is there any substance behind the hype?INCOSE UK:   MBSE - is there any substance behind the hype?
INCOSE UK: MBSE - is there any substance behind the hype?
 
Enterprise architecture for complex system of-systems contexts
Enterprise architecture for complex system of-systems contextsEnterprise architecture for complex system of-systems contexts
Enterprise architecture for complex system of-systems contexts
 
Matthew Hause Building Bridges between Systems and Software with SysML and UML
Matthew Hause Building Bridges between Systems and Software with SysML and UMLMatthew Hause Building Bridges between Systems and Software with SysML and UML
Matthew Hause Building Bridges between Systems and Software with SysML and UML
 
Matthew Hause: The Smart Grid and MBSE Driven IoT
Matthew Hause: The Smart Grid and MBSE Driven IoT Matthew Hause: The Smart Grid and MBSE Driven IoT
Matthew Hause: The Smart Grid and MBSE Driven IoT
 

Similaire à Cordova kovich sargusingh

Oracle Cloud Reference Architecture
Oracle Cloud Reference ArchitectureOracle Cloud Reference Architecture
Oracle Cloud Reference ArchitectureBob Rhubart
 
Verifying Architectural Design Rules of a Flight Software Product Line
Verifying Architectural Design Rules of a Flight Software Product LineVerifying Architectural Design Rules of a Flight Software Product Line
Verifying Architectural Design Rules of a Flight Software Product LineDharmalingam Ganesan
 
S-CUBE LP: Online Testing for Proactive Adaptation
S-CUBE LP: Online Testing for Proactive AdaptationS-CUBE LP: Online Testing for Proactive Adaptation
S-CUBE LP: Online Testing for Proactive Adaptationvirtual-campus
 
ATI Technical CONOPS and Concepts Technical Training Course Sampler
ATI Technical CONOPS and Concepts Technical Training Course SamplerATI Technical CONOPS and Concepts Technical Training Course Sampler
ATI Technical CONOPS and Concepts Technical Training Course SamplerJim Jenkins
 
Windows azure scalability
Windows azure scalabilityWindows azure scalability
Windows azure scalabilityLee Stott
 
Tech editors conf tucker yen-jacoby revised final for may 24 2012
Tech editors conf tucker yen-jacoby revised final  for may 24 2012Tech editors conf tucker yen-jacoby revised final  for may 24 2012
Tech editors conf tucker yen-jacoby revised final for may 24 2012Cisco Public Relations
 
Oracle Cloud Reference Architecture
Oracle Cloud Reference ArchitectureOracle Cloud Reference Architecture
Oracle Cloud Reference ArchitectureBob Rhubart
 
Stairway to heaven webinar
Stairway to heaven webinarStairway to heaven webinar
Stairway to heaven webinarCloudBees
 
Resisting to The Shocks
Resisting to The ShocksResisting to The Shocks
Resisting to The ShocksStefano Fago
 
Sccm 2012
Sccm 2012Sccm 2012
Sccm 2012ebuc
 
Software Reliability Engineering
Software Reliability EngineeringSoftware Reliability Engineering
Software Reliability Engineeringguest90cec6
 
Correlation of simulation_models_using_concept_modeling
Correlation of simulation_models_using_concept_modelingCorrelation of simulation_models_using_concept_modeling
Correlation of simulation_models_using_concept_modelingSalvatore Scalera
 
XPDDS19 Keynote: Xen in Automotive - Artem Mygaiev, Director, Technology Solu...
XPDDS19 Keynote: Xen in Automotive - Artem Mygaiev, Director, Technology Solu...XPDDS19 Keynote: Xen in Automotive - Artem Mygaiev, Director, Technology Solu...
XPDDS19 Keynote: Xen in Automotive - Artem Mygaiev, Director, Technology Solu...The Linux Foundation
 
Aes Senior Design Brochure
Aes Senior Design BrochureAes Senior Design Brochure
Aes Senior Design BrochureJean Koster
 
OneCommand Vision 2.1 webcast: Cutting edge LUN SLAs, AIX on PowerPC and flex...
OneCommand Vision 2.1 webcast: Cutting edge LUN SLAs, AIX on PowerPC and flex...OneCommand Vision 2.1 webcast: Cutting edge LUN SLAs, AIX on PowerPC and flex...
OneCommand Vision 2.1 webcast: Cutting edge LUN SLAs, AIX on PowerPC and flex...Emulex Corporation
 
Model-driven Framework for Dynamic Deployment and Reconfiguration of Componen...
Model-driven Framework for Dynamic Deployment and Reconfiguration of Componen...Model-driven Framework for Dynamic Deployment and Reconfiguration of Componen...
Model-driven Framework for Dynamic Deployment and Reconfiguration of Componen...Madjid KETFI
 
Reed simpson
Reed simpsonReed simpson
Reed simpsonNASAPMC
 
Developing Safety-Critical Java Applications with oSCJ
Developing Safety-Critical Java Applications with oSCJ Developing Safety-Critical Java Applications with oSCJ
Developing Safety-Critical Java Applications with oSCJ Aleš Plšek
 

Similaire à Cordova kovich sargusingh (20)

Oracle Cloud Reference Architecture
Oracle Cloud Reference ArchitectureOracle Cloud Reference Architecture
Oracle Cloud Reference Architecture
 
Verifying Architectural Design Rules of a Flight Software Product Line
Verifying Architectural Design Rules of a Flight Software Product LineVerifying Architectural Design Rules of a Flight Software Product Line
Verifying Architectural Design Rules of a Flight Software Product Line
 
Mesos docker jenkins
Mesos docker jenkinsMesos docker jenkins
Mesos docker jenkins
 
S-CUBE LP: Online Testing for Proactive Adaptation
S-CUBE LP: Online Testing for Proactive AdaptationS-CUBE LP: Online Testing for Proactive Adaptation
S-CUBE LP: Online Testing for Proactive Adaptation
 
ATI Technical CONOPS and Concepts Technical Training Course Sampler
ATI Technical CONOPS and Concepts Technical Training Course SamplerATI Technical CONOPS and Concepts Technical Training Course Sampler
ATI Technical CONOPS and Concepts Technical Training Course Sampler
 
Windows azure scalability
Windows azure scalabilityWindows azure scalability
Windows azure scalability
 
Tech editors conf tucker yen-jacoby revised final for may 24 2012
Tech editors conf tucker yen-jacoby revised final  for may 24 2012Tech editors conf tucker yen-jacoby revised final  for may 24 2012
Tech editors conf tucker yen-jacoby revised final for may 24 2012
 
Oracle Cloud Reference Architecture
Oracle Cloud Reference ArchitectureOracle Cloud Reference Architecture
Oracle Cloud Reference Architecture
 
Documenting Software Architectures
Documenting Software ArchitecturesDocumenting Software Architectures
Documenting Software Architectures
 
Stairway to heaven webinar
Stairway to heaven webinarStairway to heaven webinar
Stairway to heaven webinar
 
Resisting to The Shocks
Resisting to The ShocksResisting to The Shocks
Resisting to The Shocks
 
Sccm 2012
Sccm 2012Sccm 2012
Sccm 2012
 
Software Reliability Engineering
Software Reliability EngineeringSoftware Reliability Engineering
Software Reliability Engineering
 
Correlation of simulation_models_using_concept_modeling
Correlation of simulation_models_using_concept_modelingCorrelation of simulation_models_using_concept_modeling
Correlation of simulation_models_using_concept_modeling
 
XPDDS19 Keynote: Xen in Automotive - Artem Mygaiev, Director, Technology Solu...
XPDDS19 Keynote: Xen in Automotive - Artem Mygaiev, Director, Technology Solu...XPDDS19 Keynote: Xen in Automotive - Artem Mygaiev, Director, Technology Solu...
XPDDS19 Keynote: Xen in Automotive - Artem Mygaiev, Director, Technology Solu...
 
Aes Senior Design Brochure
Aes Senior Design BrochureAes Senior Design Brochure
Aes Senior Design Brochure
 
OneCommand Vision 2.1 webcast: Cutting edge LUN SLAs, AIX on PowerPC and flex...
OneCommand Vision 2.1 webcast: Cutting edge LUN SLAs, AIX on PowerPC and flex...OneCommand Vision 2.1 webcast: Cutting edge LUN SLAs, AIX on PowerPC and flex...
OneCommand Vision 2.1 webcast: Cutting edge LUN SLAs, AIX on PowerPC and flex...
 
Model-driven Framework for Dynamic Deployment and Reconfiguration of Componen...
Model-driven Framework for Dynamic Deployment and Reconfiguration of Componen...Model-driven Framework for Dynamic Deployment and Reconfiguration of Componen...
Model-driven Framework for Dynamic Deployment and Reconfiguration of Componen...
 
Reed simpson
Reed simpsonReed simpson
Reed simpson
 
Developing Safety-Critical Java Applications with oSCJ
Developing Safety-Critical Java Applications with oSCJ Developing Safety-Critical Java Applications with oSCJ
Developing Safety-Critical Java Applications with oSCJ
 

Plus de NASAPMC

Bejmuk bo
Bejmuk boBejmuk bo
Bejmuk boNASAPMC
 
Baniszewski john
Baniszewski johnBaniszewski john
Baniszewski johnNASAPMC
 
Yew manson
Yew mansonYew manson
Yew mansonNASAPMC
 
Wood frank
Wood frankWood frank
Wood frankNASAPMC
 
Wood frank
Wood frankWood frank
Wood frankNASAPMC
 
Wessen randi (cd)
Wessen randi (cd)Wessen randi (cd)
Wessen randi (cd)NASAPMC
 
Vellinga joe
Vellinga joeVellinga joe
Vellinga joeNASAPMC
 
Trahan stuart
Trahan stuartTrahan stuart
Trahan stuartNASAPMC
 
Stock gahm
Stock gahmStock gahm
Stock gahmNASAPMC
 
Snow lee
Snow leeSnow lee
Snow leeNASAPMC
 
Smalley sandra
Smalley sandraSmalley sandra
Smalley sandraNASAPMC
 
Seftas krage
Seftas krageSeftas krage
Seftas krageNASAPMC
 
Sampietro marco
Sampietro marcoSampietro marco
Sampietro marcoNASAPMC
 
Rudolphi mike
Rudolphi mikeRudolphi mike
Rudolphi mikeNASAPMC
 
Roberts karlene
Roberts karleneRoberts karlene
Roberts karleneNASAPMC
 
Rackley mike
Rackley mikeRackley mike
Rackley mikeNASAPMC
 
Paradis william
Paradis williamParadis william
Paradis williamNASAPMC
 
Osterkamp jeff
Osterkamp jeffOsterkamp jeff
Osterkamp jeffNASAPMC
 
O'keefe william
O'keefe williamO'keefe william
O'keefe williamNASAPMC
 
Muller ralf
Muller ralfMuller ralf
Muller ralfNASAPMC
 

Plus de NASAPMC (20)

Bejmuk bo
Bejmuk boBejmuk bo
Bejmuk bo
 
Baniszewski john
Baniszewski johnBaniszewski john
Baniszewski john
 
Yew manson
Yew mansonYew manson
Yew manson
 
Wood frank
Wood frankWood frank
Wood frank
 
Wood frank
Wood frankWood frank
Wood frank
 
Wessen randi (cd)
Wessen randi (cd)Wessen randi (cd)
Wessen randi (cd)
 
Vellinga joe
Vellinga joeVellinga joe
Vellinga joe
 
Trahan stuart
Trahan stuartTrahan stuart
Trahan stuart
 
Stock gahm
Stock gahmStock gahm
Stock gahm
 
Snow lee
Snow leeSnow lee
Snow lee
 
Smalley sandra
Smalley sandraSmalley sandra
Smalley sandra
 
Seftas krage
Seftas krageSeftas krage
Seftas krage
 
Sampietro marco
Sampietro marcoSampietro marco
Sampietro marco
 
Rudolphi mike
Rudolphi mikeRudolphi mike
Rudolphi mike
 
Roberts karlene
Roberts karleneRoberts karlene
Roberts karlene
 
Rackley mike
Rackley mikeRackley mike
Rackley mike
 
Paradis william
Paradis williamParadis william
Paradis william
 
Osterkamp jeff
Osterkamp jeffOsterkamp jeff
Osterkamp jeff
 
O'keefe william
O'keefe williamO'keefe william
O'keefe william
 
Muller ralf
Muller ralfMuller ralf
Muller ralf
 

Dernier

COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online CollaborationCOMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online Collaborationbruanjhuli
 
9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding TeamAdam Moalla
 
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesAI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesMd Hossain Ali
 
Introduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxIntroduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxMatsuo Lab
 
Computer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsComputer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsSeth Reyes
 
Designing A Time bound resource download URL
Designing A Time bound resource download URLDesigning A Time bound resource download URL
Designing A Time bound resource download URLRuncy Oommen
 
Empowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintEmpowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintMahmoud Rabie
 
Machine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdfMachine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdfAijun Zhang
 
20230202 - Introduction to tis-py
20230202 - Introduction to tis-py20230202 - Introduction to tis-py
20230202 - Introduction to tis-pyJamie (Taka) Wang
 
How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?IES VE
 
Igniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration WorkflowsIgniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration WorkflowsSafe Software
 
Building AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptxBuilding AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptxUdaiappa Ramachandran
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdfPedro Manuel
 
Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024SkyPlanner
 
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IES VE
 
VoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBXVoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBXTarek Kalaji
 
Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Adtran
 
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfUiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfDianaGray10
 
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve DecarbonizationUsing IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve DecarbonizationIES VE
 

Dernier (20)

COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online CollaborationCOMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
 
9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team
 
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesAI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
 
Introduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxIntroduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptx
 
Computer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsComputer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and Hazards
 
Designing A Time bound resource download URL
Designing A Time bound resource download URLDesigning A Time bound resource download URL
Designing A Time bound resource download URL
 
Empowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintEmpowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership Blueprint
 
Machine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdfMachine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdf
 
20230202 - Introduction to tis-py
20230202 - Introduction to tis-py20230202 - Introduction to tis-py
20230202 - Introduction to tis-py
 
How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?
 
Igniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration WorkflowsIgniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration Workflows
 
Building AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptxBuilding AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptx
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdf
 
Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024
 
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
 
VoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBXVoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBX
 
20150722 - AGV
20150722 - AGV20150722 - AGV
20150722 - AGV
 
Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™
 
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfUiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
 
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve DecarbonizationUsing IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
 

Cordova kovich sargusingh

  • 1. L. Cordova, C. Kovich, M. Sargusingh
  • 2. Agenda • Introduction • Model Based Requirements Development & Management Approach – Ops Con/models – Environments – Architecture – Interfaces – Functions – Decomposition – Performance Measures – Requirements / Verification – Functional Analysis – Technical Planning – Documentation • Conclusion 3/2/2012 NASA PM Challenge 2012 2
  • 3. Introduction • What is Model-Based Systems Engineering? – Model-Based Systems Engineering (MBSE) is the formalized application of modeling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases (INCOSE-TP-2004-004- 02, Version 2.03, September 2007) • Why is it important? – Ensures traceability and completeness of systems engineering products (e.g., Ops Con, Requirements, Verifications, etc.) – Is an approach to systems engineering where information about the system is defined, standardized, and interdependent during the lifecycle process – Is a key step in moving from a “document-based” configuration management approach to a “data object or model-centric” approach 3/2/2012 NASA PM Challenge 2012 3
  • 4. Overview • The NASA Johnson Space Center EVA Office Systems Engineering and Integration (SE&I) team utilizes MBSE to develop and manage requirements for an evolving, complex system that spans multiple programs •Seated vehicle operations •Occupant protection The space suit architecture must Crew Escape •Post-landing suited ops meet various and often conflicting & Survival •Contingency crew survival mission objectives while •Fire & Tox protection optimizing •Water survival mass, volume, reliability, and •Rapid cabin depress maintainability •Unpressurized 144 hr return •Pressurized -g mobility •Environmental protection •Vehicle supported or •Mobility to perform Microgravity Surface independent life support partial-g surface EVA EVA EVA •Vehicle Maintenance/ •Environmental protection Reconfiguration •Independent Life Support 3/2/2012 NASA PM Challenge 2012 4
  • 5. Space Suit System (EVA System Reference 2) • The original design solution developed for Constellation involved a modular, reconfigurable, component-based architecture LEA/Microgravity EVA Suit* Lunar Surface EVA Suit (aka Configuration 1) Interchangeable (aka Configuration 2) Common Components: Components: Modular Components Suit Multiple Connector Helmet, Visor Torso Assemblies (not shown) Assemblies Gloves Vehicle Multiple Connector Pressure (not shown) Garment Segments Pressure Garment Materials & Design Emergency Oxygen Life support umbilicals * Notional picture does not Thermal include: Life Preserver and Undergarments Emergency Breathing systems 3/2/2012 NASA PM Challenge 2012 5
  • 6. Lunar Crewed Mission • In the Constellation Program Lunar Design Reference Mission (DRM), the suited crewmember, and therefore the space suit, is in involved in all phases and interfaces with multiple systems MOON Lunar Surface IVA Suit Config 2 Lunar Surface EVA LLO Microgravity EVA Microgravity IVA Suit Config 1 ERO LEA Configuration EARTH 3/2/2012 NASA PM Challenge 2012 6
  • 7. Space Suit Interfaces • The space suit interfaced with every crewed vehicle included in the Constellation architecture 3/2/2012 NASA PM Challenge 2012 7
  • 8. MODEL BASED REQUIREMENTS DEVELOPMENT & MANAGEMENT APPROACH 3/2/2012 NASA PM Challenge 2012 8
  • 9. Implementation of the SE Engine Model-centric approach helps to keep this as robust yet nimble as Agency, Center, & Program possible Requirements The integrated system will have to be evaluated to verify that the hardware will be safe enough for EVA • Ops cons will be used to help determine D&C spec applicability; • DRM derived functionality will be used to support agency mission architecting activities Occurs in Hardware Hardware specs, and the Team and below (i.e. necessary ICDs; prime contractor) additional levels of Perform and/or support documentation will be hardware trades & analysis created if needed such as mass assessments and design compliance Figure: NASA/SP-2007-6105 Rev1 3/2/2012 NASA PM Challenge 2012 9
  • 10. EVA Systems Integrated Data Infrastructure Model Based Data Infrastructure Allows us to better trace the requirements synthesis process and logic (i.e. why we have the Makes data accessible to requirements we have) various stakeholders Program Management Designers Mission Architects Maintains data and traceability to support future analysis and requirements development efforts Safety Contractors Mission Ops Provides Data & Documentation to support EVA Systems Operations and Hardware Development 3/2/2012 NASA PM Challenge 2012 10
  • 11. System Model Framework • The Space Suit System Model includes definitions of the three basic parts of the technical baseline (aka the Tri-Force): operational concepts, architecture/design, and requirements • By capturing all of the connections between the technical baseline, we experienced a significant efficiency improvement in analysis and identification of change impacts 3/2/2012 NASA PM Challenge 2012 11
  • 12. Operational Concepts Generic tech baseline would be available for basic families of hardware Design & Construction Specs DRM Capabilities Function A Class A Program Specific Capabilities Function A Arch A Ops Con Perf 1 Config 1 Perf 2 Config 2 Env. Req A.1 Ver A.1 Allocated Derived Relational 3/2/2012 NASA PM Challenge 2012 12
  • 13. Operational Models • The Space Suit DRM decomposes program-level operations into suit- focused activities and adds contingency operations/transitions Long Delay Return to CSUF Simulations Fit Checks 14 13 3 Launch Countdown Call-to-Stations CDDT Arrival Launch Site Receipt CSUF Vehicle Uncrewed Transfer Ingress of Testing Shipping Suit Up of Hardware Processing Assembly Testing to Vehicle Orion Hardware 2 5 10 6 7 8 9 11 12 1 Training Prepare 4 for Launch Pad Emergency Egress 15 29 Launch Pad Abort Scrub Launch Abort OR Ascent Abort 28 30 Liftoff Ascent Contingency On Orbit Events 16 Contingency Landing and Rescue 31 Microgravity 33 IVA ISS Contingencies Operations 32 17 Ship to ISS RPOD Recovery Egress Post Water Don Suit and Processing Entry Checkout Doff Suit Processing Orion Landing Landing Ingress Vehicle Facility 18 22 20 19 26 25 24 23 21 27 3/2/2012 NASA PM Challenge 2012 13
  • 14. Operational Concepts • The Space Suit Operational Concepts (Ops Con) serve as the basis for communication between our stakeholders and designers – Stakeholders help us to understand their expectations on what the suit capabilities are and how it will be used – Designers provide information on how the suit is expected work • Operational concepts are currently presented in document format: – Multi-Purpose Crew Vehicle (MPCV) Flight Suit Element Operational Concept provides Ops Con associated with Block 0 and Block 1 MPCV operation – International Space Station (ISS) Detailed Test Objective (DTO) Design Reference Document contains Ops Con associated with the Extravehicular Mobility Unit (EMU) Demonstrator – Advanced EVA Operations will contain the Ops Con associated with the Capability Driven Framework DRMs 3/2/2012 NASA PM Challenge 2012 14
  • 15. Environments Generic tech baseline would be available for basic families of hardware Design & Construction Specs DRM Capabilities Function A Class A Program Specific Capabilities Function A Arch A Ops Con Perf 1 Config 1 Perf 2 Config 2 Env. Req A.1 Ver A.1 Allocated Derived Relational 3/2/2012 NASA PM Challenge 2012 15
  • 16. Environments • The system model framework included several aspects of the space suit environments: – Definition of environments to which the hardware could be subjected – Definition of environments in which the hardware needs to operate – Definition of environments to which the hardware would be optimized – Requirements specifying the environments to be created by the space suit • The space suit environments definitions were scattered across several documents with no mapping to operational concepts, requirements or capabilities – We were able to publish the definitions in 1 document • Environments map to specific operations from the Ops Con model – Using the definition to Ops Con mapping, the environments could be traced to requirements and verifications 3/2/2012 NASA PM Challenge 2012 16
  • 17. Architecture Generic tech baseline would be available for basic families of hardware Design & Construction Specs DRM Capabilities Function A Class A Program Specific Capabilities Function A Arch A Ops Con Perf 1 Config 1 Perf 2 Config 2 Env. Req A.1 Ver A.1 Allocated Derived Relational 3/2/2012 NASA PM Challenge 2012 17
  • 18. Hardware “Classes” • The “class” hierarchy defines the scope of the project Space Suits • A “class” of hardware Class defines a generic technical baseline Flight Suits EVA Suits – Default set of standards & specifications – Supports a generic set of Generic operational scenarios Physical MPCV ISS DTO Flight Suit Suit • Generic functions Architecture • Generic hardware • Provides a platform for Configurable MPCV MPCV mission specific systems Physical Flight Suit Flight Suit Architecture Block 1 Block 2 engineering 3/2/2012 NASA PM Challenge 2012 18
  • 19. Interface Management • The Architecture is further defined with Physical Architecture Diagrams (PADs) showing the system interfaces * Flight Crew Equipment (FCE) * FCE/LEA LEA/FCE FCE/LEA FCE/LEA LEA/FCE FCE/LEA LEA/FCE FCE/LEA Structures Loads Loads Human Nutrition Nutrition Medication Medication Factors * Flow notation is From/To * Orion/LEA Breathing Gas LEA/Orion Breathing Gas LEA/GS Audio Orion/LEA Audio GS/LEA Audio LEA/Orion Audio LEA/GS Size MPCV Orion/LEA Cooling Fluid * Flight Ground GS/LEA Power Suit LEA/Orion Cooling Fluid Systems * Orion * LEA/GS Loads Element (GS) Orion/LEA Loads * GS/LEA Loads *1* LEA/Orion Loads LEA/Orion Data LEA/GS Thermal Orion/LEA Potable GS/LEA Breathing Gas LEA/Orion Size Orion/LEA Power Water 3/2/2012 NASA PM Challenge 2012 19
  • 20. Functions Generic tech baseline would be available for basic families of hardware Design & Construction Specs DRM Capabilities Function A Class A Program Specific Capabilities Function A Arch A Ops Con Perf 1 Config 1 Perf 2 Config 2 Env. Req A.1 Ver A.1 Allocated Derived Relational 3/2/2012 NASA PM Challenge 2012 20
  • 21. Functional Decomposition • Functions provide the link between operations, architecture, and requirements (Tri-Force) • Functions were created using two methods: 1. Decomposition from Program allocated “capabilities” through a hierarchical approach 2. Derivation from the operations Capabilities Function A Program Specific 1 Capabilities Ops Con 2 Function A 3/2/2012 NASA PM Challenge 2012 21
  • 22. Decomposition from Capabilities • Capabilities are high level/programmatic functions – Capabilities decompose into lower level functions specific to the system of interest – Capabilities were included to show traceability to Program allocated functionality Return Capability crew to Earth Protect Minimize Distribute Provide the effects of launch and hearing crew orthostatic landing loads protection from intolerance flail Function Distribute Limit Distribute loads Provide Provide vibration Limit chest loads within between head neck to the deflection the suit the suit and protection protection crew seat 3/2/2012 NASA PM Challenge 2012 22
  • 23. Derivation from Operations Operation FFBD Performance Suit Up Operation Function Interface Measure Indicates a specific Mobility to mate 10 range of motion and an umbilical Indicates a leak torque at 1.0 psid unpressurized threshold at 2.0 psid Mobility to demate Leak check Provide mobility an umbilical pressure unpressurized Maintain Perform Don Pressurize OR OR AND AND AND total controlled suit suit pressure depressurization Maintain If cooling is Connect to relative required services humidity AND Provide mobility Provide adjustable Provide temperature control Provide adjustable portable AND temperature cooling J control Maintain breathing air concentrations Disconnect from Provide two-way services GS/LEA LEA/GS GS/LEA LEA/GS communication to Power Breathing Gas Audio Audio crewmember 3/2/2012 NASA PM Challenge 2012 23
  • 24. Requirements Generic tech baseline would be available for basic families of hardware Design & Construction Specs DRM Capabilities Function A Class A Program Specific Capabilities Function A Arch A Ops Con Perf 1 Config 1 Perf 2 Config 2 Env. Req A.1 Ver A.1 Allocated Derived Relational 3/2/2012 NASA PM Challenge 2012 24
  • 25. Requirements – SRD Structure • The class hierarchy produces a requirements set that is easily extensible to future suit developments – Establishes a set of generic space suit reqs/standards – Builds upon generic reqs by allowing for vehicle/mission specific reqs to be captured • Linking requirements to higher level classes limits “starting from scratch” when new programs are stood up • This structure was created to maintain horizontal integration across all suited efforts 3/2/2012 NASA PM Challenge 2012 25
  • 26. Derived Requirements Design & Construction Specs Standard: Class A The WMS shall prevent direct contact of contained urine with the crew’s skin Arch A Config 1 Config 2 Req A.1 26
  • 27. Derived Requirements Design & Construction Specs Standard: Class A The WMS shall prevent direct contact of contained urine with the crew’s skin Physical constraint: Arch A The 12-hr MAG shall fit Config 1 within the allocated Config 2 stowage volume. Req A.1 Ver A.1 27
  • 28. Derived Requirements Design & Construction Specs Standard: DRM Capabilities Function A Class A The WMS shall prevent direct contact of contained Program Specific Capabilities urine with the crew’s skin Physical constraint: Function A Arch A Ops Con The 12-hr MAG shall fit Perf 1 Config 1 within the allocated Perf 2 Config 2 stowage volume. Req A.1 Functional/Performance: The MPCV Flight Suit shall contain urine for 12 hours during Flight Test Missions 28
  • 29. Derived Requirements Design & Construction Specs Standard: DRM Capabilities Function A Class A The WMS shall prevent direct contact of contained Program Specific Capabilities urine with the crew’s skin Physical constraint: Function A Arch A Ops Con The 12-hr MAG shall fit Perf 1 Config 1 within the allocated Config 2 stowage volume. Env. Req A.1 Functional/Performance: The MPCV Flight Suit shall contain urine for 12 hours during Flight Test Missions Environment Definition: The WMS shall function after stowage in the Orion pressurized volume 29
  • 30. Requirements Validation • Requirements were initially developed from Subject Matter Expert (SME) input and decomposition/flow down of program allocated requirements – Though the Ops Con was used to derive some requirements, they were not initially linked • Audits were used to show that program allocated requirements were answered in our requirements set (traceability report) • The “Tri-Force” allowed for validation of the requirements set from a functional perspective (did we have the right requirements) • After developing the MBSE framework, the requirements were linked to the System level models through the functional analysis and interface definitions – This aided in identification of impacts for a proposed change to the technical baseline 3/2/2012 NASA PM Challenge 2012 30
  • 31. Verification • Verification planning – Begins early in the project life cycle – Updates to verification planning will continue throughout the logical decomposition and design development phases, especially as design reviews and simulations shed light on items under consideration in the requirements development phase • Our verifications were drafted along with the requirements to ensure that we had verifiable requirements – All verifications are linked to their respective requirement – The Environments map to specific operations from the Ops Con model which was intended to support the verification planning • Certification is a classification applied to environments if the verification for the requirement calls for ‘certification’ in a specified environment Without a verifiable baseline and appropriate configuration controls, later modifications could be costly or cause major performance problems for your system 3/2/2012 NASA PM Challenge 2012 31
  • 32. Verification Roles & Responsibilities • A need to clarify verification roles and responsibilities was realized during discussion regarding requirements that were applicable to the prime contract: – Which party is responsible for developing detailed verification objectives (DVO) – Which party is responsible for executing per the DVO • Approach – Responsibility categories were developed to group verifications of similar scope and complexity. Establishing categories (buckets) ensured that approaches were consistently applied and that any exceptions to the philosophy were noted • Assumptions – Requirements/children sharing equivalent scope will not duplicate verification efforts (this is based on similar/equal requirements residing at multiple levels) – Requirements sharing equivalent scope and functionality (noun changes) need to share a verification approach 3/2/2012 NASA PM Challenge 2012 32
  • 33. Technical Planning • We also used Issues and Actions to aid in technical planning – Issues were comprised of those items considered To Be Determined (TBD) and To Be Resolved (TBR) – Actions were items used to track open work that was not part of the TBD/TBRs but were necessary to update the technical baseline – Both Issues and Actions were associated with the following items: • Ops Con • Architecture • Functions • Requirements • Verifications • Environments 3/2/2012 NASA PM Challenge 2012 33
  • 34. Documentation • Templates were created to generate documents with particular formatting – Templates were hardcoded to pull in particular document sections with associated linked data • Documents were generated by printing out specified items based on the associated links (e.g. requirements linked to architecture items) – Without changing our current structure, the linkages also allowed us to create documents for specific DRMs or suit configurations (e.g. SRD, ERD, contract applicable requirements) • Data can also be extracted using a query – Exports can be performed in csv, rtf, or HTML formats 3/2/2012 NASA PM Challenge 2012 34
  • 35. Other models • Several models have been used to develop and validate system requirements – Wissler Model – Thermal Desktop CFD Model – Excel Pressure Drop / Flow Model – Macroflow Pressure Drop Model – EVA System Mass Tracker • These models are configuration managed (i.e. data managed) by the analyst (except Wissler) – Model descriptions and results are presented to peers and stakeholders as part of analysis process – Results are evaluated and used to support requirements validation or change package • There are no direct links between analytical models and SE Database 3/2/2012 NASA PM Challenge 2012 35
  • 36. THE SPACE SUIT MBSE APPROACH PUT TO THE TEST In response to the announcement of the cancellation of Constellation (2/1/10), the EVA Systems Engineering & Integration team was given the challenge to reduce contract scope commensurate with the redirection and minimize overhead associated with engineering the system 3/2/2012 NASA PM Challenge 2012 36
  • 37. Initial Scope of the Mission 3/2/2012 NASA PM Challenge 2012 37
  • 38. Updated Scope After the 2/1/11, the EVA System scope was reduced to include only ISS Missions 3/2/2012 NASA PM Challenge 2012 38
  • 39. EVA System Re-Architecting • An SE&I Tiger Team was stood up and given three weeks to update the technical baseline per the reduced scope: – Update to the operational concepts – Identify the relevant requirements from Level 2 (CARD), Level 3 (SRD), Level 4 (ERDs), HSIR, and IRDs – Updating the deliverable components list – Update to technical resource allocations (mass, volume) – Update verification responsibility – Update the Applicable Documents List • Reports of requirements with mission phase applicability and parent-child relationships identified helped to expedite this process • Existing models defining mass helped to expedite update to mass allocations 3/2/2012 NASA PM Challenge 2012 39
  • 40. Model Updates • Changes to the model instigated by this effort: – Implemented linkage of requirements to hardware configurations instead of mission phase “technical points of contact” – Separating out of functional requirements with mission / configuration dependent performance specs • Documents can be generated by printing out requirements linked to certain architecture items • Without changing the current structure, these additional links will allow creation of LEA-focused documents: – J-19 – SRD – ERDs 3/2/2012 NASA PM Challenge 2012 40
  • 41. Requirements Streamlining Effort • In order to minimize systems engineering overhead, a restructuring effort was undertaken to reduce the number of requirements in the EVA System requirements set; this would save resources by reducing unnecessary requirements management and verification activity – Delete redundant requirements – Merge related requirements where appropriate – Goal was to maintain each “requirement” only once in the entire technical baseline; i.e. Do not duplicate an Interface Requirement Document (IRD) requirement in the SRD • At this time, the requirements were also leveled – We took the existing SRD and 2 Element Requirement Documents (ERDs) and combined them into one document. Goals of this effort included the following: • Levied the requirements at the level appropriate for verification, i.e. pushed Contract End Item (CEI) specific requirements down to the CEI Specification Documents • We updated the model framework to produce a requirements set that is easily extensible to future suit developments – Established a set of generic space suit standards in the EVA SRD 3/2/2012 NASA PM Challenge 2012 41
  • 42. Requirements Leveling Approach • EVA SRD System-level requirement – Functions that include multiple elements – Standards that apply to multiple suit developments • EVA SRD Element-level requirement – Decompositions specific to suit development – Allocations where Project-level margins are desired – Requirements necessary to bound contract scope • LEA Suit ERD-level requirement – Decompositions that are appropriate for the Element-level – Element-level details where contractor ownership is desired • Subsystem-level requirement – Section removed; allocation directly to CEIs from the Element-level – Rely on the assignment of technical owners to track responsibility for applicable requirements 3/2/2012 NASA PM Challenge 2012 42
  • 43. Push to Data-Centric • The EVA Systems Engineering Model inherently captures the SE definition in a data centric manner (as opposed to document- centric) • Through use of publishing software, this data is sorted and presented in document format per the customers requirements • A data-centric configuration management approach was developed but never implemented by the EVA Office due to resource constraints • Things yet to be considered – Linkage to applicable documents – Implementation of document-centric requirements and other systems definition artifacts applied by the Program or other authoritative sources 3/2/2012 NASA PM Challenge 2012 43
  • 44. NEXT STEPS 3/2/2012 NASA PM Challenge 2012 44
  • 45. Develop “Generic” Models • Utilize the system model developed for Constellation to develop a generic space system model • Development of a generic model would reduce “start-up” cost and time and time for a new program – Basic operational concepts, capabilities and even requirements would already be defined – The time to establish the data infrastructure would be significantly reduced • A generic system model would aid in mission architecting studies – Basic capabilities would be defined to support high level functional analyses – Basic operational concepts would be defined to support high timeline analyses – Resource utilization could be defined to support trade studies and help size supporting systems • Capturing basic design features will help lead to suit design standards 3/2/2012 NASA PM Challenge 2012 45
  • 46. Generic-EVA System Generic Operational Models Flight Suit Class EVA Suit Class Mission Transportation Launch Preparation to Destination CDDT Crew Worn Stowed Flight Ops Stowed Stowed Training Unpressurized Destination cabin survival Assembly, Test, Activities Fitcheck, etc. Emergency Stowed Contingency EVA Vehicle Egress EVA Post-Landing Earth Entry / Return Processing Landing Transportation Crew Worn Stowed Generic model overlaid by Generic flight suit and EVA suit Stowed Stowed operational models 3/2/2012 NASA PM Challenge 2012 46
  • 47. Update Model to Capitalize on Class Definitions MPCV Flight Test Flight Suit DRM Pressure Crew LSS PAS Garment Survival ISS DRM PGA Vent Kit CCA LPU Lunar Transit DRM Thermal Helmet AIU EBA Kit Fcn: Contain Gloves Biomed Waste MAG … for 12 hrs 12-hr MAG LCVG … for 48 hrs 48-hr MAG FRCL … for 144 hrs 144-hr WMS 3/2/2012 NASA PM Challenge 2012 47
  • 48. Performance Items to be Implemented • We realized that multiple requirements were required for each function based on the specific performance required for a particular mission / program • We are currently exploring the best method for implementing performance items – Performance items would link to functions in accordance with specific ops con – Functions would continue to link to architecture items, and performance specifications would be linked to specific configurations Basic Suit Function Waste Mngmt WMS Flight Test DRM 12 hr MAG ISS Transport DRM 48 hr Long Duration WMS Req A.2 Req A.1 Ver A.2 3/2/2012 NASA PM Challenge 2012 Ver A.1 48
  • 49. Data-centric Configuration Management • Control data not documents • Allows contextual data (e.g. concepts of operations, functional analysis, etc) to be reviewed along with controlled data such as requirements • Data objects can be published in various reports customized to the stakeholder without compromising the integrity of the data • Allows for more comprehensive stakeholder review • Shifts emphasis on content of the data instead of the scope of a document 3/2/2012 NASA PM Challenge 2012 49
  • 50. LESSONS 3/2/2012 NASA PM Challenge 2012 50
  • 51. Lessons Experienced… • Tools and processes for complex systems need to be architected just as carefully as the hardware being developed – Want to implement something before folks get comfy • Fancy tools are only useful if people use them – Grandfathered processes – Parallel processes • Data-centric is great… in theory – People think in documents – Determination of what data needs to be controlled is not as intuitive as with documents • Communication interfaces are just as important as the data being provided – Not everyone needs to handle the data in its native/source environment – We need to show it the way that people can read it … time will tell if these lessons were learned 3/2/2012 NASA PM Challenge 2012 51
  • 52. QUESTIONS 3/2/2012 NASA PM Challenge 2012 52
  • 53. BACK-UP 3/2/2012 NASA PM Challenge 2012 53
  • 54. Mass Tracker Spreadsheet MEL and MGA multipliers feed the component Mass spreadsheet Mass Spreadsheet feeds manually assembled configuration spreadsheets Configuration totals feed a page which contains historical data TPM graph is generated from We want to get this in the SE database as soon as the historical data worksheet we can get it to do math!!! 3/2/2012 NASA PM Challenge 2012 54
  • 55. Design Compliance • Requirements Design Compliance purpose is to objectively determine if the preliminary design can be expected to meet requirements to an acceptable level of risk • The objectives of requirements design compliance include – Identify and establish resolution paths for architectural performance/design issues as early in the design cycle as possible • Proactively manage ‘acceptable level of risk’ • Early issue resolution/prevention reduces cost and schedule impacts • End-to-End mission perspective – Utilize objective design evidence to determine success of design cycle, from architecture perspective of the design reference mission (DRM) and operations concepts (ops con) – Facilitate vertical integration of design compliance data with Projects and horizontal integration across level II – Report and track significant design compliance issues (design compliance matrix is only one part of design compliance) – Engage architecture requirement owners in design aspects in preparation for requirement verification (‘get our hands dirty’) 3/2/2012 NASA PM Challenge 2012 55
  • 56. Verification Logic Network (VLN) • VLN is: – A strategy to provide evidence of closure for each Detailed Test Objective (DTO) – Bottoms-up plan by which verification events can be efficiently executed (ensures efficient grouping of requirements) • Will logically group multiple requirements that can be verified with one activity • Verification event can be a DAC cycle closure, MEIT, FEIT, DSIL event, Flight Test, Mission Sim – Graphical representation of the verification events to close out the applicable requirements set (i.e. CARD, IRD, SRD) – Aid in identifying gaps and/or any overlaps in the verification planning process • Schedule conflicts • Delivery conflicts with hardware or software • Clarify test configurations and processes • In summary, a VLN is an integrated system verification activity network 3/2/2012 NASA PM Challenge 2012 56

Notes de l'éditeur

  1. Lauren
  2. This is a great example! Some of my thoughts on the questions:NGOs are like the standards – they are imposed from above (higher level capabilities or functions that are parents to the pink box).I think the EVA System requirements would be the same.We have interface requirements, but I think those could be covered by the physical constraint box. In the end, probably all our requirements could fit in the boxes you have, although there may be a more specific name that can be applied. I believe you have covered all the flow paths for requirements.
  3. This is a great example! Some of my thoughts on the questions:NGOs are like the standards – they are imposed from above (higher level capabilities or functions that are parents to the pink box).I think the EVA System requirements would be the same.We have interface requirements, but I think those could be covered by the physical constraint box. In the end, probably all our requirements could fit in the boxes you have, although there may be a more specific name that can be applied. I believe you have covered all the flow paths for requirements.
  4. This is a great example! Some of my thoughts on the questions:NGOs are like the standards – they are imposed from above (higher level capabilities or functions that are parents to the pink box).I think the EVA System requirements would be the same.We have interface requirements, but I think those could be covered by the physical constraint box. In the end, probably all our requirements could fit in the boxes you have, although there may be a more specific name that can be applied. I believe you have covered all the flow paths for requirements.
  5. This is a great example! Some of my thoughts on the questions:NGOs are like the standards – they are imposed from above (higher level capabilities or functions that are parents to the pink box).I think the EVA System requirements would be the same.We have interface requirements, but I think those could be covered by the physical constraint box. In the end, probably all our requirements could fit in the boxes you have, although there may be a more specific name that can be applied. I believe you have covered all the flow paths for requirements.
  6. Use unnamed category value – will sum values for youMust investigate…