SEARCH · Search NASA

Results for “graphical processing units”

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 181 records · Page 10

All sources NASA NTRS DOE OSTI

NASA NTRS1989

Computational fluid dynamics analysis of space shuttle main propulsion feed line 17-inch disconnect valves

A steady incompressible three-dimensional (3-D) viscous flow analysis was conducted for the Space Shuttle Main Propulsion External Tank (ET)/Orbiter (ORB) propellant feed line quick separable 17-inch disconnect flapper valves for liquid oxygen (LO2) and liquid hydrogen (LH2). The main objectives of the analysis were to predict and correlate the hydrodynamic stability of the flappers and pressure drop with available water test data. Computational Fluid Dynamics (CFD) computer codes were procured at no cost from the public domain, and were modified and extended to carry out the disconnect flow analysis. The grid generator codes SVTGD3D and INGRID were obtained. NASA Ames Research Center supplied the flow solution code INS3D, and the color graphics code PLOT3D. A driver routine was developed to automate the grid generation process. Components such as pipes, elbows, and flappers can be generated with simple commands, and flapper angles can be varied easily. The flow solver INS3D code was modified to treat interior flappers, and other interfacing routines were developed, which include a turbulence model, a force/moment routine, a time-step routine, and initial and boundary conditions. In particular, an under-relaxation scheme was implemented to enhance the solution stability. Major physical assumptions and simplifications made in the analysis include the neglect of linkages, slightly reduced flapper diameter, and smooth solid surfaces. A grid size of 54 x 21 x 25 was employed for both the LO2 and LH2 units. Mixing length theory applied to turbulent shear flow in pipes formed the basis for the simple turbulence model. Results of the analysis are presented for LO2 and LH2 disconnects.

Kandula, Max↗

NASA NTRS2010

Kepler Science Operations Center Pipeline Framework

The Kepler mission is designed to continuously monitor up to 170,000 stars at a 30 minute cadence for 3.5 years searching for Earth-size planets. The data are processed at the Science Operations Center (SOC) at NASA Ames Research Center. Because of the large volume of data and the memory and CPU-intensive nature of the analysis, significant computing hardware is required. We have developed generic pipeline framework software that is used to distribute and synchronize the processing across a cluster of CPUs and to manage the resulting products. The framework is written in Java and is therefore platform-independent, and scales from a single, standalone workstation (for development and research on small data sets) to a full cluster of homogeneous or heterogeneous hardware with minimal configuration changes. A plug-in architecture provides customized control of the unit of work without the need to modify the framework itself. Distributed transaction services provide for atomic storage of pipeline products for a unit of work across a relational database and the custom Kepler DB. Generic parameter management and data accountability services are provided to record the parameter values, software versions, and other meta-data used for each pipeline execution. A graphical console allows for the configuration, execution, and monitoring of pipelines. An alert and metrics subsystem is used to monitor the health and performance of the pipeline. The framework was developed for the Kepler project based on Kepler requirements, but the framework itself is generic and could be used for a variety of applications where these features are needed.

Klaus, Todd C.↗

NASA NTRS2014

Clearance Analysis of CTC2 (on ELC4) to S-TRRJ HRS Radiator Rotation Envelope

