Search NASA⌕ Search

SEARCH · Search NASA

Results for “Transactive”

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 559 records · Page 31

Delay banking for air traffic management

A method and associated system for time delay banking for aircraft arrival time, aircraft departure time and/or en route flight position. The delay credit value for a given flight may decrease with passage of time and may be transferred to or traded with other flights having the same or a different user (airline owner or operator). The delay credit value for a given aircraft flight depends upon an initial delay credit value, which is determined by a central system and depends upon one or more other flight characteristics. Optionally, the delay credit value decreases with passage of time. Optionally, a transaction cost is assessed against a delay credit value that is used on behalf of another flight with the same user or is traded with a different user.

Green, Steven M.↗

Delay Banking for Managing Air Traffic

Delay banking has been invented to enhance air-traffic management in a way that would increase the degree of fairness in assigning arrival, departure, and en-route delays and trajectory deviations to aircraft impacted by congestion in the national airspace system. In delay banking, an aircraft operator (airline, military, general aviation, etc.) would be assigned a numerical credit when any of their flights are delayed because of an air-traffic flow restriction. The operator could subsequently bid against other operators competing for access to congested airspace to utilize part or all of its accumulated credit. Operators utilize credits to obtain higher priority for the same flight, or other flights operating at the same time, or later, in the same airspace, or elsewhere. Operators could also trade delay credits, according to market rules that would be determined by stakeholders in the national airspace system. Delay banking would be administered by an independent third party who would use delay banking automation to continually monitor flights, allocate delay credits, maintain accounts of delay credits for participating airlines, mediate bidding and the consumption of credits of winning bidders, analyze potential transfers of credits within and between operators, implement accepted transfers, and ensure fair treatment of all participating operators. A flow restriction can manifest itself in the form of a delay in assigned takeoff time, a reduction in assigned airspeed, a change in the position for the aircraft in a queue of all aircraft in a common stream of traffic (e.g., similar route), a change in the planned altitude profile for an aircraft, or change in the planned route for the aircraft. Flow restrictions are typically imposed to mitigate traffic congestion at an airport or in a region of airspace, particularly congestion due to inclement weather, or the unavailability of a runway or region of airspace. A delay credit would be allocated to an operator of a flight that has accepted, or upon which was imposed, a flow restriction. The amount of the credit would increase with the amount of delay caused by the flow restriction, the exact amount depending on which of several candidate formulas is eventually chosen. For example, according to one formula, there would be no credit for a delay smaller than some threshold value (e.g., 30 seconds) and the amount of the credit for a longer delay would be set at the amount of the delay minus the threshold value. Optionally, the value of a delay credit could be made to decay with time according to a suitable formula (e.g., an exponential decay). Also, optionally, a transaction charge could be assessed against the value of a delay credit that an operator used on a flight different from the one for which the delay originated or that was traded with a different operator. The delay credits accumulated by a given airline could be utilized in various ways. For example, an operator could enter a bid for priority handling in a new flow restriction that impacts one or more of the operator s flights; if the bid were unsuccessful, all or a portion of the credit would be returned to the bidder. If the bid pertained to a single aircraft that was in a queue, delay credits could be consumed in moving the aircraft to an earlier position within the queue. In the case of a flow restriction involving a choice of alternate routes, planned altitude profile, aircraft spacing, or other non-queue flow restrictions, delay credits could be used to bid for an alternative assignment.

Green, Steve↗

Polyphony: A Workflow Orchestration Framework for Cloud Computing

Cloud Computing has delivered unprecedented compute capacity to NASA missions at affordable rates. Missions like the Mars Exploration Rovers (MER) and Mars Science Lab (MSL) are enjoying the elasticity that enables them to leverage hundreds, if not thousands, or machines for short durations without making any hardware procurements. In this paper, we describe Polyphony, a resilient, scalable, and modular framework that efficiently leverages a large set of computing resources to perform parallel computations. Polyphony can employ resources on the cloud, excess capacity on local machines, as well as spare resources on the supercomputing center, and it enables these resources to work in concert to accomplish a common goal. Polyphony is resilient to node failures, even if they occur in the middle of a transaction. We will conclude with an evaluation of a production-ready application built on top of Polyphony to perform image-processing operations of images from around the solar system, including Mars, Saturn, and Titan.

Space Exploration,↗

The Kepler DB, a Database Management System for Arrays, Sparse Arrays and Binary Data

