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.

SourceResearch connectionFrom yearThrough year

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

At least 199 records · Page 11

All sources NASA NTRS DOE OSTI

NASA NTRS2002

Space Ops 2002: Bringing Space Operations into the 21st Century. Track 3: Operations, Mission Planning and Control. 2nd Generation Reusable Launch Vehicle-Concepts for Flight Operations

With the successful implementation of the International Space Station (ISS), the National Aeronautics and Space Administration (NASA) enters a new era of opportunity for scientific research. The ISS provides a working laboratory in space, with tremendous capabilities for scientific research. Utilization of these capabilities requires a launch system capable of routinely transporting crew and logistics to/from the ISS, as well as supporting ISS assembly and maintenance tasks. The Space Shuttle serves as NASA's launch system for performing these functions. The Space Shuttle also serves as NASA's launch system for supporting other science and servicing missions that require a human presence in space. The Space Shuttle provides proof that reusable launch vehicles are technically and physically implementable. However, a couple of problems faced by NASA are the prohibitive cost of operating and maintaining the Space Shuttle and its relative inability to support high launch rates. The 2nd Generation Reusable Launch Vehicle (2nd Gen RLV) is NASA's solution to this problem. The 2nd Gen RLV will provide a robust launch system with increased safety, improved reliability and performance, and less cost. The improved performance and reduced costs of the 2nd Gen RLV will free up resources currently spent on launch services. These resource savings can then be applied to scientific research, which in turn can be supported by the higher launch rate capability of the 2nd Gen RLV. The result is a win - win situation for science and NASA. While meeting NASA's needs, the 2nd Gen RLV also provides the United States aerospace industry with a commercially viable launch capability. One of the keys to achieving the goals of the 2nd Gen RLV is to develop and implement new technologies and processes in the area of flight operations. NASA's experience in operating the Space Shuttle and the ISS has brought to light several areas where automation can be used to augment or eliminate functions performed by crew and ground controllers. This experience has also identified the need for new approaches to staffing and training for both crew and ground controllers. This paper provides a brief overview of the mission capabilities provided by the 2nd Gen RLV, a description of NASA's approach to developing the 2nd Gen RLV, a discussion of operations concepts, and a list of challenges to implementing those concepts.

Hagopian, Jeff↗

NASA NTRS2001

Terrestrial Environmental Variables Derived From EOS Platform Sensors

The three main objectives of the overall project were: 1. Adaptation of environmental constraint methods to take advantage of EOS sensors, specifically, MODIS, ASTER, and Landsat-7, in addition to the PM AVHRR observations 2. Refinement of environmental constraint methods based on fundamental scientific knowledge. 3. Assessment of spatial scaling patterns in environmental constraint measurements to evaluate the potential biases and errors that occur when estimating regional and global-scale NPP patterns with moderate to coarse satellite observations. These goals were modified because, on one hand, MODIS data did not become available until after the first year of the project and because of project staffing issues at the University of Maryland., The OSU portion of the project contained a modest amount of funding and responsibility compared to the University of Maryland and the University of Toledo.

Stadler, Stephen J.↗

NASA NTRS2003

Experiences with Testing the Largest Ground System NASA Has Ever Built

