Search NASA⌕ Search

SEARCH · Search NASA

Results for “Network Time Protocol”

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 307 records · Page 17
All sourcesNASA NTRSDOE OSTI
NASA NTRSDate not supplied

A Notional Artemis Lunar Surface Exploration Package (ArLSEP) based on the Gandalf Staff Platform

Introduction: The Artemis program is planning to deliver crew and cargo to the lunar surface, but there is no current package for supporting lunar in-struments and experiments similar to the Apollo Lunar Surface Exploration Package (ALSEP). This abstract provides a possible concept for such a package using the Gandalf Staff Platform as a common core. Gandalf Staff: The Gandalf Staff is an early prototype system developed over FY’21/FY’22 using NASA Science Technology Mission Directorate (STMD) Center Information Fund (CIF) grants to de-sign, build and test “proof-of-concept” components. These components include a 24v battery powered monopole that powers a suite of subsystems, including a Graphical User Interface (GUI) for crew, surface voice and data communications, Lunar Search and Rescue (LunaSAR) navigation and communications, LiDAR, field site external lighting, 360-degree camera, and a geothermal instrument for measuring sub-surface temperature gradient. The staff can be carried independently by an Extra-Vehicular Activity (EVA) astronaut, or can be mounted into a tripod for “hands free” support at a surface site being investigated. The staff can be attached to an external solar array and power storage system for long-duration operations. [1,2] ALSEP: An ASLEP flew on each mission Apollo 12 to Apollo 17. For Apollo 11, a simplified packaged called the Early Apollo Scientific Experiments Pack-age (EASEP) was flown. Each package included a “Central Station” that provided the power and communications connected to a variety of instruments and sensors. The power was provided by a Radioisotope Thermoelectric Generator (RTG) fueled by Plutoni-um-238 generating 70 watts of power (initially, decayed over time) [3]. The communications system provide for direct to Earth data transfer from the lunar surface. Each pack-age was stowed externally in the Lunar Module (LM) Scientific Equipment (SEQ) bay with a mass up to 163 kg (Apollo 17). The crew unloaded the ALSEP from the LM and deployed the instruments on the lunar surface. Although designed to operate for only 1 year, many sites operated for up to 8 years successfully [4]. The Active Seismic Experiment (ASE) included 3 geophones for detecting seismic waves created by mortars and thumpers deployed by the crew. Other active experiments measured the lunar atmosphere, the heat flow in the subsurface, the lunar gravity and potential gravity waves, the lunar magnetic field, the solar wind and plasma interactions in cislunar space. Passive experiments included collectors for dust and cosmic rays, and retroreflectors for precise measurements of distance using a laser from Earth. The ALSEP program continues to generate insights into lunar formation and evolution. ArLSEP Concepts: The lunar surface science package for the Artemis program will hopefully exceed the capability of the ALSEP. There are multiple issues for discussion leading to the design of a new ArLSEP, needing requirements definition from the science community, NASA mission architecture, and NASA budget planners. 1. Delivery Mechanism Two possible projects currently provide capability to deliver scientific cargo to the lunar surface: 1) the Commercial Lunar Payload Services (CLPS) [5] and the Human Landing System (HLS) [6, 7]. Each project is controlled by a different organization within NASA and budgeted with different criteria although both support lunar exploration. The HLS system delivers crew (and potentially cargo) to human landing sites. If an ArLSEP is “predeployed” to such a site, the design must include power (either from the vehicle or independently) to keep the electronics functioning until deployed by the crew. If an ArLSEP is delivered on a vehicle after the crew is present on the lunar surface, safety protocols require adequate distance from the humans for impact from descent propelled sur-face regolith ejecta. This distance can not exceed the capability of the crew to walk (if no rover) to the vehicle for ArLSEP deployment. 2. Overall Guidelines The general design of ArLSEP will likely follow the ALSEP with a common system for communications and power; however, significant architecture differences between Apollo and Artemis exist. Power: The RTG will not be available for early Artemis missions nor likely follow-on Lunar Exploration Transportation Services (LETS) missions [8]. Thus, ArLSEP power must be supplied by solar arrays with sufficient battery capability to “keep alive” necessary electronics during any lunar surface eclipse period. Communication: The Artemis program is developing a series of communications satellites for lunar orbit to provide surface transmission of data and voice to Earth. Called “LunaNET”, this network is component useful for ArLSEP since south polar locations may not always have direct “line-of-sight” to Earth [9]. 3. Concept of Operations (ConOps) The general ConOps for ArLSEP is to deliver the package to lunar surface before the crew arrives, and then have the crew deploy the package after some period of time. This requires coordinated design (for power systems) and launch window (for schedule) on both the cargo and crew missions. Once the ArLSEP is deployed, it will operate autonomously for a number of years. It should be designed to be EVA compatible for crew maintenance and upgrade. 4. Notional Design (for discussion purpose only) The landing site near the South Pole is expected to have no eclipse cycle exceeding 5 days, so the “keep alive” power is 144 hours (6 days to include margin). A 12v ArLSEP will use rechargeable LiFePO4 cells, which are common in the Electric Vehicle (EV) industry. With a current of 5 amps and a 125 watt system, the mass is about 90kg. The comm. system and structure adds another 10kg, thus the “Central Station” is approximately 100kg. The solar power is collected on four arrays (each 2m above the surface), and the entire ArLSEP is designed to stow in a 2m x 1m x 1m volume. The experiment and instrument design will vary for each installation and add mass to the total (although they are expected to fit within the 2m3 volume). Seismic wave generation will likely not be provided with mortars, thus an electric “thumper” will be required. Active instruments such as imaging systems and sensing instruments will benefit from the additional power and communication capability provided by ArLSEP. Passive systems such as retroreflectors, witness plates, and cosmic dust collectors can be added to either the landing vehicle and/or the ArLSEP. With repeated HLS missions to the same human site, the ArLSEP can be expanded and easily maintained for long duration science collection on the lunar surface.

