Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “hardware and software”

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 469 records · Page 26
All sourcesNASA NTRSDOE OSTI
DOE OSTI2020

Software Framework for Federated Science Instruments

There is an unprecedented promise of enhanced capabilities for federations of leadership computing systems and experimental science facilities by leveraging software technologies for fast and efficient operations. These federations seek to unify different science instruments, both computing and experimental, to effectively support science users and operators to execute complex workflows. The FedScI project addresses the software challenges associated with the formation and operation of federated environments by leveraging recent advances in containerization of software and softwarization of hardware. We propose a software framework to streamline the federation usage by science users and it’s provisioning and operations by facility providers. A distinguishing element of our work is the support for improved interaction between experimental devices, such as beam-line instruments, and more traditional high-performance computing resources, including compute, network, storage systems. We present guiding principles for the software framework and highlight portions of a current prototype implementation. We describe our science use case involving neutron imaging beam-lines (SNAP/BL-3, Imaging/CG-1D) at the Spallation Neutron Source and High Flux Isotope Reactor facilities at Oak Ridge National Laboratory. Additionally, we detail plans for a more direct instrument interaction within a federated environment, which could enable more advanced workflows with feedback loops to shorten the time to science.

Naughton III, Thomas↗
NASA NTRS1988

TES: A modular systems approach to expert system development for real-time space applications

A major goal of the Space Station era is to reduce reliance on support from ground based experts. The development of software programs using expert systems technology is one means of reaching this goal without requiring crew members to become intimately familiar with the many complex spacecraft subsystems. Development of an expert systems program requires a validation of the software with actual flight hardware. By combining accurate hardware and software modelling techniques with a modular systems approach to expert systems development, the validation of these software programs can be successfully completed with minimum risk and effort. The TIMES Expert System (TES) is an application that monitors and evaluates real time data to perform fault detection and fault isolation tasks as they would otherwise be carried out by a knowledgeable designer. The development process and primary features of TES, a modular systems approach, and the lessons learned are discussed.

Cacace, Ralph↗
NASA NTRS1995

The widest practicable dissemination: The NASA technical report server

The search for innovative methods to distribute NASA's information lead a gross-roots team to create the NASA Technical Report Server (NTRS), which uses the World Wide Web and other popular Internet-based information systems as search engines. The NTRS is an inter-center effort which provides uniform access to various distributed publication servers residing on the Internet. Users have immediate desktop access to technical publications from NASA centers and institutes. This paper presents the NTRS architecture, usage metrics, and the lessons learned while implementing and maintaining the services over the initial 6-month period. The NTRS is largely constructed with freely available software running on existing hardware. NTRS builds upon existing hardware and software, and the resulting additional exposure for the body of literature contained will allow NASA to ensure that its institutional knowledge base will continue to receive the widest practicable and appropriate dissemination.

Nelson, Michael L.↗
NASA NTRS1995

The widest practicable dissemination: The NASA technical report server

The National Aeronautics and Space Act of 1958 established NASA and charged it to 'provide for the widest practicable and appropriate dissemination of information concerning...its activities and the results thereof.' The search for innovative methods to distribute NASA's information lead a grass-roots team to create the NASA Technical Report Server (NTRS), which uses the World Wide Web and other popular Internet-based information systems as search engines. The NTRS is an inter-center effort which provides uniform access to various distributed publication servers residing on the Internet. Users have immediate desktop access to technical publications from NASA centers and institutes. The NTRS is comprised of several units, some constructed especially for inclusion in NTRS, and others that are existing NASA publication services that NTRS reuses. This paper presents the NTRS architecture, usage metrics, and the lessons learned while implementing and maintaining the services over the initial six-month period. The NTRS is largely constructed with freely available software running on existing hardware. NTRS builds upon existing hardware and software, and the resulting additional exposure for the body of literature contained will allow NASA to ensure that its institutional knowledge base will continue to receive the widest practicable and appropriate dissemination.

Nelson, Michael L.↗
NASA NTRS1995

The Widest Practicable Dissemination: The NASA Technical Report Server

