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.
Baseband combining with and without combined carrier referencing for antenna arrays are compared under two scenarios for the Voyager 2 Uranus encounter. The combined carrier reference scheme is estimated to outperform the baseband only scheme by less than 0.3 dB E (sub b)/N (sub 0) at a bit error probability of 0.005. These results were attained both with mathematical modeling and software Viterbi decoder simulations.
The effects of programmer experience level, different program usage distributions, and programming languages are explored. All these factors affect performance, and some tentative relational hypotheses are presented. An analytic framework for replicated and non-replicated (traditional) software experiments is presented. A method of obtaining an upper bound on the error rate of the next error is proposed. The method was validated empirically by comparing forecasts with actual data. In all 14 cases the bound exceeded the observed parameter, albeit somewhat conservatively. Two other forecasting methods are proposed and compared to observed results. Although demonstrated relative to this framework that stages are neither independent nor exponentially distributed, empirical estimates show that the exponential assumption is nearly valid for all but the extreme tails of the distribution. Except for the dependence in the stage probabilities, Cox's model approximates to a degree what is being observed.
The concepts of software engineering which allow a user of the finite element method to describe a model, to collect and to check the model data in a data base as well as to form the matrices required for a finite element calculation are examined. Next the components of the model description are conceived including the mesh tree, the topology, the configuration, the kinematic boundary conditions, the data for each element, and the loads. The possibilities for description and review of the data are considered. The concept of the segments for the modularization of the programs follows the components of the model description. The significance of the mesh tree as a globular guiding structure will be understood in view of the principle of the unity of the model, the mesh tree, and the data base. The user-friendly aspects of the software system will be summarized: the principle of language communication, the data generators, error processing, and data security.
Requirements for the IUE archive, and how the signal/noise (S/N) ratio in photometrically corrected images can be enhanced considerably by cross-correlating the fixed pattern in a data image with that in a suitable flat-field image are described. From these cross-correlations it is feasible to derive an accurate geometrical correction to apply to the data image before applying the intensity transfer functions. The standard IUE processing software does not generate a sufficiently accurate geometric correction so that typical spatial errors of 1 to 2 pixels conspire with the large fixed pattern in raw images to produce significant misregistration noise. Tests on flat-field images demonstrate that an explicit geometric correction procedure can avoid most of the misregistration noise and can thereby improve the S/N ratio of IUE data by factors of 1.5 to 2.4.
Circuit board containing microprocessors designed to control acquisition of data by IBM PS/2 computer. Plugged into one of 16-bit slots on mother board of computer. Controls transfer of data from as many as 48 discrete channels to Micro Channel Interface. With expansion of software, board recognizes and filters specified kinds of signal patterns, possibly to detect errors.
This paper describes the simulation and test methods used to ensure that the NASA Standard Spacecraft Computer, Model 1, (NSSC-I) flight software for the Hubble Space Telescope properly carries out its requirements for control of scientific observations and for monitoring the health and safety of the payload. The hardware and software test environment is discussed. The different kinds of tests (unit, special real time, and stress tests) that are performed before the software is incorporated into the flight system are described, and the kinds of errors that each test category is best suited to find are listed. Finally, the limitations of the tests are discussed, and current plans for enhancing the test environment are outlined.
The rotating microphone measurement technique and data analysis procedures are documented which are used to determine circumferential and radial acoustic mode content in the inlet of the Advanced Ducted Propeller (ADP) model. Circumferential acoustic mode levels were measured at a series of radial locations using the Doppler frequency shift produced by a rotating inlet microphone probe. Radial mode content was then computed using a least squares curve fit with the measured radial distribution for each circumferential mode. The rotating microphone technique is superior to fixed-probe techniques because it results in minimal interference with the acoustic modes generated by rotor-stator interaction. This effort represents the first experimental implementation of a measuring technique developed by T. G. Sofrin. Testing was performed in the NASA Lewis Low Speed Anechoic Wind Tunnel at a simulated takeoff condition of Mach 0.2. The design is included of the data analysis software and the performance of the rotating rake apparatus. The effect of experiment errors is also discussed.
The rotating microphone measurement technique and data analysis procedures are documented which are used to determine circumferential and radial acoustic mode content in the inlet of the Advanced Ducted Propeller (ADP) model. Circumferential acoustic mode levels were measured at a series of radial locations using the Doppler frequency shift produced by a rotating inlet microphone probe. Radial mode content was then computed using a least squares curve fit with the measured radial distribution for each circumferential mode. The rotating microphone technique is superior to fixed-probe techniques because it results in minimal interference with the acoustic modes generated by rotor-stator interaction. This effort represents the first experimental implementation of a measuring technique developed by T. G. Sofrin. Testing was performed in the NASA Lewis Low Speed Anechoic Wind Tunnel at a simulated takeoff condition of Mach 0.2. The design is included of the data analysis software and the performance of the rotating rake apparatus. The effect of experiment errors is also discussed.
Lossless data compression was studied for many NASA missions. The Rice algorithm was demonstrated to provide better performance than other available techniques on most scientific data. A top-level description of the Rice algorithm is first given, along with some new capabilities implemented in both software and hardware forms. Systems issues important for onboard implementation, including sensor calibration, error propagation, and data packetization, are addressed. The latter part of the guide provides twelve case study examples drawn from a broad spectrum of science instruments.
Since the launch of NASA's Extreme Ultraviolet Explorer (EUVE) satellite in 1992, there has only been a handful of occurrences that have warranted manual intervention in the EUVE Science Operations Center (ESOC). So, in an effort to reduce costs, the current environment is being redesigned to utilize a combination of off-the-shelf packages and recently developed artificial intelligence (AI) software to automate the monitoring of the science payload and ground systems. The successful implementation of systemic automation would allow the ESOC to evolve from a seven day/week, three shift operation, to a seven day/week one shift operation. First, it was necessary to identify all areas considered mission critical. These were defined as follows: (1) The telemetry stream must be monitored autonomously and anomalies identified. (2) Duty personnel must be automatically paged and informed of the occurrence of an anomaly. (3) The 'basic' state of the ground system must be assessed. (4) Monitors should check that the systems and processes needed to continue in a 'healthy' operational mode are working at all times. (5) Network loads should be monitored to ensure that they stay within established limits. (6) Connectivity to Goddard Space Flight Center (GSFC) systems should be monitored as well, not just for connectivity of the network itself but also for the ability to transfer files. (7) All necessary peripheral devices should be monitored. This would include the disks, routers, tape drives, printers, tape carousel, and power supplies. (8) System daemons such as the archival daemon, the Sybase server, the payload monitoring software, and any other necessary processes should be monitored to ensure that they are operational. (9) The monitoring system needs to be redundant so that the failure of a single machine will not paralyze the monitors. (10) Notification should be done by means of looking though a table of the pager numbers for current 'on call' personnel. The software should be capable of dialing out to notify, sending email, and producing error logs. (11) The system should have knowledge of when real-time passes and tape recorder dumps will occur and should know that these passes and data transmissions are successful. Once the design criteria were established, the design team split into two groups: one that addressed the tracking, commanding, and health and safety of the science payload and another group that addressed the ground systems and communications aspects of the overall system.
The Timed Doppler Interferometer (TIDI) will accurately and precisely determine the global vector MLTI (Mesosphere and Lower Thermosphere) wind, temperature, and density profiles. It will measure characteristics of the gravity wave and planetary wave spectra. The tidal characteristics of temperature, density, and wind in the MLTI will be determined. The neutral and ion winds will be measured to characterize the electrodynamical behavior of the MLTI. Oxygen and O2 abundances and nocticulent cloud activity will be measured. This review goes into the calibration and error sources, optical design, mechanisms design, detector design, electronics design, microprocessor and flight software design, and quality assurance and parts.
The Display Audit Suite is an integrated package of software tools that partly automates the detection of Portable Computer System (PCS) Display errors. [PCS is a lap top computer used onboard the International Space Station (ISS).] The need for automation stems from the large quantity of PCS displays (6,000+, with 1,000,000+ lines of command and telemetry data). The Display Audit Suite includes data-extraction tools, automatic error detection tools, and database tools for generating analysis spread sheets. These spread sheets allow engineers to more easily identify many different kinds of possible errors. The Suite supports over 40 independent analyses, 16 NASA Tech Briefs, November 2008 and complements formal testing by being comprehensive (all displays can be checked) and by revealing errors that are difficult to detect via test. In addition, the Suite can be run early in the development cycle to find and correct errors in advance of testing.
Developers working in Computational Science & Engineering (CSE)/High Performance Computing (HPC) must contend with constant change due to advances in computing technology and science. Test Driven Development (TDD) is a methodology that mitigates software development risks due to change at the cost of adding comprehensive and continuous testing to the development process. Testing frameworks tailored for CSE/HPC, like pFUnit, can lower the barriers to such testing, yet CSE software faces unique constraints foreign to the broader software engineering community. Effective testing of numerical software requires a comprehensive suite of oracles, i.e., use cases with known answers, as well as robust estimates for the unavoidable numerical errors associated with implementation with finite-precision arithmetic. At first glance these concerns often seem exceedingly challenging or even insurmountable for real-world scientific applications. However, we argue that this common perception is incorrect and driven by (1) a conflation between model validation and software verification and (2) the general tendency in the scientific community to develop relatively coarse-grained, large procedures that compound numerous algorithmic steps.We believe TDD can be applied routinely to numerical software if developers pursue fine-grained implementations that permit testing, neatly side-stepping concerns about needing nontrivial oracles as well as the accumulation of errors. We present an example of a successful, complex legacy CSE/HPC code whose development process shares some aspects with TDD, which we contrast with current and potential capabilities. A mix of our proposed methodology and framework support should enable everyday use of TDD by CSE-expert developers.
Procedures used in characterizing geometric error sources for a spaceborne imaging system are described using the LANDSAT D thematic mapper ground segment processing as the prototype. Software was tested through simulation and is undergoing tests with the operational hardware as part of the prelaunch system evaluation. Geometric accuracy specifications, geometric correction, and control point processing are discussed. Cross track and along track errors are tabulated for the thematic mapper, the spacecraft, and ground processing to show the temporal registration error budget in pixel (42.5 microrad) 90%.
Innovative systems and software engineering solutions are required to meet the increasingly challenging demands of deep-space robotic missions. While recent advances in the development of an integrated systems and software engineering approach have begun to address some of these issues, they are still at the core highly manual and, therefore, error-prone. This paper describes a task aimed at infusing MIT's model-based executive, Titan, into JPL's Mission Data System (MDS), a unified state-based architecture, systems engineering process, and supporting software framework. Results of the task are presented, including a discussion of the benefits and challenges associated with integrating mature model-based programming techniques and technologies into a rigorously-defined domain specific architecture.
The EvaluateFlux program is a post-processing utility program for DIF3D, specifically DIF3D-VARIANT which handles Cartesian and hexagonal geometries. The EvaluateFlux program was developed to allow users to obtain flux and power traverses through the geometry domain, and its initial purpose was to facilitate foil analysis by evaluating the flux solution from DIF3D-VARIANT and combining it with foil cross section data. The EvaluateFlux program can calculate the neutron flux, as well as the reaction rates, at any user provided evaluation point. It does this by identifying the spatial mesh associated with the evaluation point and then evaluates the polynomial based neutron flux moments stored in the NHFLUX file at that point. The output of EvaluateFlux varies depending on the input setup. The maximum output includes the neutron flux and microscopic and macroscopic reaction rates at each evaluation point. The purpose of this work is to verify the outputs of EvaluateFlux. Simple models that have hand calculatable results are first defined and used to verify the EvaluateFlux outputs. More complex cases are then added where a duplicate program of EvaluateFlux that uses PrintTables outputs of the binary files is used to verify the EvaluateFlux outputs. In those complex cases, hand calculations of selected evaluation points were also displayed to confirm the software verification. For all the tests done, the hand calculations agreed well with those calculated by EvaluateFlux. For the larger complex problems, the duplicate program that can process hundreds of evaluation points was able to identify that zero points within some meshes have large errors. This aspect was attributed to the truncation error on the input provided to the duplicate program and is not a concern for the accuracy of the EvaluateFlux software.
The EvaluateFlux program is a post-processing utility program for DIF3D, specifically DIF3D-VARIANT which handles Cartesian and hexagonal geometries. The EvaluateFlux program was developed to allow users to obtain flux and power traverses through the geometry domain, and its initial purpose was to facilitate foil analysis by evaluating the flux solution from DIF3D-VARIANT and combining it with foil cross section data. The EvaluateFlux program can calculate the neutron flux, as well as the reaction rates, at any user provided evaluation point. It does this by identifying the spatial mesh associated with the evaluation point and then evaluates the polynomial based neutron flux moments stored in the NHFLUX file at that point. The output of EvaluateFlux varies depending on the input setup. The maximum output includes the neutron flux and microscopic and macroscopic reaction rates at each evaluation point. The purpose of this work is to verify the outputs of EvaluateFlux. Simple models that have hand calculatable results are first defined and used to verify the EvaluateFlux outputs. More complex cases are then added where a duplicate program of EvaluateFlux that uses PrintTables outputs of the binary files is used to verify the EvaluateFlux outputs. In those complex cases, hand calculations of selected evaluation points were also displayed to confirm the software verification. For all the tests done, the hand calculations agreed well with those calculated by EvaluateFlux. For the larger complex problems, the duplicate program that can process hundreds of evaluation points was able to identify that zero points within some meshes have large errors. This aspect was attributed to the truncation error on the input provided to the duplicate program and is not a concern for the accuracy of the EvaluateFlux software.
Operating spacecraft is a never-ending challenge and the risk of human error is ever- present. Many missions have been significantly affected by human error on the part of ground controllers. The Cassini mission at Saturn has not been immune to human error, but Cassini operations engineers use tools and follow processes that find and correct most human errors before they reach the spacecraft. What is needed are skilled engineers with good technical knowledge, good interpersonal communications, quality ground software, regular peer reviews, up-to-date procedures, as well as careful attention to detail and the discipline to test and verify all commands that will be sent to the spacecraft. Two areas of special concern are changes to flight software and response to in-flight anomalies. The Cassini team has a lot of practical experience in all these areas and they have found that well-trained engineers with good tools who follow clear procedures can catch most errors before they get into command sequences to be sent to the spacecraft. Finally, having a robust and fault-tolerant spacecraft that allows ground controllers excellent visibility of its condition is the most important way to ensure human error does not compromise the mission.