Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “DATA PROCESSOR”

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 1,315 records · Page 73
All sourcesNASA NTRSDOE OSTI
DOE OSTI2013

Mechanism of supporting sub-communicator collectives with O(64) counters as opposed to one counter for each sub-communicator

A system and method for enhancing barrier collective synchronization on a computer system comprises a computer system including a data storage device. The computer system includes a program stored in the data storage device and steps of the program being executed by a processor. The system includes providing a plurality of communicators for storing state information for a bather algorithm. Each communicator designates a master core in a multi-processor environment of the computer system. The system allocates or designates one counter for each of a plurality of threads. The system configures a table with a number of entries equal to the maximum number of threads. The system sets a table entry with an ID associated with a communicator when a process thread initiates a collective. The system determines an allocated or designated counter by searching entries in the table.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2013

Mechanism of supporting sub-communicator collectives with O(64) counters as opposed to one counter for each sub-communicator

A system and method for enhancing barrier collective synchronization on a computer system comprises a computer system including a data storage device. The computer system includes a program stored in the data storage device and steps of the program being executed by a processor. The system includes providing a plurality of communicators for storing state information for a bather algorithm. Each communicator designates a master core in a multi-processor environment of the computer system. The system allocates or designates one counter for each of a plurality of threads. The system configures a table with a number of entries equal to the maximum number of threads. The system sets a table entry with an ID associated with a communicator when a process thread initiates a collective. The system determines an allocated or designated counter by searching entries in the table.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2016

Mechanism of supporting sub-communicator collectives with o(64) counters as opposed to one counter for each sub-communicator

A system and method for enhancing barrier collective synchronization on a computer system comprises a computer system including a data storage device. The computer system includes a program stored in the data storage device and steps of the program being executed by a processor. The system includes providing a plurality of communicators for storing state information for a barrier algorithm. Each communicator designates a master core in a multi-processor environment of the computer system. The system allocates or designates one counter for each of a plurality of threads. The system configures a table with a number of entries equal to the maximum number of threads. The system sets a table entry with an ID associated with a communicator when a process thread initiates a collective. The system determines an allocated or designated counter by searching entries in the table.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2016

AutoSIM

AutoSIM enables several instances of an executable to run in parallel on a directory of input files and consolidate results, at scale on the world's fastest supercomputers. The software accomplishes this by balancing compression, transmission, and computation of input files, executables, and output files to allow scalable parallel runs of any executable. The software breaks-up simulations into a configurable number of "churns" or sequential instances of executable invocations on a configurable number of cores/node. It sends the executable, supporting files, and appropriate number of input files to each node for independent execution, and then transfers the executable results to a shared disk for post-processing analysis. This MPI-based code has been demonstrated using EnergyPlus, DOE's flagship whole-building simulation engine, but was architected to allow scalable runtime of any software for any application (e.g. sensitivity analysis and uncertainty quantification). The code has also been demonstrated to scale on the Titan supercomputer using 131,072 processors to run 524,288 EnergyPlus annual simulations, and write 45TB of data to disk in 68 mins 08 secs.

New, Joshua R↗
DOE OSTI2019

Blended service schedule for a power generator

A power generation system includes a power generator operatively connected to a plurality of sensors and a processor. The processor is configured to observe usage-based or event-based data regarding one or more components and consumables of the power generator. A usage-based service schedule is observed for the one or more event-based components and consumables. Operation-based data is received from the plurality of sensors regarding the functioning of the power generation system and one or more operation-based components and consumables of the power generator. An operation-based service schedule is determined for the one or more operation-based components and consumables based on the operation-based data. A blended service schedule is generated, the blended service schedule including the usage-based service schedule and the operation-based service schedule. The blended service schedule is then provided to at least one of a local monitor or a remote monitor.

Keene, Kevin↗
DOE OSTI2020

Method and apparatus for scheduling in a non-uniform compute device

