Search NASA⌕ Search

SEARCH · Search NASA

Results for “interoperability”

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 1,261 records · Page 70

Flight Test 4 Preliminary Results: NASA Ames SSI

Realization of the expected proliferation of Unmanned Aircraft System (UAS) operations in the National Airspace System (NAS) depends on the development and validation of performance standards for UAS Detect and Avoid (DAA) Systems. The RTCA Special Committee 228 is charged with leading the development of draft Minimum Operational Performance Standards (MOPS) for UAS DAA Systems. NASA, as a participating member of RTCA SC-228 is committed to supporting the development and validation of draft requirements as well as the safety substantiation and end-to-end assessment of DAA system performance. The Unmanned Aircraft System (UAS) Integration into the National Airspace System (NAS) Project conducted flight test program, referred to as Flight Test 4, at Armstrong Flight Research Center from April -June 2016. Part of the test flights were dedicated to the NASA Ames-developed Detect and Avoid (DAA) System referred to as JADEM (Java Architecture for DAA Extensibility and Modeling). The encounter scenarios, which involved NASA's Ikhana UAS and a manned intruder aircraft, were designed to collect data on DAA system performance in real-world conditions and uncertainties with four different surveillance sensor systems. Flight test 4 has four objectives: (1) validate DAA requirements in stressing cases that drive MOPS requirements, including: high-speed cooperative intruder, low-speed non-cooperative intruder, high vertical closure rate encounter, and Mode CS-only intruder (i.e. without ADS-B), (2) validate TCASDAA alerting and guidance interoperability concept in the presence of realistic sensor, tracking and navigational errors and in multiple-intruder encounters against both cooperative and non-cooperative intruders, (3) validate Well Clear Recovery guidance in the presence of realistic sensor, tracking and navigational errors, and (4) validate DAA alerting and guidance requirements in the presence of realistic sensor, tracking and navigational errors. The results will be presented at RTCA Special Committee 228 in support of final verification and validation of the DAA MOPS.

Detect-And-Avoid (DAA)↗

NASA Briefing for Unidata

The NASA representative to the Unidata Strategic Committee presented a semiannual update on NASAs work with and use of Unidata technologies. The talk covered the program of cloud computing prototypes being undertaken for the Earth Observing System Data and Information System (EOSDIS). Also discussed were dataset interoperability recommendations ratified via the EOSDIS Standards Office and the HDF Product Designer tool with respect to its possible applicability to data in network Common Data Form (NetCDF) version 4.

data integration↗

GeneLab Phase 2: Integrated Search Data Federation of Space Biology Experimental Data

The GeneLab project is a science initiative to maximize the scientific return of omics data collected from spaceflight and from ground simulations of microgravity and radiation experiments, supported by a data system for a public bioinformatics repository and collaborative analysis tools for these data. The mission of GeneLab is to maximize the utilization of the valuable biological research resources aboard the ISS by collecting genomic, transcriptomic, proteomic and metabolomic (so-called omics) data to enable the exploration of the molecular network responses of terrestrial biology to space environments using a systems biology approach. All GeneLab data are made available to a worldwide network of researchers through its open-access data system. GeneLab is currently being developed by NASA to support Open Science biomedical research in order to enable the human exploration of space and improve life on earth. Open access to Phase 1 of the GeneLab Data Systems (GLDS) was implemented in April 2015. Download volumes have grown steadily, mirroring the growth in curated space biology research data sets (61 as of June 2016), now exceeding 10 TB/month, with over 10,000 file downloads since the start of Phase 1. For the period April 2015 to May 2016, most frequently downloaded were data from studies of Mus musculus (39) followed closely by Arabidopsis thaliana (30), with the remaining downloads roughly equally split across 12 other organisms (each 10 of total downloads). GLDS Phase 2 is focusing on interoperability, supporting data federation, including integrated search capabilities, of GLDS-housed data sets with external data sources, such as gene expression data from NIHNCBIs Gene Expression Omnibus (GEO), proteomic data from EBIs PRIDE system, and metagenomic data from Argonne National Laboratory's MG-RAST. GEO and MG-RAST employ specifications for investigation metadata that are different from those used by the GLDS and PRIDE (e.g., ISA-Tab). The GLDS Phase 2 system will implement a Google-like, full-text search engine using a Service-Oriented Architecture by utilizing publicly available RESTful web services Application Programming Interfaces (e.g., GEO Entrez Programming Utilities) and a Common Metadata Model (CMM) in order to accommodate the different metadata formats between the heterogeneous bioinformatics databases. GLDS Phase 2 completion with fully implemented capabilities will be made available to the general public in September 2017.

