SEARCH · Engineering Papers

Results for “engineering software”

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.

SourceResearch connectionFrom yearThrough year

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

At least 1,639 records · Page 91

All sources NASA NTRS DOE OSTI

NASA NTRS2022

Actuator and Motor Control End-to-End V&V on the Mars 2020 Rover

The Mars 2020 Perseverance rover is the most advanced robotic exploration system ever sent to another planet. To support the complex scientific and mobility needs of the mission, the rover utilizes 33 actuators, three multi-degree-of-freedom force-torque sensors, fifteen single or dual-speed resolvers, two solenoid valves, and twelve contact switches. The control for these actuators and sensors is achieved by several levels of flight software, coordinated between two computers with varying bandwidth control loops. Furthermore, the actuators and sensors were integrated into multiple larger robotic mechanisms that were delivered by different organizations at various points in the Integration and Test (I&T) timeline. All of this created a very complex Verification and Validation (V&V) scenario involving multiple subsystems and teams, several hardware and software testbeds with varying levels of fidelity, and significant systems engineering to ensure the overall I&T schedule could be maintained while ensuring system hardware safety.This paper details the integrated V&V effort across multiple teams and venues to provide full coverage of all necessary functionality, performance, and fault protection. First, it provides an overview of how the V&V campaign was subdivided among teams and venues and provides descriptions of the various hardware configurations used to support the testing. The Mars 2020 implementation of the plan incorporates many of the lessons learned from Mars Science Laboratory’s test campaign, and these value-added modifications are discussed here. Also included in this section is the system-level environmental testing approach used for mechanisms. Second, the paper describes the phased approach used by the teams to support new hardware and software deliveries to testbed and Systems I&T. In this approach the test campaign was built upon higher-level mechanism needs for performance, functionality, and safety at specific times in the campaign. Finally, the paper discusses lessons learned from the V&V campaign that should be applied to future large-scale motion control testing efforts.

Borne, Davis↗

NASA NTRS2014

Lessons Learned in the First Year Operating Software Defined Radios in Space

Operating three unique software defined radios (SDRs) in a space environment aboard the Space Communications and Navigation (SCaN) Testbed for over one year has provided an opportunity to gather knowledge useful for future missions considering using software defined radios. This paper provides recommendations for the development and use of SDRs, and it considers the details of each SDRs approach to software upgrades and operation. After one year, the SCaN Testbed SDRs have operated for over 1000 hours. During this time, the waveforms launched with the SDR were tested on-orbit to assure that they operated in space at the same performance level as on the ground prior to launch to obtain an initial on-orbit performance baseline. A new waveform for each SDR has been developed, implemented, uploaded to the flight system, and tested in the flight environment. Recommendations for SDR-based missions have been gathered from early development through operations. These recommendations will aid future missions to reduce the cost, schedule, and risk of operating SDRs in a space environment. This paper considers the lessons learned as they apply to SDR pre-launch checkout, purchasing space-rated hardware, flexibility in command and telemetry methods, on-orbit diagnostics, use of engineering models to aid future development, and third-party software. Each SDR implements the SCaN Testbed flight computer command and telemetry interface uniquely, allowing comparisons to be drawn. The paper discusses the lessons learned from these three unique implementations, with suggestions on the preferred approach. Also, results are presented showing that it is important to have full system performance knowledge prior to launch to establish better performance baselines in space, requiring additional test applications to be developed pre-launch. Finally, the paper presents the issues encountered with the operation and implementation of new waveforms on each SDR and proposes recommendations to avoid these issues.

radio equipment↗

NASA NTRS2014

Lessons Learned in the First Year Operating Software Defined Radios in Space

