Search NASA⌕ Search

SEARCH · Search NASA

Results for “application programming interface”

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 829 records · Page 46

Link Winds: A visual data analysis system and its application to the atmospheric ozone depletion problem

The Linked Windows Interactive Data System (LinkWinds) is a prototype visual data exploration system resulting from a NASA Jet Propulsion Laboratory (JPL) program of research into the application of graphical methods for rapidly accessing, displaying, and analyzing large multi variate multidisciplinary data sets. Running under UNIX it is an integrated multi-application executing environment using a data-linking paradigm to dynamically interconnect and control multiple windows containing a variety of displays and manipulators. This paradigm, resulting in a system similar to a graphical spreadsheet, is not only a powerful method for organizing large amounts of data for analysis, but leads to a highly intuitive, easy-to-learn user interface. It provides great flexibility in rapidly interacting with large masses of complex data to detect trends, correlations, and anomalies. The system, containing an expanding suite of non-domain-specific applications, provides for the ingestion of a variety of data base formats and hard -copy output of all displays. Remote networked workstations running LinkWinds may be interconnected, providing a multiuser science environment (MUSE) for collaborative data exploration by a distributed science team. The system is being developed in close collaboration with investigators in a variety of science disciplines using both archived and real-time data. It is currently being used to support the Microwave Limb Sounder (MLS) in orbit aboard the Upper Atmosphere Research Satellite (UARS). This paper describes the application of LinkWinds to this data to rapidly detect features, such as the ozone hole configuration, and to analyze correlations between chemical constituents of the atmosphere.

Jacobson, Allan S.↗

Cryogenic Propellant Long-Term Storage With Zero Boil-Off

Significant boil-off losses from cryogenic propellant storage systems in long-duration space mission applications result in additional propellant and larger tanks. The potential propellant mass loss reductions with the Zero Boil-off (ZBO) concept are substantial; therefore, further exploration through technology programs has been initiated within NASA. A large-scale demonstration of the ZBO concept has been devised utilizing the Marshall Space Flight Center (MSFC) Multipurpose Hydrogen Test Bed (MHTB) along with a cryo-cooler unit. The ZBO concept consists of an active cryo-cooling system integrated with traditional passive thermal insulation. The cryo-cooler is interfaced with the MHTB and spraybar recirculation/mixer system in a manner that enables thermal energy removal at a rate that equals the total tank heat leak. The liquid hydrogen (LH2) is withdrawn from the tank, passed through a heat exchanger, and then the chilled liquid is sprayed back into the tank through a spraybar. The test series will be performed over a 20-30 day period. Tests will be conducted at multiple fill levels to demonstrate concept viability and to provide benchmark data to be used in analytical model development. In this paper the test set-up and test procedures are presented.

Hedayat, Ali↗

Advanced Software Development Workstation Project

The Advanced Software Development Workstation Project, funded by Johnson Space Center, is investigating knowledge-based techniques for software reuse in NASA software development projects. Two prototypes have been demonstrated and a third is now in development. The approach is to build a foundation that provides passive reuse support, add a layer that uses domain-independent programming knowledge, add a layer that supports the acquisition of domain-specific programming knowledge to provide active support, and enhance maintainability and modifiability through an object-oriented approach. The development of new application software would use specification-by-reformulation, based on a cognitive theory of retrieval from very long-term memory in humans, and using an Ada code library and an object base. Current tasks include enhancements to the knowledge representation of Ada packages and abstract data types, extensions to support Ada package instantiation knowledge acquisition, integration with Ada compilers and relational databases, enhancements to the graphical user interface, and demonstration of the system with a NASA contractor-developed trajectory simulation package. Future work will focus on investigating issues involving scale-up and integration.

Lee, Daniel↗

Analysis of Launch Vehicle Liftoff Debris: Historical Perspective from Space Shuttle and Application to Artemis I