In response to the planned retirement of the Space Shuttle Program, International Space Station (ISS) management began stockpiling spare parts on the ISS. Many of the larger orbital replacement units were stored on the Expedite the Processing of Experiments to Space Station (EXPRESS) Logistics Carriers (ELCs) mounted on the end of the S3 and P3 truss segments, immediately outboard of the Thermal Radiator Rotary Joints (TRRJs) and their attached radiators. In an August 2009 computer-aided design (CAD) assessment, it was determined that mounting the Cargo Transport Container (CTC) 2 on the inboard face of ELC4 as planned would create insufficient clearance between the CTC2 and the rotational envelope of the radiators when the TRRJs were rotated to a gamma angle of 35.0 degrees. The true clearance would depend on how the Unpressurized Cargo Carrier Attachment System (UCCAS) was mounted to the S3 truss and how the ELC4 was attached to it. If the plane of the UCCAS attachment points were tilted even slightly inboard, it would significantly change the clearance between CTC2 and the Starboard TRRJ (S-TRRJ) radiators. Additionally, since CTC2 would be covered in multilayer insulation (MLI), the true outer profile of CTC2 was not captured in the CAD models used for the clearance assessment. It was possible that, even if the S-TRRJ radiators cleared CTC2, they could snag the MLI covering. In the fall of 2010, the Image Science and Analysis Group (ISAG) was asked to perform an on-orbit clearance analysis to determine the location of CTC2 on ELC4 and the S-TRRJ radiators at the angle of closest approach so that a positive clearance could be assured. To provide the measurements as quickly as possible to aid in the assessment, it was decided that the clearance analysis would be broken into two phases. Phase I: The location and orientation of the UCCAS fittings, which support and hold the ELC4 in place, would be measured relative to the ISS Analytical Coordinate System (ISSACS) as defined by nine preexisting Space Vision System (SVS) targets affixed to the forward/zenith side of the S1 and S3 truss segments. The location of the outboard edge of the S-TRRJ radiator would also be measured when positioned at the angle of closest approach to CTC2 (gamma = 35.0 degrees). This data would allow the Digital Pre-Assembly Group to predict how the ELC4 would sit on the UCCAS and how that would translate into the clearance between CTC2 and the S-TRRJ radiators. Phase II: After the ELC4 was delivered and installed into the UCCAS, the position of the CTC2 mounting plate on the inboard face of ELC4, would be measured in the ISSACS coordinate system relative to the SVS control points used in Phase I. Although CTC2 would not yet be mounted on ELC4, the working envelope of CTC2 could be mathematically added to the measured position of ELC4 to produce a best estimate for CTC2's mounted location. Comparing CTC2's best estimated location to the S-TRRJ radiator (measured in Phase I); relative to the ISSACS coordinate system, would provide a direct measurement of the expected clearance. Due to the impending delivery of ELC4 (scheduled for January 2011), planning for the Phase I clearance analysis began immediately. Using the Dynamic Onboard Ubiquitous Graphics (DOUG) program, ISAG designed a way to acquire images of the SVS control points on truss segments S1 and S3, the aft facing edge of the S-TRRJ Heat Rejection Subsystem (HRS) radiator, and the three UCCAS latch mechanisms mounted on the zenith face of the S3 truss using the Space Station Remote Manipulator System (SSRMS). To minimize the number of SSRMS movements, the Special Purpose Dexterous Manipulator (SPDM) would be attached to the SSRMS. This would make it possible to park the SPDM in one position and acquire multiple images by changing the viewing orientation of the SPDM body cameras using the pan/tilt units on which they are mounted. Using this implementation concept, ISAG identified four SSRMS/SPDM positions from which the majority of the needed imagery could be acquired. Five additional images would be acquired using the CP-3 external ISS camera mounted on the S1 truss immediately inboard of ELC4. Based on a photogrammetric simulation, it was estimated that the measured location of the HRS radiator and UCCAS latch points would be accurate to about 0.3 in. in each of the three axes relative to ISSACS. Working with ROBO, ISAG collected 78 images of the ISS December 29, 2010. From this imagery, the best 40 were selected for use in the analysis process. The images were radiometrically enhanced to improve color and contrast and loaded into the FotoG analysis software along with the camera parameters and control data, which consisted of the coordinates for the nine SVS targets on the S1 and S3 trusses in the ISSACS coordinate system.

Liddle, Donn↗

NASA NTRS1987

A distributed data acquisition system for aeronautics test facilities

The NASA Lewis Research Center is in the process of installing a new data acquisition and display system. This new system will provide small and medium sized aeronautics test facilities with a state-of-the-art real-time data acquisition and display system. The new data system will provide for the acquisition of signals from a variety of instrumentation sources. They include analog measurements of temperatures, pressures, and other steady state voltage inputs; frequency inputs to measure speed and flow; discrete I/O for significant events, and modular instrument systems such as multiplexed pressure modules or electronic instrumentation with a IEEE 488 interface. The data system is designed to acquire data, convert it to engineering units, compute test dependent performance calculations, limit check selected channels or calculations, and display the information in alphanumeric or graphical form with a cycle time of one second for the alphanumeric data. This paper describes the system configuration, its salient features, and the expected impact on testing.

Fronek, Dennis L.↗

NASA NTRS1987

A distributed data acquisition system for aeronautics test facilities

Fronek, Dennis L.↗

NASA NTRS2008

