Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “application programming interface API”

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
NASA NTRSDate not supplied

Use of Assistive Technology to Augment API Capabilities

Application Programming Interfaces (APIs) allow for access to data and capabilities of computer applications by developers or users with experience in computer programming. Recent development with both Thermal Desktop and ESATAN-TMS have provided APIs to allow users to develop their own capabilities that interface with the Graphical User Interfaces (GUI) or manipulate the thermal model data. However, these APIs are only as good as the breadth of features in the native code accessible through the API. If a particular code’s feature is not accessible through the API, then users have very limited options besides waiting for updates to the API that expose the necessary functionality, particularly if model data access or user action, such as a button click, is required. However, Assistive Technology features that allow for users with a disability to more fully experience a software’s capabilities may be creatively utilized to gain further access to data and capabilities not yet exposed by the API. This paper describes the process to augment the features of the OpenTD API via assistive technology and describes how to identify the application instance, navigate GUI elements, updates values on forms, and execute actions such as selecting a listbox item or clicking a button. It concludes with identifying some of the pitfalls to avoid and describes methods to best implement this approach.

Application Programming Interface↗
NASA NTRSDate not supplied

Use of Assistive Technology to Augment API Capabilities

Application Programming Interfaces (APIs) allow for access to data and capabilities of computer applications by developers or users with experience in computer programming. Recent development with both Thermal Desktop and ESATAN-TMS have provided APIs to allow users to develop their own capabilities that interface with the Graphical User Interfaces (GUI) or manipulate the thermal model data. However, these APIs are only as good as the breadth of features in the native code accessible through the API; if a particular code’s feature is not accessible through the API, then users have very limited options besides waiting for updates to the API that expose the necessary functionality, particularly if model data access or user action, such as a button click, is required. However, Assistive Technology features that allow for differently-abled users to more fully experience a software’s capabilities may be creatively utilized to gain further access to data and capabilities not yet exposed by the API. This paper describes the process to augment the features of the OpenTD API via assistive technology and describes how to identify the application instance, navigate GUI elements, updates values on forms, and execute actions such as selecting a listbox item or clicking a button. It concludes with identifying some of the pitfalls to avoid and describes methods to best implement this approach.

Application Programming Interface↗
NASA NTRSDate not supplied

Interoperable Map Services with Performance Tuning for Earth Science Data through API-Tiles and Dynamic API-Styles

NASA’s Goddard Earth Sciences Data and Information Services Center (GES DISC) provides access to a wide range of global climate data from various satellite missions and models. However, the visualization and analysis of these data can be challenging due to their large volume, complex structure, and diverse formats. This study presents the implementation of interoperable map services (API-Maps) with performance tuning using API-Tiles and dynamic API-Styles. API-Maps is a standard for defining and exposing map services through RESTful (representational state transfer) APIs (application programming interfaces). API-Tiles is a technique for generating and delivering map tiles on demand from any data source. API-Styles is a method for dynamically applying styles to map tiles based on user preferences or data attributes. The use of API-Tiles and dynamic API-Styles enhances the performance and scalability of the map services, allowing for smooth and interactive visualization of large datasets. Two types of Earth Science data sources from the NASA GES DISC are used in the experiment: regularly gridded data, such as Global Precipitation Measurement (GPM) precipitation data, and low processing level data, such as low-level data of atmospheric composite measurements from the TROPOspheric Monitoring Instrument (TROPOMI) mission. Re-gridding of swath data (low level data - e.g. Level 2) of atmospheric composites (e.g. TROPOMI products, such as nitrogen dioxide, ozone and aerosol optical depth) is applied to enable the Web-based, interoperable, tiled, and styled mapping (rendering) services of such data. The results demonstrate the effectiveness of the proposed approach in providing fast and efficient access to Earth science data through interoperable map services.

Geographic Information System↗
NASA NTRS1996

A proposed application programming interface for a physical volume repository

