Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “implementation decisions”

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 19 records
All sourcesNASA NTRSDOE OSTI
NASA NTRS2014

Ground Delay Program Analytics with Behavioral Cloning and Inverse Reinforcement Learning

We used historical data to build two types of model that predict Ground Delay Program implementation decisions and also produce insights into how and why those decisions are made. More specifically, we built behavioral cloning and inverse reinforcement learning models that predict hourly Ground Delay Program implementation at Newark Liberty International and San Francisco International airports. Data available to the models include actual and scheduled air traffic metrics and observed and forecasted weather conditions. We found that the random forest behavioral cloning models we developed are substantially better at predicting hourly Ground Delay Program implementation for these airports than the inverse reinforcement learning models we developed. However, all of the models struggle to predict the initialization and cancellation of Ground Delay Programs. We also investigated the structure of the models in order to gain insights into Ground Delay Program implementation decision making. Notably, characteristics of both types of model suggest that GDP implementation decisions are more tactical than strategic: they are made primarily based on conditions now or conditions anticipated in only the next couple of hours.

Bloem, Michael↗
NASA NTRS2013

Flight Deck Weather Avoidance Decision Support: Implementation and Evaluation

Weather related disruptions account for seventy percent of the delays in the National Airspace System (NAS). A key component in the weather plan of the Next Generation of Air Transportation System (NextGen) is to assimilate observed weather information and probabilistic forecasts into the decision process of flight crews and air traffic controllers. In this research we explore supporting flight crew weather decision making through the development of a flight deck predicted weather display system that utilizes weather predictions generated by ground-based radar. This system integrates and presents this weather information, together with in-flight trajectory modification tools, within a cockpit display of traffic information (CDTI) prototype. that the CDTI features 2D and perspective 3D visualization models of weather. The weather forecast products that we implemented were the Corridor Integrated Weather System (CIWS) and the Convective Weather Avoidance Model (CWAM), both developed by MIT Lincoln Lab. We evaluated the use of CIWS and CWAM for flight deck weather avoidance in two part-task experiments. Experiment 1 compared pilots' en route weather avoidance performance in four weather information conditions that differed in the type and amount of predicted forecast (CIWS current weather only, CIWS current and historical weather, CIWS current and forecast weather, CIWS current and forecast weather and CWAM predictions). Experiment 2 compared the use of perspective 3D and 21/2D presentations of weather for flight deck weather avoidance. Results showed that pilots could take advantage of longer range predicted weather forecasts in performing en route weather avoidance but more research will be needed to determine what combinations of information are optimal and how best to present them.

CWAM↗
NASA NTRS1989

TAE Plus: Transportable Applications Environment Plus tools for building graphic-oriented applications

The Transportable Applications Environment Plus (TAE Plus), developed by NASA's Goddard Space Flight Center, is a portable User Interface Management System (UIMS), which provides an intuitive WYSIWYG WorkBench for prototyping and designing an application's user interface, integrated with tools for efficiently implementing the designed user interface and effective management of the user interface during an application's active domain. During the development of TAE Plus, many design and implementation decisions were based on the state-of-the-art within graphics workstations, windowing system and object-oriented programming languages. Some of the problems and issues experienced during implementation are discussed. A description of the next development steps planned for TAE Plus is also given.

Szczur, Martha R.↗
NASA NTRS1981

An investigation into pilot and system response to critical in-flight events. Volume 1: Executive summary

Critical in-flight events (CIFE) that threaten the aircraft were studied. The scope of the CIFE was described and defined with emphasis on characterizing event development, detection and assessment; pilot information requirements, sources, acquisition, and interpretation, pilot response options, decision processed, and decision implementation and event outcome. Detailed scenarios were developed for use in simulators and paper and pencil testing for developing relationships between pilot performance and background information as well as for an analysis of pilot reaction decision and feedback processes. Statistical relationships among pilot characteristics and observed responses to CIFE's were developed.

Rockwell, T. H.↗
NASA NTRS1990

The implementation of POSTGRES

The design and implementation decisions made for the three-dimensional data manager POSTGRES are discussed. Attention is restricted to the DBMS backend functions. The POSTGRES data model and query language, the rules system, the storage system, the POSTGRES implementation, and the current status and performance are discussed.

