SEARCH · Engineering Papers

Results for “Software Requirements”

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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 1,351 records · Page 75

All sources NASA NTRS DOE OSTI

DOE OSTI2025

Progress Towards NQA-1 for Cardinal in FY25

Cardinal is a wrapping of the GPU-oriented spectral element Computational Fluid Dynamics (CFD) code NekRS and the Monte Carlo particle transport code OpenMC within the Multiphysics Object-Oriented Simulation Environment (MOOSE). Cardinal provides high-resolution thermal-hydraulics and/or radiation transport feedback to MOOSE multiphysics simulations. Multiphysics feedback is implemented in a geometry-agnostic manner which eliminates the need for rigid one-to-one mappings. A generic data transfer implementation also allows NekRS and OpenMC to couple to any MOOSE application, enabling a broad set of multiphysics capabilities. Cardinal simulations can also leverage combinations of MPI, OpenMP, and GPU resources. Cardinal continuous development and improvement efforts have led to the software being considered as a high-fidelity design and licensing tool for key areas of nuclear reactor relevant physics, including neutron transport, fluid flow, heat transfer, and mechanical processes. The fast development and expansion of the software from a pure R&D framework towards its application in the nuclear industry and regulation require a focus on developing, enhancing,and maintaining Cardinal’s software quality through strict adherence to a Software Quality Assurance (SQA) framework and SQA program. To facilitate compliance with SQA standards, the Cardinal SQA Program was initiated during Fiscal Year 2023 (FY23). During the development of the Cardinal SQA Program, multiple gaps have been identified. These gaps are primarily related to model verification and code pedigree as they relate to the use of Cardinal as an analysis tool. These gaps were captured in a report published in 2023. A second report highlighted the progress made during Fiscal Year 2024 (FY24) and described Argonne’s effort to document and integrate software verification within Cardinal’s software development process. This report documents the progress made towards NQA-1 for Cardinal in the Fiscal Year 2025 (FY25). All cases in the expanded Continuous Integration (CI) suite of NekRS are included in this report which test the solvers and modules available in NekRS exhaustively. The NekRS tests are integrated with the Cardinal CI suite and made available in publicly accessible Github documentation. Following the CI practice permits integrating of source code changes frequently and ensuring that the integrated codebase clears the verification testing for the software. Also in this report is a brief overview of the development of the Cardinal Software Quality Assurance Plan (SQAP) that was done in FY25, though it should be noted that the rest of the documentation for the SQA program needs to be developed in a future step of this task.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

NASA NTRS1973

Shuttle mission simulator software conceptual design

Software conceptual designs (SCD) are presented for meeting the simulator requirements for the shuttle missions. The major areas of the SCD discussed include: malfunction insertion, flight software, applications software, systems software, and computer complex.

Burke, J. F.↗

NASA NTRS2010

Kepler Science Operations Center Pipeline Framework

The Kepler mission is designed to continuously monitor up to 170,000 stars at a 30 minute cadence for 3.5 years searching for Earth-size planets. The data are processed at the Science Operations Center (SOC) at NASA Ames Research Center. Because of the large volume of data and the memory and CPU-intensive nature of the analysis, significant computing hardware is required. We have developed generic pipeline framework software that is used to distribute and synchronize the processing across a cluster of CPUs and to manage the resulting products. The framework is written in Java and is therefore platform-independent, and scales from a single, standalone workstation (for development and research on small data sets) to a full cluster of homogeneous or heterogeneous hardware with minimal configuration changes. A plug-in architecture provides customized control of the unit of work without the need to modify the framework itself. Distributed transaction services provide for atomic storage of pipeline products for a unit of work across a relational database and the custom Kepler DB. Generic parameter management and data accountability services are provided to record the parameter values, software versions, and other meta-data used for each pipeline execution. A graphical console allows for the configuration, execution, and monitoring of pipelines. An alert and metrics subsystem is used to monitor the health and performance of the pipeline. The framework was developed for the Kepler project based on Kepler requirements, but the framework itself is generic and could be used for a variety of applications where these features are needed.

Klaus, Todd C.↗

NASA NTRS2018

Mission Summary of Cassini Spacecraft Guidance and Control Hardware Health and Performance