The Kepler Science Operations Center stores pixel values on approximately six million pixels collected every 30-minutes, as well as data products that are generated as a result of running the Kepler science processing pipeline. The Kepler Database (Kepler DB) management system was created to act as the repository of this information. After one year of ight usage, Kepler DB is managing 3 TiB of data and is expected to grow to over 10 TiB over the course of the mission. Kepler DB is a non-relational, transactional database where data are represented as one dimensional arrays, sparse arrays or binary large objects. We will discuss Kepler DB's APIs, implementation, usage and deployment at the Kepler Science Operations Center.

McCauliff, Sean↗

Kepler Science Operations Center Pipeline Framework

The Kepler mission is designed to continuously monitor up to 170,000 stars at a 30 minute cadence for 3.5 years searching for Earth-size planets. The data are processed at the Science Operations Center (SOC) at NASA Ames Research Center. Because of the large volume of data and the memory and CPU-intensive nature of the analysis, significant computing hardware is required. We have developed generic pipeline framework software that is used to distribute and synchronize the processing across a cluster of CPUs and to manage the resulting products. The framework is written in Java and is therefore platform-independent, and scales from a single, standalone workstation (for development and research on small data sets) to a full cluster of homogeneous or heterogeneous hardware with minimal configuration changes. A plug-in architecture provides customized control of the unit of work without the need to modify the framework itself. Distributed transaction services provide for atomic storage of pipeline products for a unit of work across a relational database and the custom Kepler DB. Generic parameter management and data accountability services are provided to record the parameter values, software versions, and other meta-data used for each pipeline execution. A graphical console allows for the configuration, execution, and monitoring of pipelines. An alert and metrics subsystem is used to monitor the health and performance of the pipeline. The framework was developed for the Kepler project based on Kepler requirements, but the framework itself is generic and could be used for a variety of applications where these features are needed.

Klaus, Todd C.↗

Component-Level Electronic-Assembly Repair (CLEAR) Synthetic Instrument Capabilities Assessment and Test Report

The role of synthetic instruments (SIs) for Component-Level Electronic-Assembly Repair (CLEAR) is to provide an external lower-level diagnostic and functional test capability beyond the built-in-test capabilities of spacecraft electronics. Built-in diagnostics can report faults and symptoms, but isolating the root cause and performing corrective action requires specialized instruments. Often a fault can be revealed by emulating the operation of external hardware. This implies complex hardware that is too massive to be accommodated in spacecraft. The SI strategy is aimed at minimizing complexity and mass by employing highly reconfigurable instruments that perform diagnostics and emulate external functions. In effect, SI can synthesize an instrument on demand. The SI architecture section of this document summarizes the result of a recent program diagnostic and test needs assessment based on the International Space Station. The SI architecture addresses operational issues such as minimizing crew time and crew skill level, and the SI data transactions between the crew and supporting ground engineering searching for the root cause and formulating corrective actions. SI technology is described within a teleoperations framework. The remaining sections describe a lab demonstration intended to show that a single SI circuit could synthesize an instrument in hardware and subsequently clear the hardware and synthesize a completely different instrument on demand. An analysis of the capabilities and limitations of commercially available SI hardware and programming tools is included. Future work in SI technology is also described.

Oeftering, Richard C.↗

Improving UDP/IP Transmission Without Increasing Congestion

Datagram Retransmission (DGR) is a computer program that, within certain limits, ensures the reception of each datagram transmitted under the User Datagram Protocol/Internet Protocol. [User Datagram Protocol (UDP) is considered unreliable because it does not involve a reliability-ensuring connection-initiation dialogue between sender and receiver. UDP is well suited to issuing of many small messages to many different receivers.] Unlike prior software for ensuring reception of UDP datagrams, DGR does not contribute to network congestion by retransmitting data more frequently as an ever-increasing number of messages and acknowledgements is lost. Instead, DGR does just the opposite: DGR includes an adaptive timeout-interval- computing component that provides maximum opportunity for reception of acknowledgements, minimizing retransmission. By monitoring changes in the rate at which message-transmission transactions are completed, DGR detects changes in the level of congestion and responds by imposing varying degrees of delay on the transmission of new messages. In addition, DGR maximizes throughput by not waiting for acknowledgement of a message before sending the next message. All DGR communication is asynchronous, to maximize efficient utilization of network connections. DGR manages multiple concurrent datagram transmission and acknowledgement conversations.

Burleigh, Scott↗

Identifying Objects via Encased X-Ray-Fluorescent Materials - the Bar Code Inside

