Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “software is hard”

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 73 records · Page 4
All sourcesNASA NTRSDOE OSTI
NASA NTRS2004

Space Communications Emulation Facility

Establishing space communication between ground facilities and other satellites is a painstaking task that requires many precise calculations dealing with relay time, atmospheric conditions, and satellite positions, to name a few. The Space Communications Emulation Facility (SCEF) team here at NASA is developing a facility that will approximately emulate the conditions in space that impact space communication. The emulation facility is comprised of a 32 node distributed cluster of computers; each node representing a satellite or ground station. The objective of the satellites is to observe the topography of the Earth (water, vegetation, land, and ice) and relay this information back to the ground stations. Software originally designed by the University of Kansas, labeled the Emulation Manager, controls the interaction of the satellites and ground stations, as well as handling the recording of data. The Emulation Manager is installed on a Linux Operating System, employing both Java and C++ programming codes. The emulation scenarios are written in extensible Markup Language, XML. XML documents are designed to store, carry, and exchange data. With XML documents data can be exchanged between incompatible systems, which makes it ideal for this project because Linux, MAC and Windows Operating Systems are all used. Unfortunately, XML documents cannot display data like HTML documents. Therefore, the SCEF team uses XML Schema Definition (XSD) or just schema to describe the structure of an XML document. Schemas are very important because they have the capability to validate the correctness of data, define restrictions on data, define data formats, and convert data between different data types, among other things. At this time, in order for the Emulation Manager to open and run an XML emulation scenario file, the user must first establish a link between the schema file and the directory under which the XML scenario files are saved. This procedure takes place on the command line on the Linux Operating System. Once this link has been established the Emulation manager validates all the XML files in that directory against the schema file, before the actual scenario is run. Using some very sophisticated commercial software called the Satellite Tool Kit (STK) installed on the Linux box, the Emulation Manager is able to display the data and graphics generated by the execution of a XML emulation scenario file. The Emulation Manager software is written in JAVA programming code. Since the SCEF project is in the developmental stage, the source code for this type of software is being modified to better fit the requirements of the SCEF project. Some parameters for the emulation are hard coded, set at fixed values. Members of the SCEF team are altering the code to allow the user to choose the values of these hard coded parameters by inserting a toolbar onto the preexisting GUI.

Hill, Chante A.↗
NASA NTRS2003

NASA Tech Briefs, December 2003

Topics covered include: Organic/Inorganic Hybrid Polymer/Clay Nanocomposites; Less-Toxic Coatings for Inhibiting Corrosion of Aluminum; Liquid Coatings for Reducing Corrosion of Steel in Concrete; Processable Polyimides Containing APB and Reactive End Caps; Rod/Coil Block Copolyimides for Ion-Conducting Membranes; Techniques for Characterizing Microwave Printed Antennas; Cylindrical Antenna With Partly Adaptive Phased-Array Feed; Command Interface ASIC - Analog Interface ASIC Chip Set; Predicting Accumulations of Ice on Aerodynamic Surfaces; Analyzing Aeroelasticity in Turbomachines; Software for Allocating Resources in the Deep Space Network; Expert Seeker; High-Speed Recording of Test Data on Hard Disks; Functionally Graded Nanophase Beryllium/Carbon Composites; Thin Thermal-Insulation Blankets for Very High Temperatures; Aerostructures Test Wing; Flight-Test Evaluation of Flutter-Prediction Methods; Piezoelectrically Actuated Microvalve for Liquid Effluents; Larger-Stroke Piezoelectrically Actuated Microvalve; Innovative, High-Pressure, Cryogenic Control Valve: Short Face-to-Face, Reduced Cost; Safer Roadside Crash Walls Would Limit Deceleration; Improved Interactive Medical-Imaging System; Scanning Microscopes Using X Rays and Microchannels; Slotting Fins of Heat Exchangers to Provide Thermal Breaks; Methane Clathrate Hydrate Prospecting; Automated Monitoring with a BSP Fault-Detection Test; Automated Monitoring with a BCP Fault-Decision Test; Vector-Ordering Filter Procedure for Data Reduction; Remote Sensing and Information Technology for Large Farms; Developments at the Advanced Design Technologies Testbed; Spore-Forming Bacteria that Resist Sterilization; and Acoustical Applications of the HHT Method.