The Cassini-Huygens mission ended on September 15, 2017, after nearly two decades in ight. The well-designed Cassini spacecraft had robust hardware that permitted two extended missions, lasting nine years longer than the expected prime mission. At the end of the mission, the Attitude and Articulation Control Subsystem (AACS) was using two pieces of redundant back-up of hardware, one reaction wheel and the hydrazine thruster branch, due to hardware anomalies earlier in the mission. The back-up hardware performed nominally through the rest of mission. The prime reaction wheels at the end of the mission had reached more than 130% of the consumable limit for number of revolutions. No thruster on either thruster branch accumulated more than 45% of the consumable limits. The inertial reference unit slightly exceeded the pre-launch requirements on bias error, but as the software continuously estimated this value in ight, the attitude estimation was not adversely a ected. The star trackers performed nominally, and though there was a spacecraft anomaly in 1998 related to the star trackers, the origin was not in hardware itself. The Sun sensors and accelerometer both performed as expected and met all requirements throughout the mission. Ultimately, the lifetime of the Cassini spacecraft was not limited by hardware performance. Planetary protection requirements necessitated the end of the mission as the spacecraft's propellant reserves depleted, and Cassini plunged into Saturn's atmosphere with a healthy attitude control system.

Stupik, Joan↗

NASA NTRS1990

Advanced Information Processing System (AIPS)-based fault tolerant avionics architecture for launch vehicles

An avionics architecture for the advanced launch system (ALS) that uses validated hardware and software building blocks developed under the advanced information processing system program is presented. The AIPS for ALS architecture defined is preliminary, and reliability requirements can be met by the AIPS hardware and software building blocks that are built using the state-of-the-art technology available in the 1992-93 time frame. The level of detail in the architecture definition reflects the level of detail available in the ALS requirements. As the avionics requirements are refined, the architecture can also be refined and defined in greater detail with the help of analysis and simulation tools. A useful methodology is demonstrated for investigating the impact of the avionics suite to the recurring cost of the ALS. It is shown that allowing the vehicle to launch with selected detected failures can potentially reduce the recurring launch costs. A comparative analysis shows that validated fault-tolerant avionics built out of Class B parts can result in lower life-cycle-cost in comparison to simplex avionics built out of Class S parts or other redundant architectures.

Lala, Jaynarayan H.↗

NASA NTRS2000

Putting ROSE to Work: A Proposed Application of a Request-Oriented Scheduling Engine for Space Station Operations

Scheduling engines are found at the core of software systems that plan and schedule activities and resources. A Request-Oriented Scheduling Engine (ROSE) is one that processes a single request (adding a task to a timeline) and then waits for another request. For the International Space Station, a robust ROSE-based system would support multiple, simultaneous users, each formulating requests (defining scheduling requirements), submitting these requests via the internet to a single scheduling engine operating on a single timeline, and immediately viewing the resulting timeline. ROSE is significantly different from the engine currently used to schedule Space Station operations. The current engine supports essentially one person at a time, with a pre-defined set of requirements from many payloads, working in either a "batch" scheduling mode or an interactive/manual scheduling mode. A planning and scheduling process that takes advantage of the features of ROSE could produce greater customer satisfaction at reduced cost and reduced flow time. This paper describes a possible ROSE-based scheduling process and identifies the additional software component required to support it. Resulting changes to the management and control of the process are also discussed.

Jaap, John↗

NASA NTRS2008

Mars Reconnaissance Orbiter In-flight Anomalies and Lessons Learned: An Update

The Mars Reconnaissance Orbiter mission has as its primary objectives: advance our understanding of the current Mars climate, the processes that have formed and modified the surface of the planet and the extent to which water has played a role in surface processes; identify sites of possible aqueous activity indicating environments that may have been or are conducive to biological activity; and thus identify and characterize sites for future landed missions; and provide forward and return relay services for current and future Mars landed assets. MRO's crucial role in the long term strategy for Mars exploration requires a high level of reliability during its 5.4 year mission. This requires an architecture which incorporates extensive redundancy and cross-strapping. Because of the distances and hence light-times involved, the spacecraft itself must be able to utilize this redundancy in responding to time-critical failures. For cases where fault protection is unable to recognize a potentially threatening condition, either due to known limitations or software flaws, intervention by ground operations is required. These aspects of MRO's design were discussed in a previous paper [Ref. 1]. This paper provides an update to the original paper, describing MRO's significant in-flight anomalies over the past year, with lessons learned for redundancy and fault protection architectures and for ground operations.

Mars Reconnaissance Orbiter↗

NASA NTRS2004

New Software for Ensemble Creation in the Spitzer-Space-Telescope Operations Database

