Search NASA⌕ Search

SEARCH · Search NASA

Results for “graphical user interface”

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 253 records · Page 14
All sourcesNASA NTRSDOE OSTI
NASA NTRS1994

Mission Operations Centers (MOCs): Integrating key spacecraft ground data system components

In an environment characterized by decreasing budgets, limited system development time, and user needs for increased capabilities, the Mission Operations Division (MOD) at the National Aeronautics and Space Administration Goddard Space Flight Center initiated a new, cost-effective concept in developing its spacecraft ground data systems: the Mission Operations Center (MOC). In the MOC approach, key components are integrated into a comprehensive and cohesive spacecraft planning, monitoring, command, and control system with a single, state-of-the-art graphical user interface. The MOD is currently implementing MOC's, which feature a common, reusable, and extendable system architecture, to support the X-Ray Timing Explorer (XTE), Tropical Rainfall Measuring Mission (TRMM), and Advanced Composition Explorer (ACE) missions. As a result of the MOC approach, mission operations are integrated, and users can, with a single system, perform real-time health and safety monitoring, real-time command and control, real-time attitude processing, real-time and predictive graphical spacecraft monitoring, trend analysis, mission planning and scheduling, command generation and management, network scheduling, guide star selection, and (using an expert system) spacecraft monitoring and fault isolation. The MOD is also implementing its test and training simulators under the new MOC management structure. This paper describes the MOC concept, the management approaches used in developing MOC systems, the technologies employed and the development process improvement initiatives applied in implementing MOC systems, and the expected benefits to both the user and the mission project in using the MOC approach.

Harbaugh, Randy↗
NASA NTRS1998

A Geometry Based Infra-Structure for Computational Analysis and Design