Human exploration-class launch vehicles are inherently prone to debris due to the extreme environments generated during pre-launch operations, liftoff, and flight. The use of cryogenic propellants often requires thermal protection system (TPS) coatings, typically foam, to maintain the propellant conditions in the tank and prevent an accumulation ice on the external surface of the vehicle. Some ice growth is to be expected at umbilical interfaces, vents, flanges, or brackets where it is difficult to apply TPS. This ice may come loose at any time due to wind on the launch pad, structural vibration and acoustics after rocket ignition, or aerodynamic forces during flight. This phenomena is especially apparent on vehicles with no TPS, such as the Saturn V rockets used in the Apollo Program, see Figure 1. During propellant tanking, the thermal contraction of the underlying substrate may generate cracks in the TPS (Figure 1). Chunks of TPS can release due to the expansion of ingested gas from cryopumping or from aerodynamic forces if the crack creates an offset surface. Most foams will also have a certain amount of “popcorning” where small pieces of foam will pop off during flight because of the differential between the static surface pressure and the pressure of the gas trapped in the foam cell structure. There are a number of other coating or closeout materials that may be shed from the vehicle and become debris. During pre-launch operations and liftoff, the vehicle may also be exposed to debris originating from the launch pad or ground support equipment. This debris is separate from foreign object debris, or FOD, which is not intended to be present and is strictly controlled through operations and maintenance procedures. In this case, debris is generated from hardware and materials that are necessary for launch and are subject to the intense vibration, acoustics, and direct plume impingement of the launch environment. Examples include ice from umbilicals, tape and tie wraps that protect cables, and rust or corrosion from the launch platform. While NASA has historically been aware of debris as a potential issue that could cause a failure resulting in loss of mission, loss of vehicle, or loss of crew, the likelihood and severity of that risk was not always well understood or given sufficient weight in program and flight decisions. After the Space Shuttle Columbia accident (STS-107), the investigation found that foam TPS debris shed from the external tank was the proximate cause of the damage to the orbiter wing. Six previous observations of debris released from the foam ramp that covered the bipod connecting the forward end of the orbiter to the external tank resulted in minor changes or were determined to be accepted flight risks. Two occurrences of bipod ramp foam loss were not identified until the STS-107 investigation. Despite the damage inflicted by these debris strikes, the Shuttle Program Requirements Control Board deemed the vehicle safe to fly. During the Return to Flight effort following the Columbia disaster, NASA Engineering developed a process for the assessment of debris transport, impact, and damage tolerance to support independent assessments of risk by NASA Safety and Mission Assurance (S&MA). Under this system, each element (vehicle or ground system) defines a catalog of all expected debris based on launch history, component testing, or analysis. Debris transport analysis (DTA) is conducted using the debris catalog characteristics and potential flow transport mechanisms (e.g., vehicle aerodynamics, gravity, wind, plume-driven). The predicted debris impact locations and velocities are provided to the hardware owners, who use available test data and analysis to determine whether each component can withstand the impacts. In cases where the element hardware may be severely damaged or fail, the options are to mitigate the debris source through some change in design or operation, or to work with S&MA to try to characterize the probability of the impact and damage for program risk acceptance. Because of the differences in debris characteristics and transport, the DTA has been divided between the Liftoff and Ascent regimes. The development and application of Liftoff DTA methodology from the Shuttle Program to the current Artemis Program is the subject of this paper. Liftoff DTA covers the time from the start of pre-launch operations at the launch pad, up until the vehicle clears the launch tower and there is no longer any interaction with ground systems. Debris transport during this period is broadly classified as either gravity, wind, and plume-entrained (GWPE) or plume driven (PD). GWPE debris is generally lower speed, travelling in a forward-to-aft direction. PD transport includes flow features from the rocket ignition transient, as well as plume impingement and recirculation that occur as the vehicle lifts off the launch platform. In these cases, the debris typically moves in an aft-to-forward direction at higher speeds. The applicable transport mechanisms must be considered for each piece of debris depending on the material, and release location and time. For example, rust or metallic debris from the tower could fall (GWPE) and impact the vehicle before landing on the launch platform deck where it could be also be transported by plume impingement (PD). However, falling ice (GWPE) from an umbilical is unlikely to survive impact with the vehicle or launch platform and be available for PD transport. Modeling of debris transport is accomplished using a set of DTA tools which simulate debris trajectories subject to a reference frame acceleration (i.e., gravity) and aerodynamic drag. Where the trajectory encounters a solid surface, the debris is allowed to rebound with a specified coefficient of restitution. The drag is calculated by interpolating the fluid state at each point in the debris trajectory from high-fidelity computational fluid dynamics (CFD) simulations of the launch vehicle and pad. The CFD data may either be static (steady state or time averaged), typically for GWPE transport, or dynamic (time-accurate) for PD flow features like the ignition transient. Examples of the CFD flow field solutions for the Space Launch System (SLS) rocket and launch pad are shown in Figure 2. Typical SLS debris trajectory predictions from DTA are illustrated in Figure 3. The final version of this paper will include a more detailed examination of the Liftoff DTA process developed during the Shuttle Program, and how it has been augmented and applied to the SLS rocket under the Artemis Program. Comparisons with debris observations from the Artemis I launch will demonstrate validation of the tools and methodology.

