SEARCH · Search NASA
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.
Document Update and Compare programs provide simple computerized documentmaintenance system on Data General NOVA 840 computer. Document Update program allows user to update document either by batch or terminal input. Documents are modified and lists of modifications printed out.
The Johnson Space Center (JSC) document index is intended to provide a single source listing of all published JSC-numbered documents their authors, and the designated offices of prime responsibility (OPR's) by mail code at the time of publication. The index contains documents which have been received and processed by the JSC Technical Library as of January 13, 1988. Other JSC-numbered documents which are controlled but not available through the JSC Library are also listed.
Currently, almost all aircraft documentation in commercial aircraft cockpits is presented via hardcopy manuals. Several recent projects are aimed at eliminating all paper documentation in cockpits using electronic libraries. Electronic libraries encompass diverse information bases including aircraft system documentation, operations and procedures, checklists, maintenance logs, minimum equipment lists, maps and charts, and flight management information. These electronic libraries are envisioned to be embedded in the avionics so as to provide real time monitoring and display of information. Background issues are examined (motivation, information retrieval models, and preliminary designs) for the on-line presentation of aircraft systems documentation including operations, procedures, and checklists.
The Digital Document Storage (DDS)/Pilot Production System (PPS) will provide cost effective electronic document storage, retrieval, hard copy reproduction, and remote access for users of NASA Technical Reports. The DDS/PPS will result in major benefits, such as improved document reproduction quality within a shorter time frame than is currently possible. In addition, the DDS/PPS will provide an important strategic value through the construction of a digital document archive. It is highly recommended that NASA proceed with the DDS Prototype System and a rapid prototyping development methodology in order to validate recent working assumptions upon which the success of the DDS/PPS is dependent.
The Maintenance Document Version 3.0 is a guide to the PAN AIR software system, a system which computes the subsonic or supersonic linear potential flow about a body of nearly arbitrary shape, using a higher order panel method. The document describes the overall system and each program module of the system. Sufficient detail is given for program maintenance, updating, and modification. It is assumed that the reader is familiar with programming and CRAY computer systems. The PAN AIR system was written in FORTRAN 4 language except for a few CAL language subroutines which exist in the PAN AIR library. Structured programming techniques were used to provide code documentation and maintainability. The operating systems accommodated are COS 1.11, COS 1.12, COS 1.13, and COS 1.14 on the CRAY 1S, 1M, and X-MP computing systems. The system is comprised of a data base management system, a program library, an execution control module, and nine separate FORTRAN technical modules. Each module calculates part of the posed PAN AIR problem. The data base manager is used to communicate between modules and within modules. The technical modules must be run in a prescribed fashion for each PAN AIR problem. In order to ease the problem of supplying the many JCL cards required to execute the modules, a set of CRAY procedures (PAPROCS) was created to automatically supply most of the JCL cards. Most of this document has not changed for Version 3.0. It now, however, strictly applies only to PAN AIR version 3.0. The major changes are: (1) additional sections covering the new FDP module (which calculates streamlines and offbody points); (2) a complete rewrite of the section on the MAG module; and (3) strict applicability to CRAY computing systems.
This NASA Scientific and Technical Information Coordination Council meeting dealt with the topic 'NACA Documents Database Project'. The following presentations were made and reported on: NACA documents database project study plan, AIAA study, the Optimal NACA database, Deficiencies in online file, NACA documents: Availability and Preservation, the NARA Collection: What is in it? and What to do about it?, and NACA foreign documents and availability. Visuals are available for most presentations.
A method and apparatus for producing an abstract or condensed version of a visual document is presented. The frames comprising the visual document are first sampled to reduce the number of frames required for processing. The frames are then subjected to a structural decomposition process that reduces all information in each frame to a set of values. These values are in turn normalized and further combined to produce only one information content value per frame. The information content values of these frames are then compared to a selected distribution cutoff point. This effectively selects those values at the tails of a normal distribution, thus filtering key frames from their surrounding frames. The value for each frame is then compared with the value from the previous frame, and the respective frame is finally stored only if the values are significantly different. The method filters or compresses a visual document with a reduction in digital storage on the ratio of up to 700 to 1 or more, depending on the content of the visual document being filtered.
Intelligent Documentation Management System, IDMS, computer program developed to assist project managers in implementing information system documentation standard known as NASA-STD-2100-91, NASA STD, COS-10300, of NASA's Software Management and Assurance Program. Standard consists of data-item descriptions or templates, each of which governs particular component of software documentation. IDMS helps program manager in tailoring documentation standard to project. Written in C language.
The Technical and Management Information System (TMIS) Life-Cycle Process Document describes the processes that shall be followed in the definition, design, development, test, deployment, and operation of all TMIS products and data base applications. This document is a roll out of TMIS Standards Document (SSP 30546). The purpose of this document is to define the life cycle methodology that the developers of all products and data base applications and any subsequent modifications shall follow. Included in this methodology are descriptions of the tasks, deliverables, reviews, and approvals that are required before a product or data base application is accepted in the TMIS environment.
A selection of key documents in the history of the U.S. civil space program is presented. This volume deals with organizational developments of the space program. More than 200 documents are printed. Each is introduced by a headnote providing context, bibliographical information, and background information necessary to understanding the document. These are organized into four major sections, each beginning with an introductory essay that keys the documents to major events in the history of the space program.
In late 1998, the Space Shuttle Program recognized a need to revitalize its payload accommodations documentation. As a result a payload documentation enhancement project was initiated to review and update payload documentation and improve the accessibility to that documentation by the Space Shuttle user community.
The documents selected for inclusion in this volume are presented in four major chapters, each covering a particular aspect of access to space and the manner in which it has developed over time. These chapters focus on the evolution toward the giant Saturn V rocket, the development of the Space Shuttle, space transportation commercialization, and future space transportation possibilities. Each chapter in this volume is introduced by an overview essay, prepared by individuals who are particularly well qualified to write on the topic. In the main, these essays are intended to introduce and complement the documents in the chapter and to place them, for the most part, in a chronological and substantive context. Each essay contains references to the documents in the chapter it introduces, and many also contain references to documents in other chapters of the collection. These introductory essays are the responsibility of their individual authors, and the views and conclusions contained therein do not necessarily represent the opinions of either George Washington University or NASA.
This document describes the Langmuir Probe Spacecraft Potential (LPSP) investigation of the plasma environment in the vicinity of the ProSEDS Delta II spacecraft. This investigation will employ a group of three (3) Langmuir Probe Assemblies, LPAs, mounted on the Delta II second stage to measure the electron density and temperature (n(sub e) and T(sub e)), the ion density (n(sub i)), and the spacecraft potential (V(sub s)) relative to the surrounding ionospheric plasma. This document is also intended to define the technical requirements and flight-vehicle installation interfaces for the design, development, assembly, testing, qualification, and operation of the LPSP subsystem for the Propulsive Small Expendable Deployer System (ProSEDS) and its associated Ground Support Equipment (GSE). This document also defines the interfaces between the LPSP instrument and the ProSEDS Delta II spacecraft, as well as the design, fabrication, operation, and other requirements established to meet the mission objectives. The LPSP is the primary measurement instrument designed to characterize the background plasma environment and is a supporting instrument for measuring spacecraft potential of the Delta II vehicle used for the ProSEDS mission. Specifically, the LPSP will use the three LPAs equally spaced around the Delta II body to make measurements of the ambient ionospheric plasma during passive operations to aid in validating existing models of electrodynamic-tether propulsion. These same probes will also be used to measure Delta II spacecraft potential when active operations occur. When the electron emitting plasma contractor is on, dense neutral plasma is emitted. Effective operation of the plasma contactor (PC) will mean a low potential difference between the Delta II second stage and the surrounding plasma and represents one of the voltage parameters needed to fully characterize the electrodynamic-tether closed circuit. Given that the LP already needs to be well away from any near-field disturbances around the Delta II, it is possible to use the same probe with a simple reconfiguration of the electronics to measure potential with respect to the ambient plasma. The LP measurement techniques are outlined in the following text and discussed in detail in the Appendix. The scientific goals of the investigation, the physical and electrical characteristics of the instrument, and the on-orbit measurement requirements are also discussed in this document.
The documents selected for inclusion in this volume are presented in three major sections, each covering a particular aspect of the origins, evolution, and execution of the US space science program. Chapter 1 deals with the origins, evolution, and organization of the space science program. Chapter 2 deals with the solar system exploration. Chapter 3 deals with NASA's astronomy and astrophysics efforts. Each chapter in the present volume is introduced by an overview essay. In the main, these essays are intended to introduce and complement the documents in the chapter and to place them in a chronological and substantive context. Each essay contains references to the documents in the chapter it introduces, and may also contain references to documents in other chapters of the collection
Atomic oxygen, which normally is found only the near Earth space environment, causes oxidation and erosion of polymers on spacecraft. The development of technology to prevent this degradation has required NASA to develop ground laboratory facilities that generate atomic oxygen. Atomic oxygen has also been found to be able to oxidize most types of ink from a variety of types of pens. The use of atomic oxygen to identify alteration of documents has been investigated and is reported. Results of testing indicates that for many types of ink, pen, and paper, identification of document alteration of pen and ink numbers and evidence of alteration can be made visible by exposing the questionable writing to atomic oxygen. Atomic oxygen provides discrimination because different inks may oxidize at different rates, the amount of time between delayed alteration may add to ink thickness at crossings, and the end of pen strokes tend to have much thicker ink deposits than the rest of the character. Examples and techniques of using atomic oxygen to identify document alteration indicate that the technology can, in many but not all cases, provide discrimination between original and altered documents.
MEANS is an acronym for the MIT Extensible Air Network Simulation. MIT is the Massachusetts Institute of Technology, where MEANS was developed. MEANS models the flow of aircraft in a simulation of the US National Airspace System. It can optionally follow the flow of passengers as well. The flight model takes the form of several queues through which the aircraft pass, as well as delays at certain times; the passengers can be transported via flights. MEANS is an event-based model. This means that events are scheduled at some point in the future, and once an event has executed, the simulation t h e advances to that of the next event. This is a different approach than some simulations (particularly those of physical systems), where time is advanced in fixed increments and the state of the system is updated at each step.This documentation is a "user guide" for MEANS - it describes how to USE means, not write new modules. For programming instructions, see the programming documentation, available as a separate document.This document assumse no programming knowledge. It will describe how to run MEANS, understand the data formats, and use such utility programs as already exist. For more detailed information on the internal workings of MEANS, and how to programmatically add to it, refer to the programming documentation.
SO WHAT IS AN RFI? IT WAS ONE OF THE FIRST THINGS I learned about back when I started my project management career with my first large construction firm. I learned how to use these forms as a convenient and effective means of documenting the many legitimate clarifications needed on a major project. However, like most other young engineers, I also learned to use the RFI as a weapon in the ongoing battle between owners. or their designer and the construction contractors. Recently, our project team has done a few simple things to greatly reduce the waste and frustration that comes from this type of battle. The RFI form can be a great tool if used properly, and I certainly don t recommend that they be eliminated entirely. The RFI form was created to document the many clarifications that are commonly required on projects. Typically, the contractor uses the top half of the form to clarify-or request permission to vary from-the contract documents. The bottom half of the form is used to record the answer. But this seemingly simple process is plagued by a number of problems. From the contractor s perspective, RFIs are needed to secure information that should have been in the contract documents in the first place. The missing information keeps their crews from working effectively, and it makes hitting already demanding cost and schedule targets even more difficult. Owners, or their design firms, often view the RFI as a means of harassment. Both sides of the issue have legitimate complaints, and both sides cause most of their own pain.
Identification, resolution, and avoidance of technical and programmatic issues are important for ensuring safe and successful space missions. Although the importance of applying lessons learned to reduce risk is frequently stressed, there is little material available to help technical and management personnel research and document lessons learned. Collecting, researching, identifying, and documenting lessons learned that will be useful to current and future management and engineering personnel is not always a straightforward task. This white paper presents lessons learned and best practices concerning the research and documentation of technical and organizational lessons learned. It is intended to enable organizations to initiate or improve lessons learned research and documentation efforts. The content of this white paper is based on four technical lessons learned projects conducted by the United Space Alliance (USA) Flight Design and Dynamics Department, in support of the NASA/Johnson Space Center (JSC) Flight Design and Dynamics Division. Each project published a report, titled as follows: (1) GPS Lessons Learned From the ISS, Space Shuttle and X-38; (2) Lessons Learned From Seven Space Shuttle Missions; (3) Space Shuttle Rendezvous and Proximity Operations Experience Report; and (4) Navigation Technical History with Lessons Learned. The four projects were different in availability of subject matter experts and primary source material, subject scope, and the level of effort required to produce the final report. However, generic lessons can be drawn from all of them. The best practices will be discussed by the phases of report research and development: (1) Defining Report Requirements, Project Organization, and Schedule; (2) Collection and Analysis of Source Material; (3) Writing and Integrating the Report; and (4) Review and Revision of the Report.