Stonebraker, Michael↗
NASA NTRS1987

Space station evolution: Planning for the future

The need for permanently manned presence in space has been recognized by the United States and its international partners for many years. The development of this capability was delayed due to the concurrent recognition that reusable earth-to-orbit transportation was also needed and should be developed first. While the decision to go ahead with a permanently manned Space Station was on hold, requirements for the use of the Station were accumulating as ground-based research and the data from unmanned spacecraft sparked the imagination of both scientists and entrepreneurs. Thus, by the time of the Space Station implementation decision in the early 1980's, a variety of disciplines, with a variety of requirements, needed to be accommodated on one Space Station. Additional future requirements could be forecast for advanced missions that were still in the early planning stages. The logical response was the development of a multi-purpose Space Station with the ability to evolve on-orbit to new capabilities as required by user needs and national or international decisions, i.e., to build an evolutionary Space Station. Planning for evolution is conducted in parallel with the design and development of the baseline Space Station. Evolution planning is a strategic management process to facilitate change and protect future decisions. The objective is not to forecast the future, but to understand the future options and the implications of these on today's decisions. The major actions required now are: (1) the incorporation of evolution provisions (hooks and scars) in the baseline Space Station; and (2) the initiation of an evolution advanced development program.

Diaz, Alphonso V.↗
NASA NTRS2016

Exploring the Science Trade Space with the JPL Innovation Foundry A-Team

The JPL Innovation Foundry has established a new approach for exploring, developing, and evaluating early concepts with a group called the Architecture Team (A-Team). The A-Team combines innovative collaborative methods and facilitated sessions with subject matter experts and analysis tools to help mature mission concepts. Science, implementation, and programmatic elements are all considered during an ATeam study. In these studies, Concept Maturity Levels (CML) are used to group methods. These levels include idea generation and capture (CML 1), initial feasibility assessment (CML 2), and trade space exploration (CML 3). Methods used for exploring the science objectives, feasibility, and scope will be described including use of a new technique for understanding the most compelling science, called a Science Return Diagram (SRD). In the process of developing the SRD, gradients in the science trade space are uncovered along with their implications for implementation and mission architecture. Special attention is paid towards developing complete investigations, establishing a series of logical claims that lead to the natural selection of a measurement approach. Over 20 science-focused A-Team studies have used these techniques to help science teams refine their mission objectives, make implementation decisions and reveal the mission concept’s most compelling science. This paper will describe the A-Team process for exploring the mission concept's science trade space and the Science Return Diagram technique.In June of 2011 a new collaborative engineering approach forearly concept formulation began in the JPL InnovationFoundry [1], six months later becoming the “A-Team” [2].Responding to a need for exploring mission architecturelevel trades [3], the A-Team precedes Team X [4,5] in asequence of concurrent engineering teams at JPL that can beused to mature a concept from a “cocktail napkin” level ideato a complete mission point design. The A-Team efficientlyexplores the science, implementation, and programmatictrade space in early concept formulation. Small, facilitatedgroups of experts generate innovative ideas, quantitativelyassess feasibility, and discover key sensitivities in the tradespace through collaborative analysis and use of advancedmethods and tools. The A-Team process builds off theexperience within JPL and other recent approaches to earlyconcept formulation [6] including best practices of the JPLInnovation Foundry, Project Systems Engineering &Formulation Section, Team Eureka and the Rapid MissionArchitecture Team[7].The A-Team is a focal point for innovative formulationapproaches and people within JPL. It relies on a largebackground of study resources, creative thinkers and “greybeard” scrutinizers, advanced tools, and subject matterexperts with both breadth and depth in experience andexpertise that are all available at JPL. The A-Team isdesigned to be a rapid and efficient process takingapproximately 6 weeks (the entire process can be as short asjust a few days or as long as up to three months) and costingthe equivalent of a work-month of a full-time employee orless. Studies begin with detailed planning and client reviewfollowed by study sessions, analysis work, and reporting.The staffing on each study is customized to the study goalsand objectives, and it is addressed early in the A-Teamprocess. Sessions are generally half-day or whole-day eventsand conducted over a series of days with focused agendas thatare moderated by a trained facilitator. Preliminary results andknowledge capture are available within hours of each session,and a final report is generally available two weeks later.One of the biggest challenges facing early conceptdevelopment is understanding the gradient in science returnversus various available mission scenarios and payload options. Often times, major areas of scientific inquiry havealready been prioritized by science groups, including throughthe National Research Council’s Decadal Studies inAstronomy, Planetary, and Earth Science. Yet science teamscontinue to struggle, especially in competitive missionsolicitations, to capture the right amount of scope that’sachievable within the cost constraints of the opportunity.Often the desire to completely and comprehensively study ascience area in just one mission (after all, true missionopportunities are rare) drives teams to take on too much,providing requirements that are unachievable within theresources of the opportunity without inducing unacceptableimplementation risk. Alternatively, science teams can seekto reduce risk by using an established instrument, but havenot thought through the traceability and key aspects of thescience question to justify its use. Both scenarios lead to badassumptions at the beginning of the concept development thatcan then ripple through implementation option choices,potentially preventing what would have been a good scienceinvestigation from being selected.The purpose of this paper is first to provide some additionalbackground and summary of the A-Team process, tools,people, and facilities. We then focus on the A-Teammethodology for overcoming the barriers of defining thescience scope well at the early concept development stage.This includes understanding the science story andtraceability, and then examining the gradient in science returnversus key characteristics of observables, developing theright payload and mission requirement specification throughexamining the science and implementation trade space.

