Search NASA⌕ Search

SEARCH · Search NASA

Results for “staffing”

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 235 records · Page 13
All sourcesNASA NTRSDOE OSTI
NASA NTRS2013

Spitzer Telemetry Processing System

The Spitzer Telemetry Processing System (SirtfTlmProc) was designed to address objectives of JPL's Multi-mission Image Processing Lab (MIPL) in processing spacecraft telemetry and distributing the resulting data to the science community. To minimize costs and maximize operability, the software design focused on automated error recovery, performance, and information management. The system processes telemetry from the Spitzer spacecraft and delivers Level 0 products to the Spitzer Science Center. SirtfTlmProc is a unique system with automated error notification and recovery, with a real-time continuous service that can go quiescent after periods of inactivity. The software can process 2 GB of telemetry and deliver Level 0 science products to the end user in four hours. It provides analysis tools so the operator can manage the system and troubleshoot problems. It automates telemetry processing in order to reduce staffing costs.

Stanboli, Alice↗
NASA NTRS2013

Planetary Protection Bioburden Analysis Program

This program is a Microsoft Access program that performed statistical analysis of the colony counts from assays performed on the Mars Science Laboratory (MSL) spacecraft to determine the bioburden density, 3-sigma biodensity, and the total bioburdens required for the MSL prelaunch reports. It also contains numerous tools that report the data in various ways to simplify the reports required. The program performs all the calculations directly in the MS Access program. Prior to this development, the data was exported to large Excel files that had to be cut and pasted to provide the desired results. The program contains a main menu and a number of submenus. Analyses can be performed by using either all the assays, or only the accountable assays that will be used in the final analysis. There are three options on the first menu: either calculate using (1) the old MER (Mars Exploration Rover) statistics, (2) the MSL statistics for all the assays, or This software implements penetration limit equations for common micrometeoroid and orbital debris (MMOD) shield configurations, windows, and thermal protection systems. Allowable MMOD risk is formulated in terms of the probability of penetration (PNP) of the spacecraft pressure hull. For calculating the risk, spacecraft geometry models, mission profiles, debris environment models, and penetration limit equations for installed shielding configurations are required. Risk assessment software such as NASA's BUMPERII is used to calculate mission PNP; however, they are unsuitable for use in shield design and preliminary analysis studies. The software defines a single equation for the design and performance evaluation of common MMOD shielding configurations, windows, and thermal protection systems, along with a description of their validity range and guidelines for their application. Recommendations are based on preliminary reviews of fundamental assumptions, and accuracy in predicting experimental impact test results. The software is programmed in Visual Basic for Applications for installation as a simple add-in for Microsoft Excel. The user is directed to a graphical user interface (GUI) that requires user inputs and provides solutions directly in Microsoft Excel workbooks. This work was done by Shannon Ryan of the USRA Lunar and Planetary Institute for Johnson Space Center. Further information is contained in a TSP (see page 1). MSC- 24582-1 Micrometeoroid and Orbital Debris (MMOD) Shield Ballistic Limit Analysis Program Lyndon B. Johnson Space Center, Houston, Texas Commercially, because it is so generic, Enigma can be used for almost any project that requires engineering visualization, model building, or animation. Models in Enigma can be exported to many other formats for use in other applications as well. Educationally, Enigma is being used to allow university students to visualize robotic algorithms in a simulation mode before using them with actual hardware. This work was done by David Shores and Sharon P. Goza of Johnson Space Center; Cheyenne McKeegan, Rick Easley, Janet Way, and Shonn Everett of MEI Technologies; Mark Manning of PTI; and Mark Guerra, Ray Kraesig, and William Leu of Tietronix Software, Inc. For further information, contact the JSC Innovation Partnerships Office at (281) 483-3809. MSC-24211-1 Spitzer Telemetry Processing System NASA's Jet Propulsion Laboratory, Pasadena, California The Spitzer Telemetry Processing System (SirtfTlmProc) was designed to address objectives of JPL's Multi-mission Image Processing Lab (MIPL) in processing spacecraft telemetry and distributing the resulting data to the science community. To minimize costs and maximize operability, the software design focused on automated error recovery, performance, and information management. The system processes telemetry from the Spitzer spacecraft and delivers Level 0 products to the Spitzer Science Center. SirtfTlmProc is a unique system with automated error notification and recovery, with a real-time continuous service that can go quiescent after periods of inactivity. The software can process 2 GB of telemetry and deliver Level 0 science products to the end user in four hours. It provides analysis tools so the operator can manage the system and troubleshoot problems. It automates telemetry processing in order to reduce staffing costs. This work was done by Alice Stanboli, Elmain M. Martinez, and James M. McAuley of Caltech for NASA's Jet Propulsion Laboratory. For more information, contact iaoffice @jpl.nasa.gov. This software is available for commercial licensing. Please contact Dan Broderick at Daniel.F. Broderick@jpl.nasa.gov. Refer to NPO-47803. NASA Tech Briefs, September 2013 29 This rapid response computer program predicts Orbiter Wing Leading Edge (WLE) damage caused by ice or foam impact during a Space Shuttle launch (Program "IMPACT2"). The program was developed after the Columbia accident in order to assess quickly WLE damage due to ice, foam, or metal impact (if any) during a Shuttle launch. IMPACT2 simulates an impact event in a few minutes for foam impactors, and in seconds for ice and metal impactors. The damage criterion is derived from results obtained from one sophisticated commercial program, which requires hours to carry out simulations of the same impact events. The program was designed to run much faster than the commercial program with prediction of projectile threshold velocities within 10 to 15% of commercial-program values. The mathematical model involves coupling of Orbiter wing normal modes of vibration to nonlinear or linear springmass models. IMPACT2 solves nonlinear or linear impact problems using classical normal modes of vibration of a target, and nonlinear/ linear time-domain equations for the projectile. Impact loads and stresses developed in the target are computed as functions of time. This model is novel because of its speed of execution. A typical model of foam, or other projectile characterized by material nonlinearities, impacting an RCC panel is executed in minutes instead of hours needed by the commercial programs. Target damage due to impact can be assessed quickly, provided that target vibration modes and allowable stress are known. This work was done by Robert Clark, Jr., Paul Cotter, and Constantine Michalopoulos of The Boeing Company for Johnson Space Center. For further information, contact the JSC Innovation Partnerships Office at (281) 483-3809. MSC-24988-1 Wing Leading Edge RCC Rapid Response Damage Prediction Tool (IMPACT2) Lyndon B. Johnson Space Center, Houston, Texas (3) the MSL statistics for only the accountable assays. Other options on the main menu include a data editing form and utility programs that produce various reports requested by the microbiologists and the project, and tools to generate the groupings for the final analyses. The analyses can be carried out in three ways: Each assay can be treated separately, the assays can be collectively treated for the whole zone as a group, or the assays can be collected in groups designated by the JPL Planetary Protection Manager. The latter approach was used to generate the final report because assays on the same equipment or similar equipment can be assumed to have been exposed to the same environment and cleaning. Thus, the statistics are improved by having a larger population, thereby reducing the standard deviation by the square root of N. For each method mentioned above, three reports are available. The first is a detailed report including all the data. This version was very useful in verifying the calculations. The second is a brief report that is similar to the full detailed report, but does not print out the data. The third is a grand total and summary report in which each assay requires only one line. For the first and second reports, most of the calculations are performed in the report section itself. For the third, all the calculations are performed directly in the query bound to the report. All the numerical results were verified by comparing them with Excel templates, then exporting the data from the Planetary Protection Analysis program to Excel.