Source record↗
NASA NTRS1993

Mongoose: Creation of a Rad-Hard MIPS R3000

This paper describes the development of a 32 Bit, full MIPS R3000 code-compatible Rad-Hard CPU, code named Mongoose. Mongoose progressed from contract award, through the design cycle, to operational silicon in 12 months to meet a space mission for NASA. The goal was the creation of a fully static device capable of operation to the maximum Mil-883 derated speed, worst-case post-rad exposure with full operational integrity. This included consideration of features for functional enhancements relating to mission compatibility and removal of commercial practices not supported by Rad-Hard technology. 'Mongoose' developed from an evolution of LSI Logic's MIPS-I embedded processor, LR33000, code named Cobra, to its Rad-Hard 'equivalent', Mongoose. The term 'equivalent' is used to infer that the core of the processor is functionally identical, allowing the same use and optimizations of the MIPS-I Instruction Set software tool suite for compilation, software program trace, etc. This activity was started in September of 1991 under a contract from NASA-Goddard Space Flight Center (GSFC)-Flight Data Systems. The approach affected a teaming of NASA-GSFC for program development, LSI Logic for system and ASIC design coupled with the Rad-Hard process technology, and Harris (GASD) for Rad-Hard microprocessor design expertise. The program culminated with the generation of Rad-Hard Mongoose prototypes one year later.

Lincoln, Dan↗
NASA NTRS1986

Event time recorder

Accurate timing of sounding rocket payload events is critical for successful missions. The payload event timers used must be checked numerous times to verify proper settings. A cost-effective time event recorder was developed which will store up to 32 time events and provide a hard copy printout. The event recorder consists of an AIM 65 microcomputer with a custom hardware interface and assembly language software. The 32 input lines can be triggered by voltage changes or current sensing.

Stuchlik, D. W.↗
NASA NTRS1992

The Soft X-ray Telescope for Solar-A - Design evolution and lessons learned

The Japanese Solar-A satellite mission's Soft X-ray Telescope uses grazing-incidence optics, a CCD detector, and a pair of filter wheels for wavelength selection. A coaxially-mounted visible-light lens furnished sunspot and magnetic plage images, together with aspect information which aids in aligning the soft X-ray images with those from the satellite's Hard X-ray Telescope. Instrument electronics are microprocessor-based, and imbedded in a tightly integrated distributed system. Control software is divided between the instrument microprocessor and the spacecraft control computer.

Bruner, Marilyn E.↗
NASA NTRS2004

Portable Electromyograph

A portable electronic apparatus records electromyographic (EMG) signals in as many as 16 channels at a sampling rate of 1,024 Hz in each channel. The apparatus (see figure) includes 16 differential EMG electrodes (each electrode corresponding to one channel) with cables and attachment hardware, reference electrodes, an input/output-and-power-adapter unit, a 16-bit analog-to-digital converter, and a hand-held computer that contains a removable 256-MB flash memory card. When all 16 EMG electrodes are in use, full-bandwidth data can be recorded in each channel for as long as 8 hours. The apparatus is powered by a battery and is small enough that it can be carried in a waist pouch. The computer is equipped with a small screen that can be used to display the incoming signals on each channel. Amplitude and time adjustments of this display can be made easily by use of touch buttons on the screen. The user can also set up a data-acquisition schedule to conform to experimental protocols or to manage battery energy and memory efficiently. Once the EMG data have been recorded, the flash memory card is removed from the EMG apparatus and placed in a flash-memory- card-reading external drive unit connected to a personal computer (PC). The PC can then read the data recorded in the 16 channels. Preferably, before further analysis, the data should be stored in the hard drive of the PC. The data files are opened and viewed on the PC by use of special- purpose software. The software for operation of the apparatus resides in a random-access memory (RAM), with backup power supplied by a small internal lithium cell. A backup copy of this software resides on the flash memory card. In the event of loss of both main and backup battery power and consequent loss of this software, the backup copy can be used to restore the RAM copy after power has been restored. Accessories for this device are also available. These include goniometers, accelerometers, foot switches, and force gauges.