Some of the computer pipelines used to process digital astronomical images from NASA's Spitzer Space Telescope require multiple input images, in order to generate high-level science and calibration products. The images are grouped into ensembles according to well documented ensemble-creation rules by making explicit associations in the operations Informix database at the Spitzer Science Center (SSC). The advantage of this approach is that a simple database query can retrieve the required ensemble of pipeline input images. New and improved software for ensemble creation has been developed. The new software is much faster than the existing software because it uses pre-compiled database stored-procedures written in Informix SPL (SQL programming language). The new software is also more flexible because the ensemble creation rules are now stored in and read from newly defined database tables. This table-driven approach was implemented so that ensemble rules can be inserted, updated, or deleted without modifying software.

Spitzer Science Center (SSC)↗

NASA NTRS1987

Investigation into the development of computer aided design software for space based sensors

The described effort is phase one of the development of a Computer Aided Design (CAD) software to be used to perform radiometric sensor design. The software package will be referred to as SCAD and is directed toward the preliminary phase of the design of space based sensor system. The approach being followed is to develop a modern, graphic intensive, user friendly software package using existing software as building blocks. The emphasis will be directed toward the development of a shell containing menus, smart defaults, and interfaces, which can accommodate a wide variety of existing application software packages. The shell will offer expected utilities such as graphics, tailored menus, and a variety of drivers for I/O devices. Following the development of the shell, the development of SCAD is planned as chiefly selection and integration of appropriate building blocks. The phase one development activities have included: the selection of hardware which will be used with SCAD; the determination of the scope of SCAD; the preliminary evaluation of a number of software packages for applicability to SCAD; determination of a method for achieving required capabilities where voids exist; and then establishing a strategy for binding the software modules into an easy to use tool kit.

Pender, C. W.↗

NASA NTRS2010

Modeling and Performance Considerations for Automated Fault Isolation in Complex Systems

The purpose of this paper is to document the modeling considerations and performance metrics that were examined in the development of a large-scale Fault Detection, Isolation and Recovery (FDIR) system. The FDIR system is envisioned to perform health management functions for both a launch vehicle and the ground systems that support the vehicle during checkout and launch countdown by using suite of complimentary software tools that alert operators to anomalies and failures in real-time. The FDIR team members developed a set of operational requirements for the models that would be used for fault isolation and worked closely with the vendor of the software tools selected for fault isolation to ensure that the software was able to meet the requirements. Once the requirements were established, example models of sufficient complexity were used to test the performance of the software. The results of the performance testing demonstrated the need for enhancements to the software in order to meet the demands of the full-scale ground and vehicle FDIR system. The paper highlights the importance of the development of operational requirements and preliminary performance testing as a strategy for identifying deficiencies in highly scalable systems and rectifying those deficiencies before they imperil the success of the project

Ferrell, Bob↗

NASA NTRS1981

Agricultural requirements for precipitation measurements

The requirements for precipitation measurements from space for hydrologic forecasting applications are discussed. The structure of the hydrologic forecasting service of the National Weather Service (NWS) is described, and an attempt is made to estimate the sampling and accuracy requirements for a range of spatial and temporal averaging scales corresponding to various NWS hydrologic applications. Finally, the data base requirements are addressed. The critical point is made that for the data source to be most useful operationally at the NWS River Forecast Centers, the data must be available on-line in a format compatible with computer processing. Several data base systems are illustrated in a scenario for a multi-sensor rainfall analysis system (MSRANS). Actually, MSRANS is the software existing within the various computer environments required to preprocess, process, and analyze rainfall information from multiple sources.

Strommen, N. D.↗

DOE OSTI2021

Position Papers for the ASCR Workshop on the Science of Scientific-Software Development and Use

Software is an increasingly important component in the pursuit of scientific discovery. Both its development and use are essential activities for many scientific teams. At the same time, very little scientific study has been conducted to understand, characterize, and improve the development and use of software for science. Computational science teams have diversified over time to include contributions from domain scientists who provide expertise in scientific and engineering disciplines, applied mathematicians and computer scientists who provide optimal algorithms and data structures, and software and data engineers who provide methodologies and tools adapted and adopted from other software domains. These diverse contributions have enabled tremendous advances in the pursuit of scientific discovery, even as models, computer architectures, and software environments have become more complicated. With this increasing diversity, we believe the next opportunity for qualitative improvement comes from applying the scientific method to understanding, characterizing, and improving how scientific software is developed and used. We believe that this pursuit requires expertise from computational scientists themselves, and from the cognitive and social sciences as well as the software engineering research community. As we look to increase the productivity and sustainability of the scientific-software-development-and-use cycle, a more systematic application of the scientific method to understand processes for software development and use will be a valuable tool to guide future work and result in more usable and sustainable software. This workshop will bring together computer scientists, software engineering researchers, computational scientists, applied mathematicians, social scientists, cognitive scientists, and others, to explore how we can conduct such systematic investigations, what can be learned, and how doing so will benefit the scientific enterprise. The workshop will be structured around a set of breakout sessions, with every attendee expected to participate actively in the discussions. Afterward, workshop attendees — from DOE, industry, and academia — will produce a report for ASCR that summarizes the findings of the workshop.