ALSEP↗
DOE OSTI2025

Understanding EV Charging Pain Points Through Deep Learning Analysis

Current and potential electric vehicle (EV) owners express concerns about the charging infrastructure, mentioning non-functional chargers, prolonged charging times, inconvenient charger locations, long wait times, and high costs as major barriers. Addressing these issues often requires analyzing actual vehicle charging data, which is typically proprietary and inconsistent due to diverse standards and protocols. To understand and improve the EV charging experience, customer reviews are typically used to identify common customer pain points (CPPs). However, there is not a comprehensive method to map customer reviews to a standardized set of CPPs. In collaboration with the National Charging Experience (ChargeX) Consortium, this study bridges these gaps by proposing a Systematic Categorization and Analysis of Large-scale EV-charging Reviews (SCALER) framework. SCALER is an integrated, deep learning framework that segments, actively labels, analyzes, and classifies EV charging customer reviews into six CPP categories. To test its effectiveness, we used SCALER to analyze over 72,000 reviews from customers charging various EV models on different networks across the United States. SCALER achieves a classification accuracy of 92.5%, with an F1 score exceeding 85.7%. By demonstrating real-world applications of SCALER, we enhance the industry’s ability to understand and address CPPs to improve the EV charging experience.

29 - ENERGY PLANNING, POLICY AND ECONOMY↗
NASA NTRS2011

Interplanetary Overlay Network Bundle Protocol Implementation

The Interplanetary Overlay Network (ION) system's BP package, an implementation of the Delay-Tolerant Networking (DTN) Bundle Protocol (BP) and supporting services, has been specifically designed to be suitable for use on deep-space robotic vehicles. Although the ION BP implementation is unique in its use of zero-copy objects for high performance, and in its use of resource-sensitive rate control, it is fully interoperable with other implementations of the BP specification (Internet RFC 5050). The ION BP implementation is built using the same software infrastructure that underlies the implementation of the CCSDS (Consultative Committee for Space Data Systems) File Delivery Protocol (CFDP) built into the flight software of Deep Impact. It is designed to minimize resource consumption, while maximizing operational robustness. For example, no dynamic allocation of system memory is required. Like all the other ION packages, ION's BP implementation is designed to port readily between Linux and Solaris (for easy development and for ground system operations) and VxWorks (for flight systems operations). The exact same source code is exercised in both environments. Initially included in the ION BP implementations are the following: libraries of functions used in constructing bundle forwarders and convergence-layer (CL) input and output adapters; a simple prototype bundle forwarder and associated CL adapters designed to run over an IPbased local area network; administrative tools for managing a simple DTN infrastructure built from these components; a background daemon process that silently destroys bundles whose time-to-live intervals have expired; a library of functions exposed to applications, enabling them to issue and receive data encapsulated in DTN bundles; and some simple applications that can be used for system checkout and benchmarking.

