Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “software triggering”

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.

108 records · Page 6
All sourcesNASA NTRSDOE OSTI
NASA NTRS2003

Investigation of Critical Heat Flux in Reduced Gravity Using Photomicrographic Techniques

Experiments were performed to examine the effects of body force on flow boiling critical heat flux (CHF). FC-72 was boiled along one wall of a transparent rectangular flow channel that permitted photographic study of the vapor-liquid interface just prior to CHF. High-speed video imaging techniques were used to identify dominant CHF mechanisms corresponding to different flow orientations and liquid velocities. Six different CHF regimes were identified: Wavy Vapor Layer, Pool Boiling, Stratification, Vapor Counterflow, Vapor Stagnation, and Separated Concurrent Vapor Flow. CHF showed significant sensitivity to orientation for flow velocities below 0.2 m/s, where extremely low CHF values where measured, especially with downward-facing heated wall and downflow orientations. High flow velocities dampened the effects of orientation considerably. The CHF data were used to assess the suitability of previous CHF models and correlations. It is shown the Interfacial Lift-off Model is very effective at predicting CHF for high velocities at all orientations. The flooding limit, on the other hand, is useful at estimating CHF at low velocities and for downflow orientations. A new method consisting of three dimensionless criteria is developed for determining the minimum flow velocity required to overcome body force effects on near-saturated flow boiling CHF. Vertical upflow boiling experiments were performed in pursuit of identifying the trigger mechanism for subcooled flow boiling CHF. While virtually all prior studies on flow boiling CHF concern the prediction or measurement of conditions that lead to CHF, this study was focused on events that take place during the CHF transient. High-speed video imaging and photomicrographic techniques were used to record the transient behavior of interfacial features from the last steady-state power level before CHF until the moment of power cut-off following CHF. The video records show the development of a wavy vapor layer which propagates along the heated wall, permitting cooling prior to CHF only in wetting fronts corresponding to the wave troughs. Image analysis software was developed to estimate void fraction from the individual video images. The void fraction records for subcooled flow boiling show the CHF transient is accompanied by gradual lift-off of wetting fronts culminating in some maximum vapor layer mean thickness, following which the vapor layer begins to thin down as the transition to film boiling ensues. This study proves the Interfacial Lift-off Model, which has been validated for near-saturated flow boiling CHF, is equally valid for subcooled conditions.

Mudawar, Issam↗
NASA NTRS1993

Development of a tool-set for simultaneous, multi-site observations of astronomical objects

A network of ground and space based telescopes can provide continuous observation of astronomical objects. In a 'Target of Opportunity' scenario triggered by the system, any telescope on the network may request supporting observations. We propose to develop a set of data collection and display tools to support these observations. We plan to demonstrate the usefulness of this toolset for simultaneous multi-site observations of astronomical targets. Possible candidates for the proposed demonstration include the Extreme Ultraviolet Explorer, International Ultraviolet Explorer, ALEXIS, and sounding rocket experiments. Ground based observations, operated by the University of California, Berkeley; the Jet Propulsion Laboratory; and Fairborn Observatory, Mesa, Arizona will be used to demonstrate the proposed concept. Although the demonstration will involve astronomical investigations, these tools will be applicable to a large number of scientific disciplines. the software tools and systems developed as a result of our work will be made available to the scientific community.

Chakrabarti, Supriya↗
NASA NTRS1992

Development of a tool-set for simultaneous, multi-site observations of astronomical objects

A network of ground and space based telescopes can provide continuous observation of astronomical objects. In a 'Target of Opportunity' scenario triggered by the system, any telescope on the network may request supporting observations. We propose to develop a set of data collection and display tools to support these observations. We plan to demonstrate the usefulness of this tool set for simultaneous multi-site observations of astronomical targets. Possible candidates for the proposed demonstration include the Extreme Ultraviolet Explorer, International Ultraviolet Explorer, ALEXIS, and sounding rocket experiments. Ground based observations operated by the University of California, Berkeley; the Jet Propulsion Laboratory; and Fairborn Observatory, Mesa, Arizona will be used to demonstrate the proposed concept. Although the demonstration will involve astronomical investigations, these tools will be applicable to a large number of scientific disciplines. The software tools and systems developed as a result of our work will be made available to the scientific community.

Chakrabarti, Supriya↗
NASA NTRS2022

Real-Time Exposure Control and Instrument Operation With the NEID Spectrograph GUI

