SEARCH · Engineering Papers

Results for “Failing Safely”

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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

295 records · Page 17

All sources NASA NTRS DOE OSTI

NASA NTRS2008

Leading Your Leaders

Even though working on a problem has been your primary effort for the past year, your leadership may have heard about this once in a briefing a decade ago. Now they are basically clueless. Pretend that you are talking to your daughter's fifth-grade class. Explain how your complicated gizmo works. If possible, do not use acronyms. Define your terms. Put your work in context. Assume your leader has no idea what you do, who you work for, or what your gizmo does. That is a good place to start. Remember, taking the next century to study the problem or spending the Gross National Product to invent a new solution are probably not going to be acceptable solutions. Real engineers and technicians build real hardware that works in the real world in a reasonable manner within a reasonable time at a reasonable cost. True, skimping on time or money can cause mistakes, but folks whose gizmos are delayed unreasonably or cost more than is practical get their programs canceled, force the business into bankruptcy, or give the market over to the competition. Real engineers and technicians always consider cost and schedule in their work. Raising questions is important. However, we are in the business of doing things. Engineers and technicians are paid to get things done. Yes, you have to identify the problem, frame the design, identify the tests, perform the analysis, and assemble the hardware. But the goal is to solve the problem. Nobody ever said flying in space was easy. We make it look easy the same way that an Olympic champion makes her sport look easy: by working hard at improving performance every day. Better are the results of a well-defined test. Remember that a test on a laboratory bench is always an approximation of reality, and rules similar to those for good analysis also apply. One should always be mindful of Mechelay's rule: "It is better to be stupid than to run a stupid test." Often we try to overtest. If a piece of hardware passes an unbelievably difficult test, then life is good. More often when an unbelievably difficult test fails, we are left with a very long discussion of why and what was wrong in the design or execution of the test. Make sure that the test is well defined. Even then, it is important to explain to your leaders what inherent accuracy (or error) the test conditions or equipment have and what the assumptions or initial conditions were for the test. Test results without a good understanding of the test's accuracy or the pedigree of the test assumptions are worth very little. Finally, there is flight test data. Always limited, never at the edge of the envelope, it still shows how the real hardware works in a combined environment. Flight experience is dangerous because it typically doesn't show how close to the edge of the cliff the equipment is operating, but it does demonstrate how the hardware really works. A flight test is the ultimate test, again taken with the knowledge that it is probably not the extreme but something more like the middle of the environmental and systems performance. Good understanding of a problem and its solution always relies on a combination of all these methods. Be sure to lead your leaders by using all the tools you have at your disposal. At the end of the day, decisions in space flight always come down to a risk trade. Our business is not remotely safe, not in the sense that the public, the media, or our legislators use the term. Everything we do has a risk, cost, schedule, or performance trade-off. For your leaders to make an appropriate decision, you need to educate them, lead them, talk with them, and engage them in the discussion until full understanding takes place. It's your job. *

Hale, Wayne N.↗

NASA NTRS1996

Cross-Cultural Barriers to Effective Communication in Aviation

