Search NASA⌕ Search

SEARCH · Search NASA

Results for “Software interfaces”

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 271 records · Page 15
All sourcesNASA NTRSDOE OSTI
DOE OSTI2024

Development of Real-Time High-Density Pulsar Data Transmission and Processing for Grid Synchronization

Taking advantage of the extreme stability of the pulsar period, it can serve as the timing source for grid synchronization to compensate for the timing drift instigated by the loss of GPS signal. Nevertheless, the real-time transmission and processing of the pulsar data suffer from its high-frequency data rate, varying from megahertz to gigahertz, resulting in reduced computing speed and increased time delay. To mitigate this issue, the hardware and software frameworks are implemented for the high-density pulsar data transmission and processing for grid synchronization in this research. Initially, the high-density pulsar data is transferred using open-source software. The complementary duty cycle timing module is designed to coordinate the operation of the dual-channel high-speed interface and software. Subsequently, the multiple-threading is applied to the receiving, parsing, and splicing pulsar data. Next, the pulsar signal extraction method is implemented based on the polyphase filterbank and time of arrival estimation. Ultimately, real-time performance verification experiments are carried out for different components under two hardware platforms. Finally, the results demonstrate that only 0.482 s is required for processing 4 Gigabyte data through multiple-threading, which is 3.8 times faster than the single thread. The pulsar signal extraction can also be executed within 707 ms for 4.8 seconds of data, thereby indicating that real-time requirements can be met.

24 POWER TRANSMISSION AND DISTRIBUTION↗
DOE OSTI2023

Cross-Facility Orchestration of Electrochemistry Experiments and Computations

Instrument-computing ecosystems supporting automated electrochemical workflows typically require the integration of disparate instruments such as syringe pump, fraction collector, and potentiostat, all connected to an electrochemical cell. These specialized instruments with custom software and interfaces are not typically designed for network integration and remote automation. We developed a networked ecosystem of these instruments and computing platforms, which includes software to enable automated workflow orchestration from remote computers. Specifically, we developed Python wrappers of APIs and custom Pyro client-server modules to support remote operation of these instruments over the ecosystem network. Herein, we describe a specific workflow for generating and validating voltammogram (I-V) measurements of an electrolyte solution pumped into the electrochemical cell. We demonstrate the orchestration of this workflow which is composed using a Jupyter notebook and executed on a remote computer.

Al Najjar, Anees↗
NASA NTRS2003

The Logical Extension

The same software controlling autonomous and crew-assisted operations for the International Space Station (ISS) is enabling commercial enterprises to integrate and automate manual operations, also known as decision logic, in real time across complex and disparate networked applications, databases, servers, and other devices, all with quantifiable business benefits. Auspice Corporation, of Framingham, Massachusetts, developed the Auspice TLX (The Logical Extension) software platform to effectively mimic the human decision-making process. Auspice TLX automates operations across extended enterprise systems, where any given infrastructure can include thousands of computers, servers, switches, and modems that are connected, and therefore, dependent upon each other. The concept behind the Auspice software spawned from a computer program originally developed in 1981 by Cambridge, Massachusetts-based Draper Laboratory for simulating tasks performed by astronauts aboard the Space Shuttle. At the time, the Space Shuttle Program was dependent upon paper-based procedures for its manned space missions, which typically averaged 2 weeks in duration. As the Shuttle Program progressed, NASA began increasing the length of manned missions in preparation for a more permanent space habitat. Acknowledging the need to relinquish paper-based procedures in favor of an electronic processing format to properly monitor and manage the complexities of these longer missions, NASA realized that Draper's task simulation software could be applied to its vision of year-round space occupancy. In 1992, Draper was awarded a NASA contract to build User Interface Language software to enable autonomous operations of a multitude of functions on Space Station Freedom (the station was redesigned in 1993 and converted into the international venture known today as the ISS)

Source record↗
NASA NTRS2017

Application of the Core Flight System to a Lunar Rover