The IEEE Storage System Standards Working Group (SSSWG) has developed the Reference Model for Open Storage Systems Interconnection, Mass Storage System Reference Model Version 5. This document, provides the framework for a series of standards for application and user interfaces to open storage systems. More recently, the SSSWG has been developing Application Programming Interfaces (APIs) for the individual components defined by the model. The API for the Physical Volume Repository is the most fully developed, but work is being done on APIs for the Physical Volume Library and for the Mover also. The SSSWG meets every other month, and meetings are open to all interested parties. The Physical Volume Repository (PVR) is responsible for managing the storage of removable media cartridges and for mounting and dismounting these cartridges onto drives. This document describes a model which defines a Physical Volume Repository, and gives a brief summary of the Application Programming Interface (API) which the IEEE Storage Systems Standards Working Group (SSSWG) is proposing as the standard interface for the PVR.

Jones, Merritt↗
DOE OSTI2026

Review of Particle Physics

The Review summarizes much of particle physics and cosmology. Using data from previous editions, plus 3,200 new measurements from 903 papers, we list, evaluate, and average measured properties of gauge bosons and the recently discovered Higgs boson, leptons, quarks, mesons, and baryons. We summarize searches for hypothetical particles such as supersymmetric particles, heavy bosons, axions, dark photons, etc. Particle properties and search limits are listed in Summary Tables. We give numerous tables, figures, formulae, and reviews of topics such as Higgs Boson Physics, Supersymmetry, Grand Unified Theories, Neutrino Mixing, Dark Energy, Dark Matter, Cosmology, Particle Detectors, Colliders, Probability and Statistics. Most of the 118 reviews are updated, including many that are heavily revised.

72 PHYSICS OF ELEMENTARY PARTICLES AND FIELDS↗
NASA NTRS1995

Fault recovery in the reliable multicast protocol

The Reliable Multicast Protocol (RMP) provides a unique, group-based model for distributed programs that need to handle reconfiguration events at the application layer. This model, called membership views, provides an abstraction in which events such as site failures, network partitions, and normal join-leave events are viewed as group reformations. RMP provides access to this model through an application programming interface (API) that notifies an application when a group is reformed as the result of a some event. RMP provides applications with reliable delivery of messages using an underlying IP Multicast (12, 5) media to other group members in a distributed environment even in the case of reformations. A distributed application can use various Quality of Service (QoS) levels provided by RMP to tolerate group reformations. This paper explores the implementation details of the mechanisms in RMP that provide distributed applications with membership view information and fault recovery capabilities.

Callahan, John R.↗
NASA NTRS1996

Specification and Design of a Fault Recovery Model for the Reliable Multicast Protocol

The Reliable Multicast Protocol (RMP) provides a unique, group-based model for distributed programs that need to handle reconfiguration events at the application layer. This model, called membership views, provides an abstraction in which events such as site failures, network partitions, and normal join-leave events are viewed as group reformations. RMP provides access to this model through an application programming interface (API) that notifies an application when a group is reformed as the result of a some event. RMP provides applications with reliable delivery of messages using an underlying IP Multicast media to other group members in a distributed environment even in the case of reformations. A distributed application can use various Quality of Service (QoS) levels provided by RMP to tolerate group reformations. This paper explores the implementation details of the mechanisms in RMP that provide distributed applications with membership view information and fault recovery capabilities.

Montgomery, Todd↗
NASA NTRS2007

Application-Program-Installer Builder

A computer program builds application programming interfaces (APIs) and related software components for installing and uninstalling application programs in any of a variety of computers and operating systems that support the Java programming language in its binary form. This program is partly similar in function to commercial (e.g., Install-Shield) software. This program is intended to enable satisfaction of a quasi-industry-standard set of requirements for a set of APIs that would enable such installation and uninstallation and that would avoid the pitfalls that are commonly encountered during installation of software. The requirements include the following: 1) Properly detecting prerequisites to an application program before performing the installation; 2) Properly registering component requirements; 3) Correctly measuring the required hard-disk space, including accounting for prerequisite components that have already been installed; and 4) Correctly uninstalling an application program. Correct uninstallation includes (1) detecting whether any component of the program to be removed is required by another program, (2) not removing that component, and (3) deleting references to requirements of the to-be-removed program for components of other programs so that those components can be properly removed at a later time.