Space Biology↗

AIAA Aviation UAS DAA Demonstration-Mini HITL Week 2 Stats

The UAS-NAS Project demo will showcase recent research efforts to ensure the interoperability between proposed UAS detect and avoid (DAA) human machine interface requirements (developed within RTCA SC-228) and existing collision avoidance displays. Attendees will be able to view the current state of the art of the DAA pilot traffic, alerting and guidance displays integrated with Traffic advisory and Collision Avoidance (TCAS) II in the UAS-NAS Project's research UAS ground control station (developed in partnership with the Air Force Research Laboratory). In addition, attendees will have the opportunity to interact with the research UAS ground control station and "fly" encounters, using the DAA and TCAS II displays to avoid simulated aircraft. The display of the advisories will be hosted on a laptop with an external 30" monitor, running the Vigilant Spririt system. DAA advisories will be generated by the JADEM software tool, connected to the system via the LVC Gateway. A repeater of the primary flight display will be shown on a 55" tv/monitor mounted on a stand at the back of the booth to show the pilot interaction to the passersby.

UAS↗

CEOS WGISS Common Data Framework for WGISS Connected Data Assets

This session will explore the benefits of having such a policy framework and future steps both domestically and internationally. Speakers can highlight current work being done to improve data interoperability, how the Common Framework is relevant for other data types, other countries and multinational organizations, and considerations for data management that have yet to be addressed in the Common Framework.

common framework↗

UAS Integration in the NAS Project: Flight Test 3 Data Analysis of JADEM-Autoresolver Detect and Avoid System

The Unmanned Aircraft Systems Integration in the National Airspace System project, or UAS Integration in the NAS, aims to reduce technical barriers related to safety and operational challenges associated with enabling routine UAS access to the NAS. The UAS Integration in the NAS Project conducted a flight test activity, referred to as Flight Test 3 (FT3), involving several Detect-and-Avoid (DAA) research prototype systems between June 15, 2015 and August 12, 2015 at the Armstrong Flight Research Center (AFRC). This report documents the flight testing and analysis results for the NASA Ames-developed JADEM-Autoresolver DAA system, referred to as 'Autoresolver' herein. Four flight test days (June 17, 18, 22, and July 22) were dedicated to Autoresolver testing. The objectives of this test were as follows: 1. Validate CPA prediction accuracy and detect-and-avoid (DAA, formerly known as self-separation) alerting logic in realistic flight conditions. 2. Validate DAA trajectory model including maneuvers. 3. Evaluate TCAS/DAA interoperability. 4. Inform final Minimum Operating Performance Standards (MOPS). Flight test scenarios were designed to collect data to directly address the objectives 1-3. Objective 4, inform final MOPS, was a general objective applicable to the UAS in the NAS project as a whole, of which flight test is a subset. This report presents analysis results completed in support of the UAS in the NAS project FT3 data review conducted on October 20, 2015. Due to time constraints and, to a lesser extent, TCAS data collection issues, objective 3 was not evaluated in this analysis.

flight test↗

DAIDALUS Observations From UAS Integration in the NAS Project Flight Test 4

