Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “software differences”

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 289 records · Page 16

System diagnostic builder

The System Diagnostic Builder (SDB) is an automated software verification and validation tool using state-of-the-art Artificial Intelligence (AI) technologies. The SDB is used extensively by project BURKE at NASA-JSC as one component of a software re-engineering toolkit. The SDB is applicable to any government or commercial organization which performs verification and validation tasks. The SDB has an X-window interface, which allows the user to 'train' a set of rules for use in a rule-based evaluator. The interface has a window that allows the user to plot up to five data parameters (attributes) at a time. Using these plots and a mouse, the user can identify and classify a particular behavior of the subject software. Once the user has identified the general behavior patterns of the software, he can train a set of rules to represent his knowledge of that behavior. The training process builds rules and fuzzy sets to use in the evaluator. The fuzzy sets classify those data points not clearly identified as a particular classification. Once an initial set of rules is trained, each additional data set given to the SDB will be used by a machine learning mechanism to refine the rules and fuzzy sets. This is a passive process and, therefore, it does not require any additional operator time. The evaluation component of the SDB can be used to validate a single software system using some number of different data sets, such as a simulator. Moreover, it can be used to validate software systems which have been re-engineered from one language and design methodology to a totally new implementation.

Nieten, Joseph L.↗

Understanding Bifacial PV Modeling: Raytracing and View Factor Models

As part of the PV Magazine Webinar 'View-factor vs. ray tracing - which bifacial modelling techniques should you use?,' the second part lead by NREL will explore the different rear-irradiance calculation software, which fall into two categories: view-factor and ray-tracing models. View factor models assume isotropic scattering of reflected rays, allowing for calculation of irradiance by integration. Due-diligence software such as PVSyst or SAM use the view-factor model. Ray-tracing models simulate multipath reflection and absorption of individual rays entering a scene. Raytracing software such as bifacial_radiance, which is the only available open-source toolkit, offers the possibility of reproducing complex scenes, including shading or finite-system edge effects. This can be useful to evaluate specific system geometries, shading and obstructions, areas of different albedo and electrical mismatch, all topics of interest to the prediction of bifacial performance. Model agreement for view factors and bifacial_radiance software is improving and has been shown to be between 2% (absolute) when compared with measured results.

14 SOLAR ENERGY↗

Fiscal Year 2025 Software Quality Assurance Activities for the ARC Software

The continued goal of the ARC SQA project in the Advanced Reactor Technologies program of DOE is to resolve the QA gaps for the ARC software that limit, or prevent, commercialization of the software for industry users. This project started in earnest in fiscal year 2023 which saw the entire code system moved from a SVN repository to a GitLab repository and an associated software quality assurance plan (SQAP) developed and ratified. Most of the QA gaps in the ARC software were identified in collaboration with industry partners and work begin in fiscal year 2023 and continued through 2024 and 2025. The continuous integration testing was extended to RCT, DASSH, and SE2ANL. Minor changes were required to the original continuous integration methodology to make this happen. When full confidence in the methodology is complete, a report will be created to detail the automated regression testing methodology and minor reports will be created to detail the tolerance settings that have been applied to the output for each ARC code. The primary documentation that is missing includes user manuals, user guides, software verification reports, and code coverage assessments. The DASSH, SE2ANL, and SE2RCT manuals were completed this fiscal year. A review of the SE2ANL software identified that it is unrealistic to include updated correlations or different geometry models and it was scheduled for deprecation in favor of DASSH. The SE2ANL manual is essential for SE2RCT as they are similar but quite different in purpose. The only piece of software missing a manual consistent with the source code is NUBOW-3D which is a focus of the coming year. The code coverage report for DIF3D was updated and code coverage reports were created for REBUS, RCT, PERSENT, GAMSRC, and DASSH. Minor coverage issues were identified for all of these pieces of software which did not prevent the work done to transition them to the OneAPI compiler. Because SE2ANL was scheduled for deprecation, it was not transitioned, but it was successfully tested with the OneAPI compiler. This leaves SE2RCT and NUBOW-3D as the only pieces of software not transitioned to OneAPI and further work is required to get SE2RCT to work properly. The SE2RCT software transition will begin early next year while the NUBOW-3D software requires a manual before it can begin. Software verification work has been completed for DIF3D, REBUS, GAMSOR, GAMSRC, VARPOW, EvaluateFlux, and SUMMAR. The PERSENT software verification work was completed this year which was somewhat delayed because of unexpected bugs in the software. The PERSENT manual was updated to detail some of the issues and discuss the bowing reactivity worth feature added in the previous fiscal year. The RCT, DASSH, SE2RCT, and NUBOW-3D software are the only maintained pieces of software without verification reports. The software verification work for DASSH will be a focus in the upcoming fiscal year and it is hoped that some of the test cases created can serve as verification tests for SE2RCT. The NUBOW-3D work will begin when the manual and requirements report are completed. Only minor industry partner software development funds were provided this year. The DASSH software was updated to handle general axial geometry for each assembly and the NUBOW-3D software was updated to incorporate a new input format and better output. Overall progress on resolving the QA gaps has been good this year.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

