Search NASA⌕ Search

SEARCH · Search NASA

Results for “mission 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 775 records · Page 43

Joint operations planning for space surveillance missions on the MSX satellite

The Midcourse Space Experiment (MSX) satellite, sponsored by BMDO, is intended to gather broad-band phenomenology data on missiles, plumes, naturally occurring earthlimb backgrounds and deep space backgrounds. In addition the MSX will be used to conduct functional demonstrations of space-based space surveillance. The JHU/Applied Physics Laboratory (APL), located in Laurel, MD, is the integrator and operator of the MSX satellite. APL will conduct all operations related to the MSX and is charged with the detailed operations planning required to implement all of the experiments run on the MSX except the space surveillance experiments. The non-surveillance operations are generally amenable to being defined months ahead of time and being scheduled on a monthly basis. Lincoln Laboratory, Massachusetts Institute of Technology (LL), located in Lexington, MA, is the provider of one of the principle MSX instruments, the Space-Based Visible (SBV) sensor, and the agency charged with implementing the space surveillance demonstrations on the MSX. The planning timelines for the space surveillance demonstrations are fundamentally different from those for the other experiments. They are generally amenable to being scheduled on a monthly basis, but the specific experiment sequence and pointing must be refined shortly before execution. This allocation of responsibilities to different organizations implies the need for a joint mission planning system for conducting space surveillance demonstrations. This paper details the iterative, joint planning system, based on passing responsibility for generating MSX commands for surveillance operations from APL to LL for specific scheduled operations. The joint planning system, including the generation of a budget for spacecraft resources to be used for surveillance events, has been successfully demonstrated during ground testing of the MSX and is being validated for MSX launch within the year. The planning system developed for the MSX forms a model possibly applicable to developing distributed mission planning systems for other multi-use satellites.

Stokes, Grant↗

Portable Simulator for On-Board International Space Station Emergency Training

The crew on-board the International Space Station (ISS) have to be prepared for any possible emergency. The emergencies of most concern are a fire, depressurization or a toxic atmosphere. The crew members train on the ground before launch but also need to practice their emergency response skills while they are on orbit for 6 months. On-Board Training (OBT) events for emergency response proficiency used to require the crew and ground teams to use paper "scripts" that showed the path through the emergency procedures. This was not very realistic since the participants could read ahead and never deviate from this scripted path. The new OBT emergency simulator allows the crew to view dynamic information on an iPad only when it would become available during an event. The simulator interface allows the crew member to indicate hatch closures, don and doff masks, read pressures, and sample smoke or atmosphere levels. As the crew executes their actions using the on-board simulator, the ground teams are able to monitor those actions via ground display data flowing through the ISS Ku Band communication system which syncs the on-board simulator software with a ground simulator which is accessible in all the control centers. The OBT Working Group (OBT WG), led by the Chief Training Office (CTO) at Johnson Space center is a Multilateral working group with partners in Russia, Japan, Germany and U.S.A. The OBTWG worked together to create a simulator based on these principles: (a) Create a dynamic simulation that gives real-time data feedback; (b) Maintain real-time interface between Mission Control Centers and crew during OBTs; (c) Provide flexibility for decision making during drill execution; (d) Materially reduce Instructor and Flight Control Team man-hour costs involved with developing, updating, and maintaining emergency OBT cases/scenarios; and (e) Introduce an element of surprise to emergency scenarios so the team can't tell the outcome of the case by reading ahead in a paper script. This paper details some of the background as the project evolved with the International Partners. It also provides more details on how the simulator information for the crew is also shared with the ground teams. Finally, the paper will discuss how this remote simulator concept can be useful for future, longer term space missions.

Bolt, Kathy↗

Reactive Sequencing for Autonomous Navigation Evolving from Phoenix Entry, Descent, and Landing

