Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “user support”

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 1,189 records · Page 66
All sourcesNASA NTRSDOE OSTI
NASA NTRS1999

Practical Application of Model Checking in Software Verification

This paper presents our experiences in applying the JAVA PATHFINDER (J(sub PF)), a recently developed JAVA to SPIN translator, in the finding of synchronization bugs in a Chinese Chess game server application written in JAVA. We give an overview of J(sub PF) and the subset of JAVA that it supports and describe the abstraction and verification of the game server. Finally, we analyze the results of the effort. We argue that abstraction by under-approximation is necessary for abstracting sufficiently smaller models for verification purposes; that user guidance is crucial for effective abstraction; and that current model checkers do not conveniently support the computational models of software in general and JAVA in particular.

Havelund, Klaus↗
NASA NTRS2013

Multi-User Space Link Extension (SLE) System

The Multi-User Space (MUS) Link Extension system, a software and data system, provides Space Link Extension (SLE) users with three space data transfer services in timely, complete, and offline modes as applicable according to standards defined by the Consultative Committee for Space Data Systems (CCSDS). MUS radically reduces the schedule, cost, and risk of implementing a new SLE user system, minimizes operating costs with a lights-out approach to SLE, and is designed to require no sustaining engineering expense during its lifetime unless changes in the CCSDS SLE standards, combined with new provider implementations, force changes. No software modification to MUS needs to be made to support a new mission. Any systems engineer with Linux experience can begin testing SLE user service instances with MUS starting from a personal computer (PC) within five days. For flight operators, MUS provides a familiar-looking Web page for entering SLE configuration data received from SLE. Operators can also use the Web page to back up a space mission's entire set of up to approximately 500 SLE service instances in less than five seconds, or to restore or transfer from another system the same amount of data from a MUS backup file in about the same amount of time. Missions operate each MUS SLE service instance independently by sending it MUS directives, which are legible, plain ASCII strings. MUS directives are usually (but not necessarily) sent through a TCP-IP (Transmission Control Protocol Internet Protocol) socket from a MOC (Mission Operations Center) or POCC (Payload Operations Control Center) system, under scripted control, during "lights-out" spacecraft operation. MUS permits the flight operations team to configure independently each of its data interfaces; not only commands and telemetry, but also MUS status messages to the MOC. Interfaces can use single- or multiple-client TCP/IP server sockets, TCP/IP client sockets, temporary disk files, the system log, or standard in, standard out, or standard error as applicable. By defining MUS templates in ASCII, the flight operations team can include any MUS system variable in telemetry or command headers or footers, and/or in status messages. Data fields can be arranged within messages in different sequences, according to the mission s needs. The only constraints imposed are on the format of MUS directive strings, and some bare minimum logical requirements that must be met in order for MUS to read the mission control center's spacecraft command inputs. The MUS system imposes no limits or constraints on the numbers and combinations of missions and SLE service instances that it will support simultaneously. At any time, flight operators may add, change, delete, bind, connect, or disconnect.

Perkins, Toby↗
DOE OSTI2020

Power-to-Gas Tool: User's Guide

PNNL, working in collaboration with ITM Power and HG&E, has developed a suite of products to support analysis of P2G in Massachusetts. These products include: (a) P2G model that can be accessed at eset.pnnl.gov, (b) P2G system valuation report that describes in detail the methodology underpinning the P2G model and presents the results of 82 scenarios run using the model, and (c) a P2G model user’s guide. This user’s guide accompanies the other products and is designed to simplify the experience of each user, providing useful instructions while guiding users as they input data and interpret results.

24 POWER TRANSMISSION AND DISTRIBUTION↗
NASA NTRS2010

Suggestions for Layout and Functional Behavior of Software-Based Voice Switch Keysets

