Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “software differences”

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 739 records · Page 41

Low Temperature SQUID for NDE Applications

We have developed a low temperature SuperConducting Quantum Interference Device - SQUID measurement system for detection of defects deep under the surface of aluminum structures using eddy current techniques. The system uses a two dimensional planar inducer with two different excitation frequencies to induce a current in the sample. We have developed a data analysis software program that enabled us to distinguish between round defects (holes), straight defects (slots) and slots close to holes simulating cracks starting from rivets in aluminum structures. We were able to detect defects that are 8mm below the surface. We have also measured the change in phase of the detected signal as a function of depth of the defect. This relationship can be used to determine the depth of hidden flaws. Using this analysis software with the high temperature SQUID system at NASA Langley we were able to detect slots close to holes in layered aluminum sample.

Wincheski, Buzz↗

Science opportunity analyzer - a multi-mission approach to science planning

In the past Science Planning for space missions has been comprised of using ad-hoc software toolscollected or reconstructed from previous missions, tools used by other groups who often speak a different 'technical' language or even 'the backs of envelopes'. In addition to the tools being rough, the work done with these tools often has had to be redone or at least re-entered when it came time to determine actual observations. Science Opportunity Analyzer (SOA), a Java-based application, has been built for scientists to enable them to identify/analyze observation opportunities and then, to create corresponding observation designs.

Science opportunity analyzer science planning SOA ↗

Create your own science planning tool in 3 days with SOA

Scientific discovery and advancement of knowledge has been, and continues to be, the goal for space missions at Jet Propulsion Laboratory. Scientist must plan their observation/experiments to get the maximum data return in order to make those discoveries. However, each mission has different science objectives, a different spacecraft and different instrument payloads, as well as, different routes to different destinations with different spacecraft restrictions and characteristics. In the current reduced cost environment, manageable cost for mission planning software is a must. Science Opportunity Analyzer (SOA), a planning tool for scientists and mission planners, utilizes a simple approach to reduce cost and promote reusability.

Science Opportunity Analyzer (SOA).↗

Aircraft signal definition for flight safety system monitoring system

A system and method compares combinations of vehicle variable values against known combinations of potentially dangerous vehicle input signal values. Alarms and error messages are selectively generated based on such comparisons. An aircraft signal definition is provided to enable definition and monitoring of sets of aircraft input signals to customize such signals for different aircraft. The input signals are compared against known combinations of potentially dangerous values by operational software and hardware of a monitoring function. The aircraft signal definition is created using a text editor or custom application. A compiler receives the aircraft signal definition to generate a binary file that comprises the definition of all the input signals used by the monitoring function. The binary file also contains logic that specifies how the inputs are to be interpreted. The file is then loaded into the monitor function, where it is validated and used to continuously monitor the condition of the aircraft.

Gibbs, Michael↗

Multiple-Flat-Panel System Displays Multidimensional Data

The NASA Ames hyperwall is a display system designed to facilitate the visualization of sets of multivariate and multidimensional data like those generated in complex engineering and scientific computations. The hyperwall includes a 77 matrix of computer-driven flat-panel video display units, each presenting an image of 1,280 1,024 pixels. The term hyperwall reflects the fact that this system is a more capable successor to prior computer-driven multiple-flat-panel display systems known by names that include the generic term powerwall and the trade names PowerWall and Powerwall. Each of the 49 flat-panel displays is driven by a rack-mounted, dual-central-processing- unit, workstation-class personal computer equipped with a hig-hperformance graphical-display circuit card and with a hard-disk drive having a storage capacity of 100 GB. Each such computer is a slave node in a master/ slave computing/data-communication system (see Figure 1). The computer that acts as the master node is similar to the slave-node computers, except that it runs the master portion of the system software and is equipped with a keyboard and mouse for control by a human operator. The system utilizes commercially available master/slave software along with custom software that enables the human controller to interact simultaneously with any number of selected slave nodes. In a powerwall, a single rendering task is spread across multiple processors and then the multiple outputs are tiled into one seamless super-display. It must be noted that the hyperwall concept subsumes the powerwall concept in that a single scene could be rendered as a mosaic image on the hyperwall. However, the hyperwall offers a wider set of capabilities to serve a different purpose: The hyperwall concept is one of (1) simultaneously displaying multiple different but related images, and (2) providing means for composing and controlling such sets of images. In place of elaborate software or hardware crossbar switches, the hyperwall concept substitutes reliance on the human visual system for integration, synthesis, and discrimination of patterns in complex and high-dimensional data spaces represented by the multiple displayed images. The variety of multidimensional data sets that can be displayed on the hyperwall is practically unlimited. For example, Figure 2 shows a hyperwall display of surface pressures and streamlines from a computational simulation of airflow about an aerospacecraft at various Mach numbers and angles of attack. In this display, Mach numbers increase from left to right and angles of attack increase from bottom to top. That is, all images in the same column represent simulations at the same Mach number, while all images in the same row represent simulations at the same angle of attack. The same viewing transformations and the same mapping from surface pressure to colors were used in generating all the images.

