Search NASA⌕ Search

SEARCH · Search NASA

Results for “Interoperable 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 145 records · Page 8

Usability Evaluation of Fleet Management Interface for High Density Vertiplex Environments

To meet the rising demand for an Advanced Air Mobility (AAM) (i.e. urban and rural unmanned aircraft systems) ecosystem, the NASA Aeronautics Research Mission Directorate (ARMD) is hosting a series of simulations and flight tests under the High Density Vertiplex sub-project (HDV) to prototype and study the effectiveness AAM capabilities under various operational contexts. HDV aims to develop an integrated automation architecture to support terminal area flight operations. The HDV simulations and flight tests address safety, integration, and operational challenges, while integrated systems and software demonstrate design readiness, robustness, and interoperability. During the initial HDV simulation in 2021, a prototype traffic management tool developed by NASA called the Fleet Management Interface (FMI) was tested. FMI was designed to introduce an advanced level of human-automation interaction to aid both Ground Control Station Operators (GCSOs) and Fleet Managers (FMs) in remotely managing flights under their ownership. In a human-in-the-loop simulation, a usability study was conducted with the FMI to identify optimal approaches for displaying information to human operators using subjective measures of usability, workload, situation awareness, risk, and trust, along with qualitative feedback. This study consisted of task analysis in which GCSO and FM subjects used an Urban Air Mobility (UAM) environment to develop and execute a plan for two different traffic scenarios of remotely controlled vehicles. In each scenario, a remotely controlled vehicle completed a takeoff, active flight, and landing sequence while simulated traffic flew in the background at a rate of 20 operations per hour. In the first scenario, the controlled vehicle flew a nominal route with takeoff and landing at the same vertiport. In the second scenario, the controlled vehicle started on the nominal route, then diverted to an unplanned location mid-flight. Results showed that self- reported performance, usability, trust, and situation awareness ratings of FMI were moderately to strongly high. There were small differences between scenarios, with Scenario 2 being perceived as more unstable, complex, variable, risky, and potentially harmful than Scenario 1. Furthermore, participants described improvements that could be made to create a better user experience. For example, users suggested customizable interfaces to accommodate information display preferences, and the ability to review routes before assigning them. The results from this study will inform future development of the FMI with the end goal of creating a reference automation tool for airspace management procedures in AAM. The FMI could serve to reduce dependency on traditional air navigation services through increased automation in high density vertiplex environments.

Fleet manager↗

Batched Sparse Linear Algebra (Final Report for Subcontract B648960)

This report finalizes design specifications for developing batched kernels for small tensor operations for unassembled matrix-free iterative solvers, batched solvers for partially assembled operators, and batched solvers with support for various sparse formats. The outcome of the project milestones is a set of interfaces to Batched Sparse LA solvers running on hardware accelerators for use in ECP Libraries and Applications. It is part of the development of sparse batched kernels, solvers/preconditioners as well as creating interoperability in xSDK libraries with sparse and dense batched functions to benefit ECP applications. The participants included representatives from ECP libraries (not limited to the xSDK project), applications, and vendors (AMD, Intel, and NVIDIA). Batched sparse linear algebra solvers form the new frontier for algorithmic development and performance engineering. Many applications (ECP and non-ECP alike) require simultaneous solutions of small linear systems of equations that are structurally sparse. To move towards high hardware utilization, it is important to provide these applications with appropriate interfaces to efficient batched sparse solvers running on modern hardware accelerators. We present interface designs in use by HPC software libraries supporting batched sparse linear algebra and the development of sparse batched kernel codes for solvers and preconditioners. We also address the potential interoperability opportunities to keep the software portable between the major hardware accelerators from AMD, Intel, and NVIDIA. The presented interface specifications includes batched band, sparse iterative, and sparse direct solvers. This report summarizes progress in Kokkos Kernels and the xSDK libraries MAGMA, Ginkgo, hypre, SUNDIALS, and SuperLU_dist.

97 MATHEMATICS AND COMPUTING↗

Recommendations for Data-in-Transit Requirements for Securing DER Communications

