Search NASA⌕ Search

SEARCH · Search NASA

Results for “hardware complexity”

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 343 records · Page 19

The application of CFD for military aircraft design at transonic speeds

Numerous computational fluid dynamics (CFD) codes are available that solve any of several variations of the transonic flow equations from small disturbance to full Navier-Stokes. The design philosophy at General Dynamics Fort Worth Division involves use of all these levels of codes, depending on the stage of configuration development. Throughout this process, drag calculation is a central issue. An overview is provided for several transonic codes and representative test-to-theory comparisons for fighter-type configurations are presented. Correlations are shown for lift, drag, pitching moment, and pressure distributions. The future of applied CFD is also discussed, including the important task of code validation. With the progress being made in code development and the continued evolution in computer hardware, the routine application of these codes for increasingly more complex geometries and flow conditions seems apparent.

Smith, C. W.↗

Space station Simulation Computer System (SCS) study for NASA/MSFC. Volume 4: Conceptual design report

The Simulation Computer System (SCS) is the computer hardware, software, and workstations that will support the Payload Training Complex (PTC) at Marshall Space Flight Center (MSFC). The PTC will train the space station payload scientists, station scientists, and ground controllers to operate the wide variety of experiments that will be onboard the Space Station Freedom. In the first step of this task, a methodology was developed to ensure that all relevant design dimensions were addressed, and that all feasible designs could be considered. The development effort yielded the following method for generating and comparing designs in task 4: (1) Extract SCS system requirements (functions) from the system specification; (2) Develop design evaluation criteria; (3) Identify system architectural dimensions relevant to SCS system designs; (4) Develop conceptual designs based on the system requirements and architectural dimensions identified in step 1 and step 3 above; (5) Evaluate the designs with respect to the design evaluation criteria developed in step 2 above. The results of the method detailed in the above 5 steps are discussed. The results of the task 4 work provide the set of designs which two or three candidate designs are to be selected by MSFC as input to task 5-refine SCS conceptual designs. The designs selected for refinement will be developed to a lower level of detail, and further analyses will be done to begin to determine the size and speed of the components required to implement these designs.

Source record↗

Space station Simulation Computer System (SCS) study for NASA/MSFC. Volume 5: Study analysis report

The Simulation Computer System (SCS) is the computer hardware, software, and workstations that will support the Payload Training Complex (PTC) at the Marshall Space Flight Center (MSFC). The PTC will train the space station payload scientists, station scientists, and ground controllers to operate the wide variety of experiments that will be on-board the Freedom Space Station. The further analysis performed on the SCS study as part of task 2-Perform Studies and Parametric Analysis-of the SCS study contract is summarized. These analyses were performed to resolve open issues remaining after the completion of task 1, and the publishing of the SCS study issues report. The results of these studies provide inputs into SCS task 3-Develop and present SCS requirements, and SCS task 4-develop SCS conceptual designs. The purpose of these studies is to resolve the issues into usable requirements given the best available information at the time of the study. A list of all the SCS study issues is given.

Source record↗

Space station Simulation Computer System (SCS) study for NASA/MSFC. Volume 6: Study issues report

The Simulation Computer System (SCS) is the computer hardware, software, and workstations that will support the Payload Training Complex (PTC) at the Marshall Space Flight Center (MSFC). The PTC will train the space station payload specialists and mission specialists to operate the wide variety of experiments that will be on-board the Freedom Space Station. This simulation Computer System (SCS) study issues report summarizes the analysis and study done as task 1-identify and analyze the CSC study issues- of the SCS study contract.This work was performed over the first three months of the SCS study which began in August of 1988. First issues were identified from all sources. These included the NASA SOW, the TRW proposal, and working groups which focused the experience of NASA and the contractor team performing the study-TRW, Essex, and Grumman. The final list is organized into training related issues, and SCS associated development issues. To begin the analysis of the issues, a list of all the functions for which the SCS could be used was created, i.e., when the computer is turned on, what will it be doing. Analysis was continued by creating an operational functions matrix of SCS users vs. SCS functions to insure all the functions considered were valid, and to aid in identification of users as the analysis progressed. The functions will form the basis for the requirements, which are currently being developed under task 3 of the SCS study.

Source record↗

Evolution of an Intelligent Information Fusion System