Burleigh, Scott C.↗
DOE OSTI2025

Quality-Controlled Meteorological Data from the Flood Control District of Maricopa County (FCDMC) Network, Phoenix, Arizona (1987-2024)

This dataset contains 15- or 30-minute interval meteorological data from the Flood Control District of Maricopa County (FCDMC), Arizona, USA, covering eight key variables across multiple sensor stations between 1987 and 2024. Each variable is stored as a separate CSV file, containing time-series data that have undergone rigorous quality control (QC) procedures and, where appropriate, short-gap interpolation for consistency. The quality control (QC) pipeline consisted of four sequential tests: (1) a range test to ensure all values fall within physically realistic limits, (2) a step test to identify abrupt and implausible changes between consecutive records, (3) a proximity test that validates flagged values from step test using data from nearby stations and exceedance probability thresholds, and (4) a persistence test to detect and remove periods of unrealistically constant readings. These thresholds were calibrated to Arizona’s environmental conditions and sensor specifications. After QC, short gaps (≤2 hours) were linearly interpolated to ensure consistent temporal resolution, except for wind variables. Due to a major upgrade in FCDMC’s data transmission system, only ALERT-2 protocol data (2016–2024) for wind variables are included; earlier ALERT-1 data were excluded because of irregular sampling and high missing rates. This dataset supports regional climate and infrastructure resilience studies by providing standardized, high-resolution meteorological data for the greater Phoenix metropolitan area.

54 ENVIRONMENTAL SCIENCES↗
NASA NTRSDate not supplied

NASA’s Interest in 3GPP Mobile Telecommunications Protocols for Near Earth Space and the Lunar Surface

In the next several years, NASA intends to return astronauts to the Moon through the Artemis Program. Under Artemis, NASA plans to collaborate with commercial and international partners to establish a long-term presence on the Moon. Near-term Artemis missions will be analogous but much more sophisticated versions of the last couple of Apollo missions. For example, the first area expected to be explored by an Artemis mission is near the south pole as opposed to the mid-latitudes visited by the Apollo astronauts, which makes direct communications with Earth more complicated. Lunar infrastructure will eventually be built over time by many organizations, public and private, to support sustained human exploration, science, and industrial activities on the Moon. A robust lunar communications and navigation infrastructure will be essential to realizing this long-term vision. Meanwhile, on Earth, major advances are being made as5G mobile telecommunications rollout across the globe. Furthermore, the 3rdGeneration Partnership Project (3GPP) is beginning to define future 6G capabilities. NASA envisions a lunar communications and navigation network with capabilities similar to those of communication networks we enjoy here on Earth. Building such a network will require participation by many organizations. NASA’s Tipping Point program seeks industry-developed space technologies that can both foster commercial space capabilities and benefit future NASA missions. This paper provides an overview of NASA’s interest in 3GPPanddescribescurrent work based on 3GPP standards within NASA or funded by NASA, such as Nokia’s upcoming Tipping Point demonstration of 4G/LTE on the lunar surface in early 2023.

Bernard L Edwards↗
NASA NTRS2000

Internet Technologies for Space-based Communications: State of the Art and Challenges

The Internet is rapidly changing the ways we communicate information around the globe today. The desire to provide Internet-based services to anyone, anywhere, anytime has brought satellite communications to the forefront to become an integral part of the Internet. In spite of the distances involved, satellite links are proving to be capable of providing Internet services based on Internet protocol (TCP/IP) stack. This development has led to the question particularly at NASA; can satellites and other space platforms become an Internet-node in space? This will allow the direct transfer of information directly from space to the users on Earth and even be able to control the spacecraft and its instruments. NASA even wants to extend the near earth space Internet to deep space applications where scientists and the public here on Earth may view space exploration in real time via the Internet. NASA's future solar system exploration will involve intensive in situ investigations of planets, moons, asteroids, and comets. While past missions typically involved a single fly-by or orbiting science spacecraft, future missions will begin to use fleets of small, highly intelligent robotic vehicles to carry out collaborative investigations. The resulting multi-spacecraft topologies will effectively create a wide area network spanning the solar system. However, this will require significant development in Internet technologies for space use. This paper provides the status'of the Internet for near earth applications and the potential extension of the Internet for use in deep space planetary exploration. The paper will discuss the overall challenges of implementing the space Internet and how the space Internet will integrate into the complex terrestrial systems those forms the Internet of today in a hybrid set of networks. Internet. We envision extending to the deep space environment such Internet concepts as a well-designed layered architecture. This effort will require an ability to develop and infuse new physical layer technology to increase network bandwidth at very low-bit error rates. In addition, we identify network technologies such as routers and switches needed to maintain standard application layer interfaces, while providing low-cost, efficient, modular networking solutions. We will describe the overall architectural approach to extending the concept of the Internet to space and highlight the important technological challenges and initiatives that will make it a reality.