Debris↗

Microgravity Science and Application Program tasks, 1989 revision

The active research tasks, as of the fiscal year 1989, of the Microgravity Science and Applications Program, NASA Office of Space Science and Applications, involving several NASA Centers and other organizations are compiled. The purpose is to provide an overview of the program scope for managers and scientists in industry, university, and government communities. The scientists in industry, university, and government communities. An introductory description of the program, the strategy and overall goal, identification of the organizational structures and people involved, and a description of each task are included. Also provided is a list of recent publications. The tasks are grouped into several major categories: electronic materials, solidification of metals, alloys, and composites; fluids, interfaces, and transport; biotechnology; glasses and ceramics; combustion science; physical and chemistry experiments (PACE); and experimental technology, facilities, and instrumentation.

Source record↗

Intelligent Systems and Advanced User Interfaces for Design, Operation, and Maintenance of Command Management Systems

Historically Command Management Systems (CMS) have been large, expensive, spacecraft-specific software systems that were costly to build, operate, and maintain. Current and emerging hardware, software, and user interface technologies may offer an opportunity to facilitate the initial formulation and design of a spacecraft-specific CMS as well as a to develop a more generic or a set of core components for CMS systems. Current MOC (mission operations center) hardware and software include Unix workstations, the C/C++ and Java programming languages, and X and Java window interfaces representations. This configuration provides the power and flexibility to support sophisticated systems and intelligent user interfaces that exploit state-of-the-art technologies in human-machine systems engineering, decision making, artificial intelligence, and software engineering. One of the goals of this research is to explore the extent to which technologies developed in the research laboratory can be productively applied in a complex system such as spacecraft command management. Initial examination of some of the issues in CMS design and operation suggests that application of technologies such as intelligent planning, case-based reasoning, design and analysis tools from a human-machine systems engineering point of view (e.g., operator and designer models) and human-computer interaction tools, (e.g., graphics, visualization, and animation), may provide significant savings in the design, operation, and maintenance of a spacecraft-specific CMS as well as continuity for CMS design and development across spacecraft with varying needs. The savings in this case is in software reuse at all stages of the software engineering process.

Mitchell, Christine M.↗

Progress in Computational Simulation of Earthquakes

GeoFEST(P) is a computer program written for use in the QuakeSim project, which is devoted to development and improvement of means of computational simulation of earthquakes. GeoFEST(P) models interacting earthquake fault systems from the fault-nucleation to the tectonic scale. The development of GeoFEST( P) has involved coupling of two programs: GeoFEST and the Pyramid Adaptive Mesh Refinement Library. GeoFEST is a message-passing-interface-parallel code that utilizes a finite-element technique to simulate evolution of stress, fault slip, and plastic/elastic deformation in realistic materials like those of faulted regions of the crust of the Earth. The products of such simulations are synthetic observable time-dependent surface deformations on time scales from days to decades. Pyramid Adaptive Mesh Refinement Library is a software library that facilitates the generation of computational meshes for solving physical problems. In an application of GeoFEST(P), a computational grid can be dynamically adapted as stress grows on a fault. Simulations on workstations using a few tens of thousands of stress and displacement finite elements can now be expanded to multiple millions of elements with greater than 98-percent scaled efficiency on over many hundreds of parallel processors (see figure).

Donnellan, Andrea↗

Applying Standard Interfaces to a Process-Control Language

