Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. Streamlining RequirementsDevelopment throughModel-based SystemsEngineering Robert Bayt, Ann Christian, Philip Nerren, and Rich DeLoof Altair Project IntegrationUsed with Permission
  2. 2. Role of the System Requirements DocumentObjectives♦ Capture the vehicle-level capabilities in a set of complete, necessary, clear, attainable, traceable, and verifiable statements of need (Requirements) If it is not needed by Cx, it is • Should not be unduly restrictive1 not a vehicle-level capability • Sets limits that eliminate items outside the boundaries drawn • Encourage competition (or alternatives) • Capture source and reason of requirement♦ Establish the verification methods that will lead to product acceptance • These should be reproducible assessment methods♦ Allocate requirements to the element-level to facilitate vehicle architecture development and integration The SRD sets the standards by which the Product will be evaluated 1MIL-STD-961E - Reference 2
  3. 3. Where do Requirements Come From?♦ The Customer • One should always listen to the Voice of the Customer when establishing what the End Item should be able to do • On Altair, we walk through the CARD Allocated Requirements and Categorize by: − MOE − Operational − Functional/Performance − Safety/-ilities♦ Operational Analysis • Develop deep understanding of Concept of Operations to identify new End Item Capabilities that are required • Evaluate operational constraints♦ Technical Disciplines Best Practices • Work with discipline experts to establish capabilities required “to do the job”♦ Design and Construction Standards • Use industry standards to specify how the product is designed 3
  4. 4. Requirements Development Approach♦ Role of the Project is to validate requirements DRM • Necessary Phase • Attainable • Traceable Activity • Clear and Verifiable♦ Vehicle Functionality should flow Event from the Concept of Operations • How is the vehicle to be Functional operated? Modes • What functionality should be on-board to support these operations? Requirements Goal: Ensure Traceability from Missions to Functions to Requirements and Drive for Completeness 4
  5. 5. Requirements Development Approach - 2♦ Required vehicle functionality flows from the concept of operations and system of systems architecture.Prior to Models-Based Systems Engineering (MBSE):♦ OPSCON articulated our Concept of Operations • Captures at the phase/activity-level the general roles of the various systems in executing the mission • Timeline captures the events that make up these operations with some articulation of rolesImplementing MBSE:♦ OPSModels are flow diagrams that depict operations described in OPSCON with an allocation of responsibility of those events • Capture discrete events that make up an activity • Capture dependencies and data flow that make up those activities • Drive traceability of Operational requirements • Provide traceability of functionality to vehicle♦ Traceability comes through linking of data objects, and reports querying database depicts this traceability 5
  6. 6. Design Reference Mission: Lunar Sortie Crew Design Reference Mission: Lunar Sortie Crew EDS LOI Burn LOI Burn Undock ATP for Ascent Jettison Procedures Sequence Complete Lunar Stay Preparation Complete Begun Complete Start Pre-Surface Lunar TLI Trans-Lunar LOI Operations Altair Surface Ascent & Operations Cruise Operations (Docked) Descent AND Operations AND RPOD Operations LSC.9 LSC.10 LSC.11 LSC.12 LSC.13 LSC.14 LSC.16 TLI Burn DockingPrep Start complete Earth Orbit Lunar Operations Orbit Maintenance Post-Surface LSC.8 Operations LSC.15Docking LSC.17complete Altair/LIDS LEO RPOD Jettison Operations LSC.7 ATP for Trans-EarthOrbit Ops Cruise LEO LSC.18 Final Configuration Entry (Post-Insertion) Prep <EI-12> LSC.6 OrbitInsertion Burn Earth Arrival Operational OperationsComplete Ascent LSC.19 Hierarchy SM LSC.5 Separation Terminology Liftoff Phase Re-entry/Entry Launch (Operation) LSC.20 Fwd Bay DRM LSC.4 Cover JettisonLCD CTS Pad Operations Integrated Operations Stand Alone Post-Flight Processing Recovery Descent and Phase Operations Landing LSC.3 LSC.2 LSC.23 LSC.22 LSC.1 LSC.21 Activity MLP Hard Transport to Arrival Arrival at Sub- Integration DD250 at Refurb Post-Flight Touchdown Down Facility Complete Site Processing Facility Activity Trigger Event (Data Item) Authoritative Source: CxP 70007, DRMOCD 6
  7. 7. Phase Model – LSC.13 Lunar Descent The phase is decomposed into activities that are generally serial. Phase Transition Activity Plane Plane Undock Change Post DOI - ATP for Change DOI Burn Burn TouchdownComplete PDI Burn Lunar Stay Procedures Maneuver Initiation Procedures Initiation Initiation Complete Complete Free Perform Perform Perform Plane Prep for Perform Lunar Perform Post Flight Powered Change DOI DOI Descent Landing Operations Descent Maneuver Coast Checkout *LSC.13.1* *LSC.13.3* *LSC.13.4* LSC.13.2 *LSC.13.5* *LSC.13.6* *LSC.13.7* Abort Required Abort Required LSC.100.12.7 Abort Required Abort Required Abort Required G LSC.100.12.4 G DRM Phase Activity Event 7
  8. 8. Activity Model – LSC.13.3 Prep for DOI * Crew Activities are the DOI Burn Event Diagram can be simulated Prep Procedure * Concur Check with Crew Altair Execute AND AND Nav State AND AND Burn LSC.13.3.1 State LSC.13.3.2 Vector Accepted Crew Burn Altair Nav. Concurrence State Crew Burn Plane Request ConcurrenceChangeManeuver Compute Maneuver DOI Burn UpdateComplete Altair DOI Burn to Burn Initiation Nav. State Solution AND Attitude AND LSC.13.3.7 LSC.13.3.3 LSC.13.3.4 Go for DOI Burn Start Burn Time and Final dV Execute Perform Altair Nav. DOI Final DOI State Update Auto-Sequence Countdown LSC.13.3.5 LSC.13.3.6 Send Mission Altair Send Go Systems Nav. for DOI State Burn Update LSC.13.3.9 LSC.13.3.8 DRMGoal:-Capture how the vehicle is operated by the crew Phase - Show Crew or Other System actions and vehicle response- Boxes should be Actions that are triggered by: Activity - Completion of prior task (only solid arrow entering) - A signal from another system (dashed arrow w/ data item) Event 8 - Reaching a fixed start time (not shown in diagram, only shown in timeline)
  9. 9. Activity Model – LSC.13.3 Prep for DOI * Crew Activities are the DOI Burn Prep Procedure * Concur Check with Crew Altair Execute AND AND Nav State AND AND Burn LSC.13.3.1 State LSC.13.3.2 Vector Accepted Crew Burn Altair Nav. Concurrence State Crew Burn Plane Request ConcurrenceChangeManeuver Compute Maneuver DOI Burn UpdateComplete Altair DOI Burn to Burn Initiation Nav. State Solution AND Attitude AND LSC.13.3.7 LSC.13.3.3 LSC.13.3.4 Go for DOI Burn Start Burn Time and Final dV Execute Perform Altair Nav. DOI Final DOI State Update Auto-Sequence Countdown LSC.13.3.5 LSC.13.3.6 Send Mission Altair Send Go Systems Nav. for DOI State Burn Update LSC.13.3.9 LSC.13.3.8 Questions: - Is the operational concept complete? Is it Valid? - Are there any actions the crew or vehicle need to take to support your subsystem or vehicle objectives? - What capabilities from your subsystem or other systems are required to implement this operational concept? 9
  10. 10. WHAT Do We Want to Specify? Treat the Vehicle Sustain Environment Perform as a Black Box Communications (Inside and Out) Can the crew live in it? Can it interact with Provide the outside world? Transportation Can it carry and Accept and service Payload? Execute Can it take Commands Provide action upon Habitability Command?Can the crew work out of it? Perform Altair Manage Vehicle Can it move Maneuvers Performance Functional and follow a Architecture trajectory? Can it assess its own status? Establish the purpose of the System; Define Functions and Measures that Implement and Quantify achieving the Purpose 10
  11. 11. The Functional Architecture♦ A function is a process that takes inputs in and transforms these inputs into outputs1♦ The functional architecture of a system contains a hierarchical model of the functions performed by the system1♦ Functional Architecture • Capture required system behavior • When someone asks, “What should the Altair be able to do?”, we should be able to point to the functional architecture as the sum total of its capabilities (independent of the mission) • Highest-Level of the architecture developed by grouping Customer Functional Requirements − Walk through all the Cx requirements and categorize them (CARD, HSIR, C3I) − Group those in the category of functional or performance♦ Functions are need based not discipline based • Don’t need a Command and Data Handling System C&DH meets • Do need to be able to Accept and Execute Commands functional need 1Source Buede, D. , Engineering Design 11
  12. 12. Example Functions Cabin Lander State Pressure = 12 psi Generate Health Request Health and Cabin Pressure Control (multiplexer) Status Lander StatusSet-point = 10 psi Pressure Cabin (Crew Display Pressure = or Downlink) 10 psi Functional Thread – Perform Rendezvous Relative Navigation Manage Perform Trajectory Vehicle Translational Design Inertial Events Maneuver Navigation 12
  13. 13. Define Subsystem Modes A system mode is defined to be a distinct operating capability of the system during which some or all of the systems functions may be performed to a full or limited degree1 • Examples: On/Off/Standby or High Data Rate/Low Data Rate • Both are an expression of capability♦ Mode Matrix • Should be as concise a representation as possible of total vehicle capability for any activity in the mission♦ Mode Characterizations • Mode Names should clearly articulate the level of capability and of what function − Status – Active – Capabilities in use; Stndby – Capabilities available but not used; Inactive– No capability Control Pressure  Automatic Pressure Control  R.EA0703  Emergency Pressure Control  R.EA3107/3181 • Use Mode definitions can tie this to our current understanding of the vehicle Passive Cabin Pressure Relief Active  Mechanical positive pressure relief valves (PPRVs) are active, but do not require power. They are probably venting in this phase. 1Source Buede, D. , Engineering Design 13
  14. 14. Functional Architecture Modes Matrix♦ Cross Correlation of sub- LSC.13 : Altair Descent : Altair Functional Relationship mode for each scenario to Operations via Modes LSC.13.2 : Perform LSC.13.1 : Free Flight Plane Change • How much capability in Operations : Maneuver : LSC.13.3 : Prep for 000/01:03:27 000/00:00:00 DOI : 000/01:34:51 Transportation each subsystem is required LNDR.1.3 : Transport Crew LNDR.1 : Crew On-board Crew On-board Crew On-board Provide execute an activity♦ Definition of each sub- LNDR.1.5 : Transport EVA Suits EVA Suits Donned EVA Suits Donned EVA Suits Donned Habitabilit LNDR.2.1 : Provide exterior LNDR.2 : mode is captured Provide viewing Exterior Viewing Available Exterior Viewing Available Exterior Viewing Available y Reading + Panel Lighting Reading + Panel Lighting Reading + Panel Lighting♦ Capabilities should be met LNDR.2.2 : Provide Lighting On On On LNDR.3 : Perform in total by requirements LNDR.3.1.1 : Estimate Maneuvers Inertial State Inertial Navigation Active Inertial Navigation Active Inertial Navigation Active♦ In some cases, functions LNDR.3.2 : Perform Translational Maneuvers Main Engine Burn are provided by other LNDR.3.5 : Perform Trajectory Design Target Computation Active Target Computation Active systems, mode should Environmen LNDR.4 : LNDR.4.1 : Control Cabin Cabin Pressure Control Cabin Pressure Control Cabin Pressure Control Sustain Altair Pressure reflect other system is LNDR.4.2 : Control Active Temperature Control Active Temperature Control Active Temperature Control Temperature providing (i.e. Altair on Active Active Active LNDR.5 : Accept LNDR.5.1 : Receive and Execute Commands Orion Power) Commands from Cx Receive Commands Active Receive Commands Active Receive Commands Active LNDR.5.2 : Receive Commands from Crew Receive Commands Active Receive Commands Active Receive Commands Active cations Performan LNDR.7 : LNDR.6 : Perform Manage Communi Vehicle LNDR.6.2 : Perform FDIR Perform FDIR Active Perform FDIR Active Perform FDIR Active LNDR.6.4.1: Manage Power Load Altair On Internal Power Altair On Internal Power Altair On Internal Power LNDR.7.1 : Communicate RF-High Data Rate RF-High Data Rate RF-High Data Rate with Cx Systems RF-Low Data Rate RF-Low Data Rate RF-Low Data Rate 14
  15. 15. Requirements linked to Sustain EnvironmentLNDR.2 Sustain Altair LNDR.2.1 Control Pressure R.EA0703 LSAM Cabin The LSAM shall control cabin pressure to a This is to facilitate pressure operation from the Environment Pressure selectable setpoint between 79 (TBR-001-907) LSAM to Orion operational pressure to the kPa (11.4 psia) to 52 (TBR-001-908) kPa (7.5 minimum nominal limit with a 34% oxygen psia) with 0.7 (TBR-001-147) kPa (0.1 psia) materials limit and 17 kPa (2.5 psia) ppO2 crew increments for Lunar Sortie and Lunar Outpost limit. This is to have common approach to cabin crew missions. pressure management across Constellation Architecture. LNDR.2.2 Control Temperature R.LNDR.024 Cabin The Altair shall control cabin temperature per LNDR.2. Control Cabin Temperature HSIR 3054 while inhabited except during suited 2.1 Temperature Control operations. LNDR.2.3 Manage O2 and N2 R.EA3062 LSAM Cabin The LSAM shall limit the maximum oxygen This is to keep the oxygen concentration from LNDR.2. Control Pressure Oxygen concentration within the pressurized cabin to 34% exceeding the materials certification limit. This is 2.2 Component Concentration (TBR-001-038) by volume for Lunar Sortie and to have common approach to cabin pressure Temperature Limits Lunar Outpost crew missions. management across Constellation Architecture. LNDR.2.4 Control Humidity LNDR.2.5 Provide Ventilation LNDR.2.6 Control Contamination R.LNDR.023 Lunar Dust The Altair shall limit the levels of lunar dust Control contaminants of less than 10 and equal to or greater than 0.1 micron (TBR-006-004) size in the internal atmosphere below 0.05 mg/m^3. LNDR.2.7 Provide Fire Detection and R.EA3139 LSAM Fire The LSAM shall provide fire detection and This is to provide cabin fire detection, Surpression Detection and suppression for the LSAM pressurized volume for notification, and suppression. The type of fire Suppression Lunar Sortie and Lunar Outpost crew missions. detection and suppression required in the avionics bays will be a function of materials selection, proximity to ignition sources and oxidizers. LNDR.2.8 Provide Potable Water LNDR.2.9 Remove CO2 LNDR.2.10 Provide Waste Collection LNDR.2.11 Provide Galley Service LNDR.2.12 Provide Suit Loop Services LNDR.2.13 Pressurize Docking Vesitbule R.EA3137 LSAM The LSAM shall provide not less than two The responsibility for vestibule pressurization Vestibule vestibule pressurization cycles per mission for must be allocated between Orion and LSAM. This Pressurization Lunar Sortie and Lunar Outpost crew missions. requirement allocates responsibility for two Cycles pressurization cycles to LSAM. Primary and contingency vestibule pressurization should account for each docking in which the crewed LSAM is the active vehicle. The LSAM will perform the vestibule pressurization when the crewed LSAM docks with the Orion. Linking requirement enforces function 15
  16. 16. Requirements Achievability Assessments I.D Name R.EA0062 LSAM Return Cargo Capability Requirement The LSAM shall return at least 100 kg (TBR-EARD-037) (220 lbm) of Payload from the lunar surface to the Lunar Rendezvous Orbit (LRO) during each crewed lunar mission. Rationale The LSAM returned mass must include the 100 kg (220 lbm) of Payload specified by ESMD in addition to the crew and Flight Crew Equipment. This requirement applies to each crewed lunar mission and is needed to size the LSAM ascent stage. Comments Quality: Add the following to the rationale "This payload is to be stored in the pressurized environment, with no power / data / thermal services provided. The payload may include rocks, ISRU product samples, crew biological samples, failed components, crew personal effects. Anything which leaves the lunar surface to be returned to Earth, excluding crew and crew equipment, can be considered payload. This allocation is a total return mass allocation that includes containment and interface hardware masses required for transport. Note the objective in R.EA6304 is 250 kg." This requirement should be a KDR (as listed on the Lunar KDRs for Altair at LCCR). KDR Verification Reqt. Reqt. Group SRD POC Req Status Reqt. Criticality VI Involved Method Type Compliance Organization Analysis MOE Provide Dave McKissock Agreed green - High C1 Altair Flight Transportation Likelihood of Systems Compliance♦ Validation (Why a requirement on us?) • Is this philosophically the right requirement to set? r – Low Likelihood of • Is the value achievable/affordable per the results of an analysis task Compliance (<50% chance)♦ Verification (How do we apply it?) y – Medium Likelihood of • Is it clear how the customer wants you to measure the value? Compliance (50-80% chance) • How will you know when this requirement is implemented? g – High Likelihood of♦ Achievability (How are we doing against it?) Compliance (>80% chance) • Is the likelihood of compliance in the final design high/medium/low? grey - Unassessed • Choose from: Inherent in current design, captured in T/O, not assessed − If not assessed, tied to future task or risk? Close the Requirements Development Loop by Assessing Achievability in a Design Concept 16
  17. 17. Enablers for MBSE and Streamlining Requirements Development♦ A relational database for requirements and models • Cx Program uses CRADLE to store both requirements and models to enable traceability between objects through links♦ Clear understanding of SRR products • Establish upfront how all of the SRR Criteria will be met and how traceability will be demonstrated and use these products to drive the process • Get comfortable reviewing the raw products within the native environment to accelerate development by eliminating post-processing into chart packages♦ Detailed process definition to eliminate development bottlenecks • Develop criteria for generating every product to minimize variability • Organize the team for greatest distribution of effort • Utilize requirement development metrics and database reports measure progress and reinforce lagging areas Establishing these business processes as a NASA institutional core competency can greatly reduce project start-up resources 17