SEARCH · Search NASA
Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.
Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.
A backup software program is installed in an isolated portion in the memory of at least one of redundant computers. The backup program performs basically the same functions as the prime program but is dissimilarly programmed to prevent a common software error. Switchover to the backup program occurs either automatically in response to monitors, or manually by the operator (i.e. pilot) when he detects an anomaly.
One of the figures (Fig. 4) in "Solar sources and geospace consequences of interplanetary magnetic Clouds observed during solar cycle 23 -- Paper 1" by Gopalswamy et al. (2008, JASTP, Vol. 70, Issues 2-4, February 2008, pp. 245-253) is incorrect because of a software error in t he routine that was used to make the plot. The source positions of various magnetic cloud (MC) types are therefore not plotted correctly.
An open source computer program has been developed to satisfy a need for simplified organization of structured input data for scientific simulation programs. Typically, such input data are parsed in from a flat American Standard Code for Information Interchange (ASCII) text file into computational data structures. Also typically, when a graphical user interface (GUI) is used, there is a need to completely duplicate the input information while providing it to a user in a more structured form. Heretofore, the duplication of the input information has entailed duplication of software efforts and increases in susceptibility to software errors because of the concomitant need to maintain two independent input-handling mechanisms. The present program implements a method in which the input data for a simulation program are completely specified in an Extensible Markup Language (XML)-based text file. The key benefit for XML is storing input data in a structured manner. More importantly, XML allows not just storing of data but also describing what each of the data items are. That XML file contains information useful for rendering the data by other applications. It also then generates data structures in the C++ language that are to be used in the simulation program. In this method, all input data are specified in one place only, and it is easy to integrate the data structures into both the simulation program and the GUI. XML-to-C is useful in two ways: 1. As an executable, it generates the corresponding C++ classes and 2. As a library, it automatically fills the objects with the input data values.
The purpose of this paper is to provide an overview of the current trends and practices in small-satellite software verification and validation. This document is not intended to promote a specific software assurance method. Rather, it seeks to present an unbiased survey of software assurance methods used to verify and validate small satellite software and to make mention of the benefits and value of each approach. These methods include simulation and testing, verification and validation with model-based design, formal methods, and fault-tolerant software design with run-time monitoring. Although the literature reveals that simulation and testing has by far the longest legacy, model-based design methods are proving to be useful for software verification and validation. Some work in formal methods, though not widely used for any satellites, may offer new ways to improve small satellite software verification and validation. These methods need to be further advanced to deal with the state explosion problem and to make them more usable by small-satellite software engineers to be regularly applied to software verification. Last, it is explained how run-time monitoring, combined with fault-tolerant software design methods, provides an important means to detect and correct software errors that escape the verification process or those errors that are produced after launch through the effects of ionizing radiation.
Neuromorphic processors, inspired by the wiring of the brain, permit certain classes of Artificial Intelligence/Machine Learning (AI/ML) algorithms to run far more efficiently. Ultimately, such systems will make the small- and nano-satellite platforms even more useful in terms of greatly improved power, communication and internal data management. In addition, on-board processing of images and data will help to not only rapidly interpret the information, but also reduce the amount of data that needs to be transmitted to ground stations. This initial flight experiment uses the Intel/ Loihi processor combined with a custom interface board and three communication channels to run the AI/ML scripts. These will vary with increasing length and complexity during the course of the mission. The algorithms will use the (at first) limited sensor data to ‘learn’ - with comparisons to similar architecture in comparable ground experiments. Some of the applications for successor flights in the TES-n flight series include Cognitive Communications, whereby the overall communication system is optimized per overflight – by optimizing timing and data transmission functions. Lastly, the performance of the Loihi 14nm process technology will be monitored for performance in the LEO radiation environment, thus looking for induced hardware and software errors. This information will help guide future radiation protection techniques to extend the lifetime and overall utility. The TES-13 is a 3U nanosat successfully launched by the Virgin Orbit Launcher-1 on January 13, 2022, and will presage more flights and AI/ML applications to come.
Despite major efforts to automate air traffic control (ATC), it is still performed by humans today. The complexity and safety-criticality of ATC makes it very difficult to safely automate, but it must be automated to increase airspace capacity (the density of traffic that can be safely managed) and airport throughput (the number of arrivals and departures that an airport can safely handle in a given period of time) beyond what is possible with human controllers. This paper presents the Trajectory Specification (TS) concept, which can help to safely automate ATC. TS is a method of specifying aircraft trajectories such that the position at any given time in flight is restricted to a precisely defined bounding space, removing all ambiguity as to where the flight is allowed to be. The bounding space or volume is determined by tolerances relative to a reference trajectory (position as a function of time). The tolerances are dynamic and are based on the aircraft navigation capabilities and the traffic situation. The tolerances can be a piecewise linear function of time or distance along the route, allowing the tolerances to vary as needed, typically increasing with time for departures and decreasing for arrivals. A Trajectory Specification Language (TSL) is proposed for communicating trajectories from aircraft to ATC as requests and from ATC to aircraft as assignments. The TS concept requires a new generation of airborne Flight Management Systems (FMS) that understand the TSL and can fly the assigned trajectories, but this paper focuses on the ATC functions and the prototype ATC algorithms and software that were developed to test the TS concept. Assuming conformance, TS can guarantee safe separation for an arbitrary length of time even in the event of an ATC system or communication outage. It can help to achieve the high level of safety and reliability needed for ATC automation, and it can also reduce the reliance on ATC backup systems for tactical conflict detection and resolution during normal operation. TS can be applied to any controlled airspace, including enroute, terminal, and urban airspace, but this paper presents algorithms and software for arrival spacing and conflict detection and resolution in the terminal airspace serving a major airport. In a fast-time simulation of a full day of traffic in a major terminal airspace, all conflicts were resolved in near real time, demonstrating the computational feasibility and the preliminary operational feasibility of the TS concept. This paper is a compilation of previous papers, and it adds significant information that was omitted from those papers due to length limitations. It also updates some of the results of those earlier papers due to algorithm refinements and corrections of minor software errors.
Neuromorphic processors, inspired by the wiring of the brain, permit certain classes of Artificial Intelligence/Machine Learning (AI/ML) algorithms to run far more efficiently. Ultimately, such systems will make the small- and nano-satellite platforms even more useful in terms of greatly improved power, communication and internal data management. In addition, on-board processing of images and data will help to not only rapidly interpret the information, but also reduce the amount of data that needs to be transmitted to ground stations. This initial flight experiment uses the Intel/Loihi processor combined with a custom interface board and three communication channels to run the AI/ML scripts. These will vary with increasing length and complexity during the course of the mission. The algorithms will use the (at first) limited sensor data to ‘learn’ - with comparisons to similar architecture in comparable ground experiments. Some of the applications for successor flights in the TES-n flight series include Cognitive Communications, whereby the overall communication system is optimized per overflight – by optimizing timing and data transmission functions. Lastly, the performance of the Loihi 14nm process technology will be monitored for performance in the LEO radiation environment, thus looking for induced hardware and software errors. This information will help guide future radiation protection techniques to extend the lifetime and overall utility. The TES-13 is a 3U nanosat successfully launched by the Virgin Orbit Launcher-1 on January 13, 2022, and will presage more flights and AI/ML applications to come.
Strategies to detect, correct, or mitigate the impact of soft errors rely on errors-injection experiments. For efficient evaluation, such experiments typically inject errors in software by sampling errors from a candidate distribution. Most often, these strategies randomly select and flip one bit in the output of an instruction. While single-bit flips might constitute a meaningful model for errors affecting hardware, the appropriateness of this model for software-based errors has not been studied. In this paper, we study the manifestation of errors in the output registers due to errors affecting candidate instructions executed by floating point ALUs. We inject single-bit flips into the RTL descriptions of floating point ALUs and analyze the differences between anticipated and observed outputs when executing floating-point addition, subtraction, multiplication, and division. We choose the operands for these instructions randomly and from operands observed in five benchmarks. We observe a rich distribution of errors in the output and analyze their implications for software-based fault-injection campaigns.
Software-only and software-hardware optimizations to reduce the overhead of intra-thread instruction duplication on a GPU or other instruction processor are disclosed. The optimizations trade off error containment for performance and include ISA extensions with limited hardware changes and area costs.
Fundamental to the development of redundant software techniques fault-tolerant software, is an understanding of the impact of multiple-joint occurrences of coincident errors. A theoretical basis for the study of redundant software is developed which provides a probabilistic framework for empirically evaluating the effectiveness of the general (N-Version) strategy when component versions are subject to coincident errors, and permits an analytical study of the effects of these errors. The basic assumptions of the model are: (1) independently designed software components are chosen in a random sample; and (2) in the user environment, the system is required to execute on a stationary input series. The intensity of coincident errors, has a central role in the model. This function describes the propensity to introduce design faults in such a way that software components fail together when executing in the user environment. The model is used to give conditions under which an N-Version system is a better strategy for reducing system failure probability than relying on a single version of software. A condition which limits the effectiveness of a fault-tolerant strategy is studied, and it is posted whether system failure probability varies monotonically with increasing N or whether an optimal choice of N exists.
We introduce Mitiq, a Python package for error mitigation on noisy quantum computers. Error mitigation techniques can reduce the impact of noise on near-term quantum computers with minimal overhead in quantum resources by relying on a mixture of quantum sampling and classical post-processing techniques. Mitiq is an extensible toolkit of different error mitigation methods, including zero-noise extrapolation, probabilistic error cancellation, and Clifford data regression. The library is designed to be compatible with generic backends and interfaces with different quantum software frameworks. We describe Mitiq using code snippets to demonstrate usage and discuss features and contribution guidelines. We present several examples demonstrating error mitigation on IBM and Rigetti superconducting quantum processors as well as on noisy simulators.
Fundamental to the development of redundant software techniques (known as fault-tolerant software) is an understanding of the impact of multiple joint occurrences of errors, referred to here as coincident errors. A theoretical basis for the study of redundant software is developed which: (1) provides a probabilistic framework for empirically evaluating the effectiveness of a general multiversion strategy when component versions are subject to coincident errors, and (2) permits an analytical study of the effects of these errors. An intensity function, called the intensity of coincident errors, has a central role in this analysis. This function describes the propensity of programmers to introduce design faults in such a way that software components fail together when executing in the application environment. A condition under which a multiversion system is a better strategy than relying on a single version is given.
Rigorous methods and models are needed to quantify, measure, and increase the cyber resilience of critical infrastructure. An adversary may exploit vulnerabilities in the vital networks such as industrial control systems (ICS) associated with critical infrastructure (e.g., energy, financial, transportation, security), in order to achieve harmful consequences. In cyber systems, the number of vulnerabilities may be large, the attack surface changes over time, and the problem consists of both technical and non-technical factors (e.g., errors in software and human error). Given this complex and dynamic landscape, strategically mitigating risk is important, where “risk” considers both the probability of an event and the consequences if that event occurs. One way to decrease risk is to address consequences by ensuring that critical infrastructure is resilient. In this context, resilience is characterized by the magnitude and duration of a deviation from targeted performance levels, given a disruption. Increasing resilience decreases the consequences of a successful attack.
An error reporting system utilizes a parity checker to receive data results from execution of an original instruction and a parity bit for the data. A decoder receives an error correcting code (ECC) for data resulting from execution of a shadow instruction of the original instruction, and data error correction is initiated on the original instruction result on condition of a mismatch between the parity bit and the original instruction result, and the decoder asserting a correctable error in the original instruction result.
In various embodiments, a software program uses hardware features of a parallel processor to checkpoint a context associated with an execution of a software application on the parallel processor. The software program uses a preemption feature of the parallel processor to cause the parallel processor to stop executing instructions in accordance with the context. The software program then causes the parallel processor to collect state data associated with the context. After generating a checkpoint based on the state data, the software program causes the parallel processor to resume executing instructions in accordance with the context.
Because of our present inability to produce error-free software, software fault tolerance is and will continue to be an important consideration in software systems. The root cause of software design errors is the complexity of the systems. Compounding the problems in building correct software is the difficulty in assessing the correctness of software for highly complex systems. After a brief overview of the software development processes, we note how hard-to-detect design faults are likely to be introduced during development and how software faults tend to be state-dependent and activated by particular input sequences. Although component reliability is an important quality measure for system level analysis, software reliability is hard to characterize and the use of post-verification reliability estimates remains a controversial issue. For some applications software safety is more important than reliability, and fault tolerance techniques used in those applications are aimed at preventing catastrophes. Single version software fault tolerance techniques discussed include system structuring and closure, atomic actions, inline fault detection, exception handling, and others. Multiversion techniques are based on the assumption that software built differently should fail differently and thus, if one of the redundant versions fails, it is expected that at least one of the other versions will provide an acceptable output. Recovery blocks, N-version programming, and other multiversion techniques are reviewed.
Software safety assurance philosophy and practices at the NASA Ames are discussed. It is shown that, to be safe, software must be error-free. Software developments on two digital flight control systems and two ground facility systems are examined, including the overall system and software organization and function, the software-safety issues, and their resolution. The effectiveness of safety assurance methods is discussed, including conventional life-cycle practices, verification and validation testing, software safety analysis, and formal design methods. It is concluded (1) that a practical software safety technology does not yet exist, (2) that it is unlikely that a set of general-purpose analytical techniques can be developed for proving that software is safe, and (3) that successful software safety-assurance practices will have to take into account the detailed design processes employed and show that the software will execute correctly under all possible conditions.
In part I of this paper, the United States (US) radiosonde temperature data are shown to have significant and unexplained inhomogeneities in the mid-troposphere. This part discusses the differences between observations taken at 0 and 12 UTC especially in the stratosphere by the Vaisala RS80 radiosondes that are integrated within the National Weather Service's (NWS) Micro-ART system. The results show that there is a large maxima in the horizontal distribution of the monthly means of the 0/12 UTC differences over the central US that is absent over Canada and this maxima is as large as 5 C at 10 hPa. The vertical profiles of the root-mean-square of the monthly means are much larger in the US than those else where. The data clearly shows that the 0/12 UTC differences are largely artificial especially over the central US and originate in the post processing software at observing stations, thus confirming the findings in part I. Special flight data from the NWS's test facility at Sterling, Va. have been obtained. This data can be used to deduce the bias correction applied by Vaisala's post processing system. By analyzing the correction data, it can be shown that the inconsistencies with non-US Vaisala RS80 data as well as most of the large 0/12 UTC differences over the US can be accounted for by multiplying the reported elapsed time (i.e. time since launch) by the factor which is incorrectly applied by the post processing software. After being presented with the findings in this paper, Vaisala further isolated the source of the inconsistencies to a software coding error in the radiation bias correction scheme. The error effects only the software installed at US stations.