De Luca, Gianluca↗
NASA NTRS1998

Integration of the Remote Agent for the NASA Deep Space One Autonomy Experiment

This paper describes the integration of the Remote Agent (RA), a spacecraft autonomy system which is scheduled to control the Deep Space 1 spacecraft during a flight experiment in 1999. The RA is a reusable, model-based autonomy system that is quite different from software typically used to control an aerospace system. We describe the integration challenges we faced, how we addressed them, and the lessons learned. We focus on those aspects of integrating the RA that were either easier or more difficult than integrating a more traditional large software application because the RA is a model-based autonomous system. A number of characteristics of the RA made integration process easier. One example is the model-based nature of RA. Since the RA is model-based, most of its behavior is not hard coded into procedural program code. Instead, engineers specify high level models of the spacecraft's components from which the Remote Agent automatically derives correct system-wide behavior on the fly. This high level, modular, and declarative software description allowed some interfaces between RA components and between RA and the flight software to be automatically generated and tested for completeness against the Remote Agent's models. In addition, the Remote Agent's model-based diagnosis system automatically diagnoses when the RA models are not consistent with the behavior of the spacecraft. In flight, this feature is used to diagnose failures in the spacecraft hardware. During integration, it proved valuable in finding problems in the spacecraft simulator or flight software. In addition, when modifications are made to the spacecraft hardware or flight software, the RA models are easily changed because they only capture a description of the spacecraft. one does not have to maintain procedural code that implements the correct behavior for every expected situation. On the other hand, several features of the RA made it more difficult to integrate than typical flight software. For example, the definition of correct behavior is more difficult to specify for a system that is expected to reason about and flexibly react to its environment than for a traditional flight software system. Consequently, whenever a change is made to the RA it is more time consuming to determine if the resulting behavior is correct. We conclude the paper with a discussion of future work on the Remote Agent as well as recommendations to ease integration of similar autonomy projects.

Dorais, Gregory A.↗
NASA NTRS1999

The Evolution of Dust in the Multiphase ISM: Grain Destruction Processes

This proposal covered year one of a long term project in which we acquired the necessary hardware and softwaxe needed to calculate grain destruction processes in the interstellar medium (ISM). The long term goal of this research is to develop a model for the dust evolution in the ISM capable of explaining observations of elemental depletions, the grain size distribution, and the emission characteristics of the ISM from the X-ray through the FIR. We purchased a SUN Ultra 10 workstation and peripheral devices including an Exabyte Tape drive, HP Laser Printer, and Seagate External Hard Disk. The PI installed the hardware and Solaris operating system on the workstation and integrated the hardware into the network. Software was also purchased to enable connections to the workstation from a PC (Hummingbird Exceed). Additional freeware required to carry out the proposed program was installed on the system including compilers (g77, gcc, g++), editors (emacs), a markup language (LaTeX), and display programs (WIP, XV, SAOtng). We have also successfully modified the required plot files to work with our system which display the results of grain processing.

Wolfire, Mark↗
NASA NTRS2001

Flight Computer Processing Avionics for Space Station Microgravity Experiments: A Risk Assessment of Commercial Off-the-Shelf Utilization

