Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “assembly instructions”

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.

70 records · Page 4
All sourcesNASA NTRSDOE OSTI
NASA NTRS2015

[Redesign of the Spacesuit Long Life Battery and the Personal Life Support System Battery]

This fall I was working on two different projects that culminated into a redesign of the spacesuit LLB (long life battery). I also did some work on the PLSS (personal life support system) battery with EC. My first project was redlining the work instruction for completing DPAs (destructive physical analysis) on battery cells in the department. The purpose of this document is to create a standard process and ensure that the data in the same way no matter who carries out the analysis. I observed three DPAs, conducted one with help, and conducted two on my own all while taking notes on the procedure. These notes were used to write the final work instruction that will become is the department standard. My second project continued the work of the summer co-op before me. I was testing aluminum heat sinks for their ability to provide good thermal conduction and structural support during a thermal runaway event. The heat sinks were designed by the summer intern but there was not much time for testing before he left. We ran tests with a heater on the bottom of a trigger cell to try to drive thermal runaway and ensure that it will not propagate to adjacent cells. We also ran heat-to-vent tests in an oven to see if the assembly provided structural support and prevented sidewall rupture during thermal runaway. These tests were carried out at ESTA (energy systems test area) and are providing very promising results that safe, high performing (greater than 180 Wh/kg) designs are possible. My main project was a redesign of the LLB battery. Another summer intern did some testing and concluded that there was no simple fix to mitigate thermal runaway propagation hazards in the current design. The only option was a clean sheet redesign of the battery. I was given a volume and ideal energy density and the rest of the design was up to me. First, I created new heat sink banks in Creo using the information gathered in the metal heat sink tests from the summer intern. After this, I made capture plates to hold the cells in place and I worked on nickel bussings for the electrical connections between the cells. Finally, I designed the test box enclosure that included sections for flame arresting materials. The battery brick design, which is the heart of the battery, promises to become the first for a manned spacecraft application to achieve greater than 180 Wh/kg. My work in redlining the DPA work instructions will also be used in selecting the cells for the battery. We had a few options of cells that would provide the necessary power output and needed to make a choice. We repeatedly charged and discharged cells for around a month until they went through 100 lifecycles. The plan is to compare the DPA results on fresh and cycled cells from each manufacturer to see if cycling introduces any differences. After the complete LLB design was approved, the parts were ordered and testing should begin the first week of December. Some of my side projects included working on the CAD data for the PLSS with EC and attending the NASA Aerospace Battery Workshop in Huntsville. I was also a member of the Tours and Lectures Committee for the USRA and Pathways interns. I coordinated Apollo Evening and was on the committee for touring KSC and seeing an Atlas 5 launch. I really enjoyed my time at JSC and I would like to continue working for NASA or another aerospace company in the future. I have worked other internships prior to this, but I think the heavy research and development focus is the best fit for me. I originally thought I would need to go to grad school to work in an environment like this, but I now see it is possible with a bachelor’s degree and hard work. I would like to go into the workforce and maybe continue my education with night classes.

Scharf, Stephanie↗
NASA NTRS2015

[Fall 2015 Abstract by Stephanie Scharf]