Software Simulates Sight: Flat Panel Mura Detection

In the increasingly sophisticated world of high-definition flat screen monitors and television screens, image clarity and the elimination of distortion are paramount concerns. As the devices that reproduce images become more and more sophisticated, so do the technologies that verify their accuracy. By simulating the manner in which a human eye perceives and interprets a visual stimulus, NASA scientists have found ways to automatically and accurately test new monitors and displays. The Spatial Standard Observer (SSO) software metric, developed by Dr. Andrew B. Watson at Ames Research Center, measures visibility and defects in screens, displays, and interfaces. In the design of such a software tool, a central challenge is determining which aspects of visual function to include while accuracy and generality are important, relative simplicity of the software module is also a key virtue. Based on data collected in ModelFest, a large cooperative multi-lab project hosted by the Optical Society of America, the SSO simulates a simplified model of human spatial vision, operating on a pair of images that are viewed at a specific viewing distance with pixels having a known relation to luminance. The SSO measures the visibility of foveal spatial patterns, or the discriminability of two patterns, by incorporating only a few essential components of vision. These components include local contrast transformation, a contrast sensitivity function, local masking, and local pooling. By this construction, the SSO provides output in units of "just noticeable differences" (JND) a unit of measure based on the assumed smallest difference of sensory input detectable by a human being. Herein is the truly amazing ability of the SSO, while conventional methods can manipulate images, the SSO models human perception. This set of equations actually defines a mathematical way of working with an image that accurately reflects the way in which the human eye and mind behold a stimulus. The SSO is intended for a wide variety of applications, such as evaluating vision from unmanned aerial vehicles, measuring visibility of damage to aircraft and to the space shuttles, predicting outcomes of corrective laser eye surgery, inspecting displays during the manufacturing process, estimating the quality of compressed digital video, evaluating legibility of text, and predicting discriminability of icons or symbols in a graphical user interface.

Source record↗

NASA NTRS2011

Telemetry and Science Data Software System

The Telemetry and Science Data Software System (TSDSS) was designed to validate the operational health of a spacecraft, ease test verification, assist in debugging system anomalies, and provide trending data and advanced science analysis. In doing so, the system parses, processes, and organizes raw data from the Aquarius instrument both on the ground and while in space. In addition, it provides a user-friendly telemetry viewer, and an instant pushbutton test report generator. Existing ground data systems can parse and provide simple data processing, but have limitations in advanced science analysis and instant report generation. The TSDSS functions as an offline data analysis system during I&T (integration and test) and mission operations phases. After raw data are downloaded from an instrument, TSDSS ingests the data files, parses, converts telemetry to engineering units, and applies advanced algorithms to produce science level 0, 1, and 2 data products. Meanwhile, it automatically schedules upload of the raw data to a remote server and archives all intermediate and final values in a MySQL database in time order. All data saved in the system can be straightforwardly retrieved, exported, and migrated. Using TSDSS s interactive data visualization tool, a user can conveniently choose any combination and mathematical computation of interesting telemetry points from a large range of time periods (life cycle of mission ground data and mission operations testing), and display a graphical and statistical view of the data. With this graphical user interface (GUI), the data queried graphs can be exported and saved in multiple formats. This GUI is especially useful in trending data analysis, debugging anomalies, and advanced data analysis. At the request of the user, mission-specific instrument performance assessment reports can be generated with a simple click of a button on the GUI. From instrument level to observatory level, the TSDSS has been operating supporting functional and performance tests and refining system calibration algorithms and coefficients, in sync with the Aquarius/SAC-D spacecraft. At the time of this reporting, it was prepared and set up to perform anomaly investigation for mission operations preceding the Aquarius/SAC-D spacecraft launch on June 10, 2011.

Bates, Lakesha↗

NASA NTRS2011

Visual Object Recognition and Tracking of Tools

