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,405 records · Page 78

All sources NASA NTRS DOE OSTI

NASA NTRS2001

Risk reduction using DDP (Defect Detection and Prevention): Software support and software applications

Risk assessment and mitigation is the focus of the Defect Detection and Prevention (DDP) process, which has been applied to spacecraft technology assessments and planning, both hardware and software. DDP's major elements and their relevance to core requirement engineering concerns are summarized. The accompanying research demonstration illustrates DDP's tool support, and further customizations for application to software.

Software-specific customizations↗

NASA NTRS2013

Cloud Absorption Radiometer Autonomous Navigation System - CANS

CAR (cloud absorption radiometer) acquires spatial reference data from host aircraft navigation systems. This poses various problems during CAR data reduction, including navigation data format, accuracy of position data, accuracy of airframe inertial data, and navigation data rate. Incorporating its own navigation system, which included GPS (Global Positioning System), roll axis inertia and rates, and three axis acceleration, CANS expedites data reduction and increases the accuracy of the CAR end data product. CANS provides a self-contained navigation system for the CAR, using inertial reference and GPS positional information. The intent of the software application was to correct the sensor with respect to aircraft roll in real time based upon inputs from a precision navigation sensor. In addition, the navigation information (including GPS position), attitude data, and sensor position details are all streamed to a remote system for recording and later analysis. CANS comprises a commercially available inertial navigation system with integral GPS capability (Attitude Heading Reference System AHRS) integrated into the CAR support structure and data system. The unit is attached to the bottom of the tripod support structure. The related GPS antenna is located on the P-3 radome immediately above the CAR. The AHRS unit provides a RS-232 data stream containing global position and inertial attitude and velocity data to the CAR, which is recorded concurrently with the CAR data. This independence from aircraft navigation input provides for position and inertial state data that accounts for very small changes in aircraft attitude and position, sensed at the CAR location as opposed to aircraft state sensors typically installed close to the aircraft center of gravity. More accurate positional data enables quicker CAR data reduction with better resolution. The CANS software operates in two modes: initialization/calibration and operational. In the initialization/calibration mode, the software aligns the precision navigation sensors and initializes the communications interfaces with the sensor and the remote computing system. It also monitors the navigation data state for quality and ensures that the system maintains the required fidelity for attitude and positional information. In the operational mode, the software runs at 12.5 Hz and gathers the required navigation/attitude data, computes the required sensor correction values, and then commands the sensor to the required roll correction. In this manner, the sensor will stay very near to vertical at all times, greatly improving the resulting collected data and imagery. CANS greatly improves quality of resulting imagery and data collected. In addition, the software component of the system outputs a concisely formatted, high-speed data stream that can be used for further science data processing. This precision, time-stamped data also can benefit other instruments on the same aircraft platform by providing extra information from the mission flight.

Kahle, Duncan↗

NASA NTRS2012

Onboard Sensor Data Qualification in Human-Rated Launch Vehicles

The avionics system software for human-rated launch vehicles requires an implementation approach that is robust to failures, especially the failure of sensors used to monitor vehicle conditions that might result in an abort determination. Sensor measurements provide the basis for operational decisions on human-rated launch vehicles. This data is often used to assess the health of system or subsystem components, to identify failures, and to take corrective action. An incorrect conclusion and/or response may result if the sensor itself provides faulty data, or if the data provided by the sensor has been corrupted. Operational decisions based on faulty sensor data have the potential to be catastrophic, resulting in loss of mission or loss of crew. To prevent these later situations from occurring, a Modular Architecture and Generalized Methodology for Sensor Data Qualification in Human-rated Launch Vehicles has been developed. Sensor Data Qualification (SDQ) is a set of algorithms that can be implemented in onboard flight software, and can be used to qualify data obtained from flight-critical sensors prior to the data being used by other flight software algorithms. Qualified data has been analyzed by SDQ and is determined to be a true representation of the sensed system state; that is, the sensor data is determined not to be corrupted by sensor faults or signal transmission faults. Sensor data can become corrupted by faults at any point in the signal path between the sensor and the flight computer. Qualifying the sensor data has the benefit of ensuring that erroneous data is identified and flagged before otherwise being used for operational decisions, thus increasing confidence in the response of the other flight software processes using the qualified data, and decreasing the probability of false alarms or missed detections.

