Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “traffic volume”

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.

280 records · Page 16

Pilot Evaluation of a UAS Detect-and-Avoid System's Effectiveness in Remaining Well Clear

Unmanned aircraft will equip with a detect-and-avoid (DAA) system that allows them to comply with the requirement to see and avoid other aircraft, an important layer in the overall set of procedural, strategic and tactical separation methods designed to prevent mid-air collisions. Although the effectiveness of the DAA system will be set to a minimum threshold by regulators, different combinations of algorithms, displays and procedures could be used to meet that minimum. The research presented in this paper indicates the effectiveness of the combined pilot-DAA system as a function of the DAA design requirements and provides data that may be used to model the behavior of pilots when employing such systems. Over the course of two simulations 21 professional UAS pilots evaluated eight different DAA system designs and metrics were collected on their ability to maintain the well clear separation standard. The independent variables were the time horizon at which pilots were alerted to potential losses of well clear, the location of the traffic display, and the tools and informational elements available on the display to aid the pilot in detecting and resolving those potential losses. In the second experiment the UAS encountered two categories of aircraft: those equipped with simulated transponders that could be seen dozens of miles away and those without that were only detectable by a simulated radar within a range of six nautical miles. The data indicate that integrating the traffic display with the primary mission map directly in front of the pilot reduced the frequency of losses of well clear. Improved detection and resolution tools, including explicit maneuver guidance and a trial planning capability, had less of an effect in reducing the frequency of losses but significantly reduced the time in loss when they occurred. The amount of warning time provided to the pilot had a strong effect on their ability to remain well clear: when alerts were first presented with less than about 15 seconds to a predicted loss of well clear pilots were able to maneuver successfully in only 26 percent of encounters, whereas they were about 83 percent successful when they had more than 15 seconds. Pilots' ability to separate from the two categories of aircraft was nearly the same after accounting for the amount of alert time provided in each encounter, although the limited surveillance volume for the non-transponder equipped aircraft meant alerts tended to occur later and therefore were more difficult to resolve.

loss of well clear↗

Detection and Tracking of Aircraft in the Far-Field from Small Unmanned Aerial Systems

Onboard far-field aircraft detection is needed for safe non-cooperative traffic mitigation in autonomous small Unmanned Aerial System (sUAS) operations. Machine vision systems, based on standard optics and visible light detectors, possess the ideal size, weight, and power (SWaP) requirements for sUAS. This work presents the design and analysis of a novel aircraft detection and tracking pipeline based on optical sensing alone. Key contributions of the work include a refined range inequality model based on sensing and detection with FAA well-clear separation assurance distances between aircraft in mind, a detector fusion method to maximize the benefit of two image detectors, and a comparative analysis of Linear Kalman-filtering and Extended Kalman-filtering to seek optimal tracking performance. The pipeline is evaluated offline against multiple intruder platforms, using two types of flight encounters: multirotor sUAS vs. fixed-wing sUAS and multirotor sUAS vs. general aviation(GA)plane. Analysis is restricted to the rate-limiting head-on and departing collision volume cases vertically separated for safety. Results indicate that it is feasible to use the proposed optical spatial-temporal tracking algorithm to provide adequate alerting time to prevent penetration of well-clear separation volumes for both sUAS and GA aircraft.

Unmanned Aerial System↗

Autonomous Contingency Management In Urban Air Mobility: The Communication Network Awareness Machine System

Next Generation Air Transportation System (NextGen) has begun the modernization of the nation’s air transportation system (NAS), with goals to improve system safety, increase operation efficiency and capacity, provide enhanced predictability, resilience and robustness [1]. The overall objective of the Air Traffic Management-eXploration (ATM-X) project is to facilitate the goals of NextGen by conducting research to enable the growing demand of new, mission variant, air vehicles with safe access to the NAS. The implementation and utilization of new and burgeoning technologies that are both flexible, scalable, and systematically user-focused are requisite for ATM-X to achieve its intention of NAS safe entry [2]. Researchers from NASA Langley’s Flight Deck Integration Team have developed a system architecture that would allow ATM-X to leverage the necessary capabilities of an Increasingly Autonomous System (IAS), machine-agent that will promote the safe access and operation of air vehicles within what has become the byproduct of NextGen modernization, a Net-Centric airspace architecture and an Urban Air Mobility (UAM) community. Conducting flight operations within this type of architecture constrains the human-agent’s natural ability by data management. When the massive volume of data, its types, and the acquisition speed at which the data is ingested is observed it becomes evident that the human-agent will be functioning at an operational disadvantage. Therefore, the development and integration of intelligent machine-agents into the flight deck are a necessary implementation to achieve ATM-X overall objective of safe access and operation in the NAS.