Operating three unique software defined radios (SDRs) in a space environment aboard the Space Communications and Navigation (SCaN) Testbed for over one year has provided an opportunity to gather knowledge useful for future missions considering using software defined radios. This paper provides recommendations for the development and use of SDRs, and it considers the details of each SDR's approach to software upgrades and operation. After one year, the SCaN Testbed SDRs have operated for over 1000 hours. During this time, the waveforms launched with the SDR were tested on-orbit to assure that they operated in space at the same performance level as on the ground prior to launch to obtain an initial on-orbit performance baseline. A new waveform for each SDR has been developed, implemented, uploaded to the flight system, and tested in the flight environment. Recommendations for SDR-based missions have been gathered from early development through operations. These recommendations will aid future missions to reduce the cost, schedule, and risk of operating SDRs in a space environment. This paper considers the lessons learned as they apply to SDR pre-launch checkout, purchasing space-rated hardware, flexibility in command and telemetry methods, on-orbit diagnostics, use of engineering models to aid future development, and third-party software. Each SDR implements the SCaN Testbed flight computer command and telemetry interface uniquely, allowing comparisons to be drawn. The paper discusses the lessons learned from these three unique implementations, with suggestions on the preferred approach. Also, results are presented showing that it is important to have full system performance knowledge prior to launch to establish better performance baselines in space, requiring additional test applications to be developed pre-launch. Finally, the paper presents the issues encountered with the operation and implementation of new waveforms on each SDR and proposes recommendations to avoid these issues.

space communication↗

NASA NTRS1985

Flow dynamic environment data base development for the SSME

The fluid flow-induced vibration of the Space Shuttle main engine (SSME) components are being studied with a view to correlating the frequency characteristics of the pressure fluctuations in a rocket engine to its operating conditions and geometry. An overview of the data base development for SSME test firing results and the interactive computer software used to access, retrieve, and plot or print the results selectively for given thrust levels, engine numbers, etc., is presented. The various statistical methods available in the computer code for data analysis are discussed. Plots of test data, nondimensionalized using parameters such as fluid flow velocities, densities, and pressures, are presented. Results are compared with those available in the literature. Correlations between the resonant peaks observed at higher frequencies in power spectral density plots with pump geometry and operating conditions are discussed. An overview of the status of the investigation is presented and future directions are discussed.

Sundaram, C. V.↗

NASA NTRS1988

Aircraft integrated design and analysis: A classroom experience

AAE 451 is the capstone course required of all senior undergraduates in the School of Aeronautics and Astronautics at Purdue University. During the past year the first steps of a long evolutionary process were taken to change the content and expectations of this course. These changes are the result of the availability of advanced computational capabilities and sophisticated electronic media availability at Purdue. This presentation will describe both the long range objectives and this year's experience using the High Speed Commercial Transport (HSCT) design, the AIAA Long Duration Aircraft design and a Remotely Piloted Vehicle (RPV) design proposal as project objectives. The central goal of these efforts was to provide a user-friendly, computer-software-based, environment to supplement traditional design course methodology. The Purdue University Computer Center (PUCC), the Engineering Computer Network (ECN), and stand-alone PC's were used for this development. This year's accomplishments centered primarily on aerodynamics software obtained from the NASA Langley Research Center and its integration into the classroom. Word processor capability for oral and written work and computer graphics were also blended into the course. A total of 10 HSCT designs were generated, ranging from twin-fuselage and forward-swept wing aircraft, to the more traditional delta and double-delta wing aircraft. Four Long Duration Aircraft designs were submitted, together with one RPV design tailored for photographic surveillance. Supporting these activities were three video satellite lectures beamed from NASA/Langley to Purdue. These lectures covered diverse areas such as an overview of HSCT design, supersonic-aircraft stability and control, and optimization of aircraft performance. Plans for next year's effort will be reviewed, including dedicated computer workstation utilization, remote satellite lectures, and university/industrial cooperative efforts.

Source record↗

NASA NTRS2020

Is Structured Agile an Oxymoron? Tales from Implementing and Executing Agile in a US Government Environment