Beaudet, Robert A.↗
NASA NTRS2013

Planning Coverage Campaigns for Mission Design and Analysis: CLASP for DESDynl

Mission design and analysis presents challenges in that almost all variables are in constant flux, yet the goal is to achieve an acceptable level of performance against a concept of operations, which might also be in flux. To increase responsiveness, automated planning tools are used that allow for the continual modification of spacecraft, ground system, staffing, and concept of operations, while returning metrics that are important to mission evaluation, such as area covered, peak memory usage, and peak data throughput. This approach was applied to the DESDynl mission design using the CLASP planning system, but since this adaptation, many techniques have changed under the hood for CLASP, and the DESDynl mission concept has undergone drastic changes. The software produces mission evaluation products, such as memory highwater marks, coverage percentages, given a mission design in the form of coverage targets, concept of operations, spacecraft parameters, and orbital parameters. It tries to overcome the lack of fidelity and timeliness of mission requirements coverage analysis during mission design. Previous techniques primarily use Excel in ad hoc fashion to approximate key factors in mission performance, often falling victim to overgeneralizations necessary in such an adaptation. The new program allows designers to faithfully represent their mission designs quickly, and get more accurate results just as quickly.

Knight, Russell L.↗
NASA NTRS2012

Autonomous Aerobraking Development Software: Phase One Performance Analysis at Mars, Venus, and Titan

