Search NASA⌕ Search

SEARCH · Search NASA

Results for “Lessons Learned”

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 865 records · Page 48

Shuttle middeck fluid transfer experiment: Lessons learned

This presentation is based on the experience gained from having integrated and flown a shuttle middeck experiment. The experiment, which demonstrated filling, expulsion, and fluid behavior of a liquid storage system under low-gravity conditions, is briefly described. The advantages and disadvantages of middeck payloads compared to other shuttle payload provisions are discussed. A general approach to the integration process is described. The requirements for the shuttle interfaces--such as structures, pressurized systems, materials, instrumentation, and electrical power--are defined and the approach that was used to satisfy these requirements is presented. Currently the middeck experiment is being used as a test bed for the development of various space fluid system components.

Tegart, James↗

Lessons learned from the DC-10 carbon-epoxy rudder program

With the DC-10 carbon-epoxy rudder, the Douglas Aircraft Company achieved one of the greatest percentage weight savings associated with composite structures. Apart from minor damage from lightning strikes, the 15 rudders put into service have experienced virtually trouble-free operation for about a decade. This paper explains why a multirib, postbuckled skin design was used for the DC-10 composite rudder, how it was justified, and how it would have compared with more conventional sandwich design concepts. Special attention is devoted to the reasons why, for such postbuckled designs, it is better to allow the skin to wrinkle and unload itself than to reinforce it and make it resist buckling until some higher load level is attained. With minor changes in the manufacturing technique, this design concept is ideal for the control surfaces on many aircraft. The paper includes suggestions on how to make even better composite control surfaces in the future.

Hart-Smith, L. J.↗

Fallible humans and vulnerable systems - Lessons learned from aviation

It is suggested that the problems being experienced in complex automatic systems are essentially due to the failure of information management and communication. The failure covers the entire spectrum: display devices and techniques, coding information so as to reduce human error, and information economy, i.e., resisting the temptation to bombard the operator with unlimited information simply because the system possesses the capability to do so. Since there has been great progress in hardware engineering, it is suggested that further attention is needed in the 'soft' side of systems. The approach should focus on (1) preventing human cognitive slips and (2) making the systems less vulnerable to such slips when they do occur. Most of the examples are taken from studies of cockpit automation.

Wiener, Earl L.↗

Lessons learned in ground processing scientific and applications payloads at Kennedy Space Center

The payload ground processing of experiments which flew on the Shuttle is examined, including studies of atmosphere and earth observation, life science, advance technology, materials science, plasma physics, astrophysics and solar physics, astronomy, navigation and communication, and fluid mechanics. The process of designing and development payloads, the integration of instruments, carrier interface verification, and late servicing at the launch pad are discussed. The problems of cost, red tape, contamination, safety, and propriety protection are considered.

Elfrey, Priscilla↗

Lessons learned in the transition to ADA from FORTRAN at NASA/Goddard

A case study was done at Goddard Space Flight Center, in which two dynamics satellite simulators are developed from the same requirements, one in Ada and the other in FORTRAN. The purpose of the research was to find out how well the prescriptive Ada development model worked to develop the Ada simulator. The FORTRAN simulator development, as well as past FORTRAN developments, provided a baseline for comparison. Since this was the first simulator developed here, the prescriptive Ada development model had many similarities to the usual FORTRAN development model. However, it was modified to include longer design and shorter testing phases, which is generally expected with Ada development. One surprising result was that the percentage of time the Ada project spent in the various development activities was very similar to the percentage of time spent in these activities when doing a FORTRAN project. Another surprising finding was the difficulty the Ada team had with unit testing as well as with integration. In retrospect it is realized that adding additional steps to the design phase, such as an abstract data type analysis, and certain guidelines to the implementation phase, such as to use primarily library units and nest sparingly, would have made development much easier.

Brophy, Carolyn Elizabeth↗

Lessons learned in the transition to Ada from FORTRAN at NASA/Goddard

