Search NASA⌕ Search

SEARCH · Search NASA

Results for “dispatch”

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 415 records · Page 23
All sourcesNASA NTRSDOE OSTI
NASA NTRS2007

Comprehensive Software Eases Air Traffic Management

To help air traffic control centers improve the safety and the efficiency of the National Airspace System, Ames Research Center developed the Future Air Traffic Management Concepts Evaluation Tool (FACET) software, which won NASA's 2006 "Software of the Year" competition. In 2005, Ames licensed FACET to Flight Explorer Inc., for integration into its Flight Explorer (version 6.0) software. The primary FACET features incorporated in the Flight Explorer software system alert airspace users to forecasted demand and capacity imbalances. Advance access to this information helps dispatchers anticipate congested sectors (airspace) and delays at airports, and decide if they need to reroute flights. FACET is now a fully integrated feature in the Flight Explorer Professional Edition (version 7.0). Flight Explorer Professional offers end-users other benefits, including ease of operation; automatic alerts to inform users of important events such as weather conditions and potential airport delays; and international, real-time flight coverage over Canada, the United Kingdom, New Zealand, and sections of the Atlantic and Pacific Oceans. Flight Explorer Inc. recently broadened coverage by partnering with Honeywell International Inc.'s Global Data Center, Blue Sky Network, Sky Connect LLC, SITA, ARINC Incorporated, Latitude Technologies Corporation, and Wingspeed Corporation, to track their aircraft anywhere in the world.

Source record↗
NASA NTRS2005

Emergency vehicle traffic signal preemption system

An emergency vehicle traffic light preemption system for preemption of traffic lights at an intersection to allow safe passage of emergency vehicles. The system includes a real-time status monitor of an intersection which is relayed to a communications controller for transmission to emergency vehicles as well as to a central dispatch office. The system also provides for audio warnings at an intersection to protect pedestrians who may not be in a position to see visual warnings or for various reasons cannot hear the approach of emergency vehicles. A transponder mounted on an emergency vehicle provides autonomous control so the vehicle operator can attend to getting to an emergency and not be concerned with the operation of the system. Activation of a Code 3 situation provides communications with each intersection being approached by an emergency vehicle and indicates whether the intersection is preempted or if there is any conflict with other approaching emergency vehicles. On-board diagnostics handle various information including heading, speed, and acceleration sent to a communications controller which is transmitted to an intersection and which also simultaneously receives information regarding the status of an intersection.

Bachelder, Aaron D.↗
NASA NTRS2008

RSRM Segment Train Derailment and Recovery

On May 2, 2007, a freight train carrying segments of the space shuttle's solid rocket boosters derailed in Myrtlewood, Alabama, after a rail trestle collapsed. The train was carrying Reusable Solid Rocket Motors (RSRM) 98 center and forward segments (STS-120) and RSRM 99 aft segments (STS-122). Initially, it was not known if the segments had been seriously damaged. Four segments dropped approximately 10 feet when the trestle collapsed and one of those four rolled off the track onto its side. The exit cones and the other four segments, not yet on the trestle, remained on solid ground. ATK and NASA immediately dispatched an investigation and recovery team to determine the safety of the situation and eventually the usability of the segments and exit cones for flight. Instrumentation on each segment provided invaluable data to determine the acceleration loads imparted into each loaded segment and exit cone. This paper details the incident, recovery plan and the team work that created a success story that ended with the safe launch of STS120 using the four center segments and the launch of STS122 using the Aft exit cones assemblies.

Taylor Jr., Robert H.↗
NASA NTRS2008

Storm Surge Measurement with an Airborne Scanning Radar Altimeter

Over the years, hurricane track and intensity forecasts and storm surge models and the digital terrain and bathymetry data they depend on have improved significantly. Strides have also been made in knowledge of the detailed variation of the surface wind field driving the surge. The area of least improvement has been in obtaining data on the details of the temporal/spatial variation of the storm surge dome of water as it evolves and inundates the land to evaluate the performance of the numerical models. Tide gages in the vicinity of the landfall are frequently destroyed by the surge. Survey crews dispatched after the event provide no temporal information and only indirect indications of the maximum surge envelope over land. The landfall of Hurricane Bonnie on 26 August 1998, with a surge less than 2 m, provided an excellent opportunity to demonstrate the potential benefits of direct airborne measurement of the temporal/spatial evolution of storm surge. Despite a 160 m variation in aircraft altitude, an 11.5 m variation in the elevation of the mean sea surface relative to the ellipsoid over the flight track, and the tidal variation over the 5 hour data acquisition interval, a survey-quality Global Positioning System (GPS) aircraft trajectory allowed the NASA Scanning Radar Altimeter carried by a NOAA hurricane research aircraft to produce storm surge measurements that generally fell between the predictions of the NOAA SLOSH model and the North Carolina State University storm surge model.