The National Aeronautics and Space Act of 1958 established NASA and charged it to "provide for the widest practicable and appropriate dissemination of information concerning [...] its activities and the results thereof." The search for innovative methods to distribute NASA s information lead a grass-roots team to create the NASA Technical Report Server (NTRS), which uses the World Wide Web and other popular Internet-based information systems as search engines. The NTRS is an inter-center effort which provides uniform access to various distributed publication servers residing on the Internet. Users have immediate desktop access to technical publications from NASA centers and institutes. The NTRS is comprised of several units, some constructed especially for inclusion in NTRS, and others that are existing NASA publication services that NTRS reuses. This paper presents the NTRS architecture, usage metrics, and the lessons learned while implementing and maintaining the services over the initial 6-month period. The NTRS is largely constructed with freely available software running on existing hardware. NTRS builds upon existing hardware and software, and the resulting additional exposure for the body of literature contained will allow NASA to ensure that its institutional knowledge base will continue to receive the widest practicable and appropriate dissemination.

Nelson, Michael L.↗
NASA NTRS1995

The NASA Technical Report Server

The National Aeronautics and Space Act of 1958 established NASA and charged it to "provide for the widest practicable and appropriate dissemination of information concerning its activities and the results thereof." The search for innovative methods to distribute NASA's information lead a grass-roots team to create the NASA Technical Report Server (NTRS), which uses the World Wide Web and other popular Internet-based information systems as search engines. The NTRS is an inter-center effort which provides uniform access to various distributed publication servers residing on the Internet. Users have immediate desktop access to technical publications from NASA centers and institutes. The NTRS is comprised of several units, some constructed especially for inclusion in NTRS, and others that are existing NASA publication services that NTRS reuses. This paper presents the NTRS architecture, usage metrics, and the lessons learned while implementing and maintaining the service. The NTRS is largely constructed with freely available software running on existing hardware. NTRS builds upon existing hardware and software, and the resulting additional exposure for the body of literature contained ensures that NASA's institutional knowledge base will continue to receive the widest practicable and appropriate dissemination.

Nelson, Michael L.↗
NASA NTRS2009

Modeling and Simulation of Variable Mass, Flexible Structures

The advent of the new Ares I launch vehicle has highlighted the need for advanced dynamic analysis tools for variable mass, flexible structures. This system is composed of interconnected flexible stages or components undergoing rapid mass depletion through the consumption of solid or liquid propellant. In addition to large rigid body configuration changes, the system simultaneously experiences elastic deformations. In most applications, the elastic deformations are compatible with linear strain-displacement relationships and are typically modeled using the assumed modes technique. The deformation of the system is approximated through the linear combination of the products of spatial shape functions and generalized time coordinates. Spatial shape functions are traditionally composed of normal mode shapes of the system or even constraint modes and static deformations derived from finite element models of the system. Equations of motion for systems undergoing coupled large rigid body motion and elastic deformation have previously been derived through a number of techniques [1]. However, in these derivations, the mode shapes or spatial shape functions of the system components were considered constant. But with the Ares I vehicle, the structural characteristics of the system are changing with the mass of the system. Previous approaches to solving this problem involve periodic updates to the spatial shape functions or interpolation between shape functions based on system mass or elapsed mission time. These solutions often introduce misleading or even unstable numerical transients into the system. Plus, interpolation on a shape function is not intuitive. This paper presents an approach in which the shape functions are held constant and operate on the changing mass and stiffness matrices of the vehicle components. Each vehicle stage or component finite element model is broken into dry structure and propellant models. A library of propellant models is used to describe the distribution of mass in the fuel tank or Solid Rocket Booster (SRB) case for various propellant levels. Based on the mass consumed by the liquid engine or SRB, the appropriate propellant model is coupled with the dry structure model for the stage. Then using vehicle configuration data, the integrated vehicle model is assembled and operated on by the constant system shape functions. The system mode shapes and frequencies can then be computed from the resulting generalized mass and stiffness matrices for that mass configuration. The rigid body mass properties of the vehicle are derived from the integrated vehicle model. The coupling terms between the vehicle rigid body motion and elastic deformation are also updated from the constant system shape functions and the integrated vehicle model. This approach was first used to analyze variable mass spinning beams and then prototyped into a generic dynamics simulation engine. The resulting code was tested against Crew Launch Vehicle (CLV-)class problems worked in the TREETOPS simulation package and by Wilson [2]. The Ares I System Integration Laboratory (SIL) is currently being developed at the Marshall Space Flight Center (MSFC) to test vehicle avionics hardware and software in a hardware-in-the-loop (HWIL) environment and certify that the integrated system is prepared for flight. The Ares I SIL utilizes the Ares Real-Time Environment for Modeling, Integration, and Simulation (ARTEMIS) tool to simulate the launch vehicle and stimulate avionics hardware. Due to the presence of vehicle control system filters and the thrust oscillation suppression system, which are tuned to the structural characteristics of the vehicle, ARTEMIS must incorporate accurate structural models of the Ares I launch vehicle. The ARTEMIS core dynamics simulation models the highly coupled nature of the vehicle flexible body dynamics, propellant slosh, and vehicle nozzle inertia effects combined with mass and flexible body properties that vary significant with time during the flight. All forces that act on the vehicle during flight must be simulated, including deflected engine thrust force, spatially distributed aerodynamic forces, gravity, and reaction control jet thrust forces. These forces are used to excite an integrated flexible vehicle, slosh, and nozzle dynamics model for the vehicle stack that simulates large rigid body translations and rotations along with small elastic deformations. Highly effective matrix math operations on a distributed, threaded high-performance simulation node allow ARTEMIS to retain up to 30 modes of flex for real-time simulation. Stage elements that separate from the stack during flight are propagated as independent rigid six degrees of freedom (6DOF) bodies. This paper will present the formulation of the resulting equations of motion, solutions to example problems, and describe the resulting dynamics simulation engine within ARTEMIS.

