Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “CONTRACTORS”

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,747 records · Page 97
All sourcesNASA NTRSDOE OSTI
NASA NTRS2015

NASA's Space Launch System Program Update

Hardware and software for the world's most powerful launch vehicle for exploration is being welded, assembled, and tested today in high bays, clean rooms and test stands across the United States. NASA's Space Launch System (SLS) continued to make significant progress in 2014 with more planned for 2015, including firing tests of both main propulsion elements and the program Critical Design Review (CDR). Developed with the goals of safety, affordability, and sustainability, SLS will still deliver unmatched capability for human and robotic exploration. The initial Block 1 configuration will deliver more than 70 metric tons of payload to low Earth orbit (LEO). The evolved Block 2 design will deliver some 130 metric tons to LEO. Both designs offer enormous opportunity and flexibility for larger payloads, simplifying payload design as well as ground and on-orbit operations, shortening interplanetary transit times, and decreasing overall mission risk. Over the past year, every vehicle element has manufactured or tested hardware. An RS-25 liquid propellant engine was hotfire-tested at NASA's Stennis Space Center, Miss. for the first time since 2009 exercising and validating the new engine controller, the renovated A-1 test stand, and the test teams. Four RS-25s will power the SLS core stage. A qualification five-segment solid rocket motor incorporating several design, material, and process changes was scheduled to be test-fired in March at the prime contractor's facility in Utah. The booster also successfully completed its Critical Design Review (CDR) validating the planned design. All six major manufacturing tools for the core stage are in place at the Michoud Assembly Facility in Louisiana, and have been used to build numerous pieces of confidence, qualification, and even flight hardware, including barrel sections, domes and rings used to assemble the world's largest rocket stage. SLS Systems Engineering accomplished several key tasks including vehicle avionics software and hardware build and testing, scale model acoustic and base heating tests. Construction of the Interim Cryogenic Propulsion Stage (ICPS) began. Advanced development provided a look into the future of SLS. Shell buckling knockdown factor testing refined decades-old design margins that added thousands of pounds to rocket payloads. Adaptive manufacturing and structured light scanning development promised to cut the cost and time associated with manufacturing and testing. This paper will provide an overview of the progress made over the past year and provide a glimpse of 2015 milestones and beyond on the way to the first launch in 2018.

May, Todd↗
NASA NTRS2014

Interim Land Use Control Implementation Plan

This Interim Land Use Control Implementation Plan (LUCIP) has been prepared to inform current and potential future users of the Kennedy Space Center (KSC) Contractors Road Heavy Equipment (CRHE) Area (SWMU 055; "the Site") of institutional controls that have been implemented at the Site1. Although there are no current unacceptable risks to human health or the environment associated with the CRHE Area, an interim institutional land use control (LUC) is necessary to prevent human health exposure to volatile organic compound (VOC)-affected groundwater at the Site. Controls will include periodic inspection, condition certification, and agency notification.

Implementation↗
NASA NTRS2010

Post-Shuttle EVA Operations on ISS

The EVA hardware used to assemble and maintain the ISS was designed with the assumption that it would be returned to Earth on the Space Shuttle for ground processing, refurbishment, or failure investigation (if necessary). With the retirement of the Space Shuttle, a new concept of operations was developed to enable EVA hardware (EMU, Airlock Systems, EVA tools, and associated support equipment and consumables) to perform ISS EVAs until 2016 and possibly beyond to 2020. Shortly after the decision to retire the Space Shuttle was announced, NASA and the One EVA contractor team jointly initiated the EVA 2010 Project. Challenges were addressed to extend the operating life and certification of EVA hardware, secure the capability to launch EVA hardware safely on alternate launch vehicles, and protect EMU hardware operability on orbit for long durations.

West, Bill↗
NASA NTRS2016

The Role of Probabilistic Design Analysis Methods in Safety and Affordability