With the adoption of Distributed Energy Resource (DER) interoperability standards, common communication protocols are now being deployed between power system operators and DER devices. In 2018, a revision to the US interconnection and interoperability standard, Institute of Electrical and Electronics Engineers (IEEE) Std. 1547, required DER equipment to have an IEEE 2030.5, IEEE 1815, or SunSpec Modbus communication exchange interface. This change supports the future transition to secure connection and exchange of information between the DER equipment and implementing parties, such as grid operators. Adoption of standardized communication protocols and associated information models is a critical step toward interoperability between power system operators and DER, such as photovoltaic (PV) and energy storage systems. However, security requirements for these standardized communication protocols are not comprehensive, resulting in non-standard and vendor-specific implementation that may leave DER equipment susceptible to cyberattacks. This paper examines the data-in-flight security requirements for standardized DER communication protocols, per IEEE 1547-2018 revision, as it relates to device authentication, key management, and encryption. The state of the art for these security features is also explored, addressing their impact on communication and performance of low-cost single board computers, which are typical of DER devices. In conclusion, a recommendation is provided to adopt a common set of communication requirements, which are intended to achieve interoperability and implement data security over DER network pathways, while ensuring reliable, secure, and real-time information delivery.

42 ENGINEERING↗

Coping with all the earth science data

A report on the NASA-sponsored Earth Science and Applications Data Systems (ESADS) Workshop is presented. The ESADS report is reviewed and the task groups of the workshop are listed. The program set up to implement the recommendations of the workshop is discussed. The priorities of the ESADS committee recommendations include the development of standards and guidelines for data and metadata exchange, the creation of interoperable catalogs and directories, the development of guidelines for ancillary data archives, development of standard user interfaces, providing greater bandwidth in the user environment, collecting information about data storage technologies, and providing improved network connectivity.

Kahn, Ralph↗

Restructuring Big Data to Improve Data Access and Performance in Analytic Services Making Research More Efficient for the Study of Extreme Weather Events and Application User Communities

By developing and enhancing various services and tools, the GES DISC provides users with the capability to access and visualize data, and to make comparisons of data from multiple sensor and models via a number of cross-discipline projects. Discovering Data via Faceted Web Interface Web interface to data products and services Search and Download mechanisms Dataset Landing Pages Accessing Data through Interoperable Services: GDS – GrADS Data Server OPeNDAP - Open-source Project for a Network Data Access Protocol WMS – OGC service GIS connector – allowing IS tools to access data easier (coming soon) HTTPS -- direct online access Downloading Data Basics: Subset and egridding Service – Parameter, Spatial, Time, Vertical, Mean averaging, format conversion, and regridding for L3/L4 gridded data Swath Data Subsetter – Parameter, spatial subset of L2 /L1 data. Visualizing Data Online: Giovanni –Visualization and Analysis L3/L4 gridded data AIRS NRT Viewer – AIRS near-real-time DQVis – L2 data quality visualization

data cube↗

Using Open Standards and NASA Open Source Simulation Tools to Model Artemis Base Camp Mission Timelines

The United States’ National Aeronautics and Space Administration (NASA) has announced that the Artemis Program will return humans to the Moon, establishing a persistent presence with the Artemis Base Camp (ABC), and extend human exploration to Mars. The NASA Exploration Systems Simulations (NExSyS) team at NASA’s Johnson Space Center is using internationally developed simulation interoperability standards and NASA open source simulation tools to support Artemis concept, analysis, designs, development, training, and ultimately operations. The NExSyS team has been tasked to support early ABC architecture and mission analysis using mission time lines developed by the crew operations mission planning team. The NExSyS team is developing a distributed simulation framework with initial Artemis element implementations to model the ABC mission timelines using the international simulation interoperability standard High Level Architecture (HLA), the Simulation Interoperability Standards Organization’s Space Reference Federation Object Model (SpaceFOM), the NASA open source Trick Simulation Environment, and another NASA open source interface package called TrickHLA. The ABC architecture is composed of a number of key surface elements and resources. Some examples of modeled elements (also known as entities) are landers, habitats, rovers, logistics carriers, and astronauts. Some examples of modeled transferable and consumable resources are power, water, oxygen, nitrogen, scientific samples, and food. These entities and resources are modeled in a collection of individual simulations called Federates. A coordinated collection of interoperable federates is called a Federation and when these federates are tied together in a coordinated simulation run, it is referred to as a Federation Execution. The federates communicate through HLA using data exchange formats defined by a collection of machine readable files called Federation Object Models (FOMs). These FOM files are based on extensions to the SpaceFOM. This enables the instantiation and sharing of objects and interactions between federates in the federation. These provide for entity and resource tracking, object transfer, and data collection. Federate interactions are used to trigger events and notify federates of entity or resource transfers. For the initial implementation, the constituent federates are Trick-based simulations that use TrickHLA to provide the required HLA-base interoperability. These Trick-based simulations provide the required modeling for the individual Artemis elements along with the associated element resources. These federates provide a means to explore traverses between surface elements and exploration sites as scheduled in a mission timeline and explore the affects traverse times have on the overall mission timeline. The mission time lines are modeled using a Trick input file event handling capabilities. Each timeline operation is handled as individual simulation events, and triggered based on previous event status, time of operation, and simulated task completions. In addition, the ABC Federation can be used to perform Monte Carlo analysis. The Monte Carlo tool can vary the inputs, timings, and malfunctions to show how various contingencies in the mission can affect the mission timeline.