Virtual Machine Language (VML) is an award-winning advanced procedural sequencing language in use on NASA deep-space missions since 1997, and was used for the successful entry, descent, and landing (EDL) of the Phoenix spacecraft onto the surface of Mars. Phoenix EDL utilized a state-oriented operations architecture which executed within the constraints of the existing VML 2.0 flight capability, compatible with the linear "land or die" nature of the mission. The intricacies of Phoenix EDL included the planned discarding of portions of the vehicle, the complex communications management for relay through on-orbit assets, the presence of temporally indeterminate physical events, and the need to rapidly catch up four days of sequencing should a reboot of the spacecraft flight computer occur shortly before atmospheric entry. These formidable operational challenges led to new techniques for packaging and coordinating reusable sequences called blocks using one-way synchronization via VML sequencing global variable events. The coordinated blocks acted as an ensemble to land the spacecraft, while individually managing various elements in as simple a fashion as possible. This paper outlines prototype VML 2.1 flight capabilities that have evolved from the one-way synchronization techniques in order to implement even more ambitious autonomous mission capabilities. Target missions for these new capabilities include autonomous touch-and-go sampling of cometary and asteroidal bodies, lunar landing of robotic missions, and ultimately landing of crewed lunar vehicles. Close proximity guidance, navigation, and control operations, on-orbit rendezvous, and descent and landing events featured in these missions require elaborate abort capability, manifesting highly non-linear scenarios that are so complex as to overtax traditional sequencing, or even the sort of one-way coordinated sequencing used during EDL. Foreseeing advanced command and control needs for small body and lunar landing guidance, navigation and control scenarios, work began three years ago on substantial upgrades to VML that are now being exercised in scenarios for lunar landing and comet/asteroid rendezvous. The advanced state-based approach includes coordinated state transition machines with distributed decision-making logic. These state machines are not merely sequences - they are reactive logic constructs capable of autonomous decision making within a well-defined domain. Combined with the JPL's AutoNav software used on Deep Space 1 and Deep Impact, the system allows spacecraft to autonomously navigate to an unmapped surface, soft-contact, and either land or ascend. The state machine architecture enabled by VML 2.1 has successfully performed sampling missions and lunar descent missions in a simulated environment, and is progressing toward flight capability. The authors are also investigating using the VML 2.1 flight director architecture to perform autonomous activities like rendezvous with a passive hypothetical Mars sample return capsule. The approach being pursued is similar to the touch-and-go sampling state machines, with the added complications associated with the search for, physical capture of, and securing of a separate spacecraft. Complications include optically finding and tracking the Orbiting Sample Capsule (OSC), keeping the OSC illuminated, making orbital adjustments, and physically capturing the OSC. Other applications could include autonomous science collection and fault compensation.

asteroid↗

Distributed Spacecraft Autonomy (DSA): Development of Swarm Autonomy Capability and Scalability for Spacecraft

The Distributed Spacecraft Autonomy project is developing a suite of software tools that enable an operator to command and receive data from a swarm as a single entity, enable a swarm to autonomously coordinate its actions via distributed decision making and reactive closed-loop control, and model swarm behavior in the presence of anomalies or failures. Our use case is the mapping of the electron density of the ionosphere using radio tomography by coordinating the selection of appropriate GPS channels, and by recording Total Electron Count (TEC)measurements. DSA will be demonstrated on board the NASA Ames Starling mission a swarm of four small, LEO spacecraft, scheduled to launch in 2021. We will also perform a ground demonstration with simulated and hardware-in-the-loop elements, to validate the tools for controlling swarms of up to 100 assets.The capability to communicate autonomously between the swarm satellites is demonstrated via a sophisticated simulation architecture. Historical Plasma sphere TEC data obtained via dual-band Novatel GPS Receivers are utilized as a representative input data set for the swarm. The representative TEC data and GPS satellite observability information is fed to the autonomous software package in place of a true real-time ground data collection process. The swarm satellites actively share status updates amongst one another and utilize multi-agent decision making to optimally identify regions of interest in the TEC distribution. The software,aware of the bandwidth limitations of the swarm satellites, prioritizes explorative measurements,which define the range of observability for the satellites, as well as exploitative measurements,which focus on maximizing the observance potential of regions with prolonged, elevated TEC density. The science of this study can ultimately be used to determine the dynamics and coupling of Earth's magnetosphere, ionosphere, and atmosphere and their response to solar and terrestrial inputs. The findings can be applied to the imaging of critical, transient phenomena in the magnetosphere in later missions. Meanwhile, the swarm autonomy capabilities have far reaching potential in future satellite missions.As an experimental demonstration of the autonomous capabilities of the network, a message is first printed within a core Flight Executive (cFE) application. Two cFE applications that communicate with one another within the same core Flight System (cFS) are shown.Communication between mission applications on the internal cFE bus is extended to utilize Data Distribution Service (DDS) for vehicle-to-vehicle networking. The DDS middle ware provides reliable delivery, routing, and topic subscription features over User Data gram Protocol (UDP).Leveraging Linux containerization, a networked set of satellite instances are generated by script to simulate swarm behavior. Swarm commanding and synchronization through the network is demonstrated under various topologies and data-loss conditions. Finally, autonomous swarms calability from 2 satellites to 100 satellites is shown.