Gundo, Daniel↗

Improved Systematic Pointing Error Model for the DSN Antennas

New pointing models have been developed for large reflector antennas whose construction is founded on elevation over azimuth mount. At JPL, the new models were applied to the Deep Space Network (DSN) 34-meter antenna s subnet for corrections of their systematic pointing errors; it achieved significant improvement in performance at Ka-band (32-GHz) and X-band (8.4-GHz). The new models provide pointing improvements relative to the traditional models by a factor of two to three, which translate to approximately 3-dB performance improvement at Ka-band. For radio science experiments where blind pointing performance is critical, the new innovation provides a new enabling technology. The model extends the traditional physical models with higher-order mathematical terms, thereby increasing the resolution of the model for a better fit to the underlying systematic imperfections that are the cause of antenna pointing errors. The philosophy of the traditional model was that all mathematical terms in the model must be traced to a physical phenomenon causing antenna pointing errors. The traditional physical terms are: antenna axis tilts, gravitational flexure, azimuth collimation, azimuth encoder fixed offset, azimuth and elevation skew, elevation encoder fixed offset, residual refraction, azimuth encoder scale error, and antenna pointing de-rotation terms for beam waveguide (BWG) antennas. Besides the addition of spherical harmonics terms, the new models differ from the traditional ones in that the coefficients for the cross-elevation and elevation corrections are completely independent and may be different, while in the traditional model, some of the terms are identical. In addition, the new software allows for all-sky or mission-specific model development, and can utilize the previously used model as an a priori estimate for the development of the updated models.

Rochblatt, David J.↗

VARED: Verification and Analysis of Requirements and Early Designs

Requirements are a part of every project life cycle; everything going forward in a project depends on them. Good requirements are hard to write, there are few useful tools to test, verify, or check them, and it is difficult to properly marry them to the subsequent design, especially if the requirements are written in natural language. In fact, the inconsistencies and errors in the requirements along with the difficulty in finding these errors contribute greatly to the cost of the testing and verification stage of flight software projects [1]. Large projects tend to have several thousand requirements written at various levels by different groups of people. The design process is distributed and a lack of widely accepted standards for requirements often results in a product that varies widely in style and quality. A simple way to improve this would be to standardize the design process using a set of tools and widely accepted requirements design constraints. The difficulty with this approach is finding the appropriate constraints and tools. Common complaints against the tools available include ease of use, functionality, and available features. Also, although preferable, it is rare that these tools are capable of testing the quality of the requirements.

Badger, Julia↗

Ice Roughness and Thickness Evolution on a Business Jet Airfoil

Experiments were performed in the Icing Research Tunnel at NASA Glenn Research Center (GRC) to investigate the ice roughness and thickness evolution on a 152.4-cm (60-in.) chord business jet airfoil exposed to both Appendix C and Appendix O (SLD - Super-cooled Large Droplet) icing conditions. The resulting measurements demonstrate that the average non-dimensional roughness and the stagnation point thickness scalings are similar to those demonstrated on symmetric wings. However, the surface variations of roughness and thickness exhibit significant differences from those observed on symmetric airfoils. The source of the roughness and thickness differences is the result of surface pressure, velocity and temperature distribution differences from the suction to the pressure sides of the airfoil. LEWICE (LEWis ICE accretion program - software developed at NASA Lewis Research Center - former name of the GRC) simulations are used to further investigate the influences of local collection efficiency and the local freezing fraction on the resulting ice roughness and thickness spatial variations.