A method of applying open-operating-system standard interfaces to the NASA User Interface Language (UIL) has been devised. UIL is a computing language that can be used in monitoring and controlling automated processes: for example, the Timeliner computer program, written in UIL, is a general-purpose software system for monitoring and controlling sequences of automated tasks in a target system. In providing the major elements of connectivity between UIL and the target system, the present method offers advantages over the prior method. Most notably, unlike in the prior method, the software description of the target system can be made independent of the applicable compiler software and need not be linked to the applicable executable compiler image. Also unlike in the prior method, it is not necessary to recompile the source code and relink the source code to a new executable compiler image. Abstraction of the description of the target system to a data file can be defined easily, with intuitive syntax, and knowledge of the source-code language is not needed for the definition.

Berthold, Richard T.↗

Ground Operations Autonomous Control and Integrated Health Management

An intelligent autonomous control capability has been developed and is currently being validated in ground cryogenic fluid management operations. The capability embodies a physical architecture consistent with typical launch infrastructure and control systems, augmented by a higher level autonomous control (AC) system enabled to make knowledge-based decisions. The AC system is supported by an integrated system health management (ISHM) capability that detects anomalies, diagnoses causes, determines effects, and could predict future anomalies. AC is implemented using the concept of programmed sequences that could be considered to be building blocks of more generic mission plans. A sequence is a series of steps, and each executes actions once conditions for the step are met (e.g. desired temperatures or fluid state are achieved). For autonomous capability, conditions must consider also health management outcomes, as they will determine whether or not an action is executed, or how an action may be executed, or if an alternative action is executed instead. Aside from health, higher level objectives can also drive how a mission is carried out. The capability was developed using the G2 software environment (www.gensym.com) augmented by a NASA Toolkit that significantly shortens time to deployment. G2 is a commercial product to develop intelligent applications. It is fully object oriented. The core of the capability is a Domain Model of the system where all elements of the system are represented as objects (sensors, instruments, components, pipes, etc.). Reasoning and decision making can be done with all elements in the domain model. The toolkit also enables implementation of failure modes and effects analysis (FMEA), which are represented as root cause trees. FMEA's are programmed graphically, they are reusable, as they address generic FMEA referring to classes of subsystems or objects and their functional relationships. User interfaces for integrated awareness by operators have been created.

Figueroa, Fernando↗

International Docking Standard (IDSS) Interface Definition Document (IDD) : Revision - E

This International Docking System Standard (IDSS) Interface Definition Document (IDD) is the result of a collaboration by the International Space Station membership to establish a standard docking interface to enable on-orbit crew rescue operations and joint collaborative endeavors utilizing different spacecraft. This IDSS IDD details the physical geometric mating interface and design loads requirements. The physical geometric interface requirements must be strictly followed to ensure physical spacecraft mating compatibility. This includes both defined components and areas that are void of components. The IDD also identifies common design parameters as identified in section 3.0, e.g., docking initial conditions and vehicle mass properties. This information represents a recommended set of design values enveloping a broad set of design reference missions and conditions, which if accommodated in the docking system design, increases the probability of successful docking between different spacecraft. This IDD does not address operational procedures or off-nominal situations, nor does it dictate implementation or design features behind the mating interface. It is the responsibility of the spacecraft developer to perform all hardware verification and validation, and to perform final docking analyses to ensure the needed docking performance and to develop the final certification loads for their application. While there are many other critical requirements needed in the development of a docking system such as fault tolerance, reliability, and environments (e.g. vibration, etc.), it is not the intent of the IDSS IDD to mandate all of these requirements; these requirements must be addressed as part of the specific developer's unique program, spacecraft and mission needs. This approach allows designers the flexibility to design and build docking mechanisms to their unique program needs and requirements. The purpose of the IDSS IDD is to provide basic common design parameters to allow developers to independently design compatible docking systems. The IDSS is intended for uses ranging from crewed to autonomous space vehicles, and from Low Earth Orbit (LEO) to deep-space exploration missions.The purpose of the IDSS IDD is to provide basic common design parameters to allow developers to independently design compatible docking systems. The IDSS is intended for uses ranging from crewed to autonomous space vehicles, and from Low Earth Orbit (LEO) to deep-space exploration missions. The purpose of the IDSS IDD is to provide basic common design parameters to allow developers to independently design compatible docking systems. The IDSS is intended for uses ranging from crewed to autonomous space vehicles, and from Low Earth Orbit (LEO) to deep-space exploration missions.