Two dynamics satellite simulators are developed from the same requirements, one in Ada and the other in FORTRAN. The purpose of the research was to find out how well the prescriptive Ada development model worked to develop the Ada simulator. The FORTRAN simulator development, as well as past FORTRAN developments, provided a baseline for comparison. Since this was the first simulator developed, the prescriptive Ada development model had many similarities to the usual FORTRAN development model. However, it was modified to include longer design and shorter testing phases, which is generally expected with Ada developments. One result was that the percentage of time the Ada project spent in the various development activities was very similar to the percentage of time spent in these activities when doing a FORTRAN project. Another finding was the difficulty the Ada team had with unit testing as well as with integration. It was realized that adding additional steps to the design phase, such as an abstract data type analysis, and certain guidelines to the implementation phase, such as to use primarily library units and nest sparingly, would have made development easier. These are among the recommendations made to be incorporated in a new Ada development model next time.

Brophy, Carolyn Elizabeth↗

Development of the XV-15 tiltrotor research aircraft - Lessons learned

The initial ground rules that guided the decision process during the initial stages of the XV-15 tiltrotor aircraft development are reviewed and reevaluated. A full flight-envelope nonlinear simulation mathematical model is outlined, along with the advantages of a multiaircraft program. Direct involvement of government engineers in all aspects of the program is considered to be beneficial, while the ejection-seat test requirement is not. Utilization of existing components - a rotor, transmissions, and engines - is analyzed, and emphasis is placed on integrated system test plans responsible for producing two reliable aircraft through a complete checkout of the aircraft subsystems before the start of the fligth program. Wind-tunnel and fatigue test requirements are presented, and the decision to go with an all mechanical control system design is addressed.

Schroers, Laurel G.↗

An expert system prototype for aiding in the development of software functional requirements for NASA Goddard's command management system: A case study and lessons learned

At NASA Goddard, the role of the command management system (CMS) is to transform general requests for spacecraft opeerations into detailed operational plans to be uplinked to the spacecraft. The CMS is part of the NASA Data System which entails the downlink of science and engineering data from NASA near-earth satellites to the user, and the uplink of command and control data to the spacecraft. Presently, it takes one to three years, with meetings once or twice a week, to determine functional requirements for CMS software design. As an alternative approach to the present technique of developing CMS software functional requirements, an expert system prototype was developed to aid in this function. Specifically, the knowledge base was formulated through interactions with domain experts, and was then linked to an existing expert system application generator called 'Knowledge Engineering System (Version 1.3).' Knowledge base development focused on four major steps: (1) develop the problem-oriented attribute hierachy; (2) determine the knowledge management approach; (3) encode the knowledge base; and (4) validate, test, certify, and evaluate the knowledge base and the expert system prototype as a whole. Backcasting was accomplished for validating and testing the expert system prototype. Knowledge refinement, evaluation, and implementation procedures of the expert system prototype were then transacted.

Liebowitz, Jay↗

Lessons learned from an Ada conversion project

Background; SAVVAS architecture; software portability; history of Ada; isolation of non-portable code; simple terminal interface package; constraints of language features; and virtual interfaces are outlined. This presentation is represented by viewgraphs only.

Porter, Tim↗

IVA the robot: Design guidelines and lessons learned from the first space station laboratory manipulation system

The first interactive Space Station Freedom (SSF) lab robot exhibit was installed at the Space and Rocket Center in Huntsville, AL, and has been running daily since. IntraVehicular Activity (IVA) the robot is mounted in a full scale U.S. Lab (USL) mockup to educate the public on possible automation and robotic applications aboard the SSF. Responding to audio and video instructions at the Command Console, exhibit patrons may prompt IVA to perform a housekeeping task or give a speaking tour of the module. Other exemplary space station tasks are simulated and the public can even challenge IVA to a game of tic tac toe. In anticipation of such a system being built for the Space Station, a discussion is provided of the approach taken, along with suggestions for applicability to the Space Station Environment.

Konkel, Carl R.↗

Historical problem areas lessons learned

Historical problem areas in space transportation propulsion technology are identified in viewgraph form. Problem areas discussed include materials compatibility, contamination, pneumatic/feed system flow instabilities, instabilities in rocket engine combustion and fuel sloshing, exhaust plume interference, composite rocket nozzle failure, and freeze/thaw damage.

Sackheim, Bob↗

Lessons learned in the development of the Hubble Space Telescope software