Bhasin, K.↗
NASA NTRS2014

Carbon-Temperature-Water Change Analysis for Peanut Production Under Climate Change: A Prototype for the AgMIP Coordinated Climate-Crop Modeling Project (C3MP)

Climate change is projected to push the limits of cropping systems and has the potential to disrupt the agricultural sector from local to global scales. This article introduces the Coordinated Climate-Crop Modeling Project (C3MP), an initiative of the Agricultural Model Intercomparison and Improvement Project (AgMIP) to engage a global network of crop modelers to explore the impacts of climate change via an investigation of crop responses to changes in carbon dioxide concentration ([CO2]), temperature, and water. As a demonstration of the C3MP protocols and enabled analyses, we apply the Decision Support System for Agrotechnology Transfer (DSSAT) CROPGRO-Peanut crop model for Henry County, Alabama, to evaluate responses to the range of plausible [CO2], temperature changes, and precipitation changes projected by climate models out to the end of the 21st century. These sensitivity tests are used to derive crop model emulators that estimate changes in mean yield and the coefficient of variation for seasonal yields across a broad range of climate conditions, reproducing mean yields from sensitivity test simulations with deviations of ca. 2% for rain-fed conditions. We apply these statistical emulators to investigate how peanuts respond to projections from various global climate models, time periods, and emissions scenarios, finding a robust projection of modest (<10%) median yield losses in the middle of the 21st century accelerating to more severe (>20%) losses and larger uncertainty at the end of the century under the more severe representative concentration pathway (RCP8.5). This projection is not substantially altered by the selection of the AgMERRA global gridded climate dataset rather than the local historical observations, differences between the Third and Fifth Coupled Model Intercomparison Project (CMIP3 and CMIP5), or the use of the delta method of climate impacts analysis rather than the C3MP impacts response surface and emulator approach.

climate change↗
NASA NTRS2009

Standards-Based Wireless Sensor Networking Protocols for Spaceflight Applications

Wireless sensor networks (WSNs) have the capacity to revolutionize data gathering in both spaceflight and terrestrial applications. WSNs provide a huge advantage over traditional, wired instrumentation since they do not require wiring trunks to connect sensors to a central hub. This allows for easy sensor installation in hard to reach locations, easy expansion of the number of sensors or sensing modalities, and reduction in both system cost and weight. While this technology offers unprecedented flexibility and adaptability, implementing it in practice is not without its difficulties. Any practical WSN deployment must contend with a number of difficulties in its radio frequency (RF) environment. Multi-path reflections can distort signals, limit data rates, and cause signal fades that prevent nodes from having clear access to channels, especially in a closed environment such as a spacecraft. Other RF signal sources, such as wireless internet, voice, and data systems may contend with the sensor nodes for bandwidth. Finally, RF noise from electrical systems and periodic scattering from moving objects such as crew members will all combine to give an incredibly unpredictable, time-varying communication environment.

Barton, Richard J.↗
NASA NTRS2008

The NASA Real Time Mission Monitor - A Situational Awareness Tool for Conducting Tropical Cyclone Field Experiments

The NASA Real Time Mission Monitor (RTMM) is a situational awareness tool that integrates satellite, aircraft state information, airborne and surface instruments, and weather state data in to a single visualization package for real time field experiment management. RTMM optimizes science and logistic decision-making during field experiments by presenting timely data and graphics to the users to improve real time situational awareness of the experiment's assets. The RTMM is proven in the field as it supported program managers, scientists, and aircraft personnel during the NASA African Monsoon Multidisciplinary Analyses (investigated African easterly waves and Tropical Storm Debby and Helene) during August-September 2006 in Cape Verde, the Tropical Composition, Cloud and Climate Coupling experiment during July-August 2007 in Costa Rica, and the Hurricane Aerosonde mission into Hurricane Noel in 2-3 November 2007. The integration and delivery of this information is made possible through data acquisition systems, network communication links, and network server resources built and managed by collaborators at NASA Marshall Space Flight Center (MSFC) and Dryden Flight Research Center (DFRC). RTMM is evolving towards a more flexible and dynamic combination of sensor ingest, network computing, and decision-making activities through the use of a service oriented architecture based on community standards and protocols. Each field experiment presents unique challenges and opportunities for advancing the functionality of RTMM. A description of RTMM, the missions it has supported, and its new features that are under development will be presented.

