Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “User Interface Design”

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 1,045 records · Page 58

SpaceWire Protocol ID: What Does It Mean To You?

Spacewire is becoming a popular solution for satellite high-speed data buses because it is a simple standard that provides great flexibility for a wide range of system requirements. It is simple in packet format and protocol, allowing users to easily tailor their implementation for their specific application. Some of the attractive aspects of Spacewire that make it easy to implement also make it hard for future reuse. Protocol reuse is difficult because Spacewire does not have a defined mechanism to communicate with the higher layers of the protocol stack. This has forced users of Spacewire to define unique packet formats and define how these packets are to be processed. Each mission writes their own Interface Control Document (ICD) and tailors Spacewire for their specific requirements making reuse difficult. Part of the reason for this habit may be because engineers typically optimize designs for their own requirements in the absence of a standard. This is an inefficient use of project resources and costs more to develop missions. A new packet format for Spacewire has been defined as a solution for this problem. This new packet format is a compliment to the Spacewire standard that will support protocol development upon Spacewire. The new packet definition does not replace the current packet structure, i.e., does not make the standard obsolete, but merely extends the standard for those who want to develop protocols over Spacewire. The Spacewire packet is defined with the first part being the Destination Address, which may be one or more bytes. This is followed by the packet cargo, which is user defined. The cargo is truncated with an End-Of-Packet (EOP) marker. This packet structure offers low packet overhead and allows the user to define how the contents are to be formatted. It also provides for many different addressing schemes, which provide flexibility in the system. This packet flexibility is typically an attractive part of the Spacewire. The new extended packet format adds one new field to the packet that greatly enhances the capability of Spacewire. This new field called the Protocol Identifier (ID) is used to identify the packet contents and the associated processing for the packet. This feature along with the restriction in the packet format that uses the Protocol ID, allows a deterministic method of decoding packets that was not before possible. The first part of the packet is still the Destination Address, which still conforms to the original standard but with one restriction. The restriction is that the first byte seen at the destination by the user needs to be a logical address, independent of the addressing scheme used. The second field is defined as the Protocol ID, which is usually one byte in length. The packet cargo (user defined) follows the Protocol ID. After the packet cargo is the EOP, which defines the end of packet. The value of the Protocol ID is assigned by the Spacewire working group and the protocol description published for others to use. The development of Protocols for Spacewire is currently the area of greatest activity by the Spacewire working group. The first protocol definition by the working group has been completed and is now in the process of formal standardization. There are many other protocols in development for missions that have not yet received formal Protocol ID assignment, but even if the protocols are not formally assigned a value, this effort will provide synergism for future developments.

Rakow, Glenn↗

Landsat Pathfinder tropical forest information management system

A Tropical Forest Information Management System_(TFIMS) has been designed to fulfill the needs of HTFIP in such a way that it tracks all aspects of the generation and analysis of the raw satellite data and the derived deforestation dataset. The system is broken down into four components: satellite image selection, processing, data management and archive management. However, as we began to think of how the TFIMS could also be used to make the data readily accessible to all user communities we realized that the initial system was too project oriented and could only be accessed locally. The new system needed development in the areas of data ingest and storage, while at the same time being implemented on a server environment with a network interface accessible via Internet. This paper summarizes the overall design of the existing prototype (version 0) information management system and then presents the design of the new system (version 1). The development of version 1 of the TFIMS is ongoing. There are no current plans for a gradual transition from version 0 to version 1 because the significant changes are in how the data within the HTFIP will be made accessible to the extended community of scientists, policy makers, educators, and students and not in the functionality of the basic system.

Salas, W.↗

User Interface Developed for Controls/CFD Interdisciplinary Research