Tobbe, Patrick A.↗
NASA NTRS2006

Detection of Water Hazards for Autonomous Robotic Vehicles

Four methods of detection of bodies of water are under development as means to enable autonomous robotic ground vehicles to avoid water hazards when traversing off-road terrain. The methods involve processing of digitized outputs of optoelectronic sensors aboard the vehicles. It is planned to implement these methods in hardware and software that would operate in conjunction with the hardware and software for navigation and for avoidance of solid terrain obstacles and hazards. The first method, intended for use during the day, is based on the observation that, under most off-road conditions, reflections of sky from water are easily discriminated from the adjacent terrain by their color and brightness, regardless of the weather and of the state of surface waves on the water. Accordingly, this method involves collection of color imagery by a video camera and processing of the image data by an algorithm that classifies each pixel as soil, water, or vegetation according to its color and brightness values (see figure). Among the issues that arise is the fact that in the presence of reflections of objects on the opposite shore, it is difficult to distinguish water by color and brightness alone. Another issue is that once a body of water has been identified by means of color and brightness, its boundary must be mapped for use in navigation. Techniques for addressing these issues are under investigation. The second method, which is not limited by time of day, is based on the observation that ladar returns from bodies of water are usually too weak to be detected. In this method, ladar scans of the terrain are analyzed for returns and the absence thereof. In appropriate regions, the presence of water can be inferred from the absence of returns. Under some conditions in which reflections from the bottom are detectable, ladar returns could, in principle, be used to determine depth. The third method involves the recognition of bodies of water as dark areas in short-wavelength infrared (SWIR) images. This method is based on the fact, well known among experts in remote sensing, that water bodies of any appreciable depth appear very dark in near-infrared, overhead imagery. Even under a thick layer of marine fog, SWIR illumination is present. Hence, this method may work even in the presence of clouds, though it is unlikely to work at night. Snow and ice also exhibit very strong absorption at wavelengths greater than about 1.4 m. Hence, the wavelength range of about 1.5 to 1.6 m might be useable in this method for recognizing water, snow, and ice. One notable drawback of this method is that useful look-ahead distance could be limited by surface reflections. The fourth method, intended for use at night, involves the contrast between water and terrain in thermal-infrared (medium-wavelength infrared) imagery. This method is based on the fact that at night, water is usually warmer than the adjacent terrain. Look-ahead distance could be limited in this method because, for reasons not yet fully understood, water appears to darken in the thermal infrared with increasing distance.

Matthes, Larry↗
NASA NTRS2000

Hardware Development Process for Human Research Facility Applications

