SEARCH · Search NASA
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.
Continued verification, validation, and improvement of Distant Observer software for quality control of newly installed parabolic troughs. Besides specific trough adjustments, the potential for improvements to the software speed, user interface, and photogrammetry algorithms will be improved.
It is critically important in any improvement activity to first understand the organization's current status, strengths, and weaknesses and, only after that understanding is achieved, examine and implement promising improvements. This fundamental rule is certainly true for an organization seeking to further its software viability and effectiveness. This paper addresses the role of the organizational process baseline in a software improvement effort and the lessons we learned assembling such an understanding for NASA overall and for the NASA Goddard Space Flight Center in particular. We discuss important, core data that must be captured and contrast that with our experience in actually finding such information. Our baselining efforts have evolved into a set of data gathering, analysis, and crosschecking techniques and information presentation formats that may prove useful to others seeking to establish similar baselines for their organization.
This report contains the source code and documentation for a computer program used to process impedance cardiography data. The cardiodynamic measures derived from impedance cardiography are ventricular stroke column, cardiac output, cardiac index and Heather index. The program digitizes data collected from the Minnesota Impedance Cardiograph, Electrocardiography (ECG), and respiratory cycles and then stores these data on hard disk. It computes the cardiodynamic functions using interactive graphics and stores the means and standard deviations of each 15-sec data epoch on floppy disk. This software was designed on a Digital PRO380 microcomputer and used version 2.0 of P/OS, with (minimally) a 4-channel 16-bit analog/digital (A/D) converter. Applications software is written in FORTRAN 77, and uses Digital's Pro-Tool Kit Real Time Interface Library, CORE Graphic Library, and laboratory routines. Source code can be readily modified to accommodate alternative detection, A/D conversion and interactive graphics. The object code utilizing overlays and multitasking has a maximum of 50 Kbytes.
New features have been added to IODA to support testing of lightweight optics. Algorithms have been developed to predict actuator influence functions and positions to correct for gravity loading effects. New features have also been added to import measured test data and to compare measured data with predicted data.
Radiation encountered in space environments can be damaging to microelectronics and potentially cause spacecraft failure. Single event effects (SEE) are a type of radiation effect that occur when an ion strikes a device. Single event gate rupture (SEGR) is a type of SEE that can cause failure in power transistors. Unlike other SEE rates in which a constant linear energy transfer (LET) can be used, SEGR rates sometimes require a non-uniform LET to be used to be accurate. A recent analysis shows that SEGR rates are most easily calculated when the environment is described as a stopping rate per unit volume for each ion species. Stopping rates in silicon for pertinent ions were calculated using the Stopping and Range of Ions in Matter (SRIM) software and CREME-MC software. A reference table was generated and can be used by others to calculate SEGR rates for a candidate device. Additionally, lasers can be used to simulate SEEs, providing more control and information at lower cost than heavy ion testing. The electron/hole pair generation rate from a laser pulse in a semiconductor can be related to the LET of an ion. MATLAB was used to generate a plot to easily make this comparison.
In order to overcome spatial resolution limitations associated with physical sensor limitations when using smallsats and cubesats, we utilize an image processing technology referred to as Super-Resolution (SR). In general, software approaches are increasingly considered in connection with smaller satellites for which size, mass and power constraints limit the sensor capabilities. Being able to perform hardware vs. software trades might enable more capabilities for a lower cost. This paper describes recent experiments conducted to optimize the spatial enhancement of acquired observations using multiple sub-pixel shifted low resolution image.
A series of efforts have been devoted to investigating methods of porting and parallelizing applications quickly and efficiently for new architectures, such as the SCSI Origin 2000 and Cray T3E. This report presents the parallelization of a CFD application, ARC3D, using the computer-aided tools, Cesspools. Steps of parallelizing this code and requirements of achieving better performance are discussed. The generated parallel version has achieved reasonably well performance, for example, having a speedup of 30 for 36 Cray T3E processors. However, this performance could not be obtained without modification of the original serial code. It is suggested that in many cases improving serial code and performing necessary code transformations are important parts for the automated parallelization process although user intervention in many of these parts are still necessary. Nevertheless, development and improvement of useful software tools, such as Cesspools, can help trim down many tedious parallelization details and improve the processing efficiency.
The studies discussed in this paper are all examples of activities that are performed as part of the Software Engineering Laboratory's (SEL's) process improvement model. Using this model, the SEL starts by understanding the product and process, then assesses the impact of new technologies, and finally packages what was learned. The preliminary examination of maintenance effort, error, and change profiles to establish a maintenance baseline exemplifies understanding-phase activities. The ongoing testing study that is examining the effects of various testing approaches on process and product measures is an example of typical assessing efforts. Finally, the derivation of cost and schedule estimation models from locally driven factors such as reuse level, application type, and language is an example of experience packaging. In the SEL, no study is ever really completed. Studies will be repeated and iterated upon in the future as part of the ongoing software improvement process.
A set or programs designed to facilitate software testing on the DATAC Bus Monitor is described. By providing a means to simplify program loading, firmware generation, and subsequent testing of programs, the overhead involved in software evaluation is reduced and that time is used more productively in performance, analysis and improvement of current software.
A cognitive engineering analysis of the Flight Management System (FMS) Vertical Navigation (VNAV) function has identified overloading of the VNAV button and overloading of the Flight Mode Annunciator (FMA) used by the VNAV function. These two types of overloading, resulting in modal input devices and ambiguous feedback, are well known sources of operator confusion, and explain, in part, the operational issues experienced by airline pilots using VNAV in descent and approach. A proposal to modify the existing VNAV design to eliminate the overloading is discussed. The proposed design improves pilot's situational awareness of the VNAV function, and potentially reduces the cost of software development and improves safety.
Ascent flight envelopes are trajectories that define the normal operating region of a space vehicle s position from liftoff until the end of powered flight. They fulfill part of the RS data requirements imposed by the Air Force s 45th Space Wing (45SW) on space vehicles launching from the Eastern Range (ER) in Florida. The 45SW is chartered to protect the public by minimizing risks associated with the inherent hazards of launching a vehicle into space. NASA s Space Shuttle program has launched 130+ manned missions over a 30 year period from the ER. Ascent envelopes were delivered for each of those missions. The 45SW envelope requirements have remained largely unchanged during this time. However, the methodology and design processes used to generate the envelopes have evolved over the years to support mission changes, maintain high data quality, and reduce costs. The evolution of the Shuttle envelope design has yielded lessons learned that can be applied to future endevours. There have been numerous Shuttle ascent design enhancements over the years that have caused the envelope methodology to evolve. One of these Shuttle improvements was the introduction of onboard flight software changes implemented to improve launch probability. This change impacted the preflight nominal ascent trajectory, which is a key element in the RS envelope design. While the early Shuttle nominal trajectories were designed preflight using a representative monthly mean wind, the new software changes involved designing a nominal ascent trajectory on launch day using real-time winds. Because the actual nominal trajectory position was not known until launch day, the envelope analysis had to be customized to account for this nominal trajectory variation in addition to the other envelope components.
In order to improve productivity (and quality), measurement of specific aspects of software has become imperative. As object oriented programming languages have become more widely used, metrics designed specifically for object-oriented software are required. Recently a large number of new metrics for object- oriented software has appeared in the literature. Unfortunately, many of these proposed metrics have not been validated to measure what they purport to measure. In this paper fifty (50) of these metrics are analyzed.
Robonaut, NASA's humanoid robot, is designed to work as both an astronaut assistant and, in certain situations, an astronaut surrogate. This highly dexterous robot performs complex tasks under telepresence control that could previously only be carried out directly by humans. Currently with 47 degrees of freedom (DOF), Robonaut is a state-of-the-art human size telemanipulator system. while many of Robonaut's embedded components have been custom designed to meet packaging or environmental requirements, the primary computing systems used in Robonaut are currently commercial-off-the-shelf (COTS) products which have some correlation to flight qualified computer systems. This loose coupling of information technology (IT) resources allows Robonaut to exploit cost effective solutions while floating the technology base to take advantage of the rapid pace of IT advances. These IT systems utilize a software development environment, which is both compatible with COTS hardware as well as flight proven computing systems, preserving the majority of software development for a flight system. The ability to use highly integrated and flexible COTS software development tools improves productivity while minimizing redesign for a space flight system. Further, the flexibility of Robonaut's software and communication architecture has allowed it to become a widely used distributed development testbed for integrating new capabilities and furthering experimental research.
Enclosed is a list of selected and recent publications. Most of these publications concern applied research in the areas of software engineering and human-computer interaction. It is felt that domain-specific knowledge plays a major role in software development. Additionally, it is believed that improvements in the general software development process (e.g., object-oriented approaches) will have to be combined with the use of large domain-specific knowledge bases.
For some time the software industry has espoused the need for improved specification-based software size metrics. This paper reports on a study of nineteen recently developed systems in a variety of application domains. The systems were developed by a single software services corporation using a variety of languages. The study investigated several metric characteristics. It shows that: earlier research into inter-item correlation within the overall function count is partially supported; a priori function counts, in themself, do not explain the majority of the effort variation in software development in the organization studied; documentation quality is critical to accurate function identification; and rater error is substantial in manual function counting. The implication of these findings for organizations using function based metrics are explored.
This paper will present data related to software development processes and personnel involvement from the perspective of software quality assurance. We examine eight years of data collected from six projects. Data collected varied by project but usually included defect and fault density with limited use of code metrics, schedule adherence, and budget growth information. The data are a blend of AFSCP 800-14 and suggested productivity measures in Software Metrics: A Practioner's Guide to Improved Product Development. A software quality assurance database tool, SQUID, was used to store and tabulate the data.