Fiscal Year 2025 Software Quality Assurance Activities for the ARC Software

The continued goal of the ARC SQA project in the Advanced Reactor Technologies program of DOE is to resolve the QA gaps for the ARC software that limit, or prevent, commercialization of the software for industry users. This project started in earnest in fiscal year 2023 which saw the entire code system moved from a SVN repository to a GitLab repository and an associated software quality assurance plan (SQAP) developed and ratified. Most of the QA gaps in the ARC software were identified in collaboration with industry partners and work begin in fiscal year 2023 and continued through 2024 and 2025. The continuous integration testing was extended to RCT, DASSH, and SE2ANL. Minor changes were required to the original continuous integration methodology to make this happen. When full confidence in the methodology is complete, a report will be created to detail the automated regression testing methodology and minor reports will be created to detail the tolerance settings that have been applied to the output for each ARC code. The primary documentation that is missing includes user manuals, user guides, software verification reports, and code coverage assessments. The DASSH, SE2ANL, and SE2RCT manuals were completed this fiscal year. A review of the SE2ANL software identified that it is unrealistic to include updated correlations or different geometry models and it was scheduled for deprecation in favor of DASSH. The SE2ANL manual is essential for SE2RCT as they are similar but quite different in purpose. The only piece of software missing a manual consistent with the source code is NUBOW-3D which is a focus of the coming year. The code coverage report for DIF3D was updated and code coverage reports were created for REBUS, RCT, PERSENT, GAMSRC, and DASSH. Minor coverage issues were identified for all of these pieces of software which did not prevent the work done to transition them to the OneAPI compiler. Because SE2ANL was scheduled for deprecation, it was not transitioned, but it was successfully tested with the OneAPI compiler. This leaves SE2RCT and NUBOW-3D as the only pieces of software not transitioned to OneAPI and further work is required to get SE2RCT to work properly. The SE2RCT software transition will begin early next year while the NUBOW-3D software requires a manual before it can begin. Software verification work has been completed for DIF3D, REBUS, GAMSOR, GAMSRC, VARPOW, EvaluateFlux, and SUMMAR. The PERSENT software verification work was completed this year which was somewhat delayed because of unexpected bugs in the software. The PERSENT manual was updated to detail some of the issues and discuss the bowing reactivity worth feature added in the previous fiscal year. The RCT, DASSH, SE2RCT, and NUBOW-3D software are the only maintained pieces of software without verification reports. The software verification work for DASSH will be a focus in the upcoming fiscal year and it is hoped that some of the test cases created can serve as verification tests for SE2RCT. The NUBOW-3D work will begin when the manual and requirements report are completed. Only minor industry partner software development funds were provided this year. The DASSH software was updated to handle general axial geometry for each assembly and the NUBOW-3D software was updated to incorporate a new input format and better output. Overall progress on resolving the QA gaps has been good this year.

97 MATHEMATICS AND COMPUTING↗

EARTHDATA PUB: A Data Publication Workflow Solution for NASA’s EOSDIS

