The document discusses the development of requirements for a vehicle through model-based systems engineering. It provides examples of models that can be used to capture a vehicle's operational concept, including a design reference mission diagram, a phase model, and an activity model. The models aim to depict how the vehicle and crew interact during different mission activities and phases to achieve objectives. They are used to identify vehicle capabilities and functions needed to implement the operational concept.

1. Streamlining Requirements
Development through
Model-based Systems
Engineering
Robert Bayt,
Ann Christian,
Philip Nerren, and
Rich DeLoof
Altair Project Integration
Used with Permission

2. Role of the System Requirements Document
Objectives
♦ 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. 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. 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. 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
roles
Implementing 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. 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 Docking
Prep Start complete
Earth
Orbit Lunar
Operations Orbit
Maintenance Post-Surface
LSC.8 Operations
LSC.15
Docking LSC.17
complete
Altair/LIDS
LEO RPOD Jettison
Operations
LSC.7
ATP for Trans-Earth
Orbit Ops Cruise
LEO LSC.18 Final
Configuration Entry
(Post-Insertion) Prep
<EI-12>
LSC.6
Orbit
Insertion
Burn
Earth
Arrival
Operational
Operations
Complete
Ascent LSC.19 Hierarchy
SM
LSC.5 Separation
Terminology
Liftoff
Phase
Re-entry/Entry
Launch (Operation) LSC.20
Fwd Bay
DRM
LSC.4
Cover
Jettison
LCD 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. 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 Touchdown
Complete 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. 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
Concurrence
Change
Maneuver Compute Maneuver DOI Burn
Update
Complete 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 DRM
Goal:
-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. 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
Concurrence
Change
Maneuver Compute Maneuver DOI Burn
Update
Complete 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. 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. 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. Example Functions
Cabin Lander State
Pressure =
12 psi
Generate
Health Request Health and
Cabin Pressure Control (multiplexer) Status Lander Status
Set-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. Define Subsystem Modes
A system mode is defined to be a distinct operating capability of the system
during which some or all of the system's 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. 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. Requirements linked to Sustain Environment
LNDR.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. 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. 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

