Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Contracting Document”

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

Documentation: No Substitute for Communication

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.

Strickland, John↗

Earth Observing System/Meteorological Satellite (EOS/METSAT). Advanced Microwave Sounding Unit-A (AMSU-A) Contamination Control Plan

This Contamination Control Plan is submitted in response the Contract Document requirements List (CDRL) 007 under contract NAS5-32314 for the Earth Observing System (EOS) Advanced Microwave Sounding Unit A (AMSU-A). In response to the CDRL instructions, this document defines the level of cleanliness and methods/procedures to be followed to achieve adequate cleanliness/contamination control, and defines the required approach to maintain cleanliness/contamination control through shipping, observatory integration, test, and flight. This plan is also applicable to the Meteorological Satellite (METSAT) except where requirements are identified as EOS-specific. This plan is based on two key factors: a. The EOS/METSAT AMSU-A Instruments are not highly contamination sensitive. b. Potential contamination of other EOS Instruments is a key concern as addressed in Section 9/0 of the Performance Assurance Requirements for EOS/METSAT Integrated Programs AMSU-A Instrument (MR) (NASA Specification S-480-79).

Fay, M.↗

Base heating methodology improvements, volume 1

This document is the final report for NASA MSFC Contract NAS8-38141. The contracted effort had the broad objective of improving the launch vehicles ascent base heating methodology to improve and simplify the determination of that environment for Advanced Launch System (ALS) concepts. It was pursued as an Advanced Development Plan (ADP) for the Joint DoD/NASA ALS program office with project management assigned to NASA/MSFC. The original study was to be completed in 26 months beginning Sep. 1989. Because of several program changes and emphasis on evolving launch vehicle concepts, the period of performance was extended to the current completion date of Nov. 1992. A computer code incorporating the methodology improvements into a quick prediction tool was developed and is operational for basic configuration and propulsion concepts. The code and its users guide are also provided as part of the contract documentation. Background information describing the specific objectives, limitations, and goals of the contract is summarized. A brief chronology of the ALS/NLS program history is also presented to provide the reader with an overview of the many variables influencing the development of the code over the past three years.

Bender, Robert L.↗

Expanded Guidance for NASA Systems Engineering. Volume 2: Crosscutting Topics, Special Topics, and Appendices

Historically, most successful NASA projects have depended on effectively blending project management, systems engineering, and technical expertise among NASA, contractors, and third parties. Underlying these successes are a variety of agreements (e.g., contract, memorandum of understanding, grant, cooperative agreement) between NASA organizations or between NASA and other Government agencies, Government organizations, companies, universities, research laboratories, and so on. To simplify the discussions, the term "contract" is used to encompass these agreements. This section focuses on the NASA systems engineering activities pertinent to awarding a contract, managing contract performance, and completing a contract. In particular, NASA systems engineering interfaces to the procurement process are covered, since the NASA engineering technical team plays a key role in the development and evaluation of contract documentation. Contractors and third parties perform activities that supplement (or substitute for) the NASA project technical team accomplishment of the NASA common systems engineering technical process activities and requirements outlined in this guide. Since contractors might be involved in any part of the systems engineering life cycle, the NASA project technical team needs to know how to prepare for, allocate or perform, and implement surveillance of technical activities that are allocated to contractors.

Steven R Hirshorn↗

Configuration management plan. System definition and project development. Repository Based Software Engineering (RBSE) program

This is the configuration management Plan for the AdaNet Repository Based Software Engineering (RBSE) contract. This document establishes the requirements and activities needed to ensure that the products developed for the AdaNet RBSE contract are accurately identified, that proposed changes to the product are systematically evaluated and controlled, that the status of all change activity is known at all times, and that the product achieves its functional performance requirements and is accurately documented.

Mckay, Charles↗

Analysis of Lidar Remote Sensing Concepts

An orbiting coherent Doppler lidar for measuring winds is required to provide two basic pieces of data to the user community. The first is the line of sight wind velocity and the second is knowledge of the position at which the measurement was made. In order to obtain this data for targets of interest to the atmospheric community the instrument must also have a level of backscatter sensitivity sufficient to achieve the goal. Sensitivity analyses for the line of sight velocity and position requirements for two lidar instruments, one with a nadir angle of 30 deg. in a 300 km altitude, 58 deg. inclination orbit and the second for a 45 deg. nadir angle instrument in a 833 km altitude , 89 deg. inclination orbit are performed. The issues relating to the backscatter sensitivity of a coherent lidar have been well documented previously and are not discussed here other than to identify a space-specific issue that does not typically need to be considered for ground and aircraft based coherent lidars. Section 2 and appendices A1 and A2 document these sensitivity analyses. This contract was intended to develop requirements for a space shuttle (STS) based coherent lidar however, shortly after the award of this contract NASA MSFC won the SPARCLE program to put a coherent Doppler lidar on STS. Consequently much of the work conducted under this contract has been documented within the development of the SPARCLE project documentation. The relevant portions of the SPARCLE documentation are identified in section 3.0 and included in appendices A3 and A4. Section 4.0 briefly outlines miscellaneous other activities that occurred under this contract.

