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.
The goal of this work is to achieve fail-operational and graceful-degradation behavior in realistic flight mission scenarios, of multicore processors such as Mars Entry-Descent-Landing (EDL) and Primitive Body proximity operations.
The current trend of multi-core and multi-processor computing is causing a paradigm shift from inherently sequential to highly concurrent and parallel applications. Certain thread interleavings, data input values, or combinations of both often cause errors in the system. Systematic verification techniques such as explicit state model checking and symbolic execution are extensively used to detect errors in such systems [7, 9]. Explicit state model checking enumerates possible thread schedules and input data values of a program in order to check for errors [3, 9]. To partially mitigate the state space explosion from data input values, symbolic execution techniques substitute data input values with symbolic values [5, 7, 6]. Explicit state model checking and symbolic execution techniques used in conjunction with exhaustive search techniques such as depth-first search are unable to detect errors in medium to large-sized concurrent programs because the number of behaviors caused by data and thread non-determinism is extremely large. We present an overview of abstraction-guided symbolic execution for concurrent programs that detects errors manifested by a combination of thread schedules and data values [8]. The technique generates a set of key program locations relevant in testing the reachability of the target locations. The symbolic execution is then guided along these locations in an attempt to generate a feasible execution path to the error state. This allows the execution to focus in parts of the behavior space more likely to contain an error.
The SpaceCubeX project is motivated by the need for high performance, modular, and scalable on-board processing to help scientists answer critical 21st century questions about global climate change, air quality, ocean health, and ecosystem dynamics, while adding new capabilities such as low-latency data products for extreme event warnings. These goals translate into on-board processing throughput requirements that are on the order of 100-1,000 more than those of previous Earth Science missions for standard processing, compression, storage, and downlink operations. To study possible future architectures to achieve these performance requirements, the SpaceCubeX project provides an evolvable testbed and framework that enables a focused design space exploration of candidate hybrid CPU/FPGA/DSP processing architectures. The framework includes ArchGen, an architecture generator tool populated with candidate architecture components, performance models, and IP cores, that allows an end user to specify the type, number, and connectivity of a hybrid architecture. The framework requires minimal extensions to integrate new processors, such as the anticipated High Performance Spaceflight Computer (HPSC), reducing time to initiate benchmarking by months. To evaluate the framework, we leverage a wide suite of high performance embedded computing benchmarks and Earth science scenarios to ensure robust architecture characterization. We report on our projects Year 1 efforts and demonstrate the capabilities across four simulation testbed models, a baseline SpaceCube 2.0 system, a dual ARM A9 processor system, a hybrid quad ARM A53 and FPGA system, and a hybrid quad ARM A53 and DSP system.
Background Oriented Schlieren (BOS) is a widely used technique that provides density gradient information in flow fields of interest, without imposing stringent optical quality requirements on the facility/experiment windows and/or optics used in the BOS setup. Typically, the BOS reference image is acquired before the test begins (flow off) and then the "live" image data are acquired during the actual testing/experiment (flow on). The raw BOS image data, while displayed in real-time as they are acquired from the camera, unfortunately provide little if any visual indication of the density gradients in the flow. Generally, the "live" images must be processed off-line after the testing is completed, providing no indication of the success of the BOS setup and no feedback on the operational success of the test. Advances in computer processing hardware enables the implementation of real-time processing and display of the BOS image data. Two different approaches to implementing the real-time BOS (RT-BOS) processing capability are described herein. First, a traditional multi-core Central Processing Unit (CPU) based approach using scheduled parallel threads is used to build a RT-BOS processing engine. In the second approach, a Graphical Processing Unit (GPU) approach is used to costruct a RT-BOS processing engine. Generally, high core count CPU processors can provide a useful processing rate for RT-BOS. However, the GPU based approach exceeds the processing capability of the CPU approach, at a fraction of the cost. The GPU approach places no restrictions on the Host PC processing capability, except that it be capable of acquiring the BOS image data from the camera in real-time.