NASA/Marshall Space Flight Center (MSFC) is continually looking for ways to reduce the costs and schedule and minimize the technical risks during the development of microgravity programs. One of the more prominent ways to minimize the cost and schedule is to use off-the-shelf hardware (OTS). However, the use of OTS often increases the risk. This paper addresses relevant factors considered during the selection and utilization of commercial off-the-shelf (COTS) flight computer processing equipment for the control of space station microgravity experiments. The paper will also discuss how to minimize the technical risks when using COTS processing hardware. Two microgravity experiments for which the COTS processing equipment is being evaluated for are the Equiaxed Dendritic Solidification Experiment (EDSE) and the Self-diffusion in Liquid Elements (SDLE) experiment. Since MSFC is the lead center for Microgravity research, EDSE and SDLE processor selection will be closely watched by other experiments that are being designed to meet payload carrier requirements. This includes the payload carriers planned for the International Space Station (ISS). The purpose of EDSE is to continue to investigate microstructural evolution of, and thermal interactions between multiple dendrites growing under diffusion controlled conditions. The purpose of SDLE is to determine accurate self-diffusivity data as a function of temperature for liquid elements selected as representative of class-like structures. In 1999 MSFC initiated a Center Director's Discretionary Fund (CDDF) effort to investigate and determine the optimal commercial data bus architecture that could lead to faster, better, and lower cost data acquisition systems for the control of microgravity experiments. As part of this effort various commercial data acquisition systems were acquired and evaluated. This included equipment with various form factors, (3U, 6U, others) and equipment that utilized various bus structures, (VME, PC104, STD bus). This evaluation of hardware was performed in conjunction with a trade study that considered over twenty (20) different factors relevant to the selection of an optimum design approach. These factors included; safety, sizing and timing, radiation hardness and single event upset, power consumption, heat dissipation, size and volume, expected service life, maintainability, heritage, operating systems, requirements for software reuse, availability of compatible interface boards, relative cost, schedule, reliability, EMI/EMC factors, "hot swap" capability, standards for conduction cooling, I/O capabilities, unique carrier requirements and operating system considerations. The approach to evaluate Safety as part of this study included a review of the Preliminary Hazard Analysis (PHA) for each of the experiment designs and a determination of how each hazard could be addressed and eliminated when different processors were selected. This included evaluating various design approaches and trade-offs between fault tolerant designs and fail-safe designs in accordance with NSTS 1700.7B. This will include the results of radiation testing where available. Various operating systems, such as VxWorks, Linux, QNX, and Embedded NT are evaluated and the advantages and disadvantages of their utilization are also addressed. Design implementation strategies for the various operating systems are considered and discussed. This paper presents the results and recommendations from this trade study. Preliminary conclusions from this study are that safety concerns from lack or radiation testing on COTS equipment can be addressed by additional testing and design considerations, the PC104 bus provided adequate I/O for the SDLE and EDSE microgravity experiments, and PC104 bus components offered significant advantages over VME and cPCI for weight and space reductions.

Estes, Howard↗
NASA NTRS2006

Infusing Software Assurance Research Techniques into Use

Research in the software engineering community continues to lead to new development techniques that encompass processes, methods and tools. However, a number of obstacles impede their infusion into software development practices. These are the recurring obstacles common to many forms of research. Practitioners cannot readily identify the emerging techniques that may benefit them, and cannot afford to risk time and effort evaluating and trying one out while there remains uncertainty about whether it will work for them. Researchers cannot readily identify the practitioners whose problems would be amenable to their techniques, and, lacking feedback from practical applications, are hard-pressed to gauge the where and in what ways to evolve their techniques to make them more likely to be successful. This paper describes an ongoing effort conducted by a software engineering research infusion team established by NASA s Software Engineering Initiative to overcome these obstacles. .

Pressburger, Thomas↗
NASA NTRS1990

VIPER project