Urban Air Mobility↗

The Small Aircraft Transportation System Higher Volume Operations (SATS HVO) Flight Experiment

This paper provides a summary of conclusions from the Small Aircraft Transportation System (SATS) Higher Volume Operations (HVO) Flight Experiment which NASA conducted to determine pilot acceptability of the HVO concept for normal conditions. The SATS HVO concept improves efficiency at non-towered, non-radar airports in Instrument Meteorological Conditions (IMC) while achieving a level of safety equal to today s system. Reported are results from flight experiment data that indicate that the SATS HVO concept is viable. The success of the SATS HVO concept is based on acceptable pilot workload, performance, and subjective criteria when compared to the procedural control operations in use today at non-towered, non-radar controlled airfields in IMC. The HVO Flight Experiment, flown on NASA's Cirrus SR22, used a subset of the HVO Simulation Experiment scenarios and evaluation pilots in order to validate the simulation experiment results. HVO and Baseline (today s system) scenarios flown included: single aircraft arriving for a GPS non-precision approach; aircraft arriving for the approach with multiple traffic aircraft; and aircraft arriving for the approach with multiple traffic aircraft and then conducting a missed approach. Results reveal that all twelve low-time instrument-rated pilots preferred SATS HVO when compared to current procedural separation operations. These pilots also flew the HVO procedures safely and proficiently without additional workload in comparison to today s system (Baseline). Detailed results of pilot flight technical error, and their subjective assessments of workload and situation awareness are presented in this paper.

Williams, Daniel M.↗

Soot and Sulfuric Acid from Aircraft: Is There Enough to Cause Detrimental Environmental E-kCTSs?

Aerosol from aircraft can affect the environment in three ways: First, soot aerosol has been implicated to cause Icing-tern ozone depletion at mid-latitudes in the lower stratosphere at a rate of approx. 5% per decade. This effect is in addition and unrelated to the polar ozone holes which are strongly influenced by heterogeneous chemistry on polar stratospheric clouds. Second, the most obvious effect of jet aircraft is the formation of visible contrails in the upper troposphere. The Salt Lake City region experienced an 8% increase in cirrus cloud cover over a 15-year period which covariates with an increase in regional commercial air traffic. If soot particles act as freezing nuclei to cause contrail formation heterogeneously, they would be linked to a secondary effect to cloud modification that very likely is climatologically important. Third, a buildup of soot aerosol could reduce the single scatter albedo of stratospheric aerosol from 0.993+0.004 to 0.98, a critical value that has been postulated to separate stratospheric cooling from warming. Thus arises an important question: Do aircraft emit sufficient amounts of soot to have detrimental effects and warrant emission controls? During the 1996 SUCCESS field campaign, we sampled aerosols in the exhaust wake of a Boeing 757 aircraft and determined emission indices for sulfuric acid (EI(sub H2SO4) = 9.0E-2 and 5.0E-1 g/kg (sub FUEL) for 75 and 675 ppm fuel-sulfur, respectively) and soot aerosol (2.2E-3 less than EI(sub SOOT) = l.lE-2 g/kg (sub FUEL)). The soot particle analysis accounted for their fractal nature, determined electron-microscopically, which enhanced the surface area by a factor of 26 and the volume 11-fold over equivalent-volume spheres. The corresponding fuel-sulfur to H2SO4 conversion efficiency was 10% (for 675 ppmm fuel-S) and 37% (for 75 ppmm fuel-S). Applying the H2SO4 emission index to the 1990 fuel use by the worlds commercial fleets of 1.3E11 kg, a conversion efficiency of 30% of 500 ppmm fuel-S would have led to an annual contribution to the atmospheric sulfur budget by aircraft of 2.E7 kg H2SO4. This is about one part in 1.E4 of anthropogenic sulfate from other sources. The soot emission index given above yielded a 1990 injection of soot aerosol by aircraft of 1.E6 kg. Thus, soot amounts to only five percent of the aerosol generated by aircraft. Its reactivity with ozone would have to be 20 times that of sulfuric acid particles to make it chemically significant. Nevertheless, the findings, of stratospheric soot loadings commensurate with aircraft fuel consumption, based on the emission index given above and the assumption of stratospheric residence times of the order of one year implicate aircraft as stratospheric polluters. A trend similar to soot of H2SO4 aerosol loading could not be deciphered, neither from in situ measurements nor SAGE II satellite extinction, against the "noise" due to volcanic eruptions. Observation of soot particles at 20 km altitude which, if emitted by aircraft were generated at 10-12 km altitude, suggests a displacement of those particles against gravity. Because eddy mixing is virtually absent in the lower stratosphere and isentropic mixing explains lofting to only about 15 km, radiometric forces acting on morphologically and chemically asymmetric soot particles must be considered a possibility. The consequence could be an extended residence time of soot against that of sulfuric acid aerosol that would lower the single scatter albedo with time.