To paraphrase a famous quote, "No plan survives contact with the reality." Software (SW) development is often a classic example of this: whatever the plan was for a particular development, it often does not survive contact with technical realities, budget realities, program realities and schedule realities. Traditionally, SW development has followed a waterfall methodology with requirements being rigorously specified before the design, which was completed before the coding and unit testing started, which were in turn finished before validation and verification started. This model of SW engineering derives much from the HW engineering of large systems, and has been the standard methodology used in US government software acquisitions and systems for decades, with highly variable results. US Government SW requirements are built around Waterfall concepts, which assume that the plan will survive contact with reality, or at least that modifications to the plan are relatively small, and relatively few.Because of the inefficiencies and difficulties inherent in Waterfall, the commercial SW world started using a different SW development methodology called Agile more than 20 years ago. Agile believes that a plan should evolve and learn rapidly in response to the realities encountered. At its core, there are a few key elements of Agile:- A small team of people which is highly flexible and adaptive. The team collaborates and interoperates through sophisticated development architectures and release environments- An iterative, incremental development and release approach which is based upon the concept that knowledge comes from experience within the team, and that the team makes decisions based upon what it knows- A team culture which prizes transparency, inspection and adaptation. These values are necessary so that the team experience and decision making is transparent and responsive to the realities encountered during development and testingSo, how to use Agile in a US Government environment? GMSEC (Goddard Mission Services Evolution Center) develops satellite ground system software for NASA and other US Government agencies. The SW developed by the team contains a large code base of many applications used within satellite mission operations centers. It spans the full gamut of SW development types: from SW which is in a classic maintenance and sustainment mode, to new developments with a fairly well understood scope and approach, to new developments whose scope and approach are quite unclear and which require significant research and prototyping. Team members move between all of these different types of SW development. Waterfall was inadequate to the programmatic and technical needs of the team, as well as the various types of SW development being done. The software plan was not surviving contact with the technical and programmatic realities experienced by the team. To address this, the team started a small pilot project in 2016 to test the use of Agile within a small subset of the team for a new web services application. In early 2018, the use of Agile was expanded to the whole team and all the software, but we had to fulfill the NASA SW development requirements. And we needed to do this while still remaining true to the key Agile elements of transparency, inspection and adaption. In order to do this, the team worked very closely with the Software Process Improvement (SPI) team at NASA Goddard, as well as NASA engineering manageme

Beech, Theresa W.↗

NASA NTRS2013

Swamp Works- Multiple Projects

My Surface Systems internship over the summer 2013 session covered a broad range of projects that ranged multiple aspects and fields of engineering and technology. This internship included a project to create a command center for a 120 ton regolith bin, a design and build for a blast shield to add further protection for the Surface Systems engineers, a design for a portable four monitor hyper wall that can extend as large as needed, research and programming a nano drill for a next generation robot, and social media tasks including the making of videos, posting to social networking websites and implementation of a new weekly outreach program to help spread the word about the Swamp Works laboratory. The objectives for the command center were to create a central computer controlled area for the still in production lunar regolith bin. It needed to be easy to use and the operating systems had to be Linux. The objectives for the hyper wall were to build a mobile transport of monitors that could potentially attach to one another. It needed to be light but sturdy, and have the ability to last. The objectives for the blast shield included a robust design that could withstand a small equipment malfunction, while also being convenient for use. The objectives for the nano-drill included the research and implementation of programming for vertical and horizontal movement. The hyper wall and blasts shield project were designed by me in the Pro/Engineer/Creo2 software. Each project required a meeting with the Swamp Works engineers and was declared successful.

Carelli, Jonathan M.↗

NASA NTRS1994

Customizing the JPL Multimission Ground Data System: Lessons learned

The Multimission Ground Data System (MGDS) at NASA's Jet Propulsion Laboratory has brought improvements and new technologies to mission operations. It was designed as a generic data system to meet the needs of multiple missions and avoid re-inventing capabilities for each new mission and thus reduce costs. It is based on adaptable tools that can be customized to support different missions and operations scenarios. The MGDS is based on a distributed client/server architecture, with powerful Unix workstations, incorporating standards and open system architectures. The distributed architecture allows remote operations and user science data exchange, while also providing capabilities for centralized ground system monitor and control. The MGDS has proved its capabilities in supporting multiple large-class missions simultaneously, including the Voyager, Galileo, Magellan, Ulysses, and Mars Observer missions. The Operations Engineering Lab (OEL) at JPL has been leading Customer Adaptation Training (CAT) teams for adapting and customizing MGDS for the various operations and engineering teams. These CAT teams have typically consisted of only a few engineers who are familiar with operations and with the MGDS software and architecture. Our experience has provided a unique opportunity to work directly with the spacecraft and instrument operations teams and understand their requirements and how the MGDS can be adapted and customized to minimize their operations costs. As part of this work, we have developed workstation configurations, automation tools, and integrated user interfaces at minimal cost that have significantly improved productivity. We have also proved that these customized data systems are most successful if they are focused on the people and the tasks they perform and if they are based upon user confidence in the development team resulting from daily interactions. This paper will describe lessons learned in adapting JPL's MGDS to fly the Voyager, Galileo, and Mars Observer missions. We will explain how powerful, existing ground data systems can be adapted and packaged in a cost effective way for operations of small and large planetary missions. We will also describe how the MGDS was adapted to support operations within the Galileo Spacecraft Testbed. The Galileo testbed provided a unique opportunity to adapt MGDS to support command and control operations for a small autonomous operations team of a handful of engineers flying the Galileo Spacecraft flight system model.

