Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “rest service”

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 37 records · Page 2
All sourcesNASA NTRSDOE OSTI
NASA NTRSDate not supplied

TPSAS-NF1676L-32053-DND

The Atmospheric Science Data Center (ASDC) offers Earth Science data sets created from satellite measurements, modeling, and field experiments enabling scientists, educators, and the public to study earth and its atmosphere. NASA ESDIS is working towards making Earth Science data and tools cloud-ready. In an effort to align itself with these efforts, the ASDC is transitioning its existing web based services, tools and applications to RESTful APIs, containerized as microservices to leverage scalability and efficiency of an on-premise cloud environment.

Makhan L Virdi↗
NASA NTRS1989

Flight support system servicing aid tool

The Space Shuttle EVA on-orbit satellite servicing time is a scare commodity which has been limited for each mission to two 6-hour work periods with an intervening 40-hour rest period. New complex missions being planned require more servicing than two EVA's can accommodate. The GSFC (Goddard Space Flight Center) Satellite Servicing Project has been working for several years to develop a Serving Aid Tool to effectively extend this on-orbit servicing capability by IVA to the point that use of a master-slave bilateral force reflecting manipulator is now planned. This will be controlled from the Shuttle aft flight deck by the RMS mission specialist using a miniature hand controller while outfitted with a physical restraint system. This development is being done on a low cost basis using demonstrated state-of-the-art commercial teleoperated system hardware and software upgraded for space flight use.

Davis, R.↗
NASA NTRS0202

Rest architecture for link analysis tools portal

A web portal is under development to improve overall services provided by NASA networks that support near-­‐Earth missions. These networks are managed by Space Communication and Navigation (SCaN) Program of NASA and include the following: Deep Space Network (DSN), Space Network (SN), and Near-­‐Earth Network (NEN). DSN is a network of antennas located in three longitudinally separated sites and supports interplanetary spacecraft missions, radio science, and radar astronomy observations. SN consists of a number of geostationary Tracking and Data Relay Satellites (TDRS) and associated ground stations. NEN consists of both NASA-­‐owned ground stations and those owned by international, commercial, and academic partners. This study investigates different web access techniques for mission users to use link analysis tools that aid in operating NASA networks. We developed a web portal prototype following principles of Representational state transfer (REST) architecture to leverage scalability, independent deployment of tools, and generic interfaces. In REST architectures, requests and responses between clients and servers are built around transferring representations of resources that can be addressed in memory. We demonstrate the feasibility of using REST architecture to facilitate web-­‐service transactions via web-­‐portal.

Lee, Carlyn-­‐Ann↗
NASA NTRS1973

Effects of weightlessness in man.

The program for the Apollo 16 flight was designed to include both safeguards against and investigations of the physiological problems arising from increase in the period of manned space flight. Precautions included the provision of a controlled diet with high potassium content, carefully controlled work loads and work-rest cycles, and an emergency cardiology consultation service, and investigations were made to enable preflight vs postflight comparisons of metabolic, cardiovascular, and central nervous system data. Results of these investigations indicate that adjustment to weightlessness can be satisfactorily assisted by appropriate countermeasures, including attention to diet.

Berry, C. A.↗
NASA NTRSDate not supplied

DIP for Service Providers

The second DIP workshop’s topic is DIP for Service Providers. The workshop presentation covers topics such as DIP onboarding process, service authentication, catalog service capabilities, API requirements, NASA services and their access points, and data requirements for service providers. The Onboarding Process describes the required documentation that enables to collaborate with NASA as well as other industry partners through DIP. Also, step by step approach for the partner to take to register services or consme services through the DIP platform. The Catalog Service describes the different ways for the users to search for services that are of interest as well as registering services to the platform, so other users can search and discover. The API Requirements and Service Specifications describes the benefits of DIP's API management approach via API Gateway where services are managed centrally but ownership is decentralized and partners completely own the administration of their own services. NASA Services and Data Access Points topic describes the services, both data access service and machine learning prediction service, that NASA provides via the DIP platform in near time and post operations via REST API endpoints defined on the API Gateway. Also, NASA's approach for data storage process is explained. The Data Requirements for service providers describes the requirements for storing and exposing to support the performance of services that are provided by the service providers. Lastly, NASA's technology development plan with preliminary scheduler will be presented. There will be a Q&A session at the end of each segment of the presentation to solicit feedback from the participants.

ATM-X↗
NASA NTRS2006

Airport Surface Network Architecture Definition

