Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Checkout”

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 991 records · Page 55
All sourcesNASA NTRSDOE OSTI
NASA NTRS2010

Status of the International Space Station Waste and Hygiene Compartment

The Waste and Hygiene Compartment (WHC) serves as the primary system for removal and containment of metabolic waste and hygiene activities on board the United States segment of the International Space Station (ISS). The WHC was launched on ULF 2 and is currently in the U.S. Laboratory and is integrated into the Water Recovery System (WRS) where pretreated urine is processed by the Urine Processor Assembly (UPA). The waste collection part of the WHC system is derived from the Service Module system and was provided by RSC-Energia along with additional hardware to allow for urine delivery to the UPA. The System has been integrated in an ISS standard equipment rack structure for use on the U.S. segment of the ISS. The system has experienced several events of interest during the deployment, checkout, and operation of the system during its first year of use and these will be covered in this paper. Design and on-orbit performance will also be discussed.

Walker, Stephanie↗
NASA NTRS2010

Hypergolic Propellants: The Handling Hazards and Lessons Learned from Use

Several unintentional hypergolic fluid related spills, fires, and explosions from the Apollo Program, the Space Shuttle Program, the Titan Program, and a few others have occurred over the past several decades. Spill sites include the following government facilities: Kennedy Space Center (KSC), Johnson Space Center (JSC), White Sands Test Facility (WSTF), Vandenberg Air Force Base (VAFB), Cape Canaveral Air Force Station (CCAFS), Edwards Air Force Base (EAFB), Little Rock AFB, and McConnell AFB. Until now, the only method of capturing the lessons learned from these incidents has been "word of mouth" or by studying each individual incident report. Through studying several dozen of these incidents, certain root cause themes are apparent. Scrutinizing these themes could prove to be highly beneficial to future hypergolic system testing, checkout, and operational use.

Nufer, Brian↗
NASA NTRS2002

Observations of the Performance of the U.S. Laboratory Architecture

The United States Laboratory Module "Destiny" was the product of many architectural, technology, manufacturing, schedule and cost constraints which spanned 15 years. Requirements for the Space Station pressurized elements were developed and baselined in the mid to late '80's. Although the station program went through several design changes the fundamental requirements that drove the architecture did not change. Manufacturing of the U.S. Laboratory began in the early 90's. Final assembly and checkout testing completed in December of 2000. Destiny was launched, mated to the International Space Station and successfully activated on the STS-98 mission in February of 2001. The purpose of this paper is to identify key requirements, which directly or indirectly established the architecture of the U.S. Laboratory. Provide an overview of how that architecture affected the manufacture, assembly, test, and activation of the module on-orbit. And finally, through observations made during the last year of operation, provide considerations in the development of future requirements and mission integration controls for space habitats.

Jones, Rod↗
NASA NTRS2011

NASA Mission Operations Directorate Preparations for the COTS Visiting Vehicles

With the retirement of the Space Shuttle looming, a series of new spacecraft is under development to assist in providing for the growing logistical needs of the International Space Station (ISS). Two of these vehicles are being built under a NASA initiative known as the Commercial Orbital Transportation Services (COTS) program. These visiting vehicles ; Space X s Dragon and Orbital Science Corporation s Cygnus , are to be domestically produced in the United States and designed to add to the capabilities of the Russian Progress and Soyuz workhorses, the European Automated Transfer Vehicle (ATV) and the Japanese H-2 Transfer Vehicle (HTV). Most of what is known about the COTS program has focused on the work of Orbital and SpaceX in designing, building, and testing their respective launch and cargo vehicles. However, there is also a team within the Mission Operations Directorate (MOD) at NASA s Johnson Space Center working with their operational counterparts in these companies to provide operational safety oversight and mission assurance via the development of operational scenarios and products needed for these missions. Ensuring that the operational aspect is addressed for the initial demonstration flights of these vehicles is the topic of this paper. Integrating Dragon and Cygnus into the ISS operational environment has posed a unique challenge to NASA and their partner companies. This is due in part to the short time span of the COTS program, as measured from initial contract award until first launch, as well as other factors that will be explored in the text. Operational scenarios and products developed for each COTS vehicle will be discussed based on the following categories: timelines, on-orbit checkout, ground documentation, crew procedures, software updates and training materials. Also addressed is an outline of the commonalities associated with the operations for each vehicle. It is the intent of the authors to provide their audience with a better understanding of the mission assurance that MOD brings to commercial ventures to the ISS