Wolgast, Paul↗
NASA NTRS2011

S-Band POSIX Device Drivers for RTEMS

This is a set of POSIX device driver level abstractions in the RTEMS RTOS (Real-Time Executive for Multiprocessor Systems real-time operating system) to SBand radio hardware devices that have been instantiated in an FPGA (field-programmable gate array). These include A/D (analog-to-digital) sample capture, D/A (digital-to-analog) sample playback, PLL (phase-locked-loop) tuning, and PWM (pulse-width-modulation)-controlled gain. This software interfaces to Sband radio hardware in an attached Xilinx Virtex-2 FPGA. It uses plug-and-play device discovery to map memory to device IDs. Instead of interacting with hardware devices directly, using direct-memory mapped access at the application level, this driver provides an application programming interface (API) offering that easily uses standard POSIX function calls. This simplifies application programming, enables portability, and offers an additional level of protection to the hardware. There are three separate device drivers included in this package: sband_device (ADC capture and DAC playback), pll_device (RF front end PLL tuning), and pwm_device (RF front end AGC control).

Lux, James P.↗
NASA NTRSDate not supplied

Extending the Capabilities of Thermal Desktop with the OpenTD Application Programming Interface

With the release of Thermal Desktop 6.0, users now had the ability to interface with some of the many elements and constructs of a Thermal Desktop model through external applications developed using the TD API (Application Programming Interface). This file allows applications to be developed in the .NET framework and interface to a number of object types within a Thermal Desktop model. The release of 6.1 expands the subset of objects able to be manipulated and now includes the raw geometrical information of surfaces. With the release of 6.1, the API was now referred to as OpenTD. This paper discusses some of the utilities and capabilities developed using the OpenTD API at the NASA Goddard Space Flight Center. These include utilities to help with configuration control of models and case sets, addition of logic to better process heater performance, and a methodology implemented to allow for submodel level processing of radiation couplings to include smaller radks where needed in a cryogenic region without using the same criteria for the warmer portions of the model. This last utility is targeting a reduction in run time without sacrificing accuracy. Lastly, some lessons learned, work-arounds, and wishes for the next release of the OpenTD API are also presented.

Thermal Desktop↗
NASA NTRS1994

Coordinating complex decision support activities across distributed applications

