Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Development assurance”

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 1,027 records · Page 57

IV&V Planning & Execution Initiative

Independent verification and validation (IV&V) is a systems engineering discipline which seeks to provide confidence that mission-critical software-dependent systems will operate safely and achieve all mission objectives. In order to optimize application of IV&V resources, it is necessary to identify specific assurance objectives that are most likely to reveal difficulty and therefore to increase confidence. Software assurance literature deals predominantly with the code itself. However, our experience is that the most significant software-related issues are discovered via analysis of other system artifacts such as operations concepts, requirements and design. Consequently, it is desirable to, when assessing risk and defining assurance objectives, consider all facets of the software system architecture. We describe in this presentation progress and lessons learned from an IV&V capability development initiative to enhance the IV&V project planning process using all available architecture information.

Risk↗

Informing New Concepts for UAS and Autonomous System Safety Management using Disaster Management and First Responder Scenarios

As emerging flight operations become more prevalent and increasingly automated and distributed, the capabilities for managing safety of vehicles and operations will also need to evolve. To address this challenge, the National Academies has envisioned an In-Time Aviation Safety Management System (IASMS) capability for a wide range of aviation operations including current commercial operations as well as new entrants envisioned with advanced air mobility (AAM). The suite of IASMS services, functions, and capabilities (SFCs) would be implemented in a federated approach and would address trends as well as individual operations. Through predictive modeling and data analysis, IASMS is envisioned to identify arising risks so that they can be mitigated, in-time, before a safety incident occurs. IASMS and its requisite set of SFCs must leverage a wide range of information to perform. To better understand these new needs, FSF worked with the aviation and humanitarian communities to develop and validate scenarios that include traditional aviation operations and UAS operations intermingled as they are deployed for disaster management and first responder (DMFR) situations. The three scenarios developed include: • Post Natural disaster response, such as a hurricane, involving multiple parties utilizing traditional aviation and UAS to support rescue operations, surveil damage, and locate survivors needing assistance. • Wildfire fighting in remote locations with traditional aircraft for transport and fire-retardant delivery combined with UAS for surveillance of fire locations as well as to track individual firefighter locations. • Medical Operations and AAM in Urban Environments including passenger-carrying helicopters and AAM vehicles, medical missions (such as transport of radio-pharmaceuticals), and other UAS delivery operations (such as the delivery of defibrillators). Each scenario was developed and validated by representatives with expertise in humanitarian operations, urban and rural emergency response, air traffic management, UAS operations, and traditional flight operations. The scenario definitions address roles and responsibilities of individual actors, the appropriate utilization of UAS, and the actions taken by those actors to appropriately manage risks associated with the mission and environment. The risks to aviation traffic and to people on the ground explored included potential risks arising from incompatibilities in calculating reference altitudes (eg, differing uses of AGL, MSL, barometric, or GPS-derived values), loss of command and control (C2) communications, rapid changes in weather and winds, and physical interference. For each risk, IASMS SFCs were postulated in the context of monitoring services, risk assessment capabilities, and identifying appropriate mitigation strategies. The identified SFC capabilities were envisioned from known services postulated for IASMS and for UTM. For these unique environments, IASMS SFCs are needed to address conditions such as hazardous payloads, micro-climates and urban canyons, and the need to keep uninvolved air traffic out of the area where DMFR operations are being conducted. The second phase of analysis focused on inferring the specific information needs and the SFCs for IASMS, utilizing a structure of 16 information classes to organize requirements. For each of the risks identified in the workshops, it was postulated what data sources would be necessary to monitor critical aspects of the risk (eg, surrounding air traffic, ground population, terrain, etc). to be directly measured as well as data that would be derived, which implies additional SFCs for different actors to understand what information would likely be exchanged between parties. For an IASMS to be effective, additional research is needed to develop the advanced algorithms that can address the increasingly autonomous and complex operations in differing environments and to develop means of identifying unknown risks. Looking at these scenarios highlighted a number of research issues. These include the ability to quickly "cordon off" airspace thru temporary flight restrictions (TFRs) or other means, developing clear definitions to enable automation-based algorithms for prioritizing operations, defining airspace density metrics, standardization of altitude reporting, and establishing a basis for safety data metrics definition and collection. This paper seeks to outline the development of an IASMS in the context of the DMFR scenarios and resulting demonstrations. Utilizing this contextual approach, NASA will generate recommendations for an assured safety framework for AAM operations that enables AAM operations to safely access the NAS.