Marshall Space Flight Center (MSFC) provides communication services for a number of real time environments, including Space Shuttle Propulsion support and International Space Station (ISS) payload operations. In such settings, control team members speak with each other via multiple voice circuits or loops. Each loop has a particular purpose and constituency, and users are assigned listen and/or talk capabilities for a given loop based on their role in fulfilling the purpose. A voice switch is a given facility's hardware and software that supports such communication, and may be interconnected with other facilities switches to create a large network that, from an end user perspective, acts like a single system. Since users typically monitor and/or respond to several voice loops concurrently for hours on end and real time operations can be very dynamic and intense, it s vital that a control panel or keyset for interfacing with the voice switch be a servant that reduces stress, not a master that adds it. Implementing the visual interface on a computer screen provides tremendous flexibility and configurability, but there s a very real risk of overcomplication. (Remember how office automation made life easier, which led to a deluge of documents that made life harder?) This paper a) discusses some basic human factors considerations related to keysets implemented as application software windows, b) suggests what to standardize at the facility level and what to leave to the user's preference, and c) provides screen shot mockups for a robust but reasonably simple user experience. Concepts apply to keyset needs in almost any type of operations control or support center.

Scott, David W.↗
NASA NTRS1993

Accessing Earth science data from the EOS data and information system

An overview of the Earth Observing System Data and Information System (EOSDIS) is presented, concentrating on the users' interactions with the system and highlighting those features that are driven by the unique requirements of the Global Change Research Program and the supported science community. However, a basic premise of the EOSDIS is that the system must evolve to meet changes in user needs and to incorporate advances in data system technology. Therefore, the development process which is being used to accommodate these changes and some of the potential areas of change are also addressed.

Mcdonald, Kenneth R.↗
NASA NTRS2013

Advanced Strategic and Tactical Relay Request Management for the Mars Relay Operations Service

This software provides a new set of capabilities for the Mars Relay Operations Service (MaROS) in support of Strategic and Tactical relay, including a highly interactive relay request Web user interface, mission control over relay planning time periods, and mission management of allowed strategic vs. tactical request parameters. Together, these new capabilities expand the scope of the system to include all elements critical for Tactical relay operations. Planning of replay activities spans a time period that is split into two distinct phases. The first phase is called Strategic, which begins at the time that relay opportunities are identified, and concludes at the point that the orbiter generates the flight sequences for on board execution. Any relay request changes from this point on are called Tactical. Tactical requests, otherwise called Orbit - er Relay State Changes (ORSC), are highly restricted in terms of what types of changes can be made, and the types of parameters that can be changed may differ from one orbiter to the next. For example, one orbiter may be able to delay the start of a relay request, while another may not. The legacy approach to ORSC management involves exchanges of e-mail with "requests for change" and "acknowledgement of approval," with no other tracking of changes outside of e-mail folders. MaROS Phases 1 and 2 provided the infrastructure for strategic relay for all supported missions. This new version, 3.0, introduces several capabilities that fully expand the scope of the system to include tactical relay. One new feature allows orbiter users to manage and "lock" Planning Periods, which allows the orbiter team to formalize the changeover from Strategic to Tactical operations. Another major feature allows users to interactively submit tactical request changes via a Web user interface. A third new feature allows orbiter missions to specify allowed tactical updates, which are automatically incorporated into the tactical change process. This software update is significant in that it provides the only centralized service for tactical request management available for relay missions.

Allard, Daniel A.↗
NASA NTRS1991

Tracking and Data Relay Satellite System (TDRSS)

The DSN (Deep Space Network) mission support requirements for the Tracking and Data Relay Satellite System (TDRSS) are summarized. The TDRSS consists of four identical satellites in geosynchronous orbits (35,800 km) and a dedicated ground station. The payload of each satellite is a telecommunications service system that relays communication signals between low earth-orbiting user spacecraft and the TDRSS ground terminal. Mission objectives are outlined and the DSN support requirements are defined through the presentation of tables and narratives describing the spacecraft flight profile; DSN support coverage; frequency assignments; support parameters for telemetry, command and support systems; and tracking support responsibility.