Goodman, Michael↗
NASA NTRS1995

Performance and policy dimensions in internet routing

The Internet Routing Project, referred to in this report as the 'Highball Project', has been investigating architectures suitable for networks spanning large geographic areas and capable of very high data rates. The Highball network architecture is based on a high speed crossbar switch and an adaptive, distributed, TDMA scheduling algorithm. The scheduling algorithm controls the instantaneous configuration and swell time of the switch, one of which is attached to each node. In order to send a single burst or a multi-burst packet, a reservation request is sent to all nodes. The scheduling algorithm then configures the switches immediately prior to the arrival of each burst, so it can be relayed immediately without requiring local storage. Reservations and housekeeping information are sent using a special broadcast-spanning-tree schedule. Progress to date in the Highball Project includes the design and testing of a suite of scheduling algorithms, construction of software reservation/scheduling simulators, and construction of a strawman hardware and software implementation. A prototype switch controller and timestamp generator have been completed and are in test. Detailed documentation on the algorithms, protocols and experiments conducted are given in various reports and papers published. Abstracts of this literature are included in the bibliography at the end of this report, which serves as an extended executive summary.

Mills, David L.↗
DOE OSTI2024

Emerging Trends and Technologies Used for the Identification, Detection, and Characterisation of Plant-Parasitic Nematode Infestation in Crops

Accurate identification and estimation of the population densities of microscopic, soil-dwelling plant-parasitic nematodes (PPNs) are essential, as PPNs cause significant economic losses in agricultural production systems worldwide. This study presents a comprehensive review of emerging techniques used for the identification of PPNs, including morphological identification, molecular diagnostics such as polymerase chain reaction (PCR), high-throughput sequencing, meta barcoding, remote sensing, hyperspectral analysis, and image processing. Classical morphological methods require a microscope and nematode taxonomist to identify species, which is laborious and time-consuming. Alternatively, quantitative polymerase chain reaction (qPCR) has emerged as a reliable and efficient approach for PPN identification and quantification; however, the cost associated with the reagents, instrumentation, and careful optimisation of reaction conditions can be prohibitive. High-throughput sequencing and meta-barcoding are used to study the biodiversity of all tropical groups of nematodes, not just PPNs, and are useful for describing changes in soil ecology. Convolutional neural network (CNN) methods are necessary to automate the detection and counting of PPNs from microscopic images, including complex cases like tangled nematodes. Remote sensing and hyperspectral methods offer non-invasive approaches to estimate nematode infestations and facilitate early diagnosis of plant stress caused by nematodes and rapid management of PPNs. This review provides a valuable resource for researchers, practitioners, and policymakers involved in nematology and plant protection. It highlights the importance of fast, efficient, and robust identification protocols and decision-support tools in mitigating the impact of PPNs on global agriculture and food security.

Plant Sciences↗
NASA NTRS2011

Tracking Climate Effects on Plant-Pollinator Interaction Phenology with Satellites and Honey Bee Hives

