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.
The application of a software reliability model having a well defined correspondence of computer program properties to requirements error analysis is described. Requirements error categories which can be related to program structural elements are identified and their effect on program execution considered. The model is applied to a hypothetical B-5 requirement specification for a program module.
In performance of this task order, bd Systems personnel provided support to the Flight Software Branch and the Software Working Group through multiple tasks related to software engineering improvement and to activities of the independent Technical Authority (iTA) Discipline Technical Warrant Holder (DTWH) for software engineering. To ensure that the products, comments, and recommendations complied with customer requirements and the statement of work, bd Systems personnel maintained close coordination with the customer. These personnel performed work in areas such as update of agency requirements and directives database, software effort estimation, software problem reports, a web-based process asset library, miscellaneous documentation review, software system requirements, issue tracking software survey, systems engineering NPR, and project-related reviews. This report contains a summary of the work performed and the accomplishments in each of these areas.
A cost effective introduction of software reuse techniques requires the reuse of existing software developed in many cases without aiming at reusability. This paper discusses the problems related to the analysis and reengineering of existing software in order to reuse it. We introduce a process model for component extraction and focus on the problem of analyzing and qualifying software components which are candidates for reuse. A prototype tool for supporting the extraction of reusable components is presented. One of the components of this tool aids in understanding programs and is based on the functional model of correctness. It can assist software engineers in the process of finding correct formal specifications for programs. A detailed description of this component and an example to demonstrate a possible operational scenario are given.
A cost effective introduction of software reuse techniques requires the reuse of existing software developed in many cases without aiming at reusability. This paper discusses the problems related to the analysis and reengineering of existing software in order to reuse it. We introduce a process model for component extraction and focus on the problem of analyzing and qualifying software components which are candidates for reuse. A prototype tool for supporting the extraction of reusable components is presented. One of the components of this tool aids in understanding programs and is based on the functional model of correctness. It can assist software engineers in the process of finding correct formal specifications for programs. A detailed description of this component and an example to demonstrate a possible operational scenario are given.
This paper presents the multi-convertor configurable simulator (MCCS) that can emulate piston/displacer dynamics and power outputs of various types of free-piston Stirling convertors developed at NASA GRC, including Technical Demonstration Convertor (TDC), Advanced Stirling Convertor (ASC), Flexure Isotope Stirling Convertor (FISC), Sunpower Robust Stirling Convertor (SRSC), and P2A. The MCCS can emulate up to four convertors, instead of two convertors in state-of-the-art Stirling simulators, and the maximum power output for each convertor is 1kW. Furthermore, hardware and software changes required to switch between convertors are minimized for easy conversion. A hardware-in-loop (HIL) system is used to easily switch between convertors by updating linearized modeling parameters in software. Also, switched-mode AC power supplies are used to generate wide ranges of voltage and current to emulate different types of Stirling convertors without replacing AC power supplies. Finally, the inductors emulating the linear alternator, which is the only hardware change needed for conversion, are modularized in alternator boxes to enable easy replacement of the inductors. These two features—easy conversion and capability of emulating up to four 1kW-convertors—will enable the validation tests of multi-convertor controller (MCC) concepts that are being developed by APL, the Dynamic Radioisotope Power System (DRPS) generator, and other controller developments for current and future DRPS flight projects. Finally, the MCCS is configured to demonstrate emulation of four FISCs and the outputs of the MCCS are compared with experimental data from the actual FISC.
Effective cybersecurity operations require the ability to analyze large amounts of information to assess security risks and formulate defensive strategies against adversaries. This has become more complex in recent years as the sprawl and interconnectivity of devices grows through implementation of virtualization, cloud computing, and Internet of Things (IoT). The amount of data and analysis required for effective cybersecurity command and control decisions far exceeds humans’ capacity to perform manually. We characterize the analysis problem as cyber situational understanding. The research presented to improve cyber situational understanding focuses on vulnerability analysis and threat intelligence. Regarding vulnerabilities, entities must analyze and plan work for between thousands and tens of thousands of software vulnerabilities annually. Entities heavily use network firewalls to limit vulnerability exposure. As a result, some of these vulnerabilities permit exposure to adversarial exploitation, whereas others are inaccessible and therefore present negligible risk of exploitation. Distinguishing between high and low risk software vulnerabilities requires a deep understanding of the vulnerability, network firewall protection, and characteristics of the targeted device. This problem is solved by extracting network service features from vulnerability data features using both machine-learning and natural language processing. Then, the network firewall topology is parsed to determine which vulnerabilities are reachable by adversaries. Ultimately, a state-based safety analysis ascertains which vulnerabilities are unsafe. A related vulnerability analysis problem occurs in cybersecurity operations when associating an entity’s hardware and software assets to public vulnerability databases. Assets often reveal hardware and software through installation artifacts and network service identification, and entities store these artifacts in inventory databases. However, software and hardware vendors apply a standard Common Platform Enumeration (CPE) naming convention when publicly reporting vulnerabilities. Associating these two datasets often requires many hours to days of manual inspection. The proposed solution automates the mapping approach of human analysts using fuzzy matching techniques, natural language processing, and, ultimately, machine learning to present a small set of recommendations for mapping the two datasets. The result significantly reduces human analysis time and reduces the occurrence of false positives in vulnerability notifications. Finally, cyber threat intelligence (CTI) requires associating cyber observable artifacts, such as IP addresses, URIs, and file hashes, with cyber threat tactics, techniques, and procedures. Unfortunately, most CTI data is compartmentalized across multiple organizations and cannot be shared due to the legal and reputational risk with cyber threat being associated with the entity. The approach to solving this problem inovlves using a distributed ledger with anonymous token spending and authentication. This allows a consortium of semi-trusted entities to share the workload of curating CTI for a threat sharing community’s cooperative benefit.
The Application Programming Interface (API) for the Crew Exploration Vehicle (CEV) Aerodynamic Database has been developed to provide the developers of software an easily implemented, fully self-contained method of accessing the CEV Aerodynamic Database for use in their analysis and simulation tools. The API is programmed in C and provides a series of functions to interact with the database, such as initialization, selecting various options, and calculating the aerodynamic data. No special functions (file read/write, table lookup) are required on the host system other than those included with a standard ANSI C installation. It reads one or more files of aero data tables. Previous releases of aerodynamic databases for space vehicles have only included data tables and a document of the algorithm and equations to combine them for the total aerodynamic forces and moments. This process required each software tool to have a unique implementation of the database code. Errors or omissions in the documentation, or errors in the implementation, led to a lengthy and burdensome process of having to debug each instance of the code. Additionally, input file formats differ for each space vehicle simulation tool, requiring the aero database tables to be reformatted to meet the tool s input file structure requirements. Finally, the capabilities for built-in table lookup routines vary for each simulation tool. Implementation of a new database may require an update to and verification of the table lookup routines. This may be required if the number of dimensions of a data table exceeds the capability of the simulation tools built-in lookup routines. A single software solution was created to provide an aerodynamics software model that could be integrated into other simulation and analysis tools. The highly complex Orion aerodynamics model can then be quickly included in a wide variety of tools. The API code is written in ANSI C for ease of portability to a wide variety of systems. The input data files are in standard formatted ASCII, also for improved portability. The API contains its own implementation of multidimensional table reading and lookup routines. The same aerodynamics input file can be used without modification on all implementations. The turnaround time from aerodynamics model release to a working implementation is significantly reduced
When software safety requirements are imposed on legacy safety-critical systems, retrospective safety cases need to be formulated as part of recertifying the systems for further use and risks must be documented and managed to give confidence for reusing the systems. The SEJ Software Development Risk Taxonomy [4] focuses on general software development issues. It does not, however, cover all the safety risks. The Software Safety Risk Taxonomy [8] was developed which provides a construct for eliciting and categorizing software safety risks in a straightforward manner. In this paper, we present extended work on the taxonomy for safety that incorporates the additional issues inherent in the development and maintenance of safety-critical systems with software. An instrument called a Software Safety Risk Taxonomy Based Questionnaire (TBQ) is generated containing questions addressing each safety attribute in the Software Safety Risk Taxonomy. Software safety risks are surfaced using the new TBQ and then analyzed. In this paper we give the definitions for the specialized Product Engineering Class within the Software Safety Risk Taxonomy. At the end of the paper, we present the tool known as the 'Legacy Systems Risk Database Tool' that is used to collect and analyze the data required to show traceability to a particular safety standard
Revised documentation is presented pertaining to the computation requirements for guidance, navigation, and control of the space shuttle orbiter vehicle. Separate sections cover the following areas; (1) reference documents, (2) GN and C system description, (3) GN and C software functional requirements, and (4) coordinate systems and transformations.
Programmatic requirements for the advancement of software technology are identified for meeting the space flight requirements in the 1980 to 1990 time period. The development items are described, and software technology item derivation worksheets are presented along with the cost/time/priority assessments.
Ada has the potential to be a part of the most significant change in software engineering technology within NASA in the last twenty years. Thus, it is particularly important that all NASA centers be aware of Ada experience and plans at other centers. Ada activity across NASA are covered, with presenters representing five of the nine major NASA centers and the Space Station Freedom Program Office. Projects discussed included - Space Station Freedom Program Office: the implications of Ada on training, reuse, management and the software support environment; Johnson Space Center (JSC): early experience with the use of Ada, software engineering and Ada training and the evaluation of Ada compilers; Marshall Space Flight Center (MSFC): university research with Ada and the application of Ada to Space Station Freedom, the Orbital Maneuvering Vehicle, the Aero-Assist Flight Experiment and the Secure Shuttle Data System; Lewis Research Center (LeRC): the evolution of Ada software to support the Space Station Power Management and Distribution System; Jet Propulsion Laboratory (JPL): the creation of a centralized Ada development laboratory and current applications of Ada including the Real-time Weather Processor for the FAA; and Goddard Space Flight Center (GSFC): experiences with Ada in the Flight Dynamics Division and the Extreme Ultraviolet Explorer (EUVE) project and the implications of GSFC experience for Ada use in NASA. Despite the diversity of the presentations, several common themes emerged from the program: Methodology - NASA experience in general indicates that the effective use of Ada requires modern software engineering methodologies; Training - It is the software engineering principles and methods that surround Ada, rather than Ada itself, which requires the major training effort; Reuse - Due to training and transition costs, the use of Ada may initially actually decrease productivity, as was clearly found at GSFC; and real-time work at LeRC, JPL and GSFC shows that it is possible to use Ada for real-time applications.
Seismic analysis and risk assessment of safety-critical infrastructure like hospitals, nuclear power plants, dams, and facilities handling radioactive materials involve computationally intensive numerical models and coupled multiphysics scenarios. They are also performed in a strict regulatory environment that requires high software quality assurance standards, and in the case of safety-related nuclear facilities, a conformance to the American Society of Mechanical Engineers Nuclear Quality Assurance (NQA-1) standard. This paper introduces the open-source finite-element software, MASTODON (Multi-hazard Analysis of Stochastic Time-Domain Phenomena), which implements state-of-the-art seismic analysis and risk assessment tools in a quality-controlled environment. MASTODON is built on MOOSE (Multi-physics Object-Oriented Simulation Environment), which is a highly parallelizable, NQA-1 conforming, coupled multiphysics, finite-element framework developed at Idaho National Laboratory. MASTODON is capable of fault rupture and source-to-site wave propagation using the domain reduction method, nonlinear site response, and soil-structure interaction analysis, implicit and explicit time integration, automated stochastic simulations, and seismic probabilistic risk assessment. When coupled with other MOOSE applications, MASTODON can also solve strongly and weakly coupled multiphysics problems. This paper presents a summary of the capabilities of MASTODON and some demonstrative examples.
The necessary personnel software base was established to accomplish the data processing requirements for this project. Conversion of software required in reformatting the raw Io sodium cloud data was completed and data processing activities were initiated. Slit spectra data acquired by the JPL Table Mountain Io sodium cloud observing program were reviewed and their scientific value assessed. The lifetime description for sodium atoms in the Io sodium cloud model was improved by incorporating the most recently available temperatures and densities for ions and electrons in the plasma torus.
The MSL Curiosity rover landed on Mars on August~5, 2012. Over time, one of its two computers experienced critical hardware memory failure. This non-volatile NAND flash memory held file system partitions and tunable parameters needed for running rover flight software. The project assembled a design and development team to re-purpose a NOR flash memory hardware chip, only 1.5\% of the size of the NAND, to hold the file systems and parameters. The usable NOR memory required major software changes to accommodate the new limitations of slower access speeds, vastly different physical layout, and smaller size. This presentation discusses the approach, challenges, and outcomes of restoring function to the computer so it can act as a ``lifeboat'' in event of problems with the primary computer.
Mission planning and scheduling of spacecraft operations are becoming more complex at NASA. Described here are a mission planning process; a robust, flexible planning language for spacecraft and payload operations; and a software scheduling system that generates schedules based on planning language inputs. The mission planning process often involves many people and organizations. Consequently, a planning language is needed to facilitate communication, to provide a standard interface, and to represent flexible requirements. The software scheduling system interprets the planning language and uses the resource, time duration, constraint, and alternative plan flexibilities to resolve scheduling conflicts.
Next-generation Mars communications networks will provide communications and navigation services to a wide variety of Mars science vehicles including: spacecraft that are arriving at Mars, spacecraft that are entering and descending in the Mars atmosphere, scientific orbiter spacecraft, spacecraft that return Mars samples to Earth, landers, rovers, aerobots, airplanes, and sensing pods. In the current architecture plans, the communication services will be provided using capabilities deployed on the science vehicles as well as dedicated communication satellites that will together make up the Mars network. This network will evolve as additional vehicles arrive, depart or end their useful missions. Cost savings and increased reliability will result from the ability to share communication services between missions. This paper discusses the basic architecture that is needed to support the Mars Communications Network part of NASA's Space Science Enterprise (SSE) communications architecture. The network may use various networking technologies such as those employed in the terrestrial Internet, as well as special purpose deep-space protocols to move data and commands autonomously between vehicles, at disparate Mars vicinity sites (on the surface or in near-Mars space) and between Mars vehicles and earthbound users. The architecture of the spacecraft on-board local communications is being reconsidered in light of these new networking requirements. The trend towards increasingly autonomous operation of the spacecraft is aimed at reducing the dependence on resource scheduling provided by Earth-based operators and increasing system fault tolerance. However, these benefits will result in increased communication and software development requirements. As a result, the envisioned Mars communications infrastructure requires both hardware and protocol technology advancements. This paper will describe a number of the critical technology needs and some of the ongoing research activities.
The National Aeronautical and Space Administration (NASA) recently launched a new software defined radio research test bed to the International Space Station. The test bed, sponsored by the Space Communications and Navigation (SCaN) Office within NASA is referred to as the SCaN Testbed. The SCaN Testbed is a highly capable communications system, composed of three software defined radios, integrated into a flight system, and mounted to the truss of the International Space Station. Software defined radios offer the future promise of in-flight reconfigurability, autonomy, and eventually cognitive operation. The adoption of software defined radios offers space missions a new way to develop and operate space transceivers for communications and navigation. Reconfigurable or software defined radios with communications and navigation functions implemented in software or VHDL (Very High Speed Hardware Description Language) provide the capability to change the functionality of the radio during development or after launch. The ability to change the operating characteristics of a radio through software once deployed to space offers the flexibility to adapt to new science opportunities, recover from anomalies within the science payload or communication system, and potentially reduce development cost and risk by adapting generic space platforms to meet specific mission requirements. The software defined radios on the SCaN Testbed are each compliant to NASA's Space Telecommunications Radio System (STRS) Architecture. The STRS Architecture is an open, non-proprietary architecture that defines interfaces for the connections between radio components. It provides an operating environment to abstract the communication waveform application from the underlying platform specific hardware such as digital-to-analog converters, analog-to-digital converters, oscillators, RF attenuators, automatic gain control circuits, FPGAs, general-purpose processors, etc. and the interconnections among different radio components.
Soil salinization, exacerbated by climate change, poses a global threat to coastal ecosystems and soil function. Salinity affects soil carbon cycling by directly impacting microbial activity and indirectly altering soil physicochemical properties, but current models inadequately represent these complexities. This dataset contains the observational and modeling data from Zheng et al. (2025), which described a process-based modeling framework that couples soil solution chemistry with microbial carbon cycling reactions to study the impacts of soil salinization. This conceptual model is implemented numerically into the open-source geochemical program PHREEQC 3.0 (Parkhurst and Appelo, 2013). This dataset consists of: - Figure2_AquaMEND_salinity_buffer: Contains model simulation outputs to assess the impact of three different cation exchange and surface complexation processes on salinity buffering (Fig. 2 from Zheng et al. 2025). - Figure3_Salinity_function: Contains salinity function fitting for literature data (Fig. 3 from Zheng et al. 2025). - Figure4_AquaMEND_microbial_mechanisms: Contains model simulation outputs for testing various microbial process-based hypotheses related to soil salinization, including microbial mortality, carbon use efficiency (CUE), extracellular enzyme activity, and other microbial mechanisms (Fig. 4 from Zheng et al. 2025). - Figure5_AquaMEND_Redox: Contains on model simulation outputs to evaluate shifts among key redox processes, such as aerobic respiration, sulfate reduction, and methanogenesis (Fig.5 from Zheng et al. 2025). - Figure6_AquaMEND_sorption: Contains on model simulation outputs for investigating the effects of salinity on dissolved organic matter (DOM) sorption and desorption processes (Fig. 6 from Zheng et al. 2025). - Figure7_AquaMEND_process_couple: Contains on model simulation outputs for exploring coupled biotic-abiotic processes and their interactions (Fig. 7 from Zheng et al. 2025). - data: Includes datasets used to develop salinity response functions and evaluate salinity buffering capacity. Datasets for MEND model calibration. - database: Contains the `.dat` file required by PHREEQC for model execution. - README.md: A Markdown plain text file describing the computational tools and directories. Files are a mixture of plain text CSV (comma-separated value) and plain text *.dat files written by the model; no special software is required to read them.