This Fall I worked on two different projects that culminated into a redesign of the spacesuit LLB (long life battery). I also did some work on the PLSS (personal life support system) battery with EC. My first project was redlining the work instruction for completing DPAs (destructive physical analysis) on battery cells in the Branch. The purpose of this document is to create a standard process and ensure that the data is collected in the same way, no matter who carries out the analysis. I observed three DPAs, conducted one with help, and conducted two on my own, all while taking notes on the procedure. These notes were used to write the final work instruction, which will become the Branch standard. My second project continued the work of the Summer co-op before me. I tested aluminum heat sinks for their ability to provide good thermal conduction and structural support during a thermal runaway event. The heat sinks had been designed by the previous Summer co-op, but there was not much time for testing before he left. We thus ran tests with a heater on the bottom of a trigger cell to try to drive thermal runaway and ensure that it will not propagate to adjacent cells. We also ran heat-to-vent tests in an oven to see if the assembly provided structural support and prevented sidewall rupture during thermal runaway. These tests were carried out at ESTA (Energy Systems Test Area) and are providing very promising results, indicating that safe, high performing (>180 Wh/kg) designs are possible. My main project was a redesign of the LLB (Lightweight Lithium Battery). Another summer intern had done some testing and concluded that there was no simple fix to mitigate thermal runaway propagation hazards in the existing design. The only option was a clean sheet redesign of the battery. I was given a volume and ideal energy density, and the rest of the design was up to me. First, I created new heat sink banks in CREO, using the information gathered in the metal heat sink tests from the summer intern. After this, I made capture plates to hold the cells in place, and I worked on nickel bussings for the electrical connections between the cells. Finally, I designed the test box enclosure that included sections for flame arresting materials. The battery brick design, which is the heart of the battery, promises to become the first for a manned spacecraft application to achieve > 180 Wh/kg. My work in redlining the DPA work instructions will also be used in selecting the cells for the battery. We had a few options for cells that would provide the necessary power output and needed to make a choice. We repeatedly charged and discharged cells for around a month until they went through 100 lifecycles. The plan was to compare the DPA results on fresh and cycled cells from each manufacturer to see if cycling introduces any differences. After the complete LLB design was approved, the parts were ordered and testing should begin the first week of December. Cutting open a cell for DPA After photo from oven heat-to-vent test

Scharf, Stephanie↗
NASA NTRS1993

Breadboard activities for advanced protein crystal growth

The proposed work entails the design, assembly, testing, and delivery of a turn-key system for the semi-automated determination of protein solubilities as a function of temperature. The system will utilize optical scintillation as a means of detecting and monitoring nucleation and crystallite growth during temperature lowering (or raising, with retrograde solubility systems). The deliverables of this contract are: (1) turn-key scintillation system for the semi-automatic determination of protein solubilities as a function of temperature, (2) instructions and software package for the operation of the scintillation system, and (3) one semi-annual and one final report including the test results obtained for ovostatin with the above scintillation system.

Rosenberger, Franz↗
NASA NTRS2011

FPGA Sequencer for Radar Altimeter Applications

A sequencer for a radar altimeter provides accurate attitude information for a reliable soft landing of the Mars Science Laboratory (MSL). This is a field-programmable- gate-array (FPGA)-only implementation. A table loaded externally into the FPGA controls timing, processing, and decision structures. Radar is memory-less and does not use previous acquisitions to assist in the current acquisition. All cycles complete in exactly 50 milliseconds, regardless of range or whether a target was found. A RAM (random access memory) within the FPGA holds instructions for up to 15 sets. For each set, timing is run, echoes are processed, and a comparison is made. If a target is seen, more detailed processing is run on that set. If no target is seen, the next set is tried. When all sets have been run, the FPGA terminates and waits for the next 50-millisecond event. This setup simplifies testing and improves reliability. A single vertex chip does the work of an entire assembly. Output products require minor processing to become range and velocity. This technology is the heart of the Terminal Descent Sensor, which is an integral part of the Entry Decent and Landing system for MSL. In addition, it is a strong candidate for manned landings on Mars or the Moon.

Berkun, Andrew C.↗
NASA NTRS1974

Attitude dynamics simulation subroutines for systems of hinge-connected rigid bodies

Several computer subroutines are designed to provide the solution to minimum-dimension sets of discrete-coordinate equations of motion for systems consisting of an arbitrary number of hinge-connected rigid bodies assembled in a tree topology. In particular, these routines may be applied to: (1) the case of completely unrestricted hinge rotations, (2) the totally linearized case (all system rotations are small), and (3) the mixed, or partially linearized, case. The use of the programs in each case is demonstrated using a five-body spacecraft and attitude control system configuration. The ability of the subroutines to accommodate prescribed motions of system bodies is also demonstrated. Complete listings and user instructions are included for these routines (written in FORTRAN V) which are intended as multi- and general-purpose tools in the simulation of spacecraft and other complex electromechanical systems.

Fleischer, G. E.↗
NASA NTRS2010

LRN, ERN:, & BERN @ Wireless Integrating the Sciences (WITS) Theatre