Communication is essential to safe flight, as evidenced by several accidents in which crew communicates was found to have contributed to the accidents. This chapter documents the essential role of explicit efficient communication to flight safety with a global context. It addresses communication between flight crews and air traffic controllers in regions a the world where pilots and controllers speak different native languages, as well as cases in which crew members within the flight deck represent different native languages and cultures. It also addresses problems associated with "exporting" crew resource management training programs to parts of the world which values and norms differ from those of the United States, where these programs were initially developed. This chapter is organized around several central questions: (1) What are various kinds of communication failures and what are their consequences; (2) What are the causes of communication failure; (3) What are features of effective crew communication; (4) What can be done to enhance communication success? To explore a wider range of communication failures than available from accident reports, we examined a set of incident reports from the Aviation Safety Reporting System. These could be classified into three major categories: those in which language actually interfered with transmission of a message; those in which transmission was adequate but the context was not expressed unambiguously and thus the message received was not the same as the message intended; and those in which the message was received as intended, but was not adequately understood or acted upon, mainly because of cultural factors. The consequences of failed communication can be flight errors (such as when a clearance is not received correctly), loss of situation awareness, or failure of crew members (or ATC and pilots) to build a shared understanding of a situation. Causes of misunderstanding can be traced to a number of sources, often grounded in faulty assumptions held by one or both parties to a conversation. Speakers and listeners often experience "illusionary understanding" in which they think they understand each other, but in fact do not. While this problem can exist within a single culture, it is much more serious across cultures. Training in effective explicit communication is a component of Crew Resource Management training programs developed in the U.S. These programs are being adopted by airlines around the world, with varying degrees of success. The level of success in part depends on how similar the conversational and social styles of those cultures are to those of the U.S. A factor that influences conversational style is a culture's relative positioned on two major dimensions that distinguish national cultural groups: individualism vs. collectivism and degree of power distance. The chapter concludes with a discussion of techniques for overcoming the various classes of communication failures and for effectively adapting training programs to fit the values and norms of cultures around the globe.

Fischer, U.↗

NASA NTRS2007

Testing of Full Scale Flight Qualified Kevlar Composite Overwrapped Pressure Vessels

Many decades ago NASA identified a need for low-mass pressure vessels for carrying various fluids aboard rockets, spacecraft, and satellites. A pressure vessel design known as the composite overwrapped pressure vessel (COPV) was identified to provide a weight savings over traditional single-material pressure vessels typically made of metal and this technology has been in use for space flight applications since the 1970's. A typical vessel design consisted of a thin liner material, typically a metal, overwrapped with a continuous fiber yarn impregnated with epoxy. Most designs were such that the overwrapped fiber would carry a majority of load at normal operating pressures. The weight advantage for a COPV versus a traditional singlematerial pressure vessel contributed to widespread use of COPVs by NASA, the military, and industry. This technology is currently used for personal breathing supply storage, fuel storage for auto and mass transport vehicles and for various space flight and aircraft applications. The NASA Engineering and Safety Center (NESC) was recently asked to review the operation of Kevlar 2 and carbon COPVs to ensure they are safely operated on NASA space flight vehicles. A request was made to evaluate the life remaining on the Kevlar COPVs used on the Space Shuttle for helium and nitrogen storage. This paper provides a review of Kevlar COPV testing relevant to the NESC assessment. Also discussed are some key findings, observations, and recommendations that may be applicable to the COPV user community. Questions raised during the investigations have revealed the need for testing to better understand the stress rupture life and age life of COPVs. The focus of this paper is to describe burst testing of Kevlar COPVs that has been completed as a part of an the effort to evaluate the effects of ageing and shelf life on full scale COPVs. The test articles evaluated in this discussion had a diameter of 22 inches for S/N 014 and 40 inches for S/N 011. The time between manufacture and burst was 28 and 22 years. Visual inspection, shearography, heat soak thermography and borescope inspection were performed on vessel S/N 011 and all but shearography was performed on S/N 014 before they were tested and details of this work can be found in a companion paper titled, "Nondestructive Methods and Special Test Instrumentation Supporting NASA Composite Overwrapped Pressure Vessel Assessments." The vessels were instrumented so that measurements could be made to aid in the understanding of vessel response. Measurements made on the test articles included girth, boss displacement, internal volume, multiple point strain, full field strain, eddy current, acoustic emission (AE) pressure and temperature. The test article before and during burst is shown with the pattern used for digital image correlation full field strain measurement blurring as the vessel fails.

Greene, Nathanael↗

NASA NTRSDate not supplied

A System to Provide Deterministic Flight Software Operation and Maximize Multicore Processing Performance: The Safe and Precise Landing – Integrated Capabilities Evolution (SPLICE) Datapath