Consideration is given to the hardware and software needed to manage the enormous amount and complexity of data that the next generation of space-borne sensors will provide. An anthology is presented illustrating the evolution of artificial intelligence, science data processing, and management from the 1960s to the near future. Problems and limitations of technologies, data structures, data standards, and conceptual thinking are addressed. The development of an end-to-end Intelligent Information Fusion System that embodies knowledge of the user's domain-specific goals is proposed.

Campbell, William J.↗

Software engineering as an engineering discipline

The purpose of this panel is to explore the emerging field of software engineering from a variety of perspectives: university programs; industry training and definition; government development; and technology transfer. In doing this, the panel will address the issues of distinctions among software engineering, computer science, and computer hardware engineering as they relate to the challenges of large, complex systems.

Freedman, Glenn B.↗

SCOSII: ESA's new generation of mission control systems: The user's perspective

In 1974 ESOC decided to develop a reusable Mission Control System infrastructure for ESA's missions operated under its responsibility. This triggered a long and successful product development line, which started with the Multi Mission Support System (MSSS) which entered in service in 1977 and is still being used today by the MARECS and ECS missions; it was followed in 1989 by a second generation of systems known as SCOS-I, which was/is used by the Hipparcos, ERS-1 and EURECA missions and will continue to support all future ESCO controlled missions until approximately 1995. In the meantime the increasing complexity of future missions together with the emergence of new hardware and software technologies have led ESOC to go for the development of a third generation of control systems, SCOSII, which will support their future missions up to at least the middle of the next decade. The objective of the paper is to present the characteristics of the SCOSII system from the perspective of the mission control team; i.e. it will concentrate on the improvements and advances in the performance, functionality and work efficiency of the system.

Kaufeler, P.↗

Blade Vibration Measurement System

The Phase I project successfully demonstrated that an advanced noncontacting stress measurement system (NSMS) could improve classification of blade vibration response in terms of mistuning and closely spaced modes. The Phase II work confirmed the microwave sensor design process, modified the sensor so it is compatible as an upgrade to existing NSMS, and improved and finalized the NSMS software. The result will be stand-alone radar/tip timing radar signal conditioning for current conventional NSMS users (as an upgrade) and new users. The hybrid system will use frequency data and relative mode vibration levels from the radar sensor to provide substantially superior capabilities over current blade-vibration measurement technology. This frequency data, coupled with a reduced number of tip timing probes, will result in a system capable of detecting complex blade vibrations that would confound traditional NSMS systems. The hardware and software package was validated on a compressor rig at Mechanical Solutions, Inc. (MSI). Finally, the hybrid radar/tip timing NSMS software package and associated sensor hardware will be installed for use in the NASA Glenn spin pit test facility.

Platt, Michael J.↗

Rapid Development of Instrument Thermal Models: Perspectives and Guidelines from NASA Goddard’s Instrument Design Laboratory

- The design and development of robotic spaceflight instruments is a critical part of NASA’s vision to discover and expand knowledge for the benefit of humanity - For typical flight instrument projects, thermal engineers will develop initial instrument thermal models over weeks or months, then iterate them over a project’s lifespan – In each iteration, the engineer will: - Refine their thermal models and thermal designs in accordance with updates from other subsystems - Perform trade studies - Solve very detailed and complex analysis problems, including worst-cases and contingencies - Pick hardware and plan for testing and integration - However, prior to a project being established, or for proposal development at an early conceptual stage, the luxury of multiple instrument design iterations may be limited or nonexistent – Within a short timeline, how do you complete a thermal model or explore multiple possible instrument configurations? – What are the critical parameters for your model? Which details do you include or leave out?

Kan Yang↗

Enabling Reliable, Fault-Tolerant Autonomous Lunar Habitats with High-Performance Spaceflight Computing