Mckenzie, J.↗
NASA NTRS2005

Shuttle-Data-Tape XML Translator

JSDTImport is a computer program for translating native Shuttle Data Tape (SDT) files from American Standard Code for Information Interchange (ASCII) format into databases in other formats. JSDTImport solves the problem of organizing the SDT content, affording flexibility to enable users to choose how to store the information in a database to better support client and server applications. JSDTImport can be dynamically configured by use of a simple Extensible Markup Language (XML) file. JSDTImport uses this XML file to define how each record and field will be parsed, its layout and definition, and how the resulting database will be structured. JSDTImport also includes a client application programming interface (API) layer that provides abstraction for the data-querying process. The API enables a user to specify the search criteria to apply in gathering all the data relevant to a query. The API can be used to organize the SDT content and translate into a native XML database. The XML format is structured into efficient sections, enabling excellent query performance by use of the XPath query language. Optionally, the content can be translated into a Structured Query Language (SQL) database for fast, reliable SQL queries on standard database server computers.

Barry, Matthew R.↗
NASA NTRSDate not supplied

Lunar Search & Rescue Applications of Lunar GNSS

Accurate lunar navigation and timing knowledge provides for the development of safety-critical services in the cislunar and lunar surface domain. Currently under development, the Goddard Space Flight Center’s (GSFC) Search and Rescue Mission Office is investigating and integrating search and rescue (SAR) capability into planned and future lunar communication and navigation interfaces. Lunar Search and Rescue (LunaSAR) development has a stated end-goal for assured, reliable, and timely indication of distress events for a wide variety of lunar surface users, including government-sponsored, commercial, and international users. LunaSAR performance requirements are modelled after the current terrestrial Cospas-Sarsat distress notification system, leveraging an internationally robust global navigation satellite system (GNSS) ecosystem as a core element of survivor locating capability. This presentation will discuss NASA’s work to develop user-focused distress messaging capabilities including infusion of example sensor data for triggering of automated distress alerts coupled with location-tagging. Additionally, the presentation will examine overall message structures, rotating fields for use in bi-directional distress messaging, and specific use cases based on NASA’s lunar exploration and lunar communication relay architectures. Modelling and simulation of LunaSAR use by individual lunar explorers will be discussed, based on notional industry and government design reference missions and mission considerations. Results from GSFC-funded Internal Research and Development (IRAD) efforts will be detailed, including successful distress message formulation simulating the ingestion of example legacy space suit telemetry fields. Hardware-in-the-loop testing using high-reliability software defined radio (SDR) modules serve as an example of IRAD successes and the framework for technical requirements. Architectural development and technical evolution from 2020 to 2021 included alignment of LunaSAR distress waveforms with ongoing NASA LunaNet interoperability development, as well as engagement with NASA Lunar Spectrum authorities for allocation of UHF-band distress frequencies on the lunar surface. S-Band and UHF-band transmission characteristics will be detailed, along with band-specific applications of each emission type. Additionally, examples of ingestion and formatting of GNSS signals (using historical terrestrial National Marine Electronics Association-formatted GNSS data) will be detailed, underscoring lunar user needs for a common lunar GNSS receiver output message framework. Maturity and ability to support evolving lunar exploration goals has been demonstrated and will be detailed, with maturity gaps such as position, navigation, and timing (PNT) and lunar reference frames identified within the context of distress message generation. Provision of LunaSAR services for lunar surface users represents a new era of ensured safety for lunar explorers and builds off of forty years of the Cospas-Sarsat program, underscoring the importance of lunar GNSS for safety-critical applications and growing interest in safe, reliable lunar surface operations. Enabled by new GNSS systems being developed by government and industry partners, NASA will continue to evolve and integrate lunar GNSS types into distress message generation, with a focus on compact and efficient message transmission over various lunar communication links. When fielded, LunaSAR will be the first dedicated search and rescue notification system employed on another celestial body. Robust lunar navigation and timing services form the core of LunaSAR capabilities, allowing for system syncing with time-dominant sensors, and high-accuracy location of those in distress while engaged in lunar surface activities.