Wright, C. W.↗
NASA NTRS2008

PyPele Rewritten To Use MPI

A computer program known as PyPele, originally written as a Pythonlanguage extension module of a C++ language program, has been rewritten in pure Python language. The original version of PyPele dispatches and coordinates parallel-processing tasks on cluster computers and provides a conceptual framework for spacecraft-mission- design and -analysis software tools to run in an embarrassingly parallel mode. The original version of PyPele uses SSH (Secure Shell a set of standards and an associated network protocol for establishing a secure channel between a local and a remote computer) to coordinate parallel processing. Instead of SSH, the present Python version of PyPele uses Message Passing Interface (MPI) [an unofficial de-facto standard language-independent application programming interface for message- passing on a parallel computer] while keeping the same user interface. The use of MPI instead of SSH and the preservation of the original PyPele user interface make it possible for parallel application programs written previously for the original version of PyPele to run on MPI-based cluster computers. As a result, engineers using the previously written application programs can take advantage of embarrassing parallelism without need to rewrite those programs.

Hockney, George↗
NASA NTRS2009

OTF Proof of Concept: CCSDS Mission Operations Alert Services

Conclusions: Use of multiple vendor frameworks within a component creates thread lockups and fragility conflicts over the control of the main thread. Avoid closed vendor messaging frameworks. The MAL layer does isolate the data elements from the messaging framework but application work dispatch is heavily dominated by the framework chosen. API Language is a major factor in implementation. Message APIs with timeouts seem unavoidable in some environments (GUI). Language environment needs to support callbacks (or threads) from the messaging framework to deal with pub/sub management messages and status. Statusing of application communications demand a local broker agent per physical system or else the use of the AMSstyle registrar heartbeat.

Reynolds, Walt↗
NASA NTRS2008

An Enhanced Convective Forecast (ECF) for the New York TRACON Area

In an effort to relieve summer-time congestion in the NY Terminal Radar Approach Control (TRACON) area, the FAA is testing an enhanced convective forecast (ECF) product. The test began in June 2008 and is scheduled to run through early September. The ECF is updated every two hours, right before the Air Traffic Control System Command Center (ATCSCC) national planning telcon. It is intended to be used by traffic managers throughout the National Airspace System (NAS) and airlines dispatchers to supplement information from the Collaborative Convective Forecast Product (CCFP) and the Corridor Integrated Weather System (CIWS). The ECF begins where the current CIWS forecast ends at 2 hours and extends out to 12 hours. Unlike the CCFP it is a detailed deterministic forecast with no aerial coverage limits. It is created by an ENSCO forecaster using a variety of guidance products including, the Weather Research and Forecast (WRF) model. This is the same version of the WRF that ENSCO runs over the Florida peninsula in support of launch operations at the Kennedy Space Center. For this project, the WRF model domain has been shifted to the Northeastern US. Several products from the NASA SPoRT group are also used by the ENSCO forecaster. In this paper we will provide examples of the ECF products and discuss individual cases of traffic management actions using ECF guidance.

Wheeler, Mark↗
NASA NTRS2009

Perl Modules for Constructing Iterators

The Iterator Perl Module provides a general-purpose framework for constructing iterator objects within Perl, and a standard API for interacting with those objects. Iterators are an object-oriented design pattern where a description of a series of values is used in a constructor. Subsequent queries can request values in that series. These Perl modules build on the standard Iterator framework and provide iterators for some other types of values. Iterator::DateTime constructs iterators from DateTime objects or Date::Parse descriptions and ICal/RFC 2445 style re-currence descriptions. It supports a variety of input parameters, including a start to the sequence, an end to the sequence, an Ical/RFC 2445 recurrence describing the frequency of the values in the series, and a format description that can refine the presentation manner of the DateTime. Iterator::String constructs iterators from string representations. This module is useful in contexts where the API consists of supplying a string and getting back an iterator where the specific iteration desired is opaque to the caller. It is of particular value to the Iterator::Hash module which provides nested iterations. Iterator::Hash constructs iterators from Perl hashes that can include multiple iterators. The constructed iterators will return all the permutations of the iterations of the hash by nested iteration of embedded iterators. A hash simply includes a set of keys mapped to values. It is a very common data structure used throughout Perl programming. The Iterator:: Hash module allows a hash to include strings defining iterators (parsed and dispatched with Iterator::String) that are used to construct an overall series of hash values.