Systems for identifying objects by means of x-ray fluorescence (XRF) of encased labeling elements have been developed. The XRF spectra of objects so labeled would be analogous to the external bar code labels now used to track objects in everyday commerce. In conjunction with computer-based tracking systems, databases, and labeling conventions, the XRF labels could be used in essentially the same manner as that of bar codes to track inventories and to record and process commercial transactions. In addition, as summarized briefly below, embedded XRF labels could be used to verify the authenticity of products, thereby helping to deter counterfeiting and fraud. A system, as described above, is called an encased core product identification and authentication system (ECPIAS). The ECPIAS concept is a modified version of that of a related recently initiated commercial development of handheld XRF spectral scanners that would identify alloys or detect labeling elements deposited on the surfaces of objects. In contrast, an ECPIAS would utilize labeling elements encased within the objects of interest. The basic ECPIAS concept is best illustrated by means of an example of one of several potential applications: labeling of cultured pearls by labeling the seed particles implanted in oysters to grow the pearls. Each pearl farmer would be assigned a unique mixture of labeling elements that could be distinguished from the corresponding mixtures of other farmers. The mixture would be either incorporated into or applied to the surfaces of the seed prior to implantation in the oyster. If necessary, the labeled seed would be further coated to make it nontoxic to the oyster. After implantation, the growth of layers of mother of pearl on the seed would encase the XRF labels, making these labels integral, permanent parts of the pearls that could not be removed without destroying the pearls themselves. The XRF labels would be read by use of XRF scanners, the spectral data outputs of which would be converted to alphanumeric data in a digital equivalent data system (DEDS), which is the subject of the previous article. These alphanumeric data would be used to track the pearls through all stages of commerce, from the farmer to the retail customer.

Schramm, Harry F.↗

Highly Reliable, High-Speed, Unidirectional Serial Data Links

Highly reliable, high-speed, unidirectional serial data-communication subsystems have been proposed to be installed in an upgrade of the computing systems aboard the space shuttles. The basic design concept of these serial data links is also adaptable to terrestrial use in applications in which there are requirements for highly reliable serial data communications. The hardware and software aspects of the architecture of the data links are dictated largely by a requirement, in the original space-shuttle application, for one computer to monitor the memory transactions and memory contents of other computers in real time with high reliability and without reliance on requests for retransmission. To minimize weight while affording a capability to transfer data at a required rate of 2.56 x 10(exp 8) bits per second, it was decided that the links would be serial ones of the fiber-channel type. [Fiber channel denotes a type of serial computer bus that is used to connect a computer (usually a supercomputer) with a high-speed data storage device. Depending on the specific application, the physical connection between the transmitter and receiver could be made via an optical fiber or a twisted pair of wires.] Heretofore, fiber-channel links have ordinarily been bidirectional and have operated under protocols that provide for receiving stations to detect errors and request retransmission when necessary. In the present case, the time taken by processing to request retransmission would conflict with the requirement for real-time transfer of data. To ensure reliability without retransmission, a link according to the proposal would utilize a modified version of the normal fiberchannel character set in conjunction with forward error correction by means of a Reed-Solomon code (see figure). The Reed-Solomon encoding and decoding and the translations between the normal and modified character sets would be effected by logic circuitry external to the fiber-channel transmitter and receiver, which would be commercial off-the-shelf units. The receiving end of the link could detect and correct errors at a rate as high as 4 million times per second, if necessary. The receiver detects uncorrectable double-byte errors. It has been estimated that uncorrectable-error rate would amount to one failure in about 10(exp 19) characters.

Cole, Robert M.↗

Hardware for Accelerating N-Modular Redundant Systems for High-Reliability Computing

A hardware unit has been designed that reduces the cost, in terms of performance and power consumption, for implementing N-modular redundancy (NMR) in a multiprocessor device. The innovation monitors transactions to memory, and calculates a form of sumcheck on-the-fly, thereby relieving the processors of calculating the sumcheck in software

Dobbs, Carl, Sr.↗

Mars Express Forward Link Capabilities for the Mars Relay Operations Service (MaROS)