In order to validate the Unmanned Aerial System (UAS) Detect-and-Avoid (DAA) solution proposed by standards body RTCA Inc., the National Aeronautics and Space Administration (NASA) UAS Integration in the NAS project, alongside industry members General Atomics and Honeywell, conducted the fourth flight test in a series at Armstrong Flight Research Center in Edwards, California. Flight Test 4 (FT4) investigated problems of interoperability with the TCAS collision avoidance system with a DAA system as well as problems associated with sensor uncertainty. A series of scripted flight encounters between the NASA Ikhana UAS and various "intruder" aircraft were flown while alerting and guidance from the DAA algorithm were recorded to investigate the timeliness of the alerts and correctness of the guidance triggered by the DAA system. The results found that alerts were triggered in a timely manner in most instances. Cases where the alerting and guidance was incorrect were investigated further.

Vincent, Michael J.↗

Architecture for Cognitive Networking within NASAs Future Space Communications Infrastructure

Future space mission concepts and designs pose many networking challenges for command, telemetry, and science data applications with diverse end-to-end data delivery needs. For future end-to-end architecture designs, a key challenge is meeting expected application quality of service requirements for multiple simultaneous mission data flows with options to use diverse onboard local data buses, commercial ground networks, and multiple satellite relay constellations in LEO, MEO, GEO, or even deep space relay links. Effectively utilizing a complex network topology requires orchestration and direction that spans the many discrete, individually addressable computer systems, which cause them to act in concert to achieve the overall network goals. The system must be intelligent enough to not only function under nominal conditions, but also adapt to unexpected situations, and reorganize or adapt to perform roles not originally intended for the system or explicitly programmed. This paper describes architecture features of cognitive networking within the future NASA space communications infrastructure, and interacting with the legacy systems and infrastructure in the meantime. The paper begins by discussing the need for increased automation, including inter-system collaboration. This discussion motivates the features of an architecture including cognitive networking for future missions and relays, interoperating with both existing endpoint-based networking models and emerging information-centric models. From this basis, we discuss progress on a proof-of-concept implementation of this architecture as a cognitive networking on-orbit application on the SCaN Testbed attached to the International Space Station.

space networks↗

High Data Rate Architecture (HiDRA)

One of the greatest challenges in developing new space technology is in navigating the transition from ground based laboratory demonstration at Technology Readiness Level 6 (TRL-6) to conducting a prototype demonstration in space (TRL-7). This challenge is com- pounded by the relatively low availability of new spacecraft missions when compared with aeronautical craft to bridge this gap, leading to the general adoption of a low-risk stance by mission management to accept new, unproven technologies into the system. Also in consideration of risk, the limited selection and availability of proven space-grade components imparts a severe limitation on achieving high performance systems by current terrestrial technology standards. Finally from a space communications point of view the long duration characteristic of most missions imparts a major constraint on the entire space and ground network architecture, since any new technologies introduced into the system would have to be compliant with the duration of the currently deployed operational technologies, and in some cases may be limited by surrounding legacy capabilities. Beyond ensuring that the new technology is verified to function correctly and validated to meet the needs of the end users the formidable challenge then grows to additionally include: carefully timing the maturity path of the new technology to coincide with a feasible and accepting future mission so it flies before its relevancy has passed, utilizing a limited catalog of available components to their maximum potential to create meaningful and unprecedented new capabilities, designing and ensuring interoperability with aging space and ground infrastructures while simultaneously providing a growth path to the future. The International Space Station (ISS) is approaching 20 years of age. To keep the ISS relevant, technology upgrades are continuously taking place. Regarding communications, the state-of-the-art communication system upgrades underway include high-rate laser terminals. These must interface with the existing, aging data infrastructure. The High Data Rate Architecture (HiDRA) project is designed to provide networked store, carry, and forward capability to optimize data flow through both the existing radio frequency (RF) and new laser communications terminal. The networking capability is realized through the Delay Tolerant Networking (DTN) protocol, and is used for scheduling data movement as well as optimizing the performance of existing RF channels. HiDRA is realized as a distributed FPGA memory and interface controller that is itself controlled by a local computer running DTN software. Thus HiDRA is applicable to other arenas seeking to employ next-generation communications technologies, e.g. deep space. In this paper, we describe HiDRA and its far-reaching research implications.

