SEARCH · Search NASA

Results for “application programming interface”

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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 127 records · Page 7

All sources NASA NTRS DOE OSTI

NASA NTRS2011

Autonomous Satellite Operations Via Secure Virtual Mission Operations Center

The science community is interested in improving their ability to respond to rapidly evolving, transient phenomena via autonomous rapid reconfiguration, which derives from the ability to assemble separate but collaborating sensors and data forecasting systems to meet a broad range of research and application needs. Current satellite systems typically require human intervention to respond to triggers from dissimilar sensor systems. Additionally, satellite ground services often need to be coordinated days or weeks in advance. Finally, the boundaries between the various sensor systems that make up such a Sensor Web are defined by such things as link delay and connectivity, data and error rate asymmetry, data reliability, quality of service provisions, and trust, complicating autonomous operations. Over the past ten years, researchers from the NASA Glenn Research Center (GRC), General Dynamics, Surrey Satellite Technology Limited (SSTL), Cisco, Universal Space Networks (USN), the U.S. Geological Survey (USGS), the Naval Research Laboratory, the DoD Operationally Responsive Space (ORS) Office, and others have worked collaboratively to develop a virtual mission operations capability. Called VMOC (Virtual Mission Operations Center), this new capability allows cross-system queuing of dissimilar mission unique systems through the use of a common security scheme and published application programming interfaces (APIs). Collaborative VMOC demonstrations over the last several years have supported the standardization of spacecraft to ground interfaces needed to reduce costs, maximize space effects to the user, and allow the generation of new tactics, techniques and procedures that lead to responsive space employment.

Miller, Eric↗

NASA NTRS2005

Doclet To Synthesize UML

The RoseDoclet computer program extends the capability of Java doclet software to automatically synthesize Unified Modeling Language (UML) content from Java language source code. [Doclets are Java-language programs that use the doclet application programming interface (API) to specify the content and format of the output of Javadoc. Javadoc is a program, originally designed to generate API documentation from Java source code, now also useful as an extensible engine for processing Java source code.] RoseDoclet takes advantage of Javadoc comments and tags already in the source code to produce a UML model of that code. RoseDoclet applies the doclet API to create a doclet passed to Javadoc. The Javadoc engine applies the doclet to the source code, emitting the output format specified by the doclet. RoseDoclet emits a Rose model file and populates it with fully documented packages, classes, methods, variables, and class diagrams identified in the source code. The way in which UML models are generated can be controlled by use of new Javadoc comment tags that RoseDoclet provides. The advantage of using RoseDoclet is that Javadoc documentation becomes leveraged for two purposes: documenting the as-built API and keeping the design documentation up to date.

Barry, Matthew R.↗

NASA NTRS2005

Shuttle-Data-Tape XML Translator

JSDTImport is a computer program for translating native Shuttle Data Tape (SDT) files from American Standard Code for Information Interchange (ASCII) format into databases in other formats. JSDTImport solves the problem of organizing the SDT content, affording flexibility to enable users to choose how to store the information in a database to better support client and server applications. JSDTImport can be dynamically configured by use of a simple Extensible Markup Language (XML) file. JSDTImport uses this XML file to define how each record and field will be parsed, its layout and definition, and how the resulting database will be structured. JSDTImport also includes a client application programming interface (API) layer that provides abstraction for the data-querying process. The API enables a user to specify the search criteria to apply in gathering all the data relevant to a query. The API can be used to organize the SDT content and translate into a native XML database. The XML format is structured into efficient sections, enabling excellent query performance by use of the XPath query language. Optionally, the content can be translated into a Structured Query Language (SQL) database for fast, reliable SQL queries on standard database server computers.

Barry, Matthew R.↗

NASA NTRS2004

Viewing ISS Data in Real Time via the Internet

EZStream is a computer program that enables authorized users at diverse terrestrial locations to view, in real time, data generated by scientific payloads aboard the International Space Station (ISS). The only computation/communication resource needed for use of EZStream is a computer equipped with standard Web-browser software and a connection to the Internet. EZStream runs in conjunction with the TReK software, described in a prior NASA Tech Briefs article, that coordinates multiple streams of data for the ground communication system of the ISS. EZStream includes server components that interact with TReK within the ISS ground communication system and client components that reside in the users' remote computers. Once an authorized client has logged in, a server component of EZStream pulls the requested data from a TReK application-program interface and sends the data to the client. Future EZStream enhancements will include (1) extensions that enable the server to receive and process arbitrary data streams on its own and (2) a Web-based graphical-user-interface-building subprogram that enables a client who lacks programming expertise to create customized display Web pages.