Keaton Craig Dodd↗

AESD (Advanced Energy System Design) Records API [SWRs-17-50, 17-51, 17-52]

The Records API (application program interface) for Advanced Energy System Design (AESD) enables software that serves multidimensional record-oriented data to interoperate with software than uses such data. In the context of the Records API, multidimensional data records are simply tuples of real numbers, integers, and character strings, where each data value is tagged by a variable name, according to a pre-defined schema, and each record is assigned a unique integer identifier. Conceptually, these records are isomorphic to rows in a relational database, JSON objects, or key-value maps. Records servers might supply static datasets, sensor measurements that periodically update as new telemetry become available, or the results of simulations as the simulations generate new output. Records client software might display or analyze the data, but in the case of simulations the client request the creation of new ensembles for specified input parameters. It is also possible to chain records clients and servers together so that a client consuming data from a server might transform that data and serve it to additional clients. This minimalist API avoids imposing burdensome metadata, structural, or implementation requirements on developers by relying on open-source technologies that are readily available for common programming languages. In particular, the API has been designed to place the least possible burden on services that provide data. This document defines the message format for the Records API, a transport mechanism for communicating the data, and the semantics for interpreting it. The message format is specified as Google Protocol Buffers and the transport mechanism uses WebSockets. We discuss three major use cases for serving and consuming records data: (i) static data, (ii) dynamically augmented data, (iii) on-demand simulations, (iv) with filters, and (v) with bookmarks. Separate implementations of the API exist in C++, Haskell, JavaScript, Python, and R.

Bush, Brian↗

Advanced Energy System Design (AESD): Technical Manual for the Records API

The Records API (application program interface) for Advanced Energy System Design (AESD) enables software that serves multidimensional record-oriented data to interoperate with software than uses such data. In the context of the Records API, multidimensional data records are simply tuples of real numbers, integers, and character strings, where each data value is tagged by a variable name, according to a pre-defined schema, and each record is assigned a unique integer identifier. Conceptually, these records are isomorphic to rows in a relational database, JSON objects, or key-value maps. Records servers might supply static datasets, sensor measurements that periodically update as new telemetry become available, or the results of simulations as the simulations generate new output. Records client software might display or analyze the data, but in the case of simulations the client request the creation of new ensembles for specified input parameters. It is also possible to chain records clients and servers together so that a client consuming data from a server might transform that data and serve it to further clients. This minimalist API avoids imposing burdensome metadata, structural, or implementation requirements on developers by relying on open-source technologies that is readily available for common programming languages. In particular, the API has been designed to place the smallest possible burden on services that provide data. This document defines the message format for the Records API, a transport mechanism for communicating the data, and semantics for interpreting it. The message format is specified as Google Protocol Buffers and the transport mechanism uses WebSockets. We discuss three major use cases for serving and consuming records data: (i) static data, (ii) dynamically augmented data, (iii) on-demand simulations, (iv) with filters, and (v) with bookmarks. Separate implementations of the API exist in C++, Haskell, JavaScript, Python, and R.

97 MATHEMATICS AND COMPUTING↗