DTN↗

Refining the GPS Space Service Volume (SSV) and Building a Multi-GNSS SSV

The GPS (Global Positioning System) Space Service Volume (SSV) was first defined to protect the GPS main lobe signals from changes from block to block. First developed as a concept by NASA in 2000, it has been adopted for the GPS III block of satellites, and is being used well beyond the current specification to enable increased navigation performance for key missions like GOES-R. NASA has engaged the US IFOR (Interagency Forum Operational Requirements) process to adopt a revised requirement to protect this increased and emerging use. Also, NASA is working through the UN International Committee on GNSS (Global Navigation Satellite System) to develop an interoperable multi-GNSS SSV in partnership with all of the foreign GNSS providers.

Parker, Joel J. K.↗

XTCE (XML Telemetric and Command Exchange) Standard Making It Work at NASA. Can It Work For You?

The XML Telemetric and Command Exchange (XTCE) standard is intended as a way to describe telemetry and command databases to be exchanged across centers and space agencies. XTCE usage has the potential to lead to consolidation of the Mission Operations Center (MOC) Monitor and Control displays for mission cross-support, reducing equipment and configuration costs, as well as a decrease in the turnaround time for telemetry and command modifications during all the mission phases. The adoption of XTCE will reduce software maintenance costs by reducing the variation between our existing mission dictionaries. The main objective of this poster is to show how powerful XTCE is in terms of interoperability across centers and missions. We will provide results for a use case where two centers can use their local tools to process and display the same mission telemetry in their MOC independently of one another. In our use case we have first quantified the ability for XTCE to capture the telemetry definitions of the mission by use of our suite of support tools (Conversion, Validation, and Compliance measurement). The next step was to show processing and monitoring of the same telemetry in two mission centers. Once the database was converted to XTCE using our tool, the XTCE file became our primary database and was shared among the various tool chains through their XTCE importers and ultimately configured to ingest the telemetry stream and display or capture the telemetered information in similar ways.Summary results include the ability to take a real mission database and real mission telemetry and display them on various tools from two centers, as well as using commercially free COTS.

CCSDS↗

FT4 Data Analysis Summary (SSI-ARC)

Standards for Unmanned Aircraft System (UAS) Detect-and-Avoid (DAA) systems are currently being developed under the auspices of the RTCA Special Committee 228 (SC-228). To support the development of these standards, a series of flight tests has been conducted at NASAs Armstrong Flight Research Center (NASA-AFRC). The fourth in this series of flight test activities (Flight Test 4, or simply FT4) was conducted during the Spring and Summer of 2016. FT4 supported the objectives of numerous organizations working toward UAS DAA Minimum Operational Performance Standards (MOPS) and UAS DAA Radar MOPS. The summary provided herein is limited to the objectives, analysis and conclusions of the NASA Ames Research Center (NASA-ARC) SSI team toward the refinement of UAS DAA MOPS. This document provides a high-level overview of FT4 and the SSI-ARC objectives, a summary of the data analysis methodology and recommendations for UAS DAA MOPS refinements based on the data analysis results. A total of 72 encounters were flown to support SSI-ARC objectives. Test results were generally consistent with acceptable UAS DAA system performance and will be considered in broader SC-228 requirements validation efforts. Observed alert lead times indicated acceptable UAS DAA alerting performance. Effective interoperability between the UAS DAA system and the Traffic Alert and Collision Avoidance System (TCAS) was observed with one notable exception: TCAS Resolutions Advisories (RA) were observed in the absence of any DAA alert on two occasions, indicating the need for alert parameter refinement. Findings further indicated the need for continued work in the areas of DAA Well Clear Recovery logic and alert stability for Mode-C-only intruders. Finally, results demonstrated a high level of compliance with a set of evaluation criteria designed to provide anecdotal evidence of acceptable UAS DAA system performance.

