Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Python 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.

26 records · Page 2

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.↗

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↗

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↗

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↗

Developing Concepts of Operations Using Multi-Step Tool Techniques With Large Language Models

The National Aeronautics and Space Administration (NASA) Air Mobility Pathfinders (AMP) project is developing and evaluating concepts of operations (ConOps) for safe, secure, and scalable Urban Air Mobility (UAM) operations. The AMP project’s Operational Concepts, Architecture, and Requirements Integration (OCARI) Team is using a Model Based System Engineering (MBSE) approach for integration, interoperability, and traceability of Advanced Air Mobility (AAM) ecosystems centered around urban air taxi services. The team’s goal is to define structures and behaviors needed for system feasibility, readiness, and interoperability, establish a UAM knowledge base, and trace and validate assumptions and requirements relevant to AAM. NASA Langley Research Center (LaRC) is spearheading an innovative digital engineering approach to integrate, communicate, and facilitate the research of multi-modal transportation systems. The Knowledge-based Digital Platform (KbDP) is a concept being developed that ties the workflows of Project Managers (PM), Principal Investigators (PI), and System Engineers together across organizational boundaries. It does so through the management of an information database defined by mathematical, data science, and system engineering principles. Machine Learning (ML) algorithms play a key role in this concept by extracting meaningful knowledge from relational and graph databases, document repositories, and system artifacts, which the human user leverages to greatly improve the efficiency and effectiveness of their research. Recent advancements in the field of Large Language Models (LLMs), specifically models trained for tool use, such as Command-R , now allow for the reliable implementation of single-step and multi-step tool-centric systems. These techniques provide the LLM with a set of tools, in our case Python functions, that can be called on to answer a much wider range of questions compared to LLMs implemented using a traditional single-source or Retrieval Augmented Generation (RAG) approach. Through this method, the LLM can pull information from multiple data sources, such as relational or graph databases, document repositories, application programming interfaces (APIs), and SysML artifacts depending on the user’s question. The LLM can also output the information in a variety of different formats, using output generation tools, such as CSV, UML, or SysML artifacts. Additionally, tools can be assigned roles and can work together to provide answers to queries in an “agent” like approach, similar to that implemented by Microsoft’s AutoGen framework where different agents can converse with each other to accomplish tasks. Previously, our team developed a chatbot system with “agent like” functionality in the form of different “modes” the user could select from a user interface (UI), this architecture can be seen on the left in figure 1. Three different modes were implemented, the first mode allowed the LLM to utilize the structures and algorithms within a graph database to trace UAM requirements. The second mode gave the LLM access to a vector search capable of providing relevant information from thousands of document pages related to UAM ConOps and requirements. The third mode served as a general assistant where users could enter open-ended questions and custom prompts to utilize the LLM for different use-cases. This system improved the process surrounding generating and analyzing information related to UAM requirements, however, the implementation provided a clunky user experience. Users were required to know what mode to select within the UI in advance before entering their question to the selected tool. Moreover, the different tools were isolated from each other, they lacked bidirectional links that would allow for tools to collaborate to generate better responses. Our team is working on a new architecture, seen on the right in the below figure, with the goal to address many of the UX shortcomings of our original system while improving the accuracy and depth of responses from the LLM. This new system will automatically select the appropriate tool to use based off the user’s question. Each tool will be capable of calling on any of the other tools available to the LLM, resulting in a collaborative pipeline where tools can pass data between other tools until enough data is received to generate an answer to the user’s question. Using a locally deployed, open-source, LLM, the NASA OCARI team, in collaboration with Collins Aerospace, will implement a prototype application that will bridge knowledge across multiple sources to assist System Engineers (SEs) with requirements discovery and tracing, research question and use case identification, and assumption validation. Such a system will also allow SEs to more easily, and intuitively, explore the AAM ecosystem, ultimately improving the efficiency and effectiveness of the SE's research and decision-making processes surrounding ConOps development and validation. In this session, our team will provide a video demonstration of our new prototype architecture in action. We will also present an overview of our prototype system architecture and talk about its advantages over traditional LLM deployments along with how those advantages can provide additional value to the field of System Engineering.

systems engineering↗

HAPI: An API Standard for Accessing Heliophysics Time Series Data

Heliophysics data analysis often involves combining diverse science measurements, many of them captured as time series. Although there are now only a few commonly used data file formats, the diversity in mechanisms for automated access to and aggregation of such data holdings can make analysis that requires intercomparison of data from multiple data providers difficult. The Heliophysics Application Programmer's Interface (HAPI) is a recently developed standard for accessing distributed time series data to increase interoperability. The HAPI specification is based on the common elements of existing data services, and it standardizes the two main parts of a data service: the request interface and the response data structures. The interface is based on the REpresentational State Transfer (REST) or RESTful architecture style, and the HAPI specification defines five required REST endpoints. Data are returned via a streaming format that hides file boundaries; the metadata is detailed enough for the content to be scientifically useful, e.g., plotted with appropriate axes layout, units, and labels. Multiple mature HAPI-related open-source projects offer server-side implementation tools and client-side libraries for reading HAPI data in multiple languages (IDL, Java, MATLAB, and Python). Multiple data providers in the US and Europe have added HAPI access alongside their existing interfaces. Based on this experience, data can be served via HAPI with little or no information loss compared to similar existing web interfaces. Finally, HAPI has been recommended as a COSPAR standard for time series data delivery.

