Search NASASearch

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 19 records

Contingency Software in Autonomous Systems

This viewgraph presentation reviews the development of contingency software for autonomous systems. Autonomous vehicles currently have a limited capacity to diagnose and mitigate failures. There is a need to be able to handle a broader range of contingencies. The goals of the project are: 1. Speed up diagnosis and mitigation of anomalous situations.2.Automatically handle contingencies, not just failures.3.Enable projects to select a degree of autonomy consistent with their needs and to incrementally introduce more autonomy.4.Augment on-board fault protection with verified contingency scripts

autonomous systems

Contingency Software in Autonomous Systems: Technical Level Briefing

Contingency management is essential to the robust operation of complex systems such as spacecraft and Unpiloted Aerial Vehicles (UAVs). Automatic contingency handling allows a faster response to unsafe scenarios with reduced human intervention on low-cost and extended missions. Results, applied to the Autonomous Rotorcraft Project and Mars Science Lab, pave the way to more resilient autonomous systems.

autonomous systems

Development of a Two-Wheel Contingency Mode for the MAP Spacecraft

The Microwave Anisotropy Probe (MAP) is a follow-on mission to the Cosmic Background Explorer (COBE), and is currently collecting data from its orbit near the second Sun-Earth libration point. Due to limited mass, power, and financial resources, a traditional reliability concept including fully redundant components was not feasible for MAP. Instead, the MAP design employs selective hardware redundancy in tandem with contingency software modes and algorithms to improve the odds of mission success. One direction for such improvement has been the development of a two-wheel backup control strategy. This strategy would allow MAP to position itself for maneuvers and collect science data should one of its three reaction wheels fail. Along with operational considerations, the strategy includes three new control algorithms. These algorithms would use the remaining attitude control actuators-thrusters and two reaction wheels-in ways that achieve control goals while minimizing adverse impacts on the functionality of other subsystems and software.

Starin, Scott R.

Solar Dynamics Observatory Guidance, Navigation, and Control System Overview