icing codes↗

Challenges in Development of Online Visualization and Analysis Tools for Satellite Data

Over the years, various online visualization and analysis tools have been developed to facilitate satellite data access and help scientific users around the world to conduct research and develop applications (e.g., data product evaluation, what-if questions, etc.). For those who are new to satellite data products, using them can be a daunting task due to many obstacles in data processing such as data formats, complex data structures, special software packages, unfamiliar terminology, etc., especially when one is not sure whether a dataset is suitable for his/er research project. Even for experienced users, developing software for data processing and analysis can be a costly and time-consuming task. Online visualization tools can overcome many of these difficulties and allow users to focus on scientific questions. For example, Giovanni (the Geospatial Interactive Online Visualization and Analysis Infrastructure, https://giovanni.gsfc.nasa.gov), developed by the NASA Goddard Earth Sciences Data and Information Services Center (GES DISC), allows access over 1900 satellite and model variables in 82 measurement groups of 8 disciplines without downloading data and software. Main features include basic functions for data analysis and visualization, data provenance, output data in different formats (ASCII, NetCDF, GeoTIFF), and more. Over the years, ~1700 peer-reviewed publications in different disciplines have been benefited from Giovanni in research activities (e.g. initial investigation, what-if questions, product evaluation). Despite the success of online visualization and analysis tools, challenges and new opportunities still exist and more can be done with new requirements and technology. Examples are: a) how to increase the efficiency of dataset search by enhancing intuitive aspects; b) how to facilitate interdisciplinary research; c) how to provide data quality information; d) how to engage users to participate in data quality assessment; and more. NASA Earth Observing System Data and Information System (EOSDIS) satellite-based data products are processed at various levels ranging from Level 0 to Level 4. While most users use data products at higher levels (Level-3 and 4), products at lower levels are still important for case studies, algorithm development, ground validation, etc. In this presentation, we will use Giovanni as an example to present and discuss challenges and near-future opportunities for satellite data online visualization and analysis tools.

Liu, Zhong↗

Strategic Center for Networking, Integration, and Communications Orbit Propagation Front-End Software Development

Orbit propagation is fundamental for space-based mission analysis, requiring software tools to predict the time-based positions and velocities of orbiting satellites. Many system analysts currently rely on commercial software, which is effective but expensive. NASA’s Space Communications and Navigation (SCaN) Strategic Center for Networking, Integration, and Communications (SCENIC) project intends to provide these analysis capabilities by using a combination of internal and open-source software, allowing for a greater flexibility while maintaining low costs. Several routines were created to take different forms of user input to translate input into the standard set of orbital elements to be utilized within the current SCENIC analysis capabilities. These inputs range from two-line elements (TLEs) and Cartesian vectors, to coordinate transformations and Walker Delta constellations. These routines will be integrated into the SCENIC user interface (UI) in order to provide greater customization and flexibility for orbit propagation and other dynamic-analysis capabilities.

Kuhl, Nick↗

Kinetics of antigen binding to arrays of antibodies in different sized spots

A fluorescence-based array biosensor has been developed which can measure the binding kinetics of an antigen to an immobilized antibody in real time. A patterned array of antibodies immobilized on the surface of a planar waveguide was used to capture a Cy5-labeled antigen present in a solution that was continuously flowed over the surface. The CCD image of the waveguide was monitored continuously for 25 min. The resulting exponential rise in fluorescence signal was determined by image analysis software and fitted to a reaction-limited kinetics model, giving a kf of 3.6 x 10(5) M(-1) s(-1). Different spot sizes were then patterned on the surface of the waveguide using either a PDMS flow cell or laser exposure, producing width sizes ranging from 80 to 1145 microm. It was demonstrated that under flow conditions, the reduction of spot size did not alter the association rate of the antigen with immobilized antibody; however, as the spot width decreased to < 200 nm, the signal intensity also decreased.

Non-NASA Center↗

Remotely Administered Psychoacoustic Test for sUAS Noise to Gauge Feasibility of Remote UAM Noise Study

The National Aeronautics and Space Administration (NASA) remotely administered a psychoacoustic test in fall of 2022 as the first of two phases of a cooperative Urban Air Mobility (UAM) vehicle noise human response study. The first phase, the Feasibility Test, described in this paper, determined the feasibility of the remote test method, in contrast to a previous in-person psychoacoustic test that found an annoyance response difference between small unmanned aerial system (sUAS) noise and ground vehicle noise. This paper discusses the Feasibility Test online layout, sound calibration method, remote test software development, stimuli selection, test subject recruitment, and test administration. Test performance is measured through comparison of annoyance response data with the previous in-person test results. The paper also investigates if providing a contextual cue to test subjects influenced their annoyance response. Response differences between test subjects in geographically distinct areas are analyzed. Administrative challenges that were encountered during the test are discussed. The second phase of this study, the implementation phase, will use a remote (web-based) test method and leverage the cooperation of multiple government agencies, academia, and industry to gain human response insights from a wide range of UAM vehicle sounds that would be challenging for a single organization to acquire. Improvements to administering a remote test for the implementation phase of the UAM vehicle noise human response study are recommended.

Remote Psychoacoustic Test↗

Remotely Administered Psychoacoustic Test for sUAS Noise to Gauge Feasibility of Remote UAM Noise Study

The National Aeronautics and Space Administration (NASA) remotely administered a psychoacoustic test in fall of 2022 as the first of two phases of a cooperative Urban Air Mobility (UAM) vehicle noise human response study. The first phase, the Feasibility Test, described in this paper, determined the feasibility of the remote test method, in contrast to a previous in-person psychoacoustic test that found an annoyance response difference between small unmanned aerial system (sUAS) noise and ground vehicle noise. This paper discusses the Feasibility Test online layout, sound calibration method, remote test software development, stimuli selection, test subject recruitment, and test administration. Test performance is measured through comparison of annoyance response data with the previous in-person test results. The paper also investigates if providing a contextual cue to test subjects influenced their annoyance response. Response differences between test subjects in geographically distinct areas are analyzed. Administrative challenges that were encountered during the test are discussed. The second phase of this study, the implementation phase, will use a remote (web-based) test method and leverage the cooperation of multiple government agencies, academia, and industry to gain human response insights from a wide range of UAM vehicle sounds that would be challenging for a single organization to acquire. Improvements to administering a remote test for the implementation phase of the UAM vehicle noise human response study are recommended.

Remote Psychoacoustic Test↗

Benchmarking hypercube hardware and software

It was long a truism in computer systems design that balanced systems achieve the best performance. Message passing parallel processors are no different. To quantify the balance of a hypercube design, an experimental methodology was developed and the associated suite of benchmarks was applied to several existing hypercubes. The benchmark suite includes tests of both processor speed in the absence of internode communication and message transmission speed as a function of communication patterns.

Grunwald, Dirk C.↗

Verification Testing: Meet User Needs Figure of Merit

Verification is the process through which Modeling and Simulation(M&S) software goes to ensure that it has been rigorously tested and debugged for its intended use. Validation confirms that said software accurately models and represents the real world system. Credibility gives an assessment of the development and testing effort that the software has gone through as well as how accurate and reliable test results are. Together, these three components form Verification, Validation, and Credibility(VV&C), the process by which all NASA modeling software is to be tested to ensure that it is ready for implementation. NASA created this process following the CAIB (Columbia Accident Investigation Board) report seeking to understand the reasons the Columbia space shuttle failed during reentry. The reports conclusion was that the accident was fully avoidable, however, among other issues, the necessary data to make an informed decision was not there and the result was complete loss of the shuttle and crew. In an effort to mitigate this problem, NASA put out their Standard for Models and Simulations, currently in version NASA-STD-7009A, in which they detailed their recommendations, requirements and rationale for the different components of VV&C. They did this with the intention that it would allow for people receiving MS software to clearly understand and have data from the past development effort. This in turn would allow the people who had not worked with the MS software before to move forward with greater confidence and efficiency in their work. This particular project looks to perform Verification on several MATLAB (Registered Trademark)(The MathWorks, Inc.) scripts that will be later implemented in a website interface. It seeks to take note and define the limits of operation, the units and significance, and the expected datatype and format of the inputs and outputs of each of the scripts. This is intended to prevent the code from attempting to make incorrect or impossible calculations. Additionally, this project will look at the coding generally and note inconsistencies, redundancies, and other aspects that may become problematic or slow down the codes run time. Certain scripts lacking in documentation also will be commented and cataloged.

validation↗

Managing Ada development

The Ada programming language was developed under the sponsorship of the Department of Defense to address the soaring costs associated with software development and maintenance. Ada is powerful, and yet to take full advantage of its power, it is sufficiently complex and different from current programming approaches that there is considerable risk associated with committing a program to be done in Ada. There are also few programs of any substantial size that have been implemented using Ada that may be studied to determine those management methods that resulted in a successful Ada project. The items presented are the author's opinions which have been formed as a result of going through an experience software development. The difficulties faced, risks assumed, management methods applied, and lessons learned, and most importantly, the techniques that were successful are all valuable sources of management information for those managers ready to assume major Ada developments projects.

Green, James R.↗

"One-Stop Shopping" for Ocean Remote-Sensing and Model Data

OurOcean Portal 2.0 (http:// ourocean.jpl.nasa.gov) is a software system designed to enable users to easily gain access to ocean observation data, both remote-sensing and in-situ, configure and run an Ocean Model with observation data assimilated on a remote computer, and visualize both the observation data and the model outputs. At present, the observation data and models focus on the California coastal regions and Prince William Sound in Alaska. This system can be used to perform both real-time and retrospective analyses of remote-sensing data and model outputs. OurOcean Portal 2.0 incorporates state-of-the-art information technologies (IT) such as MySQL database, Java Web Server (Apache/Tomcat), Live Access Server (LAS), interactive graphics with Java Applet at the Client site and MatLab/GMT at the server site, and distributed computing. OurOcean currently serves over 20 real-time or historical ocean data products. The data are served in pre-generated plots or their native data format. For some of the datasets, users can choose different plotting parameters and produce customized graphics. OurOcean also serves 3D Ocean Model outputs generated by ROMS (Regional Ocean Model System) using LAS. The Live Access Server (LAS) software, developed by the Pacific Marine Environmental Laboratory (PMEL) of the National Oceanic and Atmospheric Administration (NOAA), is a configurable Web-server program designed to provide flexible access to geo-referenced scientific data. The model output can be views as plots in horizontal slices, depth profiles or time sequences, or can be downloaded as raw data in different data formats, such as NetCDF, ASCII, Binary, etc. The interactive visualization is provided by graphic software, Ferret, also developed by PMEL. In addition, OurOcean allows users with minimal computing resources to configure and run an Ocean Model with data assimilation on a remote computer. Users may select the forcing input, the data to be assimilated, the simulation period, and the output variables and submit the model to run on a backend parallel computer. When the run is complete, the output will be added to the LAS server for

Li, P. Peggy↗

Transportability, distributability and rehosting experience with a kernel operating system interface set

For the past two years, PRC has been transporting and installing a software engineering environment framework, the Automated Product control Environment (APCE), at a number of PRC and government sites on a variety of different hardware. The APCE was designed using a layered architecture which is based on a standardized set of interfaces to host system services. This interface set called the APCE Interface Set (AIS), was designed to support many of the same goals as the Common Ada Programming Support Environment (APSE) Interface Set (CAIS). The APCE was developed to provide support for the full software lifecycle. Specific requirements of the APCE design included: automation of labor intensive administrative and logistical tasks: freedom for project team members to use existing tools: maximum transportability for APCE programs, interoperability of APCE database data, and distributability of both processes and data: and maximum performance on a wide variety of operating systems. A brief description is given of the APCE and AIS, a comparison of the AIS and CAIS both in terms of functionality and of philosophy and approach and a presentation of PRC's experience in rehosting AIS and transporting APCE programs and project data. Conclusions are drawn from this experience with respect to both the CAIS efforts and Space Station plans.

Blumberg, F. C.↗