Resource Prospector (RP) is a lunar mission sponsored by NASAs Advanced Exploration Systems (AES) division, that aims to study in-situ resource utilization (ISRU) feasibility and technologies on the surface of the moon. The RP missions lunar surface segment includes a rover equipped with with a suite of instruments specifically designed to measure and map volatiles both at the surface and in the subsurface. Of particular interest is the quantity and state of volatiles in permanently shadowed regions. To conduct the mission, ground system operators will remotely drive the rover, directing it to waypoints along the surface in order to achieve measurement objectives. At selected locations, an onboard drill will be deployed to collect material and obtain direct measurements of the subsurface constituents. RP is currently planned for launch in 2022. RP is managed at NASA Ames Research Center. The RP Rover is being designed and developed by NASA Johnson Space Center (JSC) in partnership with NASA Ames. NASA Kennedy Space Center (KSC) is responsible for the Honeybee drilling system and science payload.In order to better understand the technical challenges and demonstrate capability, in 2015 the RP project developed a rover testbed (known as RP15). In this mission in a year, a rover was designed, developed, and outfitted with science instruments and a drill. The rover was operated from a remote operations center, and operated in an outdoor lunar rock yard at Johnson space center. The study was a resounding success meeting all objectives. The RP Rover software architecture and development processes were based on the successful Lunar Atmosphere and Dust Environment Explorer spacecraft. This architecture is built on the Core Flight System software and an interface to MatlabSimulink auto-generated software components known as the Simulink Interface Layer (SIL). The application of this lunar satellite inspired framework worked well for the rover application, and is currently being planned for the mission. This presentation provides an overview of the architecture and processes, and describes some of the changes and challenges for the rover application.

CFS↗
NASA NTRS2017

Application of CFS to a Lunar Rover: Resource Prospector (RP)

Resource Prospector (RP) is a lunar mission sponsored by NASA's Advanced Exploration Systems (AES) division, that aims to study in-situ resource utilization (ISRU) feasibility and technologies on the surface of the moon. The RP mission's lunar surface segment includes a rover equipped with with a suite of instruments specifically designed to measure and map volatiles both at the surface and in the subsurface. Of particular interest is the quantity and state of volatiles in permanently shadowed regions. To conduct the mission, ground system operators will remotely drive the rover, directing it to waypoints along the surface in order to achieve measurement objectives. At selected locations, an onboard drill will be deployed to collect material and obtain direct measurements of the subsurface constituents. RP is currently planned for launch in 2022. RP is managed at NASA Ames Research Center. The RP Rover is being designed and developed by NASA Johnson Space Center (JSC) in partnership with NASA Ames. NASA Kennedy Space Center (KSC) is responsible for the Honeybee drilling system and science payload. In order to better understand the technical challenges and demonstrate capability, in 2015 the RP project developed a rover testbed (known as RP15). In this mission in a year, a rover was designed, developed, and outfitted with science instruments and a drill. The rover was operated from a remote operations center, and operated in an outdoor lunar rock yard at Johnson space center. The study was a resounding success meeting all objectives. The RP Rover software architecture and development processes were based on the successful Lunar Atmosphere and Dust Environment Explorer spacecraft. This architecture is built on the Core Flight System software and an interface to Matlab/Simulink auto-generated software components known as the Simulink Interface Layer (SIL). The application of this lunar satellite inspired framework worked well for the rover application, and is currently being planned for the mission. This presentation provides an overview of the architecture and processes, and describes some of the changes and challenges for the rover application.

RP↗
DOE OSTI2019

From Data to Models and Analytics: An Integrated Scientific Computing Platform to Accelerate Environmental Research SBIR Phase I (Final Technical Report)

Phase I research was conducted to investigate the technical feasibility of an integrated open source platform GeoLib to provide turnkey solutions for model-data integration for environmental systems science (ESS), using modern web technologies, advances in HPC and cloud computing and high-performance visualization. A key feature of our platform is that it minimizes and automates data movement between data storage and computing systems. Another critical feature of the design is that it enables users to perform high-fidelity post-processing by performing high-performance visualization server-side and in-situ on the compute cluster close to the data. The investigation, which was performed over a 12-month period ending April 2019, centered on developing prototype software to demonstrate the key enabling technologies required for this system. This included: (i) rapid access to data from multiple remote sources, via a unified data interface; (ii) software for scalable geospatial visualization of raster, vector, and point cloud data on the web; (iii) development of an easy-to-use API for creating simulation and modeling workflows; (iv) remote data visualization and processing on middle-tier servers; and (v) remote data processing on high-performance computing systems. A critical part of this work is that all of these capabilities be accessible to end users through standard desktop tools such as Project Jupyter, which is widely adopted for ESS simulation and modeling.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS1981

