Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Software Requirements”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 811 records · Page 45

DSP Implementation of the Multiscale Retinex Image Enhancement Algorithm

The Retinex is a general-purpose image enhancement algorithm that is used to produce good visual representations of scenes. It performs a non-linear spatial/ spectral transform that synthesizes strong local contrast enhancement and color constancy. A real-time, video frame rate implementation of the Retinex is required to meet the needs of various potential users. Retinex processing contains a relatively large number of complex computations, thus to achieve real-time performance using current technologies requires specialized hardware and software. In this paper we discuss the design and development of a digital signal processor (DSP) implementation of the Retinex. The target processor is a Texas Instruments TMS320C6711 floating point DSP. NTSC video is captured using a dedicated frame grabber card, Retinex processed, and displayed on a standard monitor. We discuss the optimizations used to achieve real-time performance of the Retinex and also describe our future plans on using alternative architectures.

Hines, Glenn D.↗

Emergency Flight Control of a Twin-Jet Commercial Aircraft using Manual Throttle Manipulation

The Department of Homeland Security (DHS) created the PCAR (Propulsion-Controlled Aircraft Recovery) project in 2005 to mitigate the ManPADS (man-portable air defense systems) threat to the commercial aircraft fleet with near-term, low-cost proven technology. Such an attack could potentially cause a major FCS (flight control system) malfunction or other critical system failure onboard the aircraft, despite the extreme reliability of current systems. For the situations in which nominal flight controls are lost or degraded, engine thrust may be the only remaining means for emergency flight control [ref 1]. A computer-controlled thrust system, known as propulsion-controlled aircraft (PCA), was developed in the mid 1990s with NASA, McDonnell Douglas and Honeywell. PCA's major accomplishment was a demonstration of an automatic landing capability using only engine thrust [ref 11. Despite these promising results, no production aircraft have been equipped with a PCA system, due primarily to the modifications required for implementation. A minimally invasive option is TOC (throttles-only control), which uses the same control principles as PCA, but requires absolutely no hardware, software or other aircraft modifications. TOC is pure piloting technique, and has historically been utilized several times by flight crews, both military and civilian, in emergency situations stemming from a loss of conventional control. Since the 1990s, engineers at NASA Dryden Flight Research Center (DFRC) have studied TOC, in both simulation and flight, for emergency flight control with test pilots in numerous configurations. In general, it was shown that TOC was effective on certain aircraft for making a survivable landing. DHS sponsored both NASA Dryden Flight Research Center (Edwards, CA) and United Airlines (Denver, Colorado) to conduct a flight and simulation study of the TOC characteristics of a twin-jet commercial transport, and assess the ability of a crew to control an aircraft down to a survivable runway landing using TOC. The PCAR project objective was a set of pilot procedures for operation of a specific aircraft without hydraulics that (a) have been validated in both simulation and flight by relevant personnel, and (b) mesh well with existing commercial operations, maintenance, and training at a minimum cost. As a result of this study, a procedure has been developed to assist a crew in making a survivable landing using TOC. In a simulation environment, line pilots with little or no previous TOC experience performed survivable runway landings after a few practice TOC approaches. In-flight evaluations put line pilots in a simulated emergency situation where TOC was used to recover the aircraft, maneuver to a landing site, and perform an approach down to 200 feet AGL. The results of this research, including pilot observations, procedure comments, recommendations, future work and lessons learned, will he discussed. Flight data and video footage of TOC approaches may also be shown.

Cole, Jennifer H.↗

Big Science, Small-Budget Space Experiment Package Aka MISSE-5: A Hardware And Software Perspective

Conducting space experiments with small budgets is a fact of life for many design groups with low-visibility science programs. One major consequence is that specialized space grade electronic components are often too costly to incorporate into the design. Radiation mitigation now becomes more complex as a result of being restricted to the use of commercial off-the-shelf (COTS) parts. Unique hardware and software design techniques are required to succeed in producing a viable instrument suited for use in space. This paper highlights some of the design challenges and associated solutions encountered in the production of a highly capable, low cost space experiment package.

Krasowski, Michael↗

Development and Evaluation of Sensor Concepts for Ageless Aerospace Vehicles: Report 6 - Development and Demonstration of a Self-Organizing Diagnostic System for Structural Health Monitoring

This report describes a significant advance in the capability of the CSIRO/NASA structural health monitoring Concept Demonstrator (CD). The main thrust of the work has been the development of a mobile robotic agent, and the hardware and software modifications and developments required to enable the demonstrator to operate as a single, self-organizing, multi-agent system. This single-robot system is seen as the forerunner of a system in which larger numbers of small robots perform inspection and repair tasks cooperatively, by self-organization. While the goal of demonstrating self-organized damage diagnosis was not fully achieved in the time available, much of the work required for the final element that enables the robot to point the video camera and transmit an image has been completed. A demonstration video of the CD and robotic systems operating will be made and forwarded to NASA.