In Time Aviation Safety Management System↗

Can We Use the QA4ECV Black-sky Fraction of Absorbed Photosynthetically Active Radiation (FAPAR) using AVHRR Surface Reflectance to Assess Terrestrial Global Change?

NOAA platforms provide the longest period of terrestrial observation since the 1980s. The progress in calibration, atmospheric corrections and physically based land retrieval offers the opportunity to reprocess these data for extending terrestrial product time series. Within the Quality Assurance for Essential Climate Variables (QA4ECV) project, the black-sky Joint Research Centre (JRC)-fraction of absorbed photosynthetically active radiation (FAPAR) algorithm was developed for the AVHRR sensors on-board NOAA-07 to -16 using the Land Surface Reflectance Climate Data Record. The retrieval algorithm was based on the radiative transfer theory, and uncertainties were included in the products. We proposed a time and spatial composite for providing both 10-day and monthly products at 0.05º × 0.05º. Quality control and validation were achieved through benchmarking against third-party products, including Sea-Viewing Wide Field-of-View Sensor (SeaWiFS) datasets produced with the same retrieval algorithm. Past ground-based measurements, providing a proxy of FAPAR, showed good agreement of seasonality values over short homogeneous canopies and mixed vegetation. The average difference between SeaWiFS and QA4ECV monthly products over 2002–2005 is about 0.075 with a standard deviation of 0.091. We proposed a monthly linear bias correction that reduced these statistics to 0.02 and 0.001. The complete harmonized long-term time series was then used to address its fitness for the purpose of analysis of global terrestrial change.

AVHRR↗

Detecting missing struts in metallic micro-lattices using high speed melt pool thermal monitoring

Metal lattices are an important class of cellular materials that offer great advantages by providing high-strength and lightweight structures as compared to bulk materials. Progress in additive manufacturing techniques has led to increased complexity in design and shape of produced objects and is greatly beneficial for the development of metallic lattice structures. However additive manufacturing of lattices suffers from unpredictable defect creation that can compromise its mechanical integrity. Although post-build inspection techniques can provide quality assurance of the process, accurate assessment can be technically challenging, time consuming and costly. In this work, we investigate the use of high-speed measurements of thermal emission from the melt pool to identify defective individual struts formed with a missing bottom half in an otherwise fully built lattice structure produced with laser powder bed fusion. Surprisingly, results indicate lower photodiode signal, suggesting colder melt pool surface temperature, when printing struts with missing bottom half as compared to nominal struts. Additional thermographic imaging and multi-physics simulations reveal that the low photodiode signal is accompanied by presence of hot spatters carrying heat away from detection and continuous avalanche of powder on the melt pool. Based on these observations, a method was developed to identify defective individual struts with missing bottom half in full built lattices. This prediction approach provides valuable insights about part quality which are important for process qualification and illustrates the utility of melt pool thermal emission monitoring for identifying specific defects introduced by laser powder bed fusion.

36 MATERIALS SCIENCE↗

The “Gearamid” Model: Transforming NASA Langley’s Role in the Aerospace Technology Ecosystem

