SEARCH · Engineering Papers

Results for “Technical Languages”

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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

166 records · Page 10

All sources NASA NTRS DOE OSTI

NASA NTRSDate not supplied

Inverse Text Normalization of Air Traffic Control System Command Center Planning Telecon Transcriptions

We present a hybrid neural network and rule-based Inverse Text Normalization (ITN) method for domains containing unique technical phraseology, specifically ATCSCC planning telecon audio transcriptions. The Air Traffic Control System Command Center (ATCSCC) hosts bihourly planning telephone conferences (or planning telecons) to ensure smooth operations within the National Airspace (NAS). Access to both live and post meeting transcripts of this speech audio would enable quick review of meetings. ITN is the process of converting un-formatted "raw'' speech-to-text transcripts into a human (expert) readable written form. Our hybrid ITN framework utilizes a neural network to format conversational English, and rule-based methods to format domain-specific aviation text. With a preliminary overall Word Error Rate with Punctuation and Capitalization (WER PC) of 8.26, we show that this method has vast potential in being applied to ATCSCC planning telecon audio and other audio/text based data available in ATM.

Air Traffic Management↗

NASA NTRS2002

REACH: Real-Time Data Awareness in Multi-Spacecraft Missions

Missions have been proposed that will use multiple spacecraft to perform scientific or commercial tasks. Indeed, in the commercial world, some spacecraft constellations already exist. Aside from the technical challenges of constructing and flying these missions, there is also the financial challenge presented by the tradition model of the flight operations team (FOT) when it is applied to a constellation mission. Proposed constellation missions range in size from three spacecraft to more than 50. If the current ratio of three-to-five FOT personnel per spacecraft is maintained, the size of the FOT becomes cost prohibitive. The Advanced Architectures and Automation Branch at the Goddard Space Flight Center (GSFC Code 588) saw the potential to reduce the cost of these missions by creating new user interfaces to the ground system health-and-safety data. The goal is to enable a smaller FOT to remain aware and responsive to the increased amount of ground system information in a multi-spacecraft environment. Rather than abandon the tried and true, these interfaces were developed to run alongside existing ground system software to provide additional support to the FOT. These new user interfaces have been combined in a tool called REACH. REACH-the Real-time Evaluation and Analysis of Consolidated Health-is a software product that uses advanced visualization techniques to make spacecraft anomalies easy to spot, no matter how many spacecraft are in the constellation. REACH reads a real-time stream of data from the ground system and displays it to the FOT such that anomalies are easy to pick out and investigate. Data visualization has been used in ground system operations for many years. To provide a unique visualization tool, we developed a unique source of data to visualize: the REACH Health Model Engine. The Health Model Engine is rule-based software that receives real-time telemetry information and outputs "health" information related to the subsystems and spacecraft that the telemetry belong to. The Health Engine can run out-of-the-box or can be tailored with a scripting language. Out of the box, it uses limit violations to determine the health of subsystems and spacecraft; when tailored, it determines health using equations combining the values and limits of any telemetry in the spacecraft. The REACH visualizations then "roll up" the information from the Health Engine into high level, summary displays. These summary visualizations can be "zoomed" into for increasing levels of detail. Currently REACH is installed in the Small Explorer (SMEX) lab at GSFC, and is monitoring three of their five spacecraft. We are scheduled to install REACH in the Mid-sized Explorer (MIDEX) lab, which will allow us to monitor up to six more spacecraft. The process of installing and using our "research" software in an operational environment has provided many insights into which parts of REACH are a step forward and which of our ideas are missteps. Our paper explores both the new concepts in spacecraft health-and-safety visualization, the difficulties of such systems in the operational environment, and the cost and safety issues of multi-spacecraft missions.

Maks, Lori↗

NASA NTRS2015

Mock Certification Basis for an Unmanned Rotorcraft for Precision Agricultural Spraying

This technical report presents the results of a case study using a hazard-based approach to develop preliminary design and performance criteria for an unmanned agricultural rotorcraft requiring airworthiness certification. This case study is one of the first in the public domain to examine design and performance criteria for an unmanned aircraft system (UAS) in tandem with its concept of operations. The case study results are intended to support development of airworthiness standards that could form a minimum safety baseline for midsize unmanned rotorcraft performing precision agricultural spraying operations under beyond visual line-of-sight conditions in a rural environment. This study investigates the applicability of current methods, processes, and standards for assuring airworthiness of conventionally piloted (manned) aircraft to assuring the airworthiness of UAS. The study started with the development of a detailed concept of operations for precision agricultural spraying with an unmanned rotorcraft (pp. 5-18). The concept of operations in conjunction with a specimen unmanned rotorcraft were used to develop an operational context and a list of relevant hazards (p. 22). Minimum design and performance requirements necessary to mitigate the hazards provide the foundation of a proposed (or mock) type certification basis. A type certification basis specifies the applicable standards an applicant must show compliance with to receive regulatory approval. A detailed analysis of the current airworthiness regulations for normal-category rotorcraft (14 Code of Federal Regulations, Part 27) was performed. Each Part 27 regulation was evaluated to determine whether it mitigated one of the relevant hazards for the specimen UAS. Those regulations that did were included in the initial core of the type certification basis (pp. 26-31) as written or with some simple modifications. Those regulations that did not mitigate a recognized hazard were excluded from the certification basis. The remaining regulations were applicable in intent, but the text could not be easily tailored. Those regulations were addressed in separate issue papers. Exploiting established regulations avoids the difficult task of generating and interpreting novel requirements, through the use of acceptable, standardized language. The rationale for the disposition of the regulations was assessed and captured (pp. 58-115). The core basis was then augmented by generating additional requirements (pp. 38-47) to mitigate hazards for an unmanned sprayer that are not covered in Part 27.

Hayhurst, Kelly J.↗

NASA NTRS2012

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↗