A data processing apparatus, and method of operation thereof, for executing instructions. The apparatus includes one or more host processors, each having a first processing unit, and a multi-level memory system. One or more levels of the memory system are tightly coupled to a corresponding second processing unit. At least one of the host processors includes an instruction scheduler that routes instructions selectively to at least one of the first and second processing units, dependent upon the availability of the processing units and the location, within the memory system, of data to be used when executing the instructions.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS1994

Remote Objects Message Exchange (ROME)

The performance of a single program running on a single processor is limited by the character of the processor. Moreover, the cost and difficulty of developing and sustaining programs tend to increase as their size and complexity increase. Clearly there ought to be some advantage in partitioning powerful application software in relatively small and simple components that can run in parallel on multiple processors; the software should run faster and it should be cheaper and easier to deploy. Remote Objects Message Exchange (ROME) is an attempt to provide a single relatively simple, universally available abstraction for data communication among C++ objects. It aims to enable the C++ application developer to specify objects' interactions with other objects wholly in terms of the application domain, without concern for details of interprocess communication. Every ROME-compliant object is conceptually a network peer of every other, as if each one were (for example) a separate UNIX process.

processors application software data communication↗
NASA NTRS2023

Space Networking Implementation for Lunar Operations

The High-Rate Delay Tolerant Networking (HDTN) project at NASA has developed a performance optimized and open-source Delay Tolerant Networking (DTN) implementation. The primary goal is to create a scalable networking solution to increase the scientific data return rate of space missions. To reach this goal, HDTN must span multiple edge cases in space networking by including tools and configurations to accommodate a wide range of space systems. Typically, HDTN evaluations are conducted on a laboratory emulation test bed, made up of hardware accelerated x86 based systems capable of data rates over 10 Gbps. HDTN must have an effective implementation process on a wide range of systems to increase the sustainability of the design. One important implementation option is with low-level embedded systems which could be used on small robotic missions. This paper details the implementation process, benchmark testing, and performance results of HDTN in multiple configurations on Raspberry Pi 4 devices. By implementing HDTN on a Raspberry Pi 4, a process for building HDTN onto ARM processors was developed and utilized to conduct benchmark tests in multiple network configurations, achieving a data rate performance exceeding 600 Mbps. Based on these results, HDTN proved to run on small ARM based systems with slight modifications to the build procedure. These results were then extended to evaluating an implementation of the HDTN software parsed across several Raspberry Pi 4 nodes. To test this capability, HDTN was configured in a simplified cut-through setup and distributed among multiple Raspberry Pi 4 processors. This distributed architecture was benchmark tested in a similar fashion to the testing of a singular HDTN implementation. The results from the benchmark testing are used to examine how these implementation options and capabilities can expand the use cases for DTN, and particularly with small robotic missions.

Space Networking↗
NASA NTRS2003

SpaceWire Driver Software for Special DSPs

A computer program provides a high-level C-language interface to electronics circuitry that controls a SpaceWire interface in a system based on a space qualified version of the ADSP-21020 digital signal processor (DSP). SpaceWire is a spacecraft-oriented standard for packet-switching data-communication networks that comprise nodes connected through bidirectional digital serial links that utilize low-voltage differential signaling (LVDS). The software is tailored to the SMCS-332 application-specific integrated circuit (ASIC) (also available as the TSS901E), which provides three highspeed (150 Mbps) serial point-to-point links compliant with the proposed Institute of Electrical and Electronics Engineers (IEEE) Standard 1355.2 and equivalent European Space Agency (ESA) Standard ECSS-E-50-12. In the specific application of this software, the SpaceWire ASIC was combined with the DSP processor, memory, and control logic in a Multi-Chip Module DSP (MCM-DSP). The software is a collection of low-level driver routines that provide a simple message-passing application programming interface (API) for software running on the DSP. Routines are provided for interrupt-driven access to the two styles of interface provided by the SMCS: (1) the "word at a time" conventional host interface (HOCI); and (2) a higher performance "dual port memory" style interface (COMI).