The Solar Dynamics Observatory (SDO) was designed and built at the Goddard Space Flight Center, launched from Cape Canaveral on February 11, 2010, and reached its final geosynchronous science orbit on March 16, 2010. The purpose of SDO is to observe the Sun and continuously relay data to a dedicated ground station. SDO remains Sun-pointing throughout most of its mission for the instruments to take measurements of the Sun. The SDO attitude control system (ACS) is a single-fault tolerant design. Its fully redundant attitude sensor complement includes sixteen coarse Sun sensors (CSSs), a digital Sun sensor (DSS), three two-axis inertial reference units (IRUs), and two star trackers (STs). The ACS also makes use of the four guide telescopes included as a part of one of the science instruments. Attitude actuation is performed using four reaction wheels assemblies (RWAs) and eight thrusters, with a single main engine used to provide velocity-change thrust for orbit raising. The attitude control software has five nominal control modes, three wheel-based modes and two thruster-based modes. A wheel-based Safehold running in the attitude control electronics box improves the robustness of the system as a whole. All six modes are designed on the same basic proportional-integral-derivative attitude error structure, with more robust modes setting their integral gains to zero. This paper details the final overall design of the SDO guidance, navigation, and control (GN&C) system and how it was used in practice during SDO launch, commissioning, and nominal operations. This overview will include the ACS control modes, attitude determination and sensor calibration, the high gain antenna (HGA) calibration, and jitter mitigation operation. The Solar Dynamics Observatory mission is part of the NASA Living With a Star program, which seeks to understand the changing Sun and its effects on the Solar System, life, and society. To this end, the SDO spacecraft carries three Sun-observing instruments: Helioseismic and Magnetic Imager (HMI), led by Stanford University; Atmospheric Imaging Assembly (AIA), led by Lockheed Martin Space and Astrophysics Laboratory; and Extreme Ultraviolet Variability Experiment (EVE), led by the University of Colorado. The basic mission is to observe the Sun for a very high percentage of the 5-year mission (10-year goal) with long stretches of uninterrupted observations and with constant, high-data-rate transmission to a dedicated ground station to be located in White Sands, New Mexico. These goals guided the design of the spacecraft bus that will carry and service the three-instrument payload. Overarching design goals for the bus are geosynchronous orbit, near-constant Sun observations with the ability to fly through eclipses, and constant HGA contact with the dedicated ground station. A three-axis stabilized ACS is needed both to point at the Sun accurately and to keep the roll about the Sun vector correctly positioned with respect to the solar north pole. This roll control is especially important for the magnetic field imaging of HM I. The mission requirements have several general impacts on the ACS design. Both the AIA and HMI instruments are very sensitive to the blurring caused by jitter. Each has an image stabilization system (ISS) with some ability to filter out high frequency motion, but below the bandwidth of the ISS the control system must compensate for disturbances within the ACS bandwidth or avoid exciting jitter at higher frequencies. Within the ACS bandwidth, the control requirement imposed by AIA is to place the center of the solar disk no more than 2 arc sec, 3 , from a body-defined target based on one of the GTs that accompany the instrument. This body-defined target, called the science reference boresight (SRB), was determined from the postlaunch orientation of the GTs by averaging the bounding telescope boresights for pitch to get a pitch SRB coordinate, and by averaging the bounding boresights for yaw toet the yaw SRB coordinate. The location of this SRB in the 0.5-deg field-of-view for each GT then becomes the central target for each telescope; one GT is selected for use as the ACS controlling guide telescope (CGT) at any given time. Fine Sun-pointing is effected based on this SRB for all three instruments when the Sun is within the linear range of the CGT. In addition to limiting jitter, HMI science requires averaging several observations, making the instrument sensitive to low frequency motion that induces differential motion between each observation. This requires the spacecraft attitude to be stable about the roll axis to approximately 10 arcsec over a ten-minute period. Instrument calibrations require that the spacecraft point the SRB up to 2.5 degrees in pitch and yaw away from the center of the Sun, placing the Sun outside the field-of-view of the guide telescopes. In such instances, when the GTs cannot provide the definitive target for the ACS, on-board attitude determination combined with ephemeris prediction of the Sun direction must provide the definitive target. EVE is capable of observing the Sun with less dependence on attitude control. However, the ground data processing needs for calibrations result in the most strict attitude knowledge requirements for the mission: [35,70,70] arcsec, 3 , of knowledge with respect to the center of the solar disk. In addition to driving the ACS sensor selection, the knowledge requirements, which have their effect primarily during Inertial mode calibrations, drive the accuracy requirements for the solar ephemeris. The need to achieve and maintain geosynchronous orbit (GEO) drove the need for high-efficiency propulsive systems and appropriate attitude control. The main engine provided high specific impulse for the maneuvers to attain GEO, while the smaller ACS thrusters managed the disturbance torques of the larger engine and provided the capability for much smaller adjustment burns on orbit. SDO s large solar profile means that solar radiation pressure is a large torque disturbance, and the momentum buildup from this disturbance and the GEO altitude drives the ACS to use thrusters to manage vehicle momentum. The demanding data capture budget for the mission, however, requires SDO to avoid frequent thruster maneuvers, while concerns about on-orbit jitter restrict the maximum desired wheel speeds desired from the RWAs. The plan for on-orbit wheel speed and momentum management will be discussed as well as what is now being done in operation after the jitter environment was characterized. The SDO ACS hardware complement is single-fault tolerant. Two main processors carry virtually identical copies of the command and data handling and ACS software, and two identical attitude control electronics (ACE) boxes carry Coldfire processors with contingency ACS software and other hardware interface cards; the ACE structure allows reaction wheels to be commanded by the Sun-pointing Safehold independent of the Mil Std 1553 data bus. The sixteen Adcole CSSs are grouped into primary and backup sets of eight sensors, each set providing the ability to calculate a sun vector. Each set of eight eyes provides full 4 -steradian coverage. The Adcole DSS comprises an optics head and a separate electronics box providing a 1553 data interface. The electronics box is mounted inside the Faraday cage created by the spacecraft bus module. The DSS head with its 32- deg square FOV is mounted on the instrument module with its boresight along the spacecraft X axis, nearly aligned with the Sun during observations. Adcole has designed the DSS calibration parameters so that the accuracy is 0.24 arcminutes within 10 deg of the boresight, and diminishes to 3 arcminutes as the Sun moves towards the edges of its FOV . This DSS calibration scheme provides higher accuracy attitude determination over the range of the instrument calibration maneuvers.