In the 1980s, the National Aeronautics and Space Administration (NASA) embarked upon a major Earth-focused program called Mission to Planet Earth. The Goddard Space Flight Center (GSFC) was selected to manage and develop a key component - the Earth Observing System (EOS). The EOS consisted of four major missions designed to monitor the Earth. The missions included 4 spacecraft. Terra (launched December 1999), Aqua (launched May 2002), ICESat (Ice, Cloud, and Land Elevation Satellite, launched January 2003), and Aura (scheduled for launch January 2004). The purpose of these missions was to provide support for NASA s long-term research effort for determining how human-induced and natural changes affect our global environment. The EOS Data and Information System (EOSDIS), a globally distributed, large-scale scientific system, was built to support EOS. Its primary function is to capture, collect, process, and distribute the most voluminous set of remotely sensed scientific data to date estimated to be 350 Gbytes per day. The EOSDIS is composed of a diverse set of elements with functional capabilities that require the implementation of a complex set of computers, high-speed networks, mission-unique equipment, and associated Information Technology (IT) software along with mission-specific software. All missions are constrained by schedule, budget, and staffing resources, and rigorous testing has been shown to be critical to the success of each mission. This paper addresses the challenges associated with the planning, test definition. resource scheduling, execution, and discrepancy reporting involved in the mission readiness testing of a ground system on the scale of EOSDIS. The size and complexity of the mission systems supporting the Aqua flight operations, for example, combined with the limited resources available, prompted the project to challenge the prevailing testing culture. The resulting success of the Aqua Mission Readiness Testing (MRT) program was due in no small measure to re-structuring the traditional programmatic and technical approach to a more efficient and robust program. Programmatically, it meant gaining the endorsement, commitment, and cooperation of the numerous subsystem element managers and other stakeholder organizations. Technically, it required an MRT program that was agile, could rapidly adapt to requirements changes, and was flexible in its overall approach. Furthermore, this paper addresses the following questions: 1. What are the key ingredients (e.g., test tools, organization) needed to conduct a successful MRT program? 2. What distinguishes EOS MRT from the traditional system testing approach? 3. Where should the focus of testing be since it is infeasible to test every element or subsystem? 4. How can MRT be applied effectively to other systems or missions? To provide answers to these questions, this paper relies heavily on real-life, hands-on experiences ("lessons learned") gained during mission readiness testing of the Terra ground system and, most recently, the Aqua and ICESat missions. Moreover, this paper explores how lessons learned were turned into lessons applied for the upcoming Aura mission. Although derived from the EOS missions, MRT techniques and strategies can be applied to enhance the testing of other missions.

Lehtonen, Ken↗

NASA NTRS2004

[Activities of System Studies and Simulation, Inc.]

Contents include the following: 1. Launch Vehicle Interface Work Performed: a. S3 provided to KSC the new launch inclination targets needed for the April '04 launch date. 2. Prelaunch operations work performed: a. S3 updated the staffing plan for MSFC on-console personnel\during the Final Countdown prior to launch. 3. Software Assessment Work Performed: a. S3 evaluated and recommended approval for Program Control Board (PCB) proposed change 649 for ground software changes, as well as change 650 and 650A for Stored Program Commands. 4. Education and Public Outreach Work Performed: a. S3 continues to coordinate the effort for the design and fabrication of scale models of the GP-3 for use at the launch site, education forums, and management/technical briefings. S3 also prepared a Change Request for additional funds needed for fabrication of additional scale models. S3 drafted the planned uses of these models, including the possibility of participation in the Boston, MA showings of the traveling Einstein Exhibit. 5. Program Management Support Work Performed: a. S3 prepared the input for and closed three MSFC Centerwide Action Item Tracking Systems (CAITS) actions during this period.

Source record↗

NASA NTRS2003

Plausible Explanations for Trends in Project Programmatic Findings

This paper investigates several published hypotheses to determine which might explain the observed cyclic pattern in programmatic findings by independent review teams over a ten-year period. The data does not neatly support any of the intra-project theories considered; however, something is obviously triggering these findings. A closer examination of the narratives associated with the programmatic findings did reveal consistency. The recurring themes that appeared with more numerous findings were unclear roles and staffing problems. Other explanations, external to the project teams, were also explored and the data supported a distributed political influence on project performance.

Parsons, Vickie S.↗

NASA NTRS2000

Project Galileo: completing Europa, preparing for Io