A prototype interface unit for microprocessor based Loran-C receiver

An inexpensive data/command entry and CRT display system capable of alphanumeric and graphics moe operation and designed to operate in place of a separate ASCII terminal, is documented. The software to interface this unit to the 6502-based Loran C receiver is also described. The system simplifies receiver operations to a level typical of current avionics systems.

Novacki, S. M., III↗
NASA NTRS1997

Of red planets and indigo computers: Mars database visualization as an example of platform downsizing

The last decade has witnessed tremendous advancements in the computer hardware and software used to perform scientific visualization. In this paper, we consider how the visualization of a particular data set, the digital terrain model derived from the Viking orbiter imagery, has been realized in four distinct projects over this period. These examples serve to demonstrate how the vast improvements in computational performance both decrease the cost of such visualization efforts and permit an increasing level of interactivity. We then consider how even today's graphical systems require the visualization designer to make intelligent choices and tradeoffs in database rendering. Finally, we discuss how insights gleaned from an understanding of human visual perception can guide these design decisions, and suggest new options for visualization hardware and software.

NASA Center ARC↗
NASA NTRS1993

An investigative study of multispectral data compression for remotely-sensed images using vector quantization and difference-mapped shift-coding

A study is conducted to investigate the effects and advantages of data compression techniques on multispectral imagery data acquired by NASA's airborne scanners at the Stennis Space Center. The first technique used was vector quantization. The vector is defined in the multispectral imagery context as an array of pixels from the same location from each channel. The error obtained in substituting the reconstructed images for the original set is compared for different compression ratios. Also, the eigenvalues of the covariance matrix obtained from the reconstructed data set are compared with the eigenvalues of the original set. The effects of varying the size of the vector codebook on the quality of the compression and on subsequent classification are also presented. The output data from the Vector Quantization algorithm was further compressed by a lossless technique called Difference-mapped Shift-extended Huffman coding. The overall compression for 7 channels of data acquired by the Calibrated Airborne Multispectral Scanner (CAMS), with an RMS error of 15.8 pixels was 195:1 (0.41 bpp) and with an RMS error of 3.6 pixels was 18:1 (.447 bpp). The algorithms were implemented in software and interfaced with the help of dedicated image processing boards to an 80386 PC compatible computer. Modules were developed for the task of image compression and image analysis. Also, supporting software to perform image processing for visual display and interpretation of the compressed/classified images was developed.

Jaggi, S.↗
NASA NTRS2013

Develop a Model Component

During my internship at NASA, I was a model developer for Ground Support Equipment (GSE). The purpose of a model developer is to develop and unit test model component libraries (fluid, electrical, gas, etc.). The models are designed to simulate software for GSE (Ground Special Power, Crew Access Arm, Cryo, Fire and Leak Detection System, Environmental Control System (ECS), etc. ~.) before they are implemented into hardware. These models support verifying local control and remote software for End-Item Software Under Test (SUT). The model simulates the physical behavior (function, state, limits and 110) of each end-item and it's dependencies as defined in the Subsystem Interface Table, Software Requirements & Design Specification (SRDS), Ground Integrated Schematic (GIS), and System Mechanical Schematic.(SMS). The software of each specific model component is simulated through MATLAB's Simulink program. The intensiv~ model development life cycle is a.s follows: Identify source documents; identify model scope; update schedule; preliminary design review; develop model requirements; update model.. scope; update schedule; detailed design review; create/modify library component; implement library components reference; implement subsystem components; develop a test script; run the test script; develop users guide; send model out for peer review; the model is sent out for verific~tionlvalidation; if there is empirical data, a validation data package is generated; if there is not empirical data, a verification package is generated; the test results are then reviewed; and finally, the user. requests accreditation, and a statement of accreditation is prepared. Once each component model is reviewed and approved, they are intertwined together into one integrated model. This integrated model is then tested itself, through a test script and autotest, so that it can be concluded that all models work conjointly, for a single purpose. The component I was assigned, specifically, was a fluid component, a discrete pressure switch. The switch takes a fluid pressure input, and if the pressure is greater than a designated cutoff pressure, the switch would stop fluid flow.