Background/Question/Methods: The complexity of plant-pollinator interactions, the large number of species involved, and the lack of species response functions present challenges to understanding how these critical interactions may be impacted by climate and land cover change on large scales. Given the importance of this interaction for terrestrial ecosystems, it is desirable to develop new approaches. We monitor the daily weight change of honey bee (Apis mellifera) colonies to record the phenology of the Honey Bee Nectar Flow (HBNF) in a volunteer network (honeybeenet.gsfc.nasa.gov). The records document the successful interaction of a generalist pollinator with a variety of plant resources. We extract useful HBNF phenology metrics for three seasons. Sites currently exist in 35 states/provinces in North America, with a concentration in the Mid-Atlantic region. HBNF metrics are compared to standard phenology metrics derived from remotely sensed vegetation indices from NASA's MODIS sensor and published results from NOAA's A VHRR. At any given time the percentage of plants producing nectar is usually a sma11 fraction of the total satellite sensor signal. We are interested in determining how well the 'bulk' satellite vegetation parameters relate to the phenology of the HBNF, and how it varies spatially on landscape to continental scales. Results/Conclusions: We found the median and peak seasonal HBNF dates to be robust, with variation between replicate scale hives of only a few days. We developed quality assessment protocols to identify abnormal colony artifacts. Temporally, the peak and median of the HBNF in the Mid-Atlantic show a significant advance of 0.58 d/y beginning about 1970, very similar to that observed by the A VHRR since 1982 (0.57 d/y). Spatially, the HBNF metrics are highly correlated with elevation and winter minimum temperature distribution, and exhibit significant but regionally coherent inter-annual variation. The relationship between median of the spring HBNF with the "Green-up" metric from the 500 meter MODIS NDVI phenology product, for sites throughout the Eastern US 2000-2009, is well described by a single linear fit (r(exp 2) = 0.72). We conclude.that for the tree-dominated areas of the Eastern US at least the spring HBNF can be tracked very well by MODIS phenology. Analysis of other regions and seasons is presently underway but with more limited data. Spatial patterns in the eastern US and management implications will be presented and discussed.

Esaias, Wayne E.↗
NASA NTRS2016

Deploying a Route Optimization EFB Application for Commercial Airline Operational Trials

The Traffic Aware Planner (TAP), developed for NASA Langley Research Center to support the Traffic Aware Strategic Aircrew Requests (TASAR) project, is a flight-efficiency software application developed for an Electronic Flight Bag (EFB). Tested in two flight trials and planned for operational testing by two commercial airlines, TAP is a real-time trajectory optimization application that leverages connectivity with onboard avionics and broadband Internet sources to compute and recommend route modifications to flight crews to improve fuel and time performance. The application utilizes a wide range of data, including Automatic Dependent Surveillance Broadcast (ADS-B) traffic, Flight Management System (FMS) guidance and intent, on-board sensors, published winds and weather, and Special Use Airspace (SUA) schedules. This paper discusses the challenges of developing and deploying TAP to various EFB platforms, our solutions to some of these challenges, and lessons learned, to assist commercial software developers and hardware manufacturers in their efforts to implement and extend TAP functionality in their environments. EFB applications (such as TAP) typically access avionics data via an ARINC 834 Simple Text Avionics Protocol (STAP) server hosted by an Aircraft Interface Device (AID) or other installed hardware. While the protocol is standardized, the data sources, content, and transmission rates can vary from aircraft to aircraft. Additionally, the method of communicating with the AID may vary depending on EFB hardware and/or the availability of onboard networking services, such as Ethernet, WIFI, Bluetooth, or other mechanisms. EFBs with portable and installed components can be implemented using a variety of operating systems, and cockpits are increasingly incorporating tablet-based technologies, further expanding the number of platforms the application may need to support. Supporting multiple EFB platforms, AIDs, avionics datasets, and user interfaces presents a challenge for software developers and the management of their code baselines. Maintaining multiple baselines to support all deployment targets can be extremely cumbersome and expensive. Certification also needs to be considered when developing the application. Regardless of whether the software is itself destined to be certified, data requirements in support of the application and user interface elements may introduce certification requirements for EFB manufacturers and the airlines. The example of TAP, the challenges faced, solutions implemented, and lessons learned will give EFB application and hardware developers insight into future potential requirements in deploying TAP or similar flight-deck EFB applications.

Roscoe, David A.↗
NASA NTRS2016

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↗
NASA NTRS1994

Data communication network at the ASRM facility

This three-year project (February 1991 to February 1994) has involved analyzing and helping to design the communication network for the Advanced Solid Rocket Motor (ASRM) facility at Yellow Creek, near Iuka, MS. The principal concerns in the analysis were the bandwidth (both on average and in the worst case) and the expandability of the network. As the communication network was designed and modified, a careful evaluation of the bandwidth of the network, the capabilities of the protocol, and the requirements of the controllers and computers on the network was required. The overall network, which was heterogeneous in protocol and bandwidth, needed to be modeled, analyzed, and simulated to obtain some degree of confidence in its performance capabilities and in its performance under nominal and heavy loads. The results of our analysis did have an impact on the design and operation of the ASRM facility. During 1993 we analyzed many configurations of this basic network structure. The analyses are described in detail in Section 2 and 3 herein. Section 2 reports on an analysis of the whole network. The preliminary results of that research indicated that the most likely bottleneck as the network traffic increased would be the hubs. Thus a study of Cabletron hubs was initiated. The results of that study are in Section 3. Section 4 herein reports on the final network configuration analyzed. When the ASRM facility was mothballed in December of 1993, this was basically the planned and partially installed network. A briefing was held at NASA/MSFC on December 7, 1993, at which time our final analysis and conclusions were disseminated. This report contains a written record of most of the information disseminated at that briefing.