NASA’s operating environment is evolving: numerous new emerging technologies are converging to create breakthrough solutions, many nontraditional players are partnering to create those solutions, and a diverse array of new public-private funding models are being employed. A team at NASA’s Langley Research Center (LaRC) developed a model to describe the challenges that must be addressed for an emerging breakthrough technology to penetrate the appropriate market sector, and how all the players in the relevant ecosystem can collaborate to accelerate the market infusion process. This model, which the team dubbed the “Gearamid,” originated from a narrower study to determine what LaRC should do to capitalize on and advance autonomous technology as a “game changer” in the civil aerospace domain. The elements in the original version of the Gearamid depict the various challenges that need to be addressed as an autonomous technology proceeds from initial development to market infusion. In addition, the Gearamid indicates the “actors” best suited to address each challenge element. The study team noted that all challenge elements in the Gearamid must be worked concurrently to assure successful infusion of autonomous solutions. The team also found that NASA expertise naturally positions Agency organizations—including LaRC—to lead contributions that address certain challenge elements and to play a supplemental role in other areas where entities external to NASA are actively working and investing to solve challenges. Furthermore, the team concluded that NASA can play a leadership role in coordinating efforts of the diverse entities across the civil aerospace community. After determining the center’s optimal role in the autonomous technology development ecosystem, the study team then extrapolated the Gearamid model for autonomous technologies into a broader, more general model depicting the challenge elements that must be overcome to develop and infuse any emerging technology. LaRC has embraced the Gearamid model and is using it to drive changes that will transform the center and allow it to function optimally in the evolving landscape. Given LaRC’s successes, the study team suggests that other organizations may also be able to use the Gearamid model to inform future planning/strategy efforts.

Jill M Marlowe↗

Shuttle Shortfalls and Lessons Learned for the Sustainment of Human Space Exploration

Much debate and national soul searching has taken place over the value of the Space Shuttle which first flew in 1981 and which is currently scheduled to be retired in 2010. Originally developed post-Saturn Apollo to emphasize affordability and safety, the reusable Space Shuttle instead came to be perceived as economically unsustainable and lacking the technology maturity to assure safe, routine access to low earth orbit (LEO). After the loss of two crews, aboard Challenger and Columbia, followed by the decision to retire the system in 2010, it is critical that this three decades worth of human space flight experience be well understood. Understanding of the past is imperative to further those goals for which the Space Shuttle was a stepping-stone in the advancement of knowledge. There was significant reduction in life cycle costs between the Saturn Apollo and the Space Shuttle. However, the advancement in life cycle cost reduction from Saturn Apollo to the Space Shuttle fell far short of its goal. This paper will explore the reasons for this shortfall. Shortfalls and lessons learned can be categorized as related to design factors, at the architecture, element and sub-system levels, as well as to programmatic factors, in terms of goals, requirements, management and organization. Additionally, no review of the Space Shuttle program and attempt to take away key lessons would be complete without a strategic review. That is, how do national space goals drive future space transportation development strategies? The lessons of the Space Shuttle are invaluable in all respects - technical, as in design, program-wise, as in organizational approach and goal setting, and strategically, within the context of the generational march toward an expanded human presence in space. Beyond lessons though (and the innumerable papers, anecdotes and opinions published on this topic) this paper traces tangible, achievable steps, derived from the Space Shuttle program experience, that must be a part of any 2l century initiatives furthering a growing human presence beyond earth.

Zapata, Edgar↗

Assessment Environment for Complex Systems Software Guide

This Software Guide (SG) describes the software developed to test the Assessment Environment for Complex Systems (AECS) by the West Virginia High Technology Consortium (WVHTC) Foundation's Mission Systems Group (MSG) for the National Aeronautics and Space Administration (NASA) Aeronautics Research Mission Directorate (ARMD). This software is referred to as the AECS Test Project throughout the remainder of this document. AECS provides a framework for developing, simulating, testing, and analyzing modern avionics systems within an Integrated Modular Avionics (IMA) architecture. The purpose of the AECS Test Project is twofold. First, it provides a means to test the AECS hardware and system developed by MSG. Second, it provides an example project upon which future AECS research may be based. This Software Guide fully describes building, installing, and executing the AECS Test Project as well as its architecture and design. The design of the AECS hardware is described in the AECS Hardware Guide. Instructions on how to configure, build and use the AECS are described in the User's Guide. Sample AECS software, developed by the WVHTC Foundation, is presented in the AECS Software Guide. The AECS Hardware Guide, AECS User's Guide, and AECS Software Guide are authored by MSG. The requirements set forth for AECS are presented in the Statement of Work for the Assessment Environment for Complex Systems authored by NASA Dryden Flight Research Center (DFRC). The intended audience for this document includes software engineers, hardware engineers, project managers, and quality assurance personnel from WVHTC Foundation (the suppliers of the software), NASA (the customer), and future researchers (users of the software). Readers are assumed to have general knowledge in the field of real-time, embedded computer software development.

