Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “building codes and standards”

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 NTRS1989

Comparison of analytical methods for calculation of wind loads

The following analysis is a comparison of analytical methods for calculation of wind load pressures. The analytical methods specified in ASCE Paper No. 3269, ANSI A58.1-1982, the Standard Building Code, and the Uniform Building Code were analyzed using various hurricane speeds to determine the differences in the calculated results. The winds used for the analysis ranged from 100 mph to 125 mph and applied inland from the shoreline of a large open body of water (i.e., an enormous lake or the ocean) a distance of 1500 feet or ten times the height of the building or structure considered. For a building or structure less than or equal to 250 feet in height acted upon by a wind greater than or equal to 115 mph, it was determined that the method specified in ANSI A58.1-1982 calculates a larger wind load pressure than the other methods. For a building or structure between 250 feet and 500 feet tall acted upon by a wind rangind from 100 mph to 110 mph, there is no clear choice of which method to use; for these cases, factors that must be considered are the steady-state or peak wind velocity, the geographic location, the distance from a large open body of water, and the expected design life and its risk factor.

Minderman, Donald J.↗
NASA NTRS2024

Establishing Standards for Lunar In Situ Resource Utilization Structural Materials

Lunar structures will be exposed to one of the most extreme environments that have ever been considered for human settlements. In situ, regolith-based materials are being proposed for construction on the moon, offering the benefit of reducing the cost of transporting large amounts of materials or prefabricated elements, and relying on the ability to transport mainly the equipment needed to construct landing pads, shelters, blast shields, habitats, roadways, etc. However, the properties of materials that are made, all or in part, from indigenous lunar resources are likely to change based on the make-up of the material, the location where it was taken from, the production processes, and time. No standards or building codes exist for the design and construction of infrastructure on the moon. Engineers will need dependable information about these materials before any design can be completed. Hard-won lessons from centuries of using similar resources on Earth need to be leveraged to develop the best procedures that will be critical for testing such materials for structural applications. Here we discuss the technical challenges of establishing such standards. Using the timely example of a landing pad on the moon, we identify the gaps in both knowledge and testing capabilities that exist today.

Shirley J. Dyke↗
NASA NTRS1979

Residential photovoltaic module and array requirements study

Design requirements for photovoltaic modules and arrays used in residential applications were identified. Building codes and referenced standards were reviewed for their applicability to residential photovoltaic array installations. Four installation types were identified - integral (replaces roofing), direct (mounted on top of roofing), stand-off (mounted away from roofing), and rack (for flat or low slope roofs, or ground mounted). Installation costs were developed for these mounting types as a function of panel/module size. Studies were performed to identify optimum module shapes and sizes and operating voltage cost drivers. It is concluded that there are no perceived major obstacles to the use of photovoltaic modules in residential arrays. However, there is no applicable building code category for residential photovoltaic modules and arrays and additional work with standards writing organizations is needed to develop residential module and array requirements.

Nearhoof, S. L.↗
NASA NTRS1981

Commercial/industrial photovoltaic module and array requirement study. Low-cost solar array project engineering area

Design requirements for photovoltaic modules and arrays used in commercial and industrial applications were identified. Building codes and referenced standards were reviewed for their applicability to commercial and industrial photovoltaic array installation. Four general installation types were identified - integral (replaces roofing), direct (mounted on top of roofing), stand-off (mounted away from roofing), and rack (for flat or low slope roofs, or ground mounted). Each of the generic mounting types can be used in vertical wall mounting systems. This implies eight mounting types exist in the commercial/industrial sector. Installation costs were developed for these mounting types as a function of panel/module size. Cost drivers were identified. Studies were performed to identify optimum module shapes and sizes and operating voltage cost drivers. The general conclusion is that there are no perceived major obstacles to the use of photovoltaic modules in commercial/industrial arrays.

Source record↗
NASA NTRS1975

Program for developing and implementing a new approach to designing for fire safety in buildings