Spiers, Gray D.↗

Standardization and program effect analysis (Study 2.4). Volume 3: Design-to-cost analysis

The program procedures that were incorporated into an on-going "design-to-cost" spacecraft program are examined. Program procedures are the activities that support the development and operations of the flight unit: contract management, documents, integration meetings, engineering, and testing. This report is limited to the program procedures that were implemented, with emphasis on areas that may depart from normal satellite development practices.

Shiokari, T.↗

Technical guide on documentation requirements for open market contract acquisitions of information resources

A guide is presented to assist requestors in formulating and submitting the required Complete Package for Information Resources (IR) acquisitions. Advance discussions with cognizant procurement personnel are strongly recommended for complex IR requirements or for those requestors new to the acquisition process. Open Market means the requirement either is not available on GSA Schedule Contract or exceeds the $300,000 threshold and/or the quantity Maximum Order Limitation of the GSA Schedule Contract. Only open market contract acquisitions (i.e., in excess of the $25,000 small purchase threshold), are addressed.

Shaw, Asa L., Jr.↗

Aircraft/Air Traffic Management Functional Analysis Model: Technical Description

The Aircraft/Air Traffic Management Functional Analysis Model, Version 2.0 (FAM 2.0), is a discrete event simulation model designed to support analysis of alternative concepts in air traffic management and control. FAM 2.0 was developed by the Logistics Management Institute (LMI) under a National Aeronautics and Space Administration (NASA) contract. This document provides a technical description of FAM 2.0 and its computer files to enable the modeler and programmer to make enhancements or modifications to the model. Those interested in a guide for using the model in analysis should consult the companion document, Aircraft/Air Traffic Management Functional Analysis Model, Version 2.0 Users Manual.

Etheridge, Melvin↗

Aircraft/Air Traffic Management Functional Analysis Model: User's Guide - Version 2.0

The Aircraft/Air Traffic Management Functional Analysis Model, Version 2.0 (FAM 2.0), is a discrete event simulation model designed to support analysis of alternative concepts in air traffic management and control. FAM 2.0 was developed by the Logistics Management Institute (LMI) a National Aeronautics and Space Administration (NASA) contract. This document provides a guide for using the model in analysis. Those interested in making enhancements or modification to the model should consult the companion document, Aircraft/Air Traffic Management Functional Analysis Model, Version 2.0 Technical Description.

Etheridge, Melvin↗

SEDSAT

Under this contract the Students for the Exploration and Development of Space Satellite number One (SEDSAT-1 or just SEDSAT) was completed and launched on 24-Oct-98. It achieved nominal orbit and activated its transponders after Delta II separation. Telemetry has indicated the internal systems are normal. However, SEDSAT has not responded to subsequent uplink commands. Telemetry has continued to be received allowing evaluation of bus performance and attempts at anomaly resolution. Anomaly resolution will continue during 1999 subsequent to the end of this contract. This final report documents activities under the contract period.

Source record↗

Publications of the JPL Solar Thermal Power Systems Project 1976 Through 1985

Bibliographical listings are documentation products associated with the Solar Thermal Power Systems Project carried out by the Jet Propulsion Laboratory from 1976 to 1986. Documents are categorized as conference and journal papers, JPL external reports, JPL internal reports, or contractor reports (i.e., deliverable documents produced under contract to JPL). Alphabetical listings by titles are used in the bibliography itself to facilitate location of the document by subject. Two indexes are included for ease of reference; an author index; and a topical index.

Panda, P.↗

Human computer interface guide, revision A

The Human Computer Interface Guide, SSP 30540, is a reference document for the information systems within the Space Station Freedom Program (SSFP). The Human Computer Interface Guide (HCIG) provides guidelines for the design of computer software that affects human performance, specifically, the human-computer interface. This document contains an introduction and subparagraphs on SSFP computer systems, users, and tasks; guidelines for interactions between users and the SSFP computer systems; human factors evaluation and testing of the user interface system; and example specifications. The contents of this document are intended to be consistent with the tasks and products to be prepared by NASA Work Package Centers and SSFP participants as defined in SSP 30000, Space Station Program Definition and Requirements Document. The Human Computer Interface Guide shall be implemented on all new SSFP contractual and internal activities and shall be included in any existing contracts through contract changes. This document is under the control of the Space Station Control Board, and any changes or revisions will be approved by the deputy director.