tests↗

Survey of Verification and Validation Techniques for Small Satellite Software Development

The purpose of this paper is to provide an overview of the current trends and practices in small-satellite software verification and validation. This document is not intended to promote a specific software assurance method. Rather, it seeks to present an unbiased survey of software assurance methods used to verify and validate small satellite software and to make mention of the benefits and value of each approach. These methods include simulation and testing, verification and validation with model-based design, formal methods, and fault-tolerant software design with run-time monitoring. Although the literature reveals that simulation and testing has by far the longest legacy, model-based design methods are proving to be useful for software verification and validation. Some work in formal methods, though not widely used for any satellites, may offer new ways to improve small satellite software verification and validation. These methods need to be further advanced to deal with the state explosion problem and to make them more usable by small-satellite software engineers to be regularly applied to software verification. Last, it is explained how run-time monitoring, combined with fault-tolerant software design methods, provides an important means to detect and correct software errors that escape the verification process or those errors that are produced after launch through the effects of ionizing radiation.

Small Satellite Technology↗

Evaluation of Open-Source Hard Real Time Software Packages

Reliable software is, at times, hard to find. No piece of software can be guaranteed to work in every situation that may arise during its use here at Glenn Research Center or in space. The job of the Software Assurance (SA) group in the Risk Management Office is to rigorously test the software in an effort to ensure it matches the contract specifications. In some cases the SA team also researches new alternatives for selected software packages. This testing and research is an integral part of the department of Safety and Mission Assurance. Real Time operation in reference to a computer system is a particular style of handing the timing and manner with which inputs and outputs are handled. A real time system executes these commands and appropriate processing within a defined timing constraint. Within this definition there are two other classifications of real time systems: hard and soft. A soft real time system is one in which if the particular timing constraints are not rigidly met there will be no critical results. On the other hand, a hard real time system is one in which if the timing constraints are not met the results could be catastrophic. An example of a soft real time system is a DVD decoder. If the particular piece of data from the input is not decoded and displayed to the screen at exactly the correct moment nothing critical will become of it, the user may not even notice it. However, a hard real time system is needed to control the timing of fuel injections or steering on the Space Shuttle; a delay of even a fraction of a second could be catastrophic in such a complex system. The current real time system employed by most NASA projects is Wind River's VxWorks operating system. This is a proprietary operating system that can be configured to work with many of NASA s needs and it provides very accurate and reliable hard real time performance. The down side is that since it is a proprietary operating system it is also costly to implement. The prospect of replacing this somewhat costly implementation is the focus of one of the SA group s current research projects. The explosion of open source software in the last ten years has led to the development of a multitude of software solutions which were once only produced by major corporations. The benefits of these open projects include faster release and bug patching cycles as well as inexpensive if not free software solutions. The main packages for hard real time solutions under Linux are Real Time Application Interface (RTAI) and two varieties of Real Time Linux (RTL), RTLFree and RTLPro. During my time here at NASA I have been testing various hard real time solutions operating as layers on the Linux Operating System. All testing is being run on an Intel SBC 2590 which is a common embedded hardware platform. The test plan was provided to me by the Software Assurance group at the start of my internship and my job has been to test the systems by developing and executing the test cases on the hardware. These tests are constructed so that the Software Assurance group can get hard test data for a comparison between the open source and proprietary implementations of hard real time solutions.

Mattei, Nicholas S.↗