When entering orbit about a planet or moon with an appreciable atmosphere, instead of using only the propulsion system to insert the spacecraft into its desired orbit, aerodynamic drag can be used after the initial orbit insertion to further decelerate the spacecraft. Several past NASA missions have used this aerobraking technique to reduce the fuel required to deliver a spacecraft into a desired orbit. Aerobraking was first demonstrated at Venus with Magellan in 1993 and then was used to achieve the science orbit of three Mars orbiters: Mars Global Surveyor in 1997, Mars Odyssey in 2001, and Mars Reconnaissance Orbiter in 2006. Although aerobraking itself reduces the propellant required to reach a final low period orbit, it does so at the expense of additional mission time to accommodate the aerobraking operations phase (typically 3-6 months), a large mission operations staff, and significant Deep Space Network (DSN) coverage. By automating ground based tasks and analyses associated with aerobraking and moving these onboard the spacecraft, a flight project could save millions of dollars in operations staffing and DSN costs (Ref. 1).

Maddock, Robert W.↗
NASA NTRS2013

The Antarctic Search for Meteorites: A Model for Deep Space Exploration

In an era of shrinking buying power and reduced flight opportunities, NASA must extract the greatest possible value from all sources of insight into the future of human space exploration. Antarctica is one such source. The history of Antarctic exploration has many political and technical parallels with the development of space, and Antarctica's remoteness and harsh climate make it an excellent proxy for space (e.g., [1,2]). Links between exploration of space and of the Antarctic date back to the International Geophysical Year of 1957-1958, which saw both the launch of Sputnik 1 and the establishment of a station at the South Pole. The Antarctic Search for Meteorites (ANSMET) is an annual expedition to the south polar plateau to collect meteorites. Although its intent is not to simulate a space mission, the handful of astronauts who have participated in ANSMET agree that it is very similar to a long-duration space flight. Independently, NASA and other space agencies have simulated deep space exploration missions in "analog" activities at remote field sites on Earth (e.g., [3]). These include NASA Extreme Environment Mission Operations (NEEMO) [4,5], Desert Research And Technology Studies (Desert RATS) [6,7], and the Pavilion Lake Research Project (PLRP or simply Pavilion Lake) [8]. This report focuses on NEEMO, Desert RATS, and PLRP because of the author's firsthand experience with them. Other noteworthy analogs, such as the arctic Haughton Mars Project and the European Space Agency's underground Cooperative Adventure for Valuing and Exercising human behavior and performance Skills (CAVES), are not treated here. NASA analogs often include fully staffed control centers, astronauts serving as crew, and realistic mission timelines lasting one to two weeks. Analogs have provided key insights into system architectures and operational concepts for the future human exploration of deep space. They have pioneered techniques for human communication with significant speed-of-light delays, for conducting spacewalks on natural objects with negligible surface gravity, and for empowering exploration crews to work with reduced dependence on a ground control center. They have field-tested dozens of emerging technologies including spacewalking tools and full-scale prototype vehicles and habitats. They have provided valuable experience for astronauts preparing for their first space flight, and for flown crewmembers who will take command roles on later flights. Some analogs, especially PLRP, have connected observers in the field with science teams in remotely located control centers to produce high-quality, publishable scientific results. The analogs have accomplished all of this at a tiny fraction of the cost of an actual space flight. This report treats ANSMET as space flight analog. The chapter following this introduction describes ANSMET in depth. The report then presents data on logistics and crew considerations that may be useful for developers of future human space exploration missions. It offers detailed comparisons between ANSMET and past, present, and future space flights on the Space Shuttle, the International Space Station (ISS), and a proposed Mars mission. Those comparisons are intended to complement the work of Eppler [2], who compares ANSMET to the Apollo moon flights. This report also compares ANSMET with the Desert RATS, NEEMO, and PLRP analogs. It then presents observations and makes recommendations related to ANSMET's value as a simulated space mission. The report ends with a short conclusion. The remainder of this introductory chapter provides background material to help readers interpret the rest of the report. It gives brief overviews of Space Shuttle and ISS missions along with information on a notional future human flight to Mars. It also presents the general features of three of NASA's space flight "analog" projects. With those points of reference in place, the chapter concludes with an overview of ANSMET.