For the last several years, NASA and its contractors have been working together to build space launch systems to commercialize space. Developing commercial affordable and safe launch systems becomes very important and requires a paradigm shift. This paradigm shift enforces the need for an integrated systems engineering environment where cost, safety, reliability, and performance need to be considered to optimize the launch system design. In such an environment, rule based and deterministic engineering design practices alone may not be sufficient to optimize margins and fault tolerance to reduce cost. As a result, introduction of Probabilistic Design Analysis (PDA) methods to support the current deterministic engineering design practices becomes a necessity to reduce cost without compromising reliability and safety. This paper discusses the importance of PDA methods in NASA's new commercial environment, their applications, and the key role they can play in designing reliable, safe, and affordable launch systems. More specifically, this paper discusses: 1) The involvement of NASA in PDA 2) Why PDA is needed 3) A PDA model structure 4) A PDA example application 5) PDA link to safety and affordability.

Safie, Fayssal M.↗
NASA NTRS2016

Bumper 3 Update for IADC Protection Manual

The Bumper code has been the standard in use by NASA and contractors to perform meteoroid/debris risk assessments since 1990. It has undergone extensive revisions and updates [NASA JSC HITF website; Christiansen et al., 1992, 1997]. NASA Johnson Space Center (JSC) has applied BUMPER to risk assessments for Space Station, Shuttle, Mir, Extravehicular Mobility Units (EMU) space suits, and other spacecraft (e.g., LDEF, Iridium, TDRS, and Hubble Space Telescope). Bumper continues to be updated with changes in the ballistic limit equations describing failure threshold of various spacecraft components, as well as changes in the meteoroid and debris environment models. Significant efforts are expended to validate Bumper and benchmark it to other meteoroid/debris risk assessment codes. Bumper 3 is a refactored version of Bumper II. The structure of the code was extensively modified to improve maintenance, performance and flexibility. The architecture was changed to separate the frequently updated ballistic limit equations from the relatively stable common core functions of the program. These updates allow NASA to produce specific editions of the Bumper 3 that are tailored for specific customer requirements. The core consists of common code necessary to process the Micrometeoroid and Orbital Debris (MMOD) environment models, assess shadowing and calculate MMOD risk. The library of target response subroutines includes a board range of different types of MMOD shield ballistic limit equations as well as equations describing damage to various spacecraft subsystems or hardware (thermal protection materials, windows, radiators, solar arrays, cables, etc.). The core and library of ballistic response subroutines are maintained under configuration control. A change in the core will affect all editions of the code, whereas a change in one or more of the response subroutines will affect all editions of the code that contain the particular response subroutines which are modified. Note that the Bumper II program is no longer maintained or distributed by NASA.

Christiansen, Eric L.↗
NASA NTRS2004

Lessons Learned Study Final Report for the Exploration Systems Mission Directorate

This report is the final product of a 90-day study performed for the Exploration Systems Mission Directorate. The study was to assemble lessons NASA has learned from previous programs that could help the Exploration Systems Mission Directorate pursue the Exploration vision. It focuses on those lessons that should have the greatest significance to the Directorate during the formulation of program and mission plans. The study team reviewed a large number of lessons learned reports and data bases, including the Columbia Accident Investigation Board and Rogers Commission reports on the Shuttle accidents, accident reports from robotic space flight systems, and a number of management reviews by the Defense Sciences Board, Government Accountability Office, and others. The consistency of the lessons, findings, and recommendations validate the adequacy of the data set. In addition to reviewing existing databases, a series of workshops was held at each of the NASA centers and headquarters that included senior managers from the current workforce as well as retirees. The full text of the workshop reports is included in Appendix A. A lessons learned website was opened up to permit current and retired NASA personnel and on-site contractors to input additional lessons as they arise. These new lessons, when of appropriate quality and relevance, will be brought to the attention of managers. The report consists of four parts: Part 1 provides a small set of lessons, called the Executive Lessons Learned, that represent critical lessons that the Exploration Systems Mission Directorate should act on immediately. This set of Executive Lessons and their supporting rationale have been reviewed at length and fully endorsed by a team of distinguished NASA alumni; Part 2 contains a larger set of lessons, called the Selected Lessons Learned, which have been chosen from the lessons database and center workshop reports on the basis of their specific significance and relevance to the near-term work of the Exploration Directorate. These lessons frequently support the Executive lessons but are more general in nature; Part 3 consists of the reports of the center workshops that were conducted as part of this activity. These reports are included in their entirety (approximately 200 pages) in Appendix G and have significance for specific managers; Part 4 consists of the remainder of the lessons that have been selected by this effort and assembled into a database for the use of the Explorations Directorate. The database is archived and hosted in the Lessons Learned Knowledge Network, which provides a flexible search capability using a wide variety of search terms. Finally, a spreadsheet lists databases searched and a bibliography identifies reports that have been reviewed as sources of lessons for this task. NASA has been presented with many learning opportunities. We have conducted numerous programs, some extremely successful and others total failures. Most have been documented with a formal lessons learned activity, but we have not always incorporated these learning opportunities into our normal modes of business. For example, the Robbins Report of 2001 clearly indicates that many project failures of the past two decades were the result of violating well documented best practices, often in direct violation of management instructions and directives. An overarching lesson emerges: that disciplined execution in accordance with proven best practices is the greatest single contributor to a successful program. The Lessons Learned task team offers a sincere hope that the lessons presented herein will be helpful to the Exploration Systems Directorate in charting and executing their course. The success of the Directorate and of NASA in general depends on our collective ability to move forward without having to relearn the lessons of those who have gone before.