Ziemer, John K.↗
NASA NTRS1977

Fast arithmetic in MacLISP

MacLISP provides a compiler which produces numerical code competitive in speed with some FORTRAN implementations and yet compatible with the rest of the MacLISP system. All numerical programs can be run under the MacLISP interpreter. Additional declarations to the compiler specify type information which allows the generation of optimized numerical code which generally does not require the garbage collection of temporary numerical results. Array accesses are almost as fast as in FORTRAN, and permit the use of dynamically allocated arrays of varying dimensions. The implementation decisions regarding user interface, data representations, and interfacing conventions are discussed which allow the generation of fast numerical LISP code.

Steele, G. L., Jr.↗
NASA NTRS1977

Evaluating the benefits of government funded R & D aimed at the private sector

Federal funding of technological research and development is discussed with regard to the procedures for an economic analysis with the goals of (1) determining when the public sector should invest in a research and development program, (2) evaluating the likelihood of private sector participation in terms of public sector participation, and (3) considering the major factors in the formulation of a research and development program in terms of defining initiatives. Public sector investments are evaluated, noting procedures for determining whether benefits exceed costs. The role of the public sector research and development planning is described, considering the procedure for private sector implementation decisions and a methodology for evaluating the possibility of private sector commercialization. The economic value of the public sector research and development program is presented with attention given to a specific case of NASA-sponsored research and development aimed toward the commercialization of new public communications services.

Greenberg, J. S.↗
NASA NTRS1991

Parallel processing and expert systems

Whether it be monitoring the thermal subsystem of Space Station Freedom, or controlling the navigation of the autonomous rover on Mars, NASA missions in the 1990s cannot enjoy an increased level of autonomy without the efficient implementation of expert systems. Merely increasing the computational speed of uniprocessors may not be able to guarantee that real-time demands are met for larger systems. Speedup via parallel processing must be pursued alongside the optimization of sequential implementations. Prototypes of parallel expert systems have been built at universities and industrial laboratories in the U.S. and Japan. The state-of-the-art research in progress related to parallel execution of expert systems is surveyed. The survey discusses multiprocessors for expert systems, parallel languages for symbolic computations, and mapping expert systems to multiprocessors. Results to date indicate that the parallelism achieved for these systems is small. The main reasons are (1) the body of knowledge applicable in any given situation and the amount of computation executed by each rule firing are small, (2) dividing the problem solving process into relatively independent partitions is difficult, and (3) implementation decisions that enable expert systems to be incrementally refined hamper compile-time optimization. In order to obtain greater speedups, data parallelism and application parallelism must be exploited.

Lau, Sonie↗
NASA NTRS1993

Design of a cooperative problem-solving system for enroute flight planning: An empirical study of its use by airline dispatchers