The computational steps traditionally taken for most engineering analysis suites (computational fluid dynamics (CFD), structural analysis, heat transfer and etc.) are: (1) Surface Generation -- usually by employing a Computer Assisted Design (CAD) system; (2) Grid Generation -- preparing the volume for the simulation; (3) Flow Solver -- producing the results at the specified operational point; (4) Post-processing Visualization -- interactively attempting to understand the results. For structural analysis, integrated systems can be obtained from a number of commercial vendors. These vendors couple directly to a number of CAD systems and are executed from within the CAD Graphical User Interface (GUI). It should be noted that the structural analysis problem is more tractable than CFD; there are fewer mesh topologies used and the grids are not as fine (this problem space does not have the length scaling issues of fluids). For CFD, these steps have worked well in the past for simple steady-state simulations at the expense of much user interaction. The data was transmitted between phases via files. In most cases, the output from a CAD system could go to Initial Graphics Exchange Specification (IGES) or Standard Exchange Program (STEP) files. The output from Grid Generators and Solvers do not really have standards though there are a couple of file formats that can be used for a subset of the gridding (i.e. PLOT3D data formats). The user would have to patch up the data or translate from one format to another to move to the next step. Sometimes this could take days. Specifically the problems with this procedure are:(1) File based -- Information flows from one step to the next via data files with formats specified for that procedure. File standards, when they exist, are wholly inadequate. For example, geometry from CAD systems (transmitted via IGES files) is defined as disjoint surfaces and curves (as well as masses of other information of no interest for the Grid Generator). This is particularly onerous for modern CAD systems based on solid modeling. The part was a proper solid and in the translation to IGES has lost this important characteristic. STEP is another standard for CAD data that exists and supports the concept of a solid. The problem with STEP is that a solid modeling geometry kernel is required to query and manipulate the data within this type of file. (2) 'Good' Geometry. A bottleneck in getting results from a solver is the construction of proper geometry to be fed to the grid generator. With 'good' geometry a grid can be constructed in tens of minutes (even with a complex configuration) using unstructured techniques. Adroit multi-block methods are not far behind. This means that a million node steady-state solution can be computed on the order of hours (using current high performance computers) starting from this 'good' geometry. Unfortunately, the geometry usually transmitted from the CAD system is not 'good' in the grid generator sense. The grid generator needs smooth closed solid geometry. It can take a week (or more) of interaction with the CAD output (sometimes by hand) before the process can begin. One way Communication. (3) One-way Communication -- All information travels on from one phase to the next. This makes procedures like node adaptation difficult when attempting to add or move nodes that sit on bounding surfaces (when the actual surface data has been lost after the grid generation phase). Until this process can be automated, more complex problems such as multi-disciplinary analysis or using the above procedure for design becomes prohibitive. There is also no way to easily deal with this system in a modular manner. One can only replace the grid generator, for example, if the software reads and writes the same files. Instead of the serial approach to analysis as described above, CAPRI takes a geometry centric approach. This makes the actual geometry (not a discretized version) accessible to all phases of the analysis. The connection to the geometry is made through an Application Programming Interface (API) and NOT a file system. This API isolates the top-level applications (grid generators, solvers and visualization components) from the geometry engine. Also this allows the replacement of one geometry kernel with another, without effecting these top-level applications. For example, if UniGraphics is used as the CAD package then Parasolid (UG's own geometry engine) can be used for all geometric queries so that no solid geometry information is lost in a translation. This is much better than STEP because when the data is queried, the same software is executed as used in the CAD system. Therefore, one analyzes the exact part that is in the CAD system. CAPRI uses the same idea as the commercial structural analysis codes but does not specify control. Software components of the CAD system are used, but the analysis suite, not the CAD operator, specifies the control of the software session. This also means that the license issues (may be) minimized and individuals need not have to know how to operate a CAD system in order to run the suite.

Haimes, Robert↗
NASA NTRS2013

Adaptive Distributed Environment for Procedure Training (ADEPT)

ADEPT (Adaptive Distributed Environment for Procedure Training) is designed to provide more effective, flexible, and portable training for NASA systems controllers. When creating a training scenario, an exercise author can specify a representative rationale structure using the graphical user interface, annotating the results with instructional texts where needed. The author's structure may distinguish between essential and optional parts of the rationale, and may also include "red herrings" - hypotheses that are essential to consider, until evidence and reasoning allow them to be ruled out. The system is built from pre-existing components, including Stottler Henke's SimVentive instructional simulation authoring tool and runtime. To that, a capability was added to author and exploit explicit control decision rationale representations. ADEPT uses SimVentive's Scalable Vector Graphics (SVG)- based interactive graphic display capability as the basis of the tool for quickly noting aspects of decision rationale in graph form. The ADEPT prototype is built in Java, and will run on any computer using Windows, MacOS, or Linux. No special peripheral equipment is required. The software enables a style of student/ tutor interaction focused on the reasoning behind systems control behavior that better mimics proven Socratic human tutoring behaviors for highly cognitive skills. It supports fast, easy, and convenient authoring of such tutoring behaviors, allowing specification of detailed scenario-specific, but content-sensitive, high-quality tutor hints and feedback. The system places relatively light data-entry demands on the student to enable its rationale-centered discussions, and provides a support mechanism for fostering coherence in the student/ tutor dialog by including focusing, sequencing, and utterance tuning mechanisms intended to better fit tutor hints and feedback into the ongoing context.

Domeshek, Eric↗
NASA NTRS2013

TSAFE Interface Control Document v 2.0

This document specifies the data interface for TSAFE, the Tactical Separation-Assured Flight Environment. TSAFE is a research prototype of a software application program for alerting air traffic controllers to imminent conflicts in enroute airspace. It is intended for Air Route Traffic Control Centers ("Centers") in the U.S. National Airspace System. It predicts trajectories for approximately 3 minutes into the future, searches for conflicts, and sends data about predicted conflicts to the client, which uses the data to alert an air traffic controller of conflicts. TSAFE itself does not provide a graphical user interface.

Paielli, Russell A.↗
NASA NTRS2013

Hyperspectral Microwave Atmospheric Sounder (HyMAS) Architecture and Design Accommodations

The Hyperspectral Microwave Atmospheric Sounder (HyMAS) is being developed at Lincoln Laboratories and accommodated by the Goddard Space Flight Center for a flight opportunity on a NASA research aircraft. The term "hyperspectral microwave" is used to indicate an all-weather sounding that performs equivalent to hyperspectral infrared sounders in clear air with vertical resolution of approximately 1 km. Deploying the HyMAS equipped scanhead with the existing Conical Scanning Microwave Imaging Radiometer (CoSMIR) shortens the path to a flight demonstration. Hyperspectral microwave is achieved through the use of independent RF antennas that sample the volume of the Earth s atmosphere through various levels of frequencies, thereby producing a set of dense, spaced vertical weighting functions. The simulations proposed for HyMAS 118/183-GHz system should yield surface precipitation rate and water path retrievals for small hail, soft hail, or snow pellets, snow, rainwater, etc. with accuracies comparable to those of the Advanced Technology Microwave Sounder. Further improvements in retrieval methodology (for example, polarization exploitation) are expected. The CoSMIR instrument is a packaging concept re-used on HyMAS to ease the integration features of the scanhead. The HyMAS scanhead will include an ultra-compact Intermediate Frequency Processor (IFP) module that is mounted inside the door to improve thermal management. The IFP is fabricated with materials made of Low-Temperature Co-fired Ceramic (LTCC) technology integrated with detectors, amplifiers, A/D conversion and data aggregation. The IFP will put out 52 channels of 16 bit data comprised of 4-9 channel data streams for temperature profiles and 2-8 channel streams for water vapor. With the limited volume of the existing CoSMIR scanhead and new HyMAS front end components, the HyMAS team at Goddard began preliminary layout work inside the new drum. Importing and re-using models of the shell, the scan head computer, and the slip rings developed for CoSMIR was the starting point. The next step was to modify the antenna faceplate to accommodate the dimensions of the three dual polarization Gaussian Optics Antenna (GOA) assemblies. Two mechanical concepts for the core technology, the hyperspectral IFP, were captured in a design tradeoff. Connector models considered minimum bend radii for the IFP analog connectors. Hyperspectral imaging is accomplished by strategically using a short wavelength intermediate frequency of 18-29 GHz, and thus reducing the size of components in the connection of the front end to the IFP. The SMK (2.92mm) Series connector will lay near the hinge line to minimize its flexing. The digital output of the IFP will use a Serial Peripheral Interface (SPI) that must be accommodated by the scan head computer. To make that computer more reliable, maintainable, and forward compatible with the 52 HyMAS channels, a testbed of the scan head, calibration, and archive computers and the PIC24 microprocessor that resides on the IFP is in development. The computers will be programmed using a new framework application called Interoperable Remote Component (IRC). This software allows flexibility to program computers that communicate with each other and can adapt easily to the emerging HyMAS requirements for data format, algorithms, and graphical user interface (GUI). It is expected that the CoSMIR instrument will cut over to the IRC after it is adapted on an updated CoSMIR testbed.

Hilliard, Lawrence↗
NASA NTRS1993

SCAILET: An intelligent assistant for satellite ground terminal operations

NASA Lewis Research Center has applied artificial intelligence to an advanced ground terminal. This software application is being deployed as an experimenter interface to the link evaluation terminal (LET) and was named Space Communication Artificial Intelligence for the Link Evaluation Terminal (SCAILET). The high-burst-rate (HBR) LET provides 30-GHz-transmitting and 20-GHz-receiving, 220-Mbps capability for wide band communications technology experiments with the Advanced Communication Technology Satellite (ACTS). The HBR-LET terminal consists of seven major subsystems. A minicomputer controls and monitors these subsystems through an IEEE-488 or RS-232 protocol interface. Programming scripts (test procedures defined by design engineers) configure the HBR-LET and permit data acquisition. However, the scripts are difficult to use, require a steep learning curve, are cryptic, and are hard to maintain. This discourages experimenters from utilizing the full capabilities of the HBR-LET system. An intelligent assistant module was developed as part of the SCAILET software. The intelligent assistant addresses critical experimenter needs by solving and resolving problems that are encountered during the configuring of the HBR-LET system. The intelligent assistant is a graphical user interface with an expert system running in the background. In order to further assist and familiarize an experimenter, an on-line hypertext documentation module was developed and included in the SCAILET software.

Shahidi, A. K.↗
NASA NTRS2009

Virtual Diagnostic Interface: Aerospace Experimentation in the Synthetic Environment

The Virtual Diagnostics Interface (ViDI) methodology combines two-dimensional image processing and three-dimensional computer modeling to provide comprehensive in-situ visualizations commonly utilized for in-depth planning of wind tunnel and flight testing, real time data visualization of experimental data, and unique merging of experimental and computational data sets in both real-time and post-test analysis. The preparation of such visualizations encompasses the realm of interactive three-dimensional environments, traditional and state of the art image processing techniques, database management and development of toolsets with user friendly graphical user interfaces. ViDI has been under development at the NASA Langley Research Center for over 15 years, and has a long track record of providing unique and insightful solutions to a wide variety of experimental testing techniques and validation of computational simulations. This report will address the various aspects of ViDI and how it has been applied to test programs as varied as NASCAR race car testing in NASA wind tunnels to real-time operations concerning Space Shuttle aerodynamic flight testing. In addition, future trends and applications will be outlined in the paper.

Schwartz, Richard J.↗
NASA NTRS2010

Virtual Diagnostic Interface: Aerospace Experimentation in the Synthetic Environment

The Virtual Diagnostics Interface (ViDI) methodology combines two-dimensional image processing and three-dimensional computer modeling to provide comprehensive in-situ visualizations commonly utilized for in-depth planning of wind tunnel and flight testing, real time data visualization of experimental data, and unique merging of experimental and computational data sets in both real-time and post-test analysis. The preparation of such visualizations encompasses the realm of interactive three-dimensional environments, traditional and state of the art image processing techniques, database management and development of toolsets with user friendly graphical user interfaces. ViDI has been under development at the NASA Langley Research Center for over 15 years, and has a long track record of providing unique and insightful solutions to a wide variety of experimental testing techniques and validation of computational simulations. This report will address the various aspects of ViDI and how it has been applied to test programs as varied as NASCAR race car testing in NASA wind tunnels to real-time operations concerning Space Shuttle aerodynamic flight testing. In addition, future trends and applications will be outlined in the paper.

Schwartz, Richard J.↗
NASA NTRS2006

X-Windows Socket Widget Class

The X-Windows Socket Widget Class ("Class" is used here in the object-oriented-programming sense of the word) was devised to simplify the task of implementing network connections for graphical-user-interface (GUI) computer programs. UNIX Transmission Control Protocol/Internet Protocol (TCP/IP) socket programming libraries require many method calls to configure, operate, and destroy sockets. Most X Windows GUI programs use widget sets or toolkits to facilitate management of complex objects. The widget standards facilitate construction of toolkits and application programs. The X-Windows Socket Widget Class encapsulates UNIX TCP/IP socket-management tasks within the framework of an X Windows widget. Using the widget framework, X Windows GUI programs can treat one or more network socket instances in the same manner as that of other graphical widgets, making it easier to program sockets. Wrapping ISP socket programming libraries inside a widget framework enables a programmer to treat a network interface as though it were a GUI.

Barry, Matthew R.↗
NASA NTRSDate not supplied

Usability of Pre-Flight Planning Interfaces for Supplemental Data Service Provider Tools to Support Uncrewed Aircraft System Traffic Management

Small uncrewed aircraft systems (sUASs) operate in low-altitude, uncontrolled airspace – where support services for their operators (UASOs) are not currently provided. NASA’s System-Wide Safety (SWS) project is identifying the potential risks and hazards to sUAS operations to provide, inform, and improve the designs of In-time Aviation Safety Management Systems (IASMS). The IASMS will include a suite of data-driven tools that compile and analyze data collected from aviation systems and environmental sources to predict hazards, and provide information to allow operators to mitigate these risks (Young et al., 2020). These risk and hazard services can be run and displayed to operators on graphical user interfaces (GUIs), as they relate to a vehicle(s)’ route of flight. These interfaces offer both a means to present hazard service output and offer an opportunity to test user understanding of the information, user decision making, and the best ways to present such data to an operator. Based on these future technologies and intended missions, it is important to investigate interface requirements and evaluate how operators might use these tools. Presenting salient and meaningful risk assessment information to operators is necessary to increase situation awareness and ultimately safety. Building on previous research (Feldman et al., 2022), a usability study comparing two GUIs was conducted to explore how individuals interacted with different styles of information displays. A series of pre-flight hazard and risk-assessment tasks were developed to evaluate participant performance using the Supplemental Data Service Provider Consolidated Dashboard and the Human Automation Team Interface System interfaces. Participants were trained to use both GUIs and their performance was analysed across different scenarios involving multiple sUASs. Performance on simple tasks and the System Usability Scale scores were reported by Feldman et al., 2023. Additional analyses and evaluations on more complex tasks (e.g., risk assessment, prioritization), workload and response times are examined in this paper.

sUAV interfaces↗
NASA NTRSDate not supplied

Usability of Pre-flight Planning Interfaces for Supplemental Data Service Provider Tools to Support Uncrewed Aircraft System Traffic Management

Small uncrewed aircraft systems (sUASs) operate in low-altitude, uncontrolled airspace – where support services for their operators (UASOs) are not currently provided. NASA’s System-Wide Safety (SWS) project is identifying the potential risks and hazards to sUAS operations to provide, inform, and improve the designs of In-time Aviation Safety Management Systems (IASMS). The IASMS will include a suite of data-driven tools that compile and analyze data collected from aviation systems and environmental sources to predict hazards, and provide information to allow operators to mitigate these risks (Young et al., 2020). These risk and hazard services can be run and displayed to operators on graphical user interfaces (GUIs), as they relate to a vehicle(s)’ route of flight. These interfaces offer both a means to present hazard service output and offer an opportunity to test user understanding of the information, user decision making, and the best ways to present such data to an operator. Based on these future technologies and intended missions, it is important to investigate interface requirements and evaluate how operators might use these tools. Presenting salient and meaningful risk assessment information to operators is necessary to increase situation awareness and ultimately safety. Building on previous research (Feldman et al., 2022), a usability study comparing two GUIs was conducted to explore how individuals interacted with different styles of information displays. A series of pre-flight hazard and risk-assessment tasks were developed to evaluate participant performance using the Supplemental Data Service Provider Consolidated Dashboard and the Human Automation Team Interface System interfaces. Participants were trained to use both GUIs and their performance was analysed across different scenarios involving multiple sUASs. Performance on simple tasks and the System Usability Scale scores were reported by Feldman et al., 2023. Additional analyses and evaluations on more complex tasks (e.g., risk assessment, prioritization), workload and response times are examined in this paper.

sUAV interfaces↗
NASA NTRS2006

X-Windows Information Sharing Protocol Widget Class

The X-Windows Information Sharing Protocol (ISP) Widget Class ("Class") is used here in the object-oriented-programming sense of the word) was devised to simplify the task of implementing ISP graphical-user-interface (GUI) computer programs. ISP programming tasks require many method calls to identify, query, and interpret the connections and messages exchanged between a client and an ISP server. Most X-Windows GUI programs use widget sets or toolkits to facilitate management of complex objects. The widget standards facilitate construction of toolkits and application programs. The X-Windows Information Sharing Protocol (ISP) Widget Class encapsulates the client side of the ISP programming libraries within the framework of an X-Windows widget. Using the widget framework, X-Windows GUI programs can interact with ISP services in an abstract way and in the same manner as that of other graphical widgets, making it easier to write ISP GUI client programs. Wrapping ISP client services inside a widget framework enables a programmer to treat an ISP server interface as though it were a GUI. Moreover, an alternate subclass could implement another communication protocol in the same sort of widget.