The traditional method of providing for fire safety in buildings through reliance on codes and standards that prescribe specific measures to be taken in the design and construction of buildings to minimize the potential for a fire occurring and to protect property and life should a fire occur was evaluated. A new approach to designing for fire safety in buildings is outlined.

Source record↗
NASA NTRS1985

Electrical safety requirements: Implications for the module designer

Commercial photovoltaic array installations, which include residential and intermediate applications, are subject to building and electrical codes and to product safety standards. The National Electrical Code (NEC) Article 690, titled Solar Photovoltaic Systems, contains provisions defining acceptable levels of system safety and emphasizes the system design and its installation. The Underwriters Laboratories, Inc. (UL), document titled: Proposed First Edition of the Standard for Flat Plate Photovoltaic Modules and Panels, UL-1703, identifies module and panel construction requirements that ensure product safety. Together these documents describe requirements intended to minimize hazards such as shock and fire. Although initial focus of these requirements is on single crystal silicon modules, they are generic in nature, and are equally applicable to high voltage ( 30 Vdc), multikilowatt, thin film systems. A major safety concern is insulation breakdown within the module or array wiring system, or discontinuities within the electrical conductors. These failures can result in ground faults, in circuit arcs, or exposure to hazardous electrical parts. Safeguards are discussed.

Sugimura, R. S.↗
NASA NTRS2005

C++ Coding Standards and Style Guide

This document is based on the "C Style Guide" (SEL-94-003). It contains recommendations for C++ implementations that build on, or in some cases replace, the style described in the C style guide. Style guidelines on any topics that are not covered in this document can be found in the "C Style Guide." An attempt has been made to indicate when these recommendations are just guidelines or suggestions versus when they are more strongly encouraged. Using coding standards makes code easier to read and maintain. General principles that maximize the readability and maintainability of C++ are: (1) Organize classes using encapsulation and information hiding techniques. (2) Enhance readability through the use of indentation and blank lines. (3) Add comments to header files to help users of classes. (4) Add comments to implementation files to help maintainers of classes. (5) Create names that are meaningful and readable.

Hughes, Steven↗
NASA NTRSDate not supplied

The Detection of Aromatic Amino Acids in CR Chondrites Suggests They are Prebiotically Plausible

Amino acids (AAs) are the building blocks of proteins and are essential for life on Earth. Sources of AAs on early Earth range from exogenous sources such as delivery from extraterrestrial materials(i.e., meteorites, interplanetary dust particles, comets, etc.) to endogenous sources including chemical reactions in hydrothermal vents or atmospheric mixtures. Analyses of AAs of extraterrestrial origin from meteorites and laboratory studies of simulated prebiotic environments revealed that a diverse set of abiotically produced AAs may have been present on early Earth. However only a fraction of these AAs is found within the proteins of living organisms. Of the22 genetically encoded (proteinogenic) AAs, 20 occur in the standard genetic code (SGC) and are used by nearly all living organisms to build proteins. The universality of this AA alphabet suggests the presence and incorporation of these specific AAs occurred early in the evolution of life.

A. S. Burton↗
NASA NTRS1986

Vector-matrix-quaternion, array and arithmetic packages: All HAL/S functions implemented in Ada

The HAL/S avionics programmers have enjoyed a variety of tools built into a language tailored to their special requirements. Ada is designed for a broader group of applications. Rather than providing built-in tools, Ada provides the elements with which users can build their own. Standard avionic packages remain to be developed. These must enable programmers to code in Ada as they have coded in HAL/S. The packages under development at JPL will provide all of the vector-matrix, array, and arithmetic functions described in the HAL/S manuals. In addition, the linear algebra package will provide all of the quaternion functions used in Shuttle steering and Galileo attitude control. Furthermore, using Ada's extensibility, many quaternion functions are being implemented as infix operations; equivalent capabilities were never implemented in HAL/S because doing so would entail modifying the compiler and expanding the language. With these packages, many HAL/S expressions will compile and execute in Ada, unchanged. Others can be converted simply by replacing the implicit HAL/S multiply operator with the Ada *. Errors will be trapped and identified. Input/output will be convenient and readable.