In order to develop a call to action for a learning tool that would work to best teach Science Technology Engineering and Math (STEM), the NASA Goddard team will partner with the inventor of Bop It!, an interactive game of verbs and following instructions; and Global Imagination, the developers of Magic Planet. In this paper Decision-making Orbital Health! (DOH!) will be described as a game derived from the basic functions necessary for Bop lt!, a familiar game. that will ask the educational audience to respond to changing commands to Bop It!, Twist It!, and Squeeze It! The success of the new version of the game, will be that the Earth will be making these commands from Dynamic Planet, and the crowd assembled can play wirelessly. Wireless Integrating The Sciences (WITS) Theatre : A balanced approach will describe how the communities local to Goddard and perhaps San Francisco will develop curriculum that helps kids teach kids with an engaging game and a STEM message. The performing arts will be employed to make it entertaining and appropriate to the size of the gathering, and the students educational level.

Hilliard, L.↗
NASA NTRS1978

Ball bearing heat analysis program (BABHAP)

The Ball Bearing Heat Analysis Program (BABHAP) is an attempt to assemble a series of equations, some of which are non-linear algebraic systems, in a logical order, which when solved, provide a complex analysis of load distribution among the balls, ball velocities, heat generation resulting from friction, applied load, and ball spinning, minimum lubricant film thickness, and many additional characteristics of ball bearing systems. Although initial design requirements for BABHAP were dictated by the core limitations of the PDP 11/45 computer, (approximately 8K of real words with limited number of instructions) the program dimensions can easily be expanded for large core computers such as the UNIVAC 1108. The PDP version of BABHAP is also operational on the UNIVAC system with the exception that the PDP uses 029 punch and the UNIVAC uses 026. A conversion program was written to allow transfer between machines.

Source record↗
NASA NTRS1986

A survey of the state of the art and focused research in range systems, task 2

Many communication, control, and information processing subsystems are modeled by linear systems incorporating tapped delay lines (TDL). Such optimized subsystems result in full precision multiplications in the TDL. In order to reduce complexity and cost in a microprocessor implementation, these multiplications can be replaced by single-shift instructions which are equivalent to powers of two multiplications. Since, in general, the obvious operation of rounding the infinite precision TDL coefficients to the nearest powers of two usually yield quite poor system performance, the optimum powers of two coefficient solution was considered. Detailed explanations on the use of branch-and-bound algorithms for finding the optimum powers of two solutions are given. Specific demonstration of this methodology to the design of a linear data equalizer and its implementation in assembly language on a 8080 microprocessor with a 12 bit A/D converter are reported. This simple microprocessor implementation with optimized TDL coefficients achieves a system performance comparable to the optimum linear equalization with full precision multiplications for an input data rate of 300 baud. The philosophy demonstrated in this implementation is dully applicable to many other microprocessor controlled information processing systems.

Yao, K.↗
NASA NTRS1977

Proving the correctness of the flight director program EADIFD, volume 1

EADIFD is written in symbolic assembly language for execution on the C4000 airborne computer. It is a subprogram of an aircraft navigation and guidance program and is used to generate pitch and roll command signals for use in terminal airspace. The proof of EADIFD was carried out by an inductive assertion method consisting of two parts, a verification condition generator and a source language independent proof checker. With the specifications provided by NASA, EADIFD was proved correct. The termination of the program is guaranteed and the program contains no instructions that can modify it under any conditions.

Lee, F. J.↗
NASA NTRS1994

Applications Performance on NAS Intel Paragon XP/S - 15#