Fugate, Jason↗

Juno Orbit Determination Experience During First Year At Jupiter

The Juno spacecraft successfully inserted into a polar orbit around Jupiter on 5- July-2016. Since the Jupiter Orbit Insertion (JOI) maneuver, Juno has completed six orbits around Jupiter. The mission plan at the time of JOI was for Juno to perform two 53.5-day capture orbits before executing a Period Reduction Maneuver (PRM) to place the spacecraft into its intended 14-day science orbit. This maneuver was canceled due to a concern with the propulsion system. As a result, the Juno spacecraft will remain in its longer orbit period for rest of its mission. This paper discusses the Navigation Team’s experience: the orbit determination strategy and how it changed due to the cancellation of the PRM, challenges fitting the data during perijove, and how we reconstructed the trajectory during Juno’s first year in orbit.

Thompson, Paul↗

National Aeronautics and Space Administration (NASA) Environmental Control and Life Support (ECLS) Integrated Roadmap Development

At present, NASA has considered a number of future human space exploration mission concepts . Yet, detailed mission requirements and vehicle architectures remain mostly undefined, making technology investment strategies difficult to develop and sustain without a top-level roadmap to serve as a guide. This paper documents a roadmap for development of Environmental Control and Life Support Systems (ECLSS) capabilities required to enhance the long-term operation of the International Space Station (ISS) as well as enable beyond-Low Earth Orbit (LEO) human exploration missions. Three generic mission types were defined to serve as a basis for developing a prioritized list of needed capabilities and technologies. Those are 1) a short duration micro gravity mission; 2) a long duration transit microgravity mission; and 3) a long duration surface exploration mission. To organize the effort, ECLSS was categorized into three major functional groups (atmosphere, water, and solid waste management) with each broken down into sub-functions. The ability of existing state-of-the-art (SOA) technologies to meet the functional needs of each of the three mission types was then assessed by NASA subject matter experts. When SOA capabilities were deemed to fall short of meeting the needs of one or more mission types, those gaps were prioritized in terms of whether or not the corresponding capabilities enable or enhance each of the mission types. The result was a list of enabling and enhancing capabilities needs that can be used to guide future ECLSS development, as well as a list of existing hardware that is ready to go for exploration-class missions. A strategy to fulfill those needs over time was then developed in the form of a roadmap. Through execution of this roadmap, the hardware and technologies intended to meet exploration needs will, in many cases, directly benefit the ISS operational capability, benefit the Multi-Purpose Crew Vehicle (MPCV), and guide long-term technology investments for longer duration missions The final product of this paper is an agreed-to ECLSS roadmap detailing ground and flight testing to support the three mission scenarios previously mentioned. This information will also be used to develop the integrated NASA budget submit in January 2012.

Metcalf, Jordan↗

National Aeronautics and Space Administration (NASA) Environmental Control and Life Support (ECLS) Integrated Roadmap Development

Although NASA is currently considering a number of future human space exploration mission concepts, detailed mission requirements and vehicle architectures remain mostly undefined, making technology investment strategies difficult to develop and sustain without a top-level roadmap to serve as a guide. This paper documents the process and results of an effort to define a roadmap for Environmental Control and Life Support Systems (ECLSS) capabilities required to enhance the long-term operation of the International Space Station (ISS) as well as enable beyond-Low Earth Orbit (LEO) human exploration missions. Three generic mission types were defined to serve as a basis for developing a prioritized list of needed capabilities and technologies. Those are 1) a short duration micro-gravity mission; 2) a long duration microgravity mission; and 3) a long duration partial gravity (surface) exploration mission. To organize the effort, a functional decomposition of ECLSS was completed starting with the three primary functions: atmosphere, water, and solid waste management. Each was further decomposed into sub-functions to the point that current state-of-the-art (SOA) technologies could be tied to the sub-function. Each technology was then assessed by NASA subject matter experts as to its ability to meet the functional needs of each of the three mission types. When SOA capabilities were deemed to fall short of meeting the needs of one or more mission types, those gaps were prioritized in terms of whether or not the corresponding capabilities enable or enhance each of the mission types. The result was a list of enabling and enhancing capability needs that can be used to guide future ECLSS development, as well as a list of existing hardware that is ready to go for exploration-class missions. A strategy to fulfill those needs over time was then developed in the form of a roadmap. Through execution of this roadmap, the hardware and technologies intended to meet exploration needs will, in many cases, directly benefit the ISS operational capability, benefit the Multi-Purpose Crew Vehicle (MPCV), and guide long-term technology investments for longer duration missions.