The NASA Lewis Research Center, in conjunction with the University of Akron, is developing analytical methods and software tools to create a cross-discipline "bridge" between controls and computational fluid dynamics (CFD) technologies. Traditionally, the controls analyst has used simulations based on large lumping techniques to generate low-order linear models convenient for designing propulsion system controls. For complex, high-speed vehicles such as the High Speed Civil Transport (HSCT), simulations based on CFD methods are required to capture the relevant flow physics. The use of CFD should also help reduce the development time and costs associated with experimentally tuning the control system. The initial application for this research is the High Speed Civil Transport inlet control problem. A major aspect of this research is the development of a controls/CFD interface for non-CFD experts, to facilitate the interactive operation of CFD simulations and the extraction of reduced-order, time-accurate models from CFD results. A distributed computing approach for implementing the interface is being explored. Software being developed as part of the Integrated CFD and Experiments (ICE) project provides the basis for the operating environment, including run-time displays and information (data base) management. Message-passing software is used to communicate between the ICE system and the CFD simulation, which can reside on distributed, parallel computing systems. Initially, the one-dimensional Large-Perturbation Inlet (LAPIN) code is being used to simulate a High Speed Civil Transport type inlet. LAPIN can model real supersonic inlet features, including bleeds, bypasses, and variable geometry, such as translating or variable-ramp-angle centerbodies. Work is in progress to use parallel versions of the multidimensional NPARC code.

Source record↗

A document describing shuttle considerations for the design of large space structures

A Shuttle user guide document to aid designers and analysis associated with large space structures projects is described. The format and contents are a compromise designed to satisfy the needs of several levels of users. Special features include checklists and references to source documents as a convenience to very knowledgeable readers. In addition, general, introductory and explanatory text, and art work are included for the reader less familiar with shuttle systems. Also, there are a subject index, glossary, list of acronyms, and many cross references. Throughout the document, there are suggested implications or references to the importance of the included orbiter interfaces material as it pertains to designing and planning large space structures projects. The content of the document is outlined. Shuttle payload accommodations and constraints, connections for orbiter construction fixtures, packaging, and construction space eometry are addressed.

Roebuck, J. A., Jr.↗

A generic interface between COSMIC/NASTRAN and PATRAN (R)

Despite its powerful analytical capabilities, COSMIC/NASTRAN lacks adequate post-processing adroitness. PATRAN, on the other hand is widely accepted for its graphical capabilities. A nonproprietary, public domain code mnemonically titled CPI (for COSMIC/NASTRAN-PATRAN Interface) is designed to manipulate a large number of files rapidly and efficiently between the two parent codes. In addition to PATRAN's results file preparation, CPI also prepares PATRAN's P/PLOT data files for xy plotting. The user is prompted for necessary information during an interactive session. Current implementation supports NASTRAN's displacement approach including the following rigid formats: (1) static analysis, (2) normal modal analysis, (3) direct transient response, and (4) modal transient response. A wide variety of data blocks are also supported. Error trapping is given special consideration. A sample session with CPI illustrates its simplicity and ease of use.

Roschke, Paul N.↗

Intelligent Tutoring Systems for Procedural Task Training of Remote Payload Operations at NASA