Shull, Sarah A.↗
NASA NTRS2010

Functional Fault Modeling Conventions and Practices for Real-Time Fault Isolation

The purpose of this paper is to present the conventions, best practices, and processes that were established based on the prototype development of a Functional Fault Model (FFM) for a Cryogenic System that would be used for real-time Fault Isolation in a Fault Detection, Isolation, and Recovery (FDIR) system. The FDIR system is envisioned to perform health management functions for both a launch vehicle and the ground systems that support the vehicle during checkout and launch countdown by using a suite of complimentary software tools that alert operators to anomalies and failures in real-time. The FFMs were created offline but would eventually be used by a real-time reasoner to isolate faults in a Cryogenic System. Through their development and review, a set of modeling conventions and best practices were established. The prototype FFM development also provided a pathfinder for future FFM development processes. This paper documents the rationale and considerations for robust FFMs that can easily be transitioned to a real-time operating environment.

Ferrell, Bob↗
NASA NTRS2011

Adding a Second Ku-Band Antenna to the International Space Station

The International Space Station, as originally developed, used the Ku-Band Tracking and Data Relay Satellite System communications link to transmit non-critical data to the ground. Since becoming operational, the use for the link evolved to include additional services that, although also not critical, were deemed to be necessary for the crew. The external Ku-Band Antennas were designed for transport to the ISS in the shuttle cargo bay and thus are not suitable for manifesting on any current cargo vehicle. The original intent was to stow two spare antennas on orbit in a protective container until such time as they were needed to replace a failing unit which is a long and complicated process due to the complexity of the removal and replacement procedure. The Boeing Company proposed manifesting one of those spare antennas in an operable configuration eliminating the need for an Extravehicular Activity (EVA) to correct the first failure and as such minimizing the time to hours rather than weeks required to restore the Ku-Band communications link after failures. After the first failure, an EVA would be scheduled to replace the failed antenna with the stowed spare antenna. Because the hot spare is activated internal to the ISS, the replacement of the failed unit can be done when convenient rather than in haste. This paper describes the methodology used to locate a suitable site to add a new antenna mast to the ISS as well the process followed to fabricate, deliver and install the new interface hardware. Because this was not planned when the ISS was originally designed, structural, power, data and Intermediate Frequency signal connections had to be found for use. With the movement of the P6 solar array element from the initial location in the center zenith location of the ISS to the end of the port side of the truss and concurrent relocation of one string of S-Band communications assets, there were candidate power, data and structural connections available on the Z1 Truss. The engineering team evaluated these residual interfaces for use and designed cabling and structural elements for the candidate interfaces. The antenna was recently installed on ULF-4 and has completed a preliminary checkout. Included in this check out were evaluation of the power level received from the TDRS and evaluation of the gimbal position feedback for consideration in the static bias pointing matrix. This process demonstrates the ability to modify and upgrade manned space vehicles as either need or technology requires.

DuSold, Chuck↗
NASA NTRS2011

Design of Refractory Metal Heat Pipe Life Test Environment Chamber, Cooling System, and Radio Frequency Heating System