Love, Stanley G.↗
NASA NTRS2013

The Impact of Trajectory Prediction Uncertainty on Air Traffic Controller Performance and Acceptability

A Human-In-The-Loop air traffic control simulation investigated the impact of uncertainties in trajectory predictions on NextGen Trajectory-Based Operations concepts, seeking to understand when the automation would become unacceptable to controllers or when performance targets could no longer be met. Retired air traffic controllers staffed two en route transition sectors, delivering arrival traffic to the northwest corner-post of Atlanta approach control under time-based metering operations. Using trajectory-based decision-support tools, the participants worked the traffic under varying levels of wind forecast error and aircraft performance model error, impacting the ground automations ability to make accurate predictions. Results suggest that the controllers were able to maintain high levels of performance, despite even the highest levels of trajectory prediction errors.

trajectory prediction uncertainty↗
NASA NTRS2013

Operational Evaluatioin of Dynamic Weather Routes at American Airlines

Dynamic Weather Routes (DWR) is a search engine that continuously and automatically analyzes inflight aircraft in en route airspace and proposes simple route amendments for more efficient routes around convective weather while considering sector congestion, traffic conflicts, and active Special Use Airspace. NASA and American Airlines (AA) are conducting an operational trial of DWR at the AA System Operations Center in Fort Worth, TX. The trial includes only AA flights in Fort Worth Center airspace. Over the period from July 31, 2012 through August 31, 2012, 45% of routes proposed by DWR and evaluated by AA users - air traffic control coordinators and flight dispatchers - were rated as acceptable as proposed or with some modifications. The wind-corrected potential flying time savings for these acceptable routes totals 470 flying min, and results suggest another 1,500 min of potential savings for flights not evaluated due to staffing limitations. A sector congestion analysis shows that in only two out of 83 DWR routes rated acceptable by AA staff were the flights predicted to fly through a congested sector inside of 30 min downstream of present position. This shows that users considered sector congestion data provided by DWR automation and in nearly all cases did not accept routes through over-capacity sectors. It is estimated that 12 AA flights were given reroute clearances as a direct result of DWR for a total savings of 67 flying min.

air traffic trajectory automation↗
NASA NTRS2014

Design Visualization Internship Overview