Source record↗

Electrical, Electronic, and Electromechanical (EEE) parts management and control requirements for NASA space flight programs

This document establishes electrical, electronic, and electromechanical (EEE) parts management and control requirements for contractors providing and maintaining space flight and mission-essential or critical ground support equipment for NASA space flight programs. Although the text is worded 'the contractor shall,' the requirements are also to be used by NASA Headquarters and field installations for developing program/project parts management and control requirements for in-house and contracted efforts. This document places increased emphasis on parts programs to ensure that reliability and quality are considered through adequate consideration of the selection, control, and application of parts. It is the intent of this document to identify disciplines that can be implemented to obtain reliable parts which meet mission needs. The parts management and control requirements described in this document are to be selectively applied, based on equipment class and mission needs. Individual equipment needs should be evaluated to determine the extent to which each requirement should be implemented on a procurement. Utilization of this document does not preclude the usage of other documents. The entire process of developing and implementing requirements is referred to as 'tailoring' the program for a specific project. Some factors that should be considered in this tailoring process include program phase, equipment category and criticality, equipment complexity, and mission requirements. Parts management and control requirements advocated by this document directly support the concept of 'reliability by design' and are an integral part of system reliability and maintainability. Achieving the required availability and mission success objectives during operation depends on the attention given reliability and maintainability in the design phase. Consequently, it is intended that the requirements described in this document are consistent with those of NASA publications, 'Reliability Program Requirements for Aeronautical and Space System Contractors,' NHB 5300.4(1A-l); 'Maintainability Program Requirements for Space Systems,' NHB 5300.4(1E); and 'Quality Program Provisions for Aeronautical and Space System Contractors,' NHB 5300.4(1B).

Source record↗

Constitutive modeling for isotropic materials

The first year of progress on a NASA-Lewis contract with the General Electric Co is documented. The purpose of this contract (NAS3-23927) is to develop and evaluate unified constitutive equations for applications to hot-path components of aircraft gas turbine engines such as high pressure turbine blades and vanes. To accomplish this goal, uniaxial, notched, and multiaxial specimens made of conventionally cast Rene 80 are being tested under conditions that simulate engine operating conditions. To reduce the raw data, automated data reduction techniques are being developed that produce computer files containing the information needed to analyze proposed constitutive theories. Described are the analytical methods being developed to determine the parameters for these nonlinear unified theories by using the reduced data files. In another activity, a dedicated finite-element computer code is being developed to use unified theories in the structural analysis of hot-section components. This code was extensively verified for one such theory by successfully predicting the strain histories measured experimentally at the notch root of complex specimens taken from complex laboratory specimens.

Ramaswamy, V. G.↗

Definition, technology readiness, and development cost of the orbit transfer vehicle engine integrated control and health monitoring system elements

An Integrated Control and Health Monitoring (ICHM) system was conceived for use on a 20 Klb thrust baseline Orbit Transfer Vehicle (OTV) engine. Considered for space used, the ICHM was defined for reusability requirements for an OTV engine service free life of 20 missions, with 100 starts and a total engine operational time of 4 hours. Functions were derived by flowing down requirements from NASA guidelines, previous OTV engine or ICHM documents, and related contracts. The elements of an ICHM were identified and listed, and these elements were described in sufficient detail to allow estimation of their technology readiness levels. These elements were assessed in terms of technology readiness level, and supporting rationale for these assessments presented. The remaining cost for development of a minimal ICHM system to technology readiness level 6 was estimated. The estimates are within an accuracy range of minus/plus 20 percent. The cost estimates cover what is needed to prepare an ICHM system for use on a focussed testbed for an expander cycle engine, excluding support to the actual test firings.

Cannon, I.↗

Managing Requirements-Documents to Data

Managing Requirements on long term projects like International Space Station (ISS) can go thru many phases, from initial product development to almost over 20 years of operations and sustainment. Over that time many authorized changes have been made to the requirement set, that apply to any new systems that would visit the ISS today, like commercial cargo/crew vehicles or payloads. Explore the benefits of managing requirements in a database while satisfying traditional documents needs for contracts and stakeholder/user consumption that are not tied into the database.

Orr, Kevin↗

Traffic Aware Strategic Aircrew Requests (TASAR) Analysis and Development

This document is the final report and deliverable 30 of Contract No. NNL12AA06C, the Traffic Aware Strategic Aircrew Requests (TASAR) contract awarded via the NASA Research Announcement (NRA). It documents the accomplishments of the contract, the evolution of its role in the overall TASAR project, and lessons learned from its execution.

Woods, Sharon E.↗