Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “SPECIFICATIONS”

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 37 records · Page 2

Earth Observatory Satellite system definition study. Report 5: System design and specifications. Volume 2: EOS-A system specification

The objectives of the Earth Observatory Satellite (EOS) program are defined. The system specifications for the satellite payload are examined. The broad objectives of the EOS-A program are as follows: (1) to develop space-borne sensors for the measurement of land resources, (2) to evolve spacecraft systems and subsystems which will permit earth observation with greater accuracy, coverage, spatial resolution, and continuity than existing systems, (3) to develop improved information processing, extraction, display, and distribution systems, and (4) to use space transportation systems for resupply and retrieval of the EOS.

Source record↗

Earth Observatory Satellite system definition study. Report 5: System design and specifications. Volume 5: Specification for EROS operations control center

The functional, performance, and design requirements for the Operations Control Center (OCC) of the Earth Observatory Satellite (EOS) system are presented. The OCC controls the operations of the EOS satellite to acquire mission data consisting of: (1) thematic mapper data, (2) multispectral scanner data on EOS-A, or High Resolution Pointable Imager data on EOS-B, and (3) data collection system (DCS) data. The various inputs to the OCC are identified. The functional requirements of the OCC are defined. The specific systems and subsystems of the OCC are described and block diagrams are provided.

Source record↗

Earth Observatory Satellite system definition study. Report no. 5: System design and specifications. Part 1: Observatory system element specifications

The performance, design, and quality assurance requirements for the Earth Observatory Satellite (EOS) Observatory and Ground System program elements required to perform the Land Resources Management (LRM) A-type mission are presented. The requirements for the Observatory element with the exception of the instruments specifications are contained in the first part.

Source record↗

Compiler writing system detail design specification. Volume 2: Component specification

The logic modules and data structures composing the Meta-translator module are desribed. This module is responsible for the actual generation of the executable language compiler as a function of the input Meta-language. Machine definitions are also processed and are placed as encoded data on the compiler library data file. The transformation of intermediate language in target language object text is described.

Arthur, W. J.↗

Earth Observatory Satellite system definition study. Report 5: System design and specifications. Volume 7: Specification for EOS low cost readout station

The functional, performance, and design requirements for the Low Cost Readout Station (LCRS) which supports the Earth Observatory Satellite (EOS) data system are described. The basic LCRS consists of all hardware and software needed to acquire and track the EOS-A or EOS-B satellite and receive, record, process, and annotate the instrument data from the satellites. The LCRS also provides appropriate interfaces with the unique local user provided display and extractive processing equipment. The LCRS has the capability of acquiring image data from the EOS-A and the EOS-B satellites over a ground area defines by a 500 kilometer radius from the coordinates of the station. The LCRS is also capable of receiving and processing both, but not simultaneously, full five band Multispectral Scanner (MSS) image data and various modes of the Compacted Thematic (CTM) data.

Source record↗

Software design specification. Part 2: Orbital Flight Test (OFT) detailed design specification. Volume 3: Applications. Book 2: System management

The functions performed by the systems management (SM) application software are described along with the design employed to accomplish these functions. The operational sequences (OPS) control segments and the cyclic processes they control are defined. The SM specialist function control (SPEC) segments and the display controlled 'on-demand' processes that are invoked by either an OPS or SPEC control segment as a direct result of an item entry to a display are included. Each processing element in the SM application is described including an input/output table and a structured control flow diagram. The flow through the module and other information pertinent to that process and its interfaces to other processes are included.

Source record↗

Routine detection of Epstein-Barr virus specific T-cells in the peripheral blood by flow cytometry