This is a report documenting the details of my work as a NASA KSC intern for the Summer Session from June 2nd to August 8th, 2014. This work was conducted within the Design Visualization Group, a Contractor staffed organization within the C1 division of the IT Directorate. The principle responsibilities of the KSC Design Visualization Group are the production of 3D simulations of NASA equipment and facilities for the purpose of planning complex operations such as hardware transportation and vehicle assembly. My role as an intern focused on aiding engineers in using 3D scanning equipment to obtain as-built measurements of NASA facilities, as well as using CATIA and DELMIA to process this data. My primary goals for this internship focused on expanding my CAD knowledge and capabilities, while also learning more about technologies I was previously unfamiliar with, such as 3D scanning. An additional goal of mine was to learn more about how NASA operates, and how the U.S. Space Program operates on a day-to-day basis. This opportunity provided me with a front-row seat to the daily maneuvers and operations of KSC and NASA as a whole. Each work day, I was able to witness, and even take part of, a small building block of the future systems that will take astronauts to other worlds. After my experiences this summer, not only can I say that my goals have been met, but also that this experience has been the highlight of my experience in higher education.

Telescience↗
NASA NTRS2012

JPL Innovation Foundry

Space science missions are increasingly challenged today: in ambition, by increasingly sophisticated hypotheses tested; in development, by the increasing complexity of advanced technologies; in budgeting, by the decline of flagship-class mission opportunities; in management, by expectations for breakthrough science despite a risk-averse programmatic climate; and in planning, by increasing competition for scarce resources. How are the space-science missions of tomorrow being formulated? The paper describes the JPL Innovation Foundry, created in 2011, to respond to this evolving context. The Foundry integrates methods, tools, and experts that span the mission concept lifecycle. Grounded in JPL's heritage of missions, flight instruments, mission proposals, and concept innovation, the Foundry seeks to provide continuity of support and cost-effective, on-call access to the right domain experts at the right time, as science definition teams and Principal Investigators mature mission ideas from "cocktail napkin" to PDR. The Foundry blends JPL capabilities in proposal development and concurrent engineering, including Team X, with new approaches for open-ended concept exploration in earlier, cost-constrained phases, and with ongoing research and technology projects. It applies complexity and cost models, projectformulation lessons learned, and strategy analyses appropriate to each level of concept maturity. The Foundry is organizationally integrated with JPL formulation program offices; staffed by JPL's line organizations for engineering, science, and costing; and overseen by senior Laboratory leaders to assure experienced coordination and review. Incubation of each concept is tailored depending on its maturity and proposal history, and its highest leverage modeling and analysis needs.

mission development↗
NASA NTRS2013

Exploring Mission Concepts with the JPL Innovation Foundry A-Team

The JPL Innovation Foundry has established a new approach for exploring, developing, and evaluating early concepts called the A-Team. The A-Team combines innovative collaborative methods with subject matter expertise and analysis tools to help mature mission concepts. Science, implementation, and programmatic elements are all considered during an A-Team study. Methods are grouped by Concept Maturity Level (CML), from 1 through 3, including idea generation and capture (CML 1), initial feasibility assessment (CML 2), and trade space exploration (CML 3). Methods used for each CML are presented, and the key team roles are described from two points of view: innovative methods and technical expertise. A-Team roles for providing innovative methods include the facilitator, study lead, and assistant study lead. A-Team roles for providing technical expertise include the architect, lead systems engineer, and integration engineer. In addition to these key roles, each A-Team study is uniquely staffed to match the study topic and scope including subject matter experts, scientists, technologists, flight and instrument systems engineers, and program managers as needed. Advanced analysis and collaborative engineering tools (e.g. cost, science traceability, mission design, knowledge capture, study and analysis support infrastructure) are also under development for use in A-Team studies and will be discussed briefly. The A-Team facilities provide a constructive environment for innovative ideas from all aspects of mission formulation to eliminate isolated studies and come together early in the development cycle when they can provide the biggest impact. This paper provides an overview of the A-Team, its study processes, roles, methods, tools and facilities.