Clark, Douglas↗
NASA NTRS2015

The Ocean Colour Climate Change Initiative: I. A Methodology for Assessing Atmospheric Correction Processors Based on In-Situ Measurements

The Ocean Colour Climate Change Initiative intends to provide a long-term time series of ocean colour data and investigate the detectable climate impact. A reliable and stable atmospheric correction procedure is the basis for ocean colour products of the necessary high quality. In order to guarantee an objective selection from a set of four atmospheric correction processors, the common validation strategy of comparisons between in-situ and satellite derived water leaving reflectance spectra, is extended by a ranking system. In principle, the statistical parameters such as root mean square error, bias, etc. and measures of goodness of fit, are transformed into relative scores, which evaluate the relationship of quality dependent on the algorithms under study. The sensitivity of these scores to the selected database has been assessed by a bootstrapping exercise, which allows identification of the uncertainty in the scoring results. Although the presented methodology is intended to be used in an algorithm selection process, this paper focusses on the scope of the methodology rather than the properties of the individual processors.

Climate Change↗
NASA NTRS2003

Evaluation of Algorithms for Compressing Hyperspectral Data

With EO-1 Hyperion in orbit NASA is showing their continued commitment to hyperspectral imaging (HSI). As HSI sensor technology continues to mature, the ever-increasing amounts of sensor data generated will result in a need for more cost effective communication and data handling systems. Lockheed Martin, with considerable experience in spacecraft design and developing special purpose onboard processors, has teamed with Applied Signal & Image Technology (ASIT), who has an extensive heritage in HSI spectral compression and Mapping Science (MSI) for JPEG 2000 spatial compression expertise, to develop a real-time and intelligent onboard processing (OBP) system to reduce HSI sensor downlink requirements. Our goal is to reduce the downlink requirement by a factor > 100, while retaining the necessary spectral and spatial fidelity of the sensor data needed to satisfy the many science, military, and intelligence goals of these systems. Our compression algorithms leverage commercial-off-the-shelf (COTS) spectral and spatial exploitation algorithms. We are currently in the process of evaluating these compression algorithms using statistical analysis and NASA scientists. We are also developing special purpose processors for executing these algorithms onboard a spacecraft.

Cook, Sid↗
NASA NTRS1990

General purpose intelligent sensor interface

The long range goal is to develop an intelligent sensor system that will simplify the design and development of expert systems that use sensors of physical phenomena as a source of input data. This phase of the research concentrated on the integration of image processing sensors with expert system environments. The anticipated result of this research is the ability to design systems in which the user will not need to be an expert in such areas as image processing algorithms, local area networks, image processor hardware selection or interfacing, or television cameras selection. The user will be able to access data from video sensors through standard expert system statements without any need to know about the sensor hardware or software.

Mckee, J. W.↗
DOE OSTI2019

Quantum Associative Memory in Hep Track Pattern Recognition

We have entered the Noisy Intermediate-Scale Quantum Era. A plethora of quantum processor prototypes allow evaluation of potential of the Quantum Computing paradigm in applications to pressing computational problems of the future. Growing data input rates and detector resolution foreseen in High-Energy LHC (2030s) experiments expose the often high time and/or space complexity of classical algorithms. Quantum algorithms can potentially become the lower-complexity alternatives in such cases. In this work we discuss the potential of Quantum Associative Memory (QuAM) in the context of LHC data triggering. We examine the practical limits of storage capacity, as well as store and recall errorless efficiency, from the viewpoints of the state-of-the-art IBM quantum processors and LHC real-time charged track pattern recognition requirements. We present a software prototype implementation of the QuAM protocols and analyze the topological limitations for porting the simplest QuAM instances to the public IBM 5Q and 14Q cloud-based superconducting chips.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS1977

Data processing for the DMSP microwave radiometer system