The simple goal of the Human Research Facility (HRF) is to conduct human research experiments on the International Space Station (ISS) astronauts during long-duration missions. This is accomplished by providing integration and operation of the necessary hardware and software capabilities. A typical hardware development flow consists of five stages: functional inputs and requirements definition, market research, design life cycle through hardware delivery, crew training, and mission support. The purpose of this presentation is to guide the audience through the early hardware development process: requirement definition through selecting a development path. Specific HRF equipment is used to illustrate the hardware development paths. The source of hardware requirements is the science community and HRF program. The HRF Science Working Group, consisting of SCientists from various medical disciplines, defined a basic set of equipment with functional requirements. This established the performance requirements of the hardware. HRF program requirements focus on making the hardware safe and operational in a space environment. This includes structural, thermal, human factors, and material requirements. Science and HRF program requirements are defined in a hardware requirements document which includes verification methods. Once the hardware is fabricated, requirements are verified by inspection, test, analysis, or demonstration. All data is compiled and reviewed to certify the hardware for flight. Obviously, the basis for all hardware development activities is requirement definition. Full and complete requirement definition is ideal prior to initiating the hardware development. However, this is generally not the case, but the hardware team typically has functional inputs as a guide. The first step is for engineers to conduct market research based on the functional inputs provided by scientists. CommerCially available products are evaluated against the science requirements as well as modifications needed to meet program requirements. Options are consolidated and the hardware development team reaches a hardware development decision point. Within budget and schedule constraints, the team must decide whether or not to complete the hardware as an in-house, subcontract with vendor, or commercial-off-the-shelf (COTS) development. An in-house development indicates NASA personnel or a contractor builds the hardware at a NASA site. A subcontract development is completed off-site by a commercial company. A COTS item is a vendor product available by ordering a specific part number. The team evaluates the pros and cons of each development path. For example, in-bouse developments utilize existing corporate knowledge regarding bow to build equipment for use in space. However, technical expertise would be required to fully understand the medical equipment capabilities, such as for an ultrasound system. It may require additional time and funding to gain the expertise that commercially exists. The major benefit of subcontracting a hardware development is the product is delivered as an end-item and commercial expertise is utilized. On the other hand, NASA has limited control over schedule delays. The final option of COTS or modified COTS equipment is a compromise between in-house and subcontracts. A vendor product may exist that meets all functional requirements but req uires in-house modifications for successful operation in a space environment. The HRF utilizes equipment developed using all of the paths described: inhouse, subcontract, and modified COTS.

Bauer, Liz↗
NASA NTRS1996

Evaluation of an Anthropometric Human Body Model for Simulated EVA Task Assessment

One of the more mission-critical tasks performed in space is extravehicular activity (EVA) which requires the astronaut to be external to the station or spacecraft, and subsequently at risk from the many threats posed by space. These threats include, but are not limited to: no significant atmosphere, harmful electromagnetic radiation, micrometeoroids, and space debris. To protect the astronaut from this environment, a special EVA suit is worn which is designed to maintain a sustainable atmosphere (at 1/3 atmosphere) and provide protection against the hazards of space. While the EVA suit serves these functions well, it does impose limitations on the astronaut as a consequence of the safety it provides. Since the astronaut is in a virtual vacuum, any atmospheric pressure inside the suit serves to pressurize the suit and restricts mobility of flexible joints (such as fabric). Although some of the EVA suit joints are fixed, rotary-style joints, most of the mobility is achieved by the simple flexibility of the fabric. There are multiple layers of fabric, each of which serves a special purpose in the safety of the astronaut. These multiple layers add to the restriction of motion the astronaut experiences in the space environment. Ground-based testing is implemented to evaluate the capability of EVA-suited astronauts to perform the various tasks in space. In addition to the restriction of motion imposed by the EVA suit, most EVA activity is performed in a micro-gravity (weight less) environment. To simulate weightlessness EVA-suited testing is performed in a neutral buoyancy simulator (NBS). The NBS is composed of a large container of water (pool) in which a weightless environment can be simulated. A subject is normally buoyant in the pressurized suit; however he/she can be made neutrally buoyant with the addition of weights. In addition, most objects the astronaut must interface with in the NBS sink in water and flotation must be added to render them "weightless". The implementation of NBS testing has proven to invaluable in the assessment of EVA activities performed with the Orbiter and is considered to be a key step in the construction of the International Space Station (ISS). While the NBS testing is extremely valuable, it does require considerable overhead to maintain and operate. It has been estimated that the cost of utilizing the facility is approximately $10,000 per day. Therefore it is important to maximize the utility of NBS testing for optimal results. One important aspect to consider in any human/worksite interface is the considerable wealth of anthropometric and ergonomic data available. A subset of this information specific to EVA activity is available in NASA standard 3000. The difficulty in implementing this data is that most of the anthropometric information is represented in a two-dimensional format. This poses some limitations in complete evaluation of the astronaut's capabilities in a three-dimensional environment. Advances in computer hardware and software have provided for three-dimensional design and implementation of hardware with the advance of computer aided design (CAD) software. There are a number of CAD products available and most companies and agencies have adopted CAD as a fundamental aspect of the design process. Another factor which supports the use of CAD is the implementation of computer aided manufacturing (CAM) software and hardware which provides for rapid prototyping and decreases the time to product in the design process. It is probable that most hardware to be accessed by astronauts in EVA or IVA (intravehicular activity) has been designed by a CAD system, and is therefore represented in three-dimensional space for evaluation. Because of the implementation of CAD systems and the movement towards early prototyping, a need has arisen in industry and government for tools which facilitate the evaluation of ergonomic consideration in a three-dimensional environment where the hardware has been designed by the CAD tools. One such product is Jack which was developed by the University of Pennsylvania with funding from several government agencies, including NASA. While the primary purpose of Jack is to model human figures in a ground-based (gravity) environment, it can be utilized to evaluate EVA-suited activities as well. The effects of simulated gravity must be turned off by turning off "behaviors". Although Jack provides human figures for manipulation, the primary instrument to be evaluated for EVA mobility is the work envelope provided by the EVA suit. An EVA Jack suit model has been developed by NASA-JSC and was utilized in this study. This suit model provided a more restrictive motion environment as expected for an EVA suited subject. As part of this study, the anthropometric dimensions for a 50th percentile male were compared with basic anthropometric data and were found to be representative for the population group expected in the NASA flight program. The joints for the suit were created in a manner which provided consistent performance with EVA reach envelopes published in NASA standard #3000.