Team Eureka↗
NASA NTRS2012

Model Based Systems Engineering on the Europa Mission Concept Study

At the start of 2011, the proposed Jupiter Europa Orbiter (JEO) mission was staffing up in expectation of becoming an official project later in the year for a launch in 2020. A unique aspect of the pre-project work was a strong emphasis and investment on the foundations of Model-Based Systems Engineering (MBSE). As so often happens in this business, plans changed: NASA's budget and science priorities were released and together fundamentally changed the course of JEO. As a result, it returned to being a study task whose objective is to propose more affordable ways to accomplish the science. As part of this transition, the question arose as to whether it could continue to afford the investment in MBSE. In short, the MBSE infusion has survived and is providing clear value to the study effort. By leveraging the existing infrastructure and a modest additional investment, striking advances in the capture and analysis of designs using MBSE were achieved. In the process, the need to remain relevant in the new environment has brought about a wave of innovation and progress. The effort has reaffirmed the importance of architecting. It has successfully harnessed the synergistic relationship of architecting to system modeling. We have found that MBSE can provide greater agility than traditional methods. We have also found that a diverse 'ecosystem' of modeling tools and languages (SysML, Mathematica, even Excel) is not only viable, but an important enabler of agility and adaptability. This paper will describe the successful application of MBSE in the dynamic environment of early mission formulation, the significant results produced and lessons learned in the process.

Bayer, Todd J.↗
NASA NTRS2008

Navigation Ground Data System Engineering for the Cassini/Huygens Mission

The launch of the Cassini/Huygens mission on October 15, 1997, began a seven year journey across the solar system that culminated in the entry of the spacecraft into Saturnian orbit on June 30, 2004. Cassini/Huygens Spacecraft Navigation is the result of a complex interplay between several teams within the Cassini Project, performed on the Ground Data System. The work of Spacecraft Navigation involves rigorous requirements for accuracy and completeness carried out often under uncompromising critical time pressures. To support the Navigation function, a fault-tolerant, high-reliability/high-availability computational environment was necessary to support data processing. Configuration Management (CM) was integrated with fault tolerant design and security engineering, according to the cornerstone principles of Confidentiality, Integrity, and Availability. Integrated with this approach are security benchmarks and validation to meet strict confidence levels. In addition, similar approaches to CM were applied in consideration of the staffing and training of the system administration team supporting this effort. As a result, the current configuration of this computational environment incorporates a secure, modular system, that provides for almost no downtime during tour operations.

Beswick, R. M.↗
NASA NTRS2008

Automated and Adaptive Mission Planning for Orbital Express

The Orbital Express space mission was a Defense Advanced Research Projects Agency (DARPA) lead demonstration of on-orbit satellite servicing scenarios, autonomous rendezvous, fluid transfers of hydrazine propellant, and robotic arm transfers of Orbital Replacement Unit (ORU) components. Boeing's Autonomous Space Transport Robotic Operations (ASTRO) vehicle provided the servicing to the Ball Aerospace's Next Generation Serviceable Satellite (NextSat) client. For communication opportunities, operations used the high-bandwidth ground-based Air Force Satellite Control Network (AFSCN) along with the relatively low-bandwidth GEO-Synchronous space-borne Tracking and Data Relay Satellite System (TDRSS) network. Mission operations were conducted out of the RDT&E Support Complex (RSC) at the Kirtland Air Force Base in New Mexico. All mission objectives were met successfully: The first of several autonomous rendezvous was demonstrated on May 5, 2007; autonomous free-flyer capture was demonstrated on June 22, 2007; the fluid and ORU transfers throughout the mission were successful. Planning operations for the mission were conducted by a team of personnel including Flight Directors, who were responsible for verifying the steps and contacts within the procedures, the Rendezvous Planners who would compute the locations and visibilities of the spacecraft, the Scenario Resource Planners (SRPs), who were concerned with assignment of communications windows, monitoring of resources, and sending commands to the ASTRO spacecraft, and the Mission planners who would interface with the real-time operations environment, process planning products and coordinate activities with the SRP. The SRP position was staffed by JPL personnel who used the Automated Scheduling and Planning ENvironment (ASPEN) to model and enforce mission and satellite constraints. The lifecycle of a plan began three weeks outside its execution on-board. During the planning timeframe, many aspects could change the plan, causing the need for re-planning. These variable factors, ranging from shifting contact times to ground-station closures and required maintenance times, are discussed along with the flexibility of the ASPEN tool to accommodate changes to procedures and the daily or long-range plan, which contributed to the success of the mission. This paper will present an introduction to ASPEN, a more in-depth discussion on its use on the Orbital Express mission, and other relative work. A description of ground operations after the SRP deliveries were made is included, and we briefly discuss lessons learned from the planning perspective and future work.