Pueschel, R. F.↗

Pilot Critical Incident Reports as a Means to Identify Human Factors of Remotely Piloted Aircraft

It has been estimated that aviation accidents are typically preceded by numerous minor incidents arising from the same causal factors that ultimately produced the accident. Accident databases provide in-depth information on a relatively small number of occurrences, however incident databases have the potential to provide insights into the human factors of Remotely Piloted Aircraft System (RPAS) operations based on a larger volume of less-detailed reports. Currently, there is a lack of incident data dealing with the human factors of unmanned aircraft systems. An exploratory study is being conducted to examine the feasibility of collecting voluntary critical incident reports from RPAS pilots. Twenty-three experienced RPAS pilots volunteered to participate in focus groups in which they described critical incidents from their own experience. Participants were asked to recall (1) incidents that revealed a system flaw, or (2) highlighted a case where the human operator contributed to system resilience or mission success. Participants were asked to only report incidents that could be included in a public document. During each focus group session, a note taker produced a de-identified written record of the incident narratives. At the end of the session, participants reviewed each written incident report, and made edits and corrections as necessary. The incidents were later analyzed to identify contributing factors, with a focus on design issues that either hindered or assisted the pilot during the events. A total of 90 incidents were reported. Human factor issues included the impact of reduced sensory cues, traffic separation in the absence of an out-the-window view, control latencies, vigilance during monotonous and ultra-long endurance flights, control station design considerations, transfer of control between control stations, the management of lost link procedures, and decision-making during emergencies. Pilots participated willingly and enthusiastically in the study, and generally had little difficulty recalling critical incidents. The results suggest that pilot interviews can be a productive method of gathering information on incidents that might not otherwise be reported. Some of the issues described in the reports have received significant attention in the literature, or are analogous to human factors of manned aircraft. In other cases, incident reports involved human factors that are poorly understood, and have not yet been the subject of extensive study. Although many of the reported incidents were related to pilot error, the participants also provided examples of the positive contribution that humans make to the operation of highly-automated systems.

unmanned aircraft systems↗

Data Recipes: Toward Creating How-To Knowledge Base for Earth Science Data

Both the diversity and volume of Earth science data from satellites and numerical models are growing dramatically, due to an increasing population of measured physical parameters, and also an increasing variety of spatial and temporal resolutions for many data products. To further complicate matters, Earth science data delivered to data archive centers are commonly found in different formats and structures. NASA data centers, managed by the Earth Observing System Data and Information System (EOSDIS), have developed a rich and diverse set of data services and tools with features intended to simplify finding, downloading, and working with these data. Although most data services and tools have user guides, many users still experience difficulties with accessing or reading data due to varying levels of familiarity with data services, tools, and or formats. The data recipe project at Goddard Earth Science Data and Information Services Center (GES DISC) was initiated in late 2012 for enhancing user support. A data recipe is a How-To online explanatory document, with step-by-step instructions and examples of accessing and working with real data (http:disc.sci.gsfc.nasa.govrecipes). The current suite of recipes has been found to be very helpful, especially to first-time-users of particular data services, tools, or data products. Online traffic to the data recipe pages is significant, even though the data recipe topics are still limited. An Earth Science Data System Working Group (ESDSWG) for data recipes was established in the spring of 2014, aimed to initiate an EOSDIS-wide campaign for leveraging the distributed knowledge within EOSDIS and its user communities regarding their respective services and tools. The ESDSWG data recipe group is working on an inventory and analysis of existing data recipes and tutorials, and will provide guidelines and recommendation for writing and grouping data recipes, and for cross linking recipes to data products. This presentation gives an overview of the data recipe activites at GES DISC and ESDSWG. We are seeking requirements and input from a broader data user community to establish a strong knowledge base for Earth science data research and application implementations.

data recipe↗

Communication Network Awareness Machine System Phase I Development: The Intelligent Party-Line Schema

As NextGen continues toward the full implementation of a Net-Centric Architecture (N-CA)it will inherently provide a continuous increase to the Three-Vs components (Volume, Velocity, and Variety) of big data . This will create an insurmountable environment for direct-action aviation personnel (DAAP)as the DAAP’s natural abilities to manage and process data into actionable information will be overmatched by the Three-Vs. Therefore, conducting operations within a N-CA requires that new tools and applications be researched and developed to aid the DAAP’s ability to understand and manage data, mitigate non-normals, create contingency plans and actions. This paper will describe a research area at NASA Langley Research Center known as the Intelligent Party-Line (IPL).