A method has been created to automatically build an algorithm off-line, using computer-aided design (CAD) models, and to apply this at runtime. The object type is discriminated, and the position and orientation are identified. This system can work with a single image and can provide improved performance using multiple images provided from videos. The spatial processing unit uses three stages: (1) segmentation; (2) initial type, pose, and geometry (ITPG) estimation; and (3) refined type, pose, and geometry (RTPG) calculation. The image segmentation module files all the tools in an image and isolates them from the background. For this, the system uses edge-detection and thresholding to find the pixels that are part of a tool. After the pixels are identified, nearby pixels are grouped into blobs. These blobs represent the potential tools in the image and are the product of the segmentation algorithm. The second module uses matched filtering (or template matching). This approach is used for condensing synthetic images using an image subspace that captures key information. Three degrees of orientation, three degrees of position, and any number of degrees of freedom in geometry change are included. To do this, a template-matching framework is applied. This framework uses an off-line system for calculating template images, measurement images, and the measurements of the template images. These results are used online to match segmented tools against the templates. The final module is the RTPG processor. Its role is to find the exact states of the tools given initial conditions provided by the ITPG module. The requirement that the initial conditions exist allows this module to make use of a local search (whereas the ITPG module had global scope). To perform the local search, 3D model matching is used, where a synthetic image of the object is created and compared to the sensed data. The availability of low-cost PC graphics hardware allows rapid creation of synthetic images. In this approach, a function of orientation, distance, and articulation is defined as a metric on the difference between the captured image and a synthetic image with an object in the given orientation, distance, and articulation. The synthetic image is created using a model that is looked up in an object-model database. A composable software architecture is used for implementation. Video is first preprocessed to remove sensor anomalies (like dead pixels), and then is processed sequentially by a prioritized list of tracker-identifiers.

English, James↗

NASA NTRS2014

Remote Software Application and Display Development

The era of the shuttle program has come to an end, but only to give rise to newer and more exciting projects. Now is the time of the Orion spacecraft, a work of art designed to exceed all previous endeavors of man. NASA is exiting the time of exploration and is entering a new period, a period of pioneering. With this new mission, many of NASAs organizations must undergo a great deal of change and development to support the Orion missions. The Spaceport Command and Control System (SCCS) is the new system that will provide NASA the ability to launch rockets into orbit and thus control Orion and other spacecraft as the goal of populating Mars becomes ever increasingly tangible. Since the previous control system, Launch Processing System (LPS), was primarily designed to launch the shuttles, SCCS was needed as Kennedy Space Center (KSC) reorganized to a multiuser spaceport for commercial flights, providing a more versatile control over rockets. Within SCCS, is the Launch Control System (LCS), which is the remote software behind the command and monitoring of flight and ground system hardware. This internship at KSC has involved two main components in LCS, including Remote Software Application and Display development. The display environment provides a graphical user interface for an operator to view and see if any cautions are raised, while the remote applications are the backbone that communicate with hardware, and then relay the data back to the displays. These elements go hand in hand as they provide monitoring and control over hardware and software alike from the safety of the Launch Control Center. The remote software applications are written in Application Control Language (ACL), which must undergo unit testing to ensure data integrity. This paper describes both the implementation and writing of unit tests in ACL code for remote software applications, as well as the building of remote displays to be used in the Launch Control Center (LCC).

ACL↗

NASA NTRS2004

Subsonic Aircraft With Regression and Neural-Network Approximators Designed

At the NASA Glenn Research Center, NASA Langley Research Center's Flight Optimization System (FLOPS) and the design optimization testbed COMETBOARDS with regression and neural-network-analysis approximators have been coupled to obtain a preliminary aircraft design methodology. For a subsonic aircraft, the optimal design, that is the airframe-engine combination, is obtained by the simulation. The aircraft is powered by two high-bypass-ratio engines with a nominal thrust of about 35,000 lbf. It is to carry 150 passengers at a cruise speed of Mach 0.8 over a range of 3000 n mi and to operate on a 6000-ft runway. The aircraft design utilized a neural network and a regression-approximations-based analysis tool, along with a multioptimizer cascade algorithm that uses sequential linear programming, sequential quadratic programming, the method of feasible directions, and then sequential quadratic programming again. Optimal aircraft weight versus the number of design iterations is shown. The central processing unit (CPU) time to solution is given. It is shown that the regression-method-based analyzer exhibited a smoother convergence pattern than the FLOPS code. The optimum weight obtained by the approximation technique and the FLOPS code differed by 1.3 percent. Prediction by the approximation technique exhibited no error for the aircraft wing area and turbine entry temperature, whereas it was within 2 percent for most other parameters. Cascade strategy was required by FLOPS as well as the approximators. The regression method had a tendency to hug the data points, whereas the neural network exhibited a propensity to follow a mean path. The performance of the neural network and regression methods was considered adequate. It was at about the same level for small, standard, and large models with redundancy ratios (defined as the number of input-output pairs to the number of unknown coefficients) of 14, 28, and 57, respectively. In an SGI octane workstation (Silicon Graphics, Inc., Mountainview, CA), the regression training required a fraction of a CPU second, whereas neural network training was between 1 and 9 min, as given. For a single analysis cycle, the 3-sec CPU time required by the FLOPS code was reduced to milliseconds by the approximators. For design calculations, the time with the FLOPS code was 34 min. It was reduced to 2 sec with the regression method and to 4 min by the neural network technique. The performance of the regression and neural network methods was found to be satisfactory for the analysis and design optimization of the subsonic aircraft.