42 ENGINEERING↗

DOE OSTI2021

Interactive Mesh Generation and Comparison Tools for Nuclear Energy Advanced Modeling & Simulation Phase I. Final Report

The promise of computer simulations for nuclear reactor designs is the opportunity to speed up the design process while also improving safety, providing more detail and higher fidelity, reducing cost, minimizing schedule risk, and avoiding many other potential problems; because simulations have the potential to be much less expensive and time-consuming than traditional development – where scale models and physical tests require construction and long lead times – it is possible to consider more alternatives and complete more comprehensive assessments before the design is finalized and constructed. As more design scenarios are studied by simulation, the speed that simulations promise is only available as long as bottlenecks are addressed for these scenarios. A frequent bottleneck is the amount of human labor required to describe the shape of the objects being designed and decompose the shape into simple elements, such as hexahedra, that are small enough to capture the physical phenomena of interest without being so small that even fast computers cannot perform the simulation in a reasonable amount of time. Recently, techniques for creating all-hexahedral decompositions have been developed, but they require some human input. Many simulation codes prefer all-hexahedral decompositions, so we proposed to evaluate the feasibility of these techniques on nuclear reactor geometries to see whether they required too much human input to be commercially viable. Our study concluded that they can be made viable with some additional software tools to reduce the amount of user input required.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

DOE OSTI2022

From fault-detection to automated fault correction: A field study

A fault detection and diagnostics (FDD) tool, as addressed by this study, is a tool that continuously identifies the presence of faults and efficiency improvement opportunities through a one-way interface to the building automation system and the application of automated analytics. Although FDD tools can inform operators of building operational faults, currently an action is always required to correct the faults to generate energy savings. Fault auto-correction integrating with commercial FDD technology offerings can close the loop between the passive diagnostics and active control, increase the savings generated by FDD tools, and reduce the reliance on human intervention. This paper presents the field study of seven fault auto-correction algorithms implemented in commercial FDD platforms. Implementation includes software changes in the FDD tools and additional controls hardware or software changes in the BAS that were required to enable the execution of different types of auto-correction algorithms in real buildings. The routines successfully and automatically correct faults and improve the operation of large built-up Heating, Ventilation, and Air Conditioning (HVAC) systems, common in most commercial buildings. The auto-correction algorithms are tested across four buildings and three different building automation systems, following a rigorous procedure to make sure they work properly and do not negatively impact the system and building occupants. Finally, technology benefits, market drivers, and scalability changes are drawn from the implementation effort and test results, to drive future research and industry engagement.

32 ENERGY CONSERVATION, CONSUMPTION, AND UTILIZATI↗

DOE OSTI2020

Open Source Platform for Live Processing of High Data Rate Electron Microscopy (SBIR Phase I Award Topic 15, Subtopic B, Final Scientific / Technical Report)

4D scanning transmission electron microscopy (STEM) is experiencing a revolution both in terms of data size, and data veracity, as are many other areas of experimental data acquisition. This presents enormous opportunities to make new scientific discoveries, but is also hamstrung by aging software that is no longer fit for purpose. Experimental data acquisition platforms must make the same investments in software infrastructure that the simulation community made decades ago to take advantage of high-performance computing (HPC) if they hope to realize the full potential of the latest advances made in detector technology. This requires rethinking the design and deployment of hardware, moving away from small, fixed commodity computing capabilities with closed interfaces to open, modular, scalable systems designed for parallelism and throughput. The technical approach will leverage best-in-class open source technologies, and develop new approaches strategically to build an open source platform for experimental data acquisition targeting high data rate electron microscopy. The project will develop a software platform that uses the power and performance of modern HPC resources to ingest the large volume of data produced by electron microscopes using direct electron detectors. A set of configurable pipelines will be used to enable the processing to be tailored to the problem being investigated with builtin visualization of data at interactive rates. This project will leverage investments made by the DOE and other agencies to provide a powerful software platform for the experimental data community working with most powerful electron microscopes, such as 4D STEM detectors. It will create a platform that serves as a reference for the community. Permissive open source licensing will make the platform available to all, with a simple deployment strategy offering the ability to keep data close to where it is generated. This advanced software platform will require customization for each deployment, creating opportunities for software services that are typically offered to extend open source software platforms.