Murphy, Susan C.↗

NASA NTRS1984

Flight testing the digital electronic engine control in the F-15 airplane

The digital electronic engine control (DEEC) is a full-authority digital engine control developed for the F100-PW-100 turbofan engine which was flight tested on an F-15 aircraft. The DEEC hardware and software throughout the F-15 flight envelope was evaluated. Real-time data reduction and data display systems were implemented. New test techniques and stronger coordination between the propulsion test engineer and pilot were developed which produced efficient use of test time, reduced pilot work load, and greatly improved quality data. The engine pressure ratio (EPR) control mode is demonstrated. It is found that the nonaugmented throttle transients and engine performance are satisfactory.

Myers, L. P.↗

NASA NTRS1973

Apollo experience report: Guidance and control systems. Engineering simulation program

The Apollo Program experience from early 1962 to July 1969 with respect to the engineering-simulation support and the problems encountered is summarized in this report. Engineering simulation in support of the Apollo guidance and control system is discussed in terms of design analysis and verification, certification of hardware in closed-loop operation, verification of hardware/software compatibility, and verification of both software and procedures for each mission. The magnitude, time, and cost of the engineering simulations are described with respect to hardware availability, NASA and contractor facilities (for verification of the command module, the lunar module, and the primary guidance, navigation, and control system), and scheduling and planning considerations. Recommendations are made regarding implementation of similar, large-scale simulations for future programs.

Gilbert, D. W.↗

NASA NTRS1989

Aircraft integrated design and analysis: A classroom experience

AAE 451 is the capstone course required of all senior undergraduates in the School of Aeronautics and Astronautics at Purdue University. During the past year the first steps of a long evolutionary process were taken to change the content and expectations of this course. These changes are the result of the availability of advanced computational capabilities and sophisticated electronic media availability at Purdue. This presentation will describe both the long range objectives and this year's experience using the High Speed Commercial Transport design, the AIAA Long Duration Aircraft design and RPV design proposal as project objectives. The central goal of these efforts is to provide a user-friendly, computer-software-based environment to supplement traditional design course methodology. The Purdue University Computer Center (PUCC), the Engineering Computer Network (ECN) and stand-alone PC's are being used for this development. This year's accomplishments center primarily on aerodynamics software obtained from NASA/Langley and its integration into the classroom. Word processor capability for oral and written work and computer graphics were also blended into the course. A total of ten HSCT designs were generated, ranging from twin-fuselage aircraft, forward swept wing aircraft to the more traditional delta and double-delta wing aircraft. Four Long Duration Aircraft designs were submitted, together with one RPV design tailored for photographic surveillance.

Weisshaar, Terrence A.↗

NASA NTRS2007

Integrated System Test Approaches for the NASA Ares I Crew Launch Vehicle

The Ares I Crew Launch Vehicle (CLV) is being developed by the U.S. National Aeronautics and Space Administration (NASA) to provide crew access to the International Space Station (ISS) and, together with the Ares V Cargo Launch Vehicle (CaLV), serves as one component of a future launch capability for human exploration of the Moon. During the system requirements definition process and early design cycles, NASA defined and began implementing plans for integrated ground and flight testing necessary to achieve the first human launch of Ares I. The individual Ares I flight hardware elements: the first stage five segment booster (FSB), upper stage, and J-2X upper stage engine, will undergo extensive development, qualification, and certification testing prior to flight. Key integrated system tests include the Main Propulsion Test Article (MPTA), acceptance tests of the integrated upper stage and upper stage engine assembly, a full-scale integrated vehicle dynamic test (IVDT), aerodynamic testing to characterize vehicle performance, and integrated testing of the avionics and software components. The Ares I-X development flight test will provide flight data to validate engineering models for aerodynamic performance, stage separation, structural dynamic performance, and control system functionality. The Ares I-Y flight test will validate ascent performance of the first stage, stage separation functionality, and a highaltitude actuation of the launch abort system (LAS) following separation. The Orion-1 flight test will be conducted as a full, un-crewed, operational flight test through the entire ascent flight profile prior to the first crewed launch.