A software program was developed and tested to process microwave radiometry data to be acquired by the microwave sensor (SSM/T) on the Defense Meteorological Satellite Program spacecraft. The SSM/T 7-channel microwave radiometer and systems data will be data-linked to Air Force Global Weather Central (AFGWC) where they will be merged with ephemeris data prior to product processing for use in the AFGWC upper air data base (UADB). The overall system utilizes an integrated design to provide atmospheric temperature soundings for global applications. The fully automated processing at AFGWC was accomplished by four related computer processor programs to produce compatible UADB soundings, evaluate system performance, and update the a priori developed inversion matrices. Tests with simulated data produced results significantly better than climatology.

Rigone, J. L.↗
NASA NTRS2023

Development of Two High-Energy Bus ‘Cores’ for Rapid Support of Low-TRL and Educational Payloads: A Software-Configured EPS Combined with Flexible C&DH

For several years the TechEdSat flight series (TES-n), developed by the Nano Orbital Workshop (NOW) group at NASA Ames, has relied upon an in-house developed unit to serve both EPS (Electrical Power System) and C&DH (Command and Data Handling) roles along with low data-rate telemetry functions, i.e., serving as the ‘core’ of the spacecraft bus. This ‘core’ has a considerable task given the rapid cadence of the TES program and the typically low-TRL of payloads; configurability and compatibility are key to prevent mission-specific hardware. However, at only 15 watts the current core has become insufficient to support the program’s growing missions and increasingly demanding payloads. To this end, the NOW program is developing new cores to support two TES mission classes: a single-PCB ‘MiniCore’ designed to support 80-watt missions 6U or smaller in LEO, and a three-PCB, radiation-tolerant ‘StackCore’ designed to support 6U and larger missions over 500 watts in LEO and beyond. The ‘MiniCore’ design consists of three main segments: a processor-agnostic C&DH, a software-configured EPS, and a backup low data-rate radio. The design philosophy was to enable rapid-manufacture in a turbulent supply chain, hence the design consists of COTS parts with a focus on those able to be drop-in replaced with radiation-tolerant versions when demanded by the mission. As a single PC-104 sized circuit board, power density and ease of integration also dominated design, demanding the use of modern features such as single-point USB-C for easy charging and monitoring of the spacecraft on the ground. The ‘MiniCore’ can support 80 watts of load, 140 watt-hours of storage, and over 20 watts of optimized solar generation with extensive power monitoring throughout. The ‘MiniCore’ supports one battery pack, six solar-panels, six loads, five actuators, Iridium SBD, and an internal 802.15.4 network. Additionally, the processor-agnostic design can accept any PJRC Teensy 3.x or Adafruit Feather microcontroller unit to enable processor scaling with mission requirements or environment. It is expected a development unit of this design will be completed before conference. The ‘StackCore’ design consists of three stacked PC-104 sized circuit boards: one dedicated to power generation and storage, one dedicated to power distribution, and one dedicated to C&DH tasks. This delineation is necessary to support the transition from highly integrated ICs to discrete analog circuitry, enabling a primarily analog control power system able to operate without software in a radiation environment with finer monitoring compared to the ‘MiniCore’ design. The planned base architecture supports over 500 watts of load, 250 watt-hours of storage, and over 80 watts of optimized solar generation. The power distribution board allows for the use of daughter cards hosting custom converters or interfaces for payloads, in addition to the software-configured supplies used on the ‘MiniCore’. This core stack will be managed by a Vorago ARM M4 microcontroller and support the same wireless communications as the ‘MiniCore’, with optional integration of a NOW S-band radio and attitude determination sensors for ‘black box’ functionality. It is expected the prototype will still be in development during conference.

Spacecraft↗
NASA NTRSDate not supplied

Development of Two High-Energy Bus ‘Cores’ for Rapid Support of Low-TRL and Educational Payloads: A Software-Configured EPS Combined with Flexible C&DH