Metcalf, Jordan↗

Risk-based System Upgrade Planning for AOT-IC Presentation [Slides]

The number of deployed systems and different HW/SW form factors makes it difficult to maintain a complete understanding of their health which leads to a reduced level of certainty when assessing risk and trying to prioritize system upgrade efforts. AOT-IC must constantly plan and execute system upgrade and replacement projects to ensure the longevity of the control system. There are many more projects needed than the group can realistically accomplish given schedule and resource constraints. The group must prioritize their upgrade projects to choose only the highest priority projects to execute each year. Currently plans upgrade and replacement projects based on alignment with mission needs, group vision, resource availability, and qualitative risk assessments based on SME estimates. The group maintains a risk register. This is useful as a tool for shaping strategic planning but currently lacks the quantitative data and process needed to generate accurate risk assessments.

43 PARTICLE ACCELERATORS↗

JPL's Approach for Helping Flight Project Managers Meet Today's Management Challenges

All across NASA project managers are facing tough new challenges. NASA has imposed increased oversight and the number of projects at Centers such as JPL has exploded from a handful of large projects to a much greater number of smaller ones. Experienced personnel are retiring at increasing rates and younger, less experienced managers are being rapidly promoted up the ladder. Budgets are capped, competition among NASA Centers and Federally Funded Research and Development Centers (FFRDCs) has increased significantly and there is no longer any tolerance to cost overruns. On top of all this, implementation schedules have been reduced by 25 to 50% to reduce run-out costs, making it even more difficult to define requirements, validate heritage assumptions and make accurate cost estimates during the early phases of the life-cycle.JPL's executive management, under the leadership of the Associate Director for Flight Projects and Mission Success, have attempted to meet these challenges by improving operations in five areas: (1) increased standardization, where it is judged to have significant benefit; (2) better balance and more effective partnering between projects and the line management; (3) increased infrastructure support; (4) improved management training; and (5) more effective review and oversight.

oversights↗

Lessons Learned from Autonomous Sciencecraft Experiment

An Autonomous Science Agent has been flying onboard the Earth Observing One Spacecraft since 2003. This software enables the spacecraft to autonomously detect and responds to science events occurring on the Earth such as volcanoes, flooding, and snow melt. The package includes AI-based software systems that perform science data analysis, deliberative planning, and run-time robust execution. This software is in routine use to fly the EO-l mission. In this paper we briefly review the agent architecture and discuss lessons learned from this multi-year flight effort pertinent to deployment of software agents to critical applications.

Autonomous Sciencecraft Experiment (ASE)↗

An Autonomy Architecture for Aerobot Exploration of the Saturnian Moon Titan

The Huygens probe arrived at Saturn's moon Titan on January 14, 2005, unveiling a world that is radically different from any other in the Solar system. The data obtained, complemented by continuing observations from the Cassini spacecraft, show methane lakes, river channels and drainage basins, sand dunes, cryovolcanos and sierras. This has lead to an enormous scientific interest in a follow-up mission to Titan, using a robotic lighter-than-air vehicle (or aerobot). Aerobots have modest power requirements, can fly missions with extended durations, and have very long distance traverse capabilities. They can execute regional surveys, transport and deploy scientific instruments and in-situ laboratory facilities over vast distances, and also provide surface sampling at strategic science sites. This paper describes our progress in the development of the autonomy technologies that will be required for exploration of Titan. We provide an overview of the autonomy architecture and some of its key components. We also show results obtained from autonomous flight tests conducted in the Mojave desert.

Titan↗

Hardware in the Loop Testing of an Iodine-Fed Hall Thruster