This software provides a new capability for landed Mars assets to perform forward link relay through the Mars Express (MEX) European Union orbital spacecraft. It solves the problem of standardizing the relay interface between lander missions and MEX. The Mars Operations Relay Service (MaROS) is intended as a central point for relay planning and post-pass analysis for all Mars landed and orbital assets. Through the first two phases of implementation, MaROS supports relay coordination through the Odyssey orbiter and the Mars Reconnaissance Orbiter (MRO). With this new software, MaROS now fully integrates the Mars Express spacecraft into the relay picture. This new software generates and manages a new set of file formats that allows for relay request to MEX for forward and return link relay, including the parameters specific to MEX. Existing MEX relay planning interactions were performed via email exchanges and point-to-point file transfers. By integrating MEX into MaROS, all transactions are managed by a centralized service for tracking and analysis. Additionally, all lander missions have a single, shared interface with MEX and do not have to integrate on a mission-by mission basis. Relay is a critical element of Mars lander data management. Landed assets depend largely upon orbital relay for data delivery, which can be impacted by the availability and health of each orbiter in the network. At any time, an issue may occur to prevent relay. For this reason, it is imperative that all possible orbital assets be integrated into the overall relay picture.

Allard, Daniel A.↗

Revamping Spacecraft Operational Intelligence with Splunk

So what is Splunk? Instead of giving the technical details, which you can find online, I'll tell you what it did for me. Splunk slapped everything into one place, with one uniform format, and gave me the ability to forget about all these annoying details of where it is, how to parse it, and all that. Instead, I only need to interact with Splunk to find the data I need. This sounds simple and obvious, but it's surprising what you can do once you all of your data is indexed in one place. By having your data organized, querying becomes much easier. Let's say that I want to search telemetry for a sensor_name gtemp_1 h and to return all data that is at most five minutes old. And because Splunk can hook into a real ]time stream, this data will always be up-to-date. Extending the previous example, I can now aggregate all types of data into one view based in time. In this picture, I've got transaction logs, telemetry, and downlinked files all in one page, organized by time. Even though the raw data looks completely than this, I've defined interfaces that transform it into this uniform format. This gives me a more complete picture for the question what was the spacecraft doing at this particular time? And because querying data is simple, I can start with a big block of data and whiddle it down to what I need, rather than hunting around for the individual pieces of data that I need. When we have all the data we need, we can begin widdling down the data with Splunk's Unix-like search syntax. These three examples highlights my trial-and-error attempts to find large temperature changes. I begin by showing the first 5 temperatures, only to find that they're sorted chronologically, rather than from highest temperatures to lowest temperatures. The next line shows sorting temperatures by their values, but I find that that fs not really what I want either. I want to know the delta temperatures between readings. Looking through Splunk's user manual, I find the delta function, which lets me dynamically generate new information to use in my query. With that extra piece of information, I can now return only the telemetry readings where the temperature changed by at least 10. One other useful feature I'll mention is that all of these queries can be run through Splunk's API. So any scripting language you can think of can plug right in and make these queries. This gives us the ability to build a lot of new tools.

operational intelligence↗

Relay Forward-Link File Management Services (MaROS Phase 2)

This software provides the service-level functionality to manage the delivery of files from a lander mission repository to an orbiter mission repository for eventual spacelink relay by the orbiter asset on a specific communications pass. It provides further functions to deliver and track a set of mission-defined messages detailing lander authorization instructions and orbiter data delivery state. All of the information concerning these transactions is persisted in a database providing a high level of accountability of the forward-link relay process.

Allard, Daniel A.↗

An Offload NIC for NASA, NLR, and Grid Computing

This work addresses distributed data management and access dynamically configurable high-speed access to data distributed and shared over wide-area high-speed network environments. An offload engine NIC (network interface card) is proposed that scales at nX10-Gbps increments through 100-Gbps full duplex. The Globus de facto standard was used in projects requiring secure, robust, high-speed bulk data transport. Novel extension mechanisms were derived that will combine these technologies for use by GridFTP, bandwidth management resources, and host CPU (central processing unit) acceleration. The result will be wire-rate encrypted Globus grid data transactions through offload for splintering, encryption, and compression. As the need for greater network bandwidth increases, there is an inherent need for faster CPUs. The best way to accelerate CPUs is through a network acceleration engine. Grid computing data transfers for the Globus tool set did not have wire-rate encryption or compression. Existing technology cannot keep pace with the greater bandwidths of backplane and network connections. Present offload engines with ports to Ethernet are 32 to 40 Gbps f-d at best. The best of ultra-high-speed offload engines use expensive ASICs (application specific integrated circuits) or NPUs (network processing units). The present state of the art also includes bonding and the use of multiple NICs that are also in the planning stages for future portability to ASICs and software to accommodate data rates at 100 Gbps. The remaining industry solutions are for carrier-grade equipment manufacturers, with costly line cards having multiples of 10-Gbps ports, or 100-Gbps ports such as CFP modules that interface to costly ASICs and related circuitry. All of the existing solutions vary in configuration based on requirements of the host, motherboard, or carriergrade equipment. The purpose of the innovation is to eliminate data bottlenecks within cluster, grid, and cloud computing systems, and to add several more capabilities while reducing space consumption and cost. Provisions were designed for interoperability with systems used in the NASA HEC (High-End Computing) program. The new acceleration engine consists of state-ofthe- art FPGA (field-programmable gate array) core IP, C, and Verilog code; novel communication protocol; and extensions to the Globus structure. The engine provides the functions of network acceleration, encryption, compression, packet-ordering, and security added to Globus grid or for cloud data transfer. This system is scalable in nX10-Gbps increments through 100-Gbps f-d. It can be interfaced to industry-standard system-side or network-side devices or core IP in increments of 10 GigE, scaling to provide IEEE 40/100 GigE compliance.