Cockrell, Charles E., Jr.↗

NASA NTRS2013

Session 6: Dynamic Modeling and Systems Analysis

These presentations cover some of the ongoing work in dynamic modeling and dynamic systems analysis. The first presentation discusses dynamic systems analysis and how to integrate dynamic performance information into the systems analysis. The ability to evaluate the dynamic performance of an engine design may allow tradeoffs between the dynamic performance and operability of a design resulting in a more efficient engine design. The second presentation discusses the Toolbox for Modeling and Analysis of Thermodynamic Systems (T-MATS). T-MATS is a Simulation system with a library containing the basic building blocks that can be used to create dynamic Thermodynamic Systems. Some of the key features include Turbo machinery components, such as turbines, compressors, etc., and basic control system blocks. T-MAT is written in the Matlab-Simulink environment and is open source software. The third presentation focuses on getting additional performance from the engine by allowing the limit regulators only to be active when a limit is danger of being violated. Typical aircraft engine control architecture is based on MINMAX scheme, which is designed to keep engine operating within prescribed mechanical/operational safety limits. Using a conditionally active min-max limit regulator scheme, additional performance can be gained by disabling non-relevant limit regulators

control↗

NASA NTRS1989

Interfacing modules for integrating discipline specific structural mechanics codes

An outline of the organization and capabilities of the Engine Structures Computational Simulator (Simulator) at NASA Lewis Research Center is given. One of the goals of the research at Lewis is to integrate various discipline specific structural mechanics codes into a software system which can be brought to bear effectively on a wide range of engineering problems. This system must possess the qualities of being effective and efficient while still remaining user friendly. The simulator was initially designed for the finite element simulation of gas jet engine components. Currently, the simulator has been restricted to only the analysis of high pressure turbine blades and the accompanying rotor assembly, although the current installation can be expanded for other applications. The simulator presently assists the user throughout its procedures by performing information management tasks, executing external support tasks, organizing analysis modules and executing these modules in the user defined order while maintaining processing continuity.

Endres, Ned M.↗

NASA NTRS1993

Develop advanced nonlinear signal analysis topographical mapping system

The SSME has been undergoing extensive flight certification and developmental testing, which involves some 250 health monitoring measurements. Under the severe temperature pressure, and dynamic environments sustained during operation, numerous major component failures have occurred, resulting in extensive engine hardware damage and scheduling losses. To enhance SSME safety and reliability, detailed analysis and evaluation of the measurements signal are mandatory to assess its dynamic characteristics and operational condition. Efficient and reliable signal detection techniques will reduce catastrophic system failure risks and expedite the evaluation of both flight and ground test data, and thereby reduce launch turn-around time. The basic objective of this contract are threefold: (1) Develop and validate a hierarchy of innovative signal analysis techniques for nonlinear and nonstationary time-frequency analysis. Performance evaluation will be carried out through detailed analysis of extensive SSME static firing and flight data. These techniques will be incorporated into a fully automated system. (2) Develop an advanced nonlinear signal analysis topographical mapping system (ATMS) to generate a Compressed SSME TOPO Data Base (CSTDB). This ATMS system will convert tremendous amounts of complex vibration signals from the entire SSME test history into a bank of succinct image-like patterns while retaining all respective phase information. A high compression ratio can be achieved to allow the minimal storage requirement, while providing fast signature retrieval, pattern comparison, and identification capabilities. (3) Integrate the nonlinear correlation techniques into the CSTDB data base with compatible TOPO input data format. Such integrated ATMS system will provide the large test archives necessary for a quick signature comparison. This study will provide timely assessment of SSME component operational status, identify probable causes of malfunction, and indicate feasible engineering solutions. The final result of this program will yield an ATMS system of nonlinear and nonstationary spectral analysis software package integrated with the Compressed SSME TOPO Data Base (CSTDB) on the same platform. This system will allow NASA engineers to retrieve any unique defect signatures and trends associated with different failure modes and anomalous phenomena over the entire SSME test history across turbo pump families.

Jong, Jen-Yi↗

NASA NTRS1994

Develop advanced nonlinear signal analysis topographical mapping system