A method and design are described for a system that processes multiple data streams, utilizing a multicore asymmetric processing architecture, that eliminates data interrupts to the application processors. The design supports a deterministic environment for flight software in NASA’s Safe and Precise Landing – Integrated Capabilities Evolution (SPLICE) project. The SPLICE project develops sensor, algorithm, and compute technologies for Precision Landing and Hazard Avoidance (PL&HA) capabilities. The compute technology for SPLICE is the Descent and Landing Computer (DLC). The DLC hosts several SPLICE algorithms with high computational resource requirements that must be executed in a real-time and deterministic manner. The software runs on a custom Single Board Computer (SBC), with a Xilinx Ultrascale+ Multiprocessor System-on-a-Chip (MPSoC). Input data for the flight software is from a variety of sensors, unique with respect to data rate and packet size. A data path between the SPLICE sensors and algorithms is designed to efficiently deliver this data to the flight software using the MPSoC asymmetric processing cores and Field Programmable Gate Array (FPGA) fabric. This is implemented in a manner that isolates the application processors running the flight software from interrupts associated with the input data. By leveraging real-time processors on the MPSoC, and a structure with the appropriate interfaces in the shared memory on the SBC, the flight software can use the full set of application processors. The available utilization for each processor in this set is also maximized for the SPLICE applications, providing a sufficiently deterministic execution environment without the cost and overhead of a real-time operating system.

heterogeneous processing system↗

NASA NTRS2023

A System to Provide Deterministic Flight Software Operation and Maximize Multicore Processing Performance: The Safe and Precise Landing – Integrated Capabilities Evolution (SPLICE) Datapath

David K. Rutishauser↗

NASA NTRS2008

Sensor Selection and Data Validation for Reliable Integrated System Health Management

For new access to space systems with challenging mission requirements, effective implementation of integrated system health management (ISHM) must be available early in the program to support the design of systems that are safe, reliable, highly autonomous. Early ISHM availability is also needed to promote design for affordable operations; increased knowledge of functional health provided by ISHM supports construction of more efficient operations infrastructure. Lack of early ISHM inclusion in the system design process could result in retrofitting health management systems to augment and expand operational and safety requirements; thereby increasing program cost and risk due to increased instrumentation and computational complexity. Having the right sensors generating the required data to perform condition assessment, such as fault detection and isolation, with a high degree of confidence is critical to reliable operation of ISHM. Also, the data being generated by the sensors needs to be qualified to ensure that the assessments made by the ISHM is not based on faulty data. NASA Glenn Research Center has been developing technologies for sensor selection and data validation as part of the FDDR (Fault Detection, Diagnosis, and Response) element of the Upper Stage project of the Ares 1 launch vehicle development. This presentation will provide an overview of the GRC approach to sensor selection and data quality validation and will present recent results from applications that are representative of the complexity of propulsion systems for access to space vehicles. A brief overview of the sensor selection and data quality validation approaches is provided below. The NASA GRC developed Systematic Sensor Selection Strategy (S4) is a model-based procedure for systematically and quantitatively selecting an optimal sensor suite to provide overall health assessment of a host system. S4 can be logically partitioned into three major subdivisions: the knowledge base, the down-select iteration, and the final selection analysis. The knowledge base required for productive use of S4 consists of system design information and heritage experience together with a focus on components with health implications. The sensor suite down-selection is an iterative process for identifying a group of sensors that provide good fault detection and isolation for targeted fault scenarios. In the final selection analysis, a statistical evaluation algorithm provides the final robustness test for each down-selected sensor suite. NASA GRC has developed an approach to sensor data qualification that applies empirical relationships, threshold detection techniques, and Bayesian belief theory to a network of sensors related by physics (i.e., analytical redundancy) in order to identify the failure of a given sensor within the network. This data quality validation approach extends the state-of-the-art, from red-lines and reasonableness checks that flag a sensor after it fails, to include analytical redundancy-based methods that can identify a sensor in the process of failing. The focus of this effort is on understanding the proper application of analytical redundancy-based data qualification methods for onboard use in monitoring Upper Stage sensors.