The ability to detect cytomegalovirus-specific T-cells (CD4(+)) in the peripheral blood by flow cytometry has been recently described by Picker et al. In this method, cells are incubated with viral antigen and responding (cytokine producing) T-cells are then identified by flow cytometry. To date, this technique has not been reliably used to detect Epstein-Barr virus (EBV)-specific T-cells primarily due to the superantigen/mitogenic properties of the virus which non-specifically activate T-cells. By modifying culture conditions under which the antigens are presented, we have overcome this limitation and developed an assay to detect and quantitate EBV-specific T-cells. The detection of cytokine producing T-cells by flow cytometry requires an extremely strong signal (such as culture in the presence of PMA and ionomycin). Our data indicate that in modified culture conditions (early removal of viral antigen) the non-specific activation of T-cells by EBV is reduced, but antigen presentation will continue uninhibited. Using this method, EBV-specific T-cells may be legitimately detected using flow cytometry. No reduction in the numbers of antigen-specific T-cells was observed by the early removal of target antigen when verified using cytomegalovirus antigen (a virus with no non-specific T-cell activation properties). In EBV-seropositive individuals, the phenotype of the EBV-specific cytokine producing T-cells was evaluated using four-color flow cytometry and found to be CD45(+), CD3(+), CD4(+), CD45RA(-), CD69(+), CD25(-). This phenotype indicates the stimulation of circulating previously unactivated memory T-cells. No cytokine production was observed in CD4(+) T-cells from EBV-seronegative individuals, confirming the specificity of this assay. In addition, the use of four color cytometry (CD45, CD3, CD69, IFNgamma/IL-2) allows the total quantitative assessment of EBV-specific T-cells while monitoring the interference of EBV non-specific mitogenic activity. This method may have significant utility for the monitoring of the immune response to latent virus infection/reactivation.

Non-NASA Center↗

SLS-SPEC-159 Cross-Program Design Specification for Natural Environments (DSNE) Revision D

This document is derived from the former National Aeronautics and Space Administration (NASA) Constellation Program (CxP) document CxP 70023, titled "The Design Specification for Natural Environments (DSNE), Revision C." The original document has been modified to represent updated Design Reference Missions (DRMs) for the NASA Exploration Systems Development (ESD) Programs. The DSNE completes environment-related specifications for architecture, system-level, and lower-tier documents by specifying the ranges of environmental conditions that must be accounted for by NASA ESD Programs. To assure clarity and consistency, and to prevent requirements documents from becoming cluttered with extensive amounts of technical material, natural environment specifications have been compiled into this document. The intent is to keep a unified specification for natural environments that each Program calls out for appropriate application. This document defines the natural environments parameter limits (maximum and minimum values, energy spectra, or precise model inputs, assumptions, model options, etc.), for all ESD Programs. These environments are developed by the NASA Marshall Space Flight Center (MSFC) Natural Environments Branch (MSFC organization code: EV44). Many of the parameter limits are based on experience with previous programs, such as the Space Shuttle Program. The parameter limits contain no margin and are meant to be evaluated individually to ensure they are reasonable (i.e., do not apply unrealistic extreme-on-extreme conditions). The natural environments specifications in this document should be accounted for by robust design of the flight vehicle and support systems. However, it is understood that in some cases the Programs will find it more effective to account for portions of the environment ranges by operational mitigation or acceptance of risk in accordance with an appropriate program risk management plan and/or hazard analysis process. The DSNE is not intended as a definition of operational models or operational constraints, nor is it adequate, alone, for ground facilities which may have additional requirements (for example, building codes and local environmental constraints). "Natural environments," as the term is used here, refers to the environments that are not the result of intended human activity or intervention. It consists of a variety of external environmental factors (most of natural origin and a few of human origin) which impose restrictions or otherwise impact the development or operation of flight vehicles and destination surface systems. These natural environments include the following types of environments: Terrestrial environments at launch, abort, and normal landing sites (winds, temperatures, pressures, surface roughness, sea conditions, etc.); Space environments (ionizing radiation, orbital debris, meteoroids, thermosphere density, plasma, solar, Earth, and lunar-emitted thermal radiation, etc.); Destination environments (Lunar surface and orbital, Mars atmosphere and surface, near Earth asteroids, etc.). Many of the environmental specifications in this document are based on models, data, and environment descriptions contained in the CxP 70044, Constellation Program Natural Environment Definition for Design (NEDD). The NEDD provides additional detailed environment data and model descriptions to support analytical studies for ESD Programs. For background information on specific environments and their effects on spacecraft design and operations, the environment models, and the data used to generate the specifications contained in the DSNE, the reader is referred to the NEDD paragraphs listed in each section of the DSNE. Also, most of the environmental specifications in this document are tied specifically to the ESD DRMs in ESD-10012, Revision B, Exploration Systems Development Concept of Operations (ConOps). Coordination between these environment specifications and the DRMs must be maintained. This document should be compatible with the current ESD DRMs, but updates to the mission definitions and variations in interpretation may require adjustments to the environment specifications.

Roberts, Barry C.↗

User Interface Technology for Formal Specification Development