Van Laak, Jim↗
NASA NTRS2015

Data Concentrator

Orbital Research, Inc., developed, built, and tested three high-temperature components for use in the design of a data concentrator module in distributed turbine engine control. The concentrator receives analog and digital signals related to turbine engine control and communicates with a full authority digital engine control (FADEC) or high-level command processor. This data concentrator follows the Distributed Engine Controls Working Group (DECWG) roadmap for turbine engine distributed controls communication development that operates at temperatures at least up to 225 C. In Phase I, Orbital Research developed detailed specifications for each component needed for the system and defined the total system specifications. This entailed a combination of system design, compiling existing component specifications, laboratory testing, and simulation. The results showed the feasibility of the data concentrator. Phase II of this project focused on three key objectives. The first objective was to update the data concentrator design modifications from DECWG and prime contractors. Secondly, the project defined requirements for the three new high-temperature, application-specific integrated circuits (ASICs): one-time programmable (OTP), transient voltage suppression (TVS), and 3.3V. Finally, the project validated each design by testing over temperature and under load.

Willett, Mike↗
NASA NTRS2016

Tethered Space Satellite-1 (TSS-1): Wound About a Bolt

In the early 1990's US and Italian scientists collaborated to study the electrodynamics on a long tether between two satellites as it moved through the electrically charged portion of Earth's atmosphere called the ionosphere. Potential uses for the electrical current induced in the long wire include power and thrust generation for a satellite, momentum exchange, artificial gravity, deployment of sensors or antennas, and gravity-gradient stabilization. The Tethered Space Satellite (TSS) was a first-of-its-kind experiment with long tethers in space. It consisted of a satellite with science experiments attached to a 12.5 mile long, very thin (0.10 inch diameter) copper wire assembly wound around a spool in the deployer reel mechanism. The whole mechanism sits on a pallet that is installed into the Shuttle bay. At an altitude of 160 nautical miles above earth, the satellite would be deplodeployed from the Shuttle bay by raising it on a boom facing away from Earth. Once cleared of the bay, the deployer mechanism would slowly feed out the 12-plus miles of tether. Scientific data would be collected throughout the operation, after which the satellite would be reeled back in. A receiver spool to catch the 12.5 mile tether as it was being unwound by the deployer reel mechanism was set up to do the system-level test of deployer real mechanism prior to installing the loaded pallet into the Shuttle bay. The system level tests were required before the pallet could be installed into the Space Shuttle cargo bay. A few months before flight, the system level tests, including unreeling and reeling the tether, were completed at Kennedy Space Center (KSC) and the TSS payload was installed onto the Spacelab pallet. Some of this testing equipment was then shipped back to the contractor, Martin Marietta. Integration with the Shuttle began. Systems-level load analyses, which cannot be run until all information about each payload is finalized, was run in parallel with the physical integration of the hardware into the Shuttle payload bay. An analysis, called Coupled loads analysis, incorporates any updates to the model due to system level tests of all the different payloads, and any changes that were found during integration. Engineering analysis examines the worst case scenarios for the loads the hardware will see. The two times during the mission where the dynamic loads are the worst were 1) the first 10-second portion of Shuttle lift off, and 2) a 2-second time during landing when the landing gears hit the ground. The coupled loads analysis using the final verification loads showed that a single bolt attaching the deployer reel mechanism to the support structure had a "negative margin" - which is an indication that it might fail - during touch down. Hardware certification rules do not allow for hardware to fly with negative margins. A structural failure of one payload could have serious or catastrophic consequences to other payloads, or may significantly damage the Orbiter. The issue had to be resolved before the flight.

