Search NASA⌕ Search

SEARCH · Search NASA

Results for “contingency 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.

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

At least 55 records · Page 3

Demonstration of automated proximity and docking technologies

An autodock was demonstrated using straightforward techniques and real sensor hardware. A simulation testbed was established and validated. The sensor design was refined with improved optical performance and image processing noise mitigation techniques, and the sensor is ready for production from off-the-shelf components. The autonomous spacecraft architecture is defined. The areas of sensors, docking hardware, propulsion, and avionics are included in the design. The Guidance Navigation and Control architecture and requirements are developed. Modular structures suitable for automated control are used. The spacecraft system manager functions including configuration, resource, and redundancy management are defined. The requirements for autonomous spacecraft executive are defined. High level decisionmaking, mission planning, and mission contingency recovery are a part of this. The next step is to do flight demonstrations. After the presentation the following question was asked. How do you define validation? There are two components to validation definition: software simulation with formal and vigorous validation, and hardware and facility performance validated with respect to software already validated against analytical profile.

Anderson, Robert L.↗

Autonomous reconfigurable GPS/INS navigation and pointing system for rendezvous and docking

This paper describes the results of an integrated navigation and pointing system software development effort sponsored by the NASA MSFC through a SBIR Phase 2 Program. The integrated Global Positioning System (GPS)/Inertial Navigation System (INS) implements an autonomous navigation filter that is reconfigurable in real-time to accommodate mission contingencies. An onboard expert system monitors the spacecraft status and reconfigures the navigation filter accordingly, to optimize the system performance. The navigation filter is a multi-mode Kalman filter to estimate the spacecraft position, velocity, and attitude. Three different GPS-based attitude determination techniques, namely, velocity vector matching, attitude vector matching, and interferometric processing, are implemented to encompass different mission contingencies. The integrated GPS/INS navigation filter will use any of these techniques depending on the mission phase and the state of the sensors. The first technique, velocity vector matching, uses the GPS velocity measurement to estimate the INS velocity errors and exploits the correlation between INS velocity and attitude errors to estimate the attitude. The second technique, attitude vector matching, uses INS gyro measurements and GPS carrier phase (integrated Doppler) measurements during a spacecraft rotation maneuver to determine the attitude. Both of these techniques require only one GPS antenna onboard to determine the spacecraft attitude. The third technique, interferometric processing, requires use of multiple GPS antennae. In order to determine 3-axis body attitude, three GPS antennae (2 no-coplanor baselines) are required.

Upadhyay, Triveni N.↗

An Autonomous Onboard Targeting Algorithm Using Finite Thrust Maneuvers

In earlier investigations, the adaptation and implementation of a modified two-level corrections process as the onboard targeting algorithm for the Trans-Earth Injection phase of Orion is presented. The objective of that targeting algorithm is to generate the times of ignition and magnitudes of the required maneuvers such that the desired state at entry interface is achieved. In an actual onboard flight software implementation, these times of ignition and maneuvers are relayed onto Flight Control for command and execution. Although this process works well when the burn durations or burn arcs are small, this might not be the case during a contingency situation when lower thrust engines are employed to perform the maneuvers. Therefore, a new version of the modified two-level corrections process is formulated to handle the case of finite burn arcs. This paper presents the development and formulation of that finite burn modified two-level corrections process which can again be used as an onboard targeting algorithm for the Trans-Earth Injection phase of Orion. Additionally, performance results and a comparison between the two methods are presented. The finite burn two-level corrector formulation presented here ensures the entry constraints at entry interface are still met without violating the available fuel budget, while still accounting for much longer burn times in its design.

Scarritt, Sara K.↗

An Autonomous Onboard Targeting Algorithm Using Finite Thrust Maneuvers

In earlier investigations, the adaptation and implementation of a modified two-level corrections (or targeting) process as the onboard targeting algorithm for the Trans-Earth Injection phase of Orion is presented. The objective of that targeting algorithm is to generate the times of ignition and magnitudes of the required maneuvers such that the desired state at entry interface is achieved. In an actual onboard flight software implementation, these times of ignition and maneuvers are relayed onto Flight Control for command and execution. Although this process works well when the burn durations or burn arcs are small, this might not be the case during a contingency situation when lower thrust engines are employed to perform the maneuvers. Therefore, a new model for the two-level corrections process is formulated here to accommodate finite burn arcs. This paper presents the development and formulation of the finite burn two-level corrector, used as an onboard targeting algorithm for the Trans-Earth Injection phase of Orion. A performance comparison between the impulsive and finite burn models is also presented. The present formulation ensures all entry constraints are met, without violating the available fuel budget, while allowing for low-thrust scenarios with long burn durations.