The Numerical Aerodynamic Simulation (NAS) Systems Division received an Intel Touchstone Sigma prototype model Paragon XP/S- 15 in February, 1993. The i860 XP microprocessor with an integrated floating point unit and operating in dual -instruction mode gives peak performance of 75 million floating point operations (NIFLOPS) per second for 64 bit floating point arithmetic. It is used in the Paragon XP/S-15 which has been installed at NAS, NASA Ames Research Center. The NAS Paragon has 208 nodes and its peak performance is 15.6 GFLOPS. Here, we will report on early experience using the Paragon XP/S- 15. We have tested its performance using both kernels and applications of interest to NAS. We have measured the performance of BLAS 1, 2 and 3 both assembly-coded and Fortran coded on NAS Paragon XP/S- 15. Furthermore, we have investigated the performance of a single node one-dimensional FFT, a distributed two-dimensional FFT and a distributed three-dimensional FFT Finally, we measured the performance of NAS Parallel Benchmarks (NPB) on the Paragon and compare it with the performance obtained on other highly parallel machines, such as CM-5, CRAY T3D, IBM SP I, etc. In particular, we investigated the following issues, which can strongly affect the performance of the Paragon: a. Impact of the operating system: Intel currently uses as a default an operating system OSF/1 AD from the Open Software Foundation. The paging of Open Software Foundation (OSF) server at 22 MB to make more memory available for the application degrades the performance. We found that when the limit of 26 NIB per node out of 32 MB available is reached, the application is paged out of main memory using virtual memory. When the application starts paging, the performance is considerably reduced. We found that dynamic memory allocation can help applications performance under certain circumstances. b. Impact of data cache on the i860/XP: We measured the performance of the BLAS both assembly coded and Fortran coded. We found that the measured performance of assembly-coded BLAS is much less than what memory bandwidth limitation would predict. The influence of data cache on different sizes of vectors is also investigated using one-dimensional FFTs. c. Impact of processor layout: There are several different ways processors can be laid out within the two-dimensional grid of processors on the Paragon. We have used the FFT example to investigate performance differences based on processors layout.

Saini, Subhash↗
NASA NTRS2004

Lessons Learned Study Final Report for the Exploration Systems Mission Directorate

This report is the final product of a 90-day study performed for the Exploration Systems Mission Directorate. The study was to assemble lessons NASA has learned from previous programs that could help the Exploration Systems Mission Directorate pursue the Exploration vision. It focuses on those lessons that should have the greatest significance to the Directorate during the formulation of program and mission plans. The study team reviewed a large number of lessons learned reports and data bases, including the Columbia Accident Investigation Board and Rogers Commission reports on the Shuttle accidents, accident reports from robotic space flight systems, and a number of management reviews by the Defense Sciences Board, Government Accountability Office, and others. The consistency of the lessons, findings, and recommendations validate the adequacy of the data set. In addition to reviewing existing databases, a series of workshops was held at each of the NASA centers and headquarters that included senior managers from the current workforce as well as retirees. The full text of the workshop reports is included in Appendix A. A lessons learned website was opened up to permit current and retired NASA personnel and on-site contractors to input additional lessons as they arise. These new lessons, when of appropriate quality and relevance, will be brought to the attention of managers. The report consists of four parts: Part 1 provides a small set of lessons, called the Executive Lessons Learned, that represent critical lessons that the Exploration Systems Mission Directorate should act on immediately. This set of Executive Lessons and their supporting rationale have been reviewed at length and fully endorsed by a team of distinguished NASA alumni; Part 2 contains a larger set of lessons, called the Selected Lessons Learned, which have been chosen from the lessons database and center workshop reports on the basis of their specific significance and relevance to the near-term work of the Exploration Directorate. These lessons frequently support the Executive lessons but are more general in nature; Part 3 consists of the reports of the center workshops that were conducted as part of this activity. These reports are included in their entirety (approximately 200 pages) in Appendix G and have significance for specific managers; Part 4 consists of the remainder of the lessons that have been selected by this effort and assembled into a database for the use of the Explorations Directorate. The database is archived and hosted in the Lessons Learned Knowledge Network, which provides a flexible search capability using a wide variety of search terms. Finally, a spreadsheet lists databases searched and a bibliography identifies reports that have been reviewed as sources of lessons for this task. NASA has been presented with many learning opportunities. We have conducted numerous programs, some extremely successful and others total failures. Most have been documented with a formal lessons learned activity, but we have not always incorporated these learning opportunities into our normal modes of business. For example, the Robbins Report of 2001 clearly indicates that many project failures of the past two decades were the result of violating well documented best practices, often in direct violation of management instructions and directives. An overarching lesson emerges: that disciplined execution in accordance with proven best practices is the greatest single contributor to a successful program. The Lessons Learned task team offers a sincere hope that the lessons presented herein will be helpful to the Exploration Systems Directorate in charting and executing their course. The success of the Directorate and of NASA in general depends on our collective ability to move forward without having to relearn the lessons of those who have gone before.

Van Laak, Jim↗
NASA NTRS2011

Common Bolted Joint Analysis Tool