Batten, Adam↗

Modeling Constellation Virtual Missions Using the Vdot(Trademark) Process Management Tool

The authors have identified a software tool suite that will support NASA's Virtual Mission (VM) effort. This is accomplished by transforming a spreadsheet database of mission events, task inputs and outputs, timelines, and organizations into process visualization tools and a Vdot process management model that includes embedded analysis software as well as requirements and information related to data manipulation and transfer. This paper describes the progress to date, and the application of the Virtual Mission to not only Constellation but to other architectures, and the pertinence to other aerospace applications. Vdot s intuitive visual interface brings VMs to life by turning static, paper-based processes into active, electronic processes that can be deployed, executed, managed, verified, and continuously improved. A VM can be executed using a computer-based, human-in-the-loop, real-time format, under the direction and control of the NASA VM Manager. Engineers in the various disciplines will not have to be Vdot-proficient but rather can fill out on-line, Excel-type databases with the mission information discussed above. The author s tool suite converts this database into several process visualization tools for review and into Microsoft Project, which can be imported directly into Vdot. Many tools can be embedded directly into Vdot, and when the necessary data/information is received from a preceding task, the analysis can be initiated automatically. Other NASA analysis tools are too complex for this process but Vdot automatically notifies the tool user that the data has been received and analysis can begin. The VM can be simulated from end-to-end using the author s tool suite. The planned approach for the Vdot-based process simulation is to generate the process model from a database; other advantages of this semi-automated approach are the participants can be geographically remote and after refining the process models via the human-in-the-loop simulation, the system can evolve into a process management server for the actual process.

Hardy, Roger↗

Language Model Combination and Adaptation Using Weighted Finite State Transducers

In speech recognition systems language model (LMs) are often constructed by training and combining multiple n-gram models. They can be either used to represent different genres or tasks found in diverse text sources, or capture stochastic properties of different linguistic symbol sequences, for example, syllables and words. Unsupervised LM adaption may also be used to further improve robustness to varying styles or tasks. When using these techniques, extensive software changes are often required. In this paper an alternative and more general approach based on weighted finite state transducers (WFSTs) is investigated for LM combination and adaptation. As it is entirely based on well-defined WFST operations, minimum change to decoding tools is needed. A wide range of LM combination configurations can be flexibly supported. An efficient on-the-fly WFST decoding algorithm is also proposed. Significant error rate gains of 7.3% relative were obtained on a state-of-the-art broadcast audio recognition task using a history dependently adapted multi-level LM modelling both syllable and word sequences

Liu, X.↗

Checking Flight Rules with TraceContract: Application of a Scala DSL for Trace Analysis

Typically during the design and development of a NASA space mission, rules and constraints are identified to help reduce reasons for failure during operations. These flight rules are usually captured in a set of indexed tables, containing rule descriptions, rationales for the rules, and other information. Flight rules can be part of manual operations procedures carried out by humans. However, they can also be automated, and either implemented as on-board monitors, or as ground based monitors that are part of a ground data system. In the case of automated flight rules, one considerable expense to be addressed for any mission is the extensive process by which system engineers express flight rules in prose, software developers translate these requirements into code, and then both experts verify that the resulting application is correct. This paper explores the potential benefits of using an internal Scala DSL for general trace analysis, named TRACECONTRACT, to write executable specifications of flight rules. TRACECONTRACT can generally be applied to analysis of for example log files or for monitoring executing systems online.

temporal logic↗

End-of-Mission Passivation: Successes and Challenges

The passivation of spacecraft and launch vehicle orbital stages at end-of-mission has been a principal space debris mitigation measure world-wide since the 1980 s. Space vehicle passivation includes the removal of stored energies, especially those associated with propulsion and electrical power systems. Prior to 2007 the breakup of non-functioning, non-passivated space vehicles was the major source of hazardous debris in Earth orbit. The United Nations and the Inter-Agency Space Debris Coordination Committee have both included passivation in their formal space debris mitigation guidelines. This often simple countermeasure has been adopted by many spacefaring countries and organizations and has undoubtedly prevented numerous major satellite breakups. For some existing space vehicle designs, passivation requires changes in hardware, software, and/or operational procedures. Questions about the permissible degree of passivation for both current and future space vehicles have arisen and are addressed herein. An important element to be considered is the potentially long period in which the space vehicle will remain in orbit, i.e., up to 25 years after mission termination in LEO and for centuries in orbits above LEO. Finally, the issue of passivation of space vehicles which have failed prematurely is addressed.

Johnson, Nicholas↗

ISS Live!