Each NASA Distributed Active Archive Center (DAAC) faces the challenge of dealing with an increasingly diverse number of publishable data products from diverse data producers. Data producers, on the other hand, may experience pain points when interacting with the EOSDIS for the first time or when publishing different data at different DAACs. As a result, there has been a growing need to develop a common software framework that serves as a common interface for data producers, rigorously defines the data publication procedure for DAAC staff, facilitates the management of various data publication processes, and tracks the progress of data publication. This software should also account for the different configurations at different DAACs. Currently, two primary data publication workflow and tracking tools exist in operation at the EOSDIS: Semi-Automated ingest System (SAuS) and Data Publication workflow Portal (DAPPeR). However, neither tool is cloud-ready. Automated data processing could be managed by Cumulus, an EOSDIS cloud-based data ingest, archive and management system. However, Cumulus does not support manual tasks or on-premise implementations. We propose to develop the Earthdata Publication Minimum Viable Product (Earthdata Pub MVP) -- a cloud-hosted solution that works with both cloud and on-premise systems and implements the communications and exchange requirements generated by the Earthdata Pub information architecture team.

Rice, Justin L.↗

The Chorus Conflict and Loss of Separation Resolution Algorithms

The Chorus software is designed to investigate near-term, tactical conflict and loss of separation detection and resolution concepts for air traffic management. This software is currently being used in two different problem domains: en-route self- separation and sense and avoid for unmanned aircraft systems. This paper describes the core resolution algorithms that are part of Chorus. The combination of several features of the Chorus program distinguish this software from other approaches to conflict and loss of separation resolution. First, the program stores a history of state information over time which enables it to handle communication dropouts and take advantage of previous input data. Second, the underlying conflict algorithms find resolutions that solve the most urgent conflict, but also seek to prevent secondary conflicts with the other aircraft. Third, if the program is run on multiple aircraft, and the two aircraft maneuver at the same time, the result will be implicitly co-ordinated. This implicit coordination property is established by ensuring that a resolution produced by Chorus will comply with a mathematically-defined criteria whose correctness has been formally verified. Fourth, the program produces both instantaneous solutions and kinematic solutions, which are based on simple accel- eration models. Finally, the program provides resolutions for recovery from loss of separation. Different versions of this software are implemented as Java and C++ software programs, respectively.

Butler, Ricky W.↗

Lessons Learned Implementing Multi-Mission Sequencing Software

This paper will describe the software and its uses to provide context for its criticality. The different approaches that have been taken to implement the software in a multi-mission format will be outlined. The advantages and disadvantages as well as the lessons learned during development and maintenance of these different architectures will be discussed, Finally. the use of multi-mission software in operations and the lessons learned from using it will be discussed.This paper will provide valuable information to organizations exploring the use of multi-mission software. regardless of whether the change is to minimize spacecraft ground software development time or cost reduction. Similarly. the paper will provide insight into some of the steps that can be taken during software development and operational use that will minimize difficulty later.

software↗

Autonomous Navigation, Guidance, and Control Software in a Low SWaP Box

Onboard autonomy is a necessity for responsive space operations. Autonomous navigation, guidance, and control (NGC) enables space missions to reduce their dependence on high demand ground assets and costly ground personnel. It also allows for in-situ decision making and higher return on mission data. A flight software and hardware system providing this capability, called “autoNGC,” is currently being developed at NASA Goddard Space Flight Center for infusion into multiple future missions. The autoNGC flight software is built on the plug-and-play architecture of the core Flight System (cFS) consisting of the standard cFS apps and newly developed autoNGC interface apps and libraries. The various apps cooperate through communication over the message-based software bus. With the plug-and-play architecture of autoNGC, cFS apps can easily be added and replaced to meet the needs of different missions, even after launch. The first flight software release of autoNGC is targeted for Summer 2024 to provide autonomous navigation at the Moon and beyond. It can perform sensor fusion of multiple measurement types including pseudo-range from a Global Navigation Satellite System (GNSS) receiver (including weak signal), 1-way and 2-way range and Doppler from ground stations (i.e., direct to Earth (DTE)), bearing and range from optical camera images, and accelerometer data. Accurate onboard navigation and timing is obtained through the Goddard Enhanced Onboard Navigation System (GEONS) software library which fuses different measurement types through an extended Kalman filter (EKF) framework. Optical measurements that are ingested in GEONS are first extracted from optical images by the cFS Goddard Image Analysis and Navigation Tool (cGIANT) app. If the imaged body is far enough away that it appears as a pixel or cluster of pixels, then bearing angles to the body centroid can be provided. If the body is close enough and the shape is known coarsely, then bearing angles and range to the body centroid can be derived from the limb. Bearing angles to individual surface features can also be extracted (i.e., terrain relative navigation (TRN)). Onboard guidance and control capabilities are being developed for a future release to perform autonomous station-keeping and trajectory correction maneuvers in multiple orbital regimes. Capabilities to enable distributed systems missions and constellations, such as crosslink measurements, and onboard time management are being developed as well. The first hardware implementation of autoNGC is a minimal size, weight, and power (SWaP) design allowing for inclusion into CubeSats and SmallSat-size buses. Advancements in miniaturized space processors, such as the SpaceCube 3.0 Mini and the SpaceCube Mini-Z are utilized for low SWaP while maintaining a high level of performance. The current enclosure design is 12 cm x 17 cm x 13.5 cm. The box mass is expected to be less than 2 kg, and the nominal power is 21 W. In order to accommodate a wide range of missions, the hardware interfaces are designed for flexibility with a variety of sensor inputs. Through comprehensive testing in the software-in-the-loop, processor-in-the-loop, and hardware-in-the-loop test beds that are concurrently being developed, autoNGC is expected to achieve TRL 6 by late 2024.