UAS Test Flight↗

Ka-band Technologies for Small Spacecraft Communications via Relays and Direct Data Downlink

As the scientific capabilities and number of small spacecraft missions in the near Earth region increase, standard yet configurable user spacecraft terminals operating in Ka-band are needed to lower mission cost and risk and enable significantly higher data return than current UHF or S-band terminals. These compact Ka-band terminals are intended to operate with both the current and next generation of Ka-band relay satellites and via direct data communications with near Earth tracking terminals. This presentation provides an overview of emerging NASA-sponsored and commercially provided technologies in software defined radios (SDRs), transceivers, and electronically steered antennas that will enable data rates from hundreds of kbps to over 1 Gbps and operate in multiple frequency bands (such as S- and X-bands) and expand the use of NASA's common Ka-bands frequencies: 22.55-23.15 GHz for forward data or uplink; and 25.5-27.0 GHz for return data or downlink. Reductions in mass, power and volume come from integration of multiple radio functions, operations in Ka-band, high efficiency amplifiers and receivers, and compact, flat and vibration free electronically steered narrow beam antennas for up to + 60 degrees field of regard. The software defined near Earth space transceiver (SD-NEST) described in the presentation is intended to be compliant with NASA's space telecommunications radio system (STRS) standard for communications waveforms and hardware interoperability.

Extremely High Frequency↗

Communications for UAS Integration in the NAS Phase 2 Satellite Communications and Terrestrial Extension

In order to provide for the safe integration of unmanned aircraft systems (UAS) into the National Airspace System, the command and control communications link connecting the ground-based pilot with the unmanned aircraft must be highly reliable and robust, with national and international standards to enable interoperability and certification. Both line-of-sight (LOS) links using terrestrial-based communications and beyond-line-of-sight (BLOS) links using satellite communications, supported by national and international standards, are required for integrated UAS operations. The National Aeronautics and Space Administration (NASA) has undertaken an extensive technology development and test program in order to provide the required technical data needed to enable C2 standards development. NASAs UAS Integration in the National Airspace System (NAS), or UAS in the NAS Project, included as a major element the Command and Control Communications (C2) Subproject, based at NASAs Glenn Research Center. The successful first phase of the C2 Subproject, completed during 2012-2016, focused primarily on line-of-sight communications. Accomplishments included air-ground channel propagation characterization and modeling; CNPC prototype radio development; CNPC radio flight testing; satellite communications spectrum study and interference analysis; and development of C2 LOS communications standards development. The second phase of the C2 Subproject will focus primarily on beyond-line-of-sight communications, although a follow-on activity for terrestrial LOS communications, known as Terrestrial Extension, is also included. In addition to the terrestrial element, Phase 2 also includes technology development and testing activities for Ka-Band BLOS C2 Satellite Communications; Ku-Band BLOS C2 Satellite Communications; Ku-Band Interference and Propagation; and C-Band Satellite Communications. This paper will provide brief overviews of the C2 Subproject and its Phase I accomplishments, followed by a description of the plans for the C2 Subproject Phase 2.

radiofrequency spectrum↗

Hierarchical Data Formats (HDF) Update

In this presentation, we will talk about the latest releases of HDF4 and HDF5 software and tools, new features available in HDF5, and roadmap for the HDF software. We will also solicit feedback from the users of HDF data and HDF application developers on new features and new tools. The talk will cover: Difference between 1.8 and 1.10 releases and how and when to move to the latest release Features of the recent HDF5 1.8.19, 1.10.1 and HDF 4.2.13 Overview of HDF View 3.0 and other enhancements to tools Supported compilers and systems Open discussion of new requirements and wish list of the HDF features Compression library for interoperability with h5py and Pandas and better floating-point data compression.