O'Connor, Brian↗
NASA NTRS2016

Tethered Space Satellite-1 (TSS-1): Technical Roundabouts

In the early 1990's US and Italian scientists collaborated to study the electrodynamics of dragging a satellite on a tether through the electrically charged portion of Earth's atmosphere called the ionosphere. An electrical current induced in the long wire could be used for power and thrust generation for a satellite. Other tether uses include momentum exchange, artificial gravity, deployment of sensors or antennas, and gravity-gradient stabilization for satellites. Before the Tethered Space Satellite (TSS-1), no long tether had ever been flown, so many questions existed on how it would actually behave. The TSS consisted of a satellite with science experiments attached to a 12.5 mile long, very thin (0.10 inch diameter) copper wire assembly wound around a spool in the deployer reel mechanism. With the Space Shuttle at an altitude of 160 nautical miles above earth, the satellite was to be deployed by raising it from the Shuttle bay on a boom facing away from Earth. Once cleared of the bay, the deployer mechanism was to slowly feed out the 12-plus miles of tether. Scientific data would be collected throughout the operation, after which the satellite would be reeled back in. Pre-flight testing system level tests involved setting up a tether receiver to catch the 12.5 mile tether onto another reel as it was being unwound by the deployer reel mechanism. Testing only the reel mechanism is straightforward. This test becomes more complicated when the TSS is mounted on the flight pallet at Kennedy Space Center (KSC). The system level tests must be passed before the pallet can be installed into the Space Shuttle cargo bay. A few months before flight, the TSS payload had been integrated onto the Spacelab pallet and system level tests, including unreeling and reeling the tether, had been successfully completed. Some of this testing equipment was then shipped back to the contractor Martin Marietta. Systems-level load analyses, which cannot be run until all information about each payload is finalized, was run in parallel with the physical integration of the hardware into the Shuttle payload bay. The coupled loads analysis, as it is called, incorporates any updates to the model due to system level tests, and any changes that were found during integration. The coupled loads analysis revealed that a single bolt attaching the deployer reel mechanism to the support structure had a "negative margin" - which is an indication that it might fail during operation. Hardware certification rules do not allow for hardware to fly with negative margins, so this issue had to be resolved before the flight. Since there is conservatism in engineering analysis, there is an option to "waive" the margin requirement, and fly the experiment as is. On the other hand, a structural failure of one payload could have serious or catastrophic consequences to other payloads and possibly the mission. Minor design changes or fixes might be feasible within the payload bay prior to launch. Any major design changes that required the spooling test to validate the hardware, or for the pallet to be removed, would cause TSS not to be ready for the Shuttle launch.

O'Connor, Brian↗
NASA NTRS2015

On the X-34 FASTRAC-Memorandums of Misunderstanding

Engineers at MSFC designed, developed, and tested propulsion systems that helped launch Saturn I, IB, and V boosters for the Apollo missions. After the Apollo program, Marshall was responsible for the design and development of the propulsion elements for the Shuttle launch vehicle, including the solid rocket boosters, external tank and main engines. Each of these systems offered new propulsion technological challenges that pushed engineers and administrators beyond Saturn. The technical challenges presented by the development of each of these propulsion systems helped to establish and sustain a culture of engineering conservatism and was often accompanied by a deep level of penetration into contractors that worked on these systems.

Hawkins, Lakiesha V.↗
NASA NTRS2016

A Tailored Concept of Operations for NASA LSP Integrated Operations