scheduling↗
NASA NTRS2008

Orbit Control Operations for the Cassini-Huygens Mission

The Cassini-Huygens spacecraft was launched in 1997 as an international and collaborative mission to study Saturn and its many moons. After a seven-year cruise, Cassini began orbiting Saturn for a four- year tour. This tour consists of 157 planned maneuvers, and their back-up locations, designed to target 52 encounters, mostly of Saturn's largest moon Titan. One of the mission's first activities was to release the Huygens probe to Titan in December 2004. Currently in its last year of the prime mission, Cassini-Huygens continues to obtain valuable data on Saturn, Titan, and Saturn's other satellites. Return of this information is in large part due to a healthy spacecraft and successful navigation. A two-year extended mission, beginning July 2008, will offer the opportunity to continue science activities. With a demanding navigation schedule that compares with the prime tour, the Cassini Navigation team relies on operations procedures developed during the prime mission to carry-out the extended mission objectives. Current processes for orbit control operations evolved from the primary navigational requirement of staying close to predetermined targeting conditions according to Cassini science sequence planning. The reference trajectory is comprised of flyby conditions to be accomplished at minimal propellant cost. Control of the planned reference trajectory orbit, and any trajectory updates, is achieved with the execution of Orbit Trim Maneuvers (OTMs). The procedures for designing, processing, and analyzing OTMs during Cassini operations is presented. First, a brief overview of the Cassini-Huygens Mission is given, followed by a general description of navigation. Orbit control and maneuver execution methods are defined, along with an outline of the orbit control staffing and operations philosophy. Finally, an example schedule of orbit control operations is shown.

navigation↗
NASA NTRS2008

Web Based Tool for Mission Operations Scenarios

A conventional practice for spaceflight projects is to document scenarios in a monolithic Operations Concept document. Such documents can be hundreds of pages long and may require laborious updates. Software development practice utilizes scenarios in the form of smaller, individual use cases, which are often structured and managed using UML. We have developed a process and a web-based scenario tool that utilizes a similar philosophy of smaller, more compact scenarios (but avoids the formality of UML). The need for a scenario process and tool became apparent during the authors' work on a large astrophysics mission. It was noted that every phase of the Mission (e.g., formulation, design, verification and validation, and operations) looked back to scenarios to assess completeness of requirements and design. It was also noted that terminology needed to be clarified and structured to assure communication across all levels of the project. Attempts to manage, communicate, and evolve scenarios at all levels of a project using conventional tools (e.g., Excel) and methods (Scenario Working Group meetings) were not effective given limitations on budget and staffing. The objective of this paper is to document the scenario process and tool created to offer projects a low-cost capability to create, communicate, manage, and evolve scenarios throughout project development. The process and tool have the further benefit of allowing the association of requirements with particular scenarios, establishing and viewing relationships between higher- and lower-level scenarios, and the ability to place all scenarios in a shared context. The resulting structured set of scenarios is widely visible (using a web browser), easily updated, and can be searched according to various criteria including the level (e.g., Project, System, and Team) and Mission Phase. Scenarios are maintained in a web-accessible environment that provides a structured set of scenario fields and allows for maximum visibility across the project. One key aspect is that the tool was built for a scenario process that accounts for stakeholder input, review, comment, and concurrence. By creating well-designed opportunities for stakeholder input and concurrence and by making the scenario content easily accessible to all project personnel, we maximize the opportunities for stakeholders to both understand and agree on the concepts for how their mission is to be carried out.