Myers, Gerry↗

NASA NTRS2004

MPT Prediction of Aircraft-Engine Fan Noise

A collection of computer programs has been developed that implements a procedure for predicting multiple-pure-tone (MPT) noise generated by fan blades of an aircraft engine (e.g., a turbofan engine). MPT noise arises when the fan is operating with supersonic relative tip Mach No. Under this flow condition, there is a strong upstream running shock. The strength and position of this shock are very sensitive to blade geometry variations. For a fan where all the blades are identical, the primary tone observed upstream of the fan will be the blade passing frequency. If there are small variations in geometry between blades, then tones below the blade passing frequency arise MPTs. Stagger angle differences as small as 0.1 can give rise to significant MPT. It is also noted that MPT noise is more pronounced when the fan is operating in an unstarted mode. Computational results using a three-dimensional flow solver to compute the complete annulus flow with non-uniform fans indicate that MPT noise can be estimated in a relatively simple way. Hence, once the effect of a typical geometry variation of one blade in an otherwise uniform blade row is known, the effect of all the blades being different can be quickly computed via superposition. Two computer programs that were developed as part of this work are used in conjunction with a user s computational fluid dynamics (CFD) code to predict MPT spectra for a fan with a specified set of geometric variations: (1) The first program ROTBLD reads the users CFD solution files for a single blade passage via an API (Application Program Interface). There are options to replicate and perturb the geometry with typical variations stagger, camber, thickness, and pitch. The multi-passage CFD solution files are then written in the user s file format using the API. (2) The second program SUPERPOSE requires two input files: the first is the circumferential upstream pressure distribution extracted from the CFD solution on the multi-passage mesh, the second file defines the geometry variations of each blade in a complete fan. Superposition is used to predict the spectra resulting from the geometric variations.

Connell, Stuart D.↗

NASA NTRS2011

Test Generator for MATLAB Simulations

MATLAB Automated Test Tool, version 3.0 (MATT 3.0) is a software package that provides automated tools that reduce the time needed for extensive testing of simulation models that have been constructed in the MATLAB programming language by use of the Simulink and Real-Time Workshop programs. MATT 3.0 runs on top of the MATLAB engine application-program interface to communicate with the Simulink engine. MATT 3.0 automatically generates source code from the models, generates custom input data for testing both the models and the source code, and generates graphs and other presentations that facilitate comparison of the outputs of the models and the source code for the same input data. Context-sensitive and fully searchable help is provided in HyperText Markup Language (HTML) format.

Henry, Joel↗

NASA NTRS2011

RAPID: Collaborative Commanding and Monitoring of Lunar Assets

RAPID (Robot Application Programming Interface Delegate) software utilizes highly robust technology to facilitate commanding and monitoring of lunar assets. RAPID provides the ability for intercenter communication, since these assets are developed in multiple NASA centers. RAPID is targeted at the task of lunar operations; specifically, operations that deal with robotic assets, cranes, and astronaut spacesuits, often developed at different NASA centers. RAPID allows for a uniform way to command and monitor these assets. Commands can be issued to take images, and monitoring is done via telemetry data from the asset. There are two unique features to RAPID: First, it allows any operator from any NASA center to control any NASA lunar asset, regardless of location. Second, by abstracting the native language for specific assets to a common set of messages, an operator may control and monitor any NASA lunar asset by being trained only on the use of RAPID, rather than the specific asset. RAPID is easier to use and more powerful than its predecessor, the Astronaut Interface Device (AID). Utilizing the new robust middleware, DDS (Data Distribution System), developing in RAPID has increased significantly over the old middleware. The API is built upon the Java Eclipse Platform, which combined with DDS, provides platform-independent software architecture, simplifying development of RAPID components. As RAPID continues to evolve and new messages are being designed and implemented, operators for future lunar missions will have a rich environment for commanding and monitoring assets.

Torres, Recaredo J.↗

NASA NTRS2012

Security Data Warehouse Application