Awrach, James↗

Countermeasures and Functional Testing in Head-Down Tilt Bed Rest (CFT 70)

This 70‐day bed rest campaign was comprised of 6 integrated studies and conducted at the NASA Flight Analogs Research Unit (FARU). The FARU is located at the University of Texas Medical Branch, Galveston, Texas and is a satellite unit of the Institute for Translational Sciences - Clinical Research Center. This presentation will describe the FARU, discuss the utility of the bed rest platform for use in these studies, and introduce the studies that participated in the CFT 70 bed rest campaign. Information in this presentation will serve as the background for subsequent talks from each individual study. Individual study presentations will discuss preliminary results from completed subjects. Studies included in CFT70 were:  Physiological Factors Contributing to Post Flight Changes in Functional Performance. J. Bloomberg, NASA  Integrated Resistance and Aerobic Training Study. L. Ploutz‐Snyder, USRA  Testosterone Supplementation as a Countermeasure Against Musculoskeletal losses during Space Exploration. R. Urban, University of Texas Medical Branch  Effects of Retronasal Smelling, Variety and Choice on Appetite & Satiety. J. Hunter, Cornell University  AD ASTRA: Automated Detection of Attitudes and States through Transaction Recordings Analysis. C. Miller, Smart Information Flow Technologies, LLC  Bed Rest as a Spaceflight Analog to Study Neuro‐cognitive Changes: Extent, Longevity, and Neural Bases. R. Seidler, University of Michigan

Cromwell, Ronita L.↗

Modeling Inflation Using a Non-Equilibrium Equation of Exchange

Inflation is a change in the prices of goods that takes place without changes in the actual values of those goods. The Equation of Exchange, formulated clearly in a seminal paper by Irving Fisher in 1911, establishes an equilibrium relationship between the price index P (also known as "inflation"), the economy's aggregate output Q (also known as "the real gross domestic product"), the amount of money available for spending M (also known as "the money supply"), and the rate at which money is reused V (also known as "the velocity of circulation of money"). This paper offers first a qualitative discussion of what can cause these factors to change and how those causes might be controlled, then develops a quantitative model of inflation based on a non-equilibrium version of the Equation of Exchange. Causal relationships are different from equations in that the effects of changes in the causal variables take time to play out-often significant amounts of time. In the model described here, wages track prices, but only after a distributed lag. Prices change whenever the money supply, aggregate output, or the velocity of circulation of money change, but only after a distributed lag. Similarly, the money supply depends on the supplies of domestic and foreign money, which depend on the monetary base and a variety of foreign transactions, respectively. The spreading of delays mitigates the shocks of sudden changes to important inputs, but the most important aspect of this model is that delays, which often have dramatic consequences in dynamic systems, are explicitly incorporated.macroeconomics, inflation, equation of exchange, non-equilibrium, Athena Project

Chamberlain, Robert G.↗

The Fleet Application for Scheduling and Tracking (FAST) Management Website

The FAST application was designed to replace the paper and pen method of checking out and checking in GSA Vehicles at KSC. By innovating from a paper and pen based checkout system to a fully digital one, not only the resources wasted by printing the checkout forms have been reduced, but it also reduces significantly the time that users and fleet managers need to interact with the system as well as improving the record accuracy for each vehicle. The vehicle information is pulled from a centralized database server in the SPSDL. In an attempt to add a new feature to the FAST application, the author of this report (alongside the FAST developers) has been designing and developing the FAST Management Website. The GSA fleet managers had to rely on the FAST developers in order to add new vehicles, edit vehicles and previous transactions, or for generating vehicles reports. By providing an easy-to-use FAST Management Website portal, the GSA fleet managers are now able to easily move vehicles, edit records, and print reports.

Object-Oriented Programming↗