The VIPER project has so far produced a formal specification of a 32 bit RISC microprocessor, an implementation of that chip in radiation-hard SOS technology, a partial proof of correctness of the implementation which is still being extended, and a large body of supporting software. The time has now come to consider what has been achieved and what directions should be pursued in the future. The most obvious lesson from the VIPER project was the time and effort needed to use formal methods properly. Most of the problems arose in the interfaces between different formalisms, e.g., between the (informal) English description and the HOL spec, between the block-level spec in HOL and the equivalent in ELLA needed by the low-level CAD tools. These interfaces need to be made rigorous or (better) eliminated. VIPER 1A (the latest chip) is designed to operate in pairs, to give protection against breakdowns in service as well as design faults. We have come to regard redundancy and formal design methods as complementary, the one to guard against normal component failures and the other to provide insurance against the risk of the common-cause failures which bedevil reliability predictions. Any future VIPER chips will certainly need improved performance to keep up with increasingly demanding applications. We have a prototype design (not yet specified formally) which includes 32 and 64 bit multiply, instruction pre-fetch, more efficient interface timing, and a new instruction to allow a quick response to peripheral requests. Work is under way to specify this device in MIRANDA, and then to refine the spec into a block-level design by top-down transformations. When the refinement is complete, a relatively simple proof checker should be able to demonstrate its correctness. This paper is presented in viewgraph form.

Kershaw, John↗
NASA NTRS1993

SCAILET: An intelligent assistant for satellite ground terminal operations

NASA Lewis Research Center has applied artificial intelligence to an advanced ground terminal. This software application is being deployed as an experimenter interface to the link evaluation terminal (LET) and was named Space Communication Artificial Intelligence for the Link Evaluation Terminal (SCAILET). The high-burst-rate (HBR) LET provides 30-GHz-transmitting and 20-GHz-receiving, 220-Mbps capability for wide band communications technology experiments with the Advanced Communication Technology Satellite (ACTS). The HBR-LET terminal consists of seven major subsystems. A minicomputer controls and monitors these subsystems through an IEEE-488 or RS-232 protocol interface. Programming scripts (test procedures defined by design engineers) configure the HBR-LET and permit data acquisition. However, the scripts are difficult to use, require a steep learning curve, are cryptic, and are hard to maintain. This discourages experimenters from utilizing the full capabilities of the HBR-LET system. An intelligent assistant module was developed as part of the SCAILET software. The intelligent assistant addresses critical experimenter needs by solving and resolving problems that are encountered during the configuring of the HBR-LET system. The intelligent assistant is a graphical user interface with an expert system running in the background. In order to further assist and familiarize an experimenter, an on-line hypertext documentation module was developed and included in the SCAILET software.

Shahidi, A. K.↗
NASA NTRS2005

V and V of ISHM Software for Space Exploration

NASA has established a far-reaching and long-term program for robotic and manned exploration of the solar system, beginning with missions to the moon and Mars. The Crew Transportation System (CTS), a key system for space exploration, imposes four requirements' that ISHM addresses. These requirements have a wide range of implications for V&V and certification of ISHM. There is a range of time-criticality for ISHM actions, from prognostication, which is often (but not always) non-time-critical, to time-critical state estimation and system management under off-nominal emergency conditions. These are externally imposed requirements on ISHM that are subject to V&V. - In addition, a range of techniques are needed to implement an ISHM. The approaches to ISHM are described elsewhere. These approaches range from well-understood algorithms for low-level data analysis, validation and reporting, to AI techniques for state estimation and planning. The range of techniques, and specifically the use of AI techniques such as reasoning under uncertainty and mission planning (and re-planning), implies that several V&V approaches may be required. Depending on the ISHM architecture, traditional testing approaches may be adequate for some ISHM functionality. The AI-based approaches to reasoning under uncertainty, model-based reasoning, and planning share characteristics typical of other complex software systems, but they also have characteristics that set them apart and challenge standard V&V techniques. The range of possible solutions to the overall ISHM problem impose internal challenges to V&V. The V&V challenges increase when hard real-time constraints are imposed for time-critical functionality. For example, there is an external requirement that impending catastrophic failure of the Launch Vehicle (LV) at launch time be detected and life-saving action be taken within two seconds. In this paper we outline the challenges for ISHM V&V, existing approaches and analogs in other software application areas, and possible new approaches to the V&V challenges for space exploration ISHM.