For several years the TechEdSat flight series (TES-n), developed by the Nano Orbital Workshop (NOW) group at NASA Ames, has relied upon an in-house developed unit to serve both EPS (Electrical Power System) and C&DH (Command and Data Handling) roles along with low data-rate telemetry functions, i.e., serving as the ‘core’ of the spacecraft bus. This ‘core’ has a considerable task given the rapid cadence of the TES program and the typically low-TRL of payloads; configurability and compatibility are key to prevent mission-specific hardware. However, at only 15 watts the current core has become insufficient to support the program’s growing missions and increasingly demanding payloads. To this end, the NOW program is developing new cores to support two TES mission classes: a single-PCB ‘MiniCore’ designed to support 80-watt missions 6U or smaller in LEO, and a three-PCB, radiation-tolerant ‘StackCore’ designed to support 6U and larger missions over 500 watts in LEO and beyond. The ‘MiniCore’ design consists of three main segments: a processor-agnostic C&DH, a software-configured EPS, and a backup low data-rate radio. The design philosophy was to enable rapid-manufacture in a turbulent supply chain, hence the design consists of COTS parts with a focus on those able to be drop-in replaced with radiation-tolerant versions when demanded by the mission. As a single PC-104 sized circuit board, power density and ease of integration also dominated design, demanding the use of modern features such as single-point USB-C for easy charging and monitoring of the spacecraft on the ground. The ‘MiniCore’ can support 80 watts of load, 140 watt-hours of storage, and over 20 watts of optimized solar generation with extensive power monitoring throughout. The ‘MiniCore’ supports one battery pack, six solar-panels, six loads, five actuators, Iridium SBD, and an internal 802.15.4 network. Additionally, the processor-agnostic design can accept any PJRC Teensy 3.x or Adafruit Feather microcontroller unit to enable processor scaling with mission requirements or environment. It is expected a development unit of this design will be completed before conference. The ‘StackCore’ design consists of three stacked PC-104 sized circuit boards: one dedicated to power generation and storage, one dedicated to power distribution, and one dedicated to C&DH tasks. This delineation is necessary to support the transition from highly integrated ICs to discrete analog circuitry, enabling a primarily analog control power system able to operate without software in a radiation environment with finer monitoring compared to the ‘MiniCore’ design. The planned base architecture supports over 500 watts of load, 250 watt-hours of storage, and over 80 watts of optimized solar generation. The power distribution board allows for the use of daughter cards hosting custom converters or interfaces for payloads, in addition to the software-configured supplies used on the ‘MiniCore’. This core stack will be managed by a Vorago ARM M4 microcontroller and support the same wireless communications as the ‘MiniCore’, with optional integration of a NOW S-band radio and attitude determination sensors for ‘black box’ functionality. It is expected the prototype will still be in development during conference.

Spacecraft↗
NASA NTRSDate not supplied

Development of Two High-Energy Bus ‘Cores’