International Space Station Live! (ISSLive!) is a Web application that uses a proprietary commercial technology called Lightstreamer to push data across the Internet using the standard http port (port 80). ISSLive! uses the push technology to display real-time telemetry and mission timeline data from the space station in any common Web browser or Internet- enabled mobile device. ISSLive! is designed to fill a unique niche in the education and outreach areas by providing access to real-time space station data without a physical presence in the mission control center. The technology conforms to Internet standards, supports the throughput needed for real-time space station data, and is flexible enough to work on a large number of Internet-enabled devices. ISSLive! consists of two custom components: (1) a series of data adapters that resides server-side in the mission control center at Johnson Space Center, and (2) a set of public html that renders the data pushed from the data adapters. A third component, the Lightstreamer server, is commercially available from a third party and acts as an intermediary between custom components (1) and (2). Lightstreamer also provides proprietary software libraries that are required to use the custom components. At the time of this reporting, this is the first usage of Web-based, push streaming technology in the aerospace industry.

Price, Jennifer↗

Mending the Gap, An Effort to Aid the Transfer of Formal Methods Technology

Formal methods can be applied to many of the development and verification activities required for civil avionics software. RTCA/DO-178B, Software Considerations in Airborne Systems and Equipment Certification, gives a brief description of using formal methods as an alternate method of compliance with the objectives of that standard. Despite this, the avionics industry at large has been hesitant to adopt formal methods, with few developers have actually used formal methods for certification credit. Why is this so, given the volume of evidence of the benefits of formal methods? This presentation will explore some of the challenges to using formal methods in a certification context and describe the effort by the Formal Methods Subgroup of RTCA SC-205/EUROCAE WG-71 to develop guidance to make the use of formal methods a recognized approach.

Hayhurst, Kelly↗

Effects of Long-Duration Microgravity on Fine Motor Skills: ISS One-Year Mission

Fine motor skills will be critical in future long-duration missions, particularly those skills needed to interact with advanced technologies in next-generation vehicles, spacesuits, and habitats. Studies to date on the effects of microgravity and gravitational transitions on fine motor performance have not yielded conclusive results. Datasets are incomplete-timeline gaps in the microgravity data sessions. Studies have not focused on the fine motor actions that are likely to be required for interacting with software displays and controls (pointing, clicking, dragging, multi-touch/pinching). The majority of studies have used a joystick or arm reaching task. Touchscreen tablets are already in use on ISS, and at least one commercial partner is already planning a cockpit with touchscreens as the primary means of input. We must ensure that crewmembers are ready to perform with computer-based devices after a long-duration voyage and transition to surface operations.

Kritina Holden↗

GOES-R Active Vibration Damping Controller Design, Implementation, and On-Orbit Performance

GOES-R series spacecraft feature a number of flexible appendages with modal frequencies below 3.0 Hz which, if excited by spacecraft disturbances, can be sources of undesirable jitter perturbing spacecraft pointing. In order to meet GOES-R pointing stability requirements, the spacecraft flight software implements an Active Vibration Damping (AVD) rate control law which acts in parallel with the nadir point attitude control law. The AVD controller commands spacecraft reaction wheel actuators based upon Inertial Measurement Unit (IMU) inputs to provide additional damping for spacecraft structural modes below 3.0 Hz which vary with solar wing angle. A GOES-R spacecraft dynamics and attitude control system identified model is constructed from pseudo-random reaction wheel torque commands and IMU angular rate response measurements occurring over a single orbit during spacecraft post-deployment activities. The identified Fourier model is computed on the ground, uplinked to the spacecraft flight computer, and the AVD controller filter coefficients are periodically computed on-board from the Fourier model. Consequently, the AVD controller formulation is based not upon pre-launch simulation model estimates but upon on-orbit nadir point attitude control and time-varying spacecraft dynamics. GOES-R high-fidelity time domain simulation results herein demonstrate the accuracy of the AVD identified Fourier model relative to the pre-launch spacecraft dynamics and control truth model. The AVD controller on-board the GOES-16 spacecraft achieves more than a ten-fold increase in structural mode damping of the fundamental solar wing mode while maintaining controller stability margins and ensuring that the nadir point attitude control bandwidth does not fall below 0.02 Hz. On-orbit GOES-16 spacecraft appendage modal frequencies and damping ratios are quantified based upon the AVD system identification, and the increase in modal damping provided by the AVD controller for each structural mode is presented. The GOES-16 spacecraft AVD controller frequency domain stability margins and nadir point attitude control bandwidth are presented along with on-orbit time domain disturbance response performance.

Active Vibration Damping↗

Autonomous Maneuver Planning and Execution for GeoXO Station Keeping and Momentum Management