CUBESATS are relatively new spacecraft platforms that are typically deployed from a launch vehicle as a secondary payload,1 providing low-cost access to space for a wide range of end-users. These satellites are comprised of building blocks having dimensions of 10x10x10 cm cu and a mass of 1.33 kg (a 1-U size). While providing low-cost access to space, a major operational limitation is the lack of a propulsion system that can fit within a CubeSat and is capable of executing high delta v maneuvers. This makes it difficult to use CubeSats on missions requiring certain types of maneuvers (i.e. formation flying, spacecraft rendezvous). Recently, work has been performed investigating the use of iodine as a propellant for Hall-effect thrusters (HETs) 2 that could subsequently be used to provide a high specific impulse path to CubeSat propulsion. Iodine stores as a dense solid at very low pressures, making it acceptable as a propellant on a secondary payload. It has exceptionally high ρIsp (density times specific impulse), making it an enabling technology for small satellite near-term applications and providing the potential for systems-level advantages over mid-term high power electric propulsion options. Iodine flow can also be thermally regulated, subliming at relatively low temperature ( less than100 C) to yield I2 vapor at or below 50 torr. At low power, the measured performance of an iodine-fed HET is very similar to that of a state-of-the-art xenon-fed thruster. Just as importantly, the current-voltage discharge characteristics of low power iodine-fed and xenon-fed thrusters are remarkably similar, potentially reducing development and qualifications costs by making it possible to use an already-qualified xenon-HET PPU in an iodine-fed system. Finally, a cold surface can be installed in a vacuum test chamber on which expended iodine propellant can deposit. In addition, the temperature doesn't have to be extremely cold to maintain a low vapor pressure in the vacuum chamber (it is under 10(exp -6) torr at -75 C), making it possible to 'cryopump' the propellant with lower-cost recirculating refrigerant-based systems as opposed to using liquid nitrogen or low temperature gaseous helium cryopanels. In the present paper, we describe testing performed using an iodine-fed 200 W Hall thruster mounted to a thrust stand and operated in conjunction with MSFCs Small Projects Rapid Integration and Test Environment (SPRITE) Portable Hardware In the Loop (PHIL) hardware. This work is performed in support of the iodine satellite (iSAT) project, which aims to fly a 200-W iodine-fed thruster on a 12-U CubeSat. The SPRITE PHIL hardware allows a given vehicle to do a checkout of its avionics algorithm by allowing it to monitor and feed data to simulated sensors and effectors in a digital environment. These data are then used to determine the attitude of the vehicle and a separate computer is used to interpret the data set and visualize it using a 3D graphical interface. The PHIL hardware allows the testing of the vehicles bus by providing 'real' hardware interfaces (in the case of this test a real RS422 bus) and specific components can be modeled to show their interactions with the avionics algorithm (e.g. a thruster model). For the iSAT project the PHIL is used to visualize the operating cycle of the thruster and the subsequent effect this thrusting has on the attitude of the satellite over a given period of time. The test is controlled using software running on an Andrews Space Cortex 160 flight computer. This computer is the current baseline for a full iSAT mission. While the test could be conducted with a lab computer and software, the team chose to exercise the propulsion system with a representative CubeSat-class computer. For purposes of this test, the "flight" software monitored the propulsion and PPU systems, controlled operation of the thruster, and provided thruster state data to the PHIL simulation. Commands to operate the thruster were initiated from an operator's workstation outside the vacuum chamber and passed through the Cortex 160 to exercise portions of the flight avionics. Two custom-designed pieces of electronics hardware have been designed to operate the propellant feed system. One piece of hardware is an auxiliary board that controls a latch valve, proportional flow control valves (PFCVs) and valve heaters as well as measuring pressures, temperatures and PFCV feedback voltage. An onboard FPGA provides a serial link for issuing commands and manages all lower level input-output functions. The other piece of hardware is a power distribution board, which accepts a standard bus voltage input and converts this voltage into all the different current-voltage types required to operate the auxiliary board. These electronics boards are located in the vacuum chamber near the thruster, exposing this hardware to both the vacuum and plasma environments they would encounter during a mission, with these components communicating to the flight computer through an RS-422 interface. The auxiliary board FPGA provides a 28V MOSFET switch circuit with a 20ms pulse to open or close the iodine propellant feed system latch valve. The FPGA provides a pulse width modulation (PWM) signal to a DC/DC boost converter to produce the 12-120V needed for control of the proportional flow control valve. There are eight MOSFET-switched heating circuits in the system. Heaters are 28V and located in the latch valve, PFCV, propellant tank and propellant feed lines. Both the latch valve and PFCV have thermistors built into them for temperature monitoring. There are also seven resistance temperature device (RTD) circuits on the auxiliary board that can be used to measure the propellant tank and feedline temperatures. The signals are conditioned and sent to an analog to digital converter (ADC), which is directly commanded and controlled by the FPGA.