Heuristic algorithms for design of integrated monitoring of geologic carbon storage sites

Designs for Risk Evaluation and Management (DREAM) is a tool developed under the National Risk Assessment Partnership (NRAP) to enhance geologic carbon storage safety and efficiency. Using potential leakage scenarios generated externally by the users preferred history-matching approach, DREAM constructs ideal combinations of sensor locations in the right place at the right time to detect as many leaks as possible, detect them as early as possible, and minimize cost. This user-friendly tool, developed in Java, features a window-based GUI for input and a 3D visualization tool for viewing the domain space and optimized monitoring plans. DREAM's latest version accommodates real-world usage by allowing for joint optimization of wellbore point sensor placements and surface geophysics survey geometries, and by using more efficient multi-objective optimization algorithms. We show an example where, these two improvements combined allow us to support containment assurance and go from detecting 80–90 % of the potential CO 2 leakage to +99.7 %, a step-change improvement that can make the deciding difference in whether a site is suitable for geologic carbon storage. Though developed for geologic carbon storage, this tool would be equally applicable in many surface or offshore environmental monitoring projects.

58 GEOSCIENCES↗

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.↗

Miniature EVA Software Defined Radio

As NASA embarks upon developing the Next-Generation Extra Vehicular Activity (EVA) Radio for deep space exploration, the demands on EVA battery life will substantially increase. The number of modes and frequency bands required will continue to grow in order to enable efficient and complex multi-mode operations including communications, navigation, and tracking applications. Whether conducting astronaut excursions, communicating to soldiers, or first responders responding to emergency hazards, NASA has developed an innovative, affordable, miniaturized, power-efficient software defined radio that offers unprecedented power-efficient flexibility. This lightweight, programmable, S-band, multi-service, frequency- agile EVA software defined radio (SDR) supports data, telemetry, voice, and both standard and high-definition video. Features include a modular design, an easily scalable architecture, and the EVA SDR allows for both stationary and mobile battery powered handheld operations. Currently, the radio is equipped with an S-band RF section. However, its scalable architecture can accommodate multiple RF sections simultaneously to cover multiple frequency bands. The EVA SDR also supports multiple network protocols. It currently implements a Hybrid Mesh Network based on the 802.11s open standard protocol. The radio targets RF channel data rates up to 20 Mbps and can be equipped with a real-time operating system (RTOS) that can be switched off for power-aware applications. The EVA SDR's modular design permits implementation of the same hardware at all Network Nodes concept. This approach assures the portability of the same software into any radio in the system. It also brings several benefits to the entire system including reducing system maintenance, system complexity, and development cost.

Pozhidaev, Aleksey↗

The DevOps : a concise understanding to the DevOps philosophy and science

This writing examines the DevOps practice from a new perspective, one of understanding its philosophical and scientific nature. DevOps has fundamentally changed the landscape for research and development based on guiding philosophical and scientific principles. Advanced computational technologies and domains have adopted DevOps to enable advanced solution engineering for efficient, quality-assured output. The author provides a concise account of how the philosophy and science of DevOps synergistically defines its essential disposition.

42 ENGINEERING↗

Evaluation of Minimum Detectable Activities for Stack Sample Analyses

The Rad-NESHAP program takes samples at major point sources to track how much of select nuclides are being emitted out of the stack. Samples are taken at the site where the radiological operations are being performed. The samples are then sent to analytical laboratories for analysis to determine what nuclides exist in the sample. However, due to the sensitivity of the instruments, false positives are often reported. To reduce the number of false positives, the results reported from the analytical labs are compared to set detection limits. Anything below the set detection limit is considered part of the background while anything above the limit is considered a positive hit. Therefore, the detection limit must be set low enough that any false negatives do not result in a significant dose missed at the end of the year but high enough that there are not enough false positives to skew the annual dose being reported. All detection limits listed in this section for the analyses below were designed to meet the stated equivalent emissions rate and subsequent off-site doses. These minimum detectable activities (MDAs) were developed in the 1990s and documented in the memo cited for each analysis below. These limits and memos are all currently referenced in the Quality Assurance Project Plan (QAPP) for the Rad-NESHAP Compliance Task, which is being updated to a Project Implementation Plan (PIP) concurrently with this document. As part of this update process, the original MDAs defined in this section needed to be verified that they were still conservative and meet the off-site dose levels stated.