Scarritt, Sara K.↗

Mathematical models for space shuttle ground systems

Math models are a series of algorithms, comprised of algebraic equations and Boolean Logic. At Kennedy Space Center, math models for the Space Shuttle Systems are performed utilizing the Honeywell 66/80 digital computers, Modcomp II/45 Minicomputers and special purpose hardware simulators (MicroComputers). The Shuttle Ground Operations Simulator operating system provides the language formats, subroutines, queueing schemes, execution modes and support software to write, maintain and execute the models. The ground systems presented consist primarily of the Liquid Oxygen and Liquid Hydrogen Cryogenic Propellant Systems, as well as liquid oxygen External Tank Gaseous Oxygen Vent Hood/Arm and the Vehicle Assembly Building (VAB) High Bay Cells. The purpose of math modeling is to simulate the ground hardware systems and to provide an environment for testing in a benign mode. This capability allows the engineers to check out application software for loading and launching the vehicle, and to verify the Checkout, Control, & Monitor Subsystem within the Launch Processing System. It is also used to train operators and to predict system response and status in various configurations (normal operations, emergency and contingent operations), including untried configurations or those too dangerous to try under real conditions, i.e., failure modes.

Tory, E. G.↗

Tug fleet and ground operations schedules and controls. Volume 1: Executive summary

This study presents Tug Fleet and Ground Operations Schedules and Controls plan. This plan was developed and optimized out of a combination of individual Tug program phased subplans, special emphasis studies, contingency analyses and sensitivity analyses. The subplans cover the Tug program phases: (1) Tug operational, (2) Interim Upper Stage (IUS)/Tug fleet utilization, (3) and IUS/Tug payload integration, (4) Tug site activation, (5) IUS/Tug transition, (6) Tug acquisition. Resource requirements (facility, GSE, TSE, software, manpower, logistics) are provided in each subplan, as are appropriate Tug processing flows, active and total IUS and Tug fleet requirements, fleet management and Tug payload integration concepts, facility selection recommendations, site activation and IUS to Tug transition requirements. The impact of operational concepts on Tug acquisition is assessed and the impact of operating Tugs out of KSC and WTR is analyzed and presented showing WTR as a delta. Finally, cost estimates for fleet management and ground operations of the DDT&E and operational phases of the Tug program are given.

Source record↗

LADEE Preparations for Contingency Operations for the Lunar Orbit Insertion Maneuver

The Lunar Atmosphere and Dust Environment Explorer (LADEE) spacecraft was launched on September 6, 2013, and completed its mission on April 17, 2014 with a directed impact to the Lunar Surface. Its primary goals were to examine the lunar atmosphere, measure lunar dust, and to demonstrate high rate laser communications. The LADEE mission was a resounding success, achieving all mission objectives, much of which can be attributed to careful planning and preparation. This paper discusses the specific preparations for fault conditions that could occur during a highly-critical phase of the mission. To get to the Moon, the spacecraft traversed multiple phasing loops around the Earth, and then executed a breaking maneuver to achieve lunar orbit. This Lunar Orbit Insertion (LOI) maneuver was perhaps the most time-critical phase of the entire mission. The LOI maneuver had to occur within a twenty minute window in order to achieve lunar orbit with an acceptable amount of propellant remaining. Missing this window would have likely resulted in a loss of the entire mission. An additional challenge of the maneuver was that spacecraft was out of view for approximately one hour prior to the main thruster burn, with the burn needing to occur within five minutes after coming into view. These conditions resulted in unique challenges for ground operations and the fault management system. Early in the planning stages of the mission, the criticality and challenges of this maneuver were evident to the system designers. The major concern was that any triggering of the on-board fault management system, whether it is in response to a true fault or a false positive, would result in an unacceptable delay to the burn. Therefore the flight software was designed with a flexible fault management system, such that any or all of the fault management responses could be disabled for the lead up and execution of the maneuver. Later, a triage was conducted to develop a list of fault responses, mapped to various parts of the timeline of the maneuver. Some of these contingency responses were solely ground-based if the time to detect, diagnose, and respond were adequate. Other responses were automated on-board if the response time from the ground would have been inadequate. For instance, in order to recover from a system reboot, on-board automation would have automatically reconfigured the spacecraft for the burn and reoriented the spacecraft to the burn attitude.These contingency responses were practiced, over and over, during numerous rehearsals. Although the LOI maneuver was executed without having to use any of these contingencies, the LADEE team was adequately prepared for this highly critical phase of the mission.

