Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Software and System Safety”

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 415 records · Page 23
All sourcesNASA NTRSDOE OSTI
NASA NTRS2003

System for Centering a Turbofan in a Nacelle During Tests

A feedback position-control system has been developed for maintaining the concentricity of a turbofan with respect to a nacelle during acoustic and flow tests in a wind tunnel. The system is needed for the following reasons: Thermal and thrust loads can displace the fan relative to the nacelle; In the particular test apparatus (see Figure 1), denoted as a rotor-only nacelle (RAN), the struts, vanes, and other stator components of a turbofan engine that ordinarily maintain the required concentricity in the face of thermal and thrust loads are not present; and The struts and stator components are not present because it is necessary to provide a flow path that is acoustically clean in the sense that the measured noise can be attributed to the fan alone. The system is depicted schematically in Figure 2. The nacelle is supported by two struts attached to a two-axis traverse table located outside the wind-tunnel wall. Two servomotors acting through 100:1 gearboxes drive the table along the Y and Z axes, which are perpendicular to the axis of rotation. The Y and Z components of the deviation from concentricity are measured by four laser displacement sensors mounted on the nacelle and aimed at reflective targets on the center body, which is part of the fan assembly. The outputs of the laser displacement sensors are digitized and processed through a personal computer programmed with control software. The control output of the computer commands the servomotors to move the table as needed to restore concentricity. Numerous software and hardware travel limits and alarms are provided to maximize safety. A highly ablative rub strip in the nacelle minimizes the probability of damage in the event that a deviation from concentricity exceeds the radial clearance [<0.004 in. (<0.1 mm)] between the inner surface of the nacelle and the tips of the fan blades. To be able to prevent an excursion in excess of the tip clearance, the system must be accurate enough to control X and Y displacements to within 0.001 in. (.0.025 mm). One characteristic essential to such accuracy is sufficient rigidity in the mechanical components of the system to prevent excitation of vibrations in the strut/ nacelle subsystem. The need for such a high degree of accuracy prompted a comprehensive analysis of sources of measurement and control errors, followed by rigorous design efforts to minimize these errors. As a result, the design of the system incorporates numerous improvements in hardware, software, and operational procedures.

Cunningham, Cameron C.↗
NASA NTRS2006

Transforming Our SMEX Organization by Way of Innovation, Standardization, and Automation

NASA's Small Explorer (SMEX) Flight Operations Team (FOT) is currently tackling the challenge of supporting ground operations for several satellites that have surpassed their designed lifetime and have a dwindling budget. At Goddard Space Flight Center (GSFC), these missions are presently being reengineered into a fleet-oriented ground system. When complete, this ground system will provide command and control of four SMEX missions, and will demonstrate fleet automation and control concepts as a pathfinder for additional mission integrations. A goal of this reengineering effort is to demonstrate new ground-system technologies that show promise of supporting longer mission lifecycles and simplifying component integration. In pursuit of this goal, the SMEX organization has had to examine standardization, innovation, and automation. A core technology being demonstrated in this effort is the GSFC Mission Services Evolution Center (GMSEC) architecture. The GMSEC architecture focuses on providing standard interfaces for ground system applications to promote application interoperability. Building around commercial Message Oriented Middleware and providing a common messaging standard allows GMSEC to provide the capabilities necessary to support integration of new software components into existing missions and increase the level of interaction within the system. For SMS, GMSEC has become the technology platform to transform flight operations with the innovation and automation necessary to reduce operational costs. The automation technologies supported in SMEX are built upon capabilities provided by the GMSEC architecture that allows the FOT to further reduce the involvement of the console, operator. Initially, SMEX is automating only routine operations, such as safety and health monitoring, basic commanding, and system recovery. The operational concepts being developed here will reduce the need for staffed passes and are a necessity for future fleet management. As this project continues to evolve, additional innovations beyond GMSEC and automation have, and will continue to be developed. The team developed techniques for migrating ground systems of existing on-orbit assets. The tools necessary to monitor and control software failures were integrated and tailored for operational environments. All this was done with a focus of extending fleet operations to mission beyond SMU. The result of this work is the foundation for a broader fleet-capable ground system that will include several missions supported by the Space Science Mission Operations Project.