Barry, Matthew R.↗
NASA NTRS2005

NASA Interactive Forms Type Interface - NIFTI

A flexible database query, update, modify, and delete tool was developed that provides an easy interface to Oracle forms. This tool - the NASA interactive forms type interface, or NIFTI - features on-the- fly forms creation, forms sharing among users, the capability to query the database from user-entered criteria on forms, traversal of query results, an ability to generate tab-delimited reports, viewing and downloading of reports to the user s workstation, and a hypertext-based help system. NIFTI is a very powerful ad hoc query tool that was developed using C++, X-Windows by a Motif application framework. A unique tool, NIFTI s capabilities appear in no other known commercial-off-the- shelf (COTS) tool, because NIFTI, which can be launched from the user s desktop, is a simple yet very powerful tool with a highly intuitive, easy-to-use graphical user interface (GUI) that will expedite the creation of database query/update forms. NIFTI, therefore, can be used in NASA s International Space Station (ISS) as well as within government and industry - indeed by all users of the widely disseminated Oracle base. And it will provide significant cost savings in the areas of user training and scalability while advancing the art over current COTS browsers. No COTS browser performs all the functions NIFTI does, and NIFTI is easier to use. NIFTI s cost savings are very significant considering the very large database with which it is used and the large user community with varying data requirements it will support. Its ease of use means that personnel unfamiliar with databases (e.g., managers, supervisors, clerks, and others) can develop their own personal reports. For NASA, a tool such as NIFTI was needed to query, update, modify, and make deletions within the ISS vehicle master database (VMDB), a repository of engineering data that includes an indentured parts list and associated resource data (power, thermal, volume, weight, and the like). Since the VMDB is used both as a collection point for data and as a common repository for engineering, integration, and operations teams, a tool such as NIFTI had to be designed that could expedite the creation of database query/update forms which could then be shared among users.