Coupling Noah-Multiparameterization land-surface Model with Energy Research and Forecasting Model

The Energy Research and Forecasting (ERF) model is a high-performance atmospheric model built on the AMReX adaptive mesh refinement (AMR) framework, enabling efficient simulations on heterogeneous computing platforms that combine multicore processors with hardware accelerators. To support land–atmosphere interactions within ERF’s AMR-based environment, a land-surface model must be capable of operating directly on hierarchically refined meshes. In this work, we present a methodology for coupling the Fortran-based Noah-Multiparameterization (Noah-MP) land-surface model with ERF’s C++ codebase. Rather than rewriting Noah-MP, we construct a Fortran–C interoperability layer using CodeScribe, a tool that leverages large language models (LLMs) to automate the generation of interface code. CodeScribe applies structured prompting techniques to generate bindings that support efficient data exchange and function calls between ERF and Noah-MP. The coupling framework also incorporates AMR-aware data handling strategies, allowing NoahMP to operate seamlessly within ERF’s hierarchical mesh structure. This work provides a structured approach for integrating legacy Fortran models into modern C++-based modeling systems using LLM-assisted code generation.

54 ENVIRONMENTAL SCIENCES↗

Space mission support by NASA Space Network

Normal NASA operational considerations and Phase 1 of Space Network (SN) interoperability foresees S band cross support between user spacecraft and space networks or partnering agencies. A typical interoperable scenario for an S band user spacecraft of a partner space agency with the NASA SN is presented. ESA's Hermes Manned Spaceplane exemplifies a typical interoperable user. In order to demonstrate the support potential of the NASA SN, the internal and external interfaces of the TDRSS (Tracking and Data Relay Satellite System), ATDRSS (Advanced TDRSS), and supporting elements are examined. Communications and operational requirements for a typical mission supported by the NASA SN are discussed.

Godfrey, Robert↗

A New User Interface for On-Demand Customizable Data Products for Sensors in a SensorWeb

A SensorWeb is a set of sensors, which can consist of ground, airborne and space-based sensors interoperating in an automated or autonomous collaborative manner. The NASA SensorWeb toolbox, developed at NASA/GSFC in collaboration with NASA/JPL, NASA/Ames and other partners, is a set of software and standards that (1) enables users to create virtual private networks of sensors over open networks; (2) provides the capability to orchestrate their actions; (3) provides the capability to customize the output data products and (4) enables automated delivery of the data products to the users desktop. A recent addition to the SensorWeb Toolbox is a new user interface, together with web services co-resident with the sensors, to enable rapid creation, loading and execution of new algorithms for processing sensor data. The web service along with the user interface follows the Open Geospatial Consortium (OGC) standard called Web Coverage Processing Service (WCPS). This presentation will detail the prototype that was built and how the WCPS was tested against a HyspIRI flight testbed and an elastic computation cloud on the ground with EO-1 data. HyspIRI is a future NASA decadal mission. The elastic computation cloud stores EO-1 data and runs software similar to Amazon online shopping.

Mandl, Daniel↗

Modelling feedbacks between human and natural processes in the land system

Abstract. The unprecedented use of Earth's resources by humans, in combination with increasing natural variability in natural processes over the past century, is affecting the evolution of the Earth system. To better understand natural processes and their potential future trajectories requires improved integration with and quantification of human processes. Similarly, to mitigate risk and facilitate socio-economic development requires a better understanding of how the natural system (e.g. climate variability and change, extreme weather events, and processes affecting soil fertility) affects human processes. Our understanding of these interactions and feedback between human and natural systems has been formalized through a variety of modelling approaches. However, a common conceptual framework or set of guidelines to model human–natural-system feedbacks is lacking. The presented research lays out a conceptual framework that includes representing model coupling configuration in combination with the frequency of interaction and coordination of communication between coupled models. Four different approaches used to couple representations of the human and natural system are presented in relation to this framework, which vary in the processes represented and in the scale of their application. From the development and experience associated with the four models of coupled human–natural systems, the following eight lessons were identified that if taken into account by future coupled human–natural-systems model developments may increase their success: (1) leverage the power of sensitivity analysis with models, (2) remember modelling is an iterative process, (3) create a common language, (4) make code open-access, (5) ensure consistency, (6) reconcile spatio-temporal mismatch, (7) construct homogeneous units, and (8) incorporating feedback increases non-linearity and variability. Following a discussion of feedbacks, a way forward to expedite model coupling and increase the longevity and interoperability of models is given, which suggests the use of a wrapper container software, a standardized applications programming interface (API), the incorporation of standard names, the mitigation of sunk costs by creating interfaces to multiple coupling frameworks, and the adoption of reproducible workflow environments to wire the pieces together.