HDFView↗

Data are from Mars, Tools are from Venus

Although during the data production phase, the data producers will usually ensure the products to be easily used by the specific power users the products serve. However, most data products are also posted for general public to use. It is not straightforward for data producers to anticipate what tools that these general end-data users are likely to use. In this talk, we will try to help fill in the gap by going over various tools related to Earth Science and how they work with the existing NASA HDF (Hierarchical Data Format) data products and the reasons why some products cannot be visualized or analyzed by existing tools. One goal is for to give insights for data producers on how to make their data product more interoperable. On the other hand, we also provide some hints for end users on how to make tools work with existing HDF data products. (tool category list: check the comments) HDF-EOS tools: HDFView HDF-EOS Plugin, HEG, h4tonccf, hdf-eos2 dumper, NCL, MATLAB, IDL, etc.net; CDF-Java tools: Panoply, IDV, toosUI, NcML, etc.net; CDF-C tools: ArcGIS Desktop, GrADS, NCL, NCO, etc.; GDAL tools: ArcGIS Desktop, QGIS, Google Earth, etc.; CSV tools: ArcGIS Online, MS Excel, Tableau, etc.

hdf↗

Design and Principles Enabling the Space Reference FOM

A first complete draft of the Simulation Interoperability Standards Organization (SISO) Space Reference Federation Object Model (FOM) has now been produced. This paper provides some insights into its capabilities and discusses the opportunity for reuse in other domains. The focus of this first version of the standard is execution control, time management and coordinate systems, well-known reference frames, as well as some basic support for physical entities. The biggest part of the execution control is the coordinated start-up process. This process contains a number of steps, including checking of required federates, handling of early versus late joiners, sharing of federation wide configuration data and multi-phase initialization. An additional part of Execution Control is the coordinated and synchronized transition between Run mode, Freeze mode and Shutdown. For time management, several time lines are defined, including real-time, scenario time, High Level Architecture (HLA) logical time and physical time. A strategy for mixing simulations that use different time steps is introduced, as well as an approach for finding common boundaries for fully synchronized freeze. For describing spatial information, a mechanism with a set of reference frames is specified. Each reference frame has a position and orientation related to a parent reference frame. This makes it possible for federates to perform calculations in reference frames that are convenient to them. An operation on the Moon can be performed using lunar coordinates whereas an operation on Earth can be performed using Earth coordinates. At the same time, coordinates in one reference frame have an unambiguous relationship to a coordinate in another reference frame. While the Space Reference FOM is originally being developed for Space operations, the authors believe that many parts of it can be reused for any simulation that has a focus on physical processes with one or more coordinate systems, and require high fidelity and repeatability.

Moeller, Bjoern↗

A Principled Approach to the Specification of System Architectures for Space Missions

Modern space systems are increasing in complexity and scale at an unprecedented pace. Consequently, innovative methods, processes, and tools are needed to cope with the increasing complexity of architecting these systems. A key systems challenge in practice is the ability to scale processes, methods, and tools used to architect complex space systems. Traditionally, the process for specifying space system architectures has largely relied on capturing the system architecture in informal descriptions that are often embedded within loosely coupled design documents and domain expertise. Such informal descriptions often lead to misunderstandings between design teams, ambiguous specifications, difficulty in maintaining consistency as the architecture evolves throughout the system development life cycle, and costly design iterations. Therefore, traditional methods are becoming increasingly inefficient to cope with ever-increasing system complexity. We apply the principles of component-based design and platform-based design to the development of the system architecture for a practical space system to demonstrate feasibility of our approach using SysML. Our results show that we are able to apply a systematic design method to manage system complexity, thus enabling effective data management, semantic coherence and traceability across different levels of abstraction in the design chain. Just as important, our approach enables interoperability among heterogeneous tools in a concurrent engineering model based design environment.

platform-based design↗