Tilmes, Curt↗
NASA NTRS2009

Progress Towards the Remote Sensing of Aircraft Icing Hazards

NASA has teamed with the FAA, DoD, industry, and academia for research into the remote detection and measurement of atmospheric conditions leading to aircraft icing hazards. The ultimate goal of this effort is to provide pilots, controllers, and dispatchers sufficient information to allow aircraft to avoid or minimize their exposure to the hazards of in-flight icing. Since the hazard of in-flight icing is the outcome of aircraft flight through clouds containing supercooled liquid water and strongly influenced by the aircraft s speed and configuration and by the length of exposure, the hazard cannot be directly detected, but must be inferred based upon the measurement of conducive atmospheric conditions. Therefore, icing hazard detection is accomplished through the detection and measurement of liquid water in regions of measured sub-freezing air temperatures. The icing environment is currently remotely measured from the ground with a system fusing radar, lidar, and multifrequency microwave radiometer sensors. Based upon expected ice accretion severity for the measured environment, a resultant aircraft hazard is then calculated. Because of the power, size, weight, and view angle constraints of airborne platforms, the current ground-based solution is not applicable for flight. Two current airborne concepts are based upon the use of either multifrequency radiometers or multifrequency radar. Both ground-based and airborne solutions are required for the future since groundbased systems can provide hazard detection for all aircraft in airport terminal regions while airborne systems will be needed to provide equipped aircraft with flight path coverage between terminal regions.

Reehorst, Andrew↗
NASA NTRS2007

PPC750 Performance Monitor

The PPC750 Performance Monitor (Perfmon) is a computer program that helps the user to assess the performance characteristics of application programs running under the Wind River VxWorks real-time operating system on a PPC750 computer. Perfmon generates a user-friendly interface and collects performance data by use of performance registers provided by the PPC750 architecture. It processes and presents run-time statistics on a per-task basis over a repeating time interval (typically, several seconds or minutes) specified by the user. When the Perfmon software module is loaded with the user s software modules, it is available for use through Perfmon commands, without any modification of the user s code and at negligible performance penalty. Per-task run-time performance data made available by Perfmon include percentage time, number of instructions executed per unit time, dispatch ratio, stack high water mark, and level-1 instruction and data cache miss rates. The performance data are written to a file specified by the user or to the serial port of the computer

Meyer, Donald↗
NASA NTRS2002

Shuttle Abort Flight Management (SAFM) - Application Overview

One of the most demanding tasks that must be performed by the Space Shuttle flight crew is the process of determining whether, when and where to abort the vehicle should engine or system failures occur during ascent or entry. Current Shuttle abort procedures involve paging through complicated paper checklists to decide on the type of abort and where to abort. Additional checklists then lead the crew through a series of actions to execute the desired abort. This process is even more difficult and time consuming in the absence of ground communications since the ground flight controllers have the analysis tools and information that is currently not available in the Shuttle cockpit. Crew workload specifically abort procedures will be greatly simplified with the implementation of the Space Shuttle Cockpit Avionics Upgrade (CAU) project. The intent of CAU is to maximize crew situational awareness and reduce flight workload thru enhanced controls and displays, and onboard abort assessment and determination capability. SAFM was developed to help satisfy the CAU objectives by providing the crew with dynamic information about the capability of the vehicle to perform a variety of abort options during ascent and entry. This paper- presents an overview of the SAFM application. As shown in Figure 1, SAFM processes the vehicle navigation state and other guidance information to provide the CAU displays with evaluations of abort options, as well as landing site recommendations. This is accomplished by three main SAFM components: the Sequencer Executive, the Powered Flight Function, and the Glided Flight Function, The Sequencer Executive dispatches the Powered and Glided Flight Functions to evaluate the vehicle's capability to execute the current mission (or current abort), as well as more than IS hypothetical abort options or scenarios. Scenarios are sequenced and evaluated throughout powered and glided flight. Abort scenarios evaluated include Abort to Orbit (ATO), Transatlantic Abort Landing (TAL), East Coast Abort Landing (ECAL) and Return to Launch Site (RTLS). Sequential and simultaneous engine failures are assessed and landing footprint information is provided during actual entry scenarios as well as hypothetical "loss of thrust now" scenarios during ascent.

Hu, Howard↗
NASA NTRS2011

Emergency vehicle traffic signal preemption system