In a previous report, an empirical study of 30 pilots using the Flight Planning Testbed was reported. An identical experiment using the Flight Planning Testbed (FPT), except that 27 airline dispatchers were studied, is described. Five general questions were addressed in this study: (1) under what circumstances do the introduction of computer-generated suggestions (flight plans) influence the planning behavior of dispatchers (either in a beneficial or adverse manner); (2) what is the nature of such influences (i.e., how are the person's cognitive processes changed); (3) how beneficial are the general design concepts underlying FPT (use of a graphical interface, embedding graphics in a spreadsheet, etc.); (4) how effective are the specific implementation decisions made in realizing these general design concepts; and (5) how effectively do dispatchers evaluate situations requiring replanning, and how effectively do they identify appropriate solutions to these situations.

Smith, Philip J.↗
NASA NTRS1993

Mass storage system reference model, Version 4

The high-level abstractions that underlie modern storage systems are identified. The information to generate the model was collected from major practitioners who have built and operated large storage facilities, and represents a distillation of the wisdom they have acquired over the years. The model provides a common terminology and set of concepts to allow existing systems to be examined and new systems to be discussed and built. It is intended that the model and the interfaces identified from it will allow and encourage vendors to develop mutually-compatible storage components that can be combined to form integrated storage systems and services. The reference model presents an abstract view of the concepts and organization of storage systems. From this abstraction will come the identification of the interfaces and modules that will be used in IEEE storage system standards. The model is not yet suitable as a standard; it does not contain implementation decisions, such as how abstract objects should be broken up into software modules or how software modules should be mapped to hosts; it does not give policy specifications, such as when files should be migrated; does not describe how the abstract objects should be used or connected; and does not refer to specific hardware components. In particular, it does not fully specify the interfaces.

Coleman, Sam↗
NASA NTRS1993

Hurricane risk assessment: Rollback or ride out

Winds in excess of 74.5 knots could cause severe damage to a space shuttle on the launch pad. Current plans exist for rollback to the Vehicle Assembly Building, but require 48 hour leadtime to implement. Decisions based upon cost/loss are evaluated to ascertain whether predetermined forecast probabilities for rollback/rideout decisions can be made far in advance of hurricane seasons for use in decision making.

Wohlman, Richard A.↗
NASA NTRS1993

An empirical evaulation of computerized tools to aid in enroute flight planning

The paper describes an experiment using the Flight Planning Testbed (FPT) in which 27 airline dispatchers were studied. Five general questions was addresses in the study: Under what circumstances does the introduction of computer-generated suggestions (flight plans) influence the planning behavior of dispatchers; what is the nature of such influences; How beneficial are the general design concepts underlying FPT; How effective are the specific implementation decisions made in realizing these general design concepts; How effectively do dispatchers evaluate situations requiring replanning and how effectively do they identify appropriate solutions to these situations. The study leaves little doubt that the introduction of computer-generated suggestions for solving a flight planning problem can have a marked impact on the cognitive processes of the user and on the ultimate plan selected.

Smith, Philip J.↗
NASA NTRS1997

An Approach to Building a Traceability Tool for Software Development

It is difficult in a large, complex computer program to ensure that it meets the specified requirements. As the program evolves over time, a11 program constraints originally elicited during the requirements phase must be maintained. In addition, during the life cycle of the program, requirements typically change and the program must consistently reflect those changes. Imagine the following scenario. Company X wants to develop a system to automate its assembly line. With such a large system, there are many different stakeholders, e.g., managers, experts such as industrial and mechanical engineers, and end-users. Requirements would be elicited from all of the stake holders involved in the system with each stakeholder contributing their point of view to the requirements. For example, some of the requirements provided by an industrial engineer may concern the movement of parts through the assembly line. A point of view provided by the electrical engineer may be reflected in constraints concerning maximum power usage. End-users may be concerned with comfort and safety issues, whereas managers are concerned with the efficiency of the operation. With so many points of view affecting the requirements, it is difficult to manage them, communicate information to relevant stakeholders. and it is likely that conflicts in the requirements will arise. In the coding process, the implementors will make additional assumptions and interpretations on the design and the requirements of the system. During any stage of development, stakeholders may request that a requirement be added or changed. In such a dynamic environment, it is difficult to guarantee that the system will preserve the current set of requirements. Tracing, the mapping between objects in the artifacts of the system being developed, addresses this issue. Artifacts encompass documents such as the system definition, interview transcripts, memoranda, the software requirements specification, user's manuals, the functional specifications, design reports, and system code. Tracing helps 1) validate system features against, the requirement specification, 2) identify error sources and, most importantly, 3) manage change. With so many people involved in the development of the system, it becomes necessary to identify the reasons behind the design requirements or the implementation decisions. This paper is concerned with an approach that maps documents to constraints that capture properties of and relationships between the objects being modeled by the program. Section 2 provides the reader with a background on traceability tools. Section 3 gives a brief description of the context monitoring system on which the approach suggested in this paper is based. Section 4 presents an overview of our approach to providing traceability. The last section presents our future direction of research.

Delgado, Nelly↗
NASA NTRS2014

SSL Freeform Generator v1.00

The Orion spacecraft utilizes a system of Compact Unique Identifiers (CUIs) to identify telemetry measurements in the process of communicating with the ground. While avionic systems are still in development, simulation of telemetric data must be used for the development of dependent systems. The SuperScript Language (SSL) developed by Honeywell Aerospace provides users a programming language for simulation of this data. The use of tools that provide SSL generation capabilities at a higher level allows for faster and more efficient generation of simulation waveforms. Previous SSL Generator implementations such as Orion Scripted Interface Generator (OrionSIG) relied on software supported routines to generate simulation points for the SSL scripts. This provided relevant simulation capabilities, but was reduced in flexibility by the available software routines available. For this approach, software supported routines have been entirely dropped. Rather, the user is required to enter their own simulation waveform input. This allows arbitrarily complex functions to be utilized simulated with maximum degree of freedom for the user.: The idea for this version of the SSL Generator was a mapping of arbitrary waveforms to Orion CUI telemetry data. The SSL Generator implemented offers a higher degree of freedom to the user than previous versions while attempting to maintain abstraction from the underlying SSL script and the Orion CUI data types. As such, many mappings of waveforms to CUIs will simply not work. Certain implementation decisions were made to minimize the damage caused by these unintended side-effects, such as saturation of values exceeding the maximum or minimum bounds of the data type. Other details, such as signed values being represented in unsigned data types, present problems which cant be fixed to an acceptable degree of intended behavior without user input. Awareness of the limitations of all layers of the software stack will increase the productivity of the end-user.

telemetry↗
NASA NTRS2017

Exploring the Science Trade Space with the JPL Innovation Foundry A-Team

The Jet Propulsion Laboratory Innovation Foundry has established a new approach for exploring, developing, and evaluating early concepts with a group called the Architecture Team. The Architecture Team combines innovative collaborative methods and facilitated sessions with subject matter experts and analysis tools to help mature mission concepts. Science, implementation, and programmatic elements are all considered during an A-Team study. In these studies, Concept Maturity Levels are used to group methods. These levels include idea generation and capture (Concept Maturity Level 1), initial feasibility assessment (Concept Maturity Level 2), and trade space exploration (Concept Maturity Level 3). Methods used for exploring the science objectives, feasibility, and scope will be described including the use of a new technique for understanding the most compelling science, called a Science Return Diagram. In the process of developing the Science Return Diagram, gradients in the science trade space are uncovered along with their implications for implementation and mission architecture. Special attention is paid toward developing complete investigations, establishing a series of logical claims that lead to the natural selection of a measurement approach. Over 20 science-focused A-Team studies have used these techniques to help science teams refine their mission objectives, make implementation decisions, and reveal the mission concept's most compelling science. This article will describe the A-Team process for exploring the mission concept's science trade space and the Science Return Diagram technique.

science↗
NASA NTRS1974

A decision and control multi-axis pilot model based on an urgency for action concept

An all digital multiple axis, multiple input, multiple output pilot model flies five different tasks in aircraft of different classes while encountering turbulence represented by the Dryden spectral model. Six degree of freedom linearized aircraft equations of motion are used together with a generalized stability augmentation system. The pilot model consists of two parts: (1) a decision maker, and (2) a control action implementer. This decision maker selects the critical variable and predicts the error at action implementation. The control action implementer decides the magnitude of control to be applied and applies it. This system has been successfully compared with hybrid/analog man in the loop simulations of the F-5, A-7, T-33, and 707 aircraft, thus validating the all digital simulation and the decision and control pilot model.

Pollard, J. J.↗