Patnaik, Surya N.↗

NASA NTRS2006

An Operational Configuration of the ARPS Data Analysis System to Initialize WRF in the NM'S Environmental Modeling System

The Weather Research and Forecasting (WRF) model is the next generation community mesoscale model designed to enhance collaboration between the research and operational sectors. The NM'S as a whole has begun a transition toward WRF as the mesoscale model of choice to use as a tool in making local forecasts. Currently, both the National Weather Service in Melbourne, FL (NWS MLB) and the Spaceflight Meteorology Group (SMG) are running the Advanced Regional Prediction System (AIRPS) Data Analysis System (ADAS) every 15 minutes over the Florida peninsula to produce high-resolution diagnostics supporting their daily operations. In addition, the NWS MLB and SMG have used ADAS to provide initial conditions for short-range forecasts from the ARPS numerical weather prediction (NWP) model. Both NM'S MLB and SMG have derived great benefit from the maturity of ADAS, and would like to use ADAS for providing initial conditions to WRF. In order to assist in this WRF transition effort, the Applied Meteorology Unit (AMU) was tasked to configure and implement an operational version of WRF that uses output from ADAS for the model initial conditions. Both agencies asked the AMU to develop a framework that allows the ADAS initial conditions to be incorporated into the WRF Environmental Modeling System (EMS) software. Developed by the NM'S Science Operations Officer (S00) Science and Training Resource Center (STRC), the EMS is a complete, full physics, NWP package that incorporates dynamical cores from both the National Center for Atmospheric Research's Advanced Research WRF (ARW) and the National Centers for Environmental Prediction's Non-Hydrostatic Mesoscale Model (NMM) into a single end-to-end forecasting system. The EMS performs nearly all pre- and postprocessing and can be run automatically to obtain external grid data for WRF boundary conditions, run the model, and convert the data into a format that can be readily viewed within the Advanced Weather Interactive Processing System. The EMS has also incorporated the WRF Standard Initialization (SI) graphical user interface (GUT), which allows the user to set up the domain, dynamical core, resolution, etc., with ease. In addition to the SI GUT, the EMS contains a number of configuration files with extensive documentation to help the user select the appropriate input parameters for model physics schemes, integration timesteps, etc. Therefore, because of its streamlined capability, it is quite advantageous to configure ADAS to provide initial condition data to the EMS software. One of the biggest potential benefits of configuring ADAS for ingest into the EMS is that the analyses could be used to initialize either the ARW or NMM. Currently, the ARPS/ADAS software has a conversion routine only for the ARW dynamical core. However, since the NIvIM runs about 2.5 times faster than the ARW, it is quite advantageous to be able to run an ADAS/NMM configuration operationally due to the increased efficiency.

Case, Jonathan↗

NASA NTRS2017

Future ATM Concepts Evaluation Tool (FACET) Interface Control Document