Markosian, Lawrence↗
NASA NTRS1993

Mongoose ASIC microcontroller programming guide

The 'Mongoose' ASIC microcontroller is a radiation-hard implementation of the R3000 microprocessor. This document describes the internals of the microcontroller in a level of detail necessary for someone implementing a software design.

Smith, Brian S.↗
NASA NTRS1991

Electronic Still Camera Project on STS-48

On behalf of NASA, the Office of Commercial Programs (OCP) has signed a Technical Exchange Agreement (TEA) with Autometric, Inc. (Autometric) of Alexandria, Virginia. The purpose of this agreement is to evaluate and analyze a high-resolution Electronic Still Camera (ESC) for potential commercial applications. During the mission, Autometric will provide unique photo analysis and hard-copy production. Once the mission is complete, Autometric will furnish NASA with an analysis of the ESC s capabilities. Electronic still photography is a developing technology providing the means by which a hand held camera electronically captures and produces a digital image with resolution approaching film quality. The digital image, stored on removable hard disks or small optical disks, can be converted to a format suitable for downlink transmission, or it can be enhanced using image processing software. The on-orbit ability to enhance or annotate high-resolution images and then downlink these images in real-time will greatly improve Space Shuttle and Space Station capabilities in Earth observations and on-board photo documentation.

Source record↗
NASA NTRS1991

Frequency domain identification for robust large space structure control design

A methodology is demonstrated for frequency domain identification of large space structures which systematically transforms experimental raw data into a form required for synthesizing H(infinity) controllers using modern robust control design software (e.g., Matlab Toolboxes). A unique feature of this approach is that the additive uncertainty is characterized to a specified statistic confidence rather than with hard bounds. In this study, the difference in robust performance is minimal between the two levels of confidence. In general cases, the present methodology provides a tool for performance/confidence level tradeoff studies. For simplicity, the additive uncertainty on a frequency grid is considered and the interpolation error in between grid points is neglected.

Yam, Y.↗
NASA NTRS1992

Architecture for Survivable Systems Processing (ASSP). Technology benefits for Open System Interconnects

The Architecture for Survivable Systems Processing (ASSP) program is a two phase program whose objective is the derivation, specification, development and validation of an open system architecture capable of supporting advanced processing needs of space, ground, and launch vehicle operations. The output of the first phase is a set of hardware and software standards and specifications defining this architecture at three levels. The second phase will validate these standards and develop the technology necessary to achieve strategic hardness, packaging density, throughput requirements, and interoperability/interchangeability.

Wood, Richard J.↗
NASA NTRS1995

Electronic collection system for spacelab mission timeline requirements

This paper describes the Functional Objective Requirements Collection System (FORCS) software tool that has been developed for use by Principal Investigators (PI's) and Payload Element Developers (PED's) on their own personal computers to develop on-orbit timelining requirements for their payloads. The FORCS tool can be used either in a totally stand-alone mode, storing the information in a local file on the user's personal computer hard disk or in a remote mode where the user's computer is linked to a host computer containing the integrated database of the timeline requirements for all of the payloads on a mission. There are a number of features incorporated in the FORCS software to assist the user. The user may move freely back and forth between the various forms for inputting the data. Several methods are used to input the information, depending on the type of the information. These methods range from filling in text boxes, using check boxes and radio buttons, to inputting information into a spreadsheet format. There are automated features provided to assist in developing the proper format for the data, ranging from limit checking on some of the parameters to automatic conversion of different formats of time data inputs to the one standard format used for the timeline scheduling software.

Lindberg, James P.↗