Madden, Maureen↗
NASA NTRS2003

Rocket Engine Health Management: Early Definition of Critical Flight Measurements

The NASA led Space Launch Initiative (SLI) program has established key requirements related to safety, reliability, launch availability and operations cost to be met by the next generation of reusable launch vehicles. Key to meeting these requirements will be an integrated vehicle health management ( M) system that includes sensors, harnesses, software, memory, and processors. Such a system must be integrated across all the vehicle subsystems and meet component, subsystem, and system requirements relative to fault detection, fault isolation, and false alarm rate. The purpose of this activity is to evolve techniques for defining critical flight engine system measurements-early within the definition of an engine health management system (EHMS). Two approaches, performance-based and failure mode-based, are integrated to provide a proposed set of measurements to be collected. This integrated approach is applied to MSFC s MC-1 engine. Early identification of measurements supports early identification of candidate sensor systems whose design and impacts to the engine components must be considered in engine design.

Christenson, Rick L.↗
NASA NTRS1994

An Integrated Fault Tolerant Robotic Controller System for High Reliability and Safety

This paper describes the concepts and features of a fault-tolerant intelligent robotic control system being developed for applications that require high dependability (reliability, availability, and safety). The system consists of two major elements: a fault-tolerant controller and an operator workstation. The fault-tolerant controller uses a strategy which allows for detection and recovery of hardware, operating system, and application software failures.The fault-tolerant controller can be used by itself in a wide variety of applications in industry, process control, and communications. The controller in combination with the operator workstation can be applied to robotic applications such as spaceborne extravehicular activities, hazardous materials handling, inspection and maintenance of high value items (e.g., space vehicles, reactor internals, or aircraft), medicine, and other tasks where a robot system failure poses a significant risk to life or property.

robotics fault-tolerant control systems↗
NASA NTRS2017

Trajectory Specification for Terminal Air Traffic: Pairwise Conflict Detection and Resolution

Trajectory Specification is the explicit bounding and control of aircraft trajectories such that the position at any point in time is constrained to a precisely defined volume of space. The bounding space is defined by cross-track, along-track, and vertical tolerances relative to a reference trajectory that specifies position as a function of time. The tolerances are dynamic and will be based on the aircraft navigation capabilities and the current traffic situation. Assuming conformance, Trajectory Specification can guarantee safe separation for an arbitrary period of time even in the event of an air traffic control (ATC) system or datalink failure; hence it can help to achieve the high level of safety and reliability needed for ATC automation. It can also reduce the reliance on tactical backup systems during normal operation. This paper applies it to the terminal area around a major airport and presents algorithms and software for detecting and resolving conflicts. A representative set of pairwise conflicts was generated, and a fast-time simulation was run on them. All conflicts were successfully resolved in real time, demonstrating the computational feasibility of the concept.

terminal area↗
NASA NTRSDate not supplied

LANDO: Developing Autonomous Payload Offloading Capabilities for Lunar Surface Operations

