Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Execution”

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 1,261 records · Page 70
All sourcesNASA NTRSDOE OSTI
NASA NTRS2002

Shuttle Abort Flight Management (SAFM) - Application Overview

One of the most demanding tasks that must be performed by the Space Shuttle flight crew is the process of determining whether, when and where to abort the vehicle should engine or system failures occur during ascent or entry. Current Shuttle abort procedures involve paging through complicated paper checklists to decide on the type of abort and where to abort. Additional checklists then lead the crew through a series of actions to execute the desired abort. This process is even more difficult and time consuming in the absence of ground communications since the ground flight controllers have the analysis tools and information that is currently not available in the Shuttle cockpit. Crew workload specifically abort procedures will be greatly simplified with the implementation of the Space Shuttle Cockpit Avionics Upgrade (CAU) project. The intent of CAU is to maximize crew situational awareness and reduce flight workload thru enhanced controls and displays, and onboard abort assessment and determination capability. SAFM was developed to help satisfy the CAU objectives by providing the crew with dynamic information about the capability of the vehicle to perform a variety of abort options during ascent and entry. This paper- presents an overview of the SAFM application. As shown in Figure 1, SAFM processes the vehicle navigation state and other guidance information to provide the CAU displays with evaluations of abort options, as well as landing site recommendations. This is accomplished by three main SAFM components: the Sequencer Executive, the Powered Flight Function, and the Glided Flight Function, The Sequencer Executive dispatches the Powered and Glided Flight Functions to evaluate the vehicle's capability to execute the current mission (or current abort), as well as more than IS hypothetical abort options or scenarios. Scenarios are sequenced and evaluated throughout powered and glided flight. Abort scenarios evaluated include Abort to Orbit (ATO), Transatlantic Abort Landing (TAL), East Coast Abort Landing (ECAL) and Return to Launch Site (RTLS). Sequential and simultaneous engine failures are assessed and landing footprint information is provided during actual entry scenarios as well as hypothetical "loss of thrust now" scenarios during ascent.

Hu, Howard↗
NASA NTRS2010

Methods and systems for providing reconfigurable and recoverable computing resources

A method for optimizing the use of digital computing resources to achieve reliability and availability of the computing resources is disclosed. The method comprises providing one or more processors with a recovery mechanism, the one or more processors executing one or more applications. A determination is made whether the one or more processors needs to be reconfigured. A rapid recovery is employed to reconfigure the one or more processors when needed. A computing system that provides reconfigurable and recoverable computing resources is also disclosed. The system comprises one or more processors with a recovery mechanism, with the one or more processors configured to execute a first application, and an additional processor configured to execute a second application different than the first application. The additional processor is reconfigurable with rapid recovery such that the additional processor can execute the first application when one of the one more processors fails.

Stange, Kent↗
NASA NTRS2003

Web Program for Development of GUIs for Cluster Computers

WIGLAF (a Web Interface Generator and Legacy Application Facade) is a computer program that provides a Web-based, distributed, graphical-user-interface (GUI) framework that can be adapted to any of a broad range of application programs, written in any programming language, that are executed remotely on any cluster computer system. WIGLAF enables the rapid development of a GUI for controlling and monitoring a specific application program running on the cluster and for transferring data to and from the application program. The only prerequisite for the execution of WIGLAF is a Web-browser program on a user's personal computer connected with the cluster via the Internet. WIGLAF has a client/server architecture: The server component is executed on the cluster system, where it controls the application program and serves data to the client component. The client component is an applet that runs in the Web browser. WIGLAF utilizes the Extensible Markup Language to hold all data associated with the application software, Java to enable platform-independent execution on the cluster system and the display of a GUI generator through the browser, and the Java Remote Method Invocation software package to provide simple, effective client/server networking.

Czikmantory, Akos↗
NASA NTRS2012

Virtual Machine Language 2.1