Jain, Bobby↗
DOE OSTI2024

Monte Carlo Simulation with CAD Interface for Calculation of 3D Maps of Residual Dose (CRADA)

Objective: To develop an easy-to-use software application to predict and mitigate radiation effects in research environment, space instruments, nuclear plants and medical facilities and help nonproliferation and national security efforts. Tech-X will develop standalone software libraries and command-line tools for ( 1) translating CAD into tessellated surfaces and tetrahedral meshes in GDML (for Geant4 and MARS 15), ROOT (for MARS 15) and HDF5 (for compact representation and for the visualization) formats, (2) healing CAD geometries to make them suitable for Monte Carlo simulations; (3) creating uniform and variable Cartesian and cylindrical meshes for detailed scoring; and ( 4) efficient Monte Carlo navigation in CAD geometries. JLAB will finish automation of simulations of residual dose in CAD geometries and integrate Tech-X software into Geant4 and MARS15. Finally, Tech-X will develop a Graphical User Interface to set up and heal CAD geometries, create input files, run and visualize simulations for residual dose. This application will run on local desktops, local and remote clusters and supercomputers and will be made available through public clouds, such as Amazon Web Services.

46 INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AND ↗
NASA NTRS2004

Surface Modeling and Grid Generation for Iced Airfoils (SmaggIce)