Introduction: The Lightweight Surface Manipulation System (LSMS) AutoNomy capabilities Development for surface Operations and construction (LANDO) project is an Early Career Initiative selected for funding by NASA Space Technology Mission Directorate. LANDO is developing a general-purpose autonomy framework applicable to serial and tension-actuated manipulation agents, that will be validated using an existing prototype of the LSMS-L35 (35-kg wrist lift capacity on the lunar surface [Fig. 1], sized for a Commercial Lunar Pay-load Services (CLPS) mission). The autonomous LSMS-L35 will be used to demonstrate autonomous payload handling capabilities for Lunar and other planetary surfaces, directly addressing STMD capability gaps in autonomous excavation and construction operations, advanced robotics and spacecraft autonomy technologies, and technologies supporting emerging space industries including the In-Space Servicing, Assembly and Manufacturing national strategy. LSMS: The LSMS is a tension actuated robotic agent that is scalable (reach and lifting capacity in different gravity environments), versatile (types of surface operations), and reusable. Compared to serial arms, the LSMS provides significantly higher structural efficiency and mechanical advantage, enabling a greater payload lift capacity at a lower system mass. The LSMS is envisioned to be a crucial part of the excavation and construction portfolio, capable of supporting a variety of activities on the lunar surface. Autonomous payload handling is one of the first activities the LSMS can support that develops capabilities that are extensible to other surface operations. Payload handling is required to: remove payloads from a lander; place payloads on mobile agents for transport from a lander to construction site/assembly point; emplace payloads in their operational configuration, and aggregate components to create an asset. As an example of this critical gap, manifested CLPS missions do not currently have a ubiquitous payload offloading capability; payloads (excluding rovers) are designed to remain on the lander. Why Autonomy? Autonomous robotic systems capable of carrying out excavation and construction operations are a fundamental and critical capability required for realizing the NASA Artemis program vision to “emplace and build the infrastructure, systems, and robotic missions that can enable a sustained lunar surface presence.” While teleoperation is still feasible for lunar surface operations, increased latency at Mars will require validated supervised autonomous technologies capable of operating with minimal human involvement (human-on-the-loop) unless an unexpected event occurs requiring human intervention. Autonomy reduces operator burden, allows operations to continue during uncrewed periods, in-creases the safety of operations by automatically detecting and handling faults, and allows operating in high latency environments. Development Activities: LANDO is extending critical autonomous operations to the manipulation domain and creating an integrated system, based on reusable software modules, that is capable of planning and executing payload handling and autonomous surface operations without requiring hu-man intervention beyond a supervisory role. The priority features under development are 1) autonomously offload payloads from a tilted lander deck without buckling the LSMS; 2) sensing whether a payload is safe to lift and handle; and 3) integrate with Astrobotic’s CLPS lander. The poster presentation will highlight current development activities over the past year on LSMS-L35 prototype hard-ware design, and autonomy software.

in-space assembly↗
NASA NTRS2006

Simulating Humans as Integral Parts of Spacecraft Missions

The Collaborative-Virtual Environment Simulation Tool (C-VEST) software was developed for use in a NASA project entitled "3-D Interactive Digital Virtual Human." The project is oriented toward the use of a comprehensive suite of advanced software tools in computational simulations for the purposes of human-centered design of spacecraft missions and of the spacecraft, space suits, and other equipment to be used on the missions. The C-VEST software affords an unprecedented suite of capabilities for three-dimensional virtual-environment simulations with plug-in interfaces for physiological data, haptic interfaces, plug-and-play software, realtime control, and/or playback control. Mathematical models of the mechanics of the human body and of the aforementioned equipment are implemented in software and integrated to simulate forces exerted on and by astronauts as they work. The computational results can then support the iterative processes of design, building, and testing in applied systems engineering and integration. The results of the simulations provide guidance for devising measures to counteract effects of microgravity on the human body and for the rapid development of virtual (that is, simulated) prototypes of advanced space suits, cockpits, and robots to enhance the productivity, comfort, and safety of astronauts. The unique ability to implement human-in-the-loop immersion also makes the C-VEST software potentially valuable for use in commercial and academic settings beyond the original space-mission setting.

Bruins, Anthony C.↗
NASA NTRS1998

Automated System Checkout to Support Predictive Maintenance for the Reusable Launch Vehicle

The Propulsion Checkout and Control System (PCCS) is a predictive maintenance software system. The real-time checkout procedures and diagnostics are designed to detect components that need maintenance based on their condition, rather than using more conventional approaches such as scheduled or reliability centered maintenance. Predictive maintenance can reduce turn-around time and cost and increase safety as compared to conventional maintenance approaches. Real-time sensor validation, limit checking, statistical anomaly detection, and failure prediction based on simulation models are employed. Multi-signal models, useful for testability analysis during system design, are used during the operational phase to detect and isolate degraded or failed components. The TEAMS-RT real-time diagnostic engine was developed to utilize the multi-signal models by Qualtech Systems, Inc. Capability of predicting the maintenance condition was successfully demonstrated with a variety of data, from simulation to actual operation on the Integrated Propulsion Technology Demonstrator (IPTD) at Marshall Space Flight Center (MSFC). Playback of IPTD valve actuations for feature recognition updates identified an otherwise undetectable Main Propulsion System 12 inch prevalve degradation. The algorithms were loaded into the Propulsion Checkout and Control System for further development and are the first known application of predictive Integrated Vehicle Health Management to an operational cryogenic testbed. The software performed successfully in real-time, meeting the required performance goal of 1 second cycle time.