58 GEOSCIENCES↗

An Interface Specification for Urban Air Mobility Performance Models to Support Air Traffic Management Research

Performance modeling of Urban Air Mobility vehicles in support of Air Traffic Management research poses new challenges. These aircraft often rely on a combination of fixed-wing and rotorcraft performance capabilities to enable a new and still-evolving concept of high-volume operations in densely populated areas. These characteristics lead to variability in performance model format and functionality, complicating model development and leading to difficulties for users integrating the models into their applications. This paper describes an interface specification for performance models that is intended to help address this issue. The interface aims to support the core functionality of performance models while also providing the necessary flexibility to both model developers and users. The specification describes the required model documentation, required inputs to the model, and required outputs from the model in general terms that are adaptable to most programming languages. The utilization of an appropriate interface specification will support the development of an Urban Air Mobility performance model database and help to improve interoperability of these models for a broad array of user applications.

Trajectory Prediction↗

An Interface Specification for Urban Air Mobility Performance Models to Support Air Traffic Management Research

Performance modeling of Urban Air Mobility vehicles in support of Air Traffic Management research poses new challenges. These aircraft often rely on a combination of fixed-wing and rotorcraft performance capabilities to enable a new and still-evolving concept of high-volume operations in densely populated areas. These characteristics lead to variability in performance model format and functionality, complicating model development and leading to difficulties for users integrating the models into their applications. This paper describes an interface specification for performance models that is intended to help address this issue. The interface aims to support the core functionality of performance models while also providing the necessary flexibility to both model developers and users. The specification describes the required model documentation, required inputs to the model, and required outputs from the model in general terms that are adaptable to most programming languages. The utilization of an appropriate interface specification will support the development of an Urban Air Mobility performance model database and help to improve interoperability of these models for a broad array of user applications.

Trajectory Prediction↗

Multidisciplinary Model Transformation Through Simplified Intermediate Representations

There has long been a challenge of making engineering tools from multiple disciplines interoperate. This problem extends to system modeling practices. This challenge has been confronted with a wide variety of techniques. These techniques include attempting to interface tools together into combined suites, attempting to find underlying commonalities in mathematics, supporting connections through semantic encoding, various graph mappings and transformations, and code wrappers. All of these approaches have strengths and weaknesses. These are measured in multiple areas: relative freedom of action of individual domain engineers in developing their own tools, speed of execution, ease of creation, traceability, fidelity of information transfer, and degree of alignment between the concepts of different domains. This paper presents an approach to this interoperation problem currently being used in the World-Wide Web. The approach is to develop easy-to-parse formats that allow flexibility to both the file author and file interpreter. Many of the formats that are currently deployed sacrifice runtime performance for the ability of third parties to easily understand what to do with the data. XML became popular earlier as a de-facto standard format for many web applications, but is now being replaced by JSON to enhance human readability and provide a simpler data model. This is the basis for work in this paper. Our approach, which provides the key to interoperation, is a simplified “shrapnel” intermediate collection of objects and relationships that is the result of a breakdown of the system model into minimal pieces. It is then reassembled on the destination side, forming a two-step transformation. Previous efforts with single-step transformations have proven too difficult to create efficiently. In contrast, the use of this approach leads to an almost automatic procedure for transformation development. The Europa project is a large engineering project that must coordinate the efforts of many different teams with different specialties. The traditional form of exchanging engineering information has been documentation. The vision of model-based systems engineering is to make this information exchange much more digital. This paper presents the application of our simplified format to connecting two different engineering tools to the system model, with a focus on a dynamic mission simulation encoded in Modelica.

Cole, Bjorn↗

Exploring NASA GES DISC Data with Interoperable Services