Cannon, Howard↗

Safety aspects of spacecraft commanding

The commanding of spacecraft is a potentially hazardous activity for the safety of the spacecraft. Present day control systems contain safety features in their commanding subsystem and in addition, strict procedures are also followed by operations staff. However, problems have occurred on a number of missions as a result of erroneous commanding leading in some cases to spacecraft contingencies and even to near loss of the spacecraft. The problems of checking commands in advance are increased by the tendency in modern spacecraft to use blocked/time-tagged commands and the increased usage of on-board computers, for which commands changing on-board software tables can radically change spacecraft or subsystem behavior. This paper reports on an on-going study. The study aims to improve the approach to safety of spacecraft commanding. It will show how ensuring 'safe' commanding can be carried out more efficiently, and with greater reliability, with the help of knowledge based systems and/or fast simulators. The whole concept will be developed based on the Object-Oriented approach.

Peccia, N.↗

NASA's UAS Integration into the NAS: A Report on the Human Systems Integration Phase 1 Simulation Activities

In 2011 the National Aeronautics and Space Administration (NASA) began a five-year Project to address the technical barriers related to routine access of Unmanned Aerial Systems (UAS) in the National Airspace System (NAS). Planned in two phases, the goal of the first phase was to lay the foundations for the Project by identifying those barriers and key issues to be addressed to achieve integration. Phase 1 activities were completed two years into the five-year Project. The purpose of this paper is to review activities within the Human Systems Integration (HSI) subproject in Phase 1 toward its two objectives: 1) develop GCS guidelines for routine UAS access to the NAS, and 2) develop a prototype display suite within an existing Ground Control Station (GCS). The first objective directly addresses a critical barrier for UAS integration into the NAS - a lack of GCS design standards or requirements. First, the paper describes the initial development of a prototype GCS display suite and supporting simulation software capabilities. Then, three simulation experiments utilizing this simulation architecture are summarized. The first experiment sought to determine a baseline performance of UAS pilots operating in civil airspace under current instrument flight rules for manned aircraft. The second experiment examined the effect of currently employed UAS contingency procedures on Air Traffic Control (ATC) participants. The third experiment compared three GCS command and control interfaces on UAS pilot response times in compliance with ATC clearances. The authors discuss how the results of these and future simulation and flight-testing activities contribute to the development of GCS guidelines to support the safe integration of UAS into the NAS. Finally, the planned activities for Phase 2, including an integrated human-in-the-loop simulation and two flight tests are briefly described.

National Airspace System↗

Optimal Propellant Maneuver Flight Demonstrations on ISS

In this paper, first ever flight demonstrations of Optimal Propellant Maneuver (OPM), a method of propulsive rotational state transition for spacecraft controlled using thrusters, is presented for the International Space Station (ISS). On August 1, 2012, two ISS reorientations of about 180deg each were performed using OPMs. These maneuvers were in preparation for the same-day launch and rendezvous of a Progress vehicle, also a first for ISS visiting vehicles. The first maneuver used 9.7 kg of propellant, whereas the second used 10.2 kg. Identical maneuvers performed without using OPMs would have used approximately 151.1kg and 150.9kg respectively. The OPM method is to use a pre-planned attitude command trajectory to accomplish a rotational state transition. The trajectory is designed to take advantage of the complete nonlinear system dynamics. The trajectory choice directly influences the cost of the maneuver, in this case, propellant. For example, while an eigenaxis maneuver is kinematically the shortest path between two orientations, following that path requires overcoming the nonlinear system dynamics, thereby increasing the cost of the maneuver. The eigenaxis path is used for ISS maneuvers using thrusters. By considering a longer angular path, the path dependence of the system dynamics can be exploited to reduce the cost. The benefits of OPM for the ISS include not only reduced lifetime propellant use, but also reduced loads, erosion, and contamination from thrusters due to fewer firings. Another advantage of the OPM is that it does not require ISS flight software modifications since it is a set of commands tailored to the specific attitude control architecture. The OPM takes advantage of the existing ISS control system architecture for propulsive rotation called USTO control mode1. USTO was originally developed to provide ISS Orbiter stack attitude control capability for a contingency tile-repair scenario, where the Orbiter is maneuvered using its robotic manipulator relative to the ISS. Since 2005 USTO has been used for nominal ISS operations.