Patterson-Hine, Ann↗
NASA NTRS1998

Using Immersive Virtual Environments for Certification

Immersive virtual environments (VEs) technology has matured to the point where it can be utilized as a scientific and engineering problem solving tool. In particular, VEs are starting to be used to design and evaluate safety-critical systems that involve human operators, such as flight and driving simulators, complex machinery training, and emergency rescue strategies.

virtual reality software certification human-compu↗
NASA NTRS2012

Automation of Hubble Space Telescope Mission Operations

On June 13, 2011, after more than 21 years, 115 thousand orbits, and nearly 1 million exposures taken, the operation of the Hubble Space Telescope successfully transitioned from 24x7x365 staffing to 815 staffing. This required the automation of routine mission operations including telemetry and forward link acquisition, data dumping and solid-state recorder management, stored command loading, and health and safety monitoring of both the observatory and the HST Ground System. These changes were driven by budget reductions, and required ground system and onboard spacecraft enhancements across the entire operations spectrum, from planning and scheduling systems to payload flight software. Changes in personnel and staffing were required in order to adapt to the new roles and responsibilities required in the new automated operations era. This paper will provide a high level overview of the obstacles to automating nominal HST mission operations, both technical and cultural, and how those obstacles were overcome.

Burley, Richard↗
NASA NTRS2005

Chapter 12 - Flight Envelope

The term "flight envelope" is used to refer to the boundaries of aircraft loading and flight conditions within which operation of the aircraft is satisfactory, and beyond which some aspect becomes unacceptable. This flight envelope represents, in fact, the limiting conditions arising from a matrix of inter-related flight envelopes covering the appropriate variables. Thus, for each loading (i.e., external stores configuration and its associated range of weight and center of gravity (c.g.) position) and aircraft configuration (i.e., position of undercarriage (u/c), flaps, slats, etc.), the envelopes of airspeed versus altitude, airspeed versus load factor, angle of attack versus angle of sideslip, etc., must be investigated to establish the limits within which all aspects such as handling qualities, engine behavior, structural loads, etc., remain acceptable. Flight testing of new or derivative aircraft models is carried out with the initial purpose of defining a flight envelope which is, first and foremost, safe and secondarily, which enables the effective use of the vehicle for its intended purpose. Flight testing occurs only after numerous reviews of the design and review of results from ground tests and predictions of flight characteristics in such areas as structures, aerodynamics, stability and control, flight controls (particularly fly-by-wire control systems, propulsion, etc.). Accordingly, opening and expanding the envelope is a task that must be approached cautiously, systematically, and with coordination and cooperation of the many disciplines involved in the design and test of an airplane. (Sections 8 and 10 cover test planning and safety of flight considerations, respectively). The fundamental tenet in establishing a flight envelope via flight test is risk reduction. This is reflected in the typical sequence of events leading to initial flight test - design reviews (both hardware and software), then ground test involving singular disciplines (windtunnel tests for aerodynamics, structurally loading the wing/fuselage/nacelle on a ground test article with loads anticipated to occur in flight, flight control system control law checkout, propulsion test cell runs and/or flying test bed tests, etc.), and then ground tests involving multi-disciplines (See Section 9). Only after these have been accomplished will an initial, limited, low-risk, flight envelope be established. The limited envelope will typically be in the middle of the projected final flight envelope. Subsequent flight tests will then be devoted to expanding the initial envelope by operating the airplane at increasing ranges - representing increasing risk - of engine operation, airspeeds both fast and slow, altitude, load factor both above and below 1g, centers of gravity (fore and aft), and with system/subsystem failures. Whether flight tests are to define a flight envelope on a new model airplane with the attendant new airframe, new engine(s), and new subsystems (hydraulics, pressurization, etc.), or on an airplane involving only a few of these areas such as new engines in an old airframe, the fundamental approach to establishing an envelope is the same.