Overview of NASA GES DISC (NASA Goddard Earth Science Data and Information Services Center) data with interoperable services: Open-standard and Interoperable Services Improve data discoverability, accessibility, and usability with metadata, catalogue and portal standards Achieve data, information and knowledge sharing across applications with standardized interfaces and protocols Open Geospatial Consortium (OGC) Data Services and Specifications Web Coverage Service (WCS) -- data Web Map Service (WMS) -- pictures of data Web Map Tile Service (WMTS) --- pictures of data tiles Styled Layer Descriptors (SLD) --- rendered styles.

Giovanni↗

Locating Biodiversity Data Through The Global Change Master Directory

The Global Change Master Directory (GCMD) presently holds descriptions for almost 7000 data sets held worldwide. The directory's primary purpose is for data discovery. The information provided through the GCMD's Directory Interchange Format (DIF) is the set of information that a researcher would need to determine if a particular data set could be of value. By offering data set descriptions worldwide in many scientific disciplines - including meteorology, oceanography, ecology, geology, hydrology, geophysics, remote sensing, paleoclimate, solar-terrestrial physics, and human dimensions of climate change - the GCMD simplifies the discovery of data sources. Direct linkages to many of the data sets are also provided. In addition, several data set registration tools are offered for populating the directory. To search the directory, one may choose the Guided Search or Free-Text Search. Two experimental interfaces were also made available with the latest software release - one based on a keyword search and another based on a graphical interface. The graphical interface was designed in collaboration with the Human Computer Interaction Laboratory at the University of Maryland. The latest version of the software, Version 6, was released in April, 1998. It features the implementation of a scheme to handle hierarchical data set collections (parent-child relationships); a hierarchical geospatial location search scheme; a Java-based geographic map for conducting geospatial searches; a Related-URL field for project-related data set collections, metadata extensions (such as more detailed inventory information), etc.; a new implementation of the Isite software; a new dataset language field; hyperlinked email addresses, and more. The key to the continued evolution of the GCMD is in the flexibility of the GCMD database, allowing modifications and additions to made relatively easily to maintain currency, thus providing the ability to capitalize on current technology while importing all existing records. Changes are discussed and approved through an online "interoperability" forum. The next major release of the GCMD is scheduled for early 1999 and will include the incorporation of a new matrix-based interface, a rapid valids-based query system; improvement in the operations facility - important for future distributed options; new streamlined code for greater performance and maintainability; improvements in the handling of seven current fields proposed through the interoperability forum (at no expense to the data providers); and the release of DOCmorph, a more robust version of DIFmorph to translate many 'standards' multi-directionally. Issues and actions will also be addressed.

Olsen, Lola M.↗

Recommendations for a service framework to access astronomical archives

There are a large number of astronomical archives and catalogs on-line for network access, with many different user interfaces and features. Some systems are moving towards distributed access, supplying users with client software for their home sites which connects to servers at the archive site. Many of the issues involved in defining a standard framework of services that archive/catalog suppliers can use to achieve a basic level of interoperability are described. Such a framework would simplify the development of client and server programs to access the wide variety of astronomical archive systems. The primary services that are supplied by current systems include: catalog browsing, dataset retrieval, name resolution, and data analysis. The following issues (and probably more) need to be considered in establishing a standard set of client/server interfaces and protocols: Archive Access - dataset retrieval, delivery, file formats, data browsing, analysis, etc.; Catalog Access - database management systems, query languages, data formats, synchronous/asynchronous mode of operation, etc.; Interoperability - transaction/message protocols, distributed processing mechanisms (DCE, ONC/SunRPC, etc), networking protocols, etc.; Security - user registration, authorization/authentication mechanisms, etc.; Service Directory - service registration, lookup, port/task mapping, parameters, etc.; Software - public vs proprietary, client/server software, standard interfaces to client/server functions, software distribution, operating system portability, data portability, etc. Several archive/catalog groups, notably the Astrophysics Data System (ADS), are already working in many of these areas. In the process of developing StarView, which is the user interface to the Space Telescope Data Archive and Distribution Service (ST-DADS), these issues and the work of others were analyzed. A framework of standard interfaces for accessing services on any archive system which would benefit archive user and supplier alike is proposed.

Travisano, J. J.↗