The NEID spectrograph on the WIYN 3.5-m telescope at Kitt Peak has completed its first full year of science operations and is reliably delivering sub-m/s precision radial velocity measurements. The NEID instrument control system uses the TIMS package (Bender et al. 2016), which is a client-server software system built around the twisted python software stack. During science observations, interaction with the NEID spectrograph is handled through a pair of graphical user interfaces (GUIs), written in PyQT, which wrap the underlying instrument control software and provide straightforward and reliable access to the instrument. Here, we detail the design of these interfaces and present an overview of their use for NEID operations. Observers can use the NEID GUIs to set the exposure time, signal-to-noise ratio (SNR) threshold, and other relevant parameters for observations, configure the calibration bench and observing mode, track or edit observation metadata, and monitor the current state of the instrument. These GUIs facilitate automatic spectrograph configuration and target ingestion from the nightly observing queue, which improves operational efficiency and consistency across epochs. By interfacing with the NEID exposure meter, the GUIs also allow observers to monitor the progress of individual exposures and trigger the shutter on user-defined SNR thresholds. In addition, inset plots of the instantaneous and cumulative exposure meter counts as each observation progresses allow for rapid diagnosis of changing observing conditions as well as guiding failure and other emergent issues.

Arvind F Gupta↗
NASA NTRS2006

Swift-BAT: The First Year of Gamma-Ray Burst Detections

The Burst Alert Telescope (BAT) on the Swift has been detecting gamma-ray bursts (GRBs) since Dec. 17,2004 and automated burst alerts have been distributed since Feb. 14,2005. Since commissioning the BAT has triggered on more than 100 GRBs, nearly all of which have been followed up by the narrow-field instruments on Swift through automatic repointing, and by ground and other satellite telescopes after rapid notification. Within seconds of a trigger the BAT produces and relays to the ground a position good to three arc minutes and a four channel light curve. A full ten minutes of event data follows on subsequent ground station passes. The burst archive has allowed us to determine ensemble burst parameters such as fluence, peak flux and duration. An overview of the properties of BAT bursts and BAT'S performance as a burst monitor will be presented in this talk. BAT is a coded aperture imaging system with a wide (approx.2 sr) field of view consisting of a large coded mask located 1 m above a 5200 cm2 array of 32.768 CdZnTe detectors. All electronics and other hardware systems on the BAT have been operating well since commissioning and there is no sign of any degradation on orbit. The flight and ground software have proven similarly robust and allow the real time localization of all bursts and the rapid derivation of burst light curves, spectra and spectral fits on the ground.

Krimm, Hans A.↗
NASA NTRS2003

Agent-Supported Mission Operations Teamwork

This slide presentation reviews the development of software agents to support of mission operations teamwork. The goals of the work was to make automation by agents easy to use, supervise and direct, manage information and communication to decrease distraction, interruptions, workload and errors, reduce mission impact of off-nominal situations and increase morale and decrease turnover. The accomplishments or the project are: 1. Collaborative agents - mixed initiative and creation of instructions for mediating agent 2. Methods for prototyping, evaluating and evolving socio-technical systems 3. Technology infusion: teamwork tools in mISSIons 4. Demonstrations in simulation testbed An example of the use of agent is given, the use of an agent to monitor a N2 tank leak. An incomplete instruction to the agent is handled with mediating assistants, or Intelligent Briefing and Response Assistant (IBRA). The IBRA Engine also watches data stream for triggers and executes Act-Whenever actions. There is also a Briefing and Response Instruction (BRI) which is easy for a discipline specialist to create through a BRI editor.

Malin, Jane T.↗
NASA NTRS2009

Complex Event Recognition Architecture

Complex Event Recognition Architecture (CERA) is the name of a computational architecture, and software that implements the architecture, for recognizing complex event patterns that may be spread across multiple streams of input data. One of the main components of CERA is an intuitive event pattern language that simplifies what would otherwise be the complex, difficult tasks of creating logical descriptions of combinations of temporal events and defining rules for combining information from different sources over time. In this language, recognition patterns are defined in simple, declarative statements that combine point events from given input streams with those from other streams, using conjunction, disjunction, and negation. Patterns can be built on one another recursively to describe very rich, temporally extended combinations of events. Thereafter, a run-time matching algorithm in CERA efficiently matches these patterns against input data and signals when patterns are recognized. CERA can be used to monitor complex systems and to signal operators or initiate corrective actions when anomalous conditions are recognized. CERA can be run as a stand-alone monitoring system, or it can be integrated into a larger system to automatically trigger responses to changing environments or problematic situations.

Fitzgerald, William A.↗
NASA NTRS2007

Creating Interactive Graphical Overlays in the Advanced Weather Interactive Processing System Using Shapefiles and DGM Files