Currently, airport surface communications are fragmented across multiple types of systems. These communication systems for airport operations at most airports today are based dedicated and separate architectures that cannot support system-wide interoperability and information sharing. The requirements placed upon the Communications, Navigation, and Surveillance (CNS) systems in airports are rapidly growing and integration is urgently needed if the future vision of the National Airspace System (NAS) and the Next Generation Air Transportation System (NGATS) 2025 concept are to be realized. To address this and other problems such as airport surface congestion, the Space Based Technologies Project s Surface ICNS Network Architecture team at NASA Glenn Research Center has assessed airport surface communications requirements, analyzed existing and future surface applications, and defined a set of architecture functions that will help design a scalable, reliable and flexible surface network architecture to meet the current and future needs of airport operations. This paper describes the systems approach or methodology to networking that was employed to assess airport surface communications requirements, analyze applications, and to define the surface network architecture functions as the building blocks or components of the network. The systems approach used for defining these functions is relatively new to networking. It is viewing the surface network, along with its environment (everything that the surface network interacts with or impacts), as a system. Associated with this system are sets of services that are offered by the network to the rest of the system. Therefore, the surface network is considered as part of the larger system (such as the NAS), with interactions and dependencies between the surface network and its users, applications, and devices. The surface network architecture includes components such as addressing/routing, network management, network performance and security.

Nguyen, Thanh C.↗
NASA NTRS2021

Is the Last Inflight Rest Break Really the Best?

As pilots experienced in augmented long-haul flights know, current FAA regulations limit options for scheduling in-flight rest periods, such that on many long-haul operations the landing pilot needs to use the final bunk period, closest to top of descent (TOD). However, the logistics of a particular flight (e.g., timing of the flight, timing of passenger service) and the pilot’s own physiology may mean that the last rest break isn’t always the best. To study this, we conducted a large survey of pilots flying these operations. Pilots completed the survey after eligible flights and provided us with information on which rest break they used, how much sleep they received, factors that disrupted sleep and ratings on the quality of their sleep, and they also provided fatigue and alertness ratings at top-of-descent. Pilots from another US-based carrier were also surveyed, in collaboration with our research partners at Washington State University, to increase the sample size and gather insights between operations.

in-flight rest↗
NASA NTRS2012

Operational Improvements From the Automatic Dependant Surveillance Broadcast In-Trail Procedure in the Pacific Organized Track System

The Federal Aviation Administration's Surveillance and Broadcast Services Program has supported implementation of the Automatic Dependant Surveillance Broadcast (ADS-B) In-Trail Procedure (ITP) on commercial revenue flights. ADS-B ITP is intended to be used in non-radar airspace that is employing procedural separation. Through the use of onboard tools, pilots are able to make a new type of altitude change request to an Air Traffic Service Provider (ATSP). The FAA, in partnership with United Airlines, is conducting flight trials of the ITP in revenue service in the Pacific. To support the expansion of flight trials to the rest of the US managed Pacific Airspace Region, a computerized batch study was conducted to investigate the operational impacts and potential benefits that can be gained through the use of the ITP in the Pacific Organized Track System (PACOTS). This study, which simulated the Oakland managed portion of the PACOTS, suggests that potential benefits in the PACOTS are significant with a considerable increase in time spent at optimum altitude and associated fuel savings.

Chartrand, Ryan C.↗
NASA NTRS1999

Concept Development of a Mach 1.6 High-Speed Civil Transport

A high-speed civil transport configuration with a Mach number of 1.6 was developed as part of the NASA High-Speed Research Program to serve as a baseline for assessing advanced technologies required for an aircraft with a service entry date of 2005. This configuration offered more favorable solutions to environmental concerns than configurations with higher Mach numbers. The Mach 1.6 configuration was designed for a 6500 n.mi. mission with a 250-passenger payload. The baseline configuration has a wing area of 8732 square feet a takeoff gross weight of 591570 lb, and four 41000-lb advanced turbine bypass engines defined by NASA. These engines have axisymmetric mixer-ejector nozzles that are assumed to yield 20 dB of noise suppression during takeoff, which is assumed to satisfy, the FAR Stage III noise requirements. Any substantial reduction in this assumed level of suppression would require oversizing the engines to meet community noise regulations and would severly impact the gross weight of the aircraft at takeoff. These engines yield a ratio of takeoff thrust to weight of 0.277 and a takeoff wing loading of 67.8 lb/square feet that results in a rotation speed of 169 knots. The approach velocity of the sized configuration at the end of the mission is 131 knots. The baseline configuration was resized with an engine having a projected life of 9000 hr for hot rotating parts and 18000 hr for the rest of the engine, as required for commercial use on an aircraft with a service entry date of 2005. Results show an increase in vehicle takeoff gross weight of approximately 58700 lb. This report presents the details of the configuration development, mass properties, aerodynamic design, propulsion system and integration, mission performance, and sizing.