An integral part of the Systems Engineering process is the creation of a Concept of Operations (ConOps) for a given system, with the ConOps initially established early in the system design process and evolved as the system definition and design matures. As Integration Engineers in NASA's Launch Services Program (LSP) at Kennedy Space Center (KSC), our job is to manage the interface requirements for all the robotic space missions that come to our Program for a Launch Service. LSP procures and manages a launch service from one of our many commercial Launch Vehicle Contractors (LVCs) and these commercial companies are then responsible for developing the Interface Control Document (ICD), the verification of the requirements in that document, and all the services pertaining to integrating the spacecraft and launching it into orbit. However, one of the systems engineering tools that have not been employed within LSP to date is a Concept of Operations. The goal of this project is to research the format and content that goes into these various aerospace industry ConOps and tailor the format and content into template form, so the template may be used as an engineering tool for spacecraft integration with future LSP procured launch services.

Systems↗
NASA NTRS2016

Human Factors Checklist: Think Human Factors - Focus on the People

A quick-look Human Factors (HF) Checklist condenses industry and NASA Agency standards consisting of thousands of requirements into 14 main categories. With support from contractor HF and Safety Practitioners, NASA developed a means to share key HF messages with Design, Engineering, Safety, Project Management, and others. It is often difficult to complete timely assessments due to the large volume of HF information. The HF Checklist evolved over time into a simple way to consider the most important concepts. A wide audience can apply the checklist early in design or through planning phases, even before hardware or processes are finalized or implemented. The checklist is a good place to start to supplement formal HF evaluation. The HF Checklist was based on many Space Shuttle processing experiences and lessons learned. It is now being applied to ground processing of new space vehicles and adjusted for new facilities and systems.

Human Factors; Human Systems Integration↗
NASA NTRS2016

Safety Characteristics in System Application of Software for Human Rated Exploration Missions for the 8th IAASS Conference

NASA and its industry and international partners are embarking on a bold and inspiring development effort to design and build an exploration class space system. The space system is made up of the Orion system, the Space Launch System (SLS) and the Ground Systems Development and Operations (GSDO) system. All are highly coupled together and dependent on each other for the combined safety of the space system. A key area of system safety focus needs to be in the ground and flight application software system (GFAS). In the development, certification and operations of GFAS, there are a series of safety characteristics that define the approach to ensure mission success. This paper will explore and examine the safety characteristics of the GFAS development. The GFAS system integrates the flight software packages of the Orion and SLS with the ground systems and launch countdown sequencers through the 'agile' software development process. A unique approach is needed to develop the GFAS project capabilities within this agile process. NASA has defined the software development process through a set of standards. The standards were written during the infancy of the so-called industry 'agile development' movement and must be tailored to adapt to the highly integrated environment of human exploration systems. Safety of the space systems and the eventual crew on board is paramount during the preparation of the exploration flight systems. A series of software safety characteristics have been incorporated into the development and certification efforts to ensure readiness for use and compatibility with the space systems. Three underlining factors in the exploration architecture require the GFAS system to be unique in its approach to ensure safety for the space systems, both the flight as well as the ground systems. The first are the missions themselves, which are exploration in nature, and go far beyond the comfort of low Earth orbit operations. The second is the current exploration system will launch only one mission per year even less during its developmental phases. Finally, the third is the partnered approach through the use of many different prime contractors, including commercial and international partners, to design and build the exploration systems. These three factors make the challenges to meet the mission preparations and the safety expectations extremely difficult to implement. As NASA leads a team of partners in the exploration beyond earth's influence, it is a safety imperative that the application software used to test, checkout, prepare and launch the exploration systems put safety of the hardware and mission first. Software safety characteristics are built into the design and development process to enable the human rated systems to begin their missions safely and successfully. Exploration missions beyond Earth are inherently risky, however, with solid safety approaches in both hardware and software, the boldness of these missions can be realized for all on the home planet.

capability↗
NASA NTRS2016

CASIS Fact Sheet: Hardware and Facilities