Garg, Sanjay↗

NASA NTRS2009

Cooperative Three-Robot System for Traversing Steep Slopes

Teamed Robots for Exploration and Science in Steep Areas (TRESSA) is a system of three autonomous mobile robots that cooperate with each other to enable scientific exploration of steep terrain (slope angles up to 90 ). Originally intended for use in exploring steep slopes on Mars that are not accessible to lone wheeled robots (Mars Exploration Rovers), TRESSA and systems like TRESSA could also be used on Earth for performing rescues on steep slopes and for exploring steep slopes that are too remote or too dangerous to be explored by humans. TRESSA is modeled on safe human climbing of steep slopes, two key features of which are teamwork and safety tethers. Two of the autonomous robots, denoted Anchorbots, remain at the top of a slope; the third robot, denoted the Cliffbot, traverses the slope. The Cliffbot drives over the cliff edge supported by tethers, which are payed out from the Anchorbots (see figure). The Anchorbots autonomously control the tension in the tethers to counter the gravitational force on the Cliffbot. The tethers are payed out and reeled in as needed, keeping the body of the Cliffbot oriented approximately parallel to the local terrain surface and preventing wheel slip by controlling the speed of descent or ascent, thereby enabling the Cliffbot to drive freely up, down, or across the slope. Due to the interactive nature of the three-robot system, the robots must be very tightly coupled. To provide for this tight coupling, the TRESSA software architecture is built on a combination of (1) the multi-robot layered behavior-coordination architecture reported in "An Architecture for Controlling Multiple Robots" (NPO-30345), NASA Tech Briefs, Vol. 28, No. 10 (October 2004), page 65, and (2) the real-time control architecture reported in "Robot Electronics Architecture" (NPO-41784), NASA Tech Briefs, Vol. 32, No. 1 (January 2008), page 28. The combination architecture makes it possible to keep the three robots synchronized and coordinated, to use data from all three robots for decision- making at each step, and to control the physical connections among the robots. In addition, TRESSA (as in prior systems that have utilized this architecture) , incorporates a capability for deterministic response to unanticipated situations from yet another architecture reported in Control Architecture for Robotic Agent Command and Sensing (NPO-43635), NASA Tech Briefs, Vol. 32, No. 10 (October 2008), page 40. Tether tension control is a major consideration in the design and operation of TRESSA. Tension is measured by force sensors connected to each tether at the Cliffbot. The direction of the tension (both azimuth and elevation) is also measured. The tension controller combines a controller to counter gravitational force and an optional velocity controller that anticipates the motion of the Cliffbot. The gravity controller estimates the slope angle from the inclination of the tethers. This angle and the weight of the Cliffbot determine the total tension needed to counteract the weight of the Cliffbot. The total needed tension is broken into components for each Anchorbot. The difference between this needed tension and the tension measured at the Cliffbot constitutes an error signal that is provided to the gravity controller. The velocity controller computes the tether speed needed to produce the desired motion of the Cliffbot. Another major consideration in the design and operation of TRESSA is detection of faults. Each robot in the TRESSA system monitors its own performance and the performance of its teammates in order to detect any system faults and prevent unsafe conditions. At startup, communication links are tested and if any robot is not communicating, the system refuses to execute any motion commands. Prior to motion, the Anchorbots attempt to set tensions in the tethers at optimal levels for counteracting the weight of the Cliffbot; if either Anchorbot fails to reach its optimal tension level within a specified time, it sends message to the other robots and the commanded motion is not executed. If any mechanical error (e.g., stalling of a motor) is detected, the affected robot sends a message triggering stoppage of the current motion. Lastly, messages are passed among the robots at each time step (10 Hz) to share sensor information during operations. If messages from any robot cease for more than an allowable time interval, the other robots detect the communication loss and initiate stoppage.

Stroupe, Ashley↗