This Interface Control Document (ICD) documents the airspace adaptation and air traffic inputs of NASA's Future ATM Concepts and Evaluation Tool (FACET). Its intended audience is the project manager, project team, development team, and stakeholders interested in interfacing with the system. FACET equips Air Traffic Management (ATM) researchers and service providers with a way to explore, develop and evaluate advanced air transportation concepts before they are field-tested and eventually deployed. FACET is a flexible software tool that is capable of quickly generating and analyzing thousands of aircraft trajectories. It provides researchers with a simulation environment for preliminary testing of advanced ATM concepts. Using aircraft performance profiles, airspace models, weather data, and flight schedules, the tool models trajectories for the climb, cruise, and descent phases of flight for each type of aircraft. An advanced graphical interface displays traffic patterns in two and three dimensions, under various current and projected conditions for specific airspace regions or over the entire continental United States. The system is able to simulate a full day's dynamic national airspace system (NAS) operations, model system uncertainty, measure the impact of different decision-makers in the NAS, and provide analysis of the results in graphical form, including sector, airport, fix, and airway usage statistics. NASA researchers test and analyze the system-wide impact of new traffic flow management algorithms under anticipated air traffic growth projections on the nation's air traffic system. In addition to modeling the airspace system for NASA research, FACET has also successfully transitioned into a valuable tool for operational use. Federal Aviation Administration (FAA) traffic flow managers and commercial airline dispatchers have used FACET technology for real-time operations planning. FACET integrates live air traffic data from FAA radar systems and weather data from the National Weather Service to summarize NAS performance. This information allows system operators to reroute flights around congested airspace and severe weather to maintain safety and minimize delay. FACET also supports the planning and post-operational evaluation of reroute strategies at the national level to maximize system efficiency. For the commercial airline passenger, strategic planning with FACET can result in fewer flight delays and cancellations. The performance capabilities of FACET are largely due to its architecture, which strikes a balance between flexibility and fidelity. FACET is capable of modeling the airspace operations for the continental United States, processing thousands of aircraft on a single computer. FACET was written in Java and C, enabling the portability of its software to a variety of operating systems. In addition, FACET was designed with a modular software architecture to facilitate rapid prototyping of diverse ATM concepts. Several advanced ATM concepts have already been implemented in FACET, including aircraft self-separation, prediction of aircraft demand and sector congestion, system-wide impact assessment of traffic flow management constraints, and wind-optimal routing.

FACET↗

NASA NTRS2017

Operating Small Sat Swarms as a Single Entity: Introducing SODA

Swarm concepts are a growing topic of interest in the small satellite community. Compared to a small satellite constellation, a swarm has the distinction of being multiple spacecraft in close proximity, in approximately the same orbit. Furthermore, we envision swarms to have capabilities for cross-link communication and station-keeping. Of particular interest is a means to maintain operator-specified geometry, alignment, and/or separation.From NASA's decadal survey, it is clear that simultaneous measurements from a 3D volume of space are desired for a variety of Earth scientific studies. As this mission concept is ultimately extended to deep space, some degree of local control for the swarm to self-correct its configuration is required. We claim that the practicality of ground commanding each individual satellite in the swarm is simply not a feasible concept of operations. In other words, the current state-of-practice does not scale to very large swarms (e.g. 100 spacecraft or more) without becoming cost prohibitive. To contain the operations costs and complexity, a new approach is required: the swarm must be operated as a unit, responding to high-level specifications for relative position and velocity.The Mission Design Division at NASA Ames Research Center is looking to the near future for opportunities to develop satellite swarm technology. As part of this effort, we are developing SODA (Swarm Orbital Dynamics Advisor), a tool that provides the orbital maneuvers required to achieve a desired type of relative swarm motion. The purpose of SODA is two-fold. First, it encompasses the algorithms and orbital dynamics model to enable the desired relative motion of the swarm satellites. The process starts with the user specifying the properties of a swarm configuration. This could be as simple as varying in-track spacing of the swarm in one orbit, or as complex as maintaining a specified 3D geometrical orientation. We presume that science objectives will drive this choice. Given these inputs, the tool provides the most efficient maneuver(s) to achieve the objective.Second, SODA provides a variety of visualization tools. We acknowledge that the relationship between a desired relative motion amongst the swarm, and the corresponding orbital parameters for each individual satellite may not be immediately apparent for ground controllers and mission planners. The purpose of SODA's visualization tools is to illustrate this concept clearly with a variety of graphics and animations. After computing the optimal orbital maneuvers to modify the swarm, these results are simulated to demonstrate successful swarm control.Our emphasis in this paper is on the importance of relating the desired motion of the swarm satellites relative to one another with the required orbital element changes. One cannot joystick a drifting swarm satellite back into position; the underlying orbital mechanics dictate the most efficient recovery maneuvers. To illustrate this point, results from several case study simulations are presented. We conclude with our forward work for ongoing SODA development and potential science applications.

small satellites↗