Graphical overlays can be created in real-time in the Advanced Weather Interactive Processing System (AWIPS) using shapefiles or Denver AWIPS Risk Reduction and Requirements Evaluation (DARE) Graphics Metafile (DGM) files. This presentation describes how to create graphical overlays on-the-fly for AWIPS, by using two examples of AWIPS applications that were created by the Applied Meteorology Unit (AMU) located at Cape Canaveral Air Force Station (CCAFS), Florida. The first example is the Anvil Threat Corridor Forecast Tool, which produces a shapefile that depicts a graphical threat corridor of the forecast movement of thunderstorm anvil clouds, based on the observed or forecast upper-level winds. This tool is used by the Spaceflight Meteorology Group (SMG) at Johnson Space Center, Texas and 45th Weather Squadron (45 WS) at CCAFS to analyze the threat of natural or space vehicle-triggered lightning over a location. The second example is a launch and landing trajectory tool that produces a DGM file that plots the ground track of space vehicles during launch or landing. The trajectory tool can be used by SMG and the 45 WS forecasters to analyze weather radar imagery along a launch or landing trajectory. The presentation will list the advantages and disadvantages of both file types for creating interactive graphical overlays in future AWIPS applications. Shapefiles are a popular format used extensively in Geographical Information Systems. They are usually used in AWIPS to depict static map backgrounds. A shapefile stores the geometry and attribute information of spatial features in a dataset (ESRI 1998). Shapefiles can contain point, line, and polygon features. Each shapefile contains a main file, index file, and a dBASE table. The main file contains a record for each spatial feature, which describes the feature with a list of its vertices. The index file contains the offset of each record from the beginning of the main file. The dBASE table contains records for each attribute. Attributes are commonly used to label spatial features. Shapefiles can be viewed, but not created in AWIPS. As a result, either third-party software can be installed on an AWIPS workstation, or new software must be written to create shapefiles in the correct format.

Barrett, Joe H., III↗
NASA NTRS1994

In search of Nemesis

The parallax of all stars of visual magnitude greater than about 6.5 has already been measured. If Nemesis is a main-sequence star 1 parsec away, this requires Nemesis's mass to be less than about 0.4 solar masses. If it were less than about 0.05 solar masses its gravity would be too weak to trigger a comet storm. If Nemesis is on the main sequence, this mass range requires it to be a red dwarf. A red dwarf companion would probably have been missed by standard astronomical surveys. Nearby stars are usually found because they are bright or have high proper motion. However, Nemesis's proper motion would now be 0.01 arcsec/yr, and if it is a red dwarf its magnitude is about 10 - too dim to attract attention. Unfortunately, standard four-color photometry does not distinguish between red dwarfs and giants. So although surveys such as the Dearborn Red Star Catalog list stars by magnitude and spectral type, they do not identify the dwarfs. Every star of the correct spectral type and magnitude must be scrutinized. Our candidate list is a hybrid; candidate red stars are identified in the astrometrically poor Dearborn Red Star Catalog and their positions are corrected using the Hubble Guide Star Catalog. When errors in the Dearborn catalog make it impossible to identify the corresponding Hubble star, the fields are split so that we have one centering on each possible candidate. We are currently scrutinizing 3098 fields, which we believe contain all possible red dwarf candidates in the northern hemisphere. Since our last report the analysis and database software has been completely rebuilt to take advantage of updated hardware, to make the data more accessible, and to implement improved methods of data analysis. The software is now completed and we are eliminating stars every clear night.

Carlson, S.↗
NASA NTRS2015

BioSentinel: Mission Development of a Radiation Biosensor to Gauge DNA Damage and Repair Beyond Low Earth Orbit on a 6U Nanosatellite.