18. Streamlining SRR Product Development
Cradle OpsModels as the Authoritative
Separate Products Incur Existing Products are created by
Integrated Source for Operations
Substantial Coordination Costs Extracting Reports from Cradle Models
Information eliminates Product Synch
Lunar Lander Project
TLI Burn Start LOI LOI Burn
Pwrd
Descent
ATP
Initiate
Pre-Descent
Published from Cradle
Lunar Lander Project
Complete Burn Prep Complete Initiation
Burn Prep
Pre-Surface Lunar Lunar Ascent
TLI Trans -Lunar LOI Surface and RPOD
Operations Lander
Preparation Cruise Operations AND Operations AND
Operations
(LDO) Descent
LSC.9 LSC.10 LSC.11 LSC.12 LSC.13 LSC.14 (LRO)
Docking LSC.16 Docking
Complete RPOD Complete
Operations Lunar
(LEO) Orbit
Maintenance TEI
LSC.8 Operations
Initiate LSC.15
Rendezvous LSC.17
Burn TEI Burn
LEO Loiter Complete
LSC.7
Earth
'Go' for
Trans
-
Operations Concept Orbit Ops Cruise Final
LEO
Configuration LSC.18 Entry
Document Prep
(Post-Insertion) <EI-12>
International Traffic in Arms Regulations (ITAR) Notice Orbit LSC.6
Insertion Earth
This document contains information which falls under the purview of the U.S. Munitions List (USML), as defined in the
International Traffic in Arms Regulations (ITAR), 22 CFR 120-130, and is export controlled. It shall not be transferred to
MNVR
Operations Concept
foreign nationals in the U.S. or abroad, without specific approval of a knowledgeable NASA export control official, and/or Arrival
unless an export license/license exemption is obtained/available from the United States Department of State. Violations
of these regulations are punishable by fine, imprisonment, or both.
Complete Operations Document
Ascent LSC.19 SM
Separation
LSC.5 International Traffic in Arms Regulations (ITAR) Notice
This document contains information which falls under the purview of the U.S. Munitions List (USML), as defined in the
International Traffic in Arms Regulations (ITAR), 22 CFR 120-130, and is export controlled. It shall not be transferred to
Report Generation
foreign nationals in the U.S. or abroad, without specific approval of a knowledgeable NASA export control official, and/or
T- 0 unless an export license/license exemption is obtained/available from the United States Department of State. Violations
of these regulations are punishable by fine, imprisonment, or both.
Re-entry/Entry
OPSCON
Launch
LSC.20 Fwd Bay
LSC.4 Cover
Jettison
LCD CTS
Pad Integrated
Stand start Post - Flight
Recovery
Descent
and
Alone
OPSCON
Operations Operations Operations Processing Landing
LSC.3 LSC.2 LSC.1 LSC.23 LSC.22 LSC.21
A B C D E F G H I
Sortie and Outpost Mission - Ares I/Ares V Launch Order, Zero Beta at LLO Undocking for Polar Sortie
1
Rendezvous, Proximity Operations, and Docking (RPOD) Operations (LEO) LSC.8
Phase Start: Initiation of the First Rendezvous Burn (Orion Chaser, Altair/EDS Target)
Transport to Arrival
Phase End: Completion of Post Docking Procedures (EDS Resumes Attitude Control)
MLP Hard Integration Post - Flight
2
DD250 Facility Touchdown
Lander attached to EDS (target)
Gear Folded
Lander attached to EDS
Docking in progress
Lander attached to EDS
Lander mated to CEV via LIDS Down Facility
System Configuration CEV in LEO (chaser)
Crew in CEV Suit Configuration 1
Gear Folded
LIDS Hatch Closed
Crew in CEV
Gear Folded
LIDS Hatch Closed
Crew in CEV
Complete Processing
3
Transition to Earth
Lander Mode Earth Rendezvous Mode
Rendezvous Mode
4
Compiled from Phase Models
Activity LEO Rendezvous Prep LEO Rendezvous Proximity Operations Docking Operations Post Docking Operations
5
Activity Duration 3 Hours 30 Minutes 1 Hour 26 Minutes 5 minutes 30 minutes
Reference Next start Next start End with Docking Mechanisms Latched Start with Docking Mechaisms Latched
6
Event
DRM Model
Docking Mechanisms Latched
Time MET 000/04:06:00 MET 000/09:37:00
MET = 000/09:07:00
(MET Referenced to Orion/Ares I Launch)
7
Operating in LEO as Rendezvous
Operating in LEO as Rendezvous
Chaser Crew life support Voice, Cmd, Data w/ Control Center
Chaser
CEV Crew life support
Crew life support Voice, Cmd, Data w/ Control Center Crew life support
Voice, Cmd, Data w/ Control Center Cmd & Data w/ EDS (RF) CEV Equalize Pressure
Voice, Cmd, Data w/ Control Center
8
Cmd & Data w/ EDS (RF)
Guidance and Nav
Electrical Power Generation
Guidance and Nav Trajectory and Attitude Cntl Guidance and Nav
Guidance and Nav
Trajectory and Attitude Cntl Cmd & Data w/ Control Center Free Drift At Contact
EDS Cmd & Data w/ Control Center Elec Power Generation Cmd & Data w/ Control Center
Trajectory and Attitude Cntl
Cmd & Data w/ Control Center
Elec Power Generation Cmd & Data w/ CEV (RF) Elec Power Generation
Elec Power Generation
9 Maneuver to Docking Attitude
System Functional Thermal Control Thermal Control
Thermal Control
Allocation Lander Monitor and Control Critical Parameters
Monitor and Control Critical Parameters Monitor and Control Critical Parameters
Visual Nav Aid (TBR)
10
Control Center Comm EDS - Control Center: Cmd & Data EDS - Control Center: Cmd & Data
Interfaces CEV - Cntl Center: Voice, Cmd, & Data CEV - Cntl Center: Voice Cmd, & Data
11
EDS to Lander: Power EDS to Lander: Power
EDS to Lander: Power
Element Interfaces EDS - Lander: Cmd & Data (Hardline) EDS - Lander: Cmd & Data (Hardline)
EDS - Lander - CEV: Cmd & Data (Hardline)
CEV - Lander: Cmd & Data (RF)
12
Power Distribute power from EDS (TBD kW)
13
Comm and Tracking Comm not active Provide RF comm with CEV Power down comm
Reports from Simulation
14
Provide CDH for thermal and ECLSS
Provide CDH for thermal and ECLSS subsystems subsystems
CDH Monitor and control critcal parameters on other subsystems Monitor and control critcal parameters on
Route cmds and data to / from EDS other subsystems
Route cmds and data to / from EDS and CEV
15
GNC not active
GNC GNC not active To support the RPOD operations of the CEV, the lander will provide a passive reflector. Other than this function, other GNC functions of the mated EDS/LLV stack are maintained by the EDS (instead of the LLV). To support
the RPOD operations with CEV (the chaser vehicle), the EDS will maintain the mated LLV/EDS configuration in a quiescent state.
16
Maintain radiator flow to prevent freezeup
Thermal Provide thermal control to powered subsystems
Provide thermal control to unpowered subsystems to maintain above min temperature
17
Lander Subsystems
Provide fire detection and supression to modules with powered systems
ECLSS Provide water to thermal as needed
18
Propulsion Monitor and Control Propellant Pressures and Temperatures
19
Structures and Mechanisms
20
Crew Systems
21
Lunar suit gear stowed in AM
EVA
22
Detailed Timeline
Altair Lunar Polar Sortie Mission Timeline - Ares I/Ares V Launch Order - Zero Beta at LLO Undocking - With Plane Change in LLO
Revisions for RAC-1
Flight Phase Activity Event (L minus), MET Duration Remarks
Issue DD250 Government Acceptance of Contract Deliverable Yellow = trajectory events. Lt. Blue = power transitions
Removal of Flight Hardware from Transportation L-152/00:00:00 002/00:00:00
Element Arrival Operations Transportation of Altair Elements (AM, DM, AL) to Note: All durations are notional. The Total time from the begiining
L-150/00:00:00 005/00:00:00
Processing Facility to the end of Ground Processing is the same as for LDAC-2.
Perform NASA-Approved Deferred
Unspecified L-150/00:00:00 000/00:00:00 Placeholder. Variable duration. No time allocated.
Work on Vehicle Elements
Perform Corrective Actions on
Unspecified L-150/00:00:00 000/00:00:00 Placeholder. Variable duration. No time allocated.
Lander Elements as Required
Install Altair Elements into Respective Test Stands. L-143/00:00:00 003/00:00:00
Element Receiving Inspections L-140/00:00:00 006/00:00:00
Element Non-Hazardous Commodity Servicing and Post-
L-134/00:00:00 006/00:00:00
Delivery Testing.
Element Standalone Processing
Altair Element Integration & Final Non-Hazardous
L-129/00:00:00 007/00:00:00
Standalone Servicing.
Operations (LSC.1) Element to Element Interface Verification L-122/00:00:00 006/00:00:00
Phase Model & Write-ups
Lunar Surface Systems (LSS) to Altair Integration &
L-117/00:00:00 007/00:00:00 Cargo DRM Only.
Testing.
Altair Integrated Systems Testing L-110/00:00:00 010/12:00:00
Lunar Multi-Element Integration Testing (MEIT) L-099/12:00:00 010/12:00:00
Final Internal AM & Airlock Cargo Stowage L-089/00:00:00 010/12:00:00 N/A for Cargo DRM. AM only for Outpost DRM.
Altair Integration & Test
Crew Equipment Interface Testing L-078/12:00:00 010/12:00:00 N/A for Cargo DRM
Ascent Module & Airlock Internal Closeouts & Hatch
L-068/00:00:00 006/00:00:00 N/A for Cargo DRM. AM only for Outpost DRM.
Closure Leak Checks
Altair Closeouts Altair External Closeouts L-062/00:00:00 006/00:00:00
Transport Altair to Hazardous Processing &
L-056/00:00:00 002/04:00:00
Simulation
Encapsulation Facility
Hazardous Offline Processing
AM/DM Hypergolic Propellant Servicing L-053/20:00:00 014/00:00:00 DM only for Cargo DRM
High Pressure Gas Servicing L-039/20:00:00 007/00:00:00
Encapsulation For Transportation
Encapsulation of Altair in Ares V Shroud L-032/20:00:00 007/00:00:00
to VAB
Transportation of Altair to
Transport Altair Elelements to VAB L-025/20:00:00 000/06:00:00
Integration Facility
Integrated Operations Integrated Vehicle Processing Lander/Shroud Arrival at VAB Transfer Aisle L-025/14:00:00 014/00:00:00
(LSC.2) Transportation of Stack to Launch
Transport Altair Stack to Launch Pad L-011/14:00:00 001/00:00:00
Pad
Pad Hard Down Operations Pad Hard Down L-010/14:00:00 000/02:00:00
Pad Operations Fuel Cell Cryogenic Servicing L-010/12:00:00 003/12:00:00
Pad Operations
(LSC.3) Cryogenic Propellant Servicing L-007/00:00:00 004/00:00:00
Call to Stations for Launch Call to Stations For Countdown L-003/00:00:00 000/00:00:00
Countdown - Pre-Tanking
Summary Timeline
Procedures Pre-Tanking Launch Countdown Procedures L-003/00:00:00 002/12:00:00
Launch (LSC.4) Go for Tanking Call - Cryogenic Go for Tanking L-000/12:00:00 000/00:00:00
Propellant Loading Tanking L-000/12:00:00 000/08:00:00
Call to Stations for Final Call To Stations for Final Countdown L-000/04:00:00 000/00:00:00
Countdown Final Countdown Procedures L-000/04:00:00 000/04:00:00 Times prior to MET = 000/00:00:00 are Launch Minus (L-) times
Booster Ignition Ares V/Altair/EDS Liftoff 000/01:42:00 000/00:00:01 Ares V T-0. MET = 000/00:00:00 is Ares-I/Orion Liftoff
SRB Separation 000/01:44:00 000/00:00:01
First Stage MECO 000/01:46:00 000/00:00:01
Ascent (LSC.5) EDS Separation & Ignition 000/01:46:05 000/00:00:05
Powered Flight
Shroud Jettison 000/01:46:30 000/00:00:00
Ascent Ops 1 000/01:46:30 000/00:05:30 5 minute 30 second interlude between scheduled events.
Insertion into LEO (EDS burn) 000/01:52:00 000/00:03:00
LEO Cruise Ops 1 000/01:55:00 000/00:27:00 27 minute interlude between scheduled events.
Transition to LEO Config Mode
Transfer EDS Power to Altair 000/02:22:00 000/00:05:00
Summary Timeline
Activity Model & Definitions Detailed Timeline
Cradle OPSModels (including attributes like durations, resource
usage, etc.)
Initial State Opportunity Desired State