VML (Virtual Machine Language) is an advanced computing environment that allows spacecraft to operate using mechanisms ranging from simple, time-oriented sequencing to advanced, multicomponent reactive systems. VML has developed in four evolutionary stages. VML 0 is a core execution capability providing multi-threaded command execution, integer data types, and rudimentary branching. VML 1 added named parameterized procedures, extensive polymorphism, data typing, branching, looping issuance of commands using run-time parameters, and named global variables. VML 2 added for loops, data verification, telemetry reaction, and an open flight adaptation architecture. VML 2.1 contains major advances in control flow capabilities for executable state machines. On the resource requirements front, VML 2.1 features a reduced memory footprint in order to fit more capability into modestly sized flight processors, and endian-neutral data access for compatibility with Intel little-endian processors. Sequence packaging has been improved with object-oriented programming constructs and the use of implicit (rather than explicit) time tags on statements. Sequence event detection has been significantly enhanced with multi-variable waiting, which allows a sequence to detect and react to conditions defined by complex expressions with multiple global variables. This multi-variable waiting serves as the basis for implementing parallel rule checking, which in turn, makes possible executable state machines. The new state machine feature in VML 2.1 allows the creation of sophisticated autonomous reactive systems without the need to develop expensive flight software. Users specify named states and transitions, along with the truth conditions required, before taking transitions. Transitions with the same signal name allow separate state machines to coordinate actions: the conditions distributed across all state machines necessary to arm a particular signal are evaluated, and once found true, that signal is raised. The selected signal then causes all identically named transitions in all present state machines to be taken simultaneously. VML 2.1 has relevance to all potential space missions, both manned and unmanned. It was under consideration for use on Orion.

Riedel, Joseph E.↗
NASA NTRS2013

Sample Analysis at Mars Instrument Simulator

The Sample Analysis at Mars Instrument Simulator (SAMSIM) is a numerical model dedicated to plan and validate operations of the Sample Analysis at Mars (SAM) instrument on the surface of Mars. The SAM instrument suite, currently operating on the Mars Science Laboratory (MSL), is an analytical laboratory designed to investigate the chemical and isotopic composition of the atmosphere and volatiles extracted from solid samples. SAMSIM was developed using Matlab and Simulink libraries of MathWorks Inc. to provide MSL mission planners with accurate predictions of the instrument electrical, thermal, mechanical, and fluid responses to scripted commands. This tool is a first example of a multi-purpose, full-scale numerical modeling of a flight instrument with the purpose of supplementing or even eliminating entirely the need for a hardware engineer model during instrument development and operation. SAMSIM simulates the complex interactions that occur between the instrument Command and Data Handling unit (C&DH) and all subsystems during the execution of experiment sequences. A typical SAM experiment takes many hours to complete and involves hundreds of components. During the simulation, the electrical, mechanical, thermal, and gas dynamics states of each hardware component are accurately modeled and propagated within the simulation environment at faster than real time. This allows the simulation, in just a few minutes, of experiment sequences that takes many hours to execute on the real instrument. The SAMSIM model is divided into five distinct but interacting modules: software, mechanical, thermal, gas flow, and electrical modules. The software module simulates the instrument C&DH by executing a customized version of the instrument flight software in a Matlab environment. The inputs and outputs to this synthetic C&DH are mapped to virtual sensors and command lines that mimic in their structure and connectivity the layout of the instrument harnesses. This module executes, and thus validates, complex command scripts prior to their up-linking to the SAM instrument. As an output, this module generates synthetic data and message logs at a rate that is similar to the actual instrument.

Benna, Mehdi↗
NASA NTRS2013

Towards a Decision Support System for Space Flight Operations

The Mission Operations Directorate (MOD) at the Johnson Space Center (JSC) has put in place a Model Based Systems Engineering (MBSE) technological framework for the development and execution of the Flight Production Process (FPP). This framework has provided much added value and return on investment to date. This paper describes a vision for a model based Decision Support System (DSS) for the development and execution of the FPP and its design and development process. The envisioned system extends the existing MBSE methodology and technological framework which is currently in use. The MBSE technological framework currently in place enables the systematic collection and integration of data required for building an FPP model for a diverse set of missions. This framework includes the technology, people and processes required for rapid development of architectural artifacts. It is used to build a feasible FPP model for the first flight of spacecraft and for recurrent flights throughout the life of the program. This model greatly enhances our ability to effectively engage with a new customer. It provides a preliminary work breakdown structure, data flow information and a master schedule based on its existing knowledge base. These artifacts are then refined and iterated upon with the customer for the development of a robust end-to-end, high-level integrated master schedule and its associated dependencies. The vision is to enhance this framework to enable its application for uncertainty management, decision support and optimization of the design and execution of the FPP by the program. Furthermore, this enhanced framework will enable the agile response and redesign of the FPP based on observed system behavior. The discrepancy of the anticipated system behavior and the observed behavior may be due to the processing of tasks internally, or due to external factors such as changes in program requirements or conditions associated with other organizations that are outside of MOD. The paper provides a roadmap for the three increments of this vision. These increments include (1) hardware and software system components and interfaces with the NASA ground system, (2) uncertainty management and (3) re-planning and automated execution. Each of these increments provide value independently; but some may also enable building of a subsequent increment.