We are designing and developing a "6U" (10 x 22 x 34 cm; 14 kg) nanosatellite as a secondary payload to fly aboard NASA's Space Launch System (SLS) Exploration Mission (EM) 1, scheduled for launch in late 2017. For the first time in over forty years, direct experimental data from biological studies beyond low Earth orbit (LEO) will be obtained during BioSentinel's 12- to 18- month mission. BioSentinel will measure the damage and repair of DNA in a biological organism and allow us to compare that to information from onboard physical radiation sensors. In order to understand the relative contributions of the space environment's two dominant biological perturbations, reduced gravity and ionizing radiation, results from deep space will be directly compared to data obtained in LEO (on ISS) and on Earth. These data points will be available for validation of existing biological radiation damage and repair models, and for extrapolation to humans, to assist in mitigating risks during future long-term exploration missions beyond LEO. The BioSentinel Payload occupies 4U of the spacecraft and will utilize the monocellular eukaryotic organism Saccharomyces cerevisiae (yeast) to report DNA double-strand-break (DSB) events that result from ambient space radiation. DSB repair exhibits striking conservation of repair proteins from yeast to humans. Yeast was selected because of 1) its similarity to cells in higher organisms, 2) the well-established history of strains engineered to measure DSB repair, 3) its spaceflight heritage, and 4) the wealth of available ground and flight reference data. The S. cerevisiae flight strain will include engineered genetic defects to prevent growth and division until a radiation-induced DSB activates the yeast's DNA repair mechanisms. The triggered culture growth and metabolic activity directly indicate a DSB and its successful repair. The yeast will be carried in the dry state within the 1-atm P/L container in 18 separate fluidics cards with each card having 16 independent culture microwells, with integral microchannels and filters to supply nutrients and reagents, confine the yeast to the wells, and enable optical measurement. The measurement subsystem will monitor each subgroup of culture wells continuously for several weeks, optically tracking DSBtriggered cell growth and metabolism. BioSentinel will also include physical radiation sensors based on the TimePix sensor, as implemented by JSC's RadWorks group, which record individual radiation events including estimates of their linear-energytransfer (LET) values. Radiation-dose and LET data will be compared directly to the rate of DSB-and-repair events measured by the S. cerevisiae biosentinels. The spacecraft bus will operate in a deep space environment with functions that include command and data handling, communications, power generation (via deployable solar panels) and storage, and attitude determination-and-control system with micropropulsion. Development of the BioSentinel spacecraft will mature and prove multiple nanosatellite advances in order to function well beyond LEO: Communications from distances of ≥ 500,000 km; Autonomous attitude control, momentum management, and safe mode of nanosatellites in deep space; Shielding-, hardening-, design-, and software-derived radiation tolerance for electronics; Reliable functionality for 12 - 18 months of key subsystems for biofluidics, memory, communications, power, etc.; Close integration of living biological radiation event monitors with miniature physical radiation spectrometers; Biological measurement of solar particle events beyond Earth orbit In addition to providing the first biological results from beyond LEO in over 4 decades, BioSentinel will provide an adaptable small-satellite instrument platform to perform a range of human-exploration-relevant measurements that characterize the biological consequences of multiple outer space environments. BioSentinel is being developed under NASA's Advanced Exploration Systems program.

DNA damage↗
NASA NTRS1996

Hypercars: The next industrial revolution

The auto industry -- one-seventh of the GNP, and the highest expression of the Iron Age -- is about to trigger the biggest transformation in industrial structure since the microchip. Ultralight cars molded from net-shape advanced composites can be several-fold lighter than present steel cars, yet safer, sportier, and more comfortable, durable, and beautiful. Modern hybrid-electric drives boost efficiency approximately 1.3-1.5x in heavy steel cars, but approximately 5-20x in ultralight, very slippery plafforms. Synergistically combined into ultralight-hybrid 'hypercars,' these elements can yield state-of-the-shelf family cars that average 150-300+ mi/gal -- twice that with state-of-the-art technologies -- yet can also be superior in all other respects, probably including cost: carbon-fiber monocoques can actually be cheaper to mass-produce that steel unibodies. Designing cars more like aircraft and less like tanks requires not only an approximately 400-500 kg curb mass and very low air and road drag, but also an aerospace philosophy of engineering integration. Mass, cost, and complexity turn out to compound with heavy hybrids but to decompound with ultralight hybrids, owing partly to radical simplification. Excellent aerodynamics, preferable including advanced techniques for passive boundary-layer control, will be the key to successful design integration. Transforming automaking is a competitive and environmental imperative, could form the nucleus of a green industrial Renaissance, and would enhance national security by, among other things, saving as much oil as OPEC now extracts. However, this transformation faces serious cultural barriers. For example, hypercars will be more like computers with wheels than like cars with chips -- they'll have an order of magnitude more code than today's cars -- but Detroit is not a software culture. Just the transition from stamped and welded steel to integrated and adhesive-joined synthetics is difficult enough. Nonetheless, hypercars are rapidly heading to market in the late 1990s, because approximately 25 current and intending automakers are eager to capture their potentially decisive competitive advantages -- including order-of-magnitude reductions in product cycle time, tooling cost, assembly effort, and parts count. Hypercars will succeed, and may well sweep the market, not because of mandates or subsidies, but because of manufacturers' quest for competitive advantage and customers' desire for better, smarter cars.