Intelligent Tutoring Systems (ITSs) encode and apply the subject matter and teaching expertise of experienced instructors to provide students with individualized instruction automatically. ITSs complement training simulators by providing automated instruction when it is not economical or feasible to dedicate an instructor to each student during training simulations. Despite their proven training effectiveness and favorable operating cost, however, relatively few ITSs are in use. This is largely because it is usually costly and difficult to encode the task knowledge used by the ITS to evaluate the student's actions and assess the student's performance. Procedural tasks are tasks for which there exist procedures, guidelines, and strategies that determine the correct set of steps to be taken within each situation. To lower the cost and difficulty of creating tutoring systems for procedural task training, Stottler Henke Associates, Inc. (SHAI) worked closely with the Operations Training Group at NASA's Marshall Space Flight Center to develop the Task Tutor Toolkit (T (exp 3)), a generic tutoring system shell and scenario authoring tool. The Task Tutor Toolkit employs a case-based reasoning approach where the instructor creates a procedure template that specifies the range of student actions that are "correct" within each scenario. Because each procedure template is specific to a single scenario, the system can employ relatively simple reasoning methods to represent a correct set of actions and assess student performance. This simplicity enables a non-programmer to specify task knowledge quickly and easily by via graphical user interface, using a "demonstrate, generalize, and annotate" paradigm, that recognizes the range of possible valid actions and infers principles understood (or misunderstood) by the student when those actions are carried out. The Task Tutor Toolkit was also designed to be modular and general, so that it can be interfaced with a wide range of training simulators and support a variety of training domains. SHAI and NASA applied the Task Tutor Toolkit to create the Remote Payload Operations Tutor (RPOT). RPOT is a specific tutoring system application which lets scientists who are new to space mission operations learn to monitor and control their experiments aboard the International Space Station according to NASA payload regulations, guidelines, and procedures. The RPOT simulator lets students practice these skills by monitoring the telemetry variable values of a simple, hypothetical experiment, sending commands to the experiment, coordinating with NASA personnel via voice communication loops, and submitting and retrieving information via documents and forms. At the end of each scenario, RPOT displays the principles correctly or incorrectly demonstrated by the student, along with explanations and background information. The effectiveness of RPOT and the Task Tutor Toolkit are currently under evaluation at NASA.

Ong, James↗

A Visual Editor in Java for View

In this project we continued the development of a visual editor in the Java programming language to create screens on which to display real-time data. The data comes from the numerous systems monitoring the operation of the space shuttle while on the ground and in space, and from the many tests of subsystems. The data can be displayed on any computer platform running a Java-enabled World Wide Web (WWW) browser and connected to the Internet. Previously a special-purpose program bad been written to display data on emulations of character-based display screens used for many years at NASA. The goal now is to display bit-mapped screens created by a visual editor. We report here on the visual editor that creates the display screens. This project continues the work we bad done previously. Previously we had followed the design of the 'beanbox,' a prototype visual editor created by Sun Microsystems. We abandoned this approach and implemented a prototype using a more direct approach. In addition, our prototype is based on newly released Java 2 graphical user interface (GUI) libraries. The result has been a visually more appealing appearance and a more robust application.

Stansifer, Ryan↗

Displaying and Analyzing Antenna Radiation Patterns

Radiant Energy Display and Analysis Software Package (REDAP) is a computer program for processing antenna-radiation- pattern data that have been preprocessed by a data-collection program and stored in a spherical-coordinate format. REDAP is designed specifically for application to data generated in testing of antennas in an anechoic chamber at Johnson Space Center; parts of REDAP may be reusable for processing antenna-test data collected elsewhere. REDAP provides a graphical user interface (GUI) and executes mathematical and plotting routines on a personal computer.

Siekierski, Jim↗

SSC Engineering Analysis

A package for the automation of the Engineering Analysis (EA) process at the Stennis Space Center has been customized. It provides the ability to assign and track analysis tasks electronically, and electronically route a task for approval. It now provides a mechanism to keep these analyses under configuration management. It also allows the analysis to be stored and linked to the engineering data that is needed to perform the analysis (drawings, etc.). PTC s (Parametric Technology Corp o ration) Windchill product was customized to allow the EA to be created, routed, and maintained under configuration management. Using Infoengine Tasks, JSP (JavaServer Pages), Javascript, a user interface was created within the Windchill product that allows users to create EAs. Not only does this interface allow users to create and track EAs, but it plugs directly into the out-ofthe- box ability to associate these analyses with other relevant engineering data such as drawings. Also, using the Windchill workflow tool, the Design and Data Management System (DDMS) team created an electronic routing process based on the manual/informal approval process. The team also added the ability for users to notify and track notifications to individuals about the EA. Prior to the Engineering Analysis creation, there was no electronic way of creating and tracking these analyses. There was also a feature that was added that would allow users to track/log e-mail notifications of the EA.

Ryan, Harry↗

Machine Learning-Based Atmospheric Phenomena Detection Platform