docking↗

A system-level approach to automation research

Automation is the application of self-regulating mechanical and electronic devices to processes that can be accomplished with the human organs of perception, decision, and actuation. The successful application of automation to a system process should reduce man/system interaction and the perceived complexity of the system, or should increase affordability, productivity, quality control, and safety. The expense, time constraints, and risk factors associated with extravehicular activities have led the Automation Technology Branch (ATB), as part of the NASA Automation Research and Technology Program, to investigate the use of robots and teleoperators as automation aids in the context of space operations. The ATB program addresses three major areas: (1) basic research in autonomous operations, (2) human factors research on man-machine interfaces with remote systems, and (3) the integration and analysis of automated systems. This paper reviews the current ATB research in the area of robotics and teleoperators.

Harrison, F. W.↗

Update of GRASP/Ada reverse engineering tools for Ada

The GRASP/Ada project (Graphical Representations of Algorithms, Structures, and Processes for Ada) has successfully created and prototyped a new algorithmic level graphical representation of Ada software, the Control Structure Diagram (CSD). The primary impetus for creation of the CSD was to improve the comprehension efficiency of Ada software and, as a result, improve reliability and reduce costs. The emphasis was on the automatic generation of the CSD from Ada PDL or source code to support reverse engineering and maintenance. The CSD has the potential to replace traditional prettyprinted Ada source code. In Phase 1 of the GRASP/Ada project, the CSD graphical constructs were created and applied manually to several small Ada programs. A prototype (Version 1) was designed and implemented using FLEX and BISON running under VMS on a VAS 11-780. In Phase 2, the prototype was improved and ported to the Sun 4 platform under UNIX. A user interface was designed and partially implemented using the HP widget toolkit and the X Windows System. In Phase 3, the user interface was extensively reworked using the Athena widget toolkit and X Windows. The prototype was applied successfully to numerous Ada programs ranging in size from several hundred to several thousand lines of source code. Following Phase 3, the prototype was evaluated by software engineering students at Auburn University and then updated with significant enhancements to the user interface including editing capabilities. Version 3.2 of the prototype was prepared for limited distribution to facilitate further evaluation. The current prototype provides the capability for the user to generate CSD's from Ada PDL or source code in a reverse engineering as well as forward engineering mode with a level of flexibility suitable for practical application.

Cross, James H., II↗

Port-O-Sim Object Simulation Application

Port-O-Sim is a software application that supports engineering modeling and simulation of launch-range systems and subsystems, as well as the vehicles that operate on them. It is flexible, distributed, object-oriented, and realtime. A scripting language is used to configure an array of simulation objects and link them together. The script is contained in a text file, but executed and controlled using a graphical user interface. A set of modules is defined, each with input variables, output variables, and settings. These engineering models can be either linked to each other or run as standalone. The settings can be modified during execution. Since 2001, this application has been used for pre-mission failure mode training for many Range Safety Scenarios. It contains range asset link analysis, develops look-angle data, supports sky-screen site selection, drives GPS (Global Positioning System) and IMU (Inertial Measurement Unit) simulators, and can support conceptual design efforts for multiple flight programs with its capacity for rapid six-degrees-of-freedom model development. Due to the assembly of various object types into one application, the application is applicable across a wide variety of launch range problem domains.

Lanzi, Raymond J.↗

Small Projects Rapid Integration and Test Environment (SPRITE): Application for Increasing Robustness

Marshall Space Flight Center's (MSFC) Small Projects Rapid Integration and Test Environment (SPRITE) is a Hardware-In-The-Loop (HWIL) facility that provides rapid development, integration, and testing capabilities for small projects (CubeSats, payloads, spacecraft, and launch vehicles). This facility environment focuses on efficient processes and modular design to support rapid prototyping, integration, testing and verification of small projects at an affordable cost, especially compared to larger type HWIL facilities. SPRITE (Figure 1) consists of a "core" capability or "plant" simulation platform utilizing a graphical programming environment capable of being rapidly re-configured for any potential test article's space environments, as well as a standard set of interfaces (i.e. Mil-Std 1553, Serial, Analog, Digital, etc.). SPRITE also allows this level of interface testing of components and subsystems very early in a program, thereby reducing program risk.