Bhatt, Sagar↗

A functional description of the Buffered Telemetry Demodulator (BTD)

This article gives a functional description of the buffered telemetry demodulator (BTD), which operates on recorded digital samples to extract the symbols from the received signal. The key advantages of the BTD are as follows: (1) its ability to reprocess the signal to reduce acquisition time; (2) its ability to use future information about the signal and to perform smoothing on past samples; and (3) its minimum transmission bandwidth requirement as each sub carrier harmonic is processed individually. The first application of the BTD would be the Galileo S-band contingency mission, where the signal is so weak that reprocessing to reduce the acquisition time is crucial. Moreover, in the event of employing antenna arraying with full spectrum combining, only the sub carrier harmonics need to be transmitted between sites, resulting in significant reduction in data rate transmission requirements. Software implementation of the BTD is described for various general-purpose computers.

Tsou, H.↗

Orion Exploration Flight Test-1 Contingency Drogue Deploy Velocity Trigger

As a backup to the GPS-aided Kalman filter and the Barometric altimeter, an "adjusted" velocity trigger is used during entry to trigger the chain of events that leads to drogue chute deploy for the Orion Multi-Purpose Crew Vehicle (MPCV) Exploration Flight Test-1 (EFT-1). Even though this scenario is multiple failures deep, the Orion Guidance, Navigation, and Control (GN&C) software makes use of a clever technique that was taken from the Mars Science Laboratory (MSL) program, which recently successfully landing the Curiosity rover on Mars. MSL used this technique to jettison the heat shield at the proper time during descent. Originally, Orion use the un-adjusted navigated velocity, but the removal of the Star Tracker to save costs for EFT-1, increased attitude errors which increased inertial propagation errors to the point where the un-adjusted velocity caused altitude dispersions at drogue deploy to be too large. Thus, to reduce dispersions, the velocity vector is projected onto a "reference" vector that represents the nominal "truth" vector at the desired point in the trajectory. Because the navigation errors are largely perpendicular to the truth vector, this projection significantly reduces dispersions in the velocity magnitude. This paper will detail the evolution of this trigger method for the Orion project and cover the various methods tested to determine the reference "truth" vector; and at what point in the trajectory it should be computed.

Gay, Robert S.↗

Testing of Advanced Capabilities to Enable In-time Safety Management and Assurance for Future Flight Operations