The Security Data Warehouse (SDW) is used to aggregate and correlate all JSC IT security data. This includes IT asset inventory such as operating systems and patch levels, users, user logins, remote access dial-in and VPN, and vulnerability tracking and reporting. The correlation of this data allows for an integrated understanding of current security issues and systems by providing this data in a format that associates it to an individual host. The cornerstone of the SDW is its unique host-mapping algorithm that has undergone extensive field tests, and provides a high degree of accuracy. The algorithm comprises two parts. The first part employs fuzzy logic to derive a best-guess host assignment using incomplete sensor data. The second part is logic to identify and correct errors in the database, based on subsequent, more complete data. Host records are automatically split or merged, as appropriate. The process had to be refined and thoroughly tested before the SDW deployment was feasible. Complexity was increased by adding the dimension of time. The SDW correlates all data with its relationship to time. This lends support to forensic investigations, audits, and overall situational awareness. Another important feature of the SDW architecture is that all of the underlying complexities of the data model and host-mapping algorithm are encapsulated in an easy-to-use and understandable Perl language Application Programming Interface (API). This allows the SDW to be quickly augmented with additional sensors using minimal coding and testing. It also supports rapid generation of ad hoc reports and integration with other information systems.

Vernon, Lynn R.↗

NASA NTRS2012

The Virtual Solar Observatory: What Are We Up To Now?

In the nearly ten years of a functional Virtual Solar Observatory (VSO), http://virtualsolar.org/ we have made it possible to query and access sixty-seven distinct solar data products and several event lists from nine spacecraft and fifteen observatories or observing networks. We have used existing VSO technology, and developed new software, for a distributed network of sites caching and serving SDO HMI and/ or AlA data. We have also developed an application programming interface (API) that has enabled VSO search and data access capabilities in IDL, Python, and Java. We also have quite a bit of work yet to do, including completion of the implementation of access to SDO EVE data, and access to some nineteen other data sets from space- and ground-based observatories. In addition, we have been developing a new graphic user interface that will enable the saving of user interface and search preferences. We solicit advice from the community input prioritizing our task list, and adding to it

Gurman, J. B.↗

NASA NTRS2012

TraceContract

TraceContract is an API (Application Programming Interface) for trace analysis. A trace is a sequence of events, and can, for example, be generated by a running program, instrumented appropriately to generate events. An event can be any data object. An example of a trace is a log file containing events that a programmer has found important to record during a program execution. Trace - Contract takes as input such a trace together with a specification formulated using the API and reports on any violations of the specification, potentially calling code (reactions) to be executed when violations are detected. The software is developed as an internal DSL (Domain Specific Language) in the Scala programming language. Scala is a relatively new programming language that is specifically convenient for defining such internal DSLs due to a number of language characteristics. This includes Scala s elegant combination of object-oriented and functional programming, a succinct notation, and an advanced type system. The DSL offers a combination of data-parameterized state machines and temporal logic, which is novel. As an extension of Scala, it is a very expressive and convenient log file analysis framework.

Kavelund, Klaus↗

NASA NTRS2012

Telerobotics Workstation (TRWS) for Deep Space Habitats

On medium- to long-duration human spaceflight missions, latency in communications from Earth could reduce efficiency or hinder local operations, control, and monitoring of the various mission vehicles and other elements. Regardless of the degree of autonomy of any one particular element, a means of monitoring and controlling the elements in real time based on mission needs would increase efficiency and response times for their operation. Since human crews would be present locally, a local means for monitoring and controlling all the various mission elements is needed, particularly for robotic elements where response to interesting scientific features in the environment might need near- instantaneous manipulation and control. One of the elements proposed for medium- and long-duration human spaceflight missions, the Deep Space Habitat (DSH), is intended to be used as a remote residence and working volume for human crews. The proposed solution for local monitoring and control would be to provide a workstation within the DSH where local crews can operate local vehicles and robotic elements with little to no latency. The Telerobotics Workstation (TRWS) is a multi-display computer workstation mounted in a dedicated location within the DSH that can be adjusted for a variety of configurations as required. From an Intra-Vehicular Activity (IVA) location, the TRWS uses the Robot Application Programming Interface Delegate (RAPID) control environment through the local network to remotely monitor and control vehicles and robotic assets located outside the pressurized volume in the immediate vicinity or at low-latency distances from the habitat. The multiple display area of the TRWS allows the crew to have numerous windows open with live video feeds, control windows, and data browsers, as well as local monitoring and control of the DSH and associated systems.