The lunar surface presents unfavorable constraints and harsh living conditions. To address these challenges, autonomous habitats will require complex integrated systems that combine advanced software, high-performance hardware, and cutting-edge sensors to ensure sustainability, safety, and operational efficiency. Consequently, maintaining a sustainable presence on the Moon requires reliable infrastructure and efficient development, precise monitoring, and utilization of resources within a lunar installation. These elements are essential not only to ensure that lunar settlement can be long-term, self-sustaining, and resource-efficient, but also to serve as a foundation for future missions and eventual human habitation on Mars. Humans are not native to the Moon; therefore, our survival and ability to thrive will depend on autonomous systems that can foster safety and resilience through high-availability architectures, graceful degradation, and highly fault-tolerant spaceflight hardware capable of continuing operation during failures. This requires advanced human-rated distributed systems architectures with specialized electronics, scalable capabilities, and an integrated design approach. Unlike current practices focused on short-term missions and regularly maintained components, permanent lunar compute systems must be designed for extended operations beyond mission durations. This paper explores the necessity of transitioning toward fault- tolerant, highly autonomous hardware systems designed for multi-year missions. It also identifies critical subsystems that require high levels of autonomy, supported by radiation-hardened processors and extreme thermal loads, which are essential to mitigate long-term degradation and ensure sustainable lunar habitation. Finally, the paper aligns with NASA’s identified Civil Space Shortfalls, particularly in high-performance onboard computing, advanced data acquisition, extreme-environment avionics, radiation monitoring and countermeasures, and autonomous health management. It proposes NASA’s new High-Performance Spaceflight Computing (HPSC) processor as a turnkey solution, delivering 100 times the performance-per-watt of legacy rad-hard CPUs and enabling onboard AI, edge computing, and fault-tolerant features essential for sustained lunar autonomy and beyond.

Sarkis S Mikaelian↗

Exploration Toilet Integration Challenges on the International Space Station

On the International Space Station (ISS) there are currently two toilets. One is located in the Russian segment's Service Module and the other is located in the U.S. segment's Node 3. A new Exploration Toilet will be integrated next to the existing Node 3 Waste and Hygiene Compartment (WHC). The Toilet will be evaluated as a technology demonstration for a minimum of three years. In addition, it will support an increase in ISS crew size due to Commercial Crew flights to ISS. The Toilet is designed to minimize mass and volume for Orion, the first Exploration vehicle. Currently ISS does not have a designated volume for an additional Toilet. Furthermore, operating the Toilet on ISS presents a different set of challenges as it must integrate into existing vehicle systems for urine processing. To integrate the Toilet on ISS, a suite of hardware was developed to provide mechanical, electrical, data, and fluid interfaces. This paper will provide an overview of the Toilet Integration Hardware design as well as the engineering challenges, crew interface provisions and vehicle integration complexities encountered during the concept and design phases.

Integration Hardware↗

Ground Operations Aerospace Language (GOAL). Volume 3: Data bank

The GOAL (Ground Operations Aerospace Language) test programming language was developed for use in ground checkout operations in a space vehicle launch environment. To insure compatibility with a maximum number of applications, a systematic and error-free method of referencing command/response (analog and digital) hardware measurements is a principle feature of the language. Central to the concept of requiring the test language to be independent of launch complex equipment and terminology is that of addressing measurements via symbolic names that have meaning directly in the hardware units being tested. To form the link from test program through test system interfaces to the units being tested the concept of a data bank has been introduced. The data bank is actually a large cross-reference table that provides pertinent hardware data such as interface unit addresses, data bus routings, or any other system values required to locate and access measurements.

Source record↗

An Embedded Reconfigurable Logic Module

A Miniature Embedded Reconfigurable Computer and Logic (MERCAL) module has been developed and verified. MERCAL was designed to be a general-purpose, universal module that that can provide significant hardware and software resources to meet the requirements of many of today's complex embedded applications. This is accomplished in the MERCAL module by combining a sub credit card size PC in a DIMM form factor with a XILINX Spartan I1 FPGA. The PC has the ability to download program files to the FPGA to configure it for different hardware functions and to transfer data to and from the FPGA via the PC's ISA bus during run time. The MERCAL module combines, in a compact package, the computational power of a 133 MHz PC with up to 150,000 gate equivalents of digital logic that can be reconfigured by software. The general architecture and functionality of the MERCAL hardware and system software are described.

Tucker, Jerry H.↗

Exploration Toilet Integration Challenges on the International Space Station