Vencore is a proven information solutions, engineering, and analytics company that helps our customers solve their most complex challenges. For more than 40 years, we have designed, developed and delivered mission-critical solutions as our customers' trusted partner. The Engineering Services Contract, or ESC, provides engineering and design services to the NASA organizations engaged in development of new technologies at the Kennedy Space Center. Vencore is the ESC prime contractor, with teammates that include Stinger Ghaffarian Technologies, Sierra Lobo, Nelson Engineering, EASi, and Craig Technologies. The Vencore team designs and develops systems and equipment to be used for the processing of space launch vehicles, spacecraft, and payloads. We perform flight systems engineering for spaceflight hardware and software; develop technologies that serve NASA's mission requirements and operations needs for the future. Our Flight Payload Support (FPS) team at Kennedy Space Center (KSC) provides engineering, development, and certification services as well as payload integration and management services to NASA and commercial customers. Our main objective is to assist principal investigators (PIs) integrate their science experiments into payload hardware for research aboard the International Space Station (ISS), commercial spacecraft, suborbital vehicles, parabolic flight aircrafts, and ground-based studies. Vencore's FPS team is AS9100 certified and a recognized implementation partner for the Center for Advancement of Science in Space (CASIS

Solomon, Michael R.↗
NASA NTRS2015

Lightning Protection and Structural Bonding for the B2 Test Stand

With the privatization of the space industry, NASA has entered a new era. To explore deeper parts of the solar system, NASA is developing a new spacecraft, the Space Launch System (SLS), capable of reaching these destinations, such as an asteroid or Mars. However, the test stand that is capable of testing the stage has been unused for many years. In addition to the updating/repair of the stand, more steel is being added to fully support the SLS. With all these modifications, the lightning protection system must be brought up to code to assure the protection of all personnel and assets. Structural bonding is a part of the lightning protection system. The focus of this project was to assure proper structural bonding. To begin, all relevant technical standards and the construction specifications were reviewed. This included both the specifications for the lightning protection and for general construction. The drawings were reviewed as well. From the drawings, bolted structural joints were reviewed to determine whether bonding was necessary. Several bolted joints were determined to need bonding according to the notes in the drawings. This exceeds the industry standards. The bolted joints are an electrically continuous joint. During tests, the stand experiences heavy vibration that may weaken the continuity of the bolted joint. Therefore, the secondary bonding is implemented to ensure that the structural joint has low resistance. If the structural joint has a high resistance because of corrosion, a potential gradient can occur that can cause a side flash. Damage, injury, or death can occur from a side flash so they are to be prevented. A list of the identified structural joints was compiled and sent to the contractor to be bonded. That covers the scope of this project.

Kinard, Brandon↗
NASA NTRS2016

NASA Space Flight Vehicle Fault Isolation Challenges

The Space Launch System (SLS) is the new NASA heavy lift launch vehicle and is scheduled for its first mission in 2017. The goal of the first mission, which will be uncrewed, is to demonstrate the integrated system performance of the SLS rocket and spacecraft before a crewed flight in 2021. SLS has many of the same logistics challenges as any other large scale program. Common logistics concerns for SLS include integration of discrete programs geographically separated, multiple prime contractors with distinct and different goals, schedule pressures and funding constraints. However, SLS also faces unique challenges. The new program is a confluence of new hardware and heritage, with heritage hardware constituting seventy-five percent of the program. This unique approach to design makes logistics concerns such as testability of the integrated flight vehicle especially problematic. The cost of fully automated diagnostics can be completely justified for a large fleet, but not so for a single flight vehicle. Fault detection is mandatory to assure the vehicle is capable of a safe launch, but fault isolation is another issue. SLS has considered various methods for fault isolation which can provide a reasonable balance between adequacy, timeliness and cost. This paper will address the analyses and decisions the NASA Logistics engineers are making to mitigate risk while providing a reasonable testability solution for fault isolation.

Bramon, Christopher↗
NASA NTRS2013

Origins and Early History of Underwater Neutral Buoyancy Simulation of Weightlessness for EVA Procedures Development and Training: Winnowing and Regrowth - Part 2

The technique of neutral buoyancy during water immersion was applied to a variety of questions pertaining to human performance factors in the early years of the space age. It was independently initiated by numerous aerospace contractors at nearly the same time, but specific applications depended on the problems that the developers were trying to solve. Those problems dealt primarily with human restraint and maneuverability and were often generic across extravehicular activity (EVA) and intravehicular activity (IVA) worksites. The same groups often also considered fractional gravity as well as weightless settings and experimented with ballasting to achieve lunar and Mars-equivalent loads as part of their on-going research and development. Dr. John Charles reviewed the association of those tasks with contemporary perceptions of the direction of NASA's future space exploration activities and with Air Force assessments of the military value of man in space.

Charles, John B.↗