Mittman, David S.↗

NASA NTRS2012

Using NASA Environmental Data to Enhance Public Health Decision Making

The Universities Space Research Association at the NASA Marshall Space Flight Center is collaborating with the University of Alabama at Birmingham (UAB) School of Public Health and the Centers for Disease Control and Prevention (CDC) to address issues of environmental health and enhance public health decision making by utilizing NASA remotely sensed data and products. The objectives of this collaboration are to develop high-quality spatial data sets of environmental variables, and deliver the data sets and associated analyses to local, state and federal end-user groups. These data can be linked spatially and temporally to public health data, such as mortality and disease morbidity, for further analysis and decision making. Three daily environmental data sets have been developed for the conterminous U.S. on different spatial resolutions for the time period 2003-2008: (1) spatial surfaces of estimated fine particulate matter (PM2.5) exposures on a 10-km grid utilizing the US Environmental Protection Agency (EPA) ground observations and NASA s MODerate-resolution Imaging Spectroradiometer (MODIS) data; (2) a 1-km grid of Land Surface Temperature (LST) using MODIS data; and (3) a 12-km grid of daily Solar Insolation (SI) and maximum and minimum air temperature using the North American Land Data Assimilation System (NLDAS) forcing data. These environmental data sets will be linked with public health data from the UAB REasons for Geographic And Racial Differences in Stroke (REGARDS) national cohort study to determine whether exposures to these environmental risk factors are related to cognitive decline and other health outcomes. These environmental datasets and public health linkage analyses will be made available to public health professionals, researchers and the general public through the CDC Wide-ranging Online Data for Epidemiologic Research (WONDER) system and through peer reviewed publications. To date, two of the data sets have been released to the public in CDC WONDER, Daily Air Temperature and Heat Index for years 1979-2010, and Daily Fine Particulate Matter (PM2.5) air quality measures for years 2003-2008. These data in CDC WONDER can be aggregated to the county-level, state-level, or regional-level as per users need and downloaded in tabular, graphical, and map formats. The summary statistical output are available to web and app developers via the WONDER Application Programming Interface (API). The linkage of these data with the CDC WONDER system provides a significant addition to CDC WONDER, allowing public health researchers and policy makers to better include environmental exposure data in the context of other health data available in CDC WONDER online system. It also substantially expands public access to NASA environmental data, making their use by a wide range of decision makers feasible.

Al-Hamdan, Mohammad↗

NASA NTRS2014

Using Social Media and Mobile Devices to Discover and Share Disaster Data Products Derived From Satellites

Data products derived from Earth observing satellites are difficult to find and share without specialized software and often times a highly paid and specialized staff. For our research effort, we endeavored to prototype a distributed architecture that depends on a standardized communication protocol and applications program interface (API) that makes it easy for anyone to discover and access disaster related data. Providers can easily supply the public with their disaster related products by building an adapter for our API. Users can use the API to browse and find products that relate to the disaster at hand, without a centralized catalogue, for example floods, and then are able to share that data via social media. Furthermore, a longerterm goal for this architecture is to enable other users who see the shared disaster product to be able to generate the same product for other areas of interest via simple point and click actions on the API on their mobile device. Furthermore, the user will be able to edit the data with on the ground local observations and return the updated information to the original repository of this information if configured for this function. This architecture leverages SensorWeb functionality [1] presented at previous IGARSS conferences. The architecture is divided into two pieces, the frontend, which is the GeoSocial API, and the backend, which is a standardized disaster node that knows how to talk to other disaster nodes, and also can communicate with the GeoSocial API. The GeoSocial API, along with the disaster node basic functionality enables crowdsourcing and thus can leverage insitu observations by people external to a group to perform tasks such as improving water reference maps, which are maps of existing water before floods. This can lower the cost of generating precision water maps. Keywords-Data Discovery, Disaster Decision Support, Disaster Management, Interoperability, CEOS WGISS Disaster Architecture

0↗

NASA NTRS2014

Namibia Dashboard Enhancements

