Search NASA⌕ Search

SEARCH · Search NASA

Results for “ConOps”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 145 records · Page 8
All sourcesNASA NTRSDOE OSTI
NASA NTRS2006

HALE UAS Concept of Operations. Version 3.0

This document is a system level Concept of Operations (CONOPS) from the perspective of future High Altitude Long Endurance (HALE) Unmanned Aircraft Systems (UAS) service providers and National Airspace System (NAS) users. It describes current systems (existing UAS), describes HALE UAS functions and operations to be performed (via sample missions), and offers insight into the user s environment (i.e., the UAS as a system of systems). It is intended to be a source document for NAS UAS operational requirements, and provides a construct for government agencies to use in guiding their regulatory decisions, architecture requirements, and investment strategies. Although it does not describe the technical capabilities of a specific HALE UAS system (which do, and will vary widely), it is intended to aid in requirements capture and to be used as input to the functional requirements and analysis process. The document provides a basis for development of functional requirements and operational guidelines to achieve unrestricted access into the NAS. This document is an FY06 update to the FY05 Access 5 Project-approved Concept of Operations document previously published in the Public Domain on the Access 5 open website. This version is recommended to be approved for public release also. The updates are a reorganization of materials from the previous version with the addition of an updated set of operational requirements, inclusion of sample mission scenarios, and identification of roles and responsibilities of interfaces within flight phases.

Source record↗
NASA NTRS2006

Functional Requirements Document for HALE UAS Operations in the NAS: Step 1. Version 3

The purpose of this Functional Requirements Document (FRD) is to compile the functional requirements needed to achieve the Access 5 Vision of "operating High Altitude, Long Endurance (HALE) Unmanned Aircraft Systems (UAS) routinely, safely, and reliably in the national airspace system (NAS)" for Step 1. These functional requirements could support the development of a minimum set of policies, procedures and standards by the Federal Aviation Administration (FAA) and various standards organizations. It is envisioned that this comprehensive body of work will enable the FAA to establish and approve regulations to govern safe operation of UAS in the NAS on a routine or daily "file and fly" basis. The approach used to derive the functional requirements found within this FRD was to decompose the operational requirements and objectives identified within the Access 5 Concept of Operations (CONOPS) into the functions needed to routinely and safely operate a HALE UAS in the NAS. As a result, four major functional areas evolved to enable routine and safe UAS operations for an on-demand basis in the NAS. These four major functions are: Aviate, Navigate, Communicate, and Avoid Hazards. All of the functional requirements within this document can be directly traceable to one of these four major functions. Some functions, however, are traceable to several, or even all, of these four major functions. These cross-cutting functional requirements support the "Command / Control: function as well as the "Manage Contingencies" function. The requirements associated to these high-level functions and all of their supporting low-level functions are addressed in subsequent sections of this document.

Source record↗
NASA NTRS2008

Design and Verification

As future space missions become longer, an important aspect to consider is the habitability of the spacecraft. The amount of habitable volume affects not only astronaut comfort, but safety and mission success as well. However, as the volume is increased to aid in task performance, the weight of the vehicle and cost of the mission escalates in proportion. Pressure to reduce mission cost is constant, but the risk to mission success and crew survival must remain the priorities. The Constellation Program's Altair Lunar Lander is designed for short duration surface operation missions of seven to ten days. For short duration missions, humans will tolerate fairly primitive environmental situations provided the basic physiological arrangements are acceptable. However, for long-duration lunar surface operations, the living and operational spaces within which the crew work must provide both the essentials of life, as well as the support necessary for the crew to be productive in accomplishing their mission. The Altair is still in the preliminary design phase, which is the optimal time for Human Factors data to be provided to designers and engineers. A Human Centered Design (HCD) approach is being taken with our Human Factors evaluations. Human-in-the-loop testing is conducted using low-medium fidelity mock-ups of proposed lunar architecture. Based on current ConOps (Concept of Operations) procedures, a task analysis is performed in which individual tasks are combined into larger operational scenarios. Subjective and objective performance measures are gathered at both the task and scenario level. These scores are used to determine the functionality of the vehicle in terms of task performance. Results from these evaluations will highlight areas for design or operational improvement.