A series of 16 Mo-44.5%Re alloy/sodium heat pipes will be experimentally tested to examine heat pipe aging. To support this evaluation, an environmental test chamber and a number of auxiliary subsystems are required. These subsystems include radio frequency (RF) power supplies/inductive coils, recirculation water coolant loops, and chamber gas conditioning. The heat pipes will be grouped, based on like power and gas mixture requirements, into three clusters of five units each, configured in a pentagonal arrangement. The highest powered heat pipe will be tested separately. Test chamber atmospheric purity is targeted at <0.3 ppb oxygen at an approximate operating pressure of 76 torr (.1.5 psia), maintained by active purification (oxygen level is comparable to a 10(exp -6) torr environment). Treated water will be used in two independent cooling circuits to remove .85 kW. One circuit will service the RF hardware while the other will maintain the heat pipe calorimetry. Initial procedures for the startup and operation of support systems have been identified. Each of these subsystems is outfitted with a variety of instrumentation, integrated with distributed real-time controllers and computers. A local area network provides communication between all devices. This data and control network continuously monitors the health of the test hardware, providing warning indicators followed by automatic shutdown should potentially damaging conditions develop. During hardware construction, a number of checkout tests.many making use of stainless steel prototype heat pipes that are already fabricated.will be required to verify operation.

Martin, J. J.↗
NASA NTRS2011

Operations Nomenclature [Annexes]

The purpose of Operations Nomenclature (OpNom) is to document methods for denoting all hardware and software and associated data referenced by operations products produced by the International Space Station (ISS) operations community. This includes Operations Data File (ODF) procedures, ground and onboard displays, mission rules, commands, messages and advisories, planning products, etc. This document applies to all agencies and individuals participating in or contributing to ISS mission operations. Mission operations include ground checkout, training, and simulations, as well as real-time activities. The document also applies to all operations documentation (paper or electronic media) and other products that refer to ISS-related equipment or activities.

Shannon, Yvette Y.↗
NASA NTRS2010

Coordinating, Scheduling, Processing and Analyzing IYA09

The IVS scheduled a special astrometric VLBI session for the International Year of Astronomy 2009 (IYA09) commemorating 400 years of optical astronomy and 40 years of VLBI. The IYA09 session is the most ambitious geodetic session to date in terms of network size, number of sources, and number of observations. We describe the process of designing, coordinating, scheduling, pre-session station checkout, correlating, and analyzing this session.

Gipson, John↗
NASA NTRS2011

Lessons Learned from the Space Shuttle Engine Cutoff System (ECO) Anomalies

The Space Shuttle Orbiter's main engine cutoff (ECO) system first failed ground checkout in April, 2005 during a first tanking test prior to Return-to-Flight. Despite significant troubleshooting and investigative efforts that followed, the root cause could not be found and intermittent anomalies continued to plague the Program. By implementing hardware upgrades, enhancing monitoring capability, and relaxing the launch rules, the Shuttle fleet was allowed to continue flying in spite of these unexplained failures. Root cause was finally determined following the launch attempts of STS-122 in December, 2007 when the anomalies repeated, which allowed drag-on instrumentation to pinpoint the fault (the ET feedthrough connector). The suspect hardware was removed and provided additional evidence towards root cause determination. Corrective action was implemented and the system has performed successfully since then. This white paper presents the lessons learned from the entire experience, beginning with the anomalies since Return-to-Flight through discovery and correction of the problem. To put these lessons in better perspective for the reader, an overview of the ECO system is presented first. Next, a chronological account of the failures and associated investigation activities is discussed. Root cause and corrective action are summarized, followed by the lessons learned.

Martinez, Hugo E.↗
NASA NTRS2011

Development and Deployment of Robonaut 2 to the International Space Station