The purpose of this presentation is for a Technical Interchange Meeting with the Namibia Hydrological Services (NHS) in Namibia. The meeting serves as a capacity building exercise. This presentation goes over existing software functionality developed in collaboration with NHS over the past five years called the Namibia Flood Dashboard. Furthermore, it outlines new functionality developed over the past year and future functionality that will be developed. The main purpose of the Dashboard is to assist in decision support for flood warning. The Namibia Flood Dashboard already exists online in a cloud environment and has been used in prototype mode for the past few years.Functionality in the Dashboard includes river gauge hydrographs, TRMM estimate rainfall, EO-1 flood maps, infrastructure maps and other related functions. Future functionality includes attempting to integrate interoperability standards and crowd-sourcing capability. To this end, we are adding OpenStreetMap compatibility and an Applications Program Interface (API) called a GeoSocial API to enable discovery and sharing of data products useful for decision support via social media.

Disaster Decision Support↗

NASA NTRS2014

An Airborne Onboard Parallel Processing Testbed

This presentation provides information on the progress the Intelligent Payload Module (IPM) development effort. In addition, a vision is presented on integration of the IPM architecture with the GeoSocial Application Program Interface (API) architecture to enable efficient distribution of satellite data products.

Onboard processing↗

NASA NTRS2012

The Earth System Grid Federation : an Open Infrastructure for Access to Distributed Geospatial Data

The Earth System Grid Federation (ESGF) is a multi-agency, international collaboration that aims at developing the software infrastructure needed to facilitate and empower the study of climate change on a global scale. The ESGF's architecture employs a system of geographically distributed peer nodes, which are independently administered yet united by the adoption of common federation protocols and application programming interfaces (APIs). The cornerstones of its interoperability are the peer-to-peer messaging that is continuously exchanged among all nodes in the federation; a shared architecture and API for search and discovery; and a security infrastructure based on industry standards (OpenID, SSL, GSI and SAML). The ESGF software is developed collaboratively across institutional boundaries and made available to the community as open source. It has now been adopted by multiple Earth science projects and allows access to petabytes of geophysical data, including the entire model output used for the next international assessment report on climate change (IPCC-AR5) and a suite of satellite observations (obs4MIPs) and reanalysis data sets (ANA4MIPs).

search,↗

NASA NTRS2012

Semantically-Rigorous Systems Engineering Modeling Using Sysml and OWL

The Systems Modeling Language (SysML) has found wide acceptance as a standard graphical notation for the domain of systems engineering. SysML subsets and extends the Unified Modeling Language (UML) to define conventions for expressing structural, behavioral, and analytical elements, and relationships among them. SysML-enabled modeling tools are available from multiple providers, and have been used for diverse projects in military aerospace, scientific exploration, and civil engineering. The Web Ontology Language (OWL) has found wide acceptance as a standard notation for knowledge representation. OWL-enabled modeling tools are available from multiple providers, as well as auxiliary assets such as reasoners and application programming interface libraries, etc. OWL has been applied to diverse projects in a wide array of fields. While the emphasis in SysML is on notation, SysML inherits (from UML) a semantic foundation that provides for limited reasoning and analysis. UML's partial formalization (FUML), however, does not cover the full semantics of SysML, which is a substantial impediment to developing high confidence in the soundness of any conclusions drawn therefrom. OWL, by contrast, was developed from the beginning on formal logical principles, and consequently provides strong support for verification of consistency and satisfiability, extraction of entailments, conjunctive query answering, etc. This emphasis on formal logic is counterbalanced by the absence of any graphical notation conventions in the OWL standards. Consequently, OWL has had only limited adoption in systems engineering. The complementary strengths and weaknesses of SysML and OWL motivate an interest in combining them in such a way that we can benefit from the attractive graphical notation of SysML and the formal reasoning of OWL. This paper describes an approach to achieving that combination.

Web Ontology Language (OWL)↗

NASA NTRS2010

The Evolvable Advanced Multi-Mission Operations System (AMMOS): Making Systems Interoperable

The Advanced Multi-Mission Operations System (AMMOS) provides a common Mission Operation System (MOS) infrastructure to NASA deep space missions. The evolution of AMMOS has been driven by two factors: increasingly challenging requirements from space missions, and the emergence of new IT technology. The work described in this paper focuses on three key tasks related to IT technology requirements: first, to eliminate duplicate functionality; second, to promote the use of loosely coupled application programming interfaces, text based file interfaces, web-based frameworks and integrated Graphical User Interfaces (GUI) to connect users, data, and core functionality; and third, to build, develop, and deploy AMMOS services that are reusable, agile, adaptive to project MOS configurations, and responsive to industrially endorsed information technology standards.

MGSS↗