Knowledge-based technologies have been applied successfully to automate planning and scheduling in many problem domains. Automation of decision support can be increased further by integrating task-specific applications with supporting database systems, and by coordinating interactions between such tools to facilitate collaborative activities. Unfortunately, the technical obstacles that must be overcome to achieve this vision of transparent, cooperative problem-solving are daunting. Intelligent decision support tools are typically developed for standalone use, rely on incompatible, task-specific representational models and application programming interfaces (API's), and run on heterogeneous computing platforms. Getting such applications to interact freely calls for platform independent capabilities for distributed communication, as well as tools for mapping information across disparate representations. Symbiotics is developing a layered set of software tools (called NetWorks! for integrating and coordinating heterogeneous distributed applications. he top layer of tools consists of an extensible set of generic, programmable coordination services. Developers access these services via high-level API's to implement the desired interactions between distributed applications.

Adler, Richard M.↗
NASA NTRS2003

Development of a Dynamically Configurable, Object-Oriented Framework for Distributed, Multi-modal Computational Aerospace Systems Simulation: Second Year Progress Report

Mesh generation has long been recognized as a bottleneck in the CFD process. While much research on automating the volume mesh generation process have been relatively successful,these methods rely on appropriate initial surface triangulation to work properly. Surface discretization has been one of the least automated steps in computational simulation due to its dependence on implicitly defined CAD surfaces and curves. Differences in CAD peometry engines manifest themselves in discrepancies in their interpretation of the same entities. This lack of "good" geometry causes significant problems for mesh generators, requiring users to "repair" the CAD geometry before mesh generation. The problem is exacerbated when CAD geometry is translated to other forms (e.g., IGES )which do not include important topological and construction information in addition to entity geometry. One technique to avoid these problems is to access the CAD geometry directly from the mesh generating software, rather than through files. By accessing the geometry model (not a discretized version) in its native environment, t h s a proach avoids translation to a format which can deplete the model of topological information. Our approach to enable models developed in the Denali software environment to directly access CAD geometry and functions is through an Application Programming Interface (API) known as CAPRI. CAPRI provides a layer of indirection through which CAD-specific data may be accessed by an application program using CAD-system neutral C and FORTRAN language function calls. CAPRI supports a general set of CAD operations such as truth testing, geometry construction and entity queries.

Afjeh, Abdollah A.↗
NASA NTRS1998

A Geometry Based Infra-Structure for Computational Analysis and Design

The computational steps traditionally taken for most engineering analysis suites (computational fluid dynamics (CFD), structural analysis, heat transfer and etc.) are: (1) Surface Generation -- usually by employing a Computer Assisted Design (CAD) system; (2) Grid Generation -- preparing the volume for the simulation; (3) Flow Solver -- producing the results at the specified operational point; (4) Post-processing Visualization -- interactively attempting to understand the results. For structural analysis, integrated systems can be obtained from a number of commercial vendors. These vendors couple directly to a number of CAD systems and are executed from within the CAD Graphical User Interface (GUI). It should be noted that the structural analysis problem is more tractable than CFD; there are fewer mesh topologies used and the grids are not as fine (this problem space does not have the length scaling issues of fluids). For CFD, these steps have worked well in the past for simple steady-state simulations at the expense of much user interaction. The data was transmitted between phases via files. In most cases, the output from a CAD system could go to Initial Graphics Exchange Specification (IGES) or Standard Exchange Program (STEP) files. The output from Grid Generators and Solvers do not really have standards though there are a couple of file formats that can be used for a subset of the gridding (i.e. PLOT3D data formats). The user would have to patch up the data or translate from one format to another to move to the next step. Sometimes this could take days. Specifically the problems with this procedure are:(1) File based -- Information flows from one step to the next via data files with formats specified for that procedure. File standards, when they exist, are wholly inadequate. For example, geometry from CAD systems (transmitted via IGES files) is defined as disjoint surfaces and curves (as well as masses of other information of no interest for the Grid Generator). This is particularly onerous for modern CAD systems based on solid modeling. The part was a proper solid and in the translation to IGES has lost this important characteristic. STEP is another standard for CAD data that exists and supports the concept of a solid. The problem with STEP is that a solid modeling geometry kernel is required to query and manipulate the data within this type of file. (2) 'Good' Geometry. A bottleneck in getting results from a solver is the construction of proper geometry to be fed to the grid generator. With 'good' geometry a grid can be constructed in tens of minutes (even with a complex configuration) using unstructured techniques. Adroit multi-block methods are not far behind. This means that a million node steady-state solution can be computed on the order of hours (using current high performance computers) starting from this 'good' geometry. Unfortunately, the geometry usually transmitted from the CAD system is not 'good' in the grid generator sense. The grid generator needs smooth closed solid geometry. It can take a week (or more) of interaction with the CAD output (sometimes by hand) before the process can begin. One way Communication. (3) One-way Communication -- All information travels on from one phase to the next. This makes procedures like node adaptation difficult when attempting to add or move nodes that sit on bounding surfaces (when the actual surface data has been lost after the grid generation phase). Until this process can be automated, more complex problems such as multi-disciplinary analysis or using the above procedure for design becomes prohibitive. There is also no way to easily deal with this system in a modular manner. One can only replace the grid generator, for example, if the software reads and writes the same files. Instead of the serial approach to analysis as described above, CAPRI takes a geometry centric approach. This makes the actual geometry (not a discretized version) accessible to all phases of the analysis. The connection to the geometry is made through an Application Programming Interface (API) and NOT a file system. This API isolates the top-level applications (grid generators, solvers and visualization components) from the geometry engine. Also this allows the replacement of one geometry kernel with another, without effecting these top-level applications. For example, if UniGraphics is used as the CAD package then Parasolid (UG's own geometry engine) can be used for all geometric queries so that no solid geometry information is lost in a translation. This is much better than STEP because when the data is queried, the same software is executed as used in the CAD system. Therefore, one analyzes the exact part that is in the CAD system. CAPRI uses the same idea as the commercial structural analysis codes but does not specify control. Software components of the CAD system are used, but the analysis suite, not the CAD operator, specifies the control of the software session. This also means that the license issues (may be) minimized and individuals need not have to know how to operate a CAD system in order to run the suite.

Haimes, Robert↗
NASA NTRS2003

Standards-and Component-Based Mission Operations Architecture at NASA's Goddard Space Flight Center

NASA Goddard Space Flight Center (GSFC) manages many of NASA s earth and space science satellite missions. A wide variety of commercial products and GSFC-developed software components are typically integrated into a unique system configuration for each mission. Independent development of the many mission operations center systems has led to systems that are expensive to integrate, difficult to infuse with new capabilities developed for other programs, and cumbersome to maintain. This traditional approach becomes even more problematic as NASA moves towards satellite constellations, new operations concepts, and even further budgets reductions. The GSFC Mission Services Evolution Center (GMSEC) is creating a new architecture for future missions at GSFC. Instead of selecting the best-in-class components and creating a standard control center system, GMSEC is developing component interface standards so that multiple products can plug-and-play into the configuration. Missions can then select the best components based on the merits of the product and not simply based on recent integration history at NASA. The GMSEC system utilizes a publish/subscribe information bus and standard XML-based key message interfaces. Functional components can either match directly to the interface standard, or adapters can be developed to match the product's interface to the GMSEC standard with out impacting the source product. Applications Program Interfaces (API's) are being developed to isolate the underlying middleware from the applications software and to allow the middleware product to be switched if necessary. Interface Control Documents (ICDs) between each pair of communicating components is replaced by a single message/API specification document. New applications must simply match to the information bus standards and need not worry about all of the other applications in the system. For legacy software, adapters can be developed to facilitate communications between the application and the information bus. As the approach has matured, it has become apparent that it can provide innovative solutions to some of the multi-satellite challenges facing GSFC.

Smith, Danford↗
NASA NTRS2018

Toward a Common Earth Data Publication Framework

Data publication is an essential activity for all data archives. Each of NASA's twelve Distributed Active Archive Centers (DAACs) have established publication workflows which account for the heterogeneous suite of missions, instruments, data providers, and datasets managed within the Earth Observation System Data and Information System (EOSDIS) program. Some aspects of data publication vary across DAACs: workflows range from manual to automatic, terms used to describe publication elements differ, and systems used to publish and manage data vary. Despite these differences, the DAAC data publication processes are generally the same: obtain the data and related information from data providers, describe the data with metadata and documentation, and release the data for access by the user community. In order to improve consistency and reduce the time required to publish data, we have developed a cross-DAAC initiative called the Common Earthdata Publication Framework (Earthdata Pub). Earthdata Pub seeks to: standardize communications and interactions with data providers; identify and standardize common workflows and steps in the data publication process; and design/implement a front-end system with features that include a common web interface, email & status tracking, and common application programming interfaces (APIs) to communicate with various DAAC-specific software components (services and applications) on the back-end. We will present the latest updates on this effort's progress and future plans.

data publication↗
NASA NTRSDate not supplied

POST Explorer: A Design Space Exploration Tool for POST2

Recent improvements for the Program to Optimize Simulated Trajectories II (POST2) have included the development of an application programming interface (API). This API allows POST2 simulation inputs to be directly manipulated from other applications (such as MATLAB or Python), and the outputs from POST2 are streamed directly to the external application that enables visualization, data manipulation, etc. Through this framework, a new tool called POST Explorer is being developed that provides a user the capability to modify the simulation inputs and interrogate the outputs within the same application, with raw data inspection and visualization embedded. This tool can be leveraged for multiple types of analyses, such as parametric sweeps and sensitivity studies, and will be available with a future release of the POST2 software.

Robert Anthony Williams↗
NASA NTRSDate not supplied

POST Explorer: A Design Space Exploration Tool for POST2

Recent improvements for the Program to Optimize Simulated Trajectories II (POST2) have included the development of an application programming interface (API). This API allows POST2 simulation inputs to be directly manipulated from other applications (such as MATLAB or Python), and the outputs from POST2 are streamed directly to the external application that enables visualization, data manipulation, etc. Through this framework, a new tool called POST Explorer is being developed that provides a user the capability to modify the simulation inputs and interrogate the outputs within the same application, with raw data inspection and visualization embedded. This tool can be leveraged for multiple types of analyses, such as parametric sweeps and sensitivity studies, and will be available with a future release of the POST2 software.

Anthony Williams↗
NASA NTRS2016

Experimenting Galileo on Board the International Space Station

The SCaN Testbed is an advanced integrated communications system and laboratory facility installed on the International Space Station (ISS) in 2012. The testbed incorporates a set of new generation of Software Defined Radio (SDR) technologies intended to allow researchers to develop, test, and demonstrate new communications, networking, and navigation capabilities in the actual environment of space. Qascom, in cooperation with ESA and NASA, is designing a Software Defined Radio GalileoGPS Receiver capable to provide accurate positioning and timing to be installed on the ISS SCaN Testbed. The GalileoGPS waveform will be operated in the JPL SDR that is constituted by several hardware components that can be used for experimentations in L-Band and S-Band. The JPL SDR includes an L-Band Dorne Margolin antenna mounted onto a choke ring. The antenna is connected to a radio front end capable to provide one bit samples for the three GNSS frequencies (L1, L2 and L5) at 38 MHz, exploiting the subharmonic sampling. The baseband processing is then performed by an ATMEL AT697 processor (100 MIPS) and two Virtex 2 FPGAs. The JPL SDR supports the STRS (Space Telecommunications Radio System) that provides common waveform software interfaces, methods of instantiation, operation, and testing among different compliant hardware and software products. The standard foresees the development of applications that are modular, portable, reconfigurable, and reusable. The developed waveform uses the STRS infrastructure-provided application program interfaces (APIs) and services to load, verify, execute, change parameters, terminate, or unload an application. The project is divided in three main phases. 1)Design and Development of the GalileoGPS waveform for the SCaN Testbed starting from Qascom existing GNSS SDR receiver. The baseline design is limited to the implementation of the single frequency Galileo and GPS L1E1 receiver even if as part of the activity it will be to assess the feasibility of a dual frequency implementation (L1E1+L5E5a) in the same SDR platform.2)Qualification and test the GalileoGPS waveform using ground systems available at the NASA Glenn Research Center. Experimenters can have access to two SCaN Testbed ground based systems for development and verification: the Experimenter Development System (EDS) that is intended to provide initial opportunity for software testing and basic functional validation and the Ground Integration Unit (GIU) that is a high fidelity version of the SCaN Testbed flight system and is therefore used for more controlled final development testing and verification testing.3)Perform in-orbit validation and experimentation: The experimentation phase will consists on the collection of raw measurements (pseudorange, Carrier phase, CN0) in space, assessment on the quality of the measurements and the receiver performances in terms of signal acquisition, tracking, etc. Finally computation of positioning in space (Position, Velocity and time) and assessment of its performance.(Complete abstract in attached document).

GPS↗