Lovins, Amory B.↗
NASA NTRS2012

Fault Tolerance Middleware for a Multi-Core System

Fault Tolerance Middleware (FTM) provides a framework to run on a dedicated core of a multi-core system and handles detection of single-event upsets (SEUs), and the responses to those SEUs, occurring in an application running on multiple cores of the processor. This software was written expressly for a multi-core system and can support different kinds of fault strategies, such as introspection, algorithm-based fault tolerance (ABFT), and triple modular redundancy (TMR). It focuses on providing fault tolerance for the application code, and represents the first step in a plan to eventually include fault tolerance in message passing and the FTM itself. In the multi-core system, the FTM resides on a single, dedicated core, separate from the cores used by the application. This is done in order to isolate the FTM from application faults and to allow it to swap out any application core for a substitute. The structure of the FTM consists of an interface to a fault tolerant strategy module, a responder module, a fault manager module, an error factory, and an error mapper that determines the severity of the error. In the present reference implementation, the only fault tolerant strategy implemented is introspection. The introspection code waits for an application node to send an error notification to it. It then uses the error factory to create an error object, and at this time, a severity level is assigned to the error. The introspection code uses its built-in knowledge base to generate a recommended response to the error. Responses might include ignoring the error, logging it, rolling back the application to a previously saved checkpoint, swapping in a new node to replace a bad one, or restarting the application. The original error and recommended response are passed to the top-level fault manager module, which invokes the response. The responder module also notifies the introspection module of the generated response. This provides additional information to the introspection module that it can use in generating its next response. For example, if the responder triggers an application rollback and errors are still occurring, the introspection module may decide to recommend an application restart.

Some, Raphael R.↗
NASA NTRS2012

Trick Simulation Environment 07

The Trick Simulation Environment is a generic simulation toolkit used for constructing and running simulations. This release includes a Monte Carlo analysis simulation framework and a data analysis package. It produces all auto documentation in XML. Also, the software is capable of inserting a malfunction at any point during the simulation. Trick 07 adds variable server output options and error messaging and is capable of using and manipulating wide characters for international support. Wide character strings are available as a fundamental type for variables processed by Trick. A Trick Monte Carlo simulation uses a statistically generated, or predetermined, set of inputs to iteratively drive the simulation. Also, there is a framework in place for optimization and solution finding where developers may iteratively modify the inputs per run based on some analysis of the outputs. The data analysis package is capable of reading data from external simulation packages such as MATLAB and Octave, as well as the common comma-separated values (CSV) format used by Excel, without the use of external converters. The file formats for MATLAB and Octave were obtained from their documentation sets, and Trick maintains generic file readers for each format. XML tags store the fields in the Trick header comments. For header files, XML tags for structures and enumerations, and the members within are stored in the auto documentation. For source code files, XML tags for each function and the calling arguments are stored in the auto documentation. When a simulation is built, a top level XML file, which includes all of the header and source code XML auto documentation files, is created in the simulation directory. Trick 07 provides an XML to TeX converter. The converter reads in header and source code XML documentation files and converts the data to TeX labels and tables suitable for inclusion in TeX documents. A malfunction insertion capability allows users to override the value of any simulation variable, or call a malfunction job, at any time during the simulation. Users may specify conditions, use the return value of a malfunction trigger job, or manually activate a malfunction. The malfunction action may consist of executing a block of input file statements in an action block, setting simulation variable values, call a malfunction job, or turn on/off simulation jobs.

Lin, Alexander S.↗
NASA NTRS2008

Volume Averaged Height Integrated Radar Reflectivity (VAHIRR) Cost-Benefit Analysis