Thompson, Shelby G.↗
NASA NTRS2009

Constellation Architecture Team-Lunar Scenario 12.0 Habitation Overview

This paper will describe an overview of the Constellation Architecture Team Lunar Scenario 12.0 surface habitation approach, concept, and assessments performed during the study definition. The Lunar Scenario 12 architecture study focused on two primary habitation approaches: a horizontally-oriented habitation module (LS-12.0) and a vertically-oriented habitation module (LS-12.1). This paper will provide an overview of 12.0 lunar surface campaign, the associated outpost architecture, habitation functionality, concept description, system integration strategy, mass and power resource estimates. The Scenario 12 architecture resulted from combining three previous scenarios after the Lunar Surface Systems (LSS) Project Office meeting in April 28-30, 2009. The best attributes from Scenario 4 "Optimized Exploration", Scenario 5 "Fission Surface Power System" and Scenario 8 "Initial Extensive Mobility" were combined into Scenario 12 along with an added emphasis on defining the excursion ConOps while the crew is away from the outpost location.

Kennedy, Kriss J.↗
NASA NTRS2010

Constellation Architecture Team-Lunar Scenario 12.0 Habitation Overview

This paper will describe an overview of the Constellation Architecture Team Lunar Scenario 12.0 (LS-12) surface habitation approach and concept performed during the study definition. The Lunar Scenario 12 architecture study focused on two primary habitation approaches: a horizontally-oriented habitation module (LS-12.0) and a vertically-oriented habitation module (LS-12.1). This paper will provide an overview of the 12.0 lunar surface campaign, the associated outpost architecture, habitation functionality, concept description, system integration strategy, mass and power resource estimates. The Scenario 12 architecture resulted from combining three previous scenario attributes from Scenario 4 "Optimized Exploration", Scenario 5 "Fission Surface Power System" and Scenario 8 "Initial Extensive Mobility" into Scenario 12 along with an added emphasis on defining the excursion ConOps while the crew is away from the outpost location. This paper will describe an overview of the CxAT-Lunar Scenario 12.0 habitation concepts and their functionality. The Crew Operations area includes basic crew accommodations such as sleeping, eating, hygiene and stowage. The EVA Operations area includes additional EVA capability beyond the suitlock function such as suit maintenance, spares stowage, and suit stowage. The Logistics Operations area includes the enhanced accommodations for 180 days such as enhanced life support systems hardware, consumable stowage, spares stowage, interconnection to the other habitation elements, a common interface mechanism for future growth, and mating to a pressurized rover or Pressurized Logistics Module (PLM). The Mission & Science Operations area includes enhanced outpost autonomy such as an IVA glove box, life support, medical operations, and exercise equipment.

Kennedy, Kriss J.↗
NASA NTRS2010

Communication

NASA s communication work for the UAS Command and Control area will build upon work currently being conducted under NASA Recovery Act funds. Communication portions of UAS NextGen ConOps, Stateof- the-Art assessment, and Gap Analysis. Preliminary simulations for UAS CNPC link scalability assessment. Surrogate UAS aircraft upgrades. This work will also leverage FY10 in-guide funding for communication link model development. UAS are currently managed through exceptions and are operating using DoD frequencies for line-of-sight (LOS) and satellite-based communications links, low-power LOS links in amateur bands, or unlicensed Instrument/Scientific/Medical (ISM) frequencies. None of these frequency bands are designated for Safety and Regularity of Flight. No radio-frequency (RF) spectrum has been allocated by the International Telecommunications Union (ITU) specifically for UAS command and control links, for either LOS or Beyond LOS (BLOS) communication.

Griner, James↗
NASA NTRS2010

UAS Integration into the NAS Project