As the number of Earth pointing satellites has increased over the last several decades, the data volume retrieved from instruments onboard these satellites has also increased. It is expected that this trend will continue as more data intensive missions and small satellite constellations are launched. Currently, feature detection - namely atmospheric phenomena - in these datasets is performed manually and is thus not scalable with the growing data archives. Recent advancements in computational efficiency allow for the Earth science community to leverage machine learning to identify interesting atmospheric phenomena. Given the wide range of distinctive features in various atmospheric phenomena, a specialized machine learning model is required for accurate detection of these phenomena independently. The Phenomena Portal, developed at NASA IMPACT, is designed to provide visualization for the output from these machine learning models. In addition, detected events for each atmospheric phenomena are stored in a database that can be used to more easily use/subset larger spatiotemporal datasets. The user interface also incorporates additional features to enhance the user experience including spatiotemporal analysis, multiple base layer images, and a slider to filter events with lower probabilities of positive detection. Each detection supports user feedback on whether the detection is true or false that can then be stored and used to improve the machine learning model performance.

Gurung, Iksha↗

Generation-based Evolutionary Tool for the Optimization of Constellations (GenETOC)

With the rapid growth in the capabilities of smaller satellites, satellite architectures that replace a single, extremely capable spacecraft with multiple, cheaper ones are gaining in popularity. Unfortunately, the orbit design process for constellations can be significantly more involved, especiallywhen the relative placement of the individual spacecraft within the constellation is not constrained by mission and/or science objectives. Optimizing a satellite constellation in the presence of multiple, competing objectives is a highly complex problem to which many traditional mathematical optimization methods cannot be applied and few tools exist to help mission designers search for promising candidate mission designs. The Generation-based Evolutionary Tool for the Optimization of Constellations (GenETOC) has been created to search for near-optimal constellation design options. GenETOC combines a modified version of the Non-dominated Sorting Genetic Algorithm II (NSGA II) with STK Components libraries (a 3rdparty .NET package created by Analytical Graphics Inc.) to create a framework that enables a mission designer to generate a simulation that models the design problem and obtain a family of potential, near-optimal solutions that can be investigated more in detail. GenETOC was developed in C# using the .NET framework with Windows Presentation Foundation (WPF) serving as the framework from which to create the graphical user interface (GUI). GenETOC user inputs can be categorized into three major data components: definition of the problem (areas of interest, satellite decision parameters, and sensor configurations), definition of performance objectives, and specification of the genetic algorithm (GA) parameters. In the problem definition component, the user is prompted to define the areas of interest against which the performance metrics will be computed, define the sensor parameters and attach them to specific spacecraft, select which satellite orbital parameters will be added to the decision space of the GA, and specify the range of desired values for each optimization parameter. For performance objectives, the user is presented with a list of available coverage and revisit performance based calculation options from which two metrics are chosen to serve as the objective functions that the GA will use to evaluate solutions during the optimization process. Finally, the definition of the GA parameters provides user control over the number of generations (number of optimization iterations), the population size (number of candidate constellations created in each generation), and the adaptive mutation and crossover threshold values (control parameters for how frequently each process occurs during the optimization). GenETOC has been extensively tested to verify the individual components of the optimization process. The GA has been tested against a suite of GA test problems to confirm convergence to the known two and three-dimensional Pareto fronts. The coverage and revisit performance metrics obtained in GenETOC are compared with STK desktop scenarios, confirming the constellations are being appropriately modeled within GenETOC simulations. A walkthrough of a simple, example problem is provided to illustrate the workings of GenETOC and to demonstrate the output available to the mission designer.

mission design↗

Understanding the International Space Station Crew Perspective following Long-Duration Missions through Data Analytics & Visualization of Crew Feedback