Galileo has completed the Europa leg of the Galileo Europa Mission, and is now pumping down the apojove in each succeeding orbit in preparation for the Io phase. Including three encounters earlier in the primary mission, the total of ten close passes by Europa have provided a wealth of interesting and provocative information about this intriguing body. The results presented include new and exciting information about Europa's interactions with Jupiter's magnetosphere, its interior structure, and its tantalizing surface features, which strongly hint at a watery subsurface layer. Additional data concerning Callisto, and its own outlook for a subsurface ocean are also presented. In addition the engineering aspects of operating the spacecraft during the past year are explored, as well as a brief examination of what will be the challenges to prepare for the Io encounters. The steadily increasing radiation dosage that the spacecraft is experiencing is well beyond the original design parameters, and is contributing to a number of spacecraft problems and concerns. The ability of the flight team to analyze and solve these problems, even at the reduced staffing levels of an extended mission, is a testament to their tenacity and loyalty to the mission. The engineering data being generated by these continuing radiation-induced anomalies will prove invaluable to designers of future spacecraft to Jupiter and its satellites. The lessons learned during this arduous process are presented. c 2000 International Astronautical Federation. Published by Elsevier Science Ltd. All rights reserved.

long duration↗

NASA NTRS1997

The Voyager Interstellar Mission

The Voyager Interstellar Mission began on January 1, 1990, with the primary objective being to characterize the interplanetary medium beyond Neptune and to search for the transition region between the interplanetary medium and the interstellar medium. At the start of this mission, the two Voyager spacecraft had already been in flight for over twelve years, having successfully returned a wealth of scientific information about the planetary systems of Jupiter, Saturn, Uranus, and Neptune, and the interplanetary medium between Earth and Neptune. The two spacecraft have the potential to continue returning science data until around the year 2020. With this extended operating lifetime, there is a high likelihood of one of the two spacecraft penetrating the termination shock and possibly the heliopause boundary, and entering interstellar space before that time. This paper describes the Voyager Interstellar Mission--the mission objectives, the spacecraft and science payload, the mission operations system used to support operations, and the mission operations strategy being used to maximize science data return even in the event of certain potential spacecraft subsystem failures. The implementation of automated analysis tools to offset and enable reduced flight team staffing levels is also discussed.

Flight Experiment↗

NASA NTRS2004

CDDIS Data Center Summary for the 2003 IVS Annual Report

This report summarizes activities during the year 2003 and future plans of the Crustal Dynamics Data Information System (CDDIS) with respect to the International VLBI Service for Geodesy and Astrometry (IVS). Included in this report are background information about the CDDIS, the computer architecture, staffing supporting the system, archive contents, and future plans for the CDDIS within the IVS.

Noll, Carey↗

NASA NTRS2004

Lesson Learned

ASA will begin naming "a few hundred" engineers soon who will constitute the Independent. Technical Authority (ITA) recommended by the Columbia Accident Investigation Board to pro- vide an effective check and balance on space programs for safety. Within the next month, the directors of Johnson and Kennedy space centers will name "a couple of dozen at each place" to backstop human spaceflight engineers, according to Theron M. Bradley, Jr., NASA chief engineer. By the time the new fiscal year begins Oct. 1, the ITA should be fully staffed across the agency, with a system of "warrants" delineating who is an expert in what. Overseeing the whole organization

Morring, Frank, Jr.↗

NASA NTRS2005

The Collaborative Information Portal and NASA's Mars Exploration Rover Mission

The Collaborative Information Portal was enterprise software developed jointly by the NASA Ames Research Center and the Jet Propulsion Laboratory for NASA's Mars Exploration Rover mission. Mission managers, engineers, scientists, and researchers used this Internet application to view current staffing and event schedules, download data and image files generated by the rovers, receive broadcast messages, and get accurate times in various Mars and Earth time zones. This article describes the features, architecture, and implementation of this software, and concludes with lessons we learned from its deployment and a look towards future missions.

Mak, Ronald↗

NASA NTRS2005

A Reliable Service-Oriented Architecture for NASA's Mars Exploration Rover Mission