The goal of the UAS Integration in the NAS Project is to contribute capabilities that reduce technical barriers related to the safety and operational challenges associated with enabling routine UAS access to the NAS This goal will be accomplished through a two-phased approach of system-level integration of key concepts, technologies and/or procedures, and demonstrations of integrated capabilities in an operationally relevant environment. Technical objectives include: PHASE 1: a) Validating the key technical areas identified by this project. System-level analyses, a State of the Art Analysis (SOAA), and a ConOps will identify the challenges and barriers preventing routine UAS access to the NAS. b) Developing a national roadmap and gap analysis identifying specific deliverables in the area of operations, procedures, and technologies that will impact future policy decisions. PHASE 2: a) Provide regulators with a methodology for developing airworthiness requirements for UAS and data to support development of certifications standards and regulatory guidance. b) Provide systems-level integrated testing of concepts and/or capabilities that address barriers to routine access to the NAS. Through simulation and flight testing, address issues including separation assurance, communications requirements, and Pilot Aircraft Interfaces (PAIs) in operationally relevant environments

Bauer, Jeff↗
NASA NTRS2011

Deep Space Habitat Team: HEFT Phase 2 Effects

HEFT was a NASA-wide team that performed analyses of architectures for human exploration beyond LEO, evaluating technical, programmatic, and budgetary issues to support decisions at the highest level of the agency in HSF planning. HEFT Phase I (April - September, 2010) and Phase II (September - December, 2010) examined a broad set of Human Exploration of Near Earth Objects (NEOs) Design Reference Missions (DRMs), evaluating such factors as elements, performance, technologies, schedule, and cost. At end of HEFT Phase 1, an architecture concept known as DRM 4a represented the best available option for a full capability NEO mission. Within DRM4a, the habitation system was provided by Deep Space Habitat (DSH), Multi-Mission Space Exploration Vehicle (MMSEV), and Crew Transfer Vehicle (CTV) pressurized elements. HEFT Phase 2 extended DRM4a, resulting in DRM4b. Scrubbed element-level functionality assumptions and mission Concepts of Operations. Habitation Team developed more detailed concepts of the DSH and the DSH/MMSEV/CTV Conops, including functionality and accommodations, mass & volume estimates, technology requirements, and DDT&E costs. DRM 5 represented an effort to reduce cost by scaling back on technologies and eliminating the need for the development of an MMSEV.

Toups, Larry D.↗
NASA NTRS2010

Preliminary Investigation of Civil Tiltrotor in NextGen Airspace

Presentation intro: Tiltrotor aircraft have long been envisioned as being a potentially viable means of commercial aviation transport. Preliminary results from an ongoing study into the operational and technological considerations of Civil Tiltrotor (CTR) operation in the Next Generation airspace, circa the 2025 time-frame, are presented and discussed. In particular, a fleet of CTR aircraft has been conceptually designed. The performance characteristics of this CTR fleet was subsequently translated into BADA (Base of Aircraft DAta) models that could be used as input to emulate CTR aircraft operations in the ACES and AvTerminal airspace and terminal area simulation tools. A network of nine North-Eastern corridor airports is the focus of the airspace simulation effort; the results from this airport network viII then be extrapolated to provide insights into systemic impact of CTRs on the National Airspace System (NAS). Future work will also be detailed as to attempts to model the systemic effects of noise and emissions from this fleet of new aircraft as well as assess their leveraged impact on public service missions, in time of need, such as major regional/national disaster relief efforts. The ideal outcome of this study is a set of results whereby Next Gen airspace CONOPs can be refined to reflect potential CTR capabilities and, conversely, CTR technology development efforts can be better informed as to key performance requirement thresholds needed to be met in order to successfully introduce these aircraft into civilian aviation operation.

Young, Larry A.↗
NASA NTRS2011

Vehicle Integrated Prognostic Reasoner (VIPR) 2010 Annual Final Report