Ensey, Tyler S.↗
DOE OSTI2024

Deep Learning for Fish Identification from Sonar Data (CRADA 481 Final Report)

In eastern regions of the United States, the American eel is a species of management and regulatory concern because of significant population declines, despite the species’ previous abundance in all tributaries of rivers flowing into the Atlantic Ocean. The American eel is also a candidate for listing under the U.S. Endangered Species Act. While hydropower construction and operation are only one of several factors contributing to this population decline, such a listing could impose additional regulatory challenges for a large number of hydropower projects. In this CRADA project, we improved technologies for identifying migrating eels with the goal of reducing the cost and time required for future American eel hydropower impact assessment and mitigation studies, while maintaining accuracy. We built on results from a previous FOA project (FOA# DE-FOA-0001662), led by the Electric Power Research Institute (EPRI), which developed a highly accurate, deep-learning method for identifying migrating eels from imaging sonar data. The current study aimed to further optimize this deep-learning model, originally designed for image classification, and to develop an object detection software capable of identifying fish from sonar videos in real time, enabling the detection of events like fish migrations and specific species, such as the American eel, at hydropower dams. The data conversion algorithms were packaged as software with a graphical user interface, and the software is evaluated by external collaborators. We focused on the American eel in this project and explored the transferability of the developed deep learning models to the sea lamprey, given the similar body shape and swimming behavior between the two species.

13 HYDRO ENERGY↗
NASA NTRS1993

Real-time expert system diagnostics and monitoring for the High Resolution Microwave Survey Targeted Search

An automated monitoring and diagnostics system (MDS) using virtual real-time software was developed for NASA's High Resolution Microwave Survey (HRMS) Targeted Search System (TSS). The four main tasks required of the MDS were monitoring and recording system health, alerting operators of problems, diagnosing poor system performance, and performing an emergency system shutdown. The MDS was implemented using commercial expert system software tools in addition to interface hardware and software developed on site. The expert system used objects, rules, and schematics in its TSS knowledge representation. The MDS was successfully integrated into the HRMS computer environment, and its performance met or exceeded its requirements.

Macalou, A.↗
NASA NTRS1993

Analyzing Software Requirements Errors in Safety-Critical, Embedded Systems

This paper analyzes the root causes of safety-related software errors in safety-critical, embedded systems. The results show that software errors identified as potentially hazardous to the system tend to be produced by different error mechanisms than non- safety-related software errors. Safety-related software errors are shown to arise most commonly from (1) discrepancies between the documented requirements specifications and the requirements needed for correct functioning of the system and (2) misunderstandings of the software's interface with the rest of the system. The paper uses these results to identify methods by which requirements errors can be prevented. The goal is to reduce safety-related software errors and to enhance the safety of complex, embedded systems.

Lutz, Robyn R.↗
NASA NTRS2019

Medical Data Architecture (MDA) Project Status

The Medical Data Architecture (MDA) project supports the Exploration Medical Capability (ExMC) risk to minimize or reduce the risk of adverse health outcomes and decrements in performance due to in-flight medical capabilities on human exploration missions. To mitigate this risk, the ExMC MDA project addresses the technical limitations identified in ExMC Gap Med 07: We do not have the capability to comprehensively process medically-relevant information to support medical operations during exploration missions. This gap identifies that the current in-flight medical data management includes a combination of data collection and distribution methods that are minimally integrated with on-board medical devices and systems. Furthermore, there are a variety of data sources and methods of data collection. For an exploration mission, the seamless management of such data will enable a more medically autonomous crew than the current paradigm. The medical system requirements are being developed in parallel with the exploration mission architecture and vehicle design. ExMC has recognized that in order to make informed decisions about a medical data architecture framework, current methods for medical data management must not only be understood, but an architecture must also be identified that provides the crew with actionable insight to medical conditions. This medical data architecture will provide the necessary functionality to address the challenges of executing a self-contained medical system that approaches crew health care delivery without assistance from ground support. Hence, the products supported by current prototype development will directly inform exploration medical system requirements.In fiscal year 2018, the MDA project developed Test Bed 2, the second iteration in a series of prototypes with functionality focused on data security through role-based access control and encryption, integration with One Portal exercise software and ingestion of an ultrasound Digital Imaging and Communications in Medicine (DICOM) file and image display. Test Bed 2 advances the medical data system architecture framework by providing these functionalities in a scalable system that maintained a layered, modular design. The architecture framework uses a data services approach with role-based access to data in a customized medical record system suitable for space exploration. These functionalities were demonstrated as part of the Next Space Technologies for Exploration Partnerships (NextSTEP) ground test demonstrated at the NASA Johnson Space Center Integrated Power, Avionics and Software (iPAS) facility. Interfacing to a Core Flight Software (CFS) system, the MDA system, using Consultative Committee for Space Data Systems (CCSDS) protocol, transferred an exercise file from the simulated flight MDA system to a mirrored MDA system on the ground through the CFS system. The selection of data sources and demonstrations enabled the team to address stakeholder concerns throughout the development process. In the next iteration, the MDA team will work with stakeholders to identify additional relevant functionalities to further advance system data models, standards and principles that will inform the medical system requirements development.

medical data architecture↗
NASA NTRS1991

FAST - A multiprocessed environment for visualization of computational fluid dynamics

The paper presents the Flow Analysis Software Toolset (FAST) to be used for fluid-mechanics analysis. The design criteria for FAST including the minimization of the data path in the computational fluid-dynamics (CFD) process, consistent user interface, extensible software architecture, modularization, and the isolation of three-dimensional tasks from the application programmer are outlined. Each separate process communicates through the FAST Hub, while other modules such as FAST Central, NAS file input, CFD calculator, surface extractor and renderer, titler, tracer, and isolev might work together to generate the scene. An interprocess communication package making it possible for FAST to operate as a modular environment where resources could be shared among different machines as well as a single host is discussed.

Bancroft, Gordon V.↗
DOE OSTI2023

Moore Machine Motion Controls Refurbishment Statement of Work and Specification

Diamond Turning Machines known as “Moore” machines are used in the production of Potassium diHydrogen Phosphate (KDP) optics required for the National Ignition Facility (NIF). These machines are owned by the Department of Energy, as provided by Lawrence Livermore National Security LLC (LLNS). Moore Machines 1 and 2 are located at the Gooch & Housego (G&H) facility in Highland Heights, OH. The existing Aerotech motion controllers, motor drivers/amplifiers, input/output (I/O) hardware, control computer, software user interface, human machine interface (HMI), cabling, and encoders are beyond service life and require replacement. This Statement of Work (SoW) defines the motion control system refurbishment requirements for the Moore diamond turning machines designated Moore 1 and Moore 2. The motion controls system design shall include a motion control computer, control software, motor drive amplifiers and controllers, linear scale encoders, rotary encoders, HMI, power distribution, emergency stop (E-Stop) and interlocks, cabling, switches, solenoids, transducers, sensors, actuators, ancillary system interfaces, and related components necessary for a complete machine tool control system. The Subcontractor shall include effort to standardize systems between the two machines if reasonably possible.

42 ENGINEERING↗
NASA NTRS2018

Software and Human-Machine Interface Development for Environmental Controls Subsystem Support

The Space Launch System (SLS) is the next premier launch vehicle for NASA. It is the next stage of manned space exploration from American soil, and will be the platform in which we push further beyond Earth orbit. In preparation of the SLS maiden voyage on Exploration Mission 1 (EM-1), the existing ground support architecture at Kennedy Space Center required significant overhaul and updating. A comprehensive upgrade of controls systems was necessary, including programmable logic controller software, as well as Launch Control Center (LCC) firing room and local launch pad displays for technician use. Environmental control acts as an integral component in these systems, being the foremost system for conditioning the pad and extremely sensitive launch vehicle until T-0. The Environmental Controls Subsystem (ECS) required testing and modification to meet the requirements of the designed system, as well as the human factors requirements of NASA software for Validation and Verification (V&V). This term saw significant strides in the progress and functionality of the human-machine interfaces used at the launch pad, and improved integration with the controller code.

Dobson, Matthew↗