Many of the troubles associated with problem solving are alleviated when there is a model that can be used to represent the problem. Through the Advanced Graphics and Visualization (G-VIS) Laboratory and other facilities located within the Research Analysis Center, the Computer Services Division (CSD) is able to develop and maintain programs and software that allow for the modeling of various situations. For example, the Icing Research Branch is devoted to investigating the effect of ice that forms on the wings and other airfoils of airplanes while in flight. While running tests that physically generate ice and wind on airfoils within the laboratories and wind tunnels on site are done, it would be beneficial if most of the preliminary work could be done outside of the lab. Therefore, individuals from within CSD have collaborated with Icing Research in order to create SmaggIce. This software allows users to create ice patterns on clean airfoils or open files containing a variety of icing situations, manipulate and measure these forms, generate, divide, and merge grids around these elements for more explicit analysis, and specify and rediscretize subcurves. With the projected completion date of Summer 2005, the majority of the focus of the Smagglce team is user-functionality and error handling. My primary responsibility is to test the Graphical User Interface (GUI) in SmaggIce in order to ensure the usability and verify the expected results of the events (buttons, menus, etc.) within the program. However, there is no standardized, systematic way in which to test all the possible combinations or permutations of events, not to mention unsolicited events such as errors. Moreover, scripting tests, if not done properly and with a view towards inevitable revision, can result in more apparent errors within the software and in effect become useless whenever the developers of the program make a slight change in the way a specific process is executed. My task therefore requires a brief yet intense study into GUI coverage criteria and creating algorithms for GUI implementation. Nevertheless, there are still heavily graphical features of SmaggIceSmaggIce that must be either corrected or redesigned before its release. A particular feature of SmaggIce is the ability to smooth out curves created by control points that form an arbitrary shape into something more acquiescent to gridding (while maintaining the integrity of the data). This is done by a mathematical model known as Non-Uniform Rational B-Spline (NURBS) curves. Existing NURBS code is written in FORTRAN-77 with static arrays for holding information. My new assignment is to allow for dynamic memory allocation within the code and to make it possible for the developers to call out functions from the NURBS code using C.