Search and Rescue↗
DOE OSTI2024

GPAW: An open Python package for electronic structure calculations

We review the GPAW open-source Python package for electronic structure calculations. GPAW is based on the projector-augmented wave method and can solve the self-consistent density functional theory (DFT) equations using three different wave-function representations, namely real-space grids, plane waves, and numerical atomic orbitals. The three representations are complementary and mutually independent and can be connected by transformations via the real-space grid. This multi-basis feature renders GPAW highly versatile and unique among similar codes. By virtue of its modular structure, the GPAW code constitutes an ideal platform for the implementation of new features and methodologies. Moreover, it is well integrated with the Atomic Simulation Environment (ASE), providing a flexible and dynamic user interface. In addition to ground-state DFT calculations, GPAW supports many-body GW band structures, optical excitations from the Bethe–Salpeter Equation, variational calculations of excited states in molecules and solids via direct optimization, and real-time propagation of the Kohn–Sham equations within time-dependent DFT. A range of more advanced methods to describe magnetic excitations and non-collinear magnetism in solids are also now available. In addition, GPAW can calculate non-linear optical tensors of solids, charged crystal point defects, and much more. Recently, support for graphics processing unit (GPU) acceleration has been achieved with minor modifications to the GPAW code thanks to the CuPy library. We end the review with an outlook, describing some future plans for GPAW.

37 INORGANIC, ORGANIC, PHYSICAL, AND ANALYTICAL CH↗
DOE OSTI2019

Direct-FUSE

The Direct-FUSE framework supports multiple FUSE file systems as well as other, custom user-level file systems in user space without the need to cross the user/kernel boundary into the FUSE kernel module. All layers of Direct-FUSE are in user space, and applications can directly use pre-defined unified file system calls to interact with different user-defined file systems. Our performance results show that Direct- FUSE can outperform some native FUSE file systems by 11.9% on average and does not add significant overhead over backend file systems.

SATO,, KENTO↗
DOE OSTI2024

Chemical-specific Parameters Dataset

The chemical-specific parameters dataset is searchable for physicochemical information for multiple chemicals simultaneously. After selecting chemicals of interest and the desired parameters, the RAIS will generate a table containing the values, chosen according to an established hierarchy. Results can be downloaded in Excel format. Over 40 parameters are available, including melting point, boiling point, density, density, vapor pressure, water solubility, and Henry’s Law constants. Thirteen primary sources are used to populate the dataset of chemical-specific parameters. These values should be used in cancer risk and noncancer hazard assessments for the calculation of preliminary remediation goals (PRGs), hazard characterization, and transport modeling. Users can select up to 1000 chemicals per query. The dataset supports environmental risk assessments, regulatory decision-making, and environmental planning with tools for benchmarking against risk-based standards. This structured approach ensures a robust evaluation of environmental risks tailored to regulatory needs.