Honeywell's Central Maintenance Computer Function (CMCF) and Aircraft Condition Monitoring Function (ACMF) represent the state-of-the art in integrated vehicle health management (IVHM). Underlying these technologies is a fault propagation modeling system that provides nose-to-tail coverage and root cause diagnostics. The Vehicle Integrated Prognostic Reasoner (VIPR) extends this technology to interpret evidence generated by advanced diagnostic and prognostic monitors provided by component suppliers to detect, isolate, and predict adverse events that affect flight safety. This report describes year one work that included defining the architecture and communication protocols and establishing the user requirements for such a system. Based on these and a set of ConOps scenarios, we designed and implemented a demonstration of communication pathways and associated three-tiered health management architecture. A series of scripted scenarios showed how VIPR would detect adverse events before they escalate as safety incidents through a combination of advanced reasoning and additional aircraft data collected from an aircraft condition monitoring system. Demonstrating VIPR capability for cases recorded in the ASIAS database and cross linking them with historical aircraft data is planned for year two.

Hadden, George D.↗
NASA NTRS2012

An Assessment of Civil Tiltrotor Concept of Operations in the Next Generation Air Transportation System

Based on a previous Civil Tiltrotor (CTR) National Airspace System (NAS) performance analysis study, CTR operations were evaluated over selected routes and terminal airspace configurations assuming noninterference operations (NIO) and runway-independent operations (RIO). This assessment aims to further identify issues associated with these concepts of operations (ConOps), and their dependency on the airspace configuration and interaction with conventional fixed-wing traffic. Safety analysis following a traditional Safety Management System (SMS) methodology was applied to CTR-unique departure and arrival failures in the selected airspace to identify any operational and certification issues. Additional CTR operational cases were then developed to get a broader understanding of issues and gaps that will need to be addressed in future CTR operational studies. Finally, needed enhancements to National Airspace System performance analysis tools were reviewed, and recommendations were made on improvements in these tools that are likely to be required to support future progress toward CTR fleet operations in the Next Generation Air Transportation System (NextGen).

Chung, William W.↗
NASA NTRS2012

NASA's ATM Technology Demonstration-1: Integrated Concept of Arrival Operations

This paper describes operations and procedures envisioned for NASA s Air Traffic Management (ATM) Technology Demonstration #1 (ATD-1). The ATD-1 Concept of Operations (ConOps) demonstration will integrate three NASA technologies to achieve high throughput, fuel-efficient arrival operations into busy terminal airspace. They are Traffic Management Advisor with Terminal Metering (TMA-TM) for precise time-based schedules to the runway and points within the terminal area, Controller-Managed Spacing (CMS) decision support tools for terminal controllers to better manage aircraft delay using speed control, and Flight deck Interval Management (FIM) avionics and flight crew procedures to conduct airborne spacing operations. The ATD-1 concept provides de-conflicted and efficient operations of multiple arrival streams of aircraft, passing through multiple merge points, from top-of-descent (TOD) to touchdown. It also enables aircraft to conduct Optimized Profile Descents (OPDs) from en route altitude to the runway, using primarily speed control to maintain separation and schedule. The ATD-1 project is currently addressing the challenges of integrating the three technologies, and implantation into an operational environment. Goals of the ATD-1 demonstration include increasing the throughput of high-density airports, reducing controller workload, increasing efficiency of arrival operations and the frequency of trajectory-based operations, and promoting aircraft ADS-B equipage.

Baxley, Brian T.↗
NASA NTRS2012

CloudSat Anomaly Recovery and Operational Lessons Learned

Nov 2011: NASA/JPL declared CloudSat fully operational in DO ]OP Mode . CloudSat collects science data during sunlit portion of orbit, stable spin hibernation in eclipse . New CONOPS requires constant monitoring of thermal and power profiles, while allowing collection of 54 mins of science data per sunlit orbit

spacecraft systems↗
NASA NTRS2014

Pair-Wise Trajectory Management-Oceanic (PTM-O)

