SEARCH · Search NASA
Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.
Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.
The structure of the device independent Display Management Subsystem (DMS) and the interface routines that are available to the applications programmer for use in developing a set of portable image display utility programs are described.
The structure of the device independent Display Management Subsystem (DMS) and the interface routines that are available to the applications programmer for use in developing a set of portable image display utility programs are described.
NASA's Goddard Space Flight Center (GSFC) has developed a Transportable Applications Executive (TAE) for use in implementing portable applications software that can be shared by different research projects. Since many of the supported disciplines require the interactive display and manipulation of remotely sensed images, a device independent Display Management Subsystem (DMS) was written as a TAE extension. The DMS attempts to abstract and standardize the device dependent functions that are used in the display and manipulation of image data on image analysis terminals. This paper explores the concept of DMS and the interface routines that are available to the applications programmer for use in developing a set of portable image display utility programs.
The Life Sciences Project Division (LSPD) at JSC, which manages human life sciences flight experiments for the NASA Life Sciences Division, augmented its Life Sciences Data System (LSDS) in support of the Spacelab Life Sciences-2 (SLS-2) mission, October 1993. The LSDS is a portable ground system supporting Shuttle, Spacelab, and Mir based life sciences experiments. The LSDS supports acquisition, processing, display, and storage of real-time experiment telemetry in a workstation environment. The system may acquire digital or analog data, storing the data in experiment packet format. Data packets from any acquisition source are archived and meta-parameters are derived through the application of mathematical and logical operators. Parameters may be displayed in text and/or graphical form, or output to analog devices. Experiment data packets may be retransmitted through the network interface and database applications may be developed to support virtually any data packet format. The user interface provides menu- and icon-driven program control and the LSDS system can be integrated with other workstations to perform a variety of functions. The generic capabilities, adaptability, and ease of use make the LSDS a cost-effective solution to many experiment data processing requirements. The same system is used for experiment systems functional and integration tests, flight crew training sessions and mission simulations. In addition, the system has provided the infrastructure for the development of the JSC Life Sciences Data Archive System scheduled for completion in December 1994.
Model based program design is the most clear and direct way to develop algorithms and programs for interfacing with hardware. While coding "by hand" results in a more tailored product, the ever-growing size and complexity of modern-day applications can cause the project work load to quickly become unreasonable for one programmer. This has generally been addressed by splitting the product into separate modules to allow multiple developers to work in parallel on the same project, however this introduces new potentials for errors in the process. The fluidity, reliability and robustness of the code relies on the abilities of the programmers to communicate their methods to one another; furthermore, multiple programmers invites multiple potentially differing coding styles into the same product, which can cause a loss of readability or even module incompatibility. Fortunately, Mathworks has implemented an auto-coding feature that allows programmers to design their algorithms through the use of models and diagrams in the graphical programming environment Simulink, allowing the designer to visually determine what the hardware is to do. From here, the auto-coding feature handles converting the project into another programming language. This type of approach allows the designer to clearly see how the software will be directing the hardware without the need to try and interpret large amounts of code. In addition, it speeds up the programming process, minimizing the amount of man-hours spent on a single project, thus reducing the chance of human error as well as project turnover time. One such project that has benefited from the auto-coding procedure is Ramses, a portion of the GNC flight software on-board Orion that has been implemented primarily in Simulink. Currently, however, auto-coding Ramses into C++ requires 5 hours of code generation time. This causes issues if the tool ever needs to be debugged, as this code generation will need to occur with each edit to any part of the program; additionally, this is lost time that could be spent testing and analyzing the code. This is one of the more prominent issues with the auto-coding process, and while much information is available with regard to optimizing Simulink designs to produce efficient and reliable C++ code, not much research has been made public on how to reduce the code generation time. It is of interest to develop some insight as to what causes code generation times to be so significant, and determine if there are architecture guidelines or a desirable auto-coding configuration set to assist in streamlining this step of the design process for particular applications. To address the issue at hand, the Simulink coder was studied at a foundational level. For each different component type made available by the software, the features, auto-code generation time, and the format of the generated code were analyzed and documented. Tools were developed and documented to expedite these studies, particularly in the area of automating sequential builds to ensure accurate data was obtained. Next, the Ramses model was examined in an attempt to determine the composition and the types of technologies used in the model. This enabled the development of a model that uses similar technologies, but takes a fraction of the time to auto-code to reduce the turnaround time for experimentation. Lastly, the model was used to run a wide array of experiments and collect data to obtain knowledge about where to search for bottlenecks in the Ramses model. The resulting contributions of the overall effort consist of an experimental model for further investigation into the subject, as well as several automation tools to assist in analyzing the model, and a reference document offering insight to the auto-coding process, including documentation of the tools used in the model analysis, data illustrating some potential problem areas in the auto-coding process, and recommendations on areas or practices in the current Ramses model that should be further investigated. Several skills were required to be built up over the course of the internship project. First and foremost, my Simulink skills have improved drastically, as much of my experience had been modeling electronic circuits as opposed to software models. Furthermore, I am now comfortable working with the Simulink Auto-coder, a tool I had never used until this summer; this tool also tested my critical thinking and C++ knowledge as I had to interpret the C++ code it was generating and attempt to understand how the Simulink model affected the generated code. I had come into the internship with a solid understanding of Matlab code, but had done very little in using it to automate tasks, particularly Simulink tasks; along the same lines, I had rarely used shell script to automate and interface with programs, which I gained a fair amount of experience with this summer, including how to use regular expression. Lastly, soft-skills are an area everyone can continuously improve on; having never worked with NASA engineers, which to me seem to be a completely different breed than what I am used to (commercial electronic engineers), I learned to utilize the wealth of knowledge present at JSC. I wish I had come into the internship knowing exactly how helpful everyone in my branch would be, as I would have picked up on this sooner. I hope that having gained such a strong foundation in Simulink over this summer will open the opportunity to return to work on this project, or potentially other opportunities within the division. The idea of leaving a project I devoted ten weeks to is a hard one to cope with, so having the chance to pick up where I left off sounds appealing; alternatively, I am interested to see if there are any opening in the future that would allow me to work on a project that is more in-line with my research in estimation algorithms. Regardless, this summer has been a milestone in my professional career, and I hope this has started a long-term relationship between JSC and myself. I really enjoy the thought of building on my experience here over future summers while I work to complete my PhD at Missouri University of Science and Technology.
My experience working on the Small Payload Launch Integrated Testing Services project has been both educational and rewarding. I have been given the opportunity to work on and experiment with a number of exciting projects and initiatives, each offering different challenges and opportunities for teamwork and collaboration. One of my assignments is to aid in the design and construction of a small-scale two stage rocket as part of a Rocket University initiative. My duties include programming a microcontroller to control the various sensors on the rocket as well as process and transmit data. Additionally, I am writing a graphical user interface application for the ground station that will receive the transmitted data from the rocket and display the information on screen along with a 3D rendering displaying the rocket orientation. Another project I am working on is to design and develop the avionics that will be used to control a high altitude balloon flight that will test a sensor called a Micro Dosimeter that will measure the total ionizing dose absorbed by electrical components during a flight. This includes assembling and soldering the various sensors and components, programming a microcontroller to input and process data from the Micro Dosimeter, and transmitting the data down to a ground station as well as save the data to an on-board SD card. Additionally, I am aiding in the setup and development of ITOS (Integrated Test and Operations System) capability in the SPSDL (Spaceport Processing System Development Lab).
The approach used to estimate costs for the Space Station Furnace Facility (SSFF) is based on a computer program developed internally at Teledyne Brown Engineering (TBE). The program produces time-phased estimates of cost elements for each hardware component, based on experience with similar components. Engineering estimates of the degree of similarity or difference between the current project and the historical data is then used to adjust the computer-produced cost estimate and to fit it to the current project Work Breakdown Structure (WBS). The SSFF Concept as presented at the Requirements Definition Review (RDR) was used as the base configuration for the cost estimate. This program incorporates data on costs of previous projects and the allocation of those costs to the components of one of three, time-phased, generic WBS's. Input consists of a list of similar components for which cost data exist, number of interfaces with their type and complexity, identification of the extent to which previous designs are applicable, and programmatic data concerning schedules and miscellaneous data (travel, off-site assignments). Output is program cost in labor hours and material dollars, for each component, broken down by generic WBS task and program schedule phase.
In order to develop quality control software for multiple robots, a common interface is required. By developing components in a modular fashion with well-defined boundaries, roboticists can write code to program a generic rover, and only require very simple modifications to run on any robot with a properly implemented framework. The proposed framework advances a Generic Rover that could be any rover, from Real World Interface's All Terrain Robot Vehicle Jr. series to the Fido-class rovers from the Jet Propulsion Laboratory to any other research robot. Using these generic hardware interfaces, software designers and engineers can concentrate on the actual code, and not have to worry about hardware details. In addition to the hardware support framework, three sample applications have been developed to demonstrate the flexibility and extensibility of the framework.
A computerized procedure for symbolic manipulations and FORTRAN code generation of elastoplastic material matrix for finite element applications is presented. Special emphasis is placed on expression simplifications during intermediate derivations, optimal code generation, and interface with the main program. A systematic procedure is outlined to avoid redundant algebraic manipulations. Symbolic expressions of the derived material stiffness matrix are automatically converted to RATFOR code which is then translated into FORTRAN statements through a preprocessor. To minimize the interface problem with the main program, a template file is prepared so that the translated FORTRAN statements can be merged into the file to form a subroutine (or a submodule). Three constitutive models; namely, von Mises plasticity, the Drucker-Prager model, and a concrete plasticity model, are used as illustrative examples.
A computerized procedure for symbolic manipulations and FORTRAN code generation of an elasto-plastic material matrix for finite element applications is presented. Special emphasis is placed on expression simplifications during intermediate derivations, optimal code generation, and interface with the main program. A systematic procedure is outlined to avoid redundant algebraic manipulations. Symbolic expressions of the derived material stiffness matrix are automatically converted to RATFOR code which is then translated into FORTRAN statements through a preprocessor. To minimize the interface problem with the main program, a template file is prepared so that the translated FORTRAN statements can be merged into the file to form a subroutine (or a submodule). Three constitutive models; namely, von Mises plasticity, Drucker-Prager model, and a concrete plasticity model, are used as illustrative examples.
A special system was fabricated to properly calibrate the wireless inclinometer, a new device that will measure the Orbiter s hang angle. The wireless inclinometer has a unique design and method of attachment to the Orbiter that will improve the accuracy of the measurements, as well as the safety and ease of the operation. The system properly calibrates the four attached inclinometers, in both the horizontal and vertical axes, without needing to remove any of the component parts. The Wireless Inclinometer Calibration System combines (1) a calibration fixture that emulates the point of attachment to the Orbiter in both the horizontal and vertical axes and the measurement surfaces, (2) an application-specific software program that accepts calibration data such as dates, zero functions, or offsets and tables, and (3) a wireless interface module that enables the wireless inclinometer to communicate with a calibration PC.
NASA is seeking an operating system interface definition (OSID) for the Space Station Program (SSP) in order to take advantage of the commercial off-the-shelf (COTS) products available today and the many that are expected in the future. NASA would also like to avoid the reliance on any one source for operating systems, information system, communication system, or instruction set architecture. The use of the Portable Operating System Interface for Computer Environments (POSIX) is examined as a possible solution to this problem. Since Ada is already the language of choice for SSP, the question of an Ada/POSIX binding is addressed. The intent of the binding is to provide access to the POSIX standard operation system (OS) interface and environment, by which application portability of Ada applications will be supported at the source code level. A guiding principle of Ada/POSIX binding development is a clear conformance of the Ada interface with the functional definition of POSIX. The interface is intended to be used by both application developers and system implementors. The objective is to provide a standard that allows a strictly conforming application source program that can be compiled to execute on any conforming implementation. Special emphasis is placed on first providing those functions and facilities that are needed in a wide variety of commercial applications
It is the goal of Moon to Mars (M2M) to establish a single consolidated set of safety requirements and a safety review process for utilization payloads that will cross program vehicle hatches or operate externally on multiple program vehicles during transport or operation that satisfies Exploration Ground Systems (EGS), Orion, EVA, and Human Surface Mobility Program (EHP), Gateway (GW), and Human Landing System (HLS) programs. This document defines the Cross Program Utilization Payload (xPUP) safety review process for mission effectivity of Artemis III and beyond. This review process will help ensure protection of the overall Moon to Mars integrated system from potential hazards created by cross program payloads that either cross a program vehicle hatch or can interface with more than one M2M lunar exploration program vehicle. The process will identify payload hazards and controls that will protect ground personnel, flight crew, the integrated vehicle, ground equipment, or facilities. This process is also applicable to samples that cross hatches between vehicles including for return to Earth. The xPUP safety review process will be led by one of the M2M programs' integration safety panels, chosen on a per-payload basis. After the lead integration safety panel is determined, the common safety process is established, based on pre-determined criteria, which includes ad-hoc members from other stakeholder programs. Stakeholder programs are those that interface with the utilization payload in any way (e.g., operating on a lunar exploration vehicle or crossing program vehicle hatches). The xPUP will execute this safety review process for flight and ground utilization payload hardware design, its ground support equipment, and landing and recovery in accordance with the applicable safety requirements as specified in M2M-30043: Moon to Mars Cross Program Utilization Payload Safety Requirements. The xPUP safety process will follow the lead integration safety panel’s safety process requirements. Formal agreements will be communicated with the payload developer using the payload integration processes documented in M2M-30037, Artemis Payload Integration Implementation Plan.
The Hyperspectral Microwave Atmospheric Sounder (HyMAS) is being developed at Lincoln Laboratories and accommodated by the Goddard Space Flight Center for a flight opportunity on a NASA research aircraft. The term "hyperspectral microwave" is used to indicate an all-weather sounding that performs equivalent to hyperspectral infrared sounders in clear air with vertical resolution of approximately 1 km. Deploying the HyMAS equipped scanhead with the existing Conical Scanning Microwave Imaging Radiometer (CoSMIR) shortens the path to a flight demonstration. Hyperspectral microwave is achieved through the use of independent RF antennas that sample the volume of the Earth s atmosphere through various levels of frequencies, thereby producing a set of dense, spaced vertical weighting functions. The simulations proposed for HyMAS 118/183-GHz system should yield surface precipitation rate and water path retrievals for small hail, soft hail, or snow pellets, snow, rainwater, etc. with accuracies comparable to those of the Advanced Technology Microwave Sounder. Further improvements in retrieval methodology (for example, polarization exploitation) are expected. The CoSMIR instrument is a packaging concept re-used on HyMAS to ease the integration features of the scanhead. The HyMAS scanhead will include an ultra-compact Intermediate Frequency Processor (IFP) module that is mounted inside the door to improve thermal management. The IFP is fabricated with materials made of Low-Temperature Co-fired Ceramic (LTCC) technology integrated with detectors, amplifiers, A/D conversion and data aggregation. The IFP will put out 52 channels of 16 bit data comprised of 4-9 channel data streams for temperature profiles and 2-8 channel streams for water vapor. With the limited volume of the existing CoSMIR scanhead and new HyMAS front end components, the HyMAS team at Goddard began preliminary layout work inside the new drum. Importing and re-using models of the shell, the scan head computer, and the slip rings developed for CoSMIR was the starting point. The next step was to modify the antenna faceplate to accommodate the dimensions of the three dual polarization Gaussian Optics Antenna (GOA) assemblies. Two mechanical concepts for the core technology, the hyperspectral IFP, were captured in a design tradeoff. Connector models considered minimum bend radii for the IFP analog connectors. Hyperspectral imaging is accomplished by strategically using a short wavelength intermediate frequency of 18-29 GHz, and thus reducing the size of components in the connection of the front end to the IFP. The SMK (2.92mm) Series connector will lay near the hinge line to minimize its flexing. The digital output of the IFP will use a Serial Peripheral Interface (SPI) that must be accommodated by the scan head computer. To make that computer more reliable, maintainable, and forward compatible with the 52 HyMAS channels, a testbed of the scan head, calibration, and archive computers and the PIC24 microprocessor that resides on the IFP is in development. The computers will be programmed using a new framework application called Interoperable Remote Component (IRC). This software allows flexibility to program computers that communicate with each other and can adapt easily to the emerging HyMAS requirements for data format, algorithms, and graphical user interface (GUI). It is expected that the CoSMIR instrument will cut over to the IRC after it is adapted on an updated CoSMIR testbed.
The X-37 is a technology demonstrator sponsored by NASA. It includes a number of experiments both imbedded (i.e., essential aspects of the vehicle) and separate. The technologies demonstrated will be useful in future operational versions as well as having broad applications to other programs. Mr. James R. French, of JRF Engineering Services and as a consultant to SAIC, has provided technical support to the X-37 NASA Program office since the beginning of the program. In providing this service, Mr. French has maintained close contact with the Boeing Seal Beach and Rocketdyne technical teams via telephone, e-mail, and periodic visits. His interfaces were primarily with the working engineers in order to provide NASA sponsors with a different view than that achieved through management channels. Mr. French's periodic and highly detailed technical reports were submitted to NASA and SAIC (Science Applications International Corporation) on a weekly/monthly basis. These reports addressed a wide spectrum of programmatic and technical interests related to the X-37 Program including vehicle design, flight sciences, propulsion, thermal protection, Guidance Navigation & Control (GN&C), structures, and operations. This deliverable is presented as a consolidation of the twelve monthly reports submitted during the Contract's Option Year,
In this paper we describe how to apply powerful performance analysis techniques to understand the behavior of multilevel parallel applications. We use the Paraver/OMPItrace performance analysis system for our study. This system consists of two major components: The OMPItrace dynamic instrumentation mechanism, which allows the tracing of processes and threads and the Paraver graphical user interface for inspection and analyses of the generated traces. We describe how to use the system to conduct a detailed comparative study of a benchmark code implemented in five different programming paradigms applicable for shared memory
Consumables analysis/crew training simulator interface requirements were defined. Two aspects were investigated: consumables analysis support techniques to crew training simulator for advanced spacecraft programs, and the applicability of the above techniques to the crew training simulator for the space shuttle program in particular.
The advantages of performing the partition and countercurrent distribution (CCD) of cells in phase separated aqueous polymer systems under reduced gravity were assessed. Other possible applications considered for the space processing program include the freezing front separation of cells, adsorption of cells at the air-water interface, and the macrophage electrophoretic mobility test for cancer.