For several years the TechEdSat flight series (TES-n), developed by the Nano Orbital Workshop (NOW) group at NASA Ames, has relied upon an in-house developed unit to serve both EPS (Electrical Power System) and C&DH (Command and Data Handling) roles along with low data-rate telemetry functions, i.e., serving as the ‘core’ of the spacecraft bus. This ‘core’ has a considerable task given the rapid cadence of the TES program and the typically low-TRL of payloads; configurability and compatibility are key to prevent mission-specific hardware. However, at only 15 watts the current core has become insufficient to support the program’s growing missions and increasingly demanding payloads. To this end, the NOW program is developing new cores to support two TES mission classes: a single-PCB ‘MiniCore’ designed to support 80-watt missions 6U or smaller in LEO, and a three-PCB, radiation-tolerant ‘StackCore’ designed to support 6U and larger missions over 500 watts in LEO and beyond. The ‘MiniCore’ design consists of three main segments: a processor-agnostic C&DH, a software-configured EPS, and a backup low data-rate radio. The design philosophy was to enable rapid-manufacture in a turbulent supply chain, hence the design consists of COTS parts with a focus on those able to be drop-in replaced with radiation-tolerant versions when demanded by the mission. As a single PC-104 sized circuit board, power density and ease of integration also dominated design, demanding the use of modern features such as single-point USB-C for easy charging and monitoring of the spacecraft on the ground. The ‘MiniCore’ can support 80 watts of load, 140 watt-hours of storage, and over 20 watts of optimized solar generation with extensive power monitoring throughout. The ‘MiniCore’ supports one battery pack, six solar-panels, six loads, five actuators, Iridium SBD, and an internal 802.15.4 network. Additionally, the processor-agnostic design can accept any PJRC Teensy 3.x or Adafruit Feather microcontroller unit to enable processor scaling with mission requirements or environment. It is expected a development unit of this design will be completed before conference. The ‘StackCore’ design consists of three stacked PC-104 sized circuit boards: one dedicated to power generation and storage, one dedicated to power distribution, and one dedicated to C&DH tasks. This delineation is necessary to support the transition from highly integrated ICs to discrete analog circuitry, enabling a primarily analog control power system able to operate without software in a radiation environment with finer monitoring compared to the ‘MiniCore’ design. The planned base architecture supports over 500 watts of load, 250 watt-hours of storage, and over 80 watts of optimized solar generation. The power distribution board allows for the use of daughter cards hosting custom converters or interfaces for payloads, in addition to the software-configured supplies used on the ‘MiniCore’. This core stack will be managed by a Vorago ARM M4 microcontroller and support the same wireless communications as the ‘MiniCore’, with optional integration of a NOW S-band radio and attitude determination sensors for ‘black box’ functionality. It is expected the prototype will still be in development during conference.

Avery Brock↗
NASA NTRSDate not supplied

Benefits of using Electronic Data Sheets (EDS) with coreFlight Systems (cFS) - A Project Example

Recently there has been interest in the incorporation of core Flight Systems (cFS) with Spacecraft Onboard Interface Services (SOIS) Electronic Data Sheets (EDS) in the spaceflight software community. The Regenerative Fuel Cell project at the Glenn Research Center is using cFS architecture with EDS support for its monitoring and control software. The presentation will outline the benefits to using cFS with EDS support: First, EDS establishes a single source of truth for the definitions of data structures used throughout an entire mission that may otherwise be programmed in different languages and designed with different processor architectures. Not only does this help with inter-application communication via the software bus, but it also greatly simplifies communication between systems. An EDS Application Programming Interface (API) library allows the conversion of EDS data structures to and from native data structures. Second, bindings for other programming languages (e.g. Lua, Python, JSON) have been written to allow the creation and manipulation of EDS data objects within those languages. The RFC project uses Lua scripts to automatically generate binary configuration files at build time to be loaded into our cFS programs. We also use Python bindings in a graphical user interface (GUI) to allow an operator to send commands and view telemetry messages sent from cFS instances. Finally, using Lua scripts we can set up specific simulation scenarios to perform automatic functional testing. During the development of the RFC software, the software team put together a generic python GUI called “cFS-EDS-GroundStation” that provides a basic interface to an instance of cFS with EDS support. The GUI includes a basic telecommand and telemetry system that reads directly from the generated EDS databases. In the telecommand system, dropdown menus are populated with all user commands that are defined in EDS. In the telemetry system, telemetry messages are automatically decoded, written to the screen, and saved to a binary file. Additional Python scripts have been written to convert the binary data files into a comma separated value (CSV) format for further processing. We will demonstrate the basic use of the cFS-EDS-GroundStation software including adding additional commands and telemetry payload values in EDS and see them appear automatically in the cFS-EDS-Groundstation software. About the RFC project: The Regenerative Fuel Cell project is tasked with developing and demonstrating a power system consisting of a fuel cell and electrolyzer to provide power during a lunar day/night cycle. During the night, the fuel cell takes Hydrogen and Oxygen gasses and converts them into electricity, water, and heat. During the day, the electrolyzer takes input power (e.g. from a photovoltaic array) and converts water back into Hydrogen and Oxygen gasses.

Mathew Mccaskey↗