Sun Hur-Diaz↗

Validation of NSSC-I software for the Hubble Space Telescope

This paper describes the simulation and test methods used to ensure that the NASA Standard Spacecraft Computer, Model 1, (NSSC-I) flight software for the Hubble Space Telescope properly carries out its requirements for control of scientific observations and for monitoring the health and safety of the payload. The hardware and software test environment is discussed. The different kinds of tests (unit, special real time, and stress tests) that are performed before the software is incorporated into the flight system are described, and the kinds of errors that each test category is best suited to find are listed. Finally, the limitations of the tests are discussed, and current plans for enhancing the test environment are outlined.

Foley, Glenn↗

Using Colored Stochastic Petri Net (CS-PN) software for protocol specification, validation, and evaluation

The specification, verification, validation, and evaluation, which make up the different steps of the CS-PN software are outlined. The colored stochastic Petri net software is applied to a Wound/Wait protocol decomposable into two principal modules: request or couple (transaction, granule) treatment module and wound treatment module. Each module is specified, verified, validated, and then evaluated separately, to deduce a verification, validation and evaluation of the complete protocol. The colored stochastic Petri nets tool is shown to be a natural extension of the stochastic tool, adapted to distributed systems and protocols, because the color conveniently takes into account the numerous sites, transactions, granules and messages.

Zenie, Alexandre↗

Input/Output Subroutine Library Program

Efficient, easy-to-use program moved easily to different computers. Purpose of NAVIO, Input/Output Subroutine Library, provides input/output package of software for FORTRAN programs that is portable, efficient, and easy to use. Implemented as hierarchy of libraries. At bottom is very small library containing only non-portable routines called "I/O Kernel." Design makes NAVIO easy to move from one computer to another, by simply changing kernel. NAVIO appropriate for software system of almost any size wherein different programs communicate through files.

Collier, James B.↗

Validation of vision-based obstacle detection algorithms for low-altitude helicopter flight

A validation facility being used at the NASA Ames Research Center is described which is aimed at testing vision based obstacle detection and range estimation algorithms suitable for low level helicopter flight. The facility is capable of processing hundreds of frames of calibrated multicamera 6 degree-of-freedom motion image sequencies, generating calibrated multicamera laboratory images using convenient window-based software, and viewing range estimation results from different algorithms along with truth data using powerful window-based visualization software.

Suorsa, Raymond↗

Preferred Practices Through a Project Template

In the realm of scientific software development, adherence to best practices is often advocated. However, implementing these can be challenging due to differing opinions. Certain aspects, such as software licenses and naming conventions, are typically left to the discretion of the development team. Our team has established a set of preferred practices, informed by, but not limited to, widely accepted best practices. These preferred practices are derived from our understanding of the specific contexts and user needs we cater to. To facilitate the dissemination of these practices among our team and foster standardization with collaborating domain scientists, we have created a project template for Python projects. This template serves as a platform for discussing the implementation of various decisions. This paper will succinctly delineate the components that constitute an effective project template and elucidate the advantages of consolidating preferred practices in such a manner.

Zhang, Chen↗

Do Research Software Engineers and Software Engineering Researchers Speak the Same Language?