Klumpp, Allan R.↗
NASA NTRS1998

CAPRI (Computational Analysis PRogramming Interface): A Solid Modeling Based Infra-Structure for Engineering Analysis and Design Simulations

CAPRI is a CAD-vendor neutral application programming interface designed for the construction of analysis and design systems. By allowing access to the geometry from within all modules (grid generators, solvers and post-processors) such tasks as meshing on the actual surfaces, node enrichment by solvers and defining which mesh faces are boundaries (for the solver and visualization system) become simpler. The overall reliance on file 'standards' is minimized. This 'Geometry Centric' approach makes multi-physics (multi-disciplinary) analysis codes much easier to build. By using the shared (coupled) surface as the foundation, CAPRI provides a single call to interpolate grid-node based data from the surface discretization in one volume to another. Finally, design systems are possible where the results can be brought back into the CAD system (and therefore manufactured) because all geometry construction and modification are performed using the CAD system's geometry kernel.

Haimes, Robert↗
NASA NTRS2011

Application of the Life Safety Code to a Historic Test Stand

NASA has conducted a study to assess alternatives to refurbishing existing launch vehicle modal test facilities as opposed to developing new test facilities to meet the demands of a very fiscally constrained test and evaluation environment. The results of this study showed that Marshall Space Flight Center (MSFC) Test Stand (TS) 4550 could be made compliant, within reasonable cost and schedule impacts, if safety processes and operational limitations were put in place to meet the safety codes and concerns of the Fire Marshall. Trades were performed with key selection criteria to ensure that appropriate levels of occupant safety are incorporated into test facility design modifications. In preparation for the ground vibration tests that were to be performed on the Ares I launch vehicle, the Ares Flight and Integrated Test Office (FITO) organization evaluated the available test facility options, which included the existing mothballed structural dynamic TS4550 used by Apollo and Shuttle, alternative ground vibration test facilities at other locations, and construction of a new dynamic test stand. After an exhaustive assessment of the alternatives, the results favored modifying the TS4550 because it was the lowest cost option and presented the least schedule risk to the NASA Constellation Program for Ares Integrated Vehicle Ground Vibration Test (IVGVT). As the renovation design plans and drawings were being developed for TS4550, a safety concern was discovered the original design for the construction of the test stand, originally built for the Apollo Program and renovated for the Shuttle Program, was completed before NASA s adoption of the currently imposed safety and building codes per National Fire Protection Association Life Safety Code [NFPA 101] and International Building Codes. The initial FITO assessment of the design changes, required to make TS4550 compliant with current safety and building standards, identified a significant cost increase and schedule impact. An effort was launched to thoroughly evaluate the applicable life safety requirements, examine the context in which they were derived, and determine a means by which the TS4550 modifications could be made within budget and on schedule, while still providing the occupants with appropriate levels of safety.

Askins, Bruce↗
NASA NTRS1993

An assessment of space shuttle flight software development processes