The Collaborative Information Portal (CIP) was enterprise software developed jointly by the NASA Ames Research Center and the Jet Propulsion Laboratory (JPL) for NASA's highly successful Mars Exploration Rover (MER) mission. Both MER and CIP have performed far beyond their original expectations. Mission managers and engineers ran CIP inside the mission control room at JPL, and the scientists ran CIP in their laboratories, homes, and offices. All the users connected securely over the Internet. Since the mission ran on Mars time, CIP displayed the current time in various Mars and Earth time zones, and it presented staffing and event schedules with Martian time scales. Users could send and receive broadcast messages, and they could view and download data and image files generated by the rovers' instruments. CIP had a three-tiered, service-oriented architecture (SOA) based on industry standards, including J2EE and web services, and it integrated commercial off-the-shelf software. A user's interactions with the graphical interface of the CIP client application generated web services requests to the CIP middleware. The middleware accessed the back-end data repositories if necessary and returned results for these requests. The client application could make multiple service requests for a single user action and then present a composition of the results. This happened transparently, and many users did not even realize that they were connecting to a server. CIP performed well and was extremely reliable; it attained better than 99% uptime during the course of the mission. In this paper, we present overviews of the MER mission and of CIP. We show how CIP helped to fulfill some of the mission needs and how people used it. We discuss the criteria for choosing its architecture, and we describe how the developers made the software so reliable. CIP's reliability did not come about by chance, but was the result of several key design decisions. We conclude with some of the important lessons we learned form developing, deploying, and supporting the software.

Mak, Ronald↗

NASA NTRS2005

CDDIS Data Center Summary for the 2004 IVS Annual Report

This report summarizes activities during the year 2004 and future plans of the Crustal Dynamics Data Information System (CDDIS) with respect to the International VLBI service for Geodesy and Astrometry (IVS). Included in this report are background information about the CDDIS, the computer architecture, staffing the support system, archive contents, and future plans for the CDDIS within the IVS.

Noll, Carey↗

NASA NTRS2005

Lessons Learned From Developing Three Generations of Remote Sensing Science Data Processing Systems

The Biospheric Information Systems Branch at NASA s Goddard Space Flight Center has developed three generations of Science Investigator-led Processing Systems for use with various remote sensing instruments. The first system is used for data from the MODIS instruments flown on NASA s Earth Observing Systems @OS) Terra and Aqua Spacecraft launched in 1999 and 2002 respectively. The second generation is for the Ozone Measuring Instrument flying on the EOS Aura spacecraft launched in 2004. We are now developing a third generation of the system for evaluation science data processing for the Ozone Mapping and Profiler Suite (OMPS) to be flown by the NPOESS Preparatory Project (NPP) in 2006. The initial system was based on large scale proprietary hardware, operating and database systems. The current OMI system and the OMPS system being developed are based on commodity hardware, the LINUX Operating System and on PostgreSQL, an Open Source RDBMS. The new system distributes its data archive across multiple server hosts and processes jobs on multiple processor boxes. We have created several instances of this system, including one for operational processing, one for testing and reprocessing and one for applications development and scientific analysis. Prior to receiving the first data from OMI we applied the system to reprocessing information from the Solar Backscatter Ultraviolet (SBUV) and Total Ozone Mapping Spectrometer (TOMS) instruments flown from 1978 until now. The system was able to process 25 years (108,000 orbits) of data and produce 800,000 files (400 GiB) of level 2 and level 3 products in less than a week. We will describe the lessons we have learned and tradeoffs between system design, hardware, operating systems, operational staffing, user support and operational procedures. During each generational phase, the system has become more generic and reusable. While the system is not currently shrink wrapped we believe it is to the point where it could be readily adopted, with substantial cost savings, for other similar tasks.

Tilmes, Curt↗

NASA NTRS2005

Robotic and Human-Tended Collaborative Drilling Automation for Subsurface Exploration

