Search NASA⌕ Search

SEARCH · Search NASA

Results for “Software Porting”

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 19 records
All sourcesNASA NTRSDOE OSTI
DOE OSTI2025

ComPort: Rigorous Testing Methods to Safeguard Software Porting (Final UW Report)

This report summarizes the University of Washington’s contributions to the ComPort project, Rigorous Testing Methods to Safeguard Software Porting, funded under the U.S. Department of Energy, Office of Science, Office of Advanced Scientific Computing Research (ASCR), award number DE-SC0022081. UW’s work addressed numerics-driven correctness challenges arising in heterogeneous and rapidly evolving computing environments. Our efforts focused on developing interactive analysis tools, correctness-preserving rewriting systems, semantic-aware code-transformation infrastructure, and multi-language support for reproducible numerical experiments.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2025

ComPort: Rigorous Testing Methods to Safeguard Software Porting (Final Technical Report)

This is a technical report from the lead institution – University of Utah, Kahlert School of Computing – funded under the Department of Energy, Office of Science, Office of Advanced Scientific Computing Research under award number DE-SC0022252. We summarize our work done over the three years of funding received. The relevant papers and software have already been uploaded at the DOE site.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS2001

PiVoT GPS Receiver

NASA Goddard Space Flight Center has built an open architecture, 24 channel spaceflight Global Positioning System (GPS) receiver. The compact PCI PiVoT GPS receiver card is based on the Mitel/GEC Plessey Builder 2 board. PiVoT uses two Plessey 2021 correlators to allow tracking of up to 24 separate GPS SV's on unique channels. Its four front ends can support four independent antennas, making it a useful card for hosting GPS attitude determination algorithms. It has been built using space quality, radiation tolerant parts. The PiVoT card works at a lower signal to noise ratio than the original Builder 2 board. It also hosts an improved clock oscillator. The PiVoT software is based on the original Piessey Builder 2 software ported to the Linux operating system. The software is posix compliant and can be easily converted to other posix operating systems. The software is open source to anyone with a licensing agreement with Plessey. Additional tasks can be added to the software to support GPS science experiments or attitude determination algorithms. The next generation PiVoT receiver will be a single radiation hardened compact PCI card containing the microprocessor and the GPS receiver optimized for use above the GPS constellation.

Wennersten, Miriam↗
NASA NTRS2001

PiVoT GPS Receiver

NASA Goddard Space Flight Center has built an open architecture, 24 channel space flight GPS receiver. The CompactPCI PiVoT GPS receiver card is based on the Mitel/GEC Plessey Builder-2 board. PiVoT uses two Plessey 2021 correlators to allow tracking of up to 24 separate GPS SV's on unique channels. Its four front ends can support four independent antennas, making it a useful card for hosting GPS attitude determination algorithms. It has been built using space quality, radiation tolerant parts. The PiVoT card will track a weaker signal than the original Builder 2 board. It also hosts an improved clock oscillator. The PiVoT software is based on the original Plessey Builder 2 software ported to the Linux operating system. The software is POSIX complaint and can easily be converted to other POSIX operating systems. The software is open source to anyone with a licensing agreement with Plessey. Additional tasks can be added to the software to support GPS science experiments or attitude determination algorithms. The next generation PiVoT receiver will be a single radiation hardened CompactPCI card containing the microprocessor and the GPS receiver optimized for use above the GPS constellation. PiVoT was flown successfully on a balloon in July, 2001, for its first non-simulated flight.

Wennersten, Miriam Dvorak↗
NASA NTRS1990

Attitude Determination and Control System (ADCS) and Maintenance and Diagnostic System (MDS): A maintenance and diagnostic system for Space Station Freedom

The Maintenance and Diagnostic System (MDS) that is being developed at Honeywell to enhance the Fault Detection Isolation and Recovery system (FDIR) for the Attitude Determination and Control System on Space Station Freedom is described. The MDS demonstrates ways that AI-based techniques can be used to improve the maintainability and safety of the Station by helping to resolve fault anomalies that cannot be fully determined by built-in-test, by providing predictive maintenance capabilities, and by providing expert maintenance assistance. The MDS will address the problems associated with reasoning about dynamic, continuous information versus only about static data, the concerns of porting software based on AI techniques to embedded targets, and the difficulties associated with real-time response. An initial prototype was built of the MDS. The prototype executes on Sun and IBM PS/2 hardware and is implemented in the Common Lisp; further work will evaluate its functionality and develop mechanisms to port the code to Ada.