97 MATHEMATICS AND COMPUTING↗

NASA NTRS2010

Implementation and Testing of VLBI Software Correlation at the USNO

The Washington Correlator (WACO) at the U.S. Naval Observatory (USNO) is a dedicated VLBI processor based on dedicated hardware of ASIC design. The WACO is currently over 10 years old and is nearing the end of its expected lifetime. Plans for implementation and testing of software correlation at the USNO are currently being considered. The VLBI correlation process is, by its very nature, well suited to a parallelized computing environment. Commercial off-the-shelf computer hardware has advanced in processing power to the point where software correlation is now both economically and technologically feasible. The advantages of software correlation are manifold but include flexibility, scalability, and easy adaptability to changing environments and requirements. We discuss our experience with and plans for use of software correlation at USNO with emphasis on the use of the DiFX software correlator.

Fey, Alan↗

NASA NTRS2024

Historical Aerospace Software Errors Categorized to Influence Fault Tolerance

Since the first use of computers in space and aircraft, software errors have occurred. These errors can manifest as loss-of-life or less catastrophically. As the demand for automation increases, software in mission or safety-critical systems should be designed to be tolerant to the most likely software faults. This paper categorizes a set of 55 historic aerospace software error incidents from 1962 to 2023 to determine trends of how and where automation is most likely to fail, behaving unexpectedly. A distinction between software producing unexpected (erroneous) output versus no output (failsilent) is introduced. Of the historical incidents analyzed, 85% were from software producing wrong output rather than simply stopping. Rebooting was found to be ineffective to clear erroneous behavior, and not reliable to recover from silent failures. Error origin was within the code/logic itself in 58% of cases, 16% from configurable data, 15% from unexpected sensor input, and 11% from command/operator input. A substantial forty percent (40%) of unexpected software behavior was indicated by the absence of code, arising from unanticipated situations and missing requirements, and 16% of incidents were subjectively deemed “unknown-unknowns”. No incidents were found to be the result of programming language, compiler, tool, or operating system; and only sixteen percent (16%) of all incidents were considered errors traditional computer science/programming in nature. These findings indicate that for fault tolerance, erroneous automation behavior must be a primary consideration especially at critical moments, and reboot recoverability may not be viable. Special care should be taken to validate configurable data and commands prior to use. “Test-like-you-fly”, including hardware-in-the-loop combined with robust off-nominal testing should be used to uncover missing logic arising from unanticipated situations not covered by requirements alone. This study uniquely focuses on manifestations of unexpected flight software behavior, independent of ultimate root cause. We characterize software error behavior and origin to improve software design, test, and operations for resilience to the most common manifestations, and provide a rich dataset for further study.

Aerospace↗

NASA NTRS2012

VML 3.0 Reactive Sequencing Objects and Matrix Math Operations for Attitude Profiling

VML (Virtual Machine Language) has been used as the sequencing flight software on over a dozen JPL deep-space missions, most recently flying on GRAIL and JUNO. In conjunction with the NASA SBIR entitled "Reactive Rendezvous and Docking Sequencer", VML version 3.0 has been enhanced to include object-oriented element organization, built-in queuing operations, and sophisticated matrix / vector operations. These improvements allow VML scripts to easily perform much of the work that formerly would have required a great deal of expensive flight software development to realize. Autonomous turning and tracking makes considerable use of new VML features. Profiles generated by flight software are managed using object-oriented VML data constructs executed in discrete time by the VML flight software. VML vector and matrix operations provide the ability to calculate and supply quaternions to the attitude controller flight software which produces torque requests. Using VML-based attitude planning components eliminates flight software development effort, and reduces corresponding costs. In addition, the direct management of the quaternions allows turning and tracking to be tied in with sophisticated high-level VML state machines. These state machines provide autonomous management of spacecraft operations during critical tasks like a hypothetic Mars sample return rendezvous and docking. State machines created for autonomous science observations can also use this sort of attitude planning system, allowing heightened autonomy levels to reduce operations costs. VML state machines cannot be considered merely sequences - they are reactive logic constructs capable of autonomous decision making within a well-defined domain. The state machine approach enabled by VML 3.0 is progressing toward flight capability with a wide array of applicable mission activities.

VML (Virtual Machine Language)↗