The International Space Station (ISS) first became a home and research laboratory for NASA and International Partner crewmembers over 16 years ago. Each ISS mission lasts approximately 6 months and consists of three to six crewmembers. After returning to Earth, most crewmembers participate in an extensive series of 30+ debriefs intended to further understand life onboard ISS and allow crews to reflect on their experiences. Examples of debrief data collected include ISS crew feedback about sleep, dining, payload science, scheduling and time planning, health & safety, and maintenance. The Flight Crew Integration (FCI) Operational Habitability (OpsHab) team, based at Johnson Space Center (JSC), is a small group of Human Factors engineers and one stenographer that has worked collaboratively with the NASA Astronaut office and ISS Program to collect, maintain, disseminate and analyze this data. The database provides an exceptional and unique resource for understanding the "crew perspective" on long duration space missions. Data is formatted and categorized to allow for ease of search, reporting, and ultimately trending, in order to understand lessons learned, recurring issues and efficiencies gained over time. Recently, the FCI OpsHab team began collaborating with the NASA JSC Knowledge Management team to provide analytical analysis and visualization of these over 75,000 crew comments in order to better ascertain the crew's perspective on long duration spaceflight and gain insight on changes over time. In this initial phase of study, a text mining framework was used to cluster similar comments and develop measures of similarity useful for identifying relevant topics affecting crew health or performance, locating similar comments when a particular issue or item of operational interest is identified, and providing search capabilities to identify information pertinent to future spaceflight systems and processes for things like procedure development and training. In addition, the comments were scored for sentiment using a polarity scoring algorithm to identify both positive and negative comments for particular groups and clusters, allowing the team to make analytically informed decisions regarding future hardware and operating procedures. The use of polarity scoring with time series analysis was used to provide insight into how crew health and habitability is changing throughout various spaceflight increments or the station lifecycle as a whole. Finally, a visualization framework was developed to address the needs of the end users to search for and analyze comments by user, category or mission. This paper will discuss how the use of an analytical framework in conjunction with the current human interface, improved the understanding of crew perspective and shortened the time for analysis allowing for more informed decisions and rapid development of improvements. These methods are significantly optimizing the way that this valuable data can be assessed and applied to current and future spaceflight design and development. This collaboration allows the FCI OpsHab team to effectively analyze and share data in a more automated and timely fashion. Trends are no longer derived manually and can be illustrated effectively and accurately with these evolving techniques to an ever growing group of human spaceflight end users.

Bryant, Cody↗

Advanced Technology Lifecycle Analysis System (ATLAS)

Developing credible mass and cost estimates for space exploration and development architectures require multidisciplinary analysis based on physics calculations, and parametric estimates derived from historical systems. Within the National Aeronautics and Space Administration (NASA), concurrent engineering environment (CEE) activities integrate discipline oriented analysis tools through a computer network and accumulate the results of a multidisciplinary analysis team via a centralized database or spreadsheet Each minute of a design and analysis study within a concurrent engineering environment is expensive due the size of the team and supporting equipment The Advanced Technology Lifecycle Analysis System (ATLAS) reduces the cost of architecture analysis by capturing the knowledge of discipline experts into system oriented spreadsheet models. A framework with a user interface presents a library of system models to an architecture analyst. The analyst selects models of launchers, in-space transportation systems, and excursion vehicles, as well as space and surface infrastructure such as propellant depots, habitats, and solar power satellites. After assembling the architecture from the selected models, the analyst can create a campaign comprised of missions spanning several years. The ATLAS controller passes analyst specified parameters to the models and data among the models. An integrator workbook calls a history based parametric analysis cost model to determine the costs. Also, the integrator estimates the flight rates, launched masses, and architecture benefits over the years of the campaign. An accumulator workbook presents the analytical results in a series of bar graphs. In no way does ATLAS compete with a CEE; instead, ATLAS complements a CEE by ensuring that the time of the experts is well spent Using ATLAS, an architecture analyst can perform technology sensitivity analysis, study many scenarios, and see the impact of design decisions. When the analyst is satisfied with the system configurations, technology portfolios, and deployment strategies, he or she can present the concepts to a team, which will conduct a detailed, discipline-oriented analysis within a CEE. An analog to this approach is the music industry where a songwriter creates the lyrics and music before entering a recording studio.