Etter, Brad↗
NASA NTRS2008

Open Architecture Standard for NASA's Software-Defined Space Telecommunications Radio Systems

NASA is developing an architecture standard for software-defined radios used in space- and ground-based platforms to enable commonality among radio developments to enhance capability and services while reducing mission and programmatic risk. Transceivers (or transponders) with functionality primarily defined in software (e.g., firmware) have the ability to change their functional behavior through software alone. This radio architecture standard offers value by employing common waveform software interfaces, method of instantiation, operation, and testing among different compliant hardware and software products. These common interfaces within the architecture abstract application software from the underlying hardware to enable technology insertion independently at either the software or hardware layer. This paper presents the initial Space Telecommunications Radio System (STRS) Architecture for NASA missions to provide the desired software abstraction and flexibility while minimizing the resources necessary to support the architecture.

Reinhart, Richard C.↗
NASA NTRS1988

Transmission delays in hardware clock synchronization

Various methods, both with software and hardware, have been proposed to synchronize a set of physical clocks in a system. Software methods are very flexible and economical but suffer an excessive time overhead, whereas hardware methods require no time overhead but are unable to handle transmission delays in clock signals. The effects of nonzero transmission delays in synchronization have been studied extensively in the communication area in the absence of malicious or Byzantine faults. The authors show that it is easy to incorporate the ideas from the communication area into the existing hardware clock synchronization algorithms to take into account the presence of both malicious faults and nonzero transmission delays.

Shin, Kang G.↗
NASA NTRS2012

Space Telecommunications Radio System (STRS) Architecture Standard. Release 1.02.1

This document contains the NASA architecture standard for software defined radios used in space- and ground-based platforms to enable commonality among radio developments to enhance capability and services while reducing mission and programmatic risk. Transceivers (or transponders) with functionality primarily defined in software (e.g., firmware) have the ability to change their functional behavior through software alone. This radio architecture standard offers value by employing common waveform software interfaces, method of instantiation, operation, and testing among different compliant hardware and software products. These common interfaces within the architecture abstract application software from the underlying hardware to enable technology insertion independently at either the software or hardware layer.

Reinhart, Richard C.↗
NASA NTRS1992

Design of a nickel-hydrogen battery simulator for the NASA EOS testbed

The hardware and software design of a nickel-hydrogen (Ni-H2) battery simulator (BS) with application to the NASA Earth Observation System (EOS) satellite is presented. The battery simulator is developed as a part of a complete testbed for the EOS satellite power system. The battery simulator involves both hardware and software components. The hardware component includes the capability of sourcing and sinking current at a constant programmable voltage. The software component includes the capability of monitoring the battery's ampere-hours (Ah) and programming the battery voltage according to an empirical model of the nickel-hydrogen battery stored in a computer.

Gur, Zvi↗
DOE OSTI2025

Using a Large Language Model as a Building Block to Generate Usable Validation and Verification Suite for OpenMP