Intelligent Party-Line↗

Digital Multicasting of Multiple Audio Streams

The Mission Control Center Voice Over Internet Protocol (MCC VOIP) system (see figure) comprises hardware and software that effect simultaneous, nearly real-time transmission of as many as 14 different audio streams to authorized listeners via the MCC intranet and/or the Internet. The original version of the MCC VOIP system was conceived to enable flight-support personnel located in offices outside a spacecraft mission control center to monitor audio loops within the mission control center. Different versions of the MCC VOIP system could be used for a variety of public and commercial purposes - for example, to enable members of the general public to monitor one or more NASA audio streams through their home computers, to enable air-traffic supervisors to monitor communication between airline pilots and air-traffic controllers in training, and to monitor conferences among brokers in a stock exchange. At the transmitting end, the audio-distribution process begins with feeding the audio signals to analog-to-digital converters. The resulting digital streams are sent through the MCC intranet, using a user datagram protocol (UDP), to a server that converts them to encrypted data packets. The encrypted data packets are then routed to the personal computers of authorized users by use of multicasting techniques. The total data-processing load on the portion of the system upstream of and including the encryption server is the total load imposed by all of the audio streams being encoded, regardless of the number of the listeners or the number of streams being monitored concurrently by the listeners. The personal computer of a user authorized to listen is equipped with special- purpose MCC audio-player software. When the user launches the program, the user is prompted to provide identification and a password. In one of two access- control provisions, the program is hard-coded to validate the user s identity and password against a list maintained on a domain-controller computer at the MCC. In the other access-control provision, the program verifies that the user is authorized to have access to the audio streams. Once both access-control checks are completed, the audio software presents a graphical display that includes audiostream-selection buttons and volume-control sliders. The user can select all or any subset of the available audio streams and can adjust the volume of each stream independently of that of the other streams. The audio-player program spawns a "read" process for the selected stream(s). The spawned process sends, to the router(s), a "multicast-join" request for the selected streams. The router(s) responds to the request by sending the encrypted multicast packets to the spawned process. The spawned process receives the encrypted multicast packets and sends a decryption packet to audio-driver software. As the volume or muting features are changed by the user, interrupts are sent to the spawned process to change the corresponding attributes sent to the audio-driver software. The total latency of this system - that is, the total time from the origination of the audio signals to generation of sound at a listener s computer - lies between four and six seconds.

Macha, Mitchell↗

UTM UAS Serivce Supplier Development: Sprint 1 Toward Technical Capability Level 4

NASA's UAS Traffic Management (UTM) Project has been tasked with developing concepts and initial implementations for integrating and managing small unmanned aircraft systems (UAS) into the low altitude airspace. To accomplish this task, the Project planned a phased approach based on four Technical Capability Levels (TCLs). As of this writing, TCL4 is currently in development for a late Spring 2019 flight demonstration. This TCL is focused on operations in an urban environment and includes the handling of high density and large-scale off-nominal conditions, vehicle-to-vehicle communications, detect-and-avoid technologies, communication requirements, public safety operations, airspace restrictions, and other related goals. Through research and testing to date, NASA has developed an architecture for UTM that depends on commercial entities collaboratively providing services that are traditionally provided by the Air Navigation Service Provider(ANSP) in manned aviation. A key component of this architecture is the UAS Service Supplier (USS), which acts as a communications bridge between UAS operators and the ANSP when necessary. In addition, the collection of USSs form a USS Network to collaboratively manage the airspace through the sharing of data and the adherence to a standard or set of standards required to participate in this USS Network. This document provides a record of the first step in the development of interoperable USSs that will ultimately support TCL4 flight testing and formalization of the overall UTM concept. To develop these USSs and the underlying specifications for them, NASA has planned a series of "Sprints" to work with industry partners in implementing the features and proposed specifications for USSs to participate in TCL4. This report describes Sprint One. In this Sprint, the focus was on establishing a baseline for the Application Programming Interfaces (APIs) and their associated data models. In addition, the concept of UAS Volume Reservations (UVR) (areas that impose restrictions on sUAS that are allowed to operate) was tested. NASA provided the specifications and iterated on them with partners while implementers developed to those specifications. NASA then tested each partner's implementation to ensure compatibility with all other implementers. This process helped all stakeholders gain confidence that the foundation for future Sprints was solid.

UAS service supplier↗