Lightning Launch Commit Criteria (LLCC) are designed to prevent space launch vehicles from flight through environments conducive to natural or triggered lightning and are used for all U.S. government and commercial launches at government and civilian ranges. They are maintained by a committee known as the NASA/USAF Lightning Advisory Panel (LAP). The previous LLCC for anvil cloud, meant to avoid triggered lightning, have been shown to be overly restrictive. Some of these rules have had such high safety margins that they prohibited flight under conditions that are now thought to be safe 90% of the time, leading to costly launch delays and scrubs. The LLCC for anvil clouds was upgraded in the summer of 2005 to incorporate results from the Airborne Field Mill (ABFM) experiment at the Eastern Range (ER). Numerous combinations of parameters were considered to develop the best correlation of operational weather observations to in-cloud electric fields capable of rocket triggered lightning in anvil clouds. The Volume Averaged Height Integrated Radar Reflectivity (VAHIRR) was the best metric found. Dr. Harry Koons of Aerospace Corporation conducted a risk analysis of the VAHIRR product. The results indicated that the LLCC based on the VAHIRR product would pose a negligible risk of flying through hazardous electric fields. Based on these findings, the Kennedy Space Center Weather Office is considering seeking funding for development of an automated VAHIRR algorithm for the new ER 45th Weather Squadron (45 WS) RadTec 431250 weather radar and Weather Surveillance Radar-1988 Doppler (WSR-88D) radars. Before developing an automated algorithm, the Applied Meteorology Unit (AMU) was tasked to determine the frequency with which VAHIRR would have allowed a launch to safely proceed during weather conditions otherwise deemed "red" by the Launch Weather Officer. To do this, the AMU manually calculated VAHIRR values based on candidate cases from past launches with known anvil cloud LLCC violations. An automated algorithm may be developed if the analyses from past launches show VAHIRR would have provided a significant cost benefit by allowing a launch to proceed. The 45 WS at the ER and 30th Weather Squadron (30 WS) at the Western Range provided the AMU with launch weather summaries from past launches that were impacted by LLCC. The 45 WS provided summaries from 14 launch attempts and the 30 WS fkom 5. The launch attempts occurred between December 2001 and June 2007. These summaries helped the AMU determine when the LLCC were "red" due to anvil cloud. The AMU collected WSR-88D radar reflectivity, cloud-to-ground lightning strikes, soundings and satellite imagery. The AMU used step-by-step instructions for calculating VAHIRR manually as provided by the 45 WS. These instructions were used for all of the candidate cases when anvil cloud caused an LLCC violation identified in the launch weather summaries. The AMU evaluated several software programs capable of visualizing radar data so that VAHIRR could be calculated and chose GR2Analyst from Gibson Ridge Software, LLC. Data availability and lack of detail from some launch weather summaries permitted analysis of six launch attempts from the ER and none from the WR. The AMU did not take into account whether or not other weather LCC violations were occurring at the same time as the anvil cloud LLCC since the goal of this task was to determine how often VAHIRR provided relief to the anvil cloud LLCC at any time during several previous launch attempts. Therefore, in the statistics presented in this report, it is possible that even though VAHIRR provided relief to the anvil cloud LLCC, other weather LCC could have been violated not permitting the launch to proceed. The results of this cost-benefit analysis indicated VAHIRR provided relief from the anvil cloud LLCC between about 15% and 18% of the time for varying 5-minute time periods based on summaries fkom six launch attempts and would have allowed launch to proceed that were otherwise "NO GO" due to the anvil cloud LLCC if the T-0 time occurred during the anvil cloud LLCC violations.

Bauman, William H., III↗
NASA NTRS2013

Soft Decision Analyzer

The Soft Decision Analyzer (SDA) is an instrument that combines hardware, firmware, and software to perform realtime closed-loop end-to-end statistical analysis of single- or dual- channel serial digital RF communications systems operating in very low signal-to-noise conditions. As an innovation, the unique SDA capabilities allow it to perform analysis of situations where the receiving communication system slips bits due to low signal-to-noise conditions or experiences constellation rotations resulting in channel polarity in versions or channel assignment swaps. SDA s closed-loop detection allows it to instrument a live system and correlate observations with frame, codeword, and packet losses, as well as Quality of Service (QoS) and Quality of Experience (QoE) events. The SDA s abilities are not confined to performing analysis in low signal-to-noise conditions. Its analysis provides in-depth insight of a communication system s receiver performance in a variety of operating conditions. The SDA incorporates two techniques for identifying slips. The first is an examination of content of the received data stream s relation to the transmitted data content and the second is a direct examination of the receiver s recovered clock signals relative to a reference. Both techniques provide benefits in different ways and allow the communication engineer evaluating test results increased confidence and understanding of receiver performance. Direct examination of data contents is performed by two different data techniques, power correlation or a modified Massey correlation, and can be applied to soft decision data widths 1 to 12 bits wide over a correlation depth ranging from 16 to 512 samples. The SDA detects receiver bit slips within a 4 bits window and can handle systems with up to four quadrants (QPSK, SQPSK, and BPSK systems). The SDA continuously monitors correlation results to characterize slips and quadrant change and is capable of performing analysis even when the receiver under test is subjected to conditions where its performance degrades to high error rates (30 percent or beyond). The design incorporates a number of features, such as watchdog triggers that permit the SDA system to recover from large receiver upsets automatically and continue accumulating performance analysis unaided by operator intervention. This accommodates tests that can last in the order of days in order to gain statistical confidence in results and is also useful for capturing snapshots of rare events.