An emergency vehicle traffic light preemption system for preemption of traffic lights at an intersection to allow safe passage of emergency vehicles. The system includes a real-time status monitor of an intersection which is relayed to a control module for transmission to emergency vehicles as well as to a central dispatch office. The system also provides for audio warnings at an intersection to protect pedestrians who may not be in a position to see visual warnings or for various reasons cannot hear the approach of emergency vehicles. A transponder mounted on an emergency vehicle provides autonomous control so the vehicle operator can attend to getting to an emergency and not be concerned with the operation of the system. Activation of a priority-code (i.e. Code-3) situation provides communications with each intersection being approached by an emergency vehicle and indicates whether the intersection is preempted or if there is any conflict with other approaching emergency vehicles. On-board diagnostics handle various information including heading, speed, and acceleration sent to a control module which is transmitted to an intersection and which also simultaneously receives information regarding the status of an intersection. Real-time communications and operations software allow central and remote monitoring, logging, and command of intersections and vehicles.

Bachelder, Aaron D.↗
NASA NTRS2002

Onboard Determination of Vehicle Glide Capability for Shuttle Abort Flight Managment (SAFM)

When one or more main engines fail during ascent, the flight crew of the Space Shuttle must make several critical decisions and accurately perform a series of abort procedures. One of the most important decisions for many aborts is the selection ofa landing site. Several factors influence the ability to reach a landing site, including the spacecraft point of atmospheric entry, the energy state at atmospheric entry, the vehicle glide capability from that energy state, and whether one or more suitable landing sites are within the glide capability. Energy assessment is further complicated by the fact that phugoid oscillations in total energy influence glide capability. Once the glide capability is known, the crew must select the "best" site option based upon glide capability and landing site conditions and facilities. Since most of these factors cannot currently be assessed by the crew in flight, extensive planning is required prior to each mission to script a variety of procedures based upon spacecraft velocity at the point of engine failure (or failures). The results of this preflight planning are expressed in tables and diagrams on mission-specific cockpit checklists. Crew checklist procedures involve leafing through several pages of instructions and navigating a decision tree for site selection and flight procedures - all during a time critical abort situation. With the advent of the Cockpit Avionics Upgrade (CAU), the Shuttle will have increased on-board computational power to help alleviate crew workload during aborts and provide valuable situational awareness during nominal operations. One application baselined for the CAU computers is Shuttle Abort Flight Management (SAFM), whose requirements have been designed and prototyped. The SAFM application includes powered and glided flight algorithms. This paper describes the glided flight algorithm which is dispatched by SAFM to determine the vehicle glide capability and make recommendations to the crew for site selection as well as to monitor glide capability while in route to the selected site. Background is provided on Shuttle entry guidance as well as the various types of Shuttle aborts. SAFM entry requirements and cockpit disp lays are discussed briefly to provide background for Glided Flight algorithm design considerations. The central principal of the Glided Flight algorithm is the use of energy-over-weight (EOW) curves to determine range and crossrange boundaries. The major challenges of this technique are exo-atmospheric flight, and phugoid oscillations in energy. During exo-atmospheric flight, energy is constant, so vehicle EOW is not sufficient to determine glide capability. The paper describes how the exo-atmospheric problem is solved by propagating the vehicle state to an "atmospheric pullout" state defined by Shuttle guidance parameters.

Straube, Timothy↗
NASA NTRS2009

Jet Propulsion Laboratory: Annual Report 2008

Nothing is more exciting than when science mines the far end of our knowledge for the new and the unexpected. In 2008, the world was taken by surprise when JPL astronomers announced the discovery of organic compounds on a planet orbiting another star. We were equally excited to learn from the Spitzer Space Telescope that many, if not most, sun-like stars have rocky planets roughly similar to Earth. Together these are very intriguing clues in our quest to learn if there is life elsewhere in the universe, which certainly has to be one of the most profound mysteries of our age.There are times when, dealing with unknowns, we are reminded to be humble. Very impressive progress is being made by the team developing our next flagship mission, Mars Science Laboratory. Ther conclusion, however, is that it would not be safe to try to fly during the Mars launch window in 2009, and reset for the next opportunity in 2011. We are lucky to have valuable assets that support us as we venture into the unknown. One is the global Deep Space Network, which functions both as our communication gateway to our spacecraft across the solar system as well as a research tool itself in conducting radar astronomy. Our successes depend on our entire team, administrators and business specialists as much as technical people. There are those who help share our missions with the public, finding imaginative venues such as sending out dispatches on the Internet's Twitter.com during the Phoenix mission. We also benefit greatly from the intellectual infusion that comes from our unique identity as a division of the California Institute of Technology and a member of the NASA family.