Morgenstern, Wendy M.

A History of Space Shuttle Main Engine (SSME) Redline Limits Management

The Space Shuttle Main Engine (SSME) has several "redlines", which are operational limits designated to preclude a catastrophic shutdown of the SSME. The Space Shuttle Orbiter utilizes a combination of hardware and software to enable or disable the automated redline shutdown capability. The Space Shuttle is launched with the automated SSME redline limits enabled, but there are many scenarios which may result in the manual disabling of the software by the onboard crew. The operational philosophy for manually enabling and disabling the redline limits software has evolved continuously throughout the history of the Space Shuttle Program, due to events such as SSME hardware changes and updates to Space Shuttle contingency abort software. In this paper, the evolution of SSME redline limits management will be fully reviewed, including the operational scenarios which call for manual intervention, and the events that triggered changes to the philosophy. Following this review, improvements to the management of redline limits for future spacecraft will be proposed.

Arnold, Thomas M.

Mission operations concepts for Earth Observing System (EOS)

Mission operation concepts are described which are being used to evaluate and influence space and ground system designs and architectures with the goal of achieving successful, efficient, and cost-effective Earth Observing System (EOS) operations. Emphasis is given to the general characteristics and concepts developed for the EOS Space Measurement System, which uses a new series of polar-orbiting observatories. Data rates are given for various instruments. Some of the operations concepts which require a total system view are also examined, including command operations, data processing, data accountability, data archival, prelaunch testing and readiness, launch, performance monitoring and assessment, contingency operations, flight software maintenance, and security.

Kelly, Angelita C.

Orion GN&C Sequencing for Off-Nominal Rendezvous, Proximity Operations, and Docking

This paper discusses the Concept of Operations of the nine contingency strategies available for off-nominal Rendezvous, Proximity Operations, and Docking of Orion with the Gateway in a Near-Rectilinear Halo Orbit around the Moon. Explanations are provided for each contingency strategy, how they are initiated, when they can be initiated, and how they are designed to protect the crew. Then an overview is provided of the sequencing of the Guidance, Navigation, and Control flight software used to achieve each contingency strategy, in the form of Phases, Segments, Activities, and Modes. These off-nominal scenarios re-quire the definition of new Segments and Activities.

Jordan S. Abell

System IDentification Programs for AirCraft (SIDPAC)

A collection of computer programs for aircraft system identification is described and demonstrated. The programs, collectively called System IDentification Programs for AirCraft, or SIDPAC, were developed in MATLAB as m-file functions. SIDPAC has been used successfully at NASA Langley Research Center with data from many different flight test programs and wind tunnel experiments. SIDPAC includes routines for experiment design, data conditioning, data compatibility analysis, model structure determination, equation-error and output-error parameter estimation in both the time and frequency domains, real-time and recursive parameter estimation, low order equivalent system identification, estimated parameter error calculation, linear and nonlinear simulation, plotting, and 3-D visualization. An overview of SIDPAC capabilities is provided, along with a demonstration of the use of SIDPAC with real flight test data from the NASA Glenn Twin Otter aircraft. The SIDPAC software is available without charge to U.S. citizens by request to the author, contingent on the requestor completing a NASA software usage agreement.

Morelli, Eugene A.

High precision attitude determination for Magsat

A two phase approach to attitude determination software development is introduced. The prelaunch planning and software activities connected with the development and testing of the baseline system for processing nominal attitude data for MAGSAT are described and postlaunch analysis and modifications are outlined. Attitude data processing began 5 months after launch so that postlaunch anomalies could be accounted for. Another advantage of the two phase approach is that costs are reduced because the system is not burdened with software dealing with all possible contingencies. A definitive, continuous, time history of the three axis attitude of the spacecraft was generated to a precision of 20 arc sec (one standard deviation), in each axis. Sensor alignment determinations were done continuously because of the deletrious effects of changing alignments on attitude precision.

Abshire, G.

Automated Software for Manned Spacecraft - Bridging the Gap from Sci Fi to Reality

With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.

Robert C Dempsey

Automated Software for Manned Spacecraft - Bridging the Gap from Sci Fi to Reality

With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.

Robert C. Dempsey

Automated Software for Crewed Spacecraft - Bridging the Gap from Sci Fi to Reality