Steele, Glen↗
NASA NTRS2013

Orion MPCV Touchdown Detection Threshold Development and Testing

A robust method of detecting Orion Multi ]Purpose Crew Vehicle (MPCV) splashdown is necessary to ensure crew and hardware safety during descent and after touchdown. The proposed method uses a triple redundant system to inhibit Reaction Control System (RCS) thruster firings, detach parachute risers from the vehicle, and transition to the post ]landing segment of the Flight Software (FSW). The vehicle crew is the prime input for touchdown detection, followed by an autonomous FSW algorithm, and finally a strictly time based backup timer. RCS thrusters must be inhibited before submersion in water to protect against possible damage due to firing these jets under water. In addition, neglecting to declare touchdown will not allow the vehicle to transition to post ]landing activities such as activating the Crew Module Up ]righting System (CMUS), resulting in possible loss of communication and difficult recovery. A previous AIAA paper gAssessment of an Automated Touchdown Detection Algorithm for the Orion Crew Module h concluded that a strictly Inertial Measurement Unit (IMU) based detection method using an acceleration spike algorithm had the highest safety margins and shortest detection times of other methods considered. That study utilized finite element simulations of vehicle splashdown, generated by LS ]DYNA, which were expanded to a larger set of results using a Kriging surface fit. The study also used the Decelerator Systems Simulation (DSS) to generate flight dynamics during vehicle descent under parachutes. Proto ]type IMU and FSW MATLAB models provided the basis for initial algorithm development and testing. This paper documents an in ]depth trade study, using the same dynamics data and MATLAB simulations as the earlier work, to further develop the acceleration detection method. By studying the combined effects of data rate, filtering on the rotational acceleration correction, data persistence limits and values of acceleration thresholds, an optimal configuration was determined. The lever arm calculation, which removes the centripetal acceleration caused by vehicle rotation, requires that the vehicle angular acceleration be derived from vehicle body rates, necessitating the addition of a 2nd order filter to smooth the data. It was determined that using 200 Hz data directly from the vehicle IMU outperforms the 40 Hz FSW data rate. Data persistence counter values and acceleration thresholds were balanced in order to meet desired safety and performance. The algorithm proved to exhibit ample safety margin against early detection while under parachutes, and adequate performance upon vehicle splashdown. Fall times from algorithm initiation were also studied, and a backup timer length was chosen to provide a large safety margin, yet still trigger detection before CMUS inflation. This timer serves as a backup to the primary acceleration detection method. Additionally, these parameters were tested for safety on actual flight test data, demonstrating expected safety margins.

Daum, Jared↗
NASA NTRS2010

High-Speed Ring Bus

The high-speed ring bus at the Jet Propulsion Laboratory (JPL) allows for future growth trends in spacecraft seen with future scientific missions. This innovation constitutes an enhancement of the 1393 bus as documented in the Institute of Electrical and Electronics Engineers (IEEE) 1393-1999 standard for a spaceborne fiber-optic data bus. It allows for high-bandwidth and time synchronization of all nodes on the ring. The JPL ring bus allows for interconnection of active units with autonomous operation and increased fault handling at high bandwidths. It minimizes the flight software interface with an intelligent physical layer design that has few states to manage as well as simplified testability. The design will soon be documented in the AS-1393 standard (Serial Hi-Rel Ring Network for Aerospace Applications). The framework is designed for "Class A" spacecraft operation and provides redundant data paths. It is based on "fault containment regions" and "redundant functional regions (RFR)" and has a method for allocating cables that completely supports the redundancy in spacecraft design, allowing for a complete RFR to fail. This design reduces the mass of the bus by incorporating both the Control Unit and the Data Unit in the same hardware. The standard uses ATM (asynchronous transfer mode) packets, standardized by ITU-T, ANSI, ETSI, and the ATM Forum. The IEEE-1393 standard uses the UNI form of the packet and provides no protection for the data portion of the cell. The JPL design adds optional formatting to this data portion. This design extends fault protection beyond that of the interconnect. This includes adding protection to the data portion that is contained within the Bus Interface Units (BIUs) and by adding to the signal interface between the Data Host and the JPL 1393 Ring Bus. Data transfer on the ring bus does not involve a master or initiator. Following bus protocol, any BIU may transmit data on the ring whenever it has data received from its host. There is no centralized arbitration or bus granting. The JPL design provides for autonomous synchronization of the nodes on the ring bus. An address-synchronous latency adjust buffer (LAB) has been designed that cannot get out of synchronization and needs no external input. Also, a priority-driven cable selection behavior has been programmed into each unit on the ring bus. This makes the bus able to connect itself up, according to a maximum redundancy priority system, without the need for computer intervention at startup. Switching around a failed or switched-off unit is also autonomous. The JPL bus provides a map of all the active units for the host computer to read and use for fault management. With regard to timing, this enhanced bus recognizes coordinated timing on a spacecraft as critical and addresses this with a single source of absolute and relative time, which is broadcast to all units on the bus with synchronization maintained to the tens of nanoseconds. Each BIU consists of up to five programmable triggers, which may be programmed for synchronization of events within the spacecraft of instrument. All JPL-formatted data transmitted on the ring bus are automatically time-stamped.