H Walgemoed↗
NASA NTRS2018

On-Board Battery Monitoring and Prognostics for Electric-Propulsion Aircraft

The reliability of the propulsion system of an aircraft is paramount for the aircraft safety and hence the aircraft health must be monitored continuously. In contrast to fuel- operated aircraft, electric battery-operated propulsion system poses specific problems, such as, the remaining battery power does not linearly decrease and cannot be measured directly. In this paper, we describe a combined monitoring and prognostics architecture that can continuously monitor all components of the electric propulsion system with respect to safety and performance properties as well as state of charge and rest of useful life for the battery. Our system combines a detailed electrochemical battery model for Li-ion batteries with a powerful prognostics engine based upon an Unscented Kalman Filter with the R2U2 monitoring device, which provides efficient observers for metric temporal logic and Bayesian reasoning. R2U2 is a real-time, realizable, responsive, unobtrusive unit, which continuously monitors sensor readings, outputs of the prognostics engine, as well as the ight software status for safety, performance, and security properties. We illustrate our architecture with two case studies, one reporting actual ight tests with an X8+ octocopter and the other a software-in-the-loop simulation with an unmanned Edge 540 electric aircraft model.

Kulkarni, Chetan↗
NASA NTRS2000

IVHM for the 3rd Generation RLV Program: Technology Development

The objective behind the Integrated Vehicle Health Management (IVHM) project is to develop and integrate the technologies which can provide a continuous, intelligent, and adaptive health state of a vehicle and use this information to improve safety and reduce costs of operations. Technological areas discussed include: developing, validating, and transfering next generation IVHM technologies to near term industry and government reusable launch systems; focus NASA on the next generation and highly advanced sensor and software technologies; and validating IVHM systems engineering design process for future programs.

Kahle, Bill↗
NASA NTRS1998

Issues and Methods for Assessing COTS Reliability, Maintainability, and Availability

Many vendors produce products that are not domain specific (e.g., network server) and have limited functionality (e.g., mobile phone). In contrast, many customers of COTS develop systems that am domain specific (e.g., target tracking system) and have great variability in functionality (e.g., corporate information system). This discussion takes the viewpoint of how the customer can ensure the quality of COTS components. In evaluating the benefits and costs of using COTS, we must consider the environment in which COTS will operate. Thus we must distinguish between using a non-mission critical application like a spreadsheet program to produce a budget and a mission critical application like military strategic and tactical operations. Whereas customers will tolerate an occasional bug in the former, zero tolerance is the rule in the latter. We emphasize the latter because this is the arena where there are major unresolved problems in the application of COTS. Furthermore, COTS components may be embedded in the larger customer system. We refer to these as embedded systems. These components must be reliable, maintainable, and available, and must be with the larger system in order for the customer to benefit from the advertised advantages of lower development and maintenance costs. Interestingly, when the claims of COTS advantages are closely examined, one finds that to a great extent these COTS components consist of hardware and office products, not mission critical software [1]. Obviously, COTS components are different from custom components with respect to one or more of the following attributes: source, development paradigm, safety, reliability, maintainability, availability, security, and other attributes. However, the important question is whether they should be treated differently when deciding to deploy them for operational use; we suggest the answer is no. We use reliability as an example to justify our answer. In order to demonstrate its reliability, a COTS component must pass the same reliability evaluations as the custom components, otherwise the COTS components will be the weakest link in the chain of components and will be the determinant of software system reliability. The challenge is that there will be less information available for evaluating COTS components than for custom components but this does not mean we should despair and do nothing. Actually, there is a lot we can do even in the absence of documentation on COTS components because the customer will have information about how COTS components are to be used in the larger system. To illustrate our approach, we will consider the reliability, maintainability, and availability (RMA) of COTS components as used in larger systems. Finally, COTS suppliers might consider increasing visibility into their products to assist customers in determining the components' fitness for use in a particular application. We offer ideas of information that would be useful to customers, and what vendors might do to provide it.