Meshkat, Leila↗
NASA NTRS2014

Use of Semi-Autonomous Tools for ISS Commanding and Monitoring

As the International Space Station (ISS) has moved into a utilization phase, operations have shifted to become more ground-based with fewer mission control personnel monitoring and commanding multiple ISS systems. This shift to fewer people monitoring more systems has prompted use of semi-autonomous console tools in the ISS Mission Control Center (MCC) to help flight controllers command and monitor the ISS. These console tools perform routine operational procedures while keeping the human operator "in the loop" to monitor and intervene when off-nominal events arise. Two such tools, the Pre-positioned Load (PPL) Loader and Automatic Operators Recorder Manager (AutoORM), are used by the ISS Communications RF Onboard Networks Utilization Specialist (CRONUS) flight control position. CRONUS is responsible for simultaneously commanding and monitoring the ISS Command & Data Handling (C&DH) and Communications and Tracking (C&T) systems. PPL Loader is used to uplink small pieces of frequently changed software data tables, called PPLs, to ISS computers to support different ISS operations. In order to uplink a PPL, a data load command must be built that contains multiple user-input fields. Next, a multiple step commanding and verification procedure must be performed to enable an onboard computer for software uplink, uplink the PPL, verify the PPL has incorporated correctly, and disable the computer for software uplink. PPL Loader provides different levels of automation in both building and uplinking these commands. In its manual mode, PPL Loader automatically builds the PPL data load commands but allows the flight controller to verify and save the commands for future uplink. In its auto mode, PPL Loader automatically builds the PPL data load commands for flight controller verification, but automatically performs the PPL uplink procedure by sending commands and performing verification checks while notifying CRONUS of procedure step completion. If an off-nominal condition occurs during procedure execution, PPL Loader notifies CRONUS through popup messages, allowing CRONUS to examine the situation and choose an option of how PPL loader should proceed with the procedure. The use of PPL Loader to perform frequent, routine PPL uplinks offloads CRONUS to better monitor two ISS systems. It also reduces procedure performance time and decreases risk of command errors. AutoORM identifies ISS communication outage periods and builds commands to lock, playback, and unlock ISS Operations Recorder files. Operation Recorder files are circular buffer files of continually recorded ISS telemetry data. Sections of these files can be locked from further writing, be played back to capture telemetry data that occurred during an ISS loss of signal (LOS) period, and then be unlocked for future recording use. Downlinked Operation Recorder files are used by mission support teams for data analysis, especially if failures occur during LOS. The commands to lock, playback, and unlock Operations Recorder files are encompassed in three different operational procedures and contain multiple user-input fields. AutoORM provides different levels of automation for building and uplinking the commands to lock, playback, and unlock Operations Recorder files. In its automatic mode, AutoORM automatically detects ISS LOS periods, then generates and uplinks the commands to lock, playback, and unlock Operations Recorder files when MCC regains signal with ISS. AutoORM also features semi-autonomous and manual modes which integrate CRONUS more into the command verification and uplink process. AutoORMs ability to automatically detect ISS LOS periods and build the necessary commands to preserve, playback, and release recorded telemetry data greatly offloads CRONUS to perform more high-level cognitive tasks, such as mission planning and anomaly troubleshooting. Additionally, since Operations Recorder commands contain numerical time input fields which are tedious for a human to manually build, AutoORM's ability to automatically build commands reduces operational command errors. PPL Loader and AutoORM demonstrate principles of semi-autonomous operational tools that will benefit future space mission operations. Both tools employ different levels of automation to perform simple and routine procedures, thereby offloading human operators to perform higher-level cognitive tasks. Because both tools provide procedure execution status and highlight off-nominal indications, the flight controller is able to intervene during procedure execution if needed. Semi-autonomous tools and systems that can perform routine procedures, yet keep human operators informed of execution, will be essential in future long-duration missions where the onboard crew will be solely responsible for spacecraft monitoring and control.

Brzezinski, Amy S.↗
NASA NTRS2014