Polzin, Kurt A.↗

The Iodine Satellite (iSat) Propellant Feed System - Design and Demonstration

CUBESATS are relatively new spacecraft platforms that are typically deployed from a launch vehicle as a secondary payload, providing low-cost access to space for a wide range of end-users. These satellites are comprised of building blocks having dimensions of 10x10x10 cm3 and a mass of 1.33 kg (a 1-U size). While providing low-cost access to space, a major operational limitation is the lack of a propulsion system that can fit within a CubeSat and is capable of executing high Delta V maneuvers. This makes it difficult to use CubeSats on missions requiring certain types of maneuvers (i.e. formation flying, spacecraft rendezvous). Work has been performed investigating the use of iodine as a propellant for Hall-effect thrusters (HETs) that could subsequently be used to provide a high specific impulse path to CubeSat propulsion. One of the systems under development to support such a technology is the propellant feed system, which must be capable of storing solid iodine propellant, applying heat to sublime the stored solid into the vapor phase, and then control the flow of low-pressure gaseous iodine to both the thruster and cathode. In a test conducted in 2016, a first-generation iodine propellant feed system was integrated with a cathode and Hall thruster. While this test had to be terminated, the feed system in this first test was able to support both cathode and integrated cathode and thruster operation prior to the termination of the test. In the present paper, we describe work performed since that initial integrated test. The effort uses lessons learned from the previous integrated test, retiring risk associated with the iodine propellant feed system, answering open design-space questions, and demonstrating iodine flow control in an integrated system. The work is undertaken at both the component level and then at the integrated subsystem level to systematically improve the feed system design, improving the hardware fidelity so the appearance and operation of the system are as flight-like as possible. At the component level, the work focuses on the propellant tank, the feed system tubing, the valves used to control the flow to the cathode and thruster, and the heaters that maintain the temperature of the flowpaths and keep iodine from redepositing and clogging the system. Work on the propellant reservoir focuses on fabricating a tank that matches the geometry of the flight design, which allows for the identification of flight tank fabrication issues that may arise and permits thermal testing of a tank possessing the same size and thermal mass as the flight design, which can be used to anchor thermal modeling of the component. This is critical for finalizing the tank heater power requirements that feed into the heater design. All metallic materials in the feed system are hastelloy or Inconel, as these materials are resistant to chemical attack by the highly-reactive iodine vapor. The tubing in the iodine feed system must possess ports to permit a neutral gas purge of the system that clear impurities after iodine is loaded into the propellant tank. A procedure is discussed whereby these ports are crimped and sealed after the purge process is completed so as to not re-expose the iodine system to air. The valves are a critical component for control of the flow to the thruster and the cathode. Significant effort has gone into upgrading the materials of the valves to make them more resistant to chemical attack and into developing an understanding of the use of these valves during the startup and operation of the cathode and thruster. The heaters that line the entire feed system are designed to draw minimal power from the power processing unit (PPU) while still having the capacity to maintain all the feed system components at the temperatures required to discourage iodine deposition inside components downstream of the propellant tank exit. The heaters possess two separate resistive traces, giving the design redundancy should a failure occur in the primary heater circuit of one of the heater zones. The task of operating a feed system in conjunction with a thruster and cathode is undertaken in a series of sub-steps. The system is first assembled and operated on xenon gas, using the valves for cathode startup and thruster control based on measurement of the discharge current. After startup and control on xenon are demonstrated, the thruster will be transitioned to iodine operation, demonstrating thruster startup and feed system control while using a xenon-fed cathode. Finally, the last step is to integrate an iodine-compatible cathode with the system, demonstrate autonomous cathode start-up with open-loop control and thruster start-up with closed-loop control for multiple cycles.

Polzin, Kurt A.↗

Space Weather Models and Their Validation and Verification at the CCMC