O'Neil, Daniel A.↗

Design strategies and functionality of the Visual Interface for Virtual Interaction Development (VIVID) tool

Development of interactive virtual environments (VE) has typically consisted of three primary activities: model (object) development, model relationship tree development, and environment behavior definition and coding. The model and relationship tree development activities are accomplished with a variety of well-established graphic library (GL) based programs - most utilizing graphical user interfaces (GUI) with point-and-click interactions. Because of this GUI format, little programming expertise on the part of the developer is necessary to create the 3D graphical models or to establish interrelationships between the models. However, the third VE development activity, environment behavior definition and coding, has generally required the greatest amount of time and programmer expertise. Behaviors, characteristics, and interactions between objects and the user within a VE must be defined via command line C coding prior to rendering the environment scenes. In an effort to simplify this environment behavior definition phase for non-programmers, and to provide easy access to model and tree tools, a graphical interface and development tool has been created. The principal thrust of this research is to effect rapid development and prototyping of virtual environments. This presentation will discuss the 'Visual Interface for Virtual Interaction Development' (VIVID) tool; an X-Windows based system employing drop-down menus for user selection of program access, models, and trees, behavior editing, and code generation. Examples of these selection will be highlighted in this presentation, as will the currently available program interfaces. The functionality of this tool allows non-programming users access to all facets of VE development while providing experienced programmers with a collection of pre-coded behaviors. In conjunction with its existing, interfaces and predefined suite of behaviors, future development plans for VIVID will be described. These include incorporation of dual user virtual environment enhancements, tool expansion, and additional behaviors.

Nguyen, Lac↗

The automated strength-aeroelastic design of aerospace structures program

An ongoing program whose goal is to develop an automated procedure that can assist in the preliminary design of aircraft and space structures is described. The approach and capabilities that are to be included in the final procedures are descussed. By using proven engineering software as a basis for the project, a reliable and interdisciplinary procedure is developed. The use of a control language for module sequencing and execution permits efficient development of the procedure and gives the user significant flexibility in altering or enhancing the procedure. The data base system provides reliable and efficient access to the large amounts of interrelated data required in an enterprise of this sort. In addition, the data base allows interfacing with existing pre- and post-processors in an almost trivial manner. Altogether, the procedure promises to be of considerable utility to preliminary structural design teams.

Johnson, E. H.↗

A programing system for research and applications in structural optimization

The flexibility necessary for such diverse utilizations is achieved by combining, in a modular manner, a state-of-the-art optimization program, a production level structural analysis program, and user supplied and problem dependent interface programs. Standard utility capabilities in modern computer operating systems are used to integrate these programs. This approach results in flexibility of the optimization procedure organization and versatility in the formulation of constraints and design variables. Features shown in numerical examples include: variability of structural layout and overall shape geometry, static strength and stiffness constraints, local buckling failure, and vibration constraints.

Sobieszczanski-Sobieski, J.↗

Array structure design handbook for stand alone photovoltaic applications

This handbook will permit the user to design a low-cost structure for a variety of photovoltaic system applications under 10 kW. Any presently commercially available photovoltaic modules may be used. Design alternatives are provided for different generic structure types, structural materials, and electric interfaces. The use of a hand-held calculator is sufficient to perform the necessary calculations for the array designs.

Didelot, R. C.↗

RIM as an implementation tool for a distributed heterogeneous database

The another distributed database system (ADDS) prototype supports interactive, d hoc retrieval from several of the Amoco/Standard DHDBMS. The ADDS conceptual design, the usage of RIM in several components of ADDS, and some enhancements ot RIM that were used by the developers of the ADDS prototype are outlined. Topics covered include: (1) ADDS Overview; (2) composite database dictionary/directory; (3) user interface and user profiles; (4) subrequest execution; (5) merger/formatter; and (6) a transportable implamentation.

Breitbart, Y. J.↗