Dolislager, Fred [Oak Ridge National Laboratory (O↗
DOE OSTI2024

Radionuclide-specific Parameters Dataset

The radionuclide-specific parameters dataset is searchable for radiological information for multiple isotopes simultaneously. After selecting radionuclides of interest and the desired parameters, the RAIS will generate a table containing the values, chosen according to an established hierarchy. Results can be downloaded in Excel format. 50 parameters are available, including atomic number, soil to animal transfer coefficients, plant uptake coefficients, half-life, specific activity, and water solubility. Seven primary sources are used to populate the dataset of radiological-specific parameters. These values should be used in cancer risk assessments for the calculation of preliminary remediation goals (PRGs), hazard characterization, and transport modeling. Users can select up to 1000 radionuclides per query. The dataset supports environmental risk assessments, regulatory decision-making, and environmental planning with tools for benchmarking against risk-based standards. This structured approach ensures a robust evaluation of environmental risks tailored to regulatory needs.

Manning, Karessa [Oak Ridge National Laboratory (O↗
NASA NTRS1975

Development of a new computer system for aircraft noise prediction

The paper presents an overview of the activities of NASA's Aircraft Noise Prediction Office (ANOPO). The principal goal of ANOPO is to develop a comprehensive, user-oriented, Aircraft Noise Prediction Program (ANOPP). ANOPO's activities in support of ANOPP development are briefly discussed. They include acquisition, implementation, and evaluation of an in-house, interim collection of programs and implementation of a plan for acquiring, in the form of Key Technology Documents, state-of-the-art methodology for aircraft noise prediction. The paper is primarily devoted to a presentation of the general architecture and functional capability planned for ANOPP together with the rationale supporting major design decisions.

Raney, J. P.↗
NASA NTRS1976

Synthesis and distribution of environmental satellite data

The activities of two National Oceanographic and Atmospheric Administration and two National Aeronautics and Space Administration facilities involved in the synthesis or distribution of space environmental data are reviewed. The data products, user services, and pertinent publications are given. The computer systems that support three of these facilities are discussed and some details of the synthesis procedures are given. Data from the following satellite series are included in the discussion: TIROS, NIMBUS, ESSA, NOAA, SMS/GOES, ATS, and SOLRAD. Orbital position data for HAWKEYE 1, IMP H and J, VELA 5B, PIONEERS 6-9, PIONEER 11, HELIOS 1 and 2, and SOLRAD 11A and 11B in several coordinate systems are discussed.

Vette, J. I.↗
NASA NTRS1982

Space Operations Center system analysis study extension. Volume 4, book 2: SOC system analysis report

The Space Operations Center (SOC) orbital space station research missions integration, crew requirements, SOC operations, and configurations are analyzed. Potential research and applications missions and their requirements are described. The capabilities of SOC are compared with user requirements. The SOC/space shuttle and shuttle-derived vehicle flight support operations and SOC orbital operations are described. Module configurations and systems options, SOC/external tank configurations, and configurations for geostationary orbits are described. Crew and systems safety configurations are summarized.

Source record↗
NASA NTRS1983

Interactive analysis of a large aperture Earth observations satellite

A system level design and analysis has been conducted on an Earth Observation Satellite (EOS) system using the Interactive Design and Evaluation of Advanced Spacecraft (IDEAS) computer-aided design and analysis program. The IDEAS program consists of about 40 user-friendly technical modules and an interactive graphics display. The reflector support system and feed mast of the EOS spacecraft are constructed with box-truss structural concept, a lattice configuration which can be packaged for delivery in a single Shuttle flight and deployed in orbit. The deployed spacecraft consists of a 120-m by 60-m parabolic focal axis. The spacecraft was modeled for structural, thermal, and control systems analysis and structural elements were designed. On-orbit dynamic and thermal loading analyses were conducted; spacecraft weights and developmental and first unit costs were determined.

Wright, R. L.↗
NASA NTRS1983

Interactive analysis of a large aperture Earth Observations Satellite

A system level design and analysis has been conducted on an Earth Observation Satellite (EOS) system using the Interactive Design and Evaluation of Advanced Spacecraft (IDEAS) computer-aided design and analysis program. The IDEAS program consists of about 40 user-friendly technical modules and an interactive graphics display. The reflector support system and feed mast of the EOS spacecraft are constructed with a box-truss structural concept, a lattice configuration which can be packaged for delivery in a single Shuttle flight and deployed in orbit. The deployed spacecraft consists of a 120-m by 60-m parabolic reflector, a 120-m-long support structure, and a 30-m feed arc beam on the focal axis. The spacecraft was modeled for structural, thermal, and control systems analysis and structural elements were designed. On-orbit dynamic and thermal loading analyses were conducted and spacecraft weights were determined.

Wright, R. L.↗