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.
Presentation for the LaRC HPC Community monthly meeting series. Overview of the uPSP measurements system(s) at ARC, with a focus on the processing software applications deployed at the ARC NAS Division.
Astrobiology missions to ocean worlds in our solar system must overcome both scientific and technological challenges due to extreme temperature and radiation conditions, long communication times, and limited bandwidth. While such tools could not replace ground-based analysis by science and engineering teams, machine learning algorithms could enhance the science return of these missions through development of autonomous science capabilities. Examples of science autonomy include onboard data analysis and subsequent instrument optimization, data prioritization (for transmission), and real-time decision-making based on data analysis. Similar advances could be made to develop streamlined data processing software for rapid ground-based analyses. Here we discuss several ways machine learning and autonomy could be used for astrobiology missions, including landing site selection, prioritization and targeting of samples, classification of “features” (e.g., proposed biosignatures) and novelties (uncharacterized, “new” features, which may be of most interest to agnostic astrobiological investigations), and data transmission.
Mars2020 (M2020) was formulated as a mission that leveraged as much Mars Science Laboratory (MSL) heritage as possible, while focusing major new development efforts on the original and unique elements needed to accomplish the different mission objectives. Well publicized examples of high profile new developments include precision landing, the sampling and caching system, the specific instrument suite, improved mobility via Autonomous Navigation, and later the addition of the Ingenuity helicopter. Less well known are the refinements to the core flight infrastructure, primarily in the cross-cutting functions of Telecom, Avionics, Data Management, Communications Behaviors, and Parameter Management. These enhancements are introduced predominately via flight software, and represent increases in capability that justified their inclusion in an otherwise heritage-focused project environment.Perseverance’s cross-cutting flight infrastructure improvements fall into and across the following five categories. First is a trimming of the software footprint of infrastructure modules, in order to make room for memory demands elsewhere in the system. Second is the minimization of data volume to be downlinked, through various methods such as the incorporation of new compression options. Third is the maximization of the available downlink bandwidth for data, by curtailing content-less data (fill) and introducing an improved UHF proximity link protocol. Fourth is a reduction in vulnerabilities, through increased file system redundancy, robustness, and software process monitoring. Fifth is an increase in operations efficiency by lowering file system mount times, improving parallelism between simultaneous events, minimizing the time to recover from file system errors, streamlining the purging of obsolete data, and reducing the number of commands to service parameters by a factor of 100.Individually, none of the cross-cutting infrastructure improvements are likely to garner headlines, but collectively they appreciably improve the safety and operability of Perseverance over its predecessor. This paper will describe the improvements, their promise, and where applicable, their actual impact in operations.
Contamination and degradation of external spacecraft materials by unburned and partially combusted species from bipropellant thruster plumes has long been observed as a key component of the induced space environment. Space shuttle flight experiments and returned flight hardware from the International Space Station (ISS) have both experienced microscopic impact features induced by high-velocity thruster plume droplets. Analytical results have shown that droplet impingement angle relative to a receiving surface plays a key role in the surface damage. Although impacts with normal impingement angles contribute more severely to surface degradation than highly oblique angles, surface effects at higher impingement angles should not be dismissed. Thruster plume-induced materials degradation is a complex phenomenon that depends on a variety of parameters, including but not limited to material type, system temperature and pressure, plume composition, and thruster firing specifications such as number of pulses, pulse duration, and sample distance from the thruster. For space applications, attaining the vacuum pressure and temperature conditions necessary for flight-like plume expansion and exposure conditions is not a trivial task. The German Aerospace Center (Deutsches Zentrum für Luft- und Raumfahrt, DLR) is a facility uniquely capable of simulating such conditions. Test coupons were exposed to bipropellant thruster firings under high vacuum at the DLR facility. Percent area coverage (PAC) and droplet size distributions were evaluated for the uncoated and coated solar array coverglass materials over a range of impingement angles (0̊ to 75̊). A post-test imaging workflow was developed that aimed to quantify changes in sample surface morphology obtained from scanning electron microscopy (SEM) images using the Image Processing and Analysis in Java (ImageJ) tool; an opensource image processing software. The goal was to create a framework through which to evaluate the effect of bipropellant-induced PAC and droplet size distribution on solar array coverglass optical transmission losses. Understanding this relationship is important because optical transmission losses are known to lead to current reduction in solar power generation systems. In addition to the development of surface characterization workflows, valuable lessons learned as they pertain to future investigations and experiments will be discussed. The authors hope that sharing these lessons will facilitate more utilization of DLR’s unique capabilities as well as open the conversation for how best to address experimental characterization of flight-like plume expansion and its impacts on materials surface degradation effects.
The Flight Dynamics Division (FDD) of NASA's Goddard Space Flight Center (GSFC) recently embarked on a far-reaching revision of its process for developing and maintaining satellite support software. The new process relies on an object-oriented software development method supported by a domain specific library of generalized components. This Generalized Support Software (GSS) Domain Engineering Process is currently in use at the NASA GSFC Software Engineering Laboratory (SEL). The key facets of the GSS process are (1) an architecture for rapid deployment of FDD applications, (2) a reuse asset library for FDD classes, and (3) a paradigm shift from developing software to configuring software for mission support. This paper describes the GSS architecture and process, results of fielding the first applications, lessons learned, and future directions
The process of geometric parameter estimation to accuracies of one centimeter, i.e., multilateration, is defined and applications are listed. A brief functional explanation of the theory is presented. Next, various multilateration systems are described in order of increasing system complexity. Expected systems accuracy is discussed from a general point of view and a summary of the errors is listed. An outline of the design of a software processing system for multilateration, called MICRODOT, is presented next. The links of this software, which can be used for multilateration data simulations or operational data reduction, are examined on an individual basis. Functional flow diagrams are presented to aid in understanding the software capability. MICRODOT capability is described with respect to vehicle configurations, interstation coordinate reduction, geophysical parameter estimation, and orbit determination. Numerical results obtained from MICRODOT via data simulations are displayed both for hypothetical and real world vehicle/station configurations such as used in the GEOS-3 Project. These simulations show the inherent power of the multilateration procedure.
Experience from a dozen years of analyzing software engineering processes and products is summarized as a set of software engineering and measurement principles that argue for software engineering process models that integrate sound planning and analysis into the construction process. In the TAME (Tailoring A Measurement Environment) project at the University of Maryland, such an improvement-oriented software engineering process model was developed that uses the goal/question/metric paradigm to integrate the constructive and analytic aspects of software development. The model provides a mechanism for formalizing the characterization and planning tasks, controlling and improving projects based on quantitative analysis, learning in a deeper and more systematic way about the software process and product, and feeding the appropriate experience back into the current and future projects. The TAME system is an instantiation of the TAME software engineering process model as an ISEE (integrated software engineering environment). The first in a series of TAME system prototypes has been developed. An assessment of experience with this first limited prototype is presented including a reassessment of its initial architecture.
Recent advances in image processing and new applications are presented to the user community to stimulate the development and transfer of this technology to industrial and commercial applications. The Proceedings contains 37 papers and abstracts, including many illustrations (some in color) and provides a single reference source for the user community regarding the ordering and obtaining of NASA-developed image-processing software and science data.
A model of a software development process is described. The software development process is seen to consist of a sequence of activities, such as 'program design' and 'module development' (or coding). A manpower estimate is made by multiplying code size by the rates (man months per thousand lines of code) for each of the activities relevant to the particular case of interest and summing up the results. The effect of four objectively determinable factors (organization, software product type, computer type, and code type) on productivity values for each of nine principal software development activities was assessed. Four factors were identified which account for 39% of the observed productivity variation.
The present paper describes several software techniques that can be used to get the 'most' out of an image without destroying or adding any information. A simple overview is given of a general image-processing system, a number of systems in current use are listed, and three types of processing tasks are delineated: image diagnostics, subjective enhancement, and quantitative restoration. Examples of each of these types are discussed in some detail, including histogram, differences, and Fourier analysis for image diagnostics; contrast stretching, edge enhancement, and pseudocolor displays for subjective enhancement; and photometric correction, contouring, and geometric correction for quantitative restoration.
This slide presentation reviews seven processes that NASA uses to ensure that software is developed, acquired and maintained as specified in the NPR 7150.2A requirement. The requirement is to ensure that all software be appraised for the Capability Maturity Model Integration (CMMI). The enumerated processes are: (7) Product Integration, (6) Configuration Management, (5) Verification, (4) Software Assurance, (3) Measurement and Analysis, (2) Requirements Management and (1) Planning & Monitoring. Each of these is described and the group(s) that are responsible is described.
Distributed software engineering techniques and methods for improving the specification and testing phases are considered. With multiversion development, multiple implementations allow the use of an automated approach to testing called back-to-back (B/B) testing in which the outputs are compared to detect any discrepancies. However, a specification defect may lead to similar errors in the multiple versions and the underlying fault may not be detected with a B/B testing approach. The use of diverse formal specifications has been proposed as a solution to this problem, since defects in independently written specifications are likely to be different. To examine these issues, an experiment was performed using the design diversity approach in the specification, design, implementation, and testing of distributed software. In the experiment, three diverse formal specifications were used to produce multiple independent implementations of a distributed communication protocol in Ada. The problems encountered in building complex concurrent processing systems in Ada were also studied. Many pitfalls were discovered in mapping the formal specifications into Ada implementations.
The processes followed to develop and test safety-critical flight software significantly increase development effort and overhead in comparison to both non-safety-critical and non-flight software. Generating code from models can be used to reduce development effort; however, the processes for using code generation to develop flight software are relatively immature. This work presents an approach for developing safety-critical flight software utilizing code generation from models to reduce development time and effort. The presented use-case is of electric aircraft motor control software developed for NASA's X-57 Maxwell aircraft.
Process interfaces are developed in an effort to reduce the time, effort, and money required to install computer systems. Probably the chief obstacle to the achievement of these goals lies in the problem of developing software handlers having the same degree of generality and modularity as the hardware. The problem of combining the advantages of modular instrumentation with those of modern multitask operating systems has not been completely solved, but there are a number of promising developments. The essential principles involved are considered.
In developing a software system, we would like to estimate the way in which the fault content changes during its development, as well determine the locations having the highest concentration of faults. In the phases prior to test, however, there may be very little direct information regarding the number and location of faults. This lack of direct information requires developing a fault surrogate from which the number of faults and their location can be estimated. We develop a fault surrogate based on changes in the fault index, a synthetic measure which has been successfully used as a fault surrogate in previous work. We show that changes in the fault index can be used to estimate the rates at which faults are inserted into a system between successive revisions. We can then continuously monitor the total number of faults inserted into a system, the residual fault content, and identify those portions of a system requiring the application of additional fault detection and removal resources.
In developing a software system, we would like to estimate the way in which the fault content changes during its development, as well determine the locations having the highest concentration of faults.
NASA and its industry and international partners are embarking on a bold and inspiring development effort to design and build an exploration class space system. The space system is made up of the Orion system, the Space Launch System (SLS) and the Ground Systems Development and Operations (GSDO) system. All are highly coupled together and dependent on each other for the combined safety of the space system. A key area of system safety focus needs to be in the ground and flight application software system (GFAS). In the development, certification and operations of GFAS, there are a series of safety characteristics that define the approach to ensure mission success. This paper will explore and examine the safety characteristics of the GFAS development. The GFAS system integrates the flight software packages of the Orion and SLS with the ground systems and launch countdown sequencers through the 'agile' software development process. A unique approach is needed to develop the GFAS project capabilities within this agile process. NASA has defined the software development process through a set of standards. The standards were written during the infancy of the so-called industry 'agile development' movement and must be tailored to adapt to the highly integrated environment of human exploration systems. Safety of the space systems and the eventual crew on board is paramount during the preparation of the exploration flight systems. A series of software safety characteristics have been incorporated into the development and certification efforts to ensure readiness for use and compatibility with the space systems. Three underlining factors in the exploration architecture require the GFAS system to be unique in its approach to ensure safety for the space systems, both the flight as well as the ground systems. The first are the missions themselves, which are exploration in nature, and go far beyond the comfort of low Earth orbit operations. The second is the current exploration system will launch only one mission per year even less during its developmental phases. Finally, the third is the partnered approach through the use of many different prime contractors, including commercial and international partners, to design and build the exploration systems. These three factors make the challenges to meet the mission preparations and the safety expectations extremely difficult to implement. As NASA leads a team of partners in the exploration beyond earth's influence, it is a safety imperative that the application software used to test, checkout, prepare and launch the exploration systems put safety of the hardware and mission first. Software safety characteristics are built into the design and development process to enable the human rated systems to begin their missions safely and successfully. Exploration missions beyond Earth are inherently risky, however, with solid safety approaches in both hardware and software, the boldness of these missions can be realized for all on the home planet.
Information for personnel with programming backgrounds to understand and follow the logic of the software which supports the IDAPS system hardware configuration is presented.