Robert S. Weigel↗

Biomass Harmonization and SAR Analysis with the Multi-mission Algorithm and Analysis Platform (MAAP)

The Multi‐mission Algorithm and Analysis Platform (MAAP) is a collaborative effort between NASA and the European Space Agency (ESA) to support above ground biomass (AGB) research in an open science framework. MAAP brings together relevant data, algorithms, and computing capabilities in a common cloud environment to address the challenges of sharing and processing data from field, airborne and satellite measurements. MAAP was publicly released in October 2021, providing computing capabilities co-located with the data, a collaborative coding and analysis environment, and a set of interoperable tools and algorithms developed to support the estimation and visualization of data. MAAP has allowed scientists from both North America and Europe to collaborate on the generation and analysis/visualization of data derived from multiple, discipline-adjacent missions in an open, collaborative environment that has reached beyond traditional scientific investigation. MAAP has been used to support multiple scientific activities. To date, existing LiDAR data from multiple platforms has been calibrated with field measurements and combined for more comprehensive and accurate estimates of above ground biomass AGB; these LiDAR platforms include airborne (e.g. LVIS), the International Space Station (NASA’s Global Ecosystem Dynamics Investigation (GEDI), and satellites (e.g. ICESat-2). The current challenge is to effectively and seamlessly combine the aforementioned LiDAR-based data with new data sources such as P-band RADAR from ESA’s upcoming BIOMASS mission, existing ESA Sentinel-1 C-band SAR, and the 30 PB/yr of high cadence global coverage L-band SAR data from the upcoming NASA-ISRO SAR (NISAR) mission. Recent analysis using MAAP merged ICESat-2 and optical data (Harmonized Landsat Sentinel) produced the most comprehensively precise estimate of boreal-wide AGB to date. Another effort using MAAP is the production and open distribution of global comparisons of AGB map estimates, including from ICESat-2 and GEDI, to bolster stakeholder uptake for policy applications. These map estimates will feed into the Intergovernmental Panel on Climate Change (IPCC) database, likely aiding the next Global Carbon Stocktake of the UNFCCC. Furthermore, the biomass retrieval intercomparison exercise BRIX-2 could benefit from the MAAP providing standardized test cases (based on airborne campaign and spaceborne data) allowing the community to develop and apply retrieval algorithms based on these test cases, while forthcoming SAR data training curricula could also use the MAAP as a teaching and learning platform. The MAAP is meeting the challenges inherent in international, open science collaboration and large scale computing with a platform that is entirely open source and cloud native, using open standards for data access, manipulation, protocols, and formats. The MAAP data system consists of a dedicated data store whose data is indexed in an online catalog conforming to established metadata, application programmatic interfaces (APIs), and service interface standards, using an implementation of the open sourced NASA Common Metadata Repository. Federation of user identities allows users from either NASA or ESA to access and consume services from the other using a unified metadata catalog for the data utilized across the ESA and NASA MAAP platforms. Similarly, we are exploring how to increase interoperability to achieve a common approach to packaging, orchestrating and executing algorithms, with interoperable access to data for subsetting, fast browse, and cloud-optimized access, all using interoperable standards such as those from the Open Geospatial Consortium (OGC). Designed for interoperability, ESA and NASA utilize a common architecture for the software platform. It provides a cloud-based algorithm development environment (ADE) that enables scientists to develop algorithms collaboratively with access to the MAAP data catalog as well as other data archives. MAAP provides an Eclipse Che-based ADE supporting both Python and R languages, popular in this biomass community. Algorithms developed and containerized within the ADE can be deployed to run to thousands of computational nodes in the MAAP’s data processing system (DPS), dramatically speeding up processing and giving scientists a rapid, iterative turnaround of results. NASA’s implementation of the DPS is based on the Hybrid Science Data System (HySDS) framework, used by NASA flight projects to produce Earth science standard products.

cloud computing↗

Constructing a Knowledge Graph & Applying Graph Algorithms to Draw Insights about GES-DISC Jira Tickets

In order to assess the complexities of Jira tickets created by NASA Goddard Earth Sciences Data and Information Services Center (GES-DISC), it was beneficial to create a knowledge graph. The knowledge graph receives ticket data through the Jira API. The creation of a knowledge graph will help to answer high-level questions about internal structure, knowledge gaps, and team organization within GES-DISC. To work towards this goal, the knowledge graph was constructed in adockerizedNeo4j graph database. Once the graph had been created, graph algorithms were applied to answer high-level questions, such as exploring the role of staff in relation to projects, which qualities of a ticket contribute to the formation of communities within the graph, etc. To answer these questions, centrality and community detection algorithms were applied using Cypher querying language. The analysis of the results of the algorithms indicated that, as expected, certain individuals were more connected to some projects, while others were serving as hub nodes between two or more projects. Similarly, specific keywords are more likely to increase a Jira ticket’s centrality in the graph. In terms of community detection, when tickets in a community have certain qualities, it is more probable for them to be grouped together. To best visualize which nodes had higher centrality scores or were grouped into certain communities, interactive graphs were created in Python using Plotly and Matplotlib. Ultimately, the project was successful in creating and deploying a knowledge graph to better understand the relationships between data in GES-DISC Jira tickets

Rebecca Lipton↗