Common Bolted Joint Analysis Tool (comBAT) is an Excel/VB-based bolted joint analysis/optimization program that lays out a systematic foundation for an inexperienced or seasoned analyst to determine fastener size, material, and assembly torque for a given design. Analysts are able to perform numerous what-if scenarios within minutes to arrive at an optimal solution. The program evaluates input design parameters, performs joint assembly checks, and steps through numerous calculations to arrive at several key margins of safety for each member in a joint. It also checks for joint gapping, provides fatigue calculations, and generates joint diagrams for a visual reference. Optimum fastener size and material, as well as correct torque, can then be provided. Analysis methodology, equations, and guidelines are provided throughout the solution sequence so that this program does not become a "black box:" for the analyst. There are built-in databases that reduce the legwork required by the analyst. Each step is clearly identified and results are provided in number format, as well as color-coded spelled-out words to draw user attention. The three key features of the software are robust technical content, innovative and user friendly I/O, and a large database. The program addresses every aspect of bolted joint analysis and proves to be an instructional tool at the same time. It saves analysis time, has intelligent messaging features, and catches operator errors in real time.

Imtiaz, Kauser↗
NASA NTRS2014

Hazard Analysis for Building 34 Vacuum Glove Box Assembly

One of the characteristics of an effective safety program is the recognition and control of hazards before mishaps or failures occur. Conducting potentially hazardous tests necessitates a thorough hazard analysis in order to prevent injury to personnel, and to prevent damage to facilities and equipment. The primary purpose of this hazard analysis is to define and address the potential hazards and controls associated with the Building 34 Vacuum Glove Box Assembly, and to provide the applicable team of personnel with the documented results. It is imperative that each member of the team be familiar with the hazards and controls associated with his/her particular tasks, assignments and activities while interfacing with facility test systems, equipment and hardware. In fulfillment of the stated purposes, the goal of this hazard analysis is to identify all hazards that have the potential to harm personnel, damage the facility or its test systems or equipment, test articles, Government or personal property, or the environment. This analysis may also assess the significance and risk, when applicable, of lost test objectives when substantial monetary value is involved. The hazards, causes, controls, verifications, and risk assessment codes have been documented on the hazard analysis work sheets in Appendix A of this document. The preparation and development of this report is in accordance with JPR 1700.1, "JSC Safety and Health Handbook" and JSC 17773 Rev D "Instructions for Preparation of Hazard Analysis for JSC Ground Operations".

Meginnis, Ian↗
NASA NTRS2016

SLS Flight Software Testing: Using a Modified Agile Software Testing Approach

NASA's Space Launch System (SLS) is an advanced launch vehicle for a new era of exploration beyond earth's orbit (BEO). The world's most powerful rocket, SLS, will launch crews of up to four astronauts in the agency's Orion spacecraft on missions to explore multiple deep-space destinations. Boeing is developing the SLS core stage, including the avionics that will control vehicle during flight. The core stage will be built at NASA's Michoud Assembly Facility (MAF) in New Orleans, LA using state-of-the-art manufacturing equipment. At the same time, the rocket's avionics computer software is being developed here at Marshall Space Flight Center in Huntsville, AL. At Marshall, the Flight and Ground Software division provides comprehensive engineering expertise for development of flight and ground software. Within that division, the Software Systems Engineering Branch's test and verification (T&V) team uses an agile test approach in testing and verification of software. The agile software test method opens the door for regular short sprint release cycles. The idea or basic premise behind the concept of agile software development and testing is that it is iterative and developed incrementally. Agile testing has an iterative development methodology where requirements and solutions evolve through collaboration between cross-functional teams. With testing and development done incrementally, this allows for increased features and enhanced value for releases. This value can be seen throughout the T&V team processes that are documented in various work instructions within the branch. The T&V team produces procedural test results at a higher rate, resolves issues found in software with designers at an earlier stage versus at a later release, and team members gain increased knowledge of the system architecture by interfacing with designers. SLS Flight Software teams want to continue uncovering better ways of developing software in an efficient and project beneficial manner. Through agile testing, there has been increased value through individuals and interactions over processes and tools, improved customer collaboration, and improved responsiveness to changes through controlled planning. The presentation will describe agile testing methodology as taken with the SLS FSW Test and Verification team at Marshall Space Flight Center.

Bolton, Albanie T.↗
NASA NTRS2014

Determining the Source of Water Vapor in a Cerium Oxide Electrochemical Oxygen Separator to Achieve Aviator Grade Oxygen

