SEARCH · Engineering Papers
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.
A conceptual framework for treating software quality from a total system perspective is developed. Examples are given to show how system quality objectives may be allocated to hardware and software; to illustrate trades among quality factors, both hardware and software, to achieve system performance objectives; and to illustrate the impact of certain design choices on software functionality.
Advanced nuclear reactors are a key part of the future of nuclear energy both in the United States and globally. They offer unique benefits for various energy-demanding applications, including use in remote locations, compact size, modular manufacturing, remote monitoring, low and/or variable power rating operation, and reliance on novel technologies to enhance operational safety. To achieve economic feasibility, advanced reactors must significantly reduce their workforces in comparison with the current fleet. Achieving this reduction will occur through reducing staff workloads using technology to achieve autonomous or semi-autonomous operations, demonstrated by comprehensive testing and validation activities. These operations will require both software and hardware platforms during the design and testing phases. While simulations are useful during the design phase, their performance can significantly deviate during actual deployment on hardware. This report presents the outcomes of a collaborative technical initiative between the U.S. Department of Energy (DOE) Microreactor Program (MRP) and Advanced Sensors and Instrumentation (ASI) Program. The collaboration utilized the Microreactor Automated Control System (MACS) hardware platform to bridge the gap between theoretical reactor design and actual startup and control operations. Two key use cases were investigated: facilitating the startup testing period and demonstrating supervisory control. The first use case details the key Microreactor Applications Research Validation and Evaluation (MARVEL) reactor startup physics testing activities conducted using the MACS platform. These activities included drum worth measurements, shutdown margin assessment, temperature feedback analysis, and scram time evaluation, as well as unique testing that would apply to the MARVEL reactor to demonstrate the testing methodologies in a low-risk environment. The MACS platform, serving as a surrogate representation of the MARVEL reactor, proved instrumental in performing these tests. The exercise revealed aspects that led to optimized processes, refined hardware design, and enhanced base software capabilities. By maturing methods and technologies in this manner, the initiative promises to reduce wasted time in the actual on-site reactor deployment effort, thereby saving significant time and resources. The second use case focuses on the development and implementation of supervisory control methods aimed at managing core tilt, which can result from asymmetrical operations or manufacturing imperfections in fuel rods or reactivity control devices. A key objective was to assess and compare the use of artificial intelligence (AI) for supervisory control. The effort aimed to define the role of supervisory control to enhance performance without risking control instability. This effort explored three distinct approaches: rules-based (RB) methods, optimization techniques, and reinforcement learning (RL) algorithms. Each approach was evaluated for its ease of implementation, its usability, and its effectiveness in responding to asymmetries in neutron flux. Comparative analysis of these approaches provided valuable insights into their applicability and effectiveness, offering a robust framework for advanced reactor operations. Together, these two use cases highlight the potential of hardware test beds to help streamline the design, operation, and control of advanced nuclear reactors. This collaborative effort underscores the importance of continued innovation and experimentation in achieving the next generation of safe, reliable, and economically viable nuclear energy solutions.
A programmable maintenance processor concept applicable to multiprocessing systems has been developed at the NASA Ames Research Center's Dryden Flight Research Facility. This stand-alone-processor is intended to provide support for system and application software testing as well as hardware diagnostics. An initial machanization has been incorporated into the extended aircraft interrogation and display system (XAIDS) which is multiprocessing general-purpose ground support equipment. The XAIDS maintenance processor has independent terminal and printer interfaces and a dedicated magnetic bubble memory that stores system test sequences entered from the terminal. This report describes the hardware and software embodied in this processor and shows a typical application in the check-out of a new XAIDS.
The Systems Engineering Simulator (SES) houses a variety of real-time computer generated visual systems. The earliest machine dates from the mid-1960's and is one of the first real-time graphics systems in the world. The latest acquisition is the state-of-the-art Evans and Sutherland CT6. Between the span of time from the mid-1960's to the late 1980's, tremendous strides have been made in the real-time graphics world. These strides include advances in both software and hardware engineering. The purpose is to explore the history of the development of these real-time computer generated image systems from the first machine to the present. Hardware advances as well as software algorithm changes are presented. This history is not only quite interesting but also provides us with a perspective with which we can look backward and forward.
A proposed computer architecture would exploit the capabilities of commercially available field-programmable gate arrays (FPGAs) to enable computers to detect and recover from bit errors. The main purpose of the proposed architecture is to enable fault-tolerant computing in the presence of single-event upsets (SEUs). [An SEU is a spurious bit flip (also called a soft error) caused by a single impact of ionizing radiation.] The architecture would also enable recovery from some soft errors caused by electrical transients and, to some extent, from intermittent and permanent (hard) errors caused by aging of electronic components. A typical FPGA of the current generation contains one or more complete processor cores, memories, and highspeed serial input/output (I/O) channels, making it possible to shrink a board-level processor node to a single integrated-circuit chip. Custom, highly efficient microcontrollers, general-purpose computers, custom I/O processors, and signal processors can be rapidly and efficiently implemented by use of FPGAs. Unfortunately, FPGAs are susceptible to SEUs. Prior efforts to mitigate the effects of SEUs have yielded solutions that degrade performance of the system and require support from external hardware and software. In comparison with other fault-tolerant- computing architectures (e.g., triple modular redundancy), the proposed architecture could be implemented with less circuitry and lower power demand. Moreover, the fault-tolerant computing functions would require only minimal support from circuitry outside the central processing units (CPUs) of computers, would not require any software support, and would be largely transparent to software and to other computer hardware. There would be two types of modules: a self-checking processor module and a memory system (see figure). The self-checking processor module would be implemented on a single FPGA and would be capable of detecting its own internal errors. It would contain two CPUs executing identical programs in lock step, with comparison of their outputs to detect errors. It would also contain various cache local memory circuits, communication circuits, and configurable special-purpose processors that would use self-checking checkers. (The basic principle of the self-checking checker method is to utilize logic circuitry that generates error signals whenever there is an error in either the checker or the circuit being checked.) The memory system would comprise a main memory and a hardware-controlled check-pointing system (CPS) based on a buffer memory denoted the recovery cache. The main memory would contain random-access memory (RAM) chips and FPGAs that would, in addition to everything else, implement double-error-detecting and single-error-correcting memory functions to enable recovery from single-bit errors.
Human performance is critical to crew safety during space missions. Humans interact with hardware and software during ground processing, normal flight, and in response to events. Human interactions with hardware and software can cause Loss of Crew and/or Vehicle (LOCV) through improper actions, or may prevent LOCV through recovery and control actions. Humans have the ability to deal with complex situations and system interactions beyond the capability of machines. Human Reliability Analysis (HRA) is a method used to qualitatively and quantitatively assess the occurrence of human failures that affect availability and reliability of complex systems. Modeling human actions with their corresponding failure probabilities in a Probabilistic Risk Assessment (PRA) provides a more complete picture of system risks and risk contributions. A high-quality HRA can provide valuable information on potential areas for improvement, including training, procedures, human interfaces design, and the need for automation. Modeling human error has always been a challenge in part because performance data is not always readily available. For spaceflight, the challenge is amplified not only because of the small number of participants and limited amount of performance data available, but also due to the lack of definition of the unique factors influencing human performance in space. These factors, called performance shaping factors in HRA terminology, are used in HRA techniques to modify basic human error probabilities in order to capture the context of an analyzed task. Many of the human error modeling techniques were developed within the context of nuclear power plants and therefore the methodologies do not address spaceflight factors such as the effects of microgravity and longer duration missions. This presentation will describe the types of human error risks which have shown up as risk drivers in the Shuttle PRA which may be applicable to commercial space flight. As with other large PRAs of complex machines, human error in the Shuttle PRA proved to be an important contributor (~12 percent) to LOCV. An existing HRA technique was adapted for use in the Shuttle PRA, but additional guidance and improvements are needed to make the HRA task in space-related PRAs easier and more accurate. Therefore, this presentation will also outline plans for expanding current HRA methodology to more explicitly cover spaceflight performance shaping factors.
Over the past decade the marine energy industry has continued to grow and evolve, with new concepts and technologies constantly being pursued. Additionally, the field of computing is vastly different today than it was five or ten years ago. By utilizing advanced software and hardware architectures, like graphics processing units as well as parallelization and high-performance computing resources, software can produce higher quality outputs and a higher volume of outputs. These software and hardware resources can enable the marine energy community to exploit computational advancements from other research fields, which can include machine learning, differentiable programming, and controls co-design. Better integration of existing software and development of potential new software is necessary to take advantage of trends in modern computing and respond to the current and future needs of the marine energy community. In order to better understand the existing marine energy software landscape and industry needs, DOE's Water Power Technologies Office (WPTO) tasked Sandia National Laboratories and the National Renewable Energy Laboratory to update the needs assessment by identifying existing software gaps and software needs, and assisting WPTO in planning the next wave of marine energy software development. The proposed effort involved cataloguing and analyzing the available data on existing software related to marine energy. The marine energy software landscape has vastly changed in the last ten years. There are now nearly 230 different software packages utilized by the marine energy sector, compared to a decade ago when the Cardinal Engineering survey identified approximately 40 software packages. In 2012, the marine energy software landscape was captured in two tables, whereas the current marine energy software landscape required development of a software database to collect and categorize software.
The summer research activity at Kennedy Space Center (KSC) aims to introduce the student to the basic principles in their field of study. While at KSC, a specific research project awaits the student to complete. As an Aeronautical Engineering student, my assigned project is to assist the cognizant engineer, Mr. Troy Hamilton, in the six engineering phases for replacing the Ponce De Leon (PDL)4.3M Antenna Control Unit (ACU). Although the project mainly requires the attention of two engineers and two students, it also involves the participation of many colleagues at various points during the course of the engineering change (EC). Since the PDL 4.3M ACU engineering change makes both hardware and software changes, it calls upon the expertise of a Hardware Engineer as well as a Software Engineer. As students, Mr. Jeremy Bresette and I have worked side by side with the engineers, gaining invaluable experience. We work in two teams, the hardware team and the software team, On certain tasks, we assist the engineers, while on others we assume their roles. By diligently working in this fashion, we are learning how to communicate effectively as professionals, despite the fact that we are studying different engineering fields. This project has been a great fit for my field of study, as it has highly improved my awareness of the many critical tasks involved in carrying out an engineering project.
The development of the Sampling and Caching Subsystem (SCS) of the Mars 2020 Rover Mission is highly dependent on testing of prototype hardware and software operating in explicit conditions as part of integrated testbeds. To achieve relevant integration of hardware and software while maintaining rapid algorithm development capabilities and high testing throughput, the Controls and Autonomy for Sample Acquisition and Handling (CASAH) software system was developed. CASAH is an implementation of the Intelligent Robotics System Architecture (IRSA),which mimics JPL Flight Software (FSW) in that it is divided into hierarchical modules that run separate processes that communicate via message passing, each module is assigned an owner that is a single developer, and the operator initiates requests via a text-based interface that interprets sequences of commands.IRSA enables a modular breakdown of CASAH that follows that of 2020 Flight Software,so developers can take an algorithm from a module in CASAH and re-code it into the same module in FSW. As deployment of CASAH has grown to ten testbeds - each with different hardware and objectives - bottom-up design decisions have been intentionally made to keep the system lightweight and maintainable by a very small team. To date, CASAH has been used to run 1393 different tests. This work describes CASAH, the testbeds and functionality it supports, the tools used to manage the development and sharing of code, and the features of the software. Lessons learned over the past three years of development and deployment are provided.
This software automates the collection of waveform data on a timed schedule so that an operator does not need to be at the computer to initiate the collection of data sets.It provides real time display of up to 16 channels of data as a time display, frequency display, or frequency vs time (spectrogram) display. The software provides the ability to collect data sets of a user selected time length at a selected interval. This operation can be set to occur during a selected time interval during the day. This software provides the capability to write two copies of the data files simultaneously so that the data is backed up as collected. This software automates the collection of waveform data on a timed schedule so that an operator does not need to be at the computer to initiate the collection of data sets. It provides real time display of up to 16 channels of data as a time display, frequency display, or frequency vs time (spectrogram) display. The software provides the ability to collect data sets of a user selected time length at a selected interval. This operation can be set to occur during a selected time interval during the day. This software provides the capability to write two copies of the data files simultaneously so that the data is backed up as collected.
The minicomputer, with its large capacity in a small and inexpensive package, can be an important component in special-purpose test equipment. The Voyager spacecraft flight data subsystem support equipment is an example of computer-based test gear. The subsystem to be tested is a major control and data acquisition element of the Voyager spacecraft, with a large number of interfaces to several other onboard subsystems. This equipment was designed to meet spacecraft subsystem testing requirements while making maximum use of off-the-shelf commercial components. Careful consideration was given to design tradeoffs in the areas of commercial versus specially built hardware and hardware versus software problem solutions. The resulting system is an integrated package of commercial and special-purpose hardware plus software.
Autonomous rendezvous and capture (AR&C) is a critical space technology with significant application to a variety of missions. Martin Marietta Astronautics Group (MMAG) has been developing AR&C technical capability in support of several recent NASA contracts. The use of AR&C for the Mars Rover/Sample Return (MRSR) mission was studied through a contract with JSC. Incorporation of AR&C in the Space Transportation Vehicle (STV) lunar mission was studied through a contract with MSFC. The MMAG has also been developing AR&C simulation capability under independent research and development studies. Simulation development was driven by two goals: comprehensive software simulation of the autonomous rendezvous and capture mission from launch to final capture; and integration of the overall software and hardware simulation to support an AR&C flight demonstration. This presentation will highlight the AR&C software simulation tools and analyze results from their application to the STV lunar mission. Plans for an integrated software and hardware simulation will also be summarized.
The Operator Control Station of the Jet Propulsion Laboratory (JPL)/NASA Telerobot Demonstrator System provides the man-machine interface between the operator and the system. It provides all the hardware and software for accepting human input for the direct and indirect (supervised) manipulation of the robot arms and tools for task execution. Hardware and software are also provided for the display and feedback of information and control data for the operator's consumption and interaction with the task being executed. The software design of the operator control system is discussed.
The Operator Control Station of the Jet Propulsion Laboratory (JPL)/NASA Telerobot Demonstrator System provides the man-machine interface between the operator and the system. It provides all the hardware and software for accepting human input for the direct and indirect (supervised) manipulation of the robot arms and tools for task execution. Hardware and software are also provided for the display and feedback of information and control data for the operator's consumption and interaction with the task being executed. The hardware design, system architecture, and its integration and interface with the rest of the Telerobot Demonstrator System are discussed.
The advent of new hardware and software tools permits a new approach to preparing, presenting, and maintaining software specifications and corresponding source programs. Any real reduction in software life cycle costs must make highly skilled human effort more efficient especially on large, complex, and long-lasting software projects. When these skilled human functions are examined closely, it is seen that critical factors include the way one communicates with oneself and then with others and finally with computers. Thus, there has been a long and active proliferation of programming languages and, more recently, a number of programming design languages to supplement older methods, such as flowcharting. One way to achieve cost reduction is to provide documentation tools whose use increases the effectiveness of skilled humans.
Since 2019, NASA has been operating three Astrobee free flying robots on board the International Space Station (ISS) providing an autonomous and flexible research platform for national and international payload developers in microgravity and serving as a robotic assistant for astronauts on the ISS. During its use on the ISS, in particular with over 750 hours of free-flyer operation as of March 2022, Astrobee and its Docking Station have encountered multiple software and hardware anomalies. These anomalies were either resolved remotely via software and firmware updates, or, where not possible, with hardware replacements on orbit or by the return of the faulty unit to NASA’s ground facilities for its repair. Despite being inherently designed to be repaired or replaced on orbit, Astrobee and its systems can still suffer anomalies that would be complex enough to disassemble, cause risks of hardware damage, or use excessive crew time to perform the repair in orbit. That was the case for the anomaly the Astrobee unit ‘Honey’ encountered, reason why it needed to be down-massed for repair. One of the most common points of failure was found to be the SD card, which is used for the different Astrobee processors and for the Dock Station. Other comparable SD card anomalies were found also on the Astrobee ground units, which provided useful data in the effort of upgrading their systems. This presentation will focus on 1) The overview of the different faults and anomalies on Astrobee and its systems on orbit and on the ground 2) The processes and procedures implemented to resolve the anomalies 3) The implementation of software updates and hardware upgrades in order to reduce the risk on returning anomalies 4) The lessons learned in increasing Astrobee’s robustness and resilience to such anomalies.
Embedded computer systems and supporting operating systems have recently enabled the automation of many time-critical flight functions. This automation requires the integration of computer hardware and software, aircraft hardware, and the flight application. To properly integrate and control these critical functions requires a real-time environment that is provided by the onboard flight computer, a real-time operating system, and a real-time flight application that supplies the input commands to the aircraft and responds to the resulting actions. The increased complexity of developing and testing such real-time applications can best be supported by a separate test facility that provides the processing visibility and control which is virtually impossible in the actual real-time operating environment. Such a flight software validation facility has been developed at the NASA Langley Research Center to support applications using the Shuttle real-time language HAL/S. The development and control of this facility are described. Some of the management techniques used were project schedules, status monitoring, code walk-throughs, configuration control, phased releases, validation suites, and modern programming techniques.
The prototype discussed here was developed as proof of a concept for a system which could support high volumes of requirements documents with integrated text and graphics; the solution proposed here could be extended to other projects whose goal is to place paper documents in an electronic system for viewing and printing purposes. The technical problems (such as conversion of documentation between word processors, management of a variety of graphics file formats, and difficulties involved in scanning integrated text and graphics) would be very similar for other systems of this type. Indeed, technological advances in areas such as scanning hardware and software and display terminals insure that some of the problems encountered here will be solved in the near-term (less than five years). Examples of these solvable problems include automated input of integrated text and graphics, errors in the recognition process, and the loss of image information which results from the digitization process. The solution developed for the Online Software Requirements System is modular and allows hardware and software components to be upgraded or replaced as industry solutions mature. The extensive commercial software content allows the NASA customer to apply resources to solving the problem and maintaining documents.