Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “custom”

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 199 records · Page 11
All sourcesNASA NTRSDOE OSTI
NASA NTRS1994

Customizing the JPL Multimission Ground Data System: Lessons Learned

This paper will describe lessons learned in adapting JPL's Multimission Ground Data System (MGDS) to fly the Voyager, Galileo, and Mars Observer missions. We will explain how powerful, existing ground data systems can be adapted and packaged in a cost effective way for operations of small and large planetary missions. We will also describe how the MGDS was adapted to support operations within the Galileo Spacecraft Testbed. The Galileo testbed provided a unique opportunity to adapt MGDS to support command and control operations for a small autonomous operations team with a handful of engineers flying the Galileo Spacecraft flight system model.

ground↗
NASA NTRS2021

Customized Science Carrier Modules and Accessories Developed for Microgravity Simulation Devices

Because the access to the true weightless environment of the ISS and other Low Earth Orbit (LEO) vehicles is limited and cost prohibitive, the need for ground-based microgravity simulation analogs to bridge the gravity continuum gap between 1g gravity and costly space flight studies with true weightlessness was realized. As such, the Microgravity Simulation Support Facility (MSSF) was established at NASA John F. Kennedy Space Center (KSC) to fulfill the need of the scientific community. Our facility provides the US science community with a focal point in the field of gravitational research by granting access to an array of two-dimensional(2D) and three-dimensional (3D)clinostats, and Random Positioning Machine (RPM) platforms developed by teams throughout the world. The availability of these capabilities will allow further understanding the role of altered gravity vectors from “functional weightlessness”, partial gravity conditions (1 x 10-3to 0.9g, and Moon and Mars ‘g vectors), to hypergravity (up to3g) on biological processes. We have designed and 3D printed a variety of specialized attachments(and associated “static control” hardware)to allow researchers to mount their samples onto these microgravity simulation devices to meet their unique science requirements. A summary of each attachment module will be presented below. Note: All software or code information should be requested to the author Ye Zhang, Kennedy Space Center ye.zhang-1@nasa.gov

Ye Zhang↗
NASA NTRSDate not supplied

Goes-16 On-Station Custom Maneuver Generation with Focussuite

This paper discusses the process of the NOAA GOES Mission Operations Support Team (MOST) in mitigating the effects of inconsistently performing ArcJet Thrusters (AJTs) aboard the GOES-16 spacecraft in geostationary orbit. These AJTs are hot-gas thrusters which augment the gas flow using an electric arc to increase the exit velocity of the gases. Fuel flow problems have led to GOES-16 being unable to safely use its AJTs for maneuvers at times. This primarily affects North/South Station-Keeping (NSSK) maneuvers, which control inclination and use a majority of the station-keeping fuel budget. As a result, GOES-16 has had to occasionally resort to using non-AJT hot-gas thrusters. These thrusters are not placed as close to GOES-16's centerline, have lower thrust, and have lower specific impulse when compared to AJTs. In addition, MOST’s ground systems do not officially support using these non-AJT thrusters for NSSK maneuvers. MOST had to quickly develop workaround solutions using the FocusSuite Autofocus programming environment to compute the maneuvers. This paper outlines the mixture of commercial off-the-shelf (COTS) and MOST-developed products which have allowed GOES-16 to continue station-keeping even with inconsistently-per-forming AJTs, showing that script-based automation systems like Autofocus can simplify complex solutions to a few scripted user inputs.

Henry Heim↗
NASA NTRS2022

Wallops Flight Facility Integration and Testing Customer Handbook

The Wallops Integration and Testing Handbook is a guide for planning operations at Wallops testing facilities. It provides a summary of the capabilities and technical specifications of available facilities. This handbook prescribes the information to be provided by the user that will enable the integration and testing team to effectively plan for and support the facility user’s project. Note that each facility plans for availability based on current workloads/ mission schedules. For example, sounding rockets may have between 20 and 35 missions in work at one time. Also note that special training, such as cleanroom certification, electrostatic discharge (ESD) or confined space training may be required for entrance to some facilities.

Adam Hammoudi↗
NASA NTRS2024

Runtime Thread-Block Optimization for Custom Multistream CUDA Kernels for the Glenn Research Center Communication Analysis Suite

In preparation of the return of humans to the Moon with the coming Artemis missions, NASA scientists must evaluate proposed landing site locations for terrain and communications viability. The Glenn Research Center Communication Analysis Suite (GCAS) combines sophisticated communication network models with accurate lunar terrain to access sites across the Moon’s south pole. Given the importance of proper site selection to crew safety and mission success, many locations need to be analyzed resulting in a large computational load needing to be performed. To meet the growing project demands, development has begun to improve the runtime efficiency of GCAS with GPU parallelization by way of multi-stream CUDA kernels. One of the most prominent factors in kernel optimization is the proper selection of thread-block dimensions in order to maximize the concurrent operation on the device. Typically, thread-block dimensions are optimized by hand requiring many stages of benchmarking and iteration. Additionally, given the main conditions to optimization are the physical GPU architecture and problem size, these optimal dimensions are non-portable and fragile in their scope. As such, a novel optimization routine was developed to generate the optimal thread-block dimensions during runtime with considerations to hardware specifications and problem size resolving the issues of portability and enabling the function of more dynamic routines.