This document describes the Pair-wise Trajectory Management-Oceanic (PTM-O) Concept of Operations (ConOps). Pair-wise Trajectory Management (PTM) is a concept that includes airborne and ground-based capabilities designed to enable and to benefit from, airborne pair-wise distance-monitoring capability. PTM includes the capabilities needed for the controller to issue a PTM clearance that resolves a conflict for a specific pair of aircraft. PTM avionics include the capabilities needed for the flight crew to manage their trajectory relative to specific designated aircraft. Pair-wise Trajectory Management PTM-Oceanic (PTM-O) is a regional specific application of the PTM concept. PTM is sponsored by the National Aeronautics and Space Administration (NASA) Concept and Technology Development Project (part of NASA's Airspace Systems Program). The goal of PTM is to use enhanced and distributed communications and surveillance along with airborne tools to permit reduced separation standards for given aircraft pairs, thereby increasing the capacity and efficiency of aircraft operations at a given altitude or volume of airspace.

Jones, Kenneth M.↗
NASA NTRS2014

Design, Integration, Certification and Testing of the Orion Crew Module Propulsion System

The Orion Multipurpose Crew Vehicle (MPCV) is NASA's next generation spacecraft for human exploration of deep space. Lockheed Martin is the prime contractor for the design, development, qualification and integration of the vehicle. A key component of the Orion Crew Module (CM) is the Propulsion Reaction Control System, a high‐flow hydrazine system used during re‐entry to orient the vehicle for landing. The system consists of a completely redundant helium (GHe) pressurization system and hydrazine fuel system with monopropellant thrusters. The propulsion system has been designed, integrated, and qualification tested in support of the Orion program's first orbital flight test, Exploration Flight Test One (EFT‐1), scheduled for 2014. A subset of the development challenges and lessons learned from this first flight test campaign will be discussed in this paper for consideration when designing future spacecraft propulsion systems. The CONOPS and human rating requirements of the CM propulsion system are unique when compared with a typical satellite propulsion reaction control system. The system requires a high maximum fuel flow rate. It must operate at both vacuum and sea level atmospheric pressure conditions. In order to meet Orion's human rating requirements, multiple parts of the system must be redundant, and capable of functioning after spacecraft system fault events.

McKay, Heather↗
NASA NTRS2013

Development of the Orion Crew-Service Module Umbilical Retention and Release Mechanism

The Orion CSM umbilical retention and release mechanism supports and protects all of the cross-module commodities between the spacecrafts crew and service modules. These commodities include explosive transfer lines, wiring for power and data, and flexible hoses for ground purge and life support systems. The mechanism employs a single separation interface which is retained with pyrotechnically actuated separation bolts and supports roughly two dozen electrical and fluid connectors. When module separation is commanded, either for nominal on-orbit CONOPS or in the event of an abort, the mechanism must release the separation interface and sever all commodity connections within milliseconds of command receipt. There are a number of unique and novel aspects of the design solution developed by the Orion mechanisms team. The design is highly modular and can easily be adapted to other vehiclesmodules and alternate commodity sets. It will be flight tested during Orions Exploration Flight Test 1 (EFT-1) in 2014, and the Orion team anticipates reuse of the design for all future missions. The design packages fluid, electrical, and ordnance disconnects in a single separation interface. It supports abort separations even in cases where aerodynamic loading prevents the deployment of the umbilical arm. Unlike the Apollo CSM umbilical which was a destructive separation device, the Orion design is resettable and flight units can be tested for separation performance prior to flight.Initial development testing of the mechanisms separation interface resulted in binding failures due to connector misalignments. The separation interface was redesigned with a robust linear guide system, and the connector separation and boom deployment were separated into two discretely sequenced events. These changes addressed the root cause of the binding failure by providing better control of connector alignment. The new design was tuned and validated analytically via Monte Carlo simulation. The analytical validation was followed by a repeat of the initial test suite plus test cases at thermal extremes and test cases with imposed mechanical failures demonstrating fault tolerance. The mechanism was then exposed to the qualification vibration environment. Finally, separation testing was performed at full speed with live ordnance.All tests of the redesigned mechanism resulted in successful separation of the umbilical interface with adequate force margins and timing. The test data showed good agreement with the predictions of the Monte Carlo simulation. The simulation proved invaluable due to the number of variables affecting the separation and the uncertainty associated with each. The simulation allowed for rapid assessment of numerous trades and contingency scenarios, and can be easily reconfigured for varying commodity sets and connector layouts.

Separation↗
NASA NTRS2014

Phased Array-Fed Reflector (PAFR) Antenna Architectures for Space-Based Sensors

Communication link and target ranges for satellite communications (SATCOM) and space-based sensors (e.g. radars) vary from approximately 1000 km (for LEO satellites) to 35,800 km (for GEO satellites). At these long ranges, large antenna gains are required and legacy payloads have usually employed large reflectors with single beams that are either fixed or mechanically steered. For many applications, there are inherent limitations that are associated with the use of these legacy antennas/payloads. Hybrid antenna designs using Phased Array Fed Reflectors (PAFRs) provide a compromise between reflectors and Direct Radiating phased Arrays (DRAs). PAFRs provide many of the performance benefits of DRAs while utilizing much smaller, lower cost (feed) arrays. The primary limitation associated with hybrid PAFR architectures is electronic scan range; approximately +/-5 to +/- 10 degrees is typical, but this range depends on many factors. For LEO applications, the earth FOV is approximately +/-55 degrees which is well beyond the range of electronic scanning for PAFRs. However, for some LEO missions, limited scanning is sufficient or the CONOPS and space vehicle designs can be developed to incorporate a combination mechanical slewing and electronic scanning. In this paper, we review, compare and contrast various PAFR architectures with a focus on their general applicability to space missions. We compare the RF performance of various PAFR architectures and describe key hardware design and implementation trades. Space-based PAFR designs are highly multi-disciplinary and we briefly address key hardware engineering design areas. Finally, we briefly describe two PAFR antenna architectures that have been developed at Northrop Grumman.

antenna↗
NASA NTRS2016

Human Flight to Lunar and Beyond - Re-Learning Operations Paradigms

For the first time since the Apollo era, NASA is planning on sending astronauts on flights beyond Low-Earth Orbit (LEO). The Human Space Flight (HSF) program started with a successful initial flight in Earth orbit, in December 2014. The program will continue with two Exploration Missions (EM) to Lunar orbit: EM-1 will be unmanned and EM-2, carrying astronauts, will follow. NASA established a multi-center team to address the communications, and related navigation, needs. This paper will focus on the lessons learned in the team, planning for the missions' parts that are beyond Earth orbit. Many of these lessons had to be re-learned, as the HSF program after operated for many years in Earth orbit. Fortunately, the experience base from tracking robotic missions in deep space by the Deep Space Network (DSN) and close interaction with the HSF community to understand the unique needs (e.g. 2-way voice) resulted in a ConOps that leverages of both the deep space robotic and the Human LEO experiences. Several examples will be used to highlight the unique operational needs for HSF missions beyond Earth Orbit, including: - Navigation. At LEO, HSF missions can rely on Global Positioning System (GPS) devices for orbit determination. For Lunar-and-beyond HSF missions, techniques such as precision 2-way and 3-way Doppler and ranging, Delta-Difference-of-range, and eventually on-board navigation will be used. - Impact of latency - the delay associated with Round-Trip-Light-Time (RTLT). Imagine trying to have a 2-way discussion (audio or video) with an astronaut, with a 2-3 sec delay inserted (for Lunar distances) or 20 minutes delay (for Mars distances). - Balanced communications link. For robotic missions, there has been a heavy emphasis on the downlink data rates, bringing back science data from the instruments on-board the spacecraft. Uplink data rates were of secondary importance, used to send commands to the spacecraft. The ratio of downlink-to-uplink data rates was often 10:1 or more. For HSF, rates for uplink and downlink, at least for high-quality video, need to be similar.

Kenny, Ted↗