2019 MDA↗

Characterization of MC&A for the Molten Salt Fuel Cycle

Advanced reactor developers are exploring diverse reactor designs, including molten salt reactors (MSRs). These advanced reactors are considered for wider applications and a range of deployment locations, including supporting the integration of renewable energy sources in the grid. There are three main types of MSRs: (1) reactors in which the fuel salt freely circulates within the core; (2) reactors with the fuel salt contained within vented fuel tubes; and (3) reactors that use molten salt solely as a coolant, with the fuel in a separate, solid form. In this document, the term MSR refers specifically to the first two types, which use fuel salt—special nuclear material (enriched uranium, plutonium, and 233 U) in chloride or fluoride form mixed with chloride- or fluoride-based carrier salt in a peritectic mixture—as the primary medium for fission. The composition of fuel salt, both at startup and for makeup or refueling, varies depending on the MSR design and the chosen fuel cycle approach, which can be either once-through or closed. For MSRs, a variety of fuel cycle approaches (e.g., U, U–Pu, U–Pu–TRU, U–Th, U–Pu–Th) are being considered. Fuel in MSRs is much different than traditional solid fuel, including its preparation. The uniqueness warrants investigation into characterizing fuel preparation processes, known as fuel salt synthesis . This effort characterized major fuel preparation and synthesis processes, identifying temperature, equipment, and environmental requirements for uranium-, plutonium-, and thorium-based fuel preparation and synthesis. Because MSR fuel salt synthesis facilities handle special nuclear material in loose, bulk form, a material control and accounting plan will be required for licensing from the US Nuclear Regulatory Commission or under the US Department of Energy authorization. This effort serves as a foundation to investigate material control and accounting approaches for synthesis facilities, including determining measurement points and techniques. Because several MSR developers are planning demonstration facilities in the coming years, this effort will support stakeholders with preparing or reviewing material control and accounting plans for providing assurance that all special nuclear material is accounted for at fuel salt synthesis facilities. This report was produced for Materials Protection, Accounting, and Control Technologies (MPACT) program under the US Department of Energy (DOE), Office of Nuclear Energy, Nuclear Fuel Cycle and Supply Chain.

11 NUCLEAR FUEL CYCLE AND FUEL MATERIALS↗

Membrane water deaerator investigation

The purpose of the membrane water deaerator program was to develop data on a breadboard hollow fiber membrane unit that removes both dissolved and evolved gas from a water transfer system in order to: (1) assure a hard fill of the EVLSS expendable water tank; (2) prevent flow blockage by gas bubbles in circulating systems; and (3) prevent pump cavitation.

Elam, J.↗

Spacelab program requirements, level 1

The design and development of Spacelab is reported including the ground support equipment, facilities, and operational planning. The shuttle interface, and user requirements are discussed along with product assurance and safety.

Source record↗

On-board computer progress in development of A 310 flight testing program

Onboard computer progress in development of an Airbus A 310 flight testing program is described. Minicomputers were installed onboard three A 310 airplanes in 1979 in order to: (1) assure the flight safety by exercising a limit check of a given set of parameters; (2) improve the efficiency of flight tests and allow cost reduction; and (3) perform test analysis on an external basis by utilizing onboard flight types. The following program considerations are discussed: (1) conclusions based on simulation of an onboard computer system; (2) brief descriptions of A 310 airborne computer equipment, specifically the onboard universal calculator (CUB) consisting of a ROLM 1666 system and visualization system using an AFIGRAF CRT; (3) the ground system and flight information inputs; and (4) specifications and execution priorities for temporary and permanent programs.

Reau, P.↗