Shields, Elwood W.↗
NASA NTRS2011

Implementing Strategic Planning Capabilities Within the Mars Relay Operations Service

Throughout this development and deployment process we have followed a few guiding principles: (1) Ensure ubiquitous access through ReSTful and web interfaces; (2) Design a system that is mission and even planet agnostic so that future missions may be added with little hassle, and the system itself may be redeployed for other planetary relay networks; (3) Accept constant input and feedback between mission operators and the development team to ensure that there is a useful product that may be used for years to come.

software development↗
NASA NTRS2010

MaROS Strategic Relay Planning and Coordination Interfaces

The Mars Relay Operations Service (MaROS) is designed to provide planning and analysis tools in support of ongoing Mars Network relay operations. Strategic relay planning requires coordination between lander and orbiter mission ground data system (GDS) teams to schedule and execute relay communications passes. MaROS centralizes this process, correlating all data relevant to relay coordination to provide a cohesive picture of the relay state. Service users interact with the system through thin-layer command line and web user interface client applications. Users provide and utilize data such as lander view periods of orbiters, Deep Space Network (DSN) antenna tracks, and reports of relay pass performance. Users upload and download relevant relay data via formally defined and documented file structures including some described in Extensible Markup Language (XML). Clients interface with the system via an http-based Representational State Transfer (ReST) pattern using Javascript Object Notation (JSON) formats. This paper will provide a general overview of the service architecture and detail the software interfaces and considerations for interface design.

Allard, Daniel A.↗
NASA NTRS2014

Development of Test Protocols for International Space Station Particulate Filters

Air quality control on the International Space Station (ISS) is a vital requirement for maintaining a clean environment for the crew and the hardware. This becomes a serious challenge in pressurized space compartments since no outside air ventilation is possible, and a larger particulate load is imposed on the filtration system due to lack of gravitational settling. The ISS Environmental Control and Life Support System (ECLSS) uses a filtration system that has been in use for over 14 years and has proven to meet this challenge. The heart of this system is a traditional High- Efficiency Particulate Air (HEPA) filter configured to interface with the rest of the life support elements and provide effective cabin filtration. Over the years, the service life of these filters has been re-evaluated based on limited post-flight tests of returned filters and risk factors. On earth, a well designed and installed HEPA filter will last for several years, e.g. in industrial and research clean room applications. Test methods for evaluating these filters are being developed on the basis of established test protocols used by the industry and the military. This paper will discuss the test methods adopted and test results on prototypes of the ISS filters. The results will assist in establishing whether the service life can be extended for these filters. Results from unused filters that have been in storage will also be presented to ascertain the shelf life and performance deterioration, if any and determine if the shelf life may be extended.

Aerosol↗
NASA NTRS2012

QuakeSim 2.0

QuakeSim 2.0 improves understanding of earthquake processes by providing modeling tools and integrating model applications and various heterogeneous data sources within a Web services environment. QuakeSim is a multisource, synergistic, data-intensive environment for modeling the behavior of earthquake faults individually, and as part of complex interacting systems. Remotely sensed geodetic data products may be explored, compared with faults and landscape features, mined by pattern analysis applications, and integrated with models and pattern analysis applications in a rich Web-based and visualization environment. Integration of heterogeneous data products with pattern informatics tools enables efficient development of models. Federated database components and visualization tools allow rapid exploration of large datasets, while pattern informatics enables identification of subtle, but important, features in large data sets. QuakeSim is valuable for earthquake investigations and modeling in its current state, and also serves as a prototype and nucleus for broader systems under development. The framework provides access to physics-based simulation tools that model the earthquake cycle and related crustal deformation. Spaceborne GPS and Inter ferometric Synthetic Aperture (InSAR) data provide information on near-term crustal deformation, while paleoseismic geologic data provide longerterm information on earthquake fault processes. These data sources are integrated into QuakeSim's QuakeTables database system, and are accessible by users or various model applications. UAVSAR repeat pass interferometry data products are added to the QuakeTables database, and are available through a browseable map interface or Representational State Transfer (REST) interfaces. Model applications can retrieve data from Quake Tables, or from third-party GPS velocity data services; alternatively, users can manually input parameters into the models. Pattern analysis of GPS and seismicity data has proved useful for mid-term forecasting of earthquakes, and for detecting subtle changes in crustal deformation. The GPS time series analysis has also proved useful as a data-quality tool, enabling the discovery of station anomalies and data processing and distribution errors. Improved visualization tools enable more efficient data exploration and understanding. Tools provide flexibility to science users for exploring data in new ways through download links, but also facilitate standard, intuitive, and routine uses for science users and end users such as emergency responders.