Formal specification development and modification are an essential component of the knowledge-based software life cycle. User interface technology is needed to empower end-users to create their own formal specifications. This paper describes the advanced user interface for AMPHION1 a knowledge-based software engineering system that targets scientific subroutine libraries. AMPHION is a generic, domain-independent architecture that is specialized to an application domain through a declarative domain theory. Formal specification development and reuse is made accessible to end-users through an intuitive graphical interface that provides semantic guidance in creating diagrams denoting formal specifications in an application domain. The diagrams also serve to document the specifications. Automatic deductive program synthesis ensures that end-user specifications are correctly implemented. The tables that drive AMPHION's user interface are automatically compiled from a domain theory; portions of the interface can be customized by the end-user. The user interface facilitates formal specification development by hiding syntactic details, such as logical notation. It also turns some of the barriers for end-user specification development associated with strongly typed formal languages into active sources of guidance, without restricting advanced users. The interface is especially suited for specification modification. AMPHION has been applied to the domain of solar system kinematics through the development of a declarative domain theory. Testing over six months with planetary scientists indicates that AMPHION's interactive specification acquisition paradigm enables users to develop, modify, and reuse specifications at least an order of magnitude more rapidly than manual program development.

Lowry, Michael↗

An intelligent position-specific training system for mission operations

Marshall Space Flight Center's (MSFC's) payload ground controller training program provides very good generic training; however, ground controller position-specific training can be improved by including position-specific training systems in the training program. This report explains why MSFC needs to improve payload ground controller position-specific training. The report describes a generic syllabus for position-specific training systems, a range of system designs for position-specific training systems, and a generic development process for developing position-specific training systems. The report also describes a position-specific training system prototype that was developed for the crew interface coordinator payload operations control center ground controller position. The report concludes that MSFC can improve the payload ground controller training program by incorporating position-specific training systems for each ground controller position; however, MSFC should not develop position-specific training systems unless payload ground controller position experts will be available to participate in the development process.

Schneider, M. P.↗

Building Specifications

The building in the top photo is the new home of the National Permanent Savings Bank in Washington, D.C., designed by Hartman-Cox Architects. Its construction was based on a money-saving method of preparing building specifications which derived from NASA technology developed to obtain quality construction while holding down cost of launch facilities, test centers and other structures. Written technical specifications spell out materials and components to be used on construction projects and identify the quality tests each item must pass. Specifications can have major impact on construction costs. Poorly formulated specifications can lead to unacceptable construction which must be replaced, unnecessarily high materials costs, safety hazards, disputes and often additional costs due to delays and litigation. NASA's Langley Research Center developed a novel approach to providing accurate, uniform, cost-effective specifications which can be readily updated to incorporate new building technologies. Called SPECSINTACT, it is a computerized - system accessible to all NASA centers involved in construction programs. The system contains a comprehensive catalog of master specifications applicable to many types of construction. It enables designers of any structure to call out relevant sections from computer storage and modify them to fit the needs of the project at hand. Architects and engineers can save time by concentrating their efforts on needed modifications rather than developing all specifications from scratch. Successful use of SPECSINTACT has led to a number of spinoff systems. One of the first was MASTERSPEC, developed from NASA's experience by Production Systems for Architects and Engineers, Inc., an organization established by the American Institute of Architects. MASTERSPEC, used in construction of the bank building pictured, follows the same basic format as SPECSINTACT and can be used in either automated or manual modes. The striking appearance of the bank building shows that, while MASTERSPEC saves time and money, its use involves no sacrfice in architectural design freedom. The Naval Engineering Facilities Command employs an automated specifications system based on SPECSINTACT. The Public Buildings Service of the General Services Administration used SPECSINTACT as a starting point in a plan to make its guideline specifications available to architects and engineers on a nationwide computer network. Public Technology, Inc., a NASA Technology Application Team, is working with Production Systems for Architects and Engineers, Inc., to promote widespread use of the system by state and local governments for cost benefits to taxpayers.

Source record↗

Improving Building Construction Specifications in State and Local Governments

State and local governments can benefit from master specifications systems that centralize data on all types of building materials, products, and processes. Most of these systems are organized according to the MASTERFORMAT system, which, along with guide specifications that require the insertion or deletion of standardized information, resulted from the specific needs of users and providers. For jurisdictions preparing their own specifications, staff time and cost are reduced. For those subcontracting the preparation, master specifications provide a means of evaluating the specifications submitted. Current management specification systems described include SPECINTACT, OMSPEC, MASTERPEC, and the NAVFAC, Corps of Engineers, and GSA guide specifications.

Source record↗

Formalization and visualization of domain-specific software architectures