On the International Space Station (ISS) there are currently two toilets. One is located in the Russian Service Module and the other is located in the U.S. segment's Node 3. A new Exploration Toilet will be integrated next to the existing Node 3 Waste and Hygiene Compartment (WHC). The Toilet will be evaluated as a technology demonstration for a minimum of three years. In addition, it will support an increase in ISS crew size due to Commercial Crew flights to ISS. The Toilet is designed to minimize mass and volume for Orion, the first Exploration vehicle. Currently ISS does not have a designated volume for an additional Toilet. Furthermore, operating the Toilet on ISS presents a different set of challenges as it must integrate into existing vehicle systems for urine processing. To integrate the Toilet on ISS, a suite of hardware was developed to provide mechanical, electrical, data, and fluid interfaces. This paper will provide an overview of the Toilet Integration Hardware design as well as the engineering challenges, crew interface provisions and vehicle integration complexities encountered during the concept and design phases.

Node 3↗

Fast Machine Learning for Quantum Control of Microwave Qudits on Edge Hardware

Quantum optimal control is a promising approach to improve the accuracy of quantum gates, but it relies on complex algorithms to determine the best control settings. CPU or GPU-based approaches often have delays that are too long to be applied in practice. It is paramount to have systems with extremely low delays to quickly and with high fidelity adjust quantum hardware settings, where fidelity is defined as overlap with a target quantum state. Here, we utilize machine learning (ML) models to determine control-pulse parameters for preparing Selective Number-dependent Arbitrary Phase (SNAP) gates in microwave cavity qudits, which are multi-level quantum systems that serve as elementary computation units for quantum computing. The methodology involves data generation using classical optimization techniques, ML model development, design space exploration, and quantization for hardware implementation. Our results demonstrate the efficacy of the proposed approach, with optimized models achieving low gate trace infidelity near $10^{-3}$ and efficient utilization of programmable logic resources.

Sanders, Flor [Columbia U.]↗

Universal Decoder for PPM of any Order

A recently developed algorithm for demodulation and decoding of a pulse-position- modulation (PPM) signal is suitable as a basis for designing a single hardware decoding apparatus to be capable of handling any PPM order. Hence, this algorithm offers advantages of greater flexibility and lower cost, in comparison with prior such algorithms, which necessitate the use of a distinct hardware implementation for each PPM order. In addition, in comparison with the prior algorithms, the present algorithm entails less complexity in decoding at large orders. An unavoidably lengthy presentation of background information, including definitions of terms, is prerequisite to a meaningful summary of this development. As an aid to understanding, the figure illustrates the relevant processes of coding, modulation, propagation, demodulation, and decoding. An M-ary PPM signal has M time slots per symbol period. A pulse (signifying 1) is transmitted during one of the time slots; no pulse (signifying 0) is transmitted during the other time slots. The information intended to be conveyed from the transmitting end to the receiving end of a radio or optical communication channel is a K-bit vector u. This vector is encoded by an (N,K) binary error-correcting code, producing an N-bit vector a. In turn, the vector a is subdivided into blocks of m = log2(M) bits and each such block is mapped to an M-ary PPM symbol. The resultant coding/modulation scheme can be regarded as equivalent to a nonlinear binary code. The binary vector of PPM symbols, x is transmitted over a Poisson channel, such that there is obtained, at the receiver, a Poisson-distributed photon count characterized by a mean background count nb during no-pulse time slots and a mean signal-plus-background count of ns+nb during a pulse time slot. In the receiver, demodulation of the signal is effected in an iterative soft decoding process that involves consideration of relationships among photon counts and conditional likelihoods of m-bit vectors of coded bits. Inasmuch as the likelihoods of all the m-bit vectors of coded bits mapping to the same PPM symbol are correlated, the best performance is obtained when the joint mbit conditional likelihoods are utilized. Unfortunately, the complexity of decoding, measured in the number of operations per bit, grows exponentially with m, and can thus become prohibitively expensive for large PPM orders. For a system required to handle multiple PPM orders, the cost is even higher because it is necessary to have separate decoding hardware for each order. This concludes the prerequisite background information. In the present algorithm, the decoding process as described above is modified by, among other things, introduction of an lbit marginalizer sub-algorithm. The term "l-bit marginalizer" signifies that instead of m-bit conditional likelihoods, the decoder computes l-bit conditional likelihoods, where l is fixed. Fixing l, regardless of the value of m, makes it possible to use a single hardware implementation for any PPM order. One could minimize the decoding complexity and obtain an especially simple design by fixing l at 1, but this would entail some loss of performance. An intermediate solution is to fix l at some value, greater than 1, that may be less than or greater than m. This solution makes it possible to obtain the desired flexibility to handle any PPM order while compromising between complexity and loss of performance.

Moision, Bruce E.↗