NASA NTRS2005

Multistage Magnetic Separator of Cells and Proteins

The multistage electromagnetic separator for purifying cells and magnetic particles (MAGSEP) is a laboratory apparatus for separating and/or purifying particles (especially biological cells) on the basis of their magnetic susceptibility and magnetophoretic mobility. Whereas a typical prior apparatus based on similar principles offers only a single stage of separation, the MAGSEP, as its full name indicates, offers multiple stages of separation; this makes it possible to refine a sample population of particles to a higher level of purity or to categorize multiple portions of the sample on the basis of magnetic susceptibility and/or magnetophoretic mobility. The MAGSEP includes a processing unit and an electronic unit coupled to a personal computer. The processing unit includes upper and lower plates, a plate-rotation system, an electromagnet, an electromagnet-translation system, and a capture-magnet assembly. The plates are bolted together through a roller bearing that allows the plates to rotate with respect to each other. An interface between the plates acts as a seal for separating fluids. A lower cuvette can be aligned with as many as 15 upper cuvette stations for fraction collection during processing. A two-phase stepping motor drives the rotation system, causing the upper plate to rotate for the collection of each fraction of the sample material. The electromagnet generates a magnetic field across the lower cuvette, while the translation system translates the electromagnet upward along the lower cuvette. The current supplied to the electromagnet, and thus the magnetic flux density at the pole face of the electromagnet, can be set at a programmed value between 0 and 1,400 gauss (0.14 T). The rate of translation can be programmed between 5 and 2,000 m/s so as to align all sample particles in the same position in the cuvette. The capture magnet can be a permanent magnet. It is mounted on an arm connected to a stepping motor. The stepping motor rotates the arm to position the capture magnet above the upper cuvette into which a fraction of the sample is collected. The electronic unit includes a power switch, power-supply circuitry that accepts 110-Vac input power, an RS-232 interface, and status lights. The personal computer runs the MAGSEP software and controls the operation of the MAGSEP through the RS-232 interface. The status of the power, the translating electromagnet, the capture magnet, and the rotation of the upper plate are indicated in a graphical user interface on the computer screen.

Barton, Ken↗

NASA NTRS2004

Multi-level Simulation of a Real Time Vibration Monitoring System Component

This paper describes the development of a custom built Digital Signal Processing (DSP) printed circuit board designed to implement the Advanced Real Time Vibration Monitoring Subsystem proposed by MSFC Transportation Directorate in 2000 for the Space Shuttle Main Engine Advanced Health Management System (AHMS). This Real Time Vibration Monitoring System (RTVMS) is being developed for ground use as part of the AHMS Health Management Computer-Integrated Rack Assembly (HMC-IRA). The HMC-IRA RTVMS design contains five DSPs which are highly interconnected through individual communication ports, shared memory, and a unique communication router that allows all the DSPs to receive digitized data from two multi-channel analog boards simultaneously. This paper will briefly cover the overall board design but will focus primarily on the state-of-the-art simulation environment within which this board was developed. This 16-layer board with over 1800 components and an additional mezzanine card has been an extremely challenging design. Utilization of a Mentor Graphics simulation environment provided the unique board and system level simulation capability to ascertain any timing or functional concerns before production. By combining VHDL, Synopsys Software and Hardware Models, and the Mentor Design Capture Environment, multiple simulations were developed to verify the RTVMS design. This multi-level simulation allowed the designers to achieve complete operability without error the first time the RTVMS printed circuit board was powered. The HMCIRA design has completed all engineering unit testing and the deliverable unit is currently under development.

Roberston, Bryan↗

NASA NTRS2005

Multi-level Simulation of a Real Time Vibration Monitoring System Component