Schneidewind, Norman F.↗
NASA NTRS1983

Autonomous failure detection and correction on Landsat-4

An integrated hardware/software fault tolerant system for an earth oriented, computer controlled spacecraft is described. The design philosophy as well as the rationale behind the chosen fault tolerant system is outlined. In-flight performance of the system is included for several different instances where the Failure Detection and Correction system acted autonomously to protect the spacecraft. This system exceeded the expectations of the designers by demonstrating the capability to provide a measure of safety to the spacecraft for inadvertent and undesirable ground commands as well as satisfying its primary function of monitoring the flight hardware and software for failures.

Welch, R. V.↗
NASA NTRS1995

Commercial Earth Observation

Through the Earth Observation Commercial Applications Program (EOCAP) at Stennis Space Center, Applied Analysis, Inc. developed a new tool for analyzing remotely sensed data. The Applied Analysis Spectral Analytical Process (AASAP) detects or classifies objects smaller than a pixel and removes the background. This significantly enhances the discrimination among surface features in imagery. ERDAS, Inc. offers the system as a modular addition to its ERDAS IMAGINE software package for remote sensing applications. EOCAP is a government/industry cooperative program designed to encourage commercial applications of remote sensing. Projects can run three years or more and funding is shared by NASA and the private sector participant. Through the Earth Observation Commercial Applications Program (EOCAP), Ocean and Coastal Environmental Sensing (OCENS) developed SeaStation for marine users. SeaStation is a low-cost, portable, shipboard satellite groundstation integrated with vessel catch and product monitoring software. Linked to the Global Positioning System, SeaStation provides real time relationships between vessel position and data such as sea surface temperature, weather conditions and ice edge location. This allows the user to increase fishing productivity and improve vessel safety. EOCAP is a government/industry cooperative program designed to encourage commercial applications of remote sensing. Projects can run three years or more and funding is shared by NASA and the private sector participant.

Source record↗
NASA NTRS2006

Steering Aircraft Clear of Choppy Air

AeroTech Research (U.S.A.), Inc., a leader in turbulence-detection and warning systems, has been involved with NASA Aviation Safety research since 1998. AeroTech served as a contractor for the TPAWS government/industry development project, and was funded by NASA to develop the E-Turb Mode Radar algorithms and the TAPS software. (Other contributors to this project include the National Center for Atmospheric Research, the FAA, North Carolina State University, and the Research Triangle Institute.) The radar algorithms combine an aircraft's turbulenceresponse characteristics with radar measurements to determine the predicted turbulence loads the aircraft will experience, and present this information to the pilot. The TAPS software monitors and processes onboard aircraft sensor data; generates automatic reports when an aircraft encounters turbulence and a set turbulence threshold is exceeded; and then displays the reports and underlying information to ground personnel to improve situational awareness of the location and the severity of the turbulence encounter.

Source record↗
NASA NTRS2023

An MBSE Approach for Developing an Autonomous Rover Platform

The proliferation of increasingly autonomous systems calls for new ways to address how safety is assured. As these systems become more advanced and complex, it becomes more important to model and prototype autonomous functions at the systems level and the functions that assure they are operating safely and as expected. To that effect, researchers at the National Aeronautics and Space Administration (NASA) 's Robust Software Engineering (RSE) group are working on prototyping a Research Autonomous Vehicle, commonly referred to as R-RAV. The R-RAV is an autonomous rover platform designed to act as a case study for assured autonomy research. Moreover, an overarching goal is for the R-RAV to serve as a training ground for other mission projects. In this paper, we will detail how we have used a Model-Based Systems Engineering (MBSE) approach to model a prototype of the R-RAV and test and verify its different functionalities.

MBSE↗