Future in-situ lunar/martian resource utilization and characterization, as well as the scientific search for life on Mars, will require access to the subsurface and hence drilling. Drilling on Earth is hard - an art form more than an engineering discipline. Human operators listen and feel drill string vibrations coming from kilometers underground. Abundant mass and energy make it possible for terrestrial drilling to employ brute-force approaches to failure recovery and system performance issues. Space drilling will require intelligent and autonomous systems for robotic exploration and to support human exploration. Eventual in-situ resource utilization will require deep drilling with probable human-tended operation of large-bore drills, but initial lunar subsurface exploration and near-term ISRU will be accomplished with lightweight, rover-deployable or standalone drills capable of penetrating a few tens of meters in depth. These lightweight exploration drills have a direct counterpart in terrestrial prospecting and ore-body location, and will be designed to operate either human-tended or automated. NASA and industry now are acquiring experience in developing and building low-mass automated planetary prototype drills to design and build a pre-flight lunar prototype targeted for 2011-12 flight opportunities. A successful system will include development of drilling hardware, and automated control software to operate it safely and effectively. This includes control of the drilling hardware, state estimation of both the hardware and the lithography being drilled and state of the hole, and potentially planning and scheduling software suitable for uncertain situations such as drilling. Given that Humans on the Moon or Mars are unlikely to be able to spend protracted EVA periods at a drill site, both human-tended and robotic access to planetary subsurfaces will require some degree of standalone, autonomous drilling capability. Human-robotic coordination will be important, either between a robotic drill and humans on Earth, or a human-tended drill and its visiting crew. The Mars Analog Rio Tinto Experiment (MARTE) is a current project that studies and simulates the remote science operations between an automated drill in Spain and a distant, distributed human science team. The Drilling Automation for Mars Exploration (DAME) project, by contrast: is developing and testing standalone automation at a lunar/martian impact crater analog site in Arctic Canada. The drill hardware in both projects is a hardened, evolved version of the Advanced Deep Drill (ADD) developed by Honeybee Robotics for the Mars Subsurface Program. The current ADD is capable of 20m, and the DAME project is developing diagnostic and executive software for hands-off surface operations of the evolved version of this drill. The current drill automation architecture being developed by NASA and tested in 2004-06 at analog sites in the Arctic and Spain will add downhole diagnosis of different strata, bit wear detection, and dynamic replanning capabilities when unexpected failures or drilling conditions are discovered in conjunction with simulated mission operations and remote science planning. The most important determinant of future 1unar and martian drilling automation and staffing requirements will be the actual performance of automated prototype drilling hardware systems in field trials in simulated mission operations. It is difficult to accurately predict the level of automation and human interaction that will be needed for a lunar-deployed drill without first having extensive experience with the robotic control of prototype drill systems under realistic analog field conditions. Drill-specific failure modes and software design flaws will become most apparent at this stage. DAME will develop and test drill automation software and hardware under stressful operating conditions during several planned field campaigns. Initial results from summer 2004 tests show seven identifi distinct failure modes of the drill: cuttings-removal issues with low-power drilling into permafrost, and successful steps at executive control and initial automation.

Glass, Brian↗

NASA NTRS2006

Lessons Learned from Engineering a Multi-Mission Satellite Operations Center

NASA's Small Explorers (SMEX) satellites have surpassed their designed science-lifetimes and their flight operations teams are now facing the challenge of continuing operations with reduced funding. At present, these missions are being reengineered into a fleet-oriented ground system at Goddard Space Flight Center (GSFC). When completed, this ground system will provide command and control of four SMEX missions and will demonstrate fleet automation and control concepts. As a path-finder for future mission consolidation efforts, this ground system will also demonstrate new ground-based technologies that show promise of supporting longer mission lifecycles and simplifying component integration. One of the core technologies being demonstrated in the SMEiX Mission Operations Center is the GSFC Mission Services Evolution Center (GMSEC) architecture. The GMSEC architecture uses commercial Message Oriented Middleware with a common messaging standard to realize a higher level of component interoperability, allowing for interchangeable components in ground systems. Moreover, automation technologies utilizing the GMSEC architecture are being evaluated and implemented to provide extended lights-out operations. This mode of operation will provide routine monitoring and control of the heterogeneous spacecraft fleet. The operational concepts being developed will reduce the need for staffed contacts and is seen as a necessity for fleet management. This paper will describe the experiences of the integration team throughout the reengineering effort of the SMEX ground system. Additionally, lessons learned will be presented based on the team s experiences with integrating multiple missions into a fleet-based automated ground system.

Madden, Maureen↗

NASA NTRS2006

Transforming Our SMEX Organization by Way of Innovation, Standardization, and Automation