Rakoczy, John↗

The Keck keyword layer

Each Keck instrument presents a consistent software view to the user interface programmer. The view consists of a small library of functions, which are identical for all instruments, and a large set of keywords, that vary from instrument to instrument. All knowledge of the underlying task structure is hidden from the application programmer by the keyword layer. Image capture software uses the same function library to collect data for the image header. Because the image capture software and the instrument control software are built on top of the same keyword layer, a given observation can be 'replayed' by extracting keyword-value pairs from the image header and passing them back to the control system. The keyword layer features non-blocking as well as blocking I/O. A non-blocking keyword write operation (such as setting a filter position) specifies a callback to be invoked when the operation is complete. A non-blocking keyword read operation specifies a callback to be invoked whenever the keyword changes state. The keyword-callback style meshes well with the widget-callback style commonly used in X window programs. The first keyword library was built for the two Keck optical instruments. More recently, keyword libraries have been developed for the infrared instruments and for telescope control. Although the underlying mechanisms used for inter-process communication by each of these systems vary widely (Lick MUSIC, Sun RPC, and direct socket I/O, respectively), a basic user interface has been written that can be used with any of these systems. Since the keyword libraries are bound to user interface programs dynamically at run time, only a single set of user interface executables is needed. For example, the same program, 'xshow', can be used to display continuously the telescope's position, the time left in an instrument's exposure, or both values simultaneously. Less generic tools that operate on specific keywords, for example an X display that controls optical instrument exposures, have also been written using the keyword layer.

Conrad, A. R.↗

Finite element thermal analysis of convectively-cooled aircraft structures

The design complexity and size of convectively-cooled engine and airframe structures for hypersonic transports necessitate the use of large general purpose computer programs for both thermal and structural analyses. Generally thermal analyses are based on the lumped-parameter finite difference technique, and structural analyses are based on the finite element technique. Differences in these techniques make it difficult to achieve an efficient interface. It appears, therefore, desirable to conduct an integrated analysis based on a common technique. A summary is provided of efforts by NASA concerned with the development of an integrated thermal structural analysis capability using the finite element method. Particular attention is given to the development of conduction/forced-convection finite element methodology and applications which illustrate the capabilities of the developed concepts.

Wieting, A. R.↗

Operation of the HP2250 with the HP9000 series 200 using PASCAL 3.0

A computer program has been written to provide an interface between the HP Series 200 desktop computers, operating under HP Standard Pascal 3.0, and the HP2250 Data Acquisition and Control System. Pascal 3.0 for the HP9000 desktop computer gives a number of procedures for handling bus communication at various levels. It is necessary, however, to reach the lowest possible level in Pascal to handle the bus protocols required by the HP2250. This makes programming extremely complex since these protocols are not documented. The program described solves those problems and allows the user to immediately program, simply and efficiently, any measurement and control language (MCL/50) application with a few procedure calls. The complete set of procedures is available on a 5 1/4 inch diskette from Cosmic. Included in this group of procedures is an Exerciser which allows the user to exercise his HP2250 interactively. The exerciser operates in a fashion similar to the Series 200 operating system programs, but is adapted to the requirements of the HP2250. The programs on the diskette and the user's manual assume the user is acquainted with both the MCL/50 programming language and HP Standard Pascal 3.0 for the HP series 200 desktop computers.

Perry, John↗

A pilot demonstration project of technology application from the aerospace industry to city management (four cities program)

The Four Cities Program has completed the first year of the planned two-year program. At the beginning of the first year, a variety of program initiation activities were accomplished. Contracts were negotiated; science and technology advisors were interviewed, selected and assigned; general indoctrination and integration of the advisors into city affairs occurred; technical needs were identified and related projects pursued; pilot projects for the second year were identified; inter-city coordination on technical problems began to emerge; and the general soundness of the four cities program seems to have been established. Above all, the inter-personal relationships between the advisors and their interfaces in city government appear to be functioning smoothly. The establishment of such mutual respect, trusts, and confidences are believed essential to the success of the program.

Ervin, G. F.↗