In early 1991, the National Aeronautics and Space Administration's (NASA's) Office of Space Flight commissioned the Aeronautics and Space Engineering Board (ASEB) of the National Research Council (NRC) to investigate the adequacy of the current process by which NASA develops and verifies changes and updates to the Space Shuttle flight software. The Committee for Review of Oversight Mechanisms for Space Shuttle Flight Software Processes was convened in Jan. 1992 to accomplish the following tasks: (1) review the entire flight software development process from the initial requirements definition phase to final implementation, including object code build and final machine loading; (2) review and critique NASA's independent verification and validation process and mechanisms, including NASA's established software development and testing standards; (3) determine the acceptability and adequacy of the complete flight software development process, including the embedded validation and verification processes through comparison with (1) generally accepted industry practices, and (2) generally accepted Department of Defense and/or other government practices (comparing NASA's program with organizations and projects having similar volumes of software development, software maturity, complexity, criticality, lines of code, and national standards); (4) consider whether independent verification and validation should continue. An overview of the study, independent verification and validation of critical software, and the Space Shuttle flight software development process are addressed. Findings and recommendations are presented.

Source record↗
NASA NTRS2017

Generating Real-Time Robotics Control Software from SysML

In this paper, we outline an approach for autogenerating real-time robotics control code from hierarchical state machines and hardware configurations encoded in Systems Modeling Language (SysML). We propose a software architecture that provides an abstract SysML layer with access to device state information and a set of primitive device commands, such as move actuator and release brake, allowing a user to build up a complete functional state machine directly in SysML. The SysML diagram is then exported to a standard SCXML file format and subsequently used to auto-generate hardware control code. Once this architecture is in place, the only explicit code elements that need to be written are the primitive device commands, which can be easily unit tested and reused across different systems. The motivation for this work was the need for a test bed that enables the rapid prototyping of mechanisms and control algorithms for a spacecraft that could ultimately be used for preparing Martian rock samples for their return to Earth. To this end, our software system was also designed to allow for the run-time specification of the hardware layout in SysML, with the hardware-level control functions kept agnostic to the specific parameters or communication bus of any particular device. Further, we outline a system for specifying both the state machine and hardware configuration in the MagicDraw IDE in such a way that the system can be simulated before any code is generated. The resultant software system is easy to debug, understand, and allows users to choose how much information is encoded as a visual or text-based representation.

Godart, Peter↗
NASA NTRS2000

Level 1 Processing of MODIS Direct Broadcast Data From Terra

In February 2000, an effort was begun to adapt the Moderate Resolution Imaging Spectroradiometer (MODIS) Level 1 production software to process direct broadcast data. Three Level 1 algorithms have been adapted and packaged for release: Level 1A converts raw (level 0) data into Hierarchical Data Format (HDF), unpacking packets into scans; Geolocation computes geographic information for the data points in the Level 1A; and the Level 1B computes geolocated, calibrated radiances from the Level 1A and Geolocation products. One useful aspect of adapting the production software is the ability to incorporate enhancements contributed by the MODIS Science Team. We have therefore tried to limit changes to the software. However, in order to process the data immediately on receipt, we have taken advantage of a branch in the geolocation software that reads orbit and altitude information from the packets themselves, rather than external ancillary files used in standard production. We have also verified that the algorithms can be run with smaller time increments (2.5 minutes) than the five-minute increments used in production. To make the code easier to build and run, we have simplified directories and build scripts. Also, dependencies on a commercial numerics library have been replaced by public domain software. A version of the adapted code has been released for Silicon Graphics machines running lrix. Perhaps owing to its origin in production, the software is rather CPU-intensive. Consequently, a port to Linux is underway, followed by a version to run on PC clusters, with an eventual goal of running in near-real-time (i.e., process a ten-minute pass in ten minutes).

Lynnes, Christopher↗
NASA NTRS1981

Frequency and timing system for the consolidated DSN and STDN tracking network

The consolidation on the existing Deep Space Network (DSN) and colocated Goddard Spaceflight Tracking and Data Network (STDN) stations into a multiple antenna array is discussed. Each site includes a signal processing center (SPC) centered in an array of four or five antennas each located within approximately 300 to 800 meters of the SPC. A central frequency and timing system (FTS) located in the SPC contains reference frequency, timing and time code generation, and distribution equipment for both the SPC and each antenna with its associated front end antenna control building. The reference frequency distribution and clock equipment are driven by a hydrogen maser as the prime frequency standard with cesium beam frequency standard as the secondary.

Coffin, R. C.↗
NASA NTRS2017

Embracing Open Source for NASA's Earth Science Data Systems

The overarching purpose of NASAs Earth Science program is to develop a scientific understanding of Earth as a system. Scientific knowledge is most robust and actionable when resulting from transparent, traceable, and reproducible methods. Reproducibility includes open access to the data as well as the software used to arrive at results. Additionally, software that is custom-developed for NASA should be open to the greatest degree possible, to enable re-use across Federal agencies, reduce overall costs to the government, remove barriers to innovation, and promote consistency through the use of uniform standards. Finally, Open Source Software (OSS) practices facilitate collaboration between agencies and the private sector. To best meet these ends, NASAs Earth Science Division promotes the full and open sharing of not only all data, metadata, products, information, documentation, models, images, and research results but also the source code used to generate, manipulate and analyze them. This talk focuses on the challenges to open sourcing NASA developed software within ESD and the growing pains associated with establishing policies running the gamut of tracking issues, properly documenting build processes, engaging the open source community, maintaining internal compliance, and accepting contributions from external sources. This talk also covers the adoption of existing open source technologies and standards to enhance our custom solutions and our contributions back to the community. Finally, we will be introducing the most recent OSS contributions from NASA Earth Science program and promoting these projects for wider community review and adoption.

Earth Science↗
NASA NTRS2007

The DaveMLTranslator: An Interface for DAVE-ML Aerodynamic Models

It can take weeks or months to incorporate a new aerodynamic model into a vehicle simulation and validate the performance of the model. The Dynamic Aerospace Vehicle Exchange Markup Language (DAVE-ML) has been proposed as a means to reduce the time required to accomplish this task by defining a standard format for typical components of a flight dynamic model. The purpose of this paper is to describe an object-oriented C++ implementation of a class that interfaces a vehicle subsystem model specified in DAVE-ML and a vehicle simulation. Using the DaveMLTranslator class, aerodynamic or other subsystem models can be automatically imported and verified at run-time, significantly reducing the elapsed time between receipt of a DAVE-ML model and its integration into a simulation environment. The translator performs variable initializations, data table lookups, and mathematical calculations for the aerodynamic build-up, and executes any embedded static check-cases for verification. The implementation is efficient, enabling real-time execution. Simple interface code for the model inputs and outputs is the only requirement to integrate the DaveMLTranslator as a vehicle aerodynamic model. The translator makes use of existing table-lookup utilities from the Langley Standard Real-Time Simulation in C++ (LaSRS++). The design and operation of the translator class is described and comparisons with existing, conventional, C++ aerodynamic models of the same vehicle are given.

Hill, Melissa A.↗
NASA NTRS2011

Micrometeoroid and Orbital Debris Threat Assessment: Mars Sample Return Earth Entry Vehicle

This report provides results of a Micrometeoroid and Orbital Debris (MMOD) risk assessment of the Mars Sample Return Earth Entry Vehicle (MSR EEV). The assessment was performed using standard risk assessment methodology illustrated in Figure 1-1. Central to the process is the Bumper risk assessment code (Figure 1-2), which calculates the critical penetration risk based on geometry, shielding configurations and flight parameters. The assessment process begins by building a finite element model (FEM) of the spacecraft, which defines the size and shape of the spacecraft as well as the locations of the various shielding configurations. This model is built using the NX I-deas software package from Siemens PLM Software. The FEM is constructed using triangular and quadrilateral elements that define the outer shell of the spacecraft. Bumper-II uses the model file to determine the geometry of the spacecraft for the analysis. The next step of the process is to identify the ballistic limit characteristics for the various shield types. These ballistic limits define the critical size particle that will penetrate a shield at a given impact angle and impact velocity. When the finite element model is built, each individual element is assigned a property identifier (PID) to act as an index for its shielding properties. Using the ballistic limit equations (BLEs) built into the Bumper-II code, the shield characteristics are defined for each and every PID in the model. The final stage of the analysis is to determine the probability of no penetration (PNP) on the spacecraft. This is done using the micrometeoroid and orbital debris environment definitions that are built into the Bumper-II code. These engineering models take into account orbit inclination, altitude, attitude and analysis date in order to predict an impacting particle flux on the spacecraft. Using the geometry and shielding characteristics previously defined for the spacecraft and combining that information with the environment model calculations, the Bumper-II code calculates a probability of no penetration for the spacecraft.

Christiansen, Eric L.↗