The development of the Robonaut 2 (R2) system was a joint endeavor with NASA and General Motors, producing robots strong enough to do work, yet safe enough to be trusted to work near humans. To date two R2 units have been produced, designated as R2A and R2B. This follows more than a decade of work on the Robonaut 1 units that produced advances in dexterity, tele-presence, remote supervision across time delay, combining mobility with manipulation, human-robot interaction, force control and autonomous grasping. Design challenges for the R2 included higher speed, smaller packaging, more dexterous fingers, more sensitive perception, soft drivetrain design, and the overall implementation of a system software approach for human safety, At the time of this writing the R2B unit was poised for launch to the International Space Station (ISS) aboard STS-133. R2 will be the first humanoid robot in space, and is arguably the most sophisticated robot in the world, bringing NASA into the 21st century as the world's leader in this field. Joining the other robots already on ISS, the station is now an exciting lab for robot experiments and utilization. A particular challenge for this project has been the design and certification of the robot and its software for work near humans. The 3 layer software systems will be described, and the path to ISS certification will be reviewed. R2 will go through a series of ISS checkout tests during 2011. A taskboard was shipped with the robot that will be used to compare R2B's dexterous manipulation in zero gravity with the ground robot s ability to handle similar objects in Earth s gravity. R2's taskboard has panels with increasingly difficult tasks, starting with switches, progressing to connectors and eventually handling softgoods. The taskboard is modular, and new interfaces and experiments will be built up using equipment already on ISS. Since the objective is to test R2 performing tasks with human interfaces, hardware abounds on ISS and the crew will be involved to help select tasks that are dull, dirty or dangerous. Future plans for R2 include a series of upgrades, evolving from static IVA (Intravehicular Activity) operations, to mobile IVA, then EVA (Extravehicular Activity).

Ambrose, Robert O.↗
NASA NTRS2011

Balancing Training Techniques for Flight Controller Certification

Training of ground control teams has been a difficult task in space operations. There are several intangible skills that must be learned to become the steely eyed men and women of mission control who respond to spacecraft failures that can lead to loss of vehicle or crew if handled improperly. And as difficult as training is, it can also be costly. Every day, month or year an operator is in training, is a day that not only they are being trained without direct benefit to the organization, but potentially an instructor or mentor is also being paid for hours spent assisting them. Therefore, optimization of the training flow is highly desired. Recently the Expedition Division (DI) at Johnson Space Flight Center has recreated their training flows for the purpose of both moving to an operator/specialist/instructor hierarchy and to address past inefficiencies in the training flow. This paper will discuss the types of training DI is utilizing in their new flows, and the balance that has been struck between the ideal learning environments and realistic constraints. Specifically, the past training flow for the ISS Attitude Determination and Control Officer will be presented, including drawbacks that were encountered. Then the new training flow will be discussed and how a new approach utilizes more training methods and teaching techniques. We will look at how DI has integrated classes, workshops, checkouts, module reviews, scenarios, OJT, paper sims, Mini Sims, and finally Integrated Sims to balance the cost and timing of training a new flight controller.

Gosling, Christina↗
NASA NTRS2004

Framework for Development of Object-Oriented Software

The Real-Time Control (RTC) Application Framework is a high-level software framework written in C++ that supports the rapid design and implementation of object-oriented application programs. This framework provides built-in functionality that solves common software development problems within distributed client-server, multi-threaded, and embedded programming environments. When using the RTC Framework to develop software for a specific domain, designers and implementers can focus entirely on the details of the domain-specific software rather than on creating custom solutions, utilities, and frameworks for the complexities of the programming environment. The RTC Framework was originally developed as part of a Space Shuttle Launch Processing System (LPS) replacement project called Checkout and Launch Control System (CLCS). As a result of the framework s development, CLCS software development time was reduced by 66 percent. The framework is generic enough for developing applications outside of the launch-processing system domain. Other applicable high-level domains include command and control systems and simulation/ training systems.

Perez-Poveda, Gus↗
NASA NTRS2011

Ensuring Success of Adaptive Control Research Through Project Lifecycle Risk Mitigation

Lessons Learne: 1. Design-out unnecessary risk to prevent excessive mitigation management during flight. 2. Consider iterative checkouts to confirm or improve human factor characteristics. 3. Consider the total flight test profile to uncover unanticipated human-algorithm interactions. 4. Consider test card cadence as a metric to assess test readiness. 5. Full-scale flight test is critical to development, maturation, and acceptance of adaptive control laws for operational use.

Pavlock, Kate M.↗
NASA NTRS2011

Interplanetary Overlay Network Bundle Protocol Implementation