This paper describes the development of a custom built Digital Signal Processing (DSP) printed circuit board designed to implement the Advanced Real Time Vibration Monitoring Subsystem proposed by Marshall Space Flight Center (MSFC) Transportation Directorate in 2000 for the Space Shuttle Main Engine Advanced Health Management System (AHMS). This Real Time Vibration Monitoring System (RTVMS) is being developed for ground use as part of the AHMS Health Management Computer-Integrated Rack Assembly (HMC-IRA). The HMC-IRA RTVMS design contains five DSPs which are highly interconnected through individual communication ports, shared memory, and a unique communication router that allows all the DSPs to receive digitized data fiom two multi-channel analog boards simultaneously. This paper will briefly cover the overall board design but will focus primarily on the state-of-the-art simulation environment within which this board was developed. This 16-layer board with over 1800 components and an additional mezzanine card has been an extremely challenging design. Utilization of a Mentor Graphics simulation environment provided the unique board and system level simulation capability to ascertain any timing or functional concerns before production. By combining VHDL, Synopsys Software and Hardware Models, and the Mentor Design Capture Environment, multiple simulations were developed to verify the RTVMS design. This multi-level simulation allowed the designers to achieve complete operability without error the first time the RTVMS printed circuit board was powered. The HMC-IRA design has completed all engineering and deliverable unit testing. P

Robertson, Bryan A.↗

NASA NTRS1996

GRASP/Ada 95: Reverse Engineering Tools for Ada

The GRASP/Ada project (Graphical Representations of Algorithms, Structures, and Processes for Ada) has successfully created and prototyped an algorithmic level graphical representation for Ada software, the Control Structure Diagram (CSD), and a new visualization for a fine-grained complexity metric called the Complexity Profile Graph (CPG). By synchronizing the CSD and the CPG, the CSD view of control structure, nesting, and source code is directly linked to the corresponding visualization of statement level complexity in the CPG. GRASP has been integrated with GNAT, the GNU Ada 95 Translator to provide a comprehensive graphical user interface and development environment for Ada 95. The user may view, edit, print, and compile source code as a CSD with no discernible addition to storage or computational overhead. The primary impetus for creation of the CSD was to improve the comprehension efficiency of Ada software and, as a result, improve reliability and reduce costs. The emphasis has been on the automatic generation of the CSD from Ada 95 source code to support reverse engineering and maintenance. The CSD has the potential to replace traditional prettyprinted Ada source code. The current update has focused on the design and implementation of a new Motif compliant user interface, and a new CSD generator consisting of a tagger and renderer. The Complexity Profile Graph (CPG) is based on a set of functions that describes the context, content, and the scaling for complexity on a statement by statement basis. When combined graphicafly, the result is a composite profile of complexity for the program unit. Ongoing research includes the development and refinement of the associated functions, and the development of the CPG generator prototype. The current Version 5.0 prototype provides the capability for the user to generate CSDs and CPGs from Ada 95 source code in a reverse engineering as well as forward engineering mode with a level of flexibility suitable for practical application. This report provides an overview of the GRASP/Ada project with an emphasis on the current update.

Cross, James H., II↗

NASA NTRS2013

Plant Habitat Telemetry / Command Interface and E-MIST

Plant Habitat (PH) is an experiment to be taken to the International Space Station (ISS) in 2016. It is critical that ground support computers have the ability to uplink commands to control PH, and that ISS computers have the ability to downlink PH telemetry data to ground support. This necessitates communication software that can send, receive, and process, PH specific commands and telemetry. The objective of the Plant Habitat Telemetry/ Command Interface is to provide this communication software, and to couple it with an intuitive Graphical User Interface (GUI). Initial investigation of the project objective led to the decision that code be written in C++ because of its compatibility with existing source code infrastructures and robustness. Further investigation led to a determination that multiple Ethernet packet structures would need to be created to effectively transmit data. Setting a standard for packet structures would allow us to distinguish these packets that would range from command type packets to sub categories of telemetry packets. In order to handle this range of packet types, the conclusion was made to take an object-oriented programming approach which complemented our decision to use the C++ programming language. In addition, extensive utilization of port programming concepts was required to implement the core functionality of the communication software. Also, a concrete understanding of a packet processing software was required in order to put aU the components of ISS-to-Ground Support Equipment (GSE) communication together and complete the objective. A second project discussed in this paper is Exposing Microbes to the Stratosphere (EMIST). This project exposes microbes into the stratosphere to observe how they are impacted by atmospheric effects. This paper focuses on the electrical and software expectations of the project, specifically drafting the printed circuit board, and programming the on-board sensors. The Eagle Computer-Aided Drafting (CAD) software was used to draft the E-MIST circuit. This required several component libraries to be created. Coding the sensors and obtaining sensor data involved using the Arduino Uno developmental board and coding language, and properly wiring peripheral sensors to the microcontroller (the central control unit of the experiment).

Walker, Uriae M.↗