SEARCH · Engineering Papers
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.
Correlation efforts and selected results for transonic drag are reviewed. A process to reduce the typical error sources to decrease the errors inherent in the transonic aircraft development process is summarized.
Robert Holibaugh of the Software Engineering Institute described a project which is studying the application of reusable software components. The primary goals are to gain practical experience with state-of-the-art reusable components, methods, and tools and to capture the lessons learned in the application of reuse technology. In addition the project will assess the impact of reuse on the software development process and products and will identify and validate the information that facilities software reuse during system development. The project includes two tasks - a reuse experiment and a redevelopment effort. The reuse experiment will define a life cycle and a methodology for reuse-based development, and define and implement a data collection mechanism for measuring the development. The redevelopment effort will construct a reuse test bed and will redevelop and realistically test subsystems from an embedded mission-critical real-time application. The reuse experiment will produce several products including a tested real-time application, reuse-based components and tools evaluation, a reuse-based development method, a framework for data collection, a framework for measuring productivity, and lessons learned data. Successful development with reusable components will require a rich set of components and an integrating methodology. The Tomahawk Land Attack Missile system is the application for the redevelopment effort.
This document defines the software developed by the SAO AXAF Mission Support (MS) Program and defines standards for the software development process and control of data products generated by the software. The SAO MS is tasked to develop and use software to perform a variety of functions in support of the AXAF mission. Software is developed by software engineers and scientists, and commercial off-the-shelf (COTS) software is used either directly or customized through the use of scripts to implement analysis procedures. Software controls real-time laboratory instruments, performs data archiving, displays data, and generates model predictions. Much software is used in the analysis of data to generate data products that are required by the AXAF project, for example, on-orbit mirror performance predictions or detailed characterization of the mirror reflection performance with energy.
Mathematical model of variable-polarity plasma arc (VPPA) welding process developed for use in predicting characteristics of welds and thus serves as guide for selection of process parameters. Parameters include welding electric currents in, and durations of, straight and reverse polarities; rates of flow of plasma and shielding gases; and sizes and relative positions of welding electrode, welding orifice, and workpiece.
Because of our present inability to produce error-free software, software fault tolerance is and will continue to be an important consideration in software systems. The root cause of software design errors is the complexity of the systems. Compounding the problems in building correct software is the difficulty in assessing the correctness of software for highly complex systems. After a brief overview of the software development processes, we note how hard-to-detect design faults are likely to be introduced during development and how software faults tend to be state-dependent and activated by particular input sequences. Although component reliability is an important quality measure for system level analysis, software reliability is hard to characterize and the use of post-verification reliability estimates remains a controversial issue. For some applications software safety is more important than reliability, and fault tolerance techniques used in those applications are aimed at preventing catastrophes. Single version software fault tolerance techniques discussed include system structuring and closure, atomic actions, inline fault detection, exception handling, and others. Multiversion techniques are based on the assumption that software built differently should fail differently and thus, if one of the redundant versions fails, it is expected that at least one of the other versions will provide an acceptable output. Recovery blocks, N-version programming, and other multiversion techniques are reviewed.
Program analysis techniques and tools are essential to the development process because of the support they provide in detecting errors and deficiencies at different phases of development. The types of information rendered through analysis includes the following: statistical measurements of code, type checks, dataflow analysis, consistency checks, test data,verification of code, and debugging information. Analyzers can be broken into two major categories: dynamic and static. Static analyzers examine programs with respect to syntax errors and structural properties., This includes gathering statistical information on program content, such as the number of lines of executable code, source lines. and cyclomatic complexity. In addition, static analyzers provide the ability to check for the consistency of programs with respect to variables. Dynamic analyzers in contrast are dependent on input and the execution of a program providing the ability to find errors that cannot be detected through the use of static analysis alone. Dynamic analysis provides information on the behavior of a program rather than on the syntax. Both types of analysis detect errors in a program, but dynamic analyzers accomplish this through run-time behavior. This paper focuses on the following broad classification of dynamic analyzers: 1) Metrics; 2) Models; and 3) Monitors. Metrics are those analyzers that provide measurement. The next category, models, captures those analyzers that present the state of the program to the user at specified points in time. The last category, monitors, checks specified code based on some criteria. The paper discusses each classification and the techniques that are included under them. In addition, the role of each technique in the software life cycle is discussed. Familiarization with the tools that measure, model and monitor programs provides a framework for understanding the program's dynamic behavior from different, perspectives through analysis of the input/output data.
The Mars Science Laboratory (MSL) team is sending the rover, Curiosity, to Mars, and therefore is physically and technically complex. During my stay, I have assisted the MSL Flight Software (FSW) team in implementing functional test scripts to ensure that the FSW performs to the best of its abilities. There are a large number of FSW requirements that have been written up for implementation; however I have only been assigned a few sections of these requirements. There are many stages within testing; one of the early stages is FSW Internal Testing (FIT). The FIT team can accomplish this with simulation software and the MSL Test Automation Kit (MTAK). MTAK has the ability to integrate with the Software Simulation Equipment (SSE) and the Mission Processing and Control System (MPCS) software which makes it a powerful tool within the MSL FSW development process. The MSL team must ensure that the rover accomplishes all stages of the mission successfully. Due to the natural complexity of this project there is a strong emphasis on testing, as failure is not an option. The entire mission could be jeopardized if something is overlooked.
The 6U (approximately 10cm x 20cm x 30cm) cubesat Near Earth Asteroid (NEA) Scout1, projected for launch in September 2018 aboard the maiden voyage of the Space Launch System (SLS), will utilize a solar sail as its main method of propulsion throughout its approximately 3 year mission to a Near Earth Asteroid (NEA). Due to the extreme volume constraints levied onto the mission, an acutely compact solar sail deployment mechanism has been designed to meet the volume and mass constraints, as well as provide enough propulsive solar sail area and quality in order to achieve mission success. The design of such a compact system required the development of approximately half a dozen prototypes in order to identify unforeseen problems, advance solutions, and build confidence in the final design product. This paper focuses on the obstacles of developing a solar sail deployment mechanism for such an application and the lessons learned from a thorough development process. The lessons presented will have significant applications beyond the NEA Scout mission, such as the development of other deployable boom mechanisms and uses for gossamer-thin films in space.
The 6U (approx.10 cm x 20 cm x 30 cm) cubesat Near Earth Asteroid (NEA) Scout1, projected for launch in September 2018 aboard the maiden voyage of the Space Launch System, will utilize a solar sail as its main method of propulsion throughout its approx.3-year mission to a Near Earth Asteroid. Due to the extreme volume constraints levied onto the mission, an acutely compact solar sail deployment mechanism has been designed to meet the volume and mass constraints, as well as provide enough propulsive solar sail area and quality in order to achieve mission success. The design of such a compact system required the development of approximately half a dozen prototypes in order to identify unforeseen problems, advance solutions, and build confidence in the final design product. This paper focuses on the obstacles of developing a solar sail deployment mechanism for such an application and the lessons learned from a thorough development process. The lessons presented will have significant applications beyond the NEA Scout mission, such as the development of other deployable boom mechanisms and uses for gossamer-thin films in space.
The framework is defined for a general method for selecting a necessary and sufficient subset of a general software life cycle's information products, to support new software development process. Procedures for characterizing problem domains in general and mapping to a tailored set of life cycle processes and products is presented. An overview of the method is shown using the following steps: (1) During the problem concept definition phase, perform standardized interviews and dialogs between developer and user, and between user and customer; (2) Generate a quality needs profile of the software to be developed, based on information gathered in step 1; (3) Translate the quality needs profile into a profile of quality criteria that must be met by the software to satisfy the quality needs; (4) Map the quality criteria to set of accepted processes and products for achieving each criterion; (5) Select the information products which match or support the accepted processes and product of step 4; and (6) Select the design methodology which produces the information products selected in step 5.
The framework is defined for a general method for selecting a necessary and sufficient subset of a general software life cycle's information products, to support new software development process. Procedures for characterizing problem domains in general and mapping to a tailored set of life cycle processes and products is presented. An overview of the method is shown using the following steps: (1) During the problem concept definition phase, perform standardized interviews and dialogs between developer and user, and between user and customer; (2) Generate a quality needs profile of the software to be developed, based on information gathered in step 1; (3) Translate the quality needs profile into a profile of quality criteria that must be met by the software to satisfy the quality needs; (4) Map the quality criteria to a set of accepted processes and products for achieving each criterion; (5) select the information products which match or support the accepted processes and product of step 4; and (6) Select the design methodology which produces the information products selected in step 5.
This paper describes the achievements made on the Advanced Solid Rocket Motor (ASRM) case insulation design and development program. The ASRM case insulation system described herein protects the metal case and joints from direct radiation and hot gas impingement. Critical failure of solid rocket systems is often traceable to failure of the insulation design. The wide ranging accomplishments included the development of a nonasbestos insulation material for ASRM that replaced the existing Redesigned Solid Rocket Motor (RSRM) asbestos-filled nitrile butadiene rubber (NBR) along with a performance gain of 300 pounds, and improved reliability of all the insulation joint designs, i.e., segmented case joint, case-to-nozzle and case-to-igniter joint. The insulation process development program included the internal stripwinding process. This process advancement allowed Aerojet to match to exceed the capability of other propulsion companies.
The development of the Apollo digital autopilots (the primary attitude control systems that were used for all phases of the lunar landing mission) is summarized. This report includes design requirements, design constraints, and design philosophy. The development-process functions and the essential information flow paths are identified. Specific problem areas that existed during the development are included. A discussion is also presented on the benefits inherent in mechanizing attitude-controller logic and dynamic compensation in a digital computer.
Prior to determining what Solid Waste Management (SWM) technologies should be researched and developed by the Advanced Life Support (ALS) Project for future missions, there is a need to define SWM requirements. Because future waste streams will be highly mission-dependent, missions need to be defined prior to developing SWM requirements. The SWM Working Group has used the mission architecture outlined in the System Integration, Modeling and Analysis (SIMA) Element Reference Missions Document (RMD) as a starting point in the requirement development process. The missions examined include the International Space Station (ISS), a Mars Dual Lander mission, and a Mars Base. The SWM Element has also identified common SWM functionalities needed for future missions. These functionalities include: acceptance, transport, processing, storage, monitoring and control, and disposal. Requirements in each of these six areas are currently being developed for the selected missions. This paper reviews the results of this ongoing effort and identifies mission-dependent resource recovery requirements.
Over the past six decades, satellite remote sensing technology has contributed to the transformation of using earth science not only to advance science, but to improve quality of life. With satellite missions launched almost every year, new types of earth science data are being incorporated into science, models and decision-making systems in a broad array of organizations. A challenge for space agencies has been ensuring that satellite missions serve both the scientific community and the applied community of decision makers without the missions becoming unfocused and overly expensive. By understanding and considering the needs of the environmental data and applied research user community early on in the mission-design process, agencies can ensure that satellites meet the needs of multiple constituencies. This paper describes the mission development process in the European Space Agency and the National Aeronautics and Space Administration and compares and contrasts the successes of and challenges faced by these agencies in balancing science and applications within their missions.
Satellite remote sensing technology has contributed to the transformation of multiple earth science domains, putting space observations at the forefront of innovation in earth science. With new satellite missions being launched every year, new types of earth science data are being incorporated into science models and decision-making systems in a broad array of organizations. Policy guidance can influence the degree to which user needs influence mission design and when, and ensure that satellite missions serve both the scientific and user communities without becoming unfocused and overly expensive. By considering the needs of the user community early on in the mission-design process, agencies can ensure that satellites meet the needs of multiple constituencies. This paper describes the mission development process in NASA and ESA and compares and contrasts the successes and challenges faced by these agencies as they try to balance science and applications within their missions.
In 2013, the Human Research Program at NASA began developing a new confinement analog specifically for conducting research to investigate the effects of confinement on the human system. The HERA (Human Exploration Research Analog) habitat has been used for both 7 and 14 day missions to date to examine and mitigate exploration risks to enable safe, reliable and productive human space exploration. This presentation will describe how the Flight Analogs Project developed the HERA facility and the infrastructure to suit investigator requirements for confinement research and in the process developed a new approach to analog utilization and a new state of the art analog facility. Details regarding HERA operations will be discussed including specifics on the mission simulation utilized for the current 14-day campaign, the specifics of the facility (total volume, overall size, hardware), and the capabilities available to researchers. The overall operational philosophy, mission fidelity including timeline, schedule pressures and cadence, and development and implementation of mission stressors will be presented. Research conducted to date in the HERA has addressed risks associated with behavioral health and performance, human physiology, as well as human factors. This presentation will conclude with a discussion of future research plans for the HERA, including infrastructure improvements and additional research capabilities planned for the upcoming 30-day missions in 2016.
The NASA DEVELOP National Program seeks to simultaneously build capacity to use Earth observations in early career and transitioning professionals while building capacity with institutional partners to apply Earth observations in conducting operations, making decisions, or informing policy. This is done through 10-week feasibility projects, conducted by the DEVELOP teams in collaboration with decision makers. The program carries out 60-80 projects each year, engaging with over 120 partners from local, state, and federal governments to academic institutions and NGOs. To best understand project partner needs, projects begin with a thorough proposal development process in which partners share their current practices, needs, and capabilities. Throughout the project life cycle, the DEVELOP teams engage with the partners to ensure communication, feedback, and understanding. DEVELOP’s model of conducting rapid feasibility projects is an effective way to show decision maker show they can use NASA Earth science data in new ways to help them make informed decisions. Because the projects are conducted by a DEVELOP team in collaboration with end users, the partners are introduced to new data products and methodologies that they otherwise might not be able to explore within their own resource constraints. This presentation will discuss project examples, success stories, and best practices for engaging with decision makers on applied science projects.