The Interplanetary Overlay Network (ION) system's BP package, an implementation of the Delay-Tolerant Networking (DTN) Bundle Protocol (BP) and supporting services, has been specifically designed to be suitable for use on deep-space robotic vehicles. Although the ION BP implementation is unique in its use of zero-copy objects for high performance, and in its use of resource-sensitive rate control, it is fully interoperable with other implementations of the BP specification (Internet RFC 5050). The ION BP implementation is built using the same software infrastructure that underlies the implementation of the CCSDS (Consultative Committee for Space Data Systems) File Delivery Protocol (CFDP) built into the flight software of Deep Impact. It is designed to minimize resource consumption, while maximizing operational robustness. For example, no dynamic allocation of system memory is required. Like all the other ION packages, ION's BP implementation is designed to port readily between Linux and Solaris (for easy development and for ground system operations) and VxWorks (for flight systems operations). The exact same source code is exercised in both environments. Initially included in the ION BP implementations are the following: libraries of functions used in constructing bundle forwarders and convergence-layer (CL) input and output adapters; a simple prototype bundle forwarder and associated CL adapters designed to run over an IPbased local area network; administrative tools for managing a simple DTN infrastructure built from these components; a background daemon process that silently destroys bundles whose time-to-live intervals have expired; a library of functions exposed to applications, enabling them to issue and receive data encapsulated in DTN bundles; and some simple applications that can be used for system checkout and benchmarking.

Burleigh, Scott C.↗
NASA NTRS2012

Creating Simple Windchill Admin Tools Using Info*Engine

Being a Windchill administrator often requires performing simple yet repetitive tasks on large sets of objects. These can include renaming, deleting, checking in, undoing checkout, and much more. This is especially true during a migration. Fortunately, PTC has provided a simple way to dynamically interact with Windchill using Info*Engine. This presentation will describe how to create simple Info*Engine tasks capable of saving Windchill 10.0 administrators hours of tedious work. It will also show how these tasks can be combined and displayed on a simple JSP page that acts as a "Windchill Administrator Dashboard/Toolbox". The attendee will learn some valuable tasks Info*Engine capable of performing. The attendee will gain a basic understanding of how to perform and implement Info*Engine tasks. The attendee will learn what's involved in creating a JSP page that displays Info*Engine tasks

Jones, Corey↗
NASA NTRS2011

Solid Rocket Booster (SRB) - Evolution and Lessons Learned During the Shuttle Program

The Solid Rocket Booster (SRB) element integrates all the subsystems needed for ascent flight, entry, and recovery of the combined Booster and Motor system. These include the structures, avionics, thrust vector control, pyrotechnic, range safety, deceleration, thermal protection, and retrieval systems. This represents the only human-rated, recoverable and refurbishable solid rocket ever developed and flown. Challenges included subsystem integration, thermal environments and severe loads (including water impact), sometimes resulting in hardware attrition. Several of the subsystems evolved during the program through design changes. These included the thermal protection system, range safety system, parachute/recovery system, and others. Obsolescence issues occasionally required component recertification. Because the system was recovered, the SRB was ideal for data and imagery acquisition, which proved essential for understanding loads and system response. The three main parachutes that lower the SRBs to the ocean are the largest parachutes ever designed, and the SRBs are the largest structures ever to be lowered by parachutes. SRB recovery from the ocean was a unique process and represented a significant operational challenge; requiring personnel, facilities, transportation, and ground support equipment. The SRB element achieved reliability via extensive system testing and checkout, redundancy management, and a thorough postflight assessment process. Assembly and integration of the booster subsystems was a unique process and acceptance testing of reused hardware components was required for each build. Extensive testing was done to assure hardware functionality at each level of stage integration. Because the booster element is recoverable, subsystems were available for inspection and testing postflight, unique to the Shuttle launch vehicle. Problems were noted and corrective actions were implemented as needed. The postflight assessment process was quite detailed and a significant portion of flight operations. The SRBs provided fully redundant critical systems including thrust vector control, mission critical pyrotechnics, avionics, and parachute recovery system. The design intent was to lift off with full redundancy. On occasion, the redundancy management scheme was needed during flight operations. This paper describes some of the design challenges, how the design evolved with time, and key areas where hardware reusability contributed to improved system level understanding.

Kanner, Howard S.↗