With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.

Robert C Dempsey

Smarter Software For Enhanced Vehicle Health Monitoring and Inter-Planetary Exploration

The existing philosophy for space mission control was born in the early days of the space program when technology did not exist to put significant control responsibility onboard the spacecraft. NASA relied on a team of ground control experts to troubleshoot systems when problems occurred. As computing capability improved, more responsibility was handed over to the systems software. However, there is still a large contingent of both launch and flight controllers supporting each mission. New technology can update this philosophy to increase mission assurance and reduce the cost of inter-planetary exploration. The advent of model-based diagnosis and intelligent planning software enables spacecraft to handle most routine problems automatically and allocate resources in a flexible way to realize mission objectives. The manifests for recent missions include multiple subsystems and complex experiments. Spacecraft must operate at longer distances from earth where communications delays make earthbound command and control impractical. NASA's Ames Research Center (ARC) has demonstrated the utility of onboard diagnosis and planning with the Remote Agent experiment in 1999. KSC has pioneered model-based diagnosis and demonstrated its utility for ground support operations. KSC and ARC are cooperating in research to improve the state of the art of this technology. This paper highlights model-based reasoning applications for Moon and Mars missions including in-situ resource utilization and enhanced vehicle health monitoring.

Larson, William E.

Automated Target Planning for FUSE Using the SOVA Algorithm

The SOVA algorithm was originally developed under the Resilient Systems and Operations Project of the Engineering for Complex Systems Program from NASA s Aerospace Technology Enterprise as a conceptual framework to support real-time autonomous system mission and contingency management. The algorithm and its software implementation were formulated for generic application to autonomous flight vehicle systems, and its efficacy was demonstrated by simulation within the problem domain of Unmanned Aerial Vehicle autonomous flight management. The approach itself is based upon the precept that autonomous decision making for a very complex system can be made tractable by distillation of the system state to a manageable set of strategic objectives (e.g. maintain power margin, maintain mission timeline, and et cetera), which if attended to, will result in a favorable outcome. From any given starting point, the attainability of the end-states resulting from a set of candidate decisions is assessed by propagating a system model forward in time while qualitatively mapping simulated states into margins on strategic objectives using fuzzy inference systems. The expected return value of each candidate decision is evaluated as the product of the assigned value of the end-state with the assessed attainability of the end-state. The candidate decision yielding the highest expected return value is selected for implementation; thus, the approach provides a software framework for intelligent autonomous risk management. The name adopted for the technique incorporates its essential elements: Strategic Objective Valuation and Attainability (SOVA). Maximum value of the approach is realized for systems where human intervention is unavailable in the timeframe within which critical control decisions must be made. The Far Ultraviolet Spectroscopic Explorer (FUSE) satellite, launched in 1999, has been collecting science data for eight years.[1] At its beginning of life, FUSE had six gyros in two IRUs and four reaction wheels. Over time through various failures, the satellite has been left with one reaction wheel on the vehicle skew axis and two gyros. To remain operational, a control scheme has been implemented using the magnetic torque rods and the remaining momentum wheel.[2] As a consequence, there are attitude regions where there is insufficient torque authority to overcome environmental disturbances (e.g. gravity gradient torques). The situation is further complicated by the fact that these attitude regions shift inertially with time as the spacecraft moves through earth s magnetic field during the course of its orbit. Under these conditions, the burden of planning targets and target-to-target slew maneuvers has increased significantly since the beginning of the mission.[3] Individual targets must be selected so that the magnetic field remains roughly aligned with the skew wheel axis to provide enough control authority to the other two orthogonal axes. If the field moves too far away from the skew axis, the lack of control authority allows environmental torques to pull the satellite away from the target and can potentially cause it to tumble. Slew maneuver planning must factor the stability of targets at the beginning and end, and the torque authority at all points along the slew. Due to the time varying magnetic field geometry relative to any two inertial targets, small modifications in slew maneuver timing can make large differences in the achievability of a maneuver.

Heatwole, Scott

Identifying Contingency Requirements using Obstacle Analysis on an Unpiloted Aerial Vehicle

This paper describes experience using Obstacle Analysis to identify contingency requirements on an unpiloted aerial vehicle. A contingency is an operational anomaly, and may or may not involve component failure. The challenges to this effort were: ( I ) rapid evolution of the system while operational, (2) incremental autonomy as capabilities were transferred from ground control to software control and (3) the eventual safety-criticality of such systems as they begin to fly over populated areas. The results reported here are preliminary but show that Obstacle Analysis helped (1) identify new contingencies that appeared as autonomy increased; (2) identify new alternatives for handling both previously known and new contingencies; and (3) investigate the continued validity of existing software requirements for contingency handling. Since many mobile, intelligent systems are built using a development process that poses the same challenges, the results appear to have applicability to other similar systems.

fault protection

Preliminary Development of Multi-Vehicle (m:N) Operations with NASA Langley’s Remote Vehicle Operations Center

To achieve the vision of Advanced Air Mobility (AAM), a transition from localized operations of aircraft to remote operations is being pursued across many use cases. This transition will allow fewer human operators to manage more increasingly autonomous aircraft (i.e., m operators managing N vehicles, or m:N). To study this operational concept, the National Aeronautics and Space Administration (NASA) Langley Research Center (LaRC) has developed a prototype remote vehicle operations center and ground control station (GCS) software to conduct research with simulated and real flight operations. To date, flight operations at LaRC have been limited to one vehicle per operator. However, the current paper describes initial development and considerations for enabling m:N flight operations at LaRC. Further, the research described in this paper provides the foundation for a concept of operations (ConOps) that will be developed to support remote operators managing multiple increasingly autonomous vehicles, with the goal of exploring human-autonomy teaming (HAT) concepts that enable more advanced m:N operations. Two key enablers have been identified to facilitate successful m:N operations: GCS software updates for multi-vehicle management and procedural updates for vehicle handoffs during off-nominal events. Additionally, specific modifications were identified across five key areas: technology and software, team structure, inter-team communication, contingency plans, and operator decision flows. Next steps in forming the LaRC m:N ConOps will include working with subject-matter experts to identify off-nominal scenarios, implementing the recommended GCS functionality for m:N operations, and performing integration testing of facility capabilities and new operational procedures. Although the future m:N ConOps will be tailored to the NASA LaRC remote operations facility and flight range, it is intended to be a transparent, accessible, and reality-based exemplar for external organizations seeking to create or evaluate their own m:N operational concepts.

m:N

An Onboard ISS Virtual Reality Trainer

Prior to the retirement of the Space Shuttle, many exterior repairs on the International Space Station (ISS) were carried out by shuttle astronauts, trained on the ground and flown to the Station to perform these specific repairs. With the retirement of the shuttle, this is no longer an available option. As such, the need for ISS crew members to review scenarios while on flight, either for tasks they already trained for on the ground or for contingency operations has become a very critical issue. NASA astronauts prepare for Extra-Vehicular Activities (EVA) or Spacewalks through numerous training media, such as: self-study, part task training, underwater training in the Neutral Buoyancy Laboratory (NBL), hands-on hardware reviews and training at the Virtual Reality Laboratory (VRLab). In many situations, the time between the last session of a training and an EVA task might be 6 to 8 months. EVA tasks are critical for a mission and as time passes the crew members may lose proficiency on previously trained tasks and their options to refresh or learn a new skill while on flight are limited to reading training materials and watching videos. In addition, there is an increased need for unplanned contingency repairs to fix problems arising as the Station ages. In order to help the ISS crew members maintain EVA proficiency or train for contingency repairs during their mission, the Johnson Space Center's VRLab designed an immersive ISS Virtual Reality Trainer (VRT). The VRT incorporates a unique optical system that makes use of the already successful Dynamic On-board Ubiquitous Graphics (DOUG) software to assist crew members with procedure reviews and contingency EVAs while on board the Station. The need to train and re-train crew members for EVAs and contingency scenarios is crucial and extremely demanding. ISS crew members are now asked to perform EVA tasks for which they have not been trained and potentially have never seen before. The Virtual Reality Trainer (VRT) provides an immersive 3D environment similar to the one experienced at the VRLab crew training facility at the NASA Johnson Space Center. VRT bridges the gap by allowing crew members to experience an interactive, 3D environment to reinforce skills already learned and to explore new work sites and repair procedures outside the Station.

Miralles, Evelyn