Ground Operations Autonomous Control and Integrated Health Management

An intelligent autonomous control capability has been developed and is currently being validated in ground cryogenic fluid management operations. The capability embodies a physical architecture consistent with typical launch infrastructure and control systems, augmented by a higher level autonomous control (AC) system enabled to make knowledge-based decisions. The AC system is supported by an integrated system health management (ISHM) capability that detects anomalies, diagnoses causes, determines effects, and could predict future anomalies. AC is implemented using the concept of programmed sequences that could be considered to be building blocks of more generic mission plans. A sequence is a series of steps, and each executes actions once conditions for the step are met (e.g. desired temperatures or fluid state are achieved). For autonomous capability, conditions must consider also health management outcomes, as they will determine whether or not an action is executed, or how an action may be executed, or if an alternative action is executed instead. Aside from health, higher level objectives can also drive how a mission is carried out. The capability was developed using the G2 software environment (www.gensym.com) augmented by a NASA Toolkit that significantly shortens time to deployment. G2 is a commercial product to develop intelligent applications. It is fully object oriented. The core of the capability is a Domain Model of the system where all elements of the system are represented as objects (sensors, instruments, components, pipes, etc.). Reasoning and decision making can be done with all elements in the domain model. The toolkit also enables implementation of failure modes and effects analysis (FMEA), which are represented as root cause trees. FMEA's are programmed graphically, they are reusable, as they address generic FMEA referring to classes of subsystems or objects and their functional relationships. User interfaces for integrated awareness by operators have been created.

Figueroa, Fernando↗
NASA NTRS2014

Re-Engineering the ISS Payload Operations Control Center During Increased Utilization and Critical Onboard Events

With an increase in the utilization and hours of payload operations being executed onboard the International Space Station (ISS), upgrading the NASA Marshall Space Flight Center (MSFC) Huntsville Operations Support Center (HOSC) ISS Payload Control Area (PCA) was essential to gaining efficiencies and assurance of current and future payload health and science return. PCA houses the Payload Operations Integration Center (POIC) responsible for the execution of all NASA payloads onboard the ISS. POIC Flight Controllers are responsible for the operation of voice, stowage, command, telemetry, video, power, thermal, and environmental control in support of ISS science experiments. The methodologies and execution of the PCA refurbishment were planned and performed within a four month period in order to assure uninterrupted operation of ISS payloads and minimal impacts to payload operations teams. To vacate the PCA, three additional HOSC control rooms were reconfigured to handle ISS realtime operations, Backup Control Center (BCC) to Mission Control in Houston, simulations, and testing functions. This involved coordination and cooperation from teams of ISS operations controllers, multiple engineering and design disciplines, management, and construction companies performing an array of activities simultaneously and in sync delivering a final product with no issues that impacted the schedule. For each console operator discipline, studies of Information Technology (IT) tools and equipment layouts, ergonomics, and lines of sight were performed. Infusing some of the latest IT into the project was an essential goal in ensuring future growth and success of the ISS payload science returns. Engineering evaluations led to a state of the art media wall implementation and more efficient ethernet cabling distribution providing the latest products and the best solution for the POIC. These engineering innovations led to cost savings for the project. Constraints involved in the management of the project included executing over 450 crew-hours of ISS real-time payload operations including a major onboard communications upgrade, SpaceX un-berth, a Soyuz launch, roll-out of ISS live video and interviews from the POIC, annual BCC certification and hurricane season, and ISS simulations and testing. Continuous ISS payload operations were possible during the PCA facility modifications with the reconfiguration of four control rooms and standup of two temporary control areas. Another major restriction to the project was an ongoing facility upgrade that included a NASA Headquarters mandated replacement of all electrical and mechanical systems and replacement of an external generator. These upgrades required a facility power outage during the PCA upgrades. The project also encompassed console layout designs and ordering, amenities selections and ordering, excessing of old equipment, moves, disposal of old IT equipment, camera installations, facility tour re-schedules, and contract justifications. These were just some of the tasks needed for a successful project.

Marsh, Angela L.↗
NASA NTRS2014

Re-Engineering the ISS Payload Operations Control Center During Increased Utilization and Critical Onboard Events