In the HPC area, both hardware and software move quickly. Often new hardware is developed and deployed, the corresponding software stack, including compilers and other tools, are under active development while leading edge software developers are working to port and tune their applications, all at the same time. While the software ecosystem is in flux, one of the key challenges for users is obtaining insight into the state of implementation of key features in the programming languages and models their applications are using – whether they have been implemented, and whether the implementation conforms to the specification, especially for newly implemented features (less tested by widespread use). OpenMP is one of the most prominent shared memory programming models used for on-node programming in HPC. With the shift towards accelerators (such as GPUs and FPGAs) and heterogeneous programming OpenMP features are getting more complex. It is natural to ask whether generative AI approaches, and large language models (LLMs) in particular, can help in producing validation and verification test suites to allow users better and faster insights into the availability and correctness of OpenMP features of interest. In this work, we explore the use of ChatGPT-4 to generate a suite of tests for OpenMP features. We have chosen a set of directives and clauses, a total of 78 combinations, which first appeared in OpenMP 3.0 (released in May 2008) but are also relevant for accelerators. We prompted ChatGPT to generate tests in the C and Fortran languages, for both host (CPU) and device (accelerator). On the Summit super-computer using the GNU implementation, we found that, of the 78 generated tests 67 C tests and 43 Fortran tests compiled successfully and fewer than those executed to completion. On further analysis we show that not all generated tests are valid. We document the process, results, and provide detailed analysis regarding the quality of tests generated. With the aim of providing input to a production quality validation and verification suite, we manually implement the corrections required to make the tests valid according to the current OpenMP specification. We quantify this effort as small, medium, or large, and record the lines of code changed to correct the invalid tests. With the corrected tests we validate recent implementations from HPE, AMD, and GNU on the Frontier supercomputer. Our experiment and subsequent analysis show that although LLMs are capable of producing HPC specific codes, they are limited by their understanding of the deeper semantics and restrictions of programming models such as OpenMP. Unsurprisingly more commonly used features have better support, while some OpenMP 3.0 directives such as sections and tasking are not universally supported on accelerators. We demonstrate that successful compilation and execution to completion are inadequate metrics for evaluating generated code and that, at this time, commodity LLMs require expert intervention for code verification. This points to gaps in the training data that is currently available for HPC. We demonstrate that with "small" effort 37% of generated invalid C tests and 63% of generated invalid Fortran tests could be corrected. This improves productivity of test generation as we circumvent writing from scratch and the common programming errors associated with it.

Pophale, Swaroop [ORNL] (ORCID:0000000185446367)↗
NASA NTRS1993

Demonstration of the Dynamic Flowgraph Methodology using the Titan 2 Space Launch Vehicle Digital Flight Control System

Dynamic Flowgraph Methodology (DFM) is a new approach developed to integrate the modeling and analysis of the hardware and software components of an embedded system. The objective is to complement the traditional approaches which generally follow the philosophy of separating out the hardware and software portions of the assurance analysis. In this paper, the DFM approach is demonstrated using the Titan 2 Space Launch Vehicle Digital Flight Control System. The hardware and software portions of this embedded system are modeled in an integrated framework. In addition, the time dependent behavior and the switching logic can be captured by this DFM model. In the modeling process, it is found that constructing decision tables for software subroutines is very time consuming. A possible solution is suggested. This approach makes use of a well-known numerical method, the Newton-Raphson method, to solve the equations implemented in the subroutines in reverse. Convergence can be achieved in a few steps.

Yau, M.↗
NASA NTRS1977

A microcomputer-based low-cost Omega sensor processor

The engineering approach used in the design of a low cost Omega sensor processor is discussed. The processor and its operations are described, as well as the system hardware and software. Circuit details of the hardware modules and program listings for the FORTRAN and microcomputer software are included.

Salter, R. J., Jr.↗
NASA NTRS1989

AdaNET Dynamic Software Inventory (DSI) prototype component acquisition plan

A component acquisition plan contains the information needed to evaluate, select, and acquire software and hardware components necessary for successful completion of the AdaNET Dynamic Software Inventory (DSI) Management System Prototype. This plan will evolve and be applicable to all phases of the DSI prototype development. Resources, budgets, schedules, and organizations related to component acquisition activities are provided. A purpose and description of a software or hardware component which is to be acquired are presented. Since this is a plan for acquisition of all components, this section is not applicable. The procurement activities and events conducted by the acquirer are described and who is responsible is identified, where the activity will be performed, and when the activities will occur for each planned procurement. Acquisition requirements describe the specific requirements and standards to be followed during component acquisition. The activities which will take place during component acquisition are described. A list of abbreviations and acronyms, and a glossary are contained.

Hanley, Lionel↗