Boyles, Carole A.↗
NASA NTRS2008

Orbit Determination Processes for the Navigation of the Cassini-Huygens Mission

Deep space navigation, particularly the Orbit Determination (OD) operations of Cassini at Saturn, cannot easily be automated due to the complex dynamical environment in which the spacecraft flies; however several sub-processes are automated. The Cassini OD operations are often faced with unique challenges that require more than routine procedures. The OD Team is staffed appropriately to meet the demanding schedules and allow some level of flexibility. This paper will discuss how the OD processes are developed and the seven-member OD team is scheduled to support efficient and accurate Cassini navigation operations. Also discussed will be the requirements of the radio-metric Doppler and range tracking data acquired via the Deep Space Network and the optical navigation images of the satellites to support the daily OD operations. Furthermore, the reliability of the OD solutions, which is ensured within the framework of the OD processes, will be explained.

Antreasian, P.G.↗
NASA NTRS2016

Psychological Support Operations and the ISS One-Year Mission

Since NASA began human presence on the International Space Station (ISS) in November 1998, crews have spent two to seven months onboard. In March 2015 NASA and Russia embarked on a new era of ISS utilization, with two of their crewmembers conducting a one-year mission onboard ISS. The mission has been useful for both research and mission operations to better understand the human, technological, mission management and staffing challenges that may be faced on missions beyond Low Earth Orbit. The work completed during the first 42 ISS missions provided the basis for the pre-flight, in-flight and post-flight work completed by NASA's Space Medicine Operations Division, while our Russian colleagues provided valuable insights from their long-duration mission experiences with missions lasting 10-14 months, which predated the ISS era. Space Medicine's Behavioral Health and Performance Group (BHP) provided pre-flight training, evaluation, and preparation as well as in-flight psychological support for the NASA crewmember. While the BHP team collaboratively planned for this mission with the help of all ISS international partners within the Human Behavior and Performance Working Group to leverage their collective expertise, the US and Russian BHP personnel were responsible for their respective crewmembers. The presentation will summarize the lessons and experience gained within the areas identified by this Working Group as being of primary importance for a one-year mission.

Beven, G.↗
NASA NTRS2014

Automating the SMAP Ground Data System to Support Lights-Out Operations

The Soil Moisture Active Passive (SMAP) Mission is a first tier mission in NASA's Earth Science Decadal Survey. SMAP will provide a global mapping of soil moisture and its freeze/thaw states. This mapping will be used to enhance the understanding of processes that link the terrestrial water, energy, and carbon cycles, and to enhance weather and forecast capabilities. NASA's Jet Propulsion Laboratory has been selected as the lead center for the development and operation of SMAP. The Jet Propulsion Laboratory (JPL) has an extensive history of successful deep space exploration. JPL missions have typically been large scale Class A missions with significant budget and staffing. SMAP represents a new area of JPL focus towards low cost Earth science missions. Success in this new area requires changes to the way that JPL has traditionally provided the Mission Operations System (MOS)/Ground Data System (GDS) functions. The operation of SMAP requires more routine operations activities and support for higher data rates and data volumes than have been achieved in the past. These activities must be addressed by a reduced operations team and support staff. To meet this challenge, the SMAP ground data system provides automation that will perform unattended operations, including automated commanding of the SMAP spacecraft.

GDS↗