An effort is made to document what was successful in the HST software development, and to present a retrospective analysis indicating what could have been done more efficiently. Consideration is given to systems engineering and design definition, standards and tools, system architecture and design, operational considerations, and reuse and adaptation of existing resources.

Harrington, Michael↗

Lessons learned in control center technologies and non-technologies

Information is given in viewgraph form on the Solar Mesosphere Explorer (SME) Control Center and the Oculometer and Automated Space Interface System (OASIS). Topics covered include SME mission operations functions; technical and non-technical features of the SME control center; general tasks and objects within the Space Station Freedom (SSF) ground system nodes; OASIS-Real Time for the control and monitoring of of space systems and subsystems; and OASIS planning, scheduling, and PC architecture.

Hansen, Elaine R.↗

Getting expert systems off the ground: Lessons learned from integrating model-based diagnostics with prototype flight hardware

As an initial attempt to introduce expert system technology into an onboard environment, a model based diagnostic system using the TRW MARPLE software tool was integrated with prototype flight hardware and its corresponding control software. Because this experiment was designed primarily to test the effectiveness of the model based reasoning technique used, the expert system ran on a separate hardware platform, and interactions between the control software and the model based diagnostics were limited. While this project met its objective of showing that model based reasoning can effectively isolate failures in flight hardware, it also identified the need for an integrated development path for expert system and control software for onboard applications. In developing expert systems that are ready for flight, artificial intelligence techniques must be evaluated to determine whether they offer a real advantage onboard, identify which diagnostic functions should be performed by the expert systems and which are better left to the procedural software, and work closely with both the hardware and the software developers from the beginning of a project to produce a well designed and thoroughly integrated application.

Stephan, Amy↗

Tiltrotor research aircraft composite blade repairs: Lessons learned

The XV-15, N703NA Tiltrotor Research Aircraft located at the NASA Ames Research Center, Moffett Field, California, currently uses a set of composite rotor blades of complex shape known as the advanced technology blades (ATBs). The main structural element of the blades is a D-spar constructed of unidirectional, angled fiberglass/graphite, with the aft fairing portion of the blades constructed of a fiberglass cross-ply skin bonded to a Nomex honeycomb core. The blade tip is a removable laminate shell that fits over the outboard section of the spar structure, which contains a cavity to retain balance weights. Two types of tip shells are used for research. One is highly twisted (more than a conventional helicopter blade) and has a hollow core constructed of a thin Nomex-honeycomb-and-fiberglass-skin sandwich; the other is untwisted with a solid Nomex honeycomb core and a fiberglass cross-ply skin. During initial flight testing of the blades, a number of problems in the composite structure were encountered. These problems included debonding between the fiberglass skin and the honeycomb core, failure of the honeycomb core, failures in fiberglass splices, cracks in fiberglass blocks, misalignment of mated composite parts, and failures of retention of metal fasteners. Substantial time was spent in identifying and repairing these problems. Discussed here are the types of problems encountered, the inspection procedures used to identify each problem, the repairs performed on the damaged or flawed areas, the level of criticality of the problems, and the monitoring of repaired areas. It is hoped that this discussion will help designers, analysts, and experimenters in the future as the use of composites becomes more prevalent.

Espinosa, Paul S.↗

Autonomous rough terrain navigation - Lessons learned

Because of light-time delays, a planetary rover located on Mars or beyond will probably need to be able to navigate autonomously, in order to do significant exploration. Recent work at JPL has explored several different autonomous navigation strategies. This work includes highly deliberative methods that require large amounts of computation and internal storage but yield very planful behavior to more reactive systems that require less resources but whose behavior is more difficult to model. This paper briefly presents these methods, the results from experiments both in simulation and in the field, and some conclusions on the value of different approaches, and their possible impact on the structure of the robot and the mission architecture.

Miller, David P.↗

The Extreme Ultraviolet Explorer science instruments development - Lessons learned

The science instruments development project for the Extreme Ultraviolet Explorer (EUVE) satellite is reviewed. Issues discussed include the philosophical basis of the program, the establishment of a tight development team, the approach to planning and phasing activities, the handling of the most difficult technical problems, and the assessment of the work done during the preimplemntation period of the project.

Malina, Roger F.↗