GOES-16 was launched in 2016 using GPS at GEO, a first for civil space. With the subsequent launch of GOES-17 in 2018, followed by GOES-18 in 2022, we have accumulated over a decade of error free GPS navigation experience at GEO. Confident in GPS performance at GEO, the next generation/NASA geosynchronous weather satellite program GeoXO will require the spacecraft flight software to automate station keeping and momentum management maneuver planning and execution. Coupled with low thrust propulsion, it gives us assurance that on-board maneuver planning and execution can be implemented at a very low risk, allowing instruments to operate through maneuvers while maintaining a more accurate orbital slot and reducing operational costs. In this paper, we discuss how GOES-R maneuver planning is currently performed on the ground and contrast this with our vision of how it might be automated on-board.

GeoXO↗

Geometry Software Common to All Experiments

All imaging, remote sensing, and in situ experiments require information about the geometry and location of observations. An alterntive to collecting geometry data with a supplementary experiment data record is proposed. The new method involves identifying the fundamental information, that is, the geometric state upon which geometry calculations are based, and maintaining or delivering these calculations in separate packages which are easily replaced when improved information is available. Implementation of this method in spacecraft navigation is discussed along with software system requirements.

Source record↗

Numerical arc segmentation algorithm for a radio conference-NASARC (version 2.0) technical manual

The information contained in the NASARC (Version 2.0) Technical Manual (NASA TM-100160) and NASARC (Version 2.0) User's Manual (NASA TM-100161) relates to the state of NASARC software development through October 16, 1987. The Technical Manual describes the Numerical Arc Segmentation Algorithm for a Radio Conference (NASARC) concept and the algorithms used to implement the concept. The User's Manual provides information on computer system considerations, installation instructions, description of input files, and program operating instructions. Significant revisions have been incorporated in the Version 2.0 software. These revisions have enhanced the modeling capabilities of the NASARC procedure while greatly reducing the computer run time and memory requirements. Array dimensions within the software have been structured to fit within the currently available 6-megabyte memory capacity of the International Frequency Registration Board (IFRB) computer facility. A piecewise approach to predetermined arc generation in NASARC (Version 2.0) allows worldwide scenarios to be accommodated within these memory constraints while at the same time effecting an overall reduction in computer run time.

Whyte, Wayne A., Jr.↗

Software for Generating Troposphere Corrections for InSAR Using GPS and Weather Model Data

Atmospheric errors due to the troposphere are a limiting error source for spaceborne interferometric synthetic aperture radar (InSAR) imaging. This software generates tropospheric delay maps that can be used to correct atmospheric artifacts in InSAR data. The software automatically acquires all needed GPS (Global Positioning System), weather, and Digital Elevation Map data, and generates a tropospheric correction map using a novel algorithm for combining GPS and weather information while accounting for terrain. Existing JPL software was prototypical in nature, required a MATLAB license, required additional steps to acquire and ingest needed GPS and weather data, and did not account for topography in interpolation. Previous software did not achieve a level of automation suitable for integration in a Web portal. This software overcomes these issues. GPS estimates of tropospheric delay are a source of corrections that can be used to form correction maps to be applied to InSAR data, but the spacing of GPS stations is insufficient to remove short-wavelength tropospheric artifacts. This software combines interpolated GPS delay with weather model precipitable water vapor (PWV) and a digital elevation model to account for terrain, increasing the spatial resolution of the tropospheric correction maps and thus removing short wavelength tropospheric artifacts to a greater extent. It will be integrated into a Web portal request system, allowing use in a future L-band SAR Earth radar mission data system. This will be a significant contribution to its technology readiness, building on existing investments in in situ space geodetic networks, and improving timeliness, quality, and science value of the collected data

Moore, Angelyn W.↗

Second Evaluation of Job Queuing/Scheduling Software

The recent proliferation of high performance workstations and the increased reliability of parallel systems have illustrated the need for robust job management systems to support parallel applications. To address this issue, NAS compiled a requirements checklist for job queuing/scheduling software. Next, NAS evaluated the leading job management system (JMS) software packages against the checklist. A year has now elapsed since the first comparison was published, and NAS has repeated the evaluation. This report describes this second evaluation, and presents the results of Phase 1: Capabilities versus Requirements. We show that JMS support for running parallel applications on clusters of workstations and parallel systems is still lacking, however, definite progress has been made by the vendors to correct the deficiencies. This report is supplemented by a WWW interface to the data collected, to aid other sites in extracting the evaluation information on specific requirements of interest.

Jones, James Patton↗

Formal Methods Demonstration Project for Space Applications

Requirements and design specifications are a high priority candidate for better software engineering techniques. Most hazardous software safety errors found during system integration and test of two NASA spacecraft were the result of requirements discrepancies or interface specifications. The highest density of major defects found through the use of software inspections was during the requirements phase. This was seven times higher than the density of major defects found in code inspections. Requirements errors are between 10 and 100 times more costly to fix at later phases of the software lifecycle than at the requirements phase itself. One study found that early lifecycle errors are the most likely to lead to catastrophic failures.

critical↗