Moorhead, Robert J., III↗
NASA NTRS2012

NASA Tech Briefs, December 2012

The topics include: Pattern Generator for Bench Test of Digital Boards; 670-GHz Down- and Up-Converting HEMT-Based Mixers; Lidar Electro-Optic Beam Switch with a Liquid Crystal Variable Retarder; Feedback Augmented Sub-Ranging (FASR) Quantizer; Real-Time Distributed Embedded Oscillator Operating Frequency Monitoring; Software Modules for the Proximity-1 Space Link Interleaved Time Synchronization (PITS) Protocol; Description and User Instructions for the Quaternion to Orbit v3 Software; AdapChem; Mars Relay Lander and Orbiter Overflight Profile Estimation; Extended Testability Analysis Tool; Interactive 3D Mars Visualization; Rapid Diagnostics of Onboard Sequences; MER Telemetry Processor; pyam: Python Implementation of YaM; Process for Patterning Indium for Bump Bonding; Archway for Radiation and Micrometeorite Occurrence Resistance; 4D Light Field Imaging System Using Programmable Aperture; Device and Container for Reheating and Sterilization; Radio Frequency Plasma Discharge Lamps for Use as Stable Calibration Light Sources; Membrane Shell Reflector Segment Antenna; High-Speed Transport of Fluid Drops and Solid Particles via Surface Acoustic Waves; Compact Autonomous Hemispheric Vision System; A Distributive, Non-Destructive, Real-Time Approach to Snowpack Monitoring; Wideband Single-Crystal Transducer for Bone Characterization; Numerical Simulation of Rocket Exhaust Interaction With Lunar Soil; Motion Imagery and Robotics Application (MIRA): Standards-Based Robotics; Particle Filtering for Model-Based Anomaly Detection in Sensor Networks; Ka-band Digitally Beamformed Airborne Radar Using SweepSAR Technique; Composite With In Situ Plenums; Multi-Beam Approach for Accelerating Alignment and Calibration of HyspIRI-Like Imaging Spectrometers; JWST Lifting System; Next-Generation Tumbleweed Rover; Pneumatic System for Concentration of Micrometer-Size Lunar Soil.

Source record↗
NASA NTRSDate not supplied

A Distributed Simulation-to-Flight Framework to Support Investigating Trust/Trustworthiness in Multi-Agent Systems

As autonomous systems continue to grow both in use and complexity, the necessity for robust and extensible simulation-to-flight methods is paramount for establishing an effective architecture for autonomous systems. A fundamental objective of the ATTRACTOR (Autonomy Teaming and TRAjectories for Complex Trusted Operational Reliability) project was to design and develop a distributed mixed-reality simulation environment to begin establishing a basis for certification of autonomous systems via research into trust and trustworthiness. In this paper, we present an autonomous systems architecture and development framework paired with a persistent distributed modeling and simulation environment for test and evaluation of autonomous systems. The Autonomous Entity Operations Network (AEON) framework enables autonomous system development with an easily extensible collection of libraries and plug-n-play nodes facilitated by the Data Distribution Service (DDS) communication protocol standard. The Baseline Environment for Autonomous Modeling (BEAM) simulation environment is a distributed mixed-reality Unity™-based environment built around the same DDS communication paradigm allowing for easy integration with AEON-based autonomous applications. They were designed under ATTRACTOR in order to measure and establish trustworthiness and trust in single- and multi-agent human-machine systems whether these machines are fixed-wing general aviation, rotary-wing Unmanned Aerial Vehicles (UAVs), ground rovers, or even spacecraft. Together AEON and BEAM enable sim-to-flight with minimal configuration changes. By using AEON and BEAM, source code that runs in simulation ports directly to hardware and has successfully flown in the lab and in the National Airspace System (NAS) at NASA LaRC many times over the lifetime of ATTRACTOR.

Benjamin N Kelley↗