More than a metric ton of water is transported to the International Space Station (ISS) each year to provide breathing oxygen for the astronauts. Water is a safe and compact form of stored oxygen. The water is electrolyzed on ISS and ambient pressure oxygen is delivered to the cabin. A much smaller amount of oxygen is used each year in spacesuits to conduct Extra Vehicular Activities (EVAs). Space suits need high pressure (>1000 psia) high purity oxygen (must meet Aviator Breathing Oxygen "ABO" specifications, >99.5% O2). The water / water electrolysis system cannot directly provide high pressure, high purity oxygen, so oxygen for EVAs is transported to ISS in high pressure gas tanks. The tanks are relatively large and heavy, and the majority of the system launch weight is for the tanks and not the oxygen. Extracting high purity oxygen from cabin air and mechanically compressing the oxygen might enable on-board production of EVA grade oxygen using the existing water / water electrolysis system. This capability might also benefit human spaceflight missions, where oxygen for EVAs could be stored in the form of water, and converted into high pressure oxygen on-demand. Cerium oxide solid electrolyte-based ion transport membranes have been shown to separate oxygen from air, and a supported monolithic wafer form of the CeO2 electrolyte membrane has been shown to deliver oxygen at pressures greater than 300 psia. These supported monolithic wafers can withstand high pressure differentials even though the membrane is very thin, because the ion transport membrane is supported on both sides (Fig 1). The monolithic supported wafers have six distinct layers, each with matched coefficients of thermal expansion. The wafers are assembled into a cell stack which allows easy air flow across the wafers, uniform current distribution, and uniform current density (Fig 2). The oxygen separation is reported to be "infinitely selective" to oxygen [1] with reported purity of 99.99% [2]. Combined with a mechanical compressor, a Solid Electrolyte Oxygen Separator (SEOS) should be capable of producing ABO grade oxygen at pressures >2400 psia, on the space station. Feasibility tests using a SEOS integrated with a mechanical compressor identified an unexpected contaminant in the oxygen: water vapour was found in the oxygen product, sometimes at concentrations higher than 40 ppm (the ABO limit for water vapour is 7 ppm). If solid electrolyte membranes are really "infinitely selective" to oxygen as they are reported to be, where did the water come from? If water is getting into the oxygen, what other contaminants might get into the oxygen? Microscopic analyses of wafers, welds, and oxygen delivery tubes were performed in an attempt to find the source of the water vapour contamination. Hot and cold pressure decay tests were performed. Measurements of water vapour as a function of O2 delivery rate, O2 delivery pressure, and process air humidity levels were the most instructive in finding the source of water contamination (Fig 3). Water contamination was directly affected by oxygen delivery rate (doubling the oxygen production rate cut the water level in half). Water was affected by process air humidity levels and delivery pressure in a way that indicates the water was diffusing into the oxygen delivery system.

Graf, John↗
NASA NTRS2001

Using Wearable Computers in Shuttle Processing: A Feasibility Study

Shuttle processing operations are performed following prescribed instructions compiled in a Work Authorization Document (WAD). Until very recently, WADs were printed so that they could be properly executed, including the buy off of each and every step by the appropriate authorizing agent. However, with the development of EPICs, Maximo, and PeopleSoft applications, some of these documents are now available in electronic format; hence, it is possible for technicians and engineers to access them on line and buy off the steps electronically. To take full advantage of these developments, technicians need access to such documents at the point of job execution. Body wearable computers present an opportunity to develop a WAD delivery system that enables access while preserving technician's mobility, safety levels, and quality of work done. The primary objectives of this project were to determine if body wearable computers are a feasible delivery system for WADs. More specifically, identify and recommend specific brands of body wearable computers readily available on the market. Thus, this effort has field-tested this technology in two areas of shuttle processing, and it has examined the usability of the technology. Results of two field tests and a Human Factors Usability Test are presented. Section 2 provides a description of the body wearable computer technology. Section 3 presents the test at the Space Shuttle Main Engine (SSME) Shop. Section 4 presents the results of the integration test at the Solid Rocket Boosters Assembly and Refurbishing Facility (SRBARF). Section 5 presents the results of the usability test done at the Operations Support Building (OSB).

Centeno, Martha A.↗