Hammond, Brandy M.↗
NASA NTRSDate not supplied

SIRIUS: Simulation Infrastructure for Research on Interoperating Unmanned Systems

This paper presents the Simulation Infrastructure for Research on Interoperating Unmanned Systems (SIRIUS), a research framework for simulation and analysis of future conceptual Urban Air Mobility (UAM) operations. SIRIUS is being developed under the auspices of the NASA Air Traffic Management eXploration project, UAM subproject (ATM-X UAM). SIRIUS provides an intuitive, highly configurable graphical user interface to design complex traffic scenarios and airspace configurations representative of conceptual UAM operations. Aircraft simulated with SIRIUS can be equipped with flight-tested capabilities for detect and avoid (DAA), geofencing, distributed merging and spacing, path conformance, and path planning while executing time-constrained, 4D trajectories generated by a UAM ground operations system. Central to the design of the SIRIUS simulation framework is the capability to evaluate the integration and interoperability of ground-based separation services (e.g., strategic separation) with extended DAA functionality (e.g., path monitoring, separation provision, merging and spacing, etc.) The simulation environment also supports modelling of wind, navigation, and sensor uncertainties, as well as communication delays. SIRIUS enables distributed simulation of large-scale scenarios. An interactive graphical analysis capability helps isolate, visualize, and compare relevant vehicle state data and widely used measures of performance metrics across multiple scenarios.