National Aeronautics and Space Administration (NAS↗
NASA NTRS2005

Decision Support for Emergency Operations Centers

The Flood Disaster Mitigation Decision Support System (DSS) is a computerized information system that allows regional emergency-operations government officials to make decisions regarding the dispatch of resources in response to flooding. The DSS implements a real-time model of inundation utilizing recently acquired lidar elevation data as well as real-time data from flood gauges, and other instruments within and upstream of an area that is or could become flooded. The DSS information is updated as new data become available. The model generates realtime maps of flooded areas and predicts flood crests at specified locations. The inundation maps are overlaid with information on population densities, property values, hazardous materials, evacuation routes, official contact information, and other information needed for emergency response. The program maintains a database and a Web portal through which real-time data from instrumentation are gathered into the database. Also included in the database is a geographic information system, from which the program obtains the overlay data for areas of interest as needed. The portal makes some portions of the database accessible to the public. Access to other portions of the database is restricted to government officials according to various levels of authorization. The Flood Disaster Mitigation DSS has been integrated into a larger DSS named REACT (Real-time Emergency Action Coordination Tool), which also provides emergency operations managers with data for any type of impact area such as floods, fires, bomb

Harvey, Craig↗
NASA NTRS2011

A Human Factors Approach to Bridging Systems and Introducing New Technologies

The application of human factors in aviation has grown to cover a wide range of disciplines and methods capable of assessing human-systems integration at many levels. For example, at the individual level, pilot workload may be studied while at the team level, coordinated workload distribution may be the focal point. At the organizational level, the way in which individuals and teams are supported by training and standards, policies and procedures may introduce additional, relevant topics. A consideration of human factors at each level contributes to our understanding of successes and failures in pilot performance, but this system focused on the flight deck alone -- is only one part of the airspace system. In the FAA's NextGen plan to overhaul the National Airspace System (NAS), new capabilities will enhance flightdeck systems (pilots), flight operations centers (dispatchers) and air traffic control systems (controllers and air traffic managers). At a minimum, the current roles and responsibilities of these three systems are likely to change. Since increased automation will be central to many of the enhancements, the role of automation is also likely to change. Using NextGen examples, a human factors approach for bridging complex airspace systems will be the main focus of this presentation. It is still crucial to consider the human factors within each system, but the successful implementation of new technologies in the NAS requires an understanding of the collaborations that occur when these systems intersect. This human factors approach to studying collaborative systems begins with detailed task descriptions within each system to establish a baseline of the current operations. The collaborative content and context are delineated through the review of regulatory and advisory materials, letters of agreement, policies, procedures and documented practices. Field observations and interviews also help to fill out the picture. Key collaborative functions across systems are identified and placed on a phase-of-flight timeline including information requirements, decision authority and use of automation, as well as level of frequency and criticality.

Kanki, Barbara G.↗
NASA NTRS2011

Tools for Designing, Evaluating, and Certifying NextGen Technologies and Procedures: Automation Roles and Responsibilities

Barbara Kanki from NASA Ames Research Center will discuss research that focuses on the collaborations between pilots, air traffic controllers and dispatchers that will change in NextGen systems as automation increases and roles and responsibilities change. The approach taken by this NASA Ames team is to build a collaborative systems assessment template (CSAT) based on detailed task descriptions within each system to establish a baseline of the current operations. The collaborative content and context are delineated through the review of regulatory and advisory materials, policies, procedures and documented practices as augmented by field observations and interviews. The CSAT is developed to aid the assessment of key human factors and performance tradeoffs that result from considering different collaborative arrangements under NextGen system changes. In theory, the CSAT product may be applied to any NextGen application (such as Trajectory Based Operations) with specified ground and aircraft capabilities.

Kanki, Barbara G.↗
NASA NTRS2013

Embedding Temporal Constraints For Coordinated Execution in Habitat Automation

Future NASA plans call for long-duration deep space missions with human crews. Because of light-time delay and other considerations, increased autonomy will be needed. This will necessitate integration of tools in such areas as anomaly detection, diagnosis, planning, and execution. In this paper we investigate an approach that integrates planning and execution by embedding planner-derived temporal constraints in an execution procedure. To avoid the need for propagation, we convert the temporal constraints to dispatchable form. We handle some uncertainty in the durations without it affecting the execution; larger variations may cause activities to be skipped.

Morris, Paul↗