In order to refine an initial Concept of Operations, explore Concepts of Use, and expose/validate requirements for future In-Time Aviation Safety Management Systems (IASMS), testing architectures were created, along with a set of capabilities and underlying information exchange protocols. These systems were conceived and developed based on hazards associated with two envisioned urban area flight domains: (1) highly autonomous small uncrewed aerial systems (sUAS) operating at low altitudes, and (2) highly autonomous air taxis. The initial scope of this development is described in [1]; this report provides an update, focusing on the subsequent developments and test activities. As stated in [1], it is important to note that there are many capabilities already in use by the industry (or soon to be in use) that will play critical roles in future IASMS designs. Those reported here were developed to address a gap in the current state-of-the-art regarding specific hazards/risks, and/or to allow for investigation of the interplay between and across hazard types — particularly regarding how overall safety risk can be reduced or managed effectively. Results of testing and development activities are organized by the operational phase wherein a particular capability would be employed (i.e., preflight, in-flight, and post-flight/off-line). Pre-flight: A set of capabilities were developed to help mitigate safety risk prior to flight (e.g., during flight and mission planning). Results of testing summarize (1) validation activities to raise the Technology Readiness Level (TRL) and (2) evaluation activities where the capabilities were applied to flight/mission planning procedures and used by operators/pilots. For the latter, flight plans were automatically assessed, and operators/pilots were notified of hazardous flight segments so as to enable adjustment of the flight plan and re-evaluation, and/or to better inform go/no-go decisions. Capabilities addressed hazards associated with power consumption, third-party risk, wind, navigation system performance, radiofrequency interference, and proximity to geo-spatial threats (e.g., buildings, trees, and no-fly zones). In-flight: Flight experiments tested capabilities that detect and respond to hazards encountered during flight. In the first series, safety hazards were monitored and assessed onboard, and system-generated mitigation maneuvers were recorded (but not acted upon by the vehicle). In the second series, mitigation maneuver commands directed the aircraft in response to safety hazards (i.e., auto-mitigation). The sUAS used for testing is described in full, as is the test architecture, which included commercial avionics, research avionics, and onboard software designed to detect, assess, and respond to hazards. The onboard system was designed as a run-time assurance framework, consistent with [2] and supportive of both supervisory and automated modes. The primary functions included: real-time risk assessment (RTRA), auto-pilot monitoring, constraint monitoring, and contingency select/triggering. RTRA performs integrated risk assessment considering data from several hazard-related monitors (e.g., battery, motors, navigation, communications, population density, and loss-of-control). Post-flight/off-line: Data monitored and recorded during flights can enable IASMS capabilities that execute after flights have completed (or “off-line”). These include: (1) the ability to identify anomalies and trends that may only be observable when comparing data spanning a number of similar flights; (2) the ability to update and validate pre-flight and in-flight capabilities and any underlying models to improve their performance; (3) the ability to report anomalies/off-nominals that may indicate design changes or maintenance actions are needed; and (4) the ability for humans involved in operations to report safety-relevant observations to help in understanding the flight data and/or the operational context of a flight. Progress on three such capabilities is summarized; the first investigates anomaly detection given a limited set of flight logs and applies an approach previously used for space operations. The second explores what could be identified using a larger set of flight logs, including from web-based forums where flight logs are posted by sUAS autopilot users. The third creates a new means of collecting information on UAS incidents and accidents via the Aviation Safety Reporting System (ASRS).

sUAS↗

Autonomous Operating System (AOS)

The Autonomy Operating System (AOS) is a software system that enables core capabilities for the autonomous operations for an unmanned aircraft. It is based on the NASA cFS system and provides a higher-level layer of infrastructure and applications for the execution of flight plans, natural-language communication with Air Traffic Control, Diagnostics, Prognostics, and contingency planning.

Lowry, Michael R.↗

Work Experience Report

The NASA Platform for Autonomous Systems (NPAS) toolkit is currently being used at the NASA John C. Stennis Space Center (SSC) to develop the INSIGHT program, which will autonomously monitor and control the Nitrogen System of the High Pressure Gas Facility (HPGF) on site. The INSIGHT program is in need of generic timing capabilities in order to perform timing based actions such as pump usage timing and sequence step timing. The purpose of this project was to develop a timing module that could fulfill these requirements and be adaptable for expanded use in the future. The code was written in Gensym G2 software platform, the same as INSIGHT, and was written generically to ensure compatibility with any G2 program. Currently, the module has two timing capabilities, a stopwatch function and a countdown function. Although the module has gone through some functionality testing, actual integration of the module into NPAS and the INSIGHT program is contingent on the module passing later checks.

Guo, Daniel↗

Proximity operations considerations affecting spacecraft design

Proximity operations can be defined as the maneuvering of two or more spacecraft within 1 nautical mile range, with relative velocity less than 10 feet per second. The passive vehicle is nontranslating and should provide for maintenance of the desired approach attitude. It must accommodate the active (translating) vehicle induced structural loads and performance characteristics (mating hardware tolerances), and support sensor compatibility (transponder, visual targets, etc.). The active vehicle must provide adequate sensor systems (relative state information, field-of-view, redundancy), flight control hardware (thruster sizing, minimal cross-coupling, performance margins, redundancy) and software (reconfigurable, attitude/rate modes, translation and rotation fine control authority) characteristic, and adequate non-propulsive consumables such as power. Operational concerns must be considered. These include the following: (1) the desired approach trajectory and relative orientation; (2) the active vehicle thruster plume effects (forces, torques, contamination) on the passive vehicle; and (3) procedures for contingencies such as loss of communications, sensor or propulsion failures, and target vehicle loss of control.

