SEARCH · Search NASA
Results for “service systems”
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.
Charter for Systems Engineer Working Group
This charter establishes the International Space Station Program (ISSP) Mobile Servicing System (MSS) Systems Engineering Working Group (SEWG). The MSS SEWG is established to provide a mechanism for Systems Engineering for the end-to-end MSS function. The MSS end-to-end function includes the Space Station Remote Manipulator System (SSRMS), the Mobile Remote Servicer (MRS) Base System (MBS), Robotic Work Station (RWS), Special Purpose Dexterous Manipulator (SPDM), Video Signal Converters (VSC), and Operations Control Software (OCS), the Mobile Transporter (MT), and by interfaces between and among these elements, and United States On-Orbit Segment (USOS) distributed systems, and other International Space Station Elements and Payloads, (including the Power Data Grapple Fixtures (PDGFs), MSS Capture Attach System (MCAS) and the Mobile Transporter Capture Latch (MTCL)). This end-to-end function will be supported by the ISS and MSS ground segment facilities. This charter defines the scope and limits of the program authority and document control that is delegated to the SEWG and it also identifies the panel core membership and specific operating policies.
Remote servicing of space systems
Space systems are difficult to maintain on orbit. The difficulty arises from the limited ability and availability of the astronaut work force in the hazardous space environment. Remote robotic manipulation can free the astronaut from the hazardous working environment while also increasing the work force. However, remote robotic servicing is not without its own set of problems and limitations, such as communication time delay and unstructured worksites. Tests and test equipment are described which are designed to increase the understanding of the remote servicing problems and to allow development of potential solutions. A half scale satellite mockup was developed for evaluating and improving upon the design of replaceable subsystems, such as batteries and electronic boxes. A servicer system, that includes a six degree of freedom PUMA 560 robot and interchangeable end effectors (tools), was developed to aid in driving out servicer design requirements. The results include the time delay impact on servicing timelines and requirements for the servicer system.
Telerobotic Architecture for an on-Orbit Servicer
An on-orbit servicer system has unique functional and human factors requirements. The servicing, whether it be teleoperation task, a supervised control task or an autonomous robotic task, the man-machine interface function is likely to be a bottleneck to the operation of the whole system. The man-machine interface system for a space servicer, namely the operator control station, includes several subsystems with a hierarchical architecture. Those subsystems include a reasoning and planning subsystem (also known as the artificial intelligence planner), a run-time control subsystem, a manipulator control and mechanization subsystem, and a sensing and perception subsystem. Indicative of these potentials, certain generic tasks, suggestive of space assembly, maintenance and repair, were performed in a testbed environment. Through performance in several modes: direct teleoperation, shared control, traded control, and robotic operation, the benefits of the individual technology contributions to the operation were quantized and recommendations for use in telerobotic systems were established.
Human factors requirements for telerobotic command and control: The European Space Agency experimental programme
Space Telerobotics research, performed under contract to the European Space Agency (ESA), concerning the execution of human factors experiments, and ultimately leading to the development of a telerobotics test bed, has been carried out since 1985 by a British Consortium consisting of British Aerospace, the United Kingdom Atomic Energy Authority and, more recently, the UK National Advanced Robotics Research Centre. The principal aim of the first study of the series was to derive preliminary requirements for a teleoperation servicing system, with reference to two mission model scenarios. The first scenario introduced the problem of communications time delays, and their likely effect on the ground-based operator in control of a manipulator system on board an unmanned servicing vehicle in Low Earth Orbit. In the second scenario, the operator was located on the NASA Orbiter aft flight deck, supervising the control of a prototype manipulator in the 'servicing' of an experimental payload in the cargo bay area. Human factors analyses centered on defining the requirements for the teleoperator workstation, such as identifying basic ergonomic requirements for workstation and panel layouts, defining teleoperation strategies, developing alphanumeric and graphic screen formats for the supervision or direct control of the manipulator, and the potential applications of expert system technology. The second study for ESA involved an experimental appraisal of some of the important issues highlighted in the first study, for which relevant human factors data did not exist. Of central importance during the second study was the issue of communications time delays and their effect on the manual control of a teleoperated manipulator from a ground-based command and control station.
Review of water disinfection techniques
Throughout the history of manned space flight the supply of potable water to the astronauts has presented unique problems. Of particular concern has been the microbiological quality of the potable water. This has required the development of both preflight water system servicing procedures to disinfect the systems and inflight disinfectant addition and monitoring devices to ensure continuing microbiological control. The disinfectants successfully used to date have been aqueous chlorine or iodine. Because of special system limitations the use of iodine has been the most successful for inflight use and promises to be the agent most likely to be used in the future. Future spacecraft potable, hygiene, and experiment water systems will utilize recycled water. This will present special problems for water quality control. NASA is currently conducting research and development to solve these problems.
Launch Pad in a Box
NASA Kennedy Space Center (KSC) is developing a new deployable launch system capability to support a small class of launch vehicles for NASA and commercial space companies to test and launch their vehicles. The deployable launch pad concept was first demonstrated on a smaller scale at KSC in 2012 in support of NASA Johnson Space Center's Morpheus Lander Project. The main objective of the Morpheus Project was to test a prototype planetary lander as a vertical takeoff and landing test-bed for advanced spacecraft technologies using a hazard field that KSC had constructed at the Shuttle Landing Facility (SLF). A steel pad for launch or landing was constructed using a modular design that allowed it to be reconfigurable and expandable. A steel flame trench was designed as an optional module that could be easily inserted in place of any modular steel plate component. The concept of a transportable modular launch and landing pad may also be applicable to planetary surfaces where the effects of rocket exhaust plume on surface regolith is problematic for hardware on the surface that may either be damaged by direct impact of high speed dust particles, or impaired by the accumulation of dust (e.g., solar array panels and thermal radiators). During the Morpheus free flight campaign in 2013-14, KSC performed two studies related to rocket plume effects. One study compared four different thermal ablatives that were applied to the interior of a steel flame trench that KSC had designed and built. The second study monitored the erosion of a concrete landing pad following each landing of the Morpheus vehicle on the same pad located in the hazard field. All surfaces of a portable flame trench that could be directly exposed to hot gas during launch of the Morpheus vehicle were coated with four types of ablatives. All ablative products had been tested by NASA KSC and/or the manufacturer. The ablative thicknesses were measured periodically following the twelve Morpheus free flight tests. The thermal energy from the Morpheus rocket exhaust plume was only found to be sufficient to cause appreciable ablation of one of the four ablatives that were tested. The rocket exhaust plume did cause spalling of concrete during each descent and landing on a landing pad in the hazard field. The Extended Abstract ASE Earth and Space Conference April, 2016 - Orlando, FL concrete surface was laser scanned following each Morpheus landing, and the total volume of spalled concrete that eroded between the first and final landings of the Morpheus Project's test campaign was estimated. This paper will also describe a new deployable launch system (DLS) capability that is being developed at KSC and was publicly announced in May 2015 (KSC Partnerships, 2015). The DLS is a set of multi-user Ground Support Equipment that will be used to test and launch small class launch vehicles. The system is comprised of four main elements: the Launch Stand, the Flame Deflector, the Pad Apron and the KAMAG transporter. The system elements are designed to be deployed at launch or test sites within the KSC/CCAFS boundaries. The DLS is intended to be used together with the Fluid and Electrical System of the Universal Propellant Servicing Systems and Mobile Power Data and Communications Unit.
Launch Pad in a Box
NASA Kennedy Space Center (KSC) is developing a new deployable launch system capability to support a small class of launch vehicles for NASA and commercial space companies to test and launch their vehicles. The deployable launch pad concept was first demonstrated on a smaller scale at KSC in 2012 in support of NASA Johnson Space Center's Morpheus Lander Project. The main objective of the Morpheus Project was to test a prototype planetary lander as a vertical takeoff and landing test-bed for advanced spacecraft technologies using a hazard field that KSC had constructed at the Shuttle Landing Facility (SLF). A steel pad for launch or landing was constructed using a modular design that allowed it to be reconfigurable and expandable. A steel flame trench was designed as an optional module that could be easily inserted in place of any modular steel plate component. The concept of a transportable modular launch and landing pad may also be applicable to planetary surfaces where the effects of rocket exhaust plume on surface regolith is problematic for hardware on the surface that may either be damaged by direct impact of high speed dust particles, or impaired by the accumulation of dust (e.g., solar array panels and thermal radiators). During the Morpheus free flight campaign in 2013-14, KSC performed two studies related to rocket plume effects. One study compared four different thermal ablatives that were applied to the interior of a steel flame trench that KSC had designed and built. The second study monitored the erosion of a concrete landing pad following each landing of the Morpheus vehicle on the same pad located in the hazard field. All surfaces of a portable flame trench that could be directly exposed to hot gas during launch of the Morpheus vehicle were coated with four types of ablatives. All ablative products had been tested by NASA KSC and/or the manufacturer. The ablative thicknesses were measured periodically following the twelve Morpheus free flight tests. The thermal energy from the Morpheus rocket exhaust plume was only found to be sufficient to cause appreciable ablation of one of the four ablatives that were tested. The rocket exhaust plume did cause spalling of concrete during each descent and landing on a landing pad in the hazard field. The Extended Abstract ASE Earth and Space Conference April, 2016 - Orlando, FL concrete surface was laser scanned following each Morpheus landing, and the total volume of spalled concrete that eroded between the first and final landings of the Morpheus Project's test campaign was estimated. This paper will also describe a new deployable launch system (DLS) capability that is being developed at KSC and was publicly announced in May 2015 (KSC Partnerships, 2015). The DLS is a set of multi-user Ground Support Equipment that will be used to test and launch small class launch vehicles. The system is comprised of four main elements: the Launch Stand, the Flame Deflector, the Pad Apron and the KAMAG transporter. The system elements are designed to be deployed at launch or test sites within the KSC/CCAFS boundaries. The DLS is intended to be used together with the Fluid and Electrical System of the Universal Propellant Servicing Systems and Mobile Power Data and Communications Unit
A performance measurement system for engineering services
A performance measurement system which provides both a means of monitoring performance and a resource to support management decision making is described. The process of performance indicator development is discussed and typical indicators are described. The paper concludes with a summary of some of the lessons learned in applying productivity measurements to engineering services tasks and in automating data collection, evaluation and interpretation.
DMFS: A Data Migration File System for NetBSD
I have recently developed dmfs, a Data Migration File System, for NetBSD. This file system is based on the overlay file system, which is discussed in a separate paper, and provides kernel support for the data migration system being developed by my research group here at NASA/Ames. The file system utilizes an underlying file store to provide the file backing, and coordinates user and system access to the files. It stores its internal meta data in a flat file, which resides on a separate file system. Our data migration system provides archiving and file migration services. System utilities scan the dmfs file system for recently modified files, and archive them to two separate tape stores. Once a file has been doubly archived, files larger than a specified size will be truncated to that size, potentially freeing up large amounts of the underlying file store. Some sites will choose to retain none of the file (deleting its contents entirely from the file system) while others may choose to retain a portion, for instance a preamble describing the remainder of the file. The dmfs layer coordinates access to the file, retaining user-perceived access and modification times, file size, and restricting access to partially migrated files to the portion actually resident. When a user process attempts to read from the non-resident portion of a file, it is blocked and the dmfs layer sends a request to a system daemon to restore the file. As more of the file becomes resident, the user process is permitted to begin accessing the now-resident portions of the file. For simplicity, our data migration system divides a file into two portions, a resident portion followed by an optional non-resident portion. Also, a file is in one of three states: fully resident, fully resident and archived, and (partially) non-resident and archived. For a file which is only partially resident, any attempt to write or truncate the file, or to read a non-resident portion, will trigger a file restoration. Truncations and writes are blocked until the file is fully restored so that a restoration which only partially succeed does not leave the file in an indeterminate state with portions existing only on tape and other portions only in the disk file system. We chose layered file system technology as it permits us to focus on the data migration functionality, and permits end system administrators to choose the underlying file store technology. We chose the overlay layered file system instead of the null layer for two reasons: first to permit our layer to better preserve meta data integrity and second to prevent even root processes from accessing migrated files. This is achieved as the underlying file store becomes inaccessible once the dmfs layer is mounted. We are quite pleased with how the layered file system has turned out. Of the 45 vnode operations in NetBSD, 20 (forty-four percent) required no intervention by our file layer - they are passed directly to the underlying file store. Of the twenty five we do intercept, nine (such as vop_create()) are intercepted only to ensure meta data integrity. Most of the functionality was concentrated in five operations: vop_read, vop_write, vop_getattr, vop_setattr, and vop_fcntl. The first four are the core operations for controlling access to migrated files and preserving the user experience. vop_fcntl, a call generated for a certain class of fcntl codes, provides the command channel used by privileged user programs to communicate with the dmfs layer.
System and Method for Providing a Climate Data Persistence Service
A system, method and computer-readable storage devices for providing a climate data persistence service. A system configured to provide the service can include a climate data server that performs data and metadata storage and management functions for climate data objects, a compute-storage platform that provides the resources needed to support a climate data server, provisioning software that allows climate data server instances to be deployed as virtual climate data servers in a cloud computing environment, and a service interface, wherein persistence service capabilities are invoked by software applications running on a client device. The climate data objects can be in various formats, such as International Organization for Standards (ISO) Open Archival Information System (OAIS) Reference Model Submission Information Packages, Archive Information Packages, and Dissemination Information Packages. The climate data server can enable scalable, federated storage, management, discovery, and access, and can be tailored for particular use cases.
Adaptive multisatellite systems for aeronautical services.
The use of satellite systems to provide operational communications and ATC services to aircraft flying the oceanic routes has been the subject of considerable interest recently. Since most of the link factors are functions of geometry and the aircraft traffic density varies with time, the satellite power needed to meet the communication demand varies considerably in an oceanic area as a function of both location and time. An adaptive system that tailors the use of system resources to the needs of the user can result in an additional system capacity improvement by a factor of between two and three. Results of studies conducted to date indicate that simple implementation of adaptive techniques in aeronautical satellite systems is feasible. Study is continuing in this area and on the application of satellite multibeam techniques to gain even further increase in capacity.
Batching System for Superior Service
Veridian's Portable Batch System (PBS) was the recipient of the 1997 NASA Space Act Award for outstanding software. A batch system is a set of processes for managing queues and jobs. Without a batch system, it is difficult to manage the workload of a computer system. By bundling the enterprise's computing resources, the PBS technology offers users a single coherent interface, resulting in efficient management of the batch services. Users choose which information to package into "containers" for system-wide use. PBS also provides detailed system usage data, a procedure not easily executed without this software. PBS operates on networked, multi-platform UNIX environments. Veridian's new version, PBS Pro,TM has additional features and enhancements, including support for additional operating systems. Veridian distributes the original version of PBS as Open Source software via the PBS website. Customers can register and download the software at no cost. PBS Pro is also available via the web and offers additional features such as increased stability, reliability, and fault tolerance.A company using PBS can expect a significant increase in the effective management of its computing resources. Tangible benefits include increased utilization of costly resources and enhanced understanding of computational requirements and user needs.
Tracking and Data Relay Satellite System configuration and tradeoff study. Volume 3: Atlas Centaur launched TDRSS. Part 2: Final Report, 22 August 1972 - 1 April 1973
Configuration data and design information for the Atlas Centaur launched configuration are presented. Overall system definition, operations and control, and telecommunication service system, including link budgets, are discussed. A brief description of the user telecommunications equipment and ground station is presented. A summary description of the TDR spacecraft and all the subsystems is included. The data presented are largely in tabular form. A brief treatment of an optional configuration with enhanced telecommunications service is described.
Tracking and Data Relay Satellite System configuration and tradeoff study. Volume 4: Space shuttle launched TDRSS. Part 2: Final Report, 22 August 1972 - 1 April 1973
Configuration data and design information for the space shuttle launched configuration is presented. The overall system definition, operations and control, and telecommunication service system including link budgets are discussed. A brief description of the user transceiver and ground station is presented. A final section includes a summary description of the TDR spacecraft and all the subsystems. The data presented are largely in tabular form.
Tracking and data relay satellite system configuration and tradeoff study. Volume 3: TDRSS configuration and data summary, part 1
A reference handbook of configuration data and design information is presented. It treats the overall system definition, operations and control, and telecommunication service system including link budgets. A brief description of the user transceiver and ground station is presented. A final section includes a summary description of the TDR spacecraft and all the subsystems. The data presented are largely in tabular form for easy reference.
Apollo Command and Service Module Propulsion Systems Overview
An overview of the Apollo Command and Service Module (CSM) propulsion systems is provided. The systems for CSM propulsion and control are defined, the times during the mission when each system is used are listed, and, the basic components and operation of the service propulsion system, SM reaction control system and CM reaction control system are described.
Implementation of a system to provide mobile satellite services in North America
This paper describes the implementation of the ground network to support Mobile Satellite Services (MSS). The system is designed to take advantage of a powerful new satellite series and provides significant improvements in capacity and throughput over systems in service today. The system is described in terms of the services provided and the system architecture being implemented to deliver those services. The system operation is described including examples of a circuit switched and packet switched call placement. The physical architecture is presented showing the major hardware components and software functionality placement within the hardware.