Andrew Peters↗
NASA NTRS2006

UWB Tracking Software Development

An Ultra-Wideband (UWB) two-cluster Angle of Arrival (AOA) tracking prototype system is currently being developed and tested at NASA Johnson Space Center for space exploration applications. This talk discusses the software development efforts for this UWB two-cluster AOA tracking system. The role the software plays in this system is to take waveform data from two UWB radio receivers as an input, feed this input into an AOA tracking algorithm, and generate the target position as an output. The architecture of the software (Input/Output Interface and Algorithm Core) will be introduced in this talk. The development of this software has three phases. In Phase I, the software is mostly Matlab driven and calls C++ socket functions to provide the communication links to the radios. This is beneficial in the early stage when it is necessary to frequently test changes in the algorithm. Phase II of the development is to have the software mostly C++ driven and call a Matlab function for the AOA tracking algorithm. This is beneficial in order to send the tracking results to other systems and also to improve the tracking update rate of the system. The third phase is part of future work and is to have the software completely C++ driven with a graphics user interface. This software design enables the fine resolution tracking of the UWB two-cluster AOA tracking system.

Gross, Julia↗
NASA NTRS2009

Configuring the HYSPLIT Model for National Weather Service Forecast Office and Spaceflight Meteorology Group Applications

For expedience in delivering dispersion guidance in the diversity of operational situations, National Weather Service Melbourne (MLB) and Spaceflight Meteorology Group (SMG) are becoming increasingly reliant on the PC-based version of the HYSPLIT model run through a graphical user interface (GUI). While the GUI offers unique advantages when compared to traditional methods, it is difficult for forecasters to run and manage in an operational environment. To alleviate the difficulty in providing scheduled real-time trajectory and concentration guidance, the Applied Meteorology Unit (AMU) configured a Linux version of the Hybrid Single-Particle Lagrangian Integrated Trajectory (HYSPLIT) (HYSPLIT) model that ingests the National Centers for Environmental Prediction (NCEP) guidance, such as the North American Mesoscale (NAM) and the Rapid Update Cycle (RUC) models. The AMU configured the HYSPLIT system to automatically download the NCEP model products, convert the meteorological grids into HYSPLIT binary format, run the model from several pre-selected latitude/longitude sites, and post-process the data to create output graphics. In addition, the AMU configured several software programs to convert local Weather Research and Forecast (WRF) model output into HYSPLIT format.

Dreher, Joseph G.↗