Aden Bergstresser↗
NASA NTRS1998

Issues and Methods for Assessing COTS Reliability, Maintainability, and Availability

Many vendors produce products that are not domain specific (e.g., network server) and have limited functionality (e.g., mobile phone). In contrast, many customers of COTS develop systems that am domain specific (e.g., target tracking system) and have great variability in functionality (e.g., corporate information system). This discussion takes the viewpoint of how the customer can ensure the quality of COTS components. In evaluating the benefits and costs of using COTS, we must consider the environment in which COTS will operate. Thus we must distinguish between using a non-mission critical application like a spreadsheet program to produce a budget and a mission critical application like military strategic and tactical operations. Whereas customers will tolerate an occasional bug in the former, zero tolerance is the rule in the latter. We emphasize the latter because this is the arena where there are major unresolved problems in the application of COTS. Furthermore, COTS components may be embedded in the larger customer system. We refer to these as embedded systems. These components must be reliable, maintainable, and available, and must be with the larger system in order for the customer to benefit from the advertised advantages of lower development and maintenance costs. Interestingly, when the claims of COTS advantages are closely examined, one finds that to a great extent these COTS components consist of hardware and office products, not mission critical software [1]. Obviously, COTS components are different from custom components with respect to one or more of the following attributes: source, development paradigm, safety, reliability, maintainability, availability, security, and other attributes. However, the important question is whether they should be treated differently when deciding to deploy them for operational use; we suggest the answer is no. We use reliability as an example to justify our answer. In order to demonstrate its reliability, a COTS component must pass the same reliability evaluations as the custom components, otherwise the COTS components will be the weakest link in the chain of components and will be the determinant of software system reliability. The challenge is that there will be less information available for evaluating COTS components than for custom components but this does not mean we should despair and do nothing. Actually, there is a lot we can do even in the absence of documentation on COTS components because the customer will have information about how COTS components are to be used in the larger system. To illustrate our approach, we will consider the reliability, maintainability, and availability (RMA) of COTS components as used in larger systems. Finally, COTS suppliers might consider increasing visibility into their products to assist customers in determining the components' fitness for use in a particular application. We offer ideas of information that would be useful to customers, and what vendors might do to provide it.

Schneidewind, Norman F.↗
NASA NTRS2009

Extreme Programming: Maestro Style

"Extreme Programming: Maestro Style" is the name of a computer programming methodology that has evolved as a custom version of a methodology, called extreme programming that has been practiced in the software industry since the late 1990s. The name of this version reflects its origin in the work of the Maestro team at NASA's Jet Propulsion Laboratory that develops software for Mars exploration missions. Extreme programming is oriented toward agile development of software resting on values of simplicity, communication, testing, and aggressiveness. Extreme programming involves use of methods of rapidly building and disseminating institutional knowledge among members of a computer-programming team to give all the members a shared view that matches the view of the customers for whom the software system is to be developed. Extreme programming includes frequent planning by programmers in collaboration with customers, continually examining and rewriting code in striving for the simplest workable software designs, a system metaphor (basically, an abstraction of the system that provides easy-to-remember software-naming conventions and insight into the architecture of the system), programmers working in pairs, adherence to a set of coding standards, collaboration of customers and programmers, frequent verbal communication, frequent releases of software in small increments of development, repeated testing of the developmental software by both programmers and customers, and continuous interaction between the team and the customers. The environment in which the Maestro team works requires the team to quickly adapt to changing needs of its customers. In addition, the team cannot afford to accept unnecessary development risk. Extreme programming enables the Maestro team to remain agile and provide high-quality software and service to its customers. However, several factors in the Maestro environment have made it necessary to modify some of the conventional extreme-programming practices. The single most influential of these factors is that continuous interaction between customers and programmers is not feasible.

Norris, Jeffrey↗
NASA NTRS1993

New mission requirements methodologies for services provided by the Office of Space Communications