The Community Coordinated l\lodeling Center (CCMC) is a US multi-agency activity with a dual mission. With equal emphasis, CCMC strives to provide science support to the international space research community through the execution of advanced space plasma simulations, and it endeavors to support the space weather needs of the CS and partners. Space weather support involves a broad spectrum, from designing robust forecasting systems and transitioning them to forecasters, to providing space weather updates and forecasts to NASA's robotic mission operators. All of these activities have to rely on validation and verification of models and their products, so users and forecasters have the means to assign confidence levels to the space weather information. In this presentation, we provide an overview of space weather models resident at CCMC, as well as of validation and verification activities undertaken at CCMC or through the use of CCMC services.

Hesse, Michael↗

Robot Sequencing and Visualization Program (RSVP)

The Robot Sequencing and Visualization Program (RSVP) is being used in the Mars Science Laboratory (MSL) mission for downlink data visualization and command sequence generation. RSVP reads and writes downlink data products from the operations data server (ODS) and writes uplink data products to the ODS. The primary users of RSVP are members of the Rover Planner team (part of the Integrated Planning and Execution Team (IPE)), who use it to perform traversability/articulation analyses, take activity plan input from the Science and Mission Planning teams, and create a set of rover sequences to be sent to the rover every sol. The primary inputs to RSVP are downlink data products and activity plans in the ODS database. The primary outputs are command sequences to be placed in the ODS for further processing prior to uplink to each rover. RSVP is composed of two main subsystems. The first, called the Robot Sequence Editor (RoSE), understands the MSL activity and command dictionaries and takes care of converting incoming activity level inputs into command sequences. The Rover Planners use the RoSE component of RSVP to put together command sequences and to view and manage command level resources like time, power, temperature, etc. (via a transparent realtime connection to SEQGEN). The second component of RSVP is called HyperDrive, a set of high-fidelity computer graphics displays of the Martian surface in 3D and in stereo. The Rover Planners can explore the environment around the rover, create commands related to motion of all kinds, and see the simulated result of those commands via its underlying tight coupling with flight navigation, motor, and arm software. This software is the evolutionary replacement for the Rover Sequencing and Visualization software used to create command sequences (and visualize the Martian surface) for the Mars Exploration Rover mission.

Cooper, Brian K.↗

Tales from the Mars Science Laboratory Thermal Protection System Development (or, Try Not to Panic When Your Heatshield Material Disappears)

In 2012, the entry vehicle for the Mars Science Laboratory (MSL) mission was the largest and heaviest vehicle flown to another planet, designed to be able to withstand the largest heat fluxes in the Martian atmosphere ever attempted. The heatshield material that had been successfully used for all previous Mars missions had been baselined in the design, but during the development and qualification testing demonstrated catastrophic and unexplained failures. With only 10 months remaining before the original launch date, the TPS team led by NASA Ames designed and implemented a first-ever tiled, ablative heatshield. Highlights from MSL of the testing difficulties and innovations required to execute a new heatshield design will be presented, along with a sneak peak of the Mars 2020 mission.

Hwang, Helen H.↗

Tales from the Mars Science Laboratory Thermal Protection System Development (or, Try Not to Panic When Your Heatshield Material Disappears)

In 2012, the entry vehicle for the Mars Science Laboratory (MSL) mission was the largest and heaviest vehicle flown to another planet, designed to be able to withstand the largest heat fluxes in the Martian atmosphere ever attempted. The heatshield material that had been successfully used for all previous Mars missions had been baselined in the design, but during the development and qualification testing demonstrated catastrophic and unexplained failures. With only 10 months remaining before the original launch date, the TPS team led by NASA Ames designed and implemented a first-ever tiled, ablative heatshield. Highlights from MSL of the testing difficulties and innovations required to execute a new heatshield design will be presented, along with a sneak peak of the Mars 2020 mission.

Hwang, Helen H.↗

Tales from the Mars Science Laboratory Thermal Protection System Development (or, Try Not to Panic When Your Heatshield Material Disappears)

In 2012, the entry vehicle for the Mars Science Laboratory (MSL) mission was the largest and heaviest vehicle flown to another planet, designed to be able to withstand the largest heat fluxes in the Martian atmosphere ever attempted. The heatshield material that had been successfully used for all previous Mars missions had been baselined in the design, but during the development and qualification testing demonstrated catastrophic and unexplained failures. With only 10 months remaining before the original launch date, the TPS team led by NASA Ames designed and implemented a first-ever tiled, ablative heatshield. Highlights from MSL of the testing difficulties and innovations required to execute a new heatshield design will be presented, along with a sneak peak of the Mars 2020 mission.

Helen H. Hwang↗