This paper describes a domain-specific software design system based on the concepts of software architectures engineering and domain-specific models and languages. In this system, software architectures are used as high level abstractions to formulate a domain-specific software design. The software architecture serves as a framework for composing architectural fragments (e.g., domain objects, system components, and hardware interfaces) that make up the knowledge (or model) base for solving a problem in a particular application area. A corresponding software design is generated by analyzing and describing a system in the context of the software architecture. While the software architecture serves as the framework for the design, this concept is insufficient by itself for supplying the additional details required for a specific design. Additional domain knowledge is still needed to instantiate components of the architecture and develop optimized algorithms for the problem domain. One possible way to obtain the additional details is through the use of domain-specific languages. Thus, the general concept of a software architecture and the specific design details provided by domain-specific languages are combined to create what can be termed a domain-specific software architecture (DSSA).

Bailor, Paul D.↗

Antigen presentation by non-immune B-cell hybridoma clones: presentation of synthetic antigenic sites reveals clones that exhibit no specificity and clones that present only one epitope

Recently, we reported the preparation and antigen-presenting properties of hybridoma B-cell clones obtained after fusing non-secreting, non-antigen presenting Balb/c 653-myeloma cells with non-immune SJL spleen cells. It was found that antigen presentation at the clonal level can be specific or non-specific, depending on the particular B-cell clone. In the present work, one specific and one general presenter B-cell clones were tested for their epitope presentation ability to SJL T-cells that were specific to lysozyme or myoglobin. B-cell clone A1G12, a general presenter which presented both lysozyme and myoglobin to their respective T-cell lines, was found to present all five myoglobin epitopes while clone A1L16, a lysozyme specific presenter presented only one of the three epitopes of lysozyme. The latter reveals a hitherto unknown submolecular specificity (to a given epitope within a protein) for antigen presenting cells at the clonal level. Therefore, the specificity of T-cell recognition does not only derive from the T-cell but may also be dependent on the epitope specificity of the antigen-presenting B-cell.

Hybridomas/immunology↗

A Multiphysics Study to Improve Specific Energy of Primary Batteries for Low Temperature Operation for Deep Space Missions

Several lander missions on the outer planets such as Europa, Enceladus, and Titan require electrical power to operate scientific and communication equipment. The traditional power generation methods, such as a photovoltaic array, are not feasible as their efficiency drops significantly at these vast distances. The novel radioisotope power systems are not practical today based on current lander designs and the effectiveness of these systems. To perform in situ science on distant planets, a high specific energy battery (>700 Wh/kg) needs to operate for about 480 hours under cold temperatures (-40C or 0C) [1]. While a primary battery such as Li-CFx can provide high specific energy at room temperature, its specific capacity decreases significantly at low temperatures. One of the causes for this drop is low ion and electrical conductivity, and slower reaction kinetics. Slower transport and facile kinetics lead to an increase in the battery’s resistance and higher voltage drops during the cell operation, thus reducing specific capacity. Both the transport and kinetics show a strong dependence on temperature. Thus, a small temperature rise can lead to an increase in the reaction rate and ion conductivity; since the temperature, cell resistance, and specific capacity are interdependent. A conventional battery model accounts for ohmic, thermodynamic, and, electrochemical, and chemical decomposition heating. The ohmic heating can be controlled by designing a resistive microstructure and varying the ratios of the active materials [2]. The kinetics can be improved by increasing the surface area, reducing the particle size, or adding a catalyst. These parameters are often optimized to achieve high specific energy at room temperatures. A similar optimization study is not available at low temperatures and for a primary (high specific energy) battery. For this presentation, we will explore the effect of geometrical, microstructural, and material properties on optimal specific capacity at low temperatures through multiphysics simulations. The ion transport resistance depends on the porosity and the tortuosity of an electrode and the separator.

M. Mehta↗

The SIFT Code Specification

The specification of Software Implemented Fault Tolerance (SIFT) consists of two parts, the specifications of the SIFT models and the specifications of the SIFT PASCAL program which actually implements the SIFT system. The code specifications are the last of a hierarchy of models describing the operation of the SIFT system and are related to the SIFT models as well as the PASCAL program. These Specifications serve to link the SIFT models to the running program. The specifications are very large and detailed and closely follow the form and organization of the PASCAL code. In addition to describing each of the components of the SIFT code, the code specifications describe the assumptions of the upper SIFT models which are required to actually prove that the code will work as specified. These constraints are imposed primarily on the schedule tables.

Source record↗