Wong, Edmond↗

NASA NTRS1991

A software development and evolution model based on decision-making

Design is a complex activity whose purpose is to construct an artifact which satisfies a set of constraints and requirements. However the design process is not well understood. The software design and evolution process is the focus of interest, and a three dimensional software development space organized around a decision-making paradigm is presented. An initial instantiation of this model called 3DPM(sub p) which was partly implemented, is presented. Discussion of the use of this model in software reuse and process management is given.

Wild, J. Christian↗

NASA NTRS1990

Methodology for automating software systems

Applying ITS technology to the shuttle diagnostics would not require the rigor of the Petri Net representation, however it is important in providing the animated simulated portion of the interface and the demands placed on the system to support the training aspects to have a homogeneous and consistent underlying knowledge representation. By keeping the diagnostic rule base, the hardware description, the software description, user profiles, desired behavioral knowledge, and the user interface in the same notation, it is possible to reason about the all of the properties of petri nets, on any selected portion of the simulation. This reasoning provides foundation for utilization of intelligent tutoring systems technology.

Moseley, Warren↗

NASA NTRS2024

The Thermal Structure and Composition of Jupiter's Great Red Spot From JWST/MIRI

Jupiter's Great Red Spot (GRS) was mapped by the James Webb Space Telescope (JWST)/Mid-Infrared Instrument (4.9–27.9 μm) in July and August 2022. These observations took place alongside a suite of visual and infrared observations from; Hubble, JWST/NIRCam, Very Large Telescope/VISIR and amateur observers which provided both spatial and temporal context across the jovian disc. The stratospheric temperature structure retrieved using the NEMESIS software revealed a series of hot-spots above the GRS. These could be the consequence of GRS-induced wave activity. In the troposphere, the temperature structure was used to derive the thermal wind structure of the GRS vortex. These winds were only consistent with the independently determined wind field by JWST/NIRCam at 240 mbar if the altitude of the Hubble-derived winds were located around 1,200 mbar, considerably deeper than previously assumed. No enhancement in ammonia was found within the GRS but a link between elevated aerosol and phosphine abundances was observed within this region. North-south asymmetries were observed in the retrieved temperature, ammonia, phosphine and aerosol structure, consistent with the GRS tilting in the north-south direction. Finally, a small storm was captured north-west of the GRS that displayed a considerable excess in retrieved phosphine abundance, suggestive of vigorous convection. Despite this, no ammonia ice was detected in this region. The novelty of JWST required us to develop custom-made software to resolve challenges in calibration of the data. This involved the derivation of the “FLT-5” wavelength calibration solution that has subsequently been integrated into the standard calibration pipeline.

Jake Harkett↗

DOE OSTI2026

Opportunities in AI/ML for the Rubin LSST Dark Energy Science Collaboration

The Vera C. Rubin Observatory's Legacy Survey of Space and Time (LSST) will produce unprecedented volumes of heterogeneous astronomical data (images, catalogs, and alerts) that challenge traditional analysis pipelines. The LSST Dark Energy Science Collaboration (DESC) aims to derive robust constraints on dark energy and dark matter from these data, requiring methods that are statistically powerful, scalable, and operationally reliable. Artificial intelligence and machine learning (AI/ML) are already embedded across DESC science workflows, from photometric redshifts and transient classification to weak lensing inference and cosmological simulations. Yet their utility for precision cosmology hinges on trustworthy uncertainty quantification, robustness to covariate shift and model misspecification, and reproducible integration within scientific pipelines. This white paper surveys the current landscape of AI/ML across DESC's primary cosmological probes and cross-cutting analyses, revealing that the same core methodologies and fundamental challenges recur across disparate science cases. Since progress on these cross-cutting challenges would benefit multiple probes simultaneously, we identify key methodological research priorities, including Bayesian inference at scale, physics-informed methods, validation frameworks, and active learning for discovery. With an eye on emerging techniques, we also explore the potential of the latest foundation model methodologies and LLM-driven agentic AI systems to reshape DESC workflows, provided their deployment is coupled with rigorous evaluation and governance. Finally, we discuss critical software, computing, data infrastructure, and human capital requirements for the successful deployment of these new methodologies, and consider associated risks and opportunities for broader coordination with external actors.