Staas, Steven K.↗

AERCam Autonomy: Intelligent Software Architecture for Robotic Free Flying Nanosatellite Inspection Vehicles

The NASA Johnson Space Center has developed a nanosatellite-class Free Flyer intended for future external inspection and remote viewing of human spacecraft. The Miniature Autonomous Extravehicular Robotic Camera (Mini AERCam) technology demonstration unit has been integrated into the approximate form and function of a flight system. The spherical Mini AERCam Free Flyer is 7.5 inches in diameter and weighs approximately 10 pounds, yet it incorporates significant additional capabilities compared to the 35-pound, 14-inch diameter AERCam Sprint that flew as a Shuttle flight experiment in 1997. Mini AERCam hosts a full suite of miniaturized avionics, instrumentation, communications, navigation, power, propulsion, and imaging subsystems, including digital video cameras and a high resolution still image camera. The vehicle is designed for either remotely piloted operations or supervised autonomous operations, including automatic stationkeeping, point-to-point maneuvering, and waypoint tracking. The Mini AERCam Free Flyer is accompanied by a sophisticated control station for command and control, as well as a docking system for automated deployment, docking, and recharge at a parent spacecraft. Free Flyer functional testing has been conducted successfully on both an airbearing table and in a six-degree-of-freedom closed-loop orbital simulation with avionics hardware in the loop. Mini AERCam aims to provide beneficial on-orbit views that cannot be obtained from fixed cameras, cameras on robotic manipulators, or cameras carried by crewmembers during extravehicular activities (EVA s). On Shuttle or International Space Station (ISS), for example, Mini AERCam could support external robotic operations by supplying orthogonal views to the intravehicular activity (IVA) robotic operator, supply views of EVA operations to IVA and/or ground crews monitoring the EVA, and carry out independent visual inspections of areas of interest around the spacecraft. To enable these future benefits with minimal impact on IVA operators and ground controllers, the Mini AERCam system architecture incorporates intelligent systems attributes that support various autonomous capabilities. 1) A robust command sequencer enables task-level command scripting. Command scripting is employed for operations such as automatic inspection scans over a region of interest, and operator-hands-off automated docking. 2) A system manager built on the same expert-system software as the command sequencer provides detection and smart-response capability for potential system-level anomalies, like loss of communications between the Free Flyer and control station. 3) An AERCam dynamics manager provides nominal and off-nominal management of guidance, navigation, and control (GN&C) functions. It is employed for safe trajectory monitoring, contingency maneuvering, and related roles. This paper will describe these architectural components of Mini AERCam autonomy, as well as the interaction of these elements with a human operator during supervised autonomous control.

Fredrickson, Steven E.↗

Computerized atmospheric trace contaminant control simulation for manned spacecraft

Buildup of atmospheric trace contaminants in enclosed volumes such as a spacecraft may lead to potentially serious health problems for the crew members. For this reason, active control methods must be implemented to minimize the concentration of atmospheric contaminants to levels that are considered safe for prolonged, continuous exposure. Designing hardware to accomplish this has traditionally required extensive testing to characterize and select appropriate control technologies. Data collected since the Apollo project can now be used in a computerized performance simulation to predict the performance and life of contamination control hardware to allow for initial technology screening, performance prediction, and operations and contingency studies to determine the most suitable hardware approach before specific design and testing activities begin. The program, written in FORTRAN 77, provides contaminant removal rate, total mass removed, and per pass efficiency for each control device for discrete time intervals. In addition, projected cabin concentration is provided. Input and output data are manipulated using commercial spreadsheet and data graphing software. These results can then be used in analyzing hardware design parameters such as sizing and flow rate, overall process performance and program economics. Test performance may also be predicted to aid test design.

Perry, J. L.↗