The Office of Space Communications, NASA Headquarters, has recently revised its methodology for receiving, accepting and responding to customer requests for use of that office's tracking and communications capabilities. This revision is the result of a process which has become over-burdened by the size of the currently active and proposed missions set, requirements reviews that focus on single missions rather than on mission sets, and negotiations most often not completed early enough to effect needed additions to capacity or capability prior to launch. The requirements-coverage methodology described is more responsive to project/program needs and provides integrated input into the NASA budget process early enough to effect change, and describes the mechanisms and tools in place to insure a value-added process which will benefit both NASA and its customers. Key features of the requirements methodology include the establishment of a mechanism for early identification of and systems trades with new customers, and delegates the review and approval of requirements documents to NASA centers in lieu of Headquarters, thus empowering the system design teams to establish and negotiate the detailed requirements with the user. A Mission Requirements Request (MRR) is introduced to facilitate early customer interaction. The expected result is that the time to achieve an approved set of implementation requirements which meet the customer's needs can be greatly reduced. Finally, by increasing the discipline in requirements management, through the use of base lining procedures, a tighter coupling between customer requirements and the budget is provided. A twice-yearly projection of customer requirements accommodation, designated as the Capacity Projection Plan (CPP), provides customer feedback allowing the entire mission set to be serviced.

Holmes, Dwight P.↗
NASA NTRS1994

Human factors involvement in bringing the power of AI to a heterogeneous user population

The Human Factors involvement in developing COMPAQ QuickSolve, an electronic problem-solving and information system for Compaq's line of networked printers, is described. Empowering customers with expert system technology so they could solve advanced networked printer problems on their own was a major goal in designing this system. This process would minimize customer down-time, reduce the number of phone calls to the Compaq Customer Support Center, improve customer satisfaction, and, most importantly, differentiate Compaq printers in the marketplace by providing the best, and most technologically advanced, customer support. This represents a re-engineering of Compaq's customer support strategy and implementation. In its first generation system, SMART, the objective was to provide expert knowledge to Compaq's help desk operation to more quickly and correctly answer customer questions and problems. QuickSolve is a second generation system in that customer support is put directly in the hands of the consumers. As a result, the design of QuickSolve presented a number of challenging issues. Because the produce would be used by a diverse and heterogeneous set of users, a significant amount of human factors research and analysis was required while designing and implementing the system. Research that shaped the organization and design of the expert system component as well.

Czerwinski, Mary↗
NASA NTRS1991

Retrievable Payload Carrier (RPC): Next generation Long Duration Exposure Facility

The Retrievable Payload Carrier (RPC) is described which is a multi-experiment, free-flyer spacecraft being privately developed to make in-space experimentation more accessible and economically feasible for research and development organizations. The carrier concept was derived from NASA's highly successful and flight proven Long Duration Exposure Facility (LDEF). The LDEF capabilities were enhanced to meet new customer requirements. This reusable payload carrier is planned for launch and retrieval by the space shuttle on a regular basis. The RPC's compact design facilitates flexible manifesting of the shuttle cargo bay space, thereby, permitting timely launches and retrievals. The vehicle is designed so that either the entire carrier can be retrieved from orbit, or individual experiment pallets can be removed and replaced in orbit. This gives customers even greater control over their experiment recoveries. A fully operational RPC System consists of: (1) a carrier spacecraft; (2) a ground control station for communication with customer payloads and the carrier; (3) a ground processing facility to provide refurbishment, final checkout, and integration of customer payloads and the carrier; and (4) the personnel required to support both the development and operation phases of the program. Customer payloads will fly 6 to 18 month missions, or longer, as required. Spreading launch, operations, and retrieval costs over multiple experimental payloads results in minimized customer costs. The RPC Program's initial objective is to operate a simple carrier system which meets basic customer service needs.

Perry, Arthur T.↗
NASA NTRS2002

Cross-Cultural Perspectives of Service Quality and Risk in Air Transportation

This study compares US and Korean customers in terms of their perceptions of airline service quality based on SERVPERF and industry-based measures, as well as their perceptions of risks involved in the airline choice. SERVPERF is a set of multi-dimensional measures of customer evaluations of service quality. The results indicate that: (1) US passengers are generally more satisfied with their airline service than Korean customers on most of the SERVPERF dimensions; (2) Koreans are generally more satisfied with the bumping procedures whereas US participants feel more satisfied with the airline's baggage handling, operations/safety, and connections; and (3) US participants perceive higher levels of performance and financial risks whereas Koreans feel greater social risk in choosing an airline. This study also examines the SERVPERF, industry-based measure, and perceived risk in predicting customer satisfaction with, and intention to repatronize the airline. The results suggest that US customers consider service reliability, in-flight comfort, and connections as the key factors determining satisfaction with airline service whereas Korean passengers generally regard reliability, assurance, and risk factors as predictors of satisfaction. The determining factors of customer intention to repatronize the airline are reliability and empathy for US, and reliability and overall risk for Korean customers. The study demonstrates the applicability of SERVPERF as a cross-cultural tool and indicates the importance of perceived risk in cross-cultural studies.

Cunningham, Lawrence F.↗