Donnellan, Andrea↗
NASA NTRS1989

Advanced information processing system: Local system services

The Advanced Information Processing System (AIPS) is a multi-computer architecture composed of hardware and software building blocks that can be configured to meet a broad range of application requirements. The hardware building blocks are fault-tolerant, general-purpose computers, fault-and damage-tolerant networks (both computer and input/output), and interfaces between the networks and the computers. The software building blocks are the major software functions: local system services, input/output, system services, inter-computer system services, and the system manager. The foundation of the local system services is an operating system with the functions required for a traditional real-time multi-tasking computer, such as task scheduling, inter-task communication, memory management, interrupt handling, and time maintenance. Resting on this foundation are the redundancy management functions necessary in a redundant computer and the status reporting functions required for an operator interface. The functional requirements, functional design and detailed specifications for all the local system services are documented.

Burkhardt, Laura↗
NASA NTRS2021

HAPI: An API Standard for Accessing Heliophysics Time Series Data

Heliophysics data analysis often involves combining diverse science measurements, many of them captured as time series. Although there are now only a few commonly used data file formats, the diversity in mechanisms for automated access to and aggregation of such data holdings can make analysis that requires intercomparison of data from multiple data providers difficult. The Heliophysics Application Programmer's Interface (HAPI) is a recently developed standard for accessing distributed time series data to increase interoperability. The HAPI specification is based on the common elements of existing data services, and it standardizes the two main parts of a data service: the request interface and the response data structures. The interface is based on the REpresentational State Transfer (REST) or RESTful architecture style, and the HAPI specification defines five required REST endpoints. Data are returned via a streaming format that hides file boundaries; the metadata is detailed enough for the content to be scientifically useful, e.g., plotted with appropriate axes layout, units, and labels. Multiple mature HAPI-related open-source projects offer server-side implementation tools and client-side libraries for reading HAPI data in multiple languages (IDL, Java, MATLAB, and Python). Multiple data providers in the US and Europe have added HAPI access alongside their existing interfaces. Based on this experience, data can be served via HAPI with little or no information loss compared to similar existing web interfaces. Finally, HAPI has been recommended as a COSPAR standard for time series data delivery.

Robert S. Weigel↗
NASA NTRS2004

Gesture-controlled interfaces for self-service machines and other applications

A gesture recognition interface for use in controlling self-service machines and other devices is disclosed. A gesture is defined as motions and kinematic poses generated by humans, animals, or machines. Specific body features are tracked, and static and motion gestures are interpreted. Motion gestures are defined as a family of parametrically delimited oscillatory motions, modeled as a linear-in-parameters dynamic system with added geometric constraints to allow for real-time recognition using a small amount of memory and processing time. A linear least squares method is preferably used to determine the parameters which represent each gesture. Feature position measure is used in conjunction with a bank of predictor bins seeded with the gesture parameters, and the system determines which bin best fits the observed motion. Recognizing static pose gestures is preferably performed by localizing the body/object from the rest of the image, describing that object, and identifying that description. The disclosure details methods for gesture recognition, as well as the overall architecture for using gesture recognition to control of devices, including self-service machines.

Cohen, Charles J.↗
NASA NTRS2007

Overview for Attached Payload Accommodations and Environments

External payload accommodations are provided at attach sites on the U.S provided ELC, U.S. Truss, the Japanese Experiment Module Exposed Facility (JEM EF) and the Columbus EPF (External Payload Facilities). The Integrated Truss Segment (ITS) provides the backbone structure for the ISS. It attaches the solar and thermal control arrays to the rest of the complex, and houses cable distribution trays Extravehicular Activity (EVA) support equipment such as handholds and lighting; and providing for Extravehicular Robotic (EVR) accommodations using the Mobile Servicing System (MSS). It also provides logistics and maintenance, and payload attachment sites. The attachment sites accommodate logistics and maintenance and payloads carriers, zenith and nadir. The JEM-EF, a back porch-like attachment to the JEM Pressurized Module, accommodates up to eight payloads, which can be serviced by the crew via the JEM PM's airlock and dedicated robotic arm. The Columbus-EPF is another porch-like platform that can accommodate two zenith and two nadir looking payloads.

Schaffer, Craig↗