The Space Shuttle Main Engine (SSME) has been undergoing extensive flight certification and developmental testing, which involves some 250 health monitoring measurements. Under the severe temperature, pressure, and dynamic environments sustained during operation, numerous major component failures have occurred, resulting in extensive engine hardware damage and scheduling losses. To enhance SSME safety and reliability, detailed analysis and evaluation of the measurements signal are mandatory to assess its dynamic characteristics and operational condition. Efficient and reliable signal detection techniques will reduce catastrophic system failure risks and expedite the evaluation of both flight and ground test data, and thereby reduce launch turn-around time. The basic objective of this contract are threefold: (1) develop and validate a hierarchy of innovative signal analysis techniques for nonlinear and nonstationary time-frequency analysis. Performance evaluation will be carried out through detailed analysis of extensive SSME static firing and flight data. These techniques will be incorporated into a fully automated system; (2) develop an advanced nonlinear signal analysis topographical mapping system (ATMS) to generate a Compressed SSME TOPO Data Base (CSTDB). This ATMS system will convert tremendous amount of complex vibration signals from the entire SSME test history into a bank of succinct image-like patterns while retaining all respective phase information. High compression ratio can be achieved to allow minimal storage requirement, while providing fast signature retrieval, pattern comparison, and identification capabilities; and (3) integrate the nonlinear correlation techniques into the CSTDB data base with compatible TOPO input data format. Such integrated ATMS system will provide the large test archives necessary for quick signature comparison. This study will provide timely assessment of SSME component operational status, identify probable causes of malfunction, and indicate feasible engineering solutions. The final result of this program will yield an ATMS system of nonlinear and nonstationary spectral analysis software package integrated with the Compressed SSME TOPO Data Base (CSTDB) on the same platform. This system will allow NASA engineers to retrieve any unique defect signatures and trends associated with different failure modes and anomalous phenomena over the entire SSME test history across turbo pump families.

Source record↗

NASA NTRS1986

Orbital flight simulation utility software unit specifications

The HP PASCAL source code contained in pages 6 through 104 was developed for the Mission Planning and Analysis Division (MPAD) and takes the place of detailed flow charts defining the specifications for a Utility Software Unit designed to support orbital flight simulators such as MANHANDLE and GREAS (General Research and Engineering Analysis Simulator). Besides providing basic input/output, mathematical, vector, matrix, quaternion, and statistical routines for such simulators, one of the primary functions of the Utility Software Unit is to isolate all system-dependent code in one well-defined compartment, thereby facilitating transportation of the simulations from one computer to another. Directives to the PASCAL compilers of the HP-9000 Series 200 PASCAL 3.0 operating system and the HP-9000 Series 500 HP-UX 5.0 operations systems are also provided.

Wilson, S. W.↗

NASA NTRS2008

Integrated Testing Approaches for the NASA Ares I Crew Launch Vehicle

The Ares I crew launch vehicle is being developed by the U.S. National Aeronautics and Space Administration (NASA) to provide crew and cargo access to the International Space Station (ISS) and, together with the Ares V cargo launch vehicle, serves as a critical component of NASA's future human exploration of the Moon. During the preliminary design phase, NASA defined and began implementing plans for integrated ground and flight testing necessary to achieve the first human launch of Ares I. The individual Ares I flight hardware elements - including the first stage five segment booster (FSB), upper stage, and J-2X upper stage engine - will undergo extensive development, qualification, and certification testing prior to flight. Key integrated system tests include the upper stage Main Propulsion Test Article (MPTA), acceptance tests of the integrated upper stage and upper stage engine assembly, a full-scale integrated vehicle ground vibration test (IVGVT), aerodynamic testing to characterize vehicle performance, and integrated testing of the avionics and software components. The Ares I-X development flight test will provide flight data to validate engineering models for aerodynamic performance, stage separation, structural dynamic performance, and control system functionality. The Ares I-Y flight test will validate ascent performance of the first stage, stage separation functionality, validate the ability of the upper stage to manage cryogenic propellants to achieve upper stage engine start conditions, and a high-altitude demonstration of the launch abort system (LAS) following stage separation. The Orion 1 flight test will be conducted as a full, un-crewed, operational flight test through the entire ascent flight profile prior to the first crewed launch.

Taylor, James L.↗