Wysocky, Terry↗
NASA NTRS2009

Cooperative Three-Robot System for Traversing Steep Slopes

Teamed Robots for Exploration and Science in Steep Areas (TRESSA) is a system of three autonomous mobile robots that cooperate with each other to enable scientific exploration of steep terrain (slope angles up to 90 ). Originally intended for use in exploring steep slopes on Mars that are not accessible to lone wheeled robots (Mars Exploration Rovers), TRESSA and systems like TRESSA could also be used on Earth for performing rescues on steep slopes and for exploring steep slopes that are too remote or too dangerous to be explored by humans. TRESSA is modeled on safe human climbing of steep slopes, two key features of which are teamwork and safety tethers. Two of the autonomous robots, denoted Anchorbots, remain at the top of a slope; the third robot, denoted the Cliffbot, traverses the slope. The Cliffbot drives over the cliff edge supported by tethers, which are payed out from the Anchorbots (see figure). The Anchorbots autonomously control the tension in the tethers to counter the gravitational force on the Cliffbot. The tethers are payed out and reeled in as needed, keeping the body of the Cliffbot oriented approximately parallel to the local terrain surface and preventing wheel slip by controlling the speed of descent or ascent, thereby enabling the Cliffbot to drive freely up, down, or across the slope. Due to the interactive nature of the three-robot system, the robots must be very tightly coupled. To provide for this tight coupling, the TRESSA software architecture is built on a combination of (1) the multi-robot layered behavior-coordination architecture reported in "An Architecture for Controlling Multiple Robots" (NPO-30345), NASA Tech Briefs, Vol. 28, No. 10 (October 2004), page 65, and (2) the real-time control architecture reported in "Robot Electronics Architecture" (NPO-41784), NASA Tech Briefs, Vol. 32, No. 1 (January 2008), page 28. The combination architecture makes it possible to keep the three robots synchronized and coordinated, to use data from all three robots for decision- making at each step, and to control the physical connections among the robots. In addition, TRESSA (as in prior systems that have utilized this architecture) , incorporates a capability for deterministic response to unanticipated situations from yet another architecture reported in Control Architecture for Robotic Agent Command and Sensing (NPO-43635), NASA Tech Briefs, Vol. 32, No. 10 (October 2008), page 40. Tether tension control is a major consideration in the design and operation of TRESSA. Tension is measured by force sensors connected to each tether at the Cliffbot. The direction of the tension (both azimuth and elevation) is also measured. The tension controller combines a controller to counter gravitational force and an optional velocity controller that anticipates the motion of the Cliffbot. The gravity controller estimates the slope angle from the inclination of the tethers. This angle and the weight of the Cliffbot determine the total tension needed to counteract the weight of the Cliffbot. The total needed tension is broken into components for each Anchorbot. The difference between this needed tension and the tension measured at the Cliffbot constitutes an error signal that is provided to the gravity controller. The velocity controller computes the tether speed needed to produce the desired motion of the Cliffbot. Another major consideration in the design and operation of TRESSA is detection of faults. Each robot in the TRESSA system monitors its own performance and the performance of its teammates in order to detect any system faults and prevent unsafe conditions. At startup, communication links are tested and if any robot is not communicating, the system refuses to execute any motion commands. Prior to motion, the Anchorbots attempt to set tensions in the tethers at optimal levels for counteracting the weight of the Cliffbot; if either Anchorbot fails to reach its optimal tension level within a specified time, it sends message to the other robots and the commanded motion is not executed. If any mechanical error (e.g., stalling of a motor) is detected, the affected robot sends a message triggering stoppage of the current motion. Lastly, messages are passed among the robots at each time step (10 Hz) to share sensor information during operations. If messages from any robot cease for more than an allowable time interval, the other robots detect the communication loss and initiate stoppage.

Stroupe, Ashley↗