NASA's Small Explorer (SMEX) Flight Operations Team (FOT) is currently tackling the challenge of supporting ground operations for several satellites that have surpassed their designed lifetime and have a dwindling budget. At Goddard Space Flight Center (GSFC), these missions are presently being reengineered into a fleet-oriented ground system. When complete, this ground system will provide command and control of four SMEX missions, and will demonstrate fleet automation and control concepts as a pathfinder for additional mission integrations. A goal of this reengineering effort is to demonstrate new ground-system technologies that show promise of supporting longer mission lifecycles and simplifying component integration. In pursuit of this goal, the SMEX organization has had to examine standardization, innovation, and automation. A core technology being demonstrated in this effort is the GSFC Mission Services Evolution Center (GMSEC) architecture. The GMSEC architecture focuses on providing standard interfaces for ground system applications to promote application interoperability. Building around commercial Message Oriented Middleware and providing a common messaging standard allows GMSEC to provide the capabilities necessary to support integration of new software components into existing missions and increase the level of interaction within the system. For SMS, GMSEC has become the technology platform to transform flight operations with the innovation and automation necessary to reduce operational costs. The automation technologies supported in SMEX are built upon capabilities provided by the GMSEC architecture that allows the FOT to further reduce the involvement of the console, operator. Initially, SMEX is automating only routine operations, such as safety and health monitoring, basic commanding, and system recovery. The operational concepts being developed here will reduce the need for staffed passes and are a necessity for future fleet management. As this project continues to evolve, additional innovations beyond GMSEC and automation have, and will continue to be developed. The team developed techniques for migrating ground systems of existing on-orbit assets. The tools necessary to monitor and control software failures were integrated and tailored for operational environments. All this was done with a focus of extending fleet operations to mission beyond SMU. The result of this work is the foundation for a broader fleet-capable ground system that will include several missions supported by the Space Science Mission Operations Project.

Madden, Maureen↗

NASA NTRS2006

Lessons Learned from Engineering a Multi-Mission Satellite Operations Center

NASA's Small Explorers (SMEX) satellites have surpassed their designed science-lifetimes and their flight operations teams are now facing the challenge of continuing operations with reduced funding. At present, these missions are being re-engineered into a fleet-oriented ground system at Goddard Space Flight Center (GSFC). When completed, this ground system will provide command and control of four SMEX missions and will demonstrate fleet automation and control concepts. As a path-finder for future mission consolidation efforts, this ground system will also demonstrate new ground-based technologies that show promise of supporting longer mission lifecycles and simplifying component integration. One of the core technologies being demonstrated in the SMEX Mission Operations Center is the GSFC Mission Services Evolution Center (GMSEC) architecture. The GMSEC architecture uses commercial Message Oriented Middleware with a common messaging standard to realize a higher level of component interoperability, allowing for interchangeable components in ground systems. Moreover, automation technologies utilizing the GMSEC architecture are being evaluated and implemented to provide extended lights-out operations. This mode of operation will provide routine monitoring and control of the heterogeneous spacecraft fleet. The operational concepts being developed will reduce the need for staffed contacts and is seen as a necessity for fleet management. This paper will describe the experiences of the integration team throughout the re-enginering effort of the SMEX ground system. Additionally, lessons learned will be presented based on the team's experiences with integrating multiple missions into a fleet-automated ground system.

Madden, Maureen↗

NASA NTRS2005

Assemby, test, and launch operations for the Mars Exploration Rovers

In January of 2004, NASA's twin Mars rovers, Spirit and Opportunity, successfully landed on opposite sides of the Red Planet after a seven month Earth to Mars cruise period. Both vehicles have operated well beyond their 90 day primary mission design life requirements. The Assembly, Test, and Launch Operations (ATLO) program for these missions presented unique technical and schedule challenges to the team at the Jet Propulsion Laboratory (JPL). Among these challenges were a highly compressed schedule and late deliveries leading to extended double shift staffing, dual spacecraft operations requiring test program diversification and resource arbitration, multiple atypical test configurations for airbag/rocket landings and surface mobility testing, and verification of an exceptionally large number of separations, deployments, and mechanisms. This paper discusses the flight system test philosophies and approach, and presents lessons learned.

Assembly, Test, and Launch Operations (ATLO)↗