Anecdotal evidence suggests that research software engineers (RSEs) and software engineering researchers (SERs) often use different terminologies for similar concepts, creating communication challenges. To better understand these divergences, we have started investigating how software engineering fundamentals from the SER community are interpreted within the RSE community, identifying aligned concepts, knowledge gaps, and areas for potential adaptation. In conclusion, our preliminary findings reveal opportunities for mutual learning and collaboration, and our systematic methodology for terminology mapping provides a foundation for a crowdsourced extension and validation in the future.

Kehrer, Timo [Univ. of Bern (Switzerland)] (ORCID:↗

Assessment of Envelope- and Machine Learning-Based Electrical Fault Type Detection Algorithms for Electrical Distribution Grids

This study introduces envelope- and machine learning (ML)-based electrical fault type detection algorithms for electrical distribution grids, advancing beyond traditional logic-based methods. The proposed detection model involves three stages: anomaly area detection, ML-based fault presence detection, and ML-based fault type detection. Initially, an envelope-based detector identifying the anomaly region was improved to handle noisier power grid signals from meters. The second stage acts as a switch, detecting the presence of a fault among four classes: normal, motor, switching, and fault. Finally, if a fault is detected, the third stage identifies specific fault types. This study explored various feature extraction methods and evaluated different ML algorithms to maximize prediction accuracy. The performance of the proposed algorithms is tested in an emulated software–hardware electrical grid testbed using different sample rate meters/relays, such as SEL735, SEL421, SEL734, SEL700GT, and SEL351S near and far from an inverter-based photovoltaic array farm. The performance outcomes demonstrate the proposed model’s robustness and accuracy under realistic conditions.

24 POWER TRANSMISSION AND DISTRIBUTION↗

Study of application of space telescope science operations software for SIRTF use

The design and development of the Space Telescope Science Operations Ground System (ST SOGS) was evaluated to compile a history of lessons learned that would benefit NASA's Space Infrared Telescope Facility (SIRTF). Forty-nine specific recommendations resulted and were categorized as follows: (1) requirements: a discussion of the content, timeliness and proper allocation of the system and segment requirements and the resulting impact on SOGS development; (2) science instruments: a consideration of the impact of the Science Instrument design and data streams on SOGS software; and (3) contract phasing: an analysis of the impact of beginning the various ST program segments at different times. Approximately half of the software design and source code might be useable for SIRTF. Transportability of this software requires, at minimum, a compatible DEC VAX-based architecture and VMS operating system, system support software similar to that developed for SOGS, and continued evolution of the SIRTF operations concept and requirements such that they remain compatible with ST SOGS operation.

Dignam, F.↗

SSME Bearing and Seal Tester Data Compilation, Analysis and Reporting; and Refinement of the Cryogenic Bearing Analysis Mathematical Model

SRS and NASA/MSFC have developed software with unique capabilities to couple bearing kinematic modeling with high fidelity thermal modeling. The core thermomechanical modeling software was developed by SRS and others in the late 1980's and early 1990's under various different contractual efforts. SRS originally developed software that enabled SHABERTH (Shaft Bearing Thermal Model) and SINDA (Systems Improved Numerical Differencing Analyzer) to exchange data and autonomously allowing bearing component temperature effects to propagate into the steady state bearing mechanical model. A separate contract was issued in 1990 to create a personal computer version of the software. At that time SRS performed major improvements to the code. Both SHABERTH and SINDA were independently ported to the PC and compiled. SRS them integrated the two programs into a single program that was named SINSHA. This was a major code improvement.

Moore, James↗

SSME Bearing and Seal Tester Data Compilation, Analysis, and Reporting; and Refinement of the Cryogenic Bearing Analysis Mathematical Model

SRS and NASA/MSFC have developed software with unique capabilities to couple bearing kinematic modeling with high fidelity thermal modeling. The core thermomechanical modeling software was developed by SRS and others in the late 1980's and early 1990's under various different contractual efforts. SRS originally developed software that enabled SHABERTH (Shaft Bearing Thermal Model) and SINDA (Systems Improved Numerical Differencing Analyzer) to exchange data and autonomously allowing bearing component temperature effects to propagate into the steady state bearing mechanical model. A separate contract was issued in 1990 to create a personal computer version of the software. At that time SRS performed major improvements to the code. Both SHABERTH and SINDA were independently ported to the PC and compiled. SRS them integrated the two programs into a single program that was named SINSHA. This was a major code improvement.

Moore, James↗