Toms, David↗
NASA NTRS2006

PVM Enhancement for Beowulf Multiple-Processor Nodes

A recent version of the Parallel Virtual Machine (PVM) computer program has been enhanced to enable use of multiple processors in a single node of a Beowulf system (a cluster of personal computers that runs the Linux operating system). A previous version of PVM had been enhanced by addition of a software port, denoted BEOLIN, that enables the incorporation of a Beowulf system into a larger parallel processing system administered by PVM, as though the Beowulf system were a single computer in the larger system. BEOLIN spawns tasks on (that is, automatically assigns tasks to) individual nodes within the cluster. However, BEOLIN does not enable the use of multiple processors in a single node. The present enhancement adds support for a parameter in the PVM command line that enables the user to specify which Internet Protocol host address the code should use in communicating with other Beowulf nodes. This enhancement also provides for the case in which each node in a Beowulf system contains multiple processors. In this case, by making multiple references to a single node, the user can cause the software to spawn multiple tasks on the multiple processors in that node.

Springer, Paul↗
NASA NTRS1993

Clementine Sensor Processing System

The design of the DSPSE Satellite Controller (DSC) is baselined as a single-string satellite controller. The DSC performs two main functions: health and maintenance of the spacecraft; and image capture, storage, and playback. The DSC contains two processors: a radiation-hardened Mil-Std-1750, and a commercial R3000. The Mil-Std-1750 processor performs all housekeeping operations, while the R3000 is mainly used to perform the image processing functions associated with the navigation functions, as well as performing various experiments. The DSC also contains a data handling unit (DHU) used to interface to various spacecraft imaging sensors and to capture, compress, and store selected images onto the solid-state data recorder. The development of the DSC evolved from several key requirements; the DSPSE satellite was to do the following: (1) have a radiation-hardened spacecraft control system and be immune to single-event upsets (SEU's); (2) use an R3000-based processor to run the star tracker software that was developed by SDIO (due to schedule and cost constraints, there was no time to port the software to a radiation-hardened processor); and (3) fly a commercial processor to verify its suitability for use in a space environment. In order to enhance the DSC reliability, the system was designed with multiple processing paths. These multiple processing paths provide for greater tolerance to various component failures. The DSC was designed so that all housekeeping processing functions are performed by either the Mil-Std-1750 processor or the R3000 processor. The image capture and storage is performed either by the DHU or the R3000 processor.

Feldstein, A. A.↗
NASA NTRS1992

EOS workstation

This final report summarizes the work done from mid-1989 until January 1992 to develop a prototype set of tools for the analysis of EOS-type images. Such images are characterized by great multiplicity and quantity. A single 'snapshot' of EOS-type imagery may contain several hundred component images so that on a particular pixel, one finds multiple gray values. A prototype EOS-sensor, AVIRIS, has 224 gray values at each pixel. The work focused on the ability to utilize very large images and continuously roam through those images, zoom and be able to hold more than one black and white or color image, for example for stereo viewing or for image comparisons. A second focus was the utilization of so-called 'image cubes', where multiple images need to be co-registered and then jointly analyzed, viewed, and manipulated. The target computer platform that was selected was a high-performance graphics superworkstation, Stardent 3000. This particular platform offered many particular graphics tools such as the Application Visualization System (AVS) or Dore, but it missed availability of commercial third-party software for relational data bases, image processing, etc. The project was able to cope with these limitations and a phase-3 activity is currently being negotiated to port the software and enhance it for use with a novel graphics superworkstation to be introduced into the market in the Spring of 1993.

Leberl, Franz↗
NASA NTRS1991

Mark 4A antenna control system data handling architecture study

A high-level review was conducted to provide an analysis of the existing architecture used to handle data and implement control algorithms for NASA's Deep Space Network (DSN) antennas and to make system-level recommendations for improving this architecture so that the DSN antennas can support the ever-tightening requirements of the next decade and beyond. It was found that the existing system is seriously overloaded, with processor utilization approaching 100 percent. A number of factors contribute to this overloading, including dated hardware, inefficient software, and a message-passing strategy that depends on serial connections between machines. At the same time, the system has shortcomings and idiosyncrasies that require extensive human intervention. A custom operating system kernel and an obscure programming language exacerbate the problems and should be modernized. A new architecture is presented that addresses these and other issues. Key features of the new architecture include a simplified message passing hierarchy that utilizes a high-speed local area network, redesign of particular processing function algorithms, consolidation of functions, and implementation of the architecture in modern hardware and software using mainstream computer languages and operating systems. The system would also allow incremental hardware improvements as better and faster hardware for such systems becomes available, and costs could potentially be low enough that redundancy would be provided economically. Such a system could support DSN requirements for the foreseeable future, though thorough consideration must be given to hard computational requirements, porting existing software functionality to the new system, and issues of fault tolerance and recovery.

Briggs, H. C.↗
NASA NTRS1986

A preliminary design for flight testing the FINDS algorithm

This report presents a preliminary design for flight testing the FINDS (Fault Inferring Nonlinear Detection System) algorithm on a target flight computer. The FINDS software was ported onto the target flight computer by reducing the code size by 65%. Several modifications were made to the computational algorithms resulting in a near real-time execution speed. Finally, a new failure detection strategy was developed resulting in a significant improvement in the detection time performance. In particular, low level MLS, IMU and IAS sensor failures are detected instantaneously with the new detection strategy, while accelerometer and the rate gyro failures are detected within the minimum time allowed by the information generated in the sensor residuals based on the point mass equations of motion. All of the results have been demonstrated by using five minutes of sensor flight data for the NASA ATOPS B-737 aircraft in a Microwave Landing System (MLS) environment.

Caglayan, A. K.↗
NASA NTRS1986

Methods of downloading to user institutions

The Pilot Climate Data System (PCDS) not only supports the ability to output data in a uniform structure via the Common Data Format (CDF, but also supports the ability to provide data in native format for any data set supported by the PCDS. Methods are discussed for acquiring data in either format from the PCDS for further work at remote sites. Four levels of remote utilization are defined, based on the extent of offloading the National Space Science Data Center (NSSDC) computer and local PCDS processing. Characteristics of each level are thoroughly explained, including details of information and data transfers, downloading, uploading, and offloading of the NSSDC computer. Only the levels themselves are specified here. The first level defined is that of a network-based distributed PCDS. A subset of the PCDS software is ported to another VAX and made available on a network (i.e., SPAN) node. There is no subset of the PCDS at the second level, but it is also network based. Non-network utilization of the PCDS, requiring dial-up log on, is denoted as a third level. Finally, at the fourth level, personal computer utilization of the PCDS through dial-up log on with proper terminal emulation is defined.

Treinish, L.↗
NASA NTRS1995

A software bus for thread objects

The authors have implemented a software bus for lightweight threads in an object-oriented programming environment that allows for rapid reconfiguration and reuse of thread objects in discrete-event simulation experiments. While previous research in object-oriented, parallel programming environments has focused on direct communication between threads, our lightweight software bus, called the MiniBus, provides a means to isolate threads from their contexts of execution by restricting communications between threads to message-passing via their local ports only. The software bus maintains a topology of connections between these ports. It routes, queues, and delivers messages according to this topology. This approach allows for rapid reconfiguration and reuse of thread objects in other systems without making changes to the specifications or source code. A layered approach that provides the needed transparency to developers is presented. Examples of using the MiniBus are given, and the value of bus architectures in building and conducting simulations of discrete-event systems is discussed.

Callahan, John R.↗
DOE OSTI2024

FTTN: Feature-Targeted Testing for Numerical Properties of NVIDIA & AMD Matrix Accelerators

While NVIDIA has been the dominant provider of GPUs for HPC and ML, now AMD has several offerings of GPUs. This encourages programmers to try out AMD GPUs for new codes and also port existing codes over. Unfortunately, without understanding the floating-point differences between these GPU types, software development or porting can introduce bugs—and currently such an understanding is lacking. The magnitude of this open question becomes clear if one imagines the the number of floating-point precision choices (FP16, FP32, etc.), floating-point formats (standard floats, brain-float, etc.), and execution units available (elementary units, matrix/tensor cores, etc.) Questions such as rounding modes and subnormal support are also important. Most of these answers are unknown today or are hard to access. We provide the first testing-guided approach that answers a significant number of these questions. We also devise tests to reveal internal information (e.g., extra bits kept) to make sure that our findings are reliable. Many of our tests employ systematically generated random-programs, others apply fast-math flags and some involve fused multiplyadd. Especially for tensor/matrix cores, the tests have nontrivial logic that we present Our testing approach is reusable for the plethora of GPUs yet to be introduced. Our findings include up to 7 ulps of difference between NVIDIA and AMD for sin and cos at FP32 precision and 3 ulp at FP64. In our study of matrix cores (NVIDIA) and tensor cores (AMD), we have extensively characterized rounding modes (truncation versus round-to-nearest), the number of extra internal bits kept (whether 3 bits are kept or not), subnormal support for inputs and outputs across four different floating-point formats and across NVIDIA A100 and AMD MI250X GPUs. We believe that this wealth of data becoming available for the first time may help avoid significant porting bugs when migrating code across these platforms.

Li, Xinyi↗
NASA NTRS2005

Self port scanning tool : providing a more secure computing Environment through the use of proactive port scanning

Secure computing is a necessity in the hostile environment that the internet has become. Protection from nefarious individuals and organizations requires a solution that is more a methodology than a one time fix. One aspect of this methodology is having the knowledge of which network ports a computer has open to the world, These network ports are essentially the doorways from the internet into the computer. An assessment method which uses the nmap software to scan ports has been developed to aid System Administrators (SAs) with analysis of open ports on their system(s). Additionally, baselines for several operating systems have been developed so that SAs can compare their open ports to a baseline for a given operating system. Further, the tool is deployed on a website where SAs and Users can request a port scan of their computer. The results are then emailed to the requestor. This tool aids Users, SAs, and security professionals by providing an overall picture of what services are running, what ports are open, potential trojan programs or backdoors, and what ports can be closed.

nMap↗
NASA NTRS2013

GRC GSFC TDRSS Waveform Metrics Report

The report presents software metrics and porting metrics for the GGT Waveform. The porting was from a ground-based COTS SDR, the SDR-3000, to the CoNNeCT JPL SDR. The report does not address any of the Operating Environment (OE) software development, nor the original TDRSS waveform development at GSFC for the COTS SDR. With regard to STRS, the report presents compliance data and lessons learned.

Mortensen, Dale J.↗
NASA NTRS2018

Increasing Flight Software Reuse with OpenSatKit

In January 2015 the NASA Goddard Space Flight Center (GSFC) released the Core Flight System (cFS) as open source under the NASA Open Source Agreement (NOSA) license. The cFS is based on flight software (FSW) developed for 12 spacecraft spanning nearly two decades of effort and it can provide about a third of the FSW functionality for a low-earth orbiting scientific spacecraft. The cFS is a FSW framework that is portable, configurable, and extendable using a product line deployment model. However, the components are maintained separately so the user must configure, integrate, and deploy them as a cohesive functional system. This can be very challenging especially for organizations such as universities building cubesats that have minimal experience developing FSW. Supporting universities was one of the primary motivators for releasing the cFS under NOSA. This paper describes the OpenSatKit that was developed to address the cFS deployment challenges and to serve as a cFS training platform for new users. It provides a fully functional out-of-the box software system that includes NASA's cFS, Ball Aerospace's command and control system COSMOS, and a NASA dynamic simulator called 42. The kit is freely available since all of the components have been released as open source. The kit runs on a Linux platform, includes 8 cFS applications, several kit-specific applications, and built in demos illustrating how to use key application features. It also includes the software necessary to port the cFS to a Raspberry Pi and instructions for configuring COSMOS to communicate with the target. All of the demos and test scripts can be rerun unchanged with the cFS running on the Raspberry Pi. The cFS uses a 3-tiered layered architecture including a platform abstraction layer, a Core Flight Executive (cFE) middle layer, and an application layer. Similar to smart phones, the cFS application layer is the key architectural feature for users to extend the FSW functionality to meet their mission-specific requirements. The platform abstraction layer and the cFE layers go a step further than smart phones by providing a platform-agnostic Application Programmer Interface (API) that allows applications to run unchanged on different platforms. OpenSatKit can serve two significant architectural roles that will further help the adoption of the cFS and help create a community of users that can share assets. First, the kit is being enhanced to automate the integration of applications with the goal of creating a virtual cFS "App Store".. Second, a platform certification test suite can be developed that would allow users to verify the port of the cFS to a new platform. This paper will describe the current state of these efforts and future plans.

Computer Programming and Software↗