Aubourg, Eric [APC, Paris] (ORCID:000000025592023X↗

NASA NTRS1988

Artificial intelligence approaches to software engineering

Artificial intelligence approaches to software engineering are examined. The software development life cycle is a sequence of not so well-defined phases. Improved techniques for developing systems have been formulated over the past 15 years, but pressure continues to attempt to reduce current costs. Software development technology seems to be standing still. The primary objective of the knowledge-based approach to software development presented in this paper is to avoid problem areas that lead to schedule slippages, cost overruns, or software products that fall short of their desired goals. Identifying and resolving software problems early, often in the phase in which they first occur, has been shown to contribute significantly to reducing risks in software development. Software development is not a mechanical process but a basic human activity. It requires clear thinking, work, and rework to be successful. The artificial intelligence approaches to software engineering presented support the software development life cycle through the use of software development techniques and methodologies in terms of changing current practices and methods. These should be replaced by better techniques that that improve the process of of software development and the quality of the resulting products. The software development process can be structured into well-defined steps, of which the interfaces are standardized, supported and checked by automated procedures that provide error detection, production of the documentation and ultimately support the actual design of complex programs.

Johannes, James D.↗

NASA NTRS1983

Software fault tolerance for real-time avionics systems

Avionics systems have very high reliability requirements and are therefore prime candidates for the inclusion of fault tolerance techniques. In order to provide tolerance to software faults, some form of state restoration is usually advocated as a means of recovery. State restoration can be very expensive for systems which utilize concurrent processes. The concurrency present in most avionics systems and the further difficulties introduced by timing constraints imply that providing tolerance for software faults may be inordinately expensive or complex. A straightforward pragmatic approach to software fault tolerance which is believed to be applicable to many real-time avionics systems is proposed. A classification system for software errors is presented together with approaches to recovery and continued service for each error type.

Anderson, T.↗

NASA NTRS1993

Minimum Hamiltonian ascent trajectory evaluation (MASTRE) program (update to automatic flight trajectory design, performance prediction, and vehicle sizing for support of shuttle and shuttle derived vehicles) users manual

Documentation for the User Interface Program for the Minimum Hamiltonian Ascent Trajectory Evaluation (MASTRE) is provided. The User Interface Program is a separate software package designed to ease the user input requirements when using the MASTRE Trajectory Program. This document supplements documentation on the MASTRE Program that consists of the MASTRE Engineering Manual and the MASTRE Programmers Guide. The User Interface Program provides a series of menus and tables using the VAX Screen Management Guideline (SMG) software. These menus and tables allow the user to modify the MASTRE Program input without the need for learning the various program dependent mnemonics. In addition, the User Interface Program allows the user to modify and/or review additional input Namelist and data files, to build and review command files, to formulate and calculate mass properties related data, and to have a plotting capability.

Lyons, J. T.↗

NASA NTRS1993

The Cassini spacecraft: Object oriented flight control software

The Cassini Attitude and Articulation Control Subsystem (AACS) is responsible for determining and controlling the spacecraft attitude including instrument pointing, antenna pointing, and thrust vector pointing during velocity change maneuvers. The 12 year mission life, long round-trip light time, and extended periods of coast without continuous ground control drive the AACS flight software design in the directions of autonomy, fault tolerance, and modularity to accommodate planned upgrades in flight. The Cassini AACS Flight Software is depicted in increasing levels of detail using a Context Diagram, Architecture Diagrams (i.e., Dependency Diagrams), an Object Diagram for each object, and a Statechart (i.e., State Transition Diagram) for each object. The detail contained in the diagrams is enhanced and refined during the Requirements and Design Phases of both Subsystem and Software Development. Examples of all the diagrams as well as the criteria for object selection, the advantages of statecharts, and the ease of modifying the design to accommodate changes in scope are described.

Hackney, John C.↗

DOE OSTI2021

SD-WAN Evaluation Criteria for a Defense Information Systems Network Expeditionary Customer Edge

The Defense Information Systems Agency (DISA) has identified a service provision gap midway between the capacity and capability of a Defense Information Systems Network (DISN) transport Edge Points of Presence (POP) and U.S. Department of Defense (DoD) Enterprise Classified Travel Kit (DECTK). Some deployed force 100-user Tactical Operations Centers are in field locations far removed from the DISN transport core, in challenging environmental conditions with limitations on space, weight, power, and cooling for network equipment. As part of a multi-phase project, Pacific Northwest National Laboratory (PNNL) will gather and analyze requirements, design, develop, prototype, and test a miniaturized and ruggedized DISN Customer Edge POP scaled to support approximately 100 users in a field Tactical Operations Center. An Expeditionary Customer Edge (ECE) will be more suitable for field deployment than a DISN transport Edge POP, using ruggedized hardware and network function virtualization (NFV) to operate in challenging field environmental conditions, plus reduce weight, power, and cooling requirements. A key enabling technology for ECE is Software Defined Wide Area Networking (SD-WAN). This document provides: • A brief overview of SD-WAN use cases and how they apply to ECE • How SD-WAN technology compares to existing networks like DISN that use Optical Transport Networking (OTN) and Multiprotocol Label Switching (MPLS) • SD-WAN functional requirements relevant to ECE • A description of an ECE Virtual Prototype, including simulated wide area network paths and a DISN-representative implementation of MPLS, in Cisco Modeling Labs • Detailed network flow walkthroughs • Evaluation criteria based on ECE-relevant SD-WAN functional requirements Finally, an appendix provides an informal evaluation of Speedify—a commercial retail Virtual Private Network service—against the ECE SD-WAN evaluation criteria.

42 ENGINEERING↗

NASA NTRS2013

Mission Operations Center (MOC) - Precipitation Processing System (PPS) Interface Software System (MPISS)

MPISS is an automatic file transfer system that implements a combination of standard and mission-unique transfer protocols required by the Global Precipitation Measurement Mission (GPM) Precipitation Processing System (PPS) to control the flow of data between the MOC and the PPS. The primary features of MPISS are file transfers (both with and without PPS specific protocols), logging of file transfer and system events to local files and a standard messaging bus, short term storage of data files to facilitate retransmissions, and generation of file transfer accounting reports. The system includes a graphical user interface (GUI) to control the system, allow manual operations, and to display events in real time. The PPS specific protocols are an enhanced version of those that were developed for the Tropical Rainfall Measuring Mission (TRMM). All file transfers between the MOC and the PPS use the SSH File Transfer Protocol (SFTP). For reports and data files generated within the MOC, no additional protocols are used when transferring files to the PPS. For observatory data files, an additional handshaking protocol of data notices and data receipts is used. MPISS generates and sends to the PPS data notices containing data start and stop times along with a checksum for the file for each observatory data file transmitted. MPISS retrieves the PPS generated data receipts that indicate the success or failure of the PPS to ingest the data file and/or notice. MPISS retransmits the appropriate files as indicated in the receipt when required. MPISS also automatically retrieves files from the PPS. The unique feature of this software is the use of both standard and PPS specific protocols in parallel. The advantage of this capability is that it supports users that require the PPS protocol as well as those that do not require it. The system is highly configurable to accommodate the needs of future users.

Ferrara, Jeffrey↗

NASA NTRS1998

An Adaptable Power System with Software Control Algorithm

A low cost, flexible and modular spacecraft power system design was developed in response to a call for an architecture that could accommodate multiple missions in the small to medium load range. Three upcoming satellites will use this design, with one launch date in 1999 and two in the year 2000. The design consists of modular hardware that can be scaled up or down, without additional cost, to suit missions in the 200 to 600 Watt orbital average load range. The design will be applied to satellite orbits that are circular, polar elliptical and a libration point orbit. Mission unique adaptations are accomplished in software and firmware. In designing this advanced, adaptable power system, the major goals were reduction in weight volume and cost. This power system design represents reductions in weight of 78 percent, volume of 86 percent and cost of 65 percent from previous comparable systems. The efforts to miniaturize the electronics without sacrificing performance has created streamlined power electronics with control functions residing in the system microprocessor. The power system design can handle any battery size up to 50 Amp-hour and any battery technology. The three current implementations will use both nickel cadmium and nickel hydrogen batteries ranging in size from 21 to 50 Amp-hours. Multiple batteries can be used by adding another battery module. Any solar cell technology can be used and various array layouts can be incorporated with no change in Power System Electronics (PSE) hardware. Other features of the design are the standardized interfaces between cards and subsystems and immunity to radiation effects up to 30 krad Total Ionizing Dose (TID) and 35 Mev/cm(exp 2)-kg for Single Event Effects (SEE). The control algorithm for the power system resides in a radiation-hardened microprocessor. A table driven software design allows for flexibility in mission specific requirements. By storing critical power system constants in memory, modifying the system code for other programs is simple. These constants can be altered also by ground command, or in response to an anomolous event. All critical power system functions have backup hardware functions to prevent a software or computer glitch from propagating. A number of battery charge control schemes can be implemented by selecting the proper control terms in the code. The architecture allows the design engineer to tune the system response to various system components and anticipated load profiles without costly alterations. A design trade was made with the size, weight and power dissipation of the electronics versus the performance of the power bus to load variations. Linear, fine control is maintained with a streamlined electronics design. This paper describes the hardware design as well as the software control algorithm. The challenges of closing the system control loop digitally is discussed. Control loop margin and power system performance is presented. Lab measurements are shown and compared to the system response of a hardware model running actual flight software.

Castell, Karen↗

NASA NTRS1998

Flight Guidance System Validation Using SPIN

To verify the requirements for the mode control logic of a Flight Guidance System (FGS) we applied SPIN, a widely used software package that supports the formal verification of distributed systems. These requirements, collectively called the FGS specification, were developed at Rockwell Avionics & Communications and expressed in terms of the Consortium Requirements Engineering (CoRE) method. The properties to be verified are the invariants formulated in the FGS specification, along with the standard properties of consistency and completeness. The project had two stages. First, the FGS specification and the properties to be verified were reformulated in PROMELA, the input language of SPIN. This involved a semantics issue, as some constructs of the FGS specification do not have well-defined semantics in CoRE. Then we attempted to verify the requirements' properties using the automatic model checking facilities of SPIN. Due to the large size of the state space of the FGS specification an exhaustive state space analysis with SPIN turned out to be impossible. So we used the supertrace model checking procedure of SPIN that provides for a partial analysis of the state space. During this process, we found some subtle errors in the FGS specification.

Naydich, Dimitri↗

DOE OSTI2026

Generalizable Web User Interface for Scalable and Streamlined Deployment of Building Energy Management Systems in Small and Medium-Sized Commercial Buildings

Small and medium-sized commercial buildings (SMCBs) comprise 94% of US commercial buildings yet face significant barriers to implementing building energy management systems despite advances in smart device technology. Existing solutions present critical limitations: cloud-based API solutions simplify deployment but create vendor lock-in constraints; commercial integrated software solutions ensure compatibility via standardized protocols but require substantial cost and technical expertise; open-source IoT platforms offer cost-effective vendor independence but provide insufficient standardized protocol support for commercial building automation. This research presents a generalizable web user interface framework that bridges the gap between evolving smart device capabilities and lagging software infrastructure for SMCBs. The proposed system integrates VOLTTRON open-source middleware with an automated configuration converter that transforms unified specifications written in YAML, a human-readable data-serialization format, into system-specific files, streamlining manual setup processes. The vendor-agnostic architecture supports industry-standard protocols (BACnet and Modbus) and semantic building models while providing adaptive web interfaces that dynamically adjust to various building configurations. Demonstrations through simulation-based testing and a field deployment show automatic interface adaptation across heterogeneous HVAC systems and multizone monitoring. The automated configuration converter also substantially reduces labor-intensive setup.

Chung, Jihoon [ORNL] (ORCID:0000000184880815)↗

NASA NTRS1989

Integrating NASA's Land Analysis System (LAS) image processing software with an appropriate Geographic Information System (GIS): A review of candidates in the public domain

A user requirements analysis (URA) was undertaken to determine and appropriate public domain Geographic Information System (GIS) software package for potential integration with NASA's LAS (Land Analysis System) 5.0 image processing system. The necessity for a public domain system was underscored due to the perceived need for source code access and flexibility in tailoring the GIS system to the needs of a heterogenous group of end-users, and to specific constraints imposed by LAS and its user interface, Transportable Applications Executive (TAE). Subsequently, a review was conducted of a variety of public domain GIS candidates, including GRASS 3.0, MOSS, IEMIS, and two university-based packages, IDRISI and KBGIS. The review method was a modified version of the GIS evaluation process, development by the Federal Interagency Coordinating Committee on Digital Cartography. One IEMIS-derivative product, the ALBE (AirLand Battlefield Environment) GIS, emerged as the most promising candidate for integration with LAS. IEMIS (Integrated Emergency Management Information System) was developed by the Federal Emergency Management Agency (FEMA). ALBE GIS is currently under development at the Pacific Northwest Laboratory under contract with the U.S. Army Corps of Engineers' Engineering Topographic Laboratory (ETL). Accordingly, recommendations are offered with respect to a potential LAS/ALBE GIS linkage and with respect to further system enhancements, including coordination with the development of the Spatial Analysis and Modeling System (SAMS) GIS in Goddard's IDM (Intelligent Data Management) developments in Goddard's National Space Science Data Center.

Rochon, Gilbert L.↗

NASA NTRSDate not supplied

Swift Mission Gyro Patch and Re-Calibration Without A Calibration Campaign

The Swift spacecraft has three Two-Axis-Rate-Assemblies (TARAs) (designated as TARA 1, TARA 2, and TARA 3, and generically referred to as gyros) which until March of 2024 were all used in rate estimation as an operational workaround (dubbed “corrector-gyro”) of a software defect discovered in 2007. TARA 1 performance degraded throughout 2023 and 2024, making it an unreliable rate source. It was determined that shifting TARA 1 to be the corrector-gyro and using mainly TARAs 2 and 3, with the existing flight software (FSW) defect, would not meet performance requirements for science operations. Rather the FSW was patched to remove the defect found in 2007. This patch was delivered by the vendor in 2009, but was not fully tested or installed at that time. A decision was made in 2024 to install the patch despite limited simulation and testing capabilities. The problem facing the team was to come up with a set of alignment parameters that would work with the new patch, using data from the spacecraft operating normally in the old configuration. Calibration activities would have been possible in either the old or new FSW configuration, but were ultimately deemed unnecessary, saving staff time and pre-serving time on the spacecraft for science data collection. This paper describes the old and new FSW configurations related to gyro processing and alignment, and how the raw gyro and star tracker data from normal operation were used with a multidimensional unconstrained nonlinear minimization in MATLAB (Nelder-Mead1) to produce a fully calibrated set of gyro alignment parameters compatible with the patched FSW. Flight data is presented showing that not only did the process work, it improved performance significantly, rivaling the best slew performance of the mission to date.

MATLAB↗