With an increase in utilization and hours of payload operations being executed onboard the International Space Station (ISS), upgrading the NASA Marshall Space Flight Center (MSFC) Huntsville Operations Support Center (HOSC) ISS Payload Control Area (PCA) was essential to gaining efficiencies and assurance of current and future payload health and science return. PCA houses the Payload Operations Integration Center (POIC) responsible for the execution of all NASA payloads onboard the ISS. POIC Flight Controllers are responsible for the operation of voice, stowage, command, telemetry, video, power, thermal, and environmental control in support of ISS science experiments. The methodologies and execution of the PCA refurbishment were planned and performed within a four-month period in order to assure uninterrupted operation of ISS payloads and minimal impacts to payload operations teams. To vacate the PCA, three additional HOSC control rooms were reconfigured to handle ISS real-time operations, Backup Control Center (BCC) to Mission Control in Houston, simulations, and testing functions. This involved coordination and cooperation from teams of ISS operations controllers, multiple engineering and design disciplines, management, and construction companies performing an array of activities simultaneously and in sync delivering a final product with no issues that impacted the schedule. For each console operator discipline, studies of Information Technology (IT) tools and equipment layouts, ergonomics, and lines of sight were performed. Infusing some of the latest IT into the project was an essential goal in ensuring future growth and success of the ISS payload science returns. Engineering evaluations led to a state of the art Video Wall implementation and more efficient ethernet cabling distribution providing the latest products and the best solution for the POIC. These engineering innovations led to cost savings for the project. Constraints involved in the management of the project included executing over 450 crew-hours of ISS real-time payload operations including a major onboard communications upgrade, SpaceX un-berth, a Soyuz launch, roll-out of ISS live video and interviews from the POIC, annual BCC certification and hurricane season, and ISS simulations and testing. Continuous ISS payload operations were possible during the PCA facility modifications with the reconfiguration of four control rooms and standup of two temporary control areas. Another major restriction to the project was an ongoing facility upgrade that included a NASA Headquarters mandated replacement of all electrical and mechanical systems and replacement of an external generator. These upgrades required a facility power outage during the PCA upgrades. The project also encompassed console layout designs and ordering, amenities selections and ordering, excessing of old equipment, moves, disposal of old IT equipment, camera installations, facility tour re-schedules, and contract justifications. These were just some of the tasks needed for a successful project. This paper describes the logistics and lessons learned in upgrading a control center capability in the middle of complex real-time operations. Combining the efficiencies of controller interaction and new technology infusion were prime drivers for this upgrade to handle the increased utilization of science research on ISS. The success of this project could not jeopardize the current operations while these facility upgrades occurred.

Dudley, Stephanie R. B.↗
NASA NTRS2010

Spitzer Mission Operation System Planning for IRAC Warm-Instrument Characterization

This paper will describe how the Spitzer Mission Operations System planned and executed the characterization phase between Spitzer's cryogenic mission and its warm mission. To the largest extend possible, the execution of this phase was done with existing processing and procedures. The modifications that were made were in response to the differences of the characterization phase compared to normal phases before and after. The primary two categories of difference are: unknown date of execution due to uncertainty of knowledge of the date of helium depletion, and the short cycle time for data analysis and re-planning during execution. In addition, all of the planning and design had to be done in parallel with normal operations, and we had to transition smoothly back to normal operations following the transition. This paper will also describe the re-planning we had to do following an anomaly discovered in the first days after helium depletion.

IWIC↗
NASA NTRS2016

Analog Testing of Operations Concepts for Mitigation of Communication Latency During Human Space Exploration

OBJECTIVES: NASA Extreme Environment Mission Operations (NEEMO) is an underwater spaceflight analog that allows a true mission‐like operational environment and uses buoyancy effects and added weight to simulate different gravity levels. Three missions were undertaken from 2014‐2015, NEEMO's 18‐20. All missions were performed at the Aquarius undersea research habitat. During each mission, the effects of varying operations concepts and tasks type and complexity on representative communication latencies associated with Mars missions were studied. METHODS: 12 subjects (4 per mission) were weighed out to simulate near‐zero or partial gravity extravehicular activity (EVA) and evaluated different operations concepts for integration and management of a simulated Earth‐based science backroom team (SBT) to provide input and direction during exploration activities. Exploration traverses were planned in advance based on precursor data collected. Subjects completed science‐related tasks including presampling surveys, geologic‐based sampling, and marine‐based sampling as a portion of their tasks on saturation dives up to 4 hours in duration that were to simulate extravehicular activity (EVA) on Mars or the moons of Mars. One‐way communication latencies, 5 and 10 minutes between space and mission control, were simulated throughout the missions. Objective data included task completion times, total EVA times, crew idle time, translation time, SBT assimilation time (defined as time available for SBT to discuss data/imagery after it has been collected, in addition to the time taken to watch imagery streaming over latency). Subjective data included acceptability, simulation quality, capability assessment ratings, and comments. RESULTS: Precursor data can be used effectively to plan and execute exploration traverse EVAs (plans included detailed location of science sites, high‐fidelity imagery of the sites, and directions to landmarks of interest within a site). Operations concepts that allow for presampling surveys enable efficient traverse execution and meaningful Mission Control Center (MCC) interaction across long communication latencies and can be done with minimal crew idle time. Imagery and information from the EVA crew that is transmitted real‐time to the intravehicular (IV) crewmember(s) can be used to verify that exploration traverse plans are being executed correctly. That same data can be effectively used by MCC (across comm latency) to provide further instructions to the crew from a SBT on sampling priorities, additional tasks, and changes to the plan. Text / data capabilities are preferred over voice capabilities between MCC and IV when executing exploration traverse plans over communication latency. Autonomous crew planning tools can be effective at modifying existing plans if the objectives and constraints are clearly defined.

Chappell, Steven P.↗
NASA NTRS2016

NEEMO 18-20: Analog Testing for Mitigation of Communication Latency During Human Space Exploration

NASA Extreme Environment Mission Operations (NEEMO) is an underwater spaceflight analog that allows a true mission-like operational environment and uses buoyancy effects and added weight to simulate different gravity levels. Three missions were undertaken from 2014-2015, NEEMO's 18-20. All missions were performed at the Aquarius undersea research habitat. During each mission, the effects of communication latencies on operations concepts, timelines, and tasks were studied. METHODS: Twelve subjects (4 per mission) were weighed out to simulate near-zero or partial gravity extravehicular activity (EVA) and evaluated different operations concepts for integration and management of a simulated Earth-based science team (ST) to provide input and direction during exploration activities. Exploration traverses were preplanned based on precursor data. Subjects completed science-related tasks including pre-sampling surveys, geologic-based sampling, and marine-based sampling as a portion of their tasks on saturation dives up to 4 hours in duration that were designed to simulate extravehicular activity (EVA) on Mars or the moons of Mars. One-way communication latencies, 5 and 10 minutes between space and mission control, were simulated throughout the missions. Objective data included task completion times, total EVA times, crew idle time, translation time, ST assimilation time (defined as time available for ST to discuss data/imagery after data acquisition). Subjective data included acceptability, simulation quality, capability assessment ratings, and comments. RESULTS: Precursor data can be used effectively to plan and execute exploration traverse EVAs (plans included detailed location of science sites, high-fidelity imagery of the sites, and directions to landmarks of interest within a site). Operations concepts that allow for pre-sampling surveys enable efficient traverse execution and meaningful Mission Control Center (MCC) interaction across communication latencies and can be done with minimal crew idle time. Imagery and contextual information from the EVA crew that is transmitted real-time to the intravehicular (IV) crewmember(s) can be used to verify that exploration traverse plans are being executed correctly. That same data can be effectively used by MCC (across comm latency) to provide meaningful feedback and instruction to the crew regarding sampling priorities, additional tasks, and changes to the EVA timeline. Text / data capabilities are preferred over voice capabilities between MCC and IV when executing exploration traverse plans over communication latency.

Chappell, Steven P.↗
NASA NTRS2017

Program to Optimize Simulated Trajectories II (POST2) Surrogate Models for Mars Ascent Vehicle (MAV) Performance Assessment

The primary purpose of the multiPOST tool is to enable the execution of much larger sets of vehicle cases to allow for broader trade space exploration. However, this exploration is not achieved solely with the increased case throughput. The multiPOST tool is applied to carry out a Design of Experiments (DOE), which is a set of cases that have been structured to capture a maximum amount of information about the design space with minimal computational effort. The results of the DOE are then used to fit a surrogate model, ultimately enabling parametric design space exploration. The approach used for the MAV study includes both DOE and surrogate modeling. First, the primary design considerations for the vehicle were used to develop the variables and ranges for the multiPOST DOE. The final set of DOE variables were carefully selected in order to capture the desired vehicle trades and take into account any special considerations for surrogate modeling. Next, the DOE sets were executed through multiPOST. Following successful completion of the DOE cases, a manual verification trial was performed. The trial involved randomly selecting cases from the DOE set and running them by hand. The results from the human analyst's run and multiPOST were then compared to ensure that the automated runs were being executed properly. Completion of the verification trials was then followed by surrogate model fitting. After fits to the multiPOST data were successfully created, the surrogate models were used as a stand-in for POST2 to carry out the desired MAV trades. Using the surrogate models in lieu of POST2 allowed for visualization of vehicle sensitivities to the input variables as well as rapid evaluation of vehicle performance. Although the models introduce some error into the output of the trade study, they were very effective at identifying areas of interest within the trade space for further refinement by human analysts. The next section will cover all of the ground rules and assumptions associated with DOE setup and multiPOST execution. Section 3.1 gives the final DOE variables and ranges, while section 3.2 addresses the POST2 specific assumptions. The results of the verification trials are given in section 4. Section 5 gives the surrogate model fitting results, including the goodness-of-fit metrics for each fit. Finally, the MAV specific results are discussed in section 6.

Zwack, M. R.↗
NASA NTRS2018

USA Space Debris Environment, Operations, and Research Updates

Space Missions in 2017 Earth Satellite Population Collision Avoidance Maneuvers Post mission Disposal of U.S.A. Spacecraft Space Situational Awareness (SSA) and the Space Debris Sensor (SDS) A total of 86 space launches placed more than 400 spacecraft into Earth orbits during 2017, following the trend of increase over the past decade NASA has established conjunction assessment processes for its human spaceflight and uncrewed spacecraft to avoid accidental collisions with objects tracked by the U.S. Space Surveillance Network - NASA also assists other U.S. government spacecraft owners with conjunction assessments and subsequent maneuvers The ISS has conducted 25 debris collision avoidance maneuvers since 1999 - None in 2016-2017, but an ISS visiting vehicle had one collision avoidance maneuver in 2017 During 2017 NASA executed or assisted in the execution of 21 collision avoidance maneuvers by uncrewed spacecraft - Four maneuvers were conducted to avoid debris from Fengyun-1C - Two maneuvers were conducted to avoid debris from the collision of Cosmos 2251 and Iridium 33 - One maneuver was conducted to avoid the ISS NASA has established conjunction assessment processes for its human spaceflight and uncrewed spacecraft to avoid accidental collisions with objects tracked by the U.S. Space Surveillance Network - NASA also assists other U.S. government spacecraft owners with conjunction assessments and subsequent maneuvers The ISS has conducted 25 debris collision avoidance maneuvers since 1999 - None in 2016-2017, but an ISS visiting vehicle had one collision avoidance maneuver in 2017 During 2017 NASA executed or assisted in the execution of 21 collision avoidance maneuvers by uncrewed spacecraft - Four maneuvers were conducted to avoid debris from Fengyun-1C - Two maneuvers were conducted to avoid debris from the collision of Cosmos 2251 and Iridium 33 The 2014-15 NASA Engineering and Safety Center (NESC) study on the micrometeoroid and orbital debris (MMOD) assessment for the Joint Polar Satellite System (JPSS) provided the following findings - Millimeter-sized orbital debris pose the highest penetration risk to most operational spacecraft in LEO - The most effective means to collect direct measurement data on millimetersized debris above 600 km altitude is to conduct in situ measurements - There is currently no in situ data on such small debris above 600 km altitude Since the orbital debris population follows a power-law size distribution, there are many more millimeter-sized debris than the large tracked objects - Current conjunction assessments and collision avoidance maneuvers against the tracked objects (which are typically 10 cm and larger) only address a small fraction (<1%) of the mission-ending risk from orbital debris To address the millimeter-sized debris data gap above 600 km, NASA has recently developed an innovative in situ measurement instrument - the Space Debris Sensor (SDS) - One maneuver was conducted to avoid the ISS

Liou, J.-C.↗
NASA NTRS2018

Mars Sample Return: Grand Challenge for EDL

A year ago, I gave a talk in anticipation of a Mars Sample Return effort at the 9th Ablation Workshop. Since then a lot has happened. "April of this year, after a year of study phase, NASA and ESA (European Space Agency) signed a Statement of Intent (SOI) to jointly develop a Mars Sample Return plan to be submitted to their respective authorities by the end of 2019. This signing is historic, as it signals the desire, the readiness, and the willingness to work together to execute this inspiring mission, we all have the opportunity to tackle this grand challenge. We have the scientific and engineering maturity to identify the critical technologies ready to be applied, and with discipline this campaign can be executed affordably," Jim Watzin, Mars Program Executive, NASA. NASA Centers with JPL (Jet Propulsion Laboratory) leading the charge is in the midst of a pre-formulation phase for executing a Mars Sample Return before the end of next decade. The proposed talk builds on the previous year talk. In light of the agreement between NASA and ESA, NASA has assumed the responsibilities for developing the earth entry vehicle (EEV) that will fly along with a European Spacecraft and return with the sample from Mars. EEV will be deployed for entry into earth. The EEV design, development, testing and certification have to result in a highly reliable sample return system. The entire architecture has to be demonstrated to meet the planetary protection requirement. NASA is considering two distinctly different earth entry vehicle architectures and with each choice, many different ablative TPS (Thermal Protective Shield) candidates. As a result of the NASA-ESA ongoing studies, some of the key entry conditions and design requirements are better understood today and more are being scoped out. The heat-shield ablative TPS choice need to be done with a good understanding as it plays a very significant role in determining the robustness of the EEV. Knowledge about how materials and system perform, and how the features could become flaws and how flaws lead to failure, etc. need to be clearly understood and the knowledge then need to be used to down select the TPS. This proposed talk will provide greater insight into the progress being made and the challenges that need to be tackled.

Mars Sample Return: Grand Challenge for EDL↗
NASA NTRS2015

Measured Response for UAS Integration into the National Airspace System

The measured response (MR) is the response time of aircraft to Air Traffic Controller (ATCo) commands and clearances. The overall MR can be broken up into several components, including the pilot verbal latencies (MR1), the time between the end of an ATCo clearance and the beginning of the pilots read back, and the execution initiation latency (MR2), the time between the end of the ATCos clearance and when the pilot begins to execute a maneuver. The MR is a crucial concern for the integration of Unmanned Aircraft Systems (UAS) into the National Airspace System (NAS) due to potentially greater latencies stemming from remote pilot communication and command execution. As a result, it is important to quantify what latencies in verbal responding and command execution are acceptable for safe and efficient operations in the NAS. The present studies begin to address these issues in a series of four simulations supported by the UAS Integration into the NAS program.

UAS in the NAS↗
NASA NTRS2016

On the Maneuvers Operational Response for NASA’s Soil Moisture Active-Passive (SMAP) Mission

The Soil-Moisture Active-Passive (SMAP) spacecraft requires various kinds of in-orbit maneuvers over the course of its three-year mission. The types of maneuvers include pre-planned commissioning maneuvers to reach its science orbit, regularly executed orbit maintenance maneuvers to overcome drag and other nominally occurring phenomena, as well as (the possibility of) collision avoidance maneuvers. The architecture of the spacecraft – in terms of availability of commanding via ground assets, the inherited avionics' ability to sequence and execute commands, and the capability of available subsystems able to carry out maneuvers – was well defined early in the development of the spacecraft and mission, well before the operational plan for responding to maneuver requests was cemented. The systems engineering challenge became: how to accommodate all three types of maneuvers in the confines of this well-defined architecture. This paper will describe how the operations team on SMAP successfully met this challenge. Specifically, it will dive into the three pronged approach that SMAP developed to handle each type of maneuver described above – to meet the timeliness requirements leveraged on the operations team to execute said maneuvers, while continuing to fit within the allotted staffing profile during nominal operations. Defining this paradigm to fit the mission’s architecture meant re-defining the original paradigm, (planned maneuvers being thought of separately than collision avoidance maneuvers), and re-classifying all responses to maneuver requests as variations and permutations of a singular operational response to a maneuver request. This paper will also describe the tools that were created to simplify the human interface and automate as much of the response as was possible. Finally, this paper will describe, at a very high level, some of the problems encountered and lessons learned by the operations team when this process was executed the first four times during the first ninety days of operations. Though the architecture of the operations team's response to maneuver requests will never be repeated exactly, the flexibility that was inserted via redefining the scope of the problem and by redefining the human interfaces should influence future projects' architectures earlier in their development – in the hopes that said influence will save time and money in the future.

Tirona, Joseph↗