Results for “vehicle operating data” — Page 6

NASA NTRS2002

Latest Development in Advanced Sensors at Kennedy Space Center (KSC)

Inexpensive space transportation system must be developed in order to make spaceflight more affordable. To achieve this goal, there is a need to develop inexpensive smart sensors to allow autonomous checking of the health of the vehicle and associated ground support equipment, warn technicians or operators of an impending problem and facilitate rapid vehicle pre-launch operations. The Transducers and Data Acquisition group at Kennedy Space Center has initiated an effort to study, research, develop and prototype inexpensive smart sensors to accomplish these goals. Several technological challenges are being investigated and integrated in this project multi-discipline sensors; self-calibration, health self-diagnosis capabilities embedded in sensors; advanced data acquisition systems with failure prediction algorithms and failure correction (self-healing) capabilities.

Perotti, Jose M.↗

NASA NTRS2009

Improving the Estimates of International Space Station (ISS) Induced K-Factor Failure Rates for On-Orbit Replacement Unit (ORU) Supportability Analyses

This is a case study on revised estimates of induced failure for International Space Station (ISS) on-orbit replacement units (ORUs). We devise a heuristic to leverage operational experience data by aggregating ORU, associated function (vehicle sub -system), and vehicle effective' k-factors using actual failure experience. With this input, we determine a significant failure threshold and minimize the difference between the actual and predicted failure rates. We conclude with a discussion on both qualitative and quantitative improvements the heuristic methods and potential benefits to ISS supportability engineering analysis.

Anderson, Leif F.↗

NASA NTRS2012

CloudSat Anomaly Recovery and Operational Lessons Learned

In April 2011, NASA's pioneering cloud profiling radar satellite, CloudSat, experienced a battery anomaly that placed it into emergency mode and rendered it operations incapable. All initial attempts to recover the spacecraft failed as the resultant power limitations could not support even the lowest power mode. Originally part of a six-satellite constellation known as the "A-Train", CloudSat was unable to stay within its assigned control box, posing a threat to other A-Train satellites. CloudSat needed to exit the constellation, but with the tenuous power profile, conducting maneuvers was very risky. The team was able to execute a complex sequence of operations which recovered control, conducted an orbit lower maneuver, and returned the satellite to safe mode, within one 65 minute sunlit period. During the course of the anomaly recovery, the team developed several bold, innovative operational strategies. Details of the investigation into the root-cause and the multiple approaches to revive CloudSat are examined. Satellite communication and commanding during the anomaly are presented. A radical new system of "Daylight Only Operations" (DO-OP) was developed, which cycles the payload and subsystem components off in tune with earth eclipse entry and exit in order to maintain positive power and thermal profiles. The scientific methodology and operational results behind the graduated testing and ramp-up to DO-OP are analyzed. In November 2011, the CloudSat team successfully restored the vehicle to consistent operational collection of cloud radar data during sunlit portions of the orbit. Lessons learned throughout the six-month return-to-operations recovery effort are discussed and offered for application to other R&D satellites, in the context of on-orbit anomaly resolution efforts.

cloud profiling radar satellite↗

NASA NTRSDate not supplied

NAS Exploratory Concepts & Technologies (NExCT) Upper Class E Traffic Management (ETM) Collaborative Evaluation #1 (CE-1)

NASA, in partnership with AeroVironment and Aerostar, recently demonstrated a first-of-its-kind air traffic management concept that could pave the way for aircraft to safely operate at higher altitudes. This work seeks to open the door for increased internet coverage, improved disaster response, expanded scientific missions, and even supersonic flight. The concept is referred to as an Upper-Class E traffic management, or ETM. NASA and its partners have developed an ETM traffic management system that allows aircraft to autonomously share location and flight plans, enabling aircraft to stay safely separated. This concept was demonstrated during the recent traffic management simulation in the Airspace Operations Laboratory at Ames, data from multiple air vehicles was displayed across dozens of traffic control monitors and shared with partner computers off site. The study details and the initial results are presented at a regular, informal ETM industry meetings held virtually.

Upper Class E Traffic Management (ETM)↗

NASA NTRS2019

Noise Abatement Flight Test Data Report

An acoustic flight test of six helicopters conducted by NASA, FAA, and the US Army is described. Microphone arrays were used to collect acoustic data for source noise characterization, to investigate the acoustic impacts of maneuvering flight, and to develop and evaluate noise abatement operations for helicopters on approach. Atmospheric data and vehicle state data were also collected. Noise metrics are calculated and plotted for all conditions tested. All data described are publicly available upon request.

Rotorcraft↗

NASA NTRS1999

Propulsion System Airframe Integration Issues and Aerodynamic Database Development for the Hyper-X Flight Research Vehicle

NASA's Hyper-X Research Vehicle will provide a unique opportunity to obtain data on an operational airframe integrated scramjet propulsion system at true flight conditions. The airframe integrated nature of the scramjet engine with the Hyper-X vehicle results in a strong coupling effect between the propulsion system operation and the airframe s basic aerodynamic characteristics. Comments on general airframe integrated scramjet propulsion system effects on vehicle aerodynamic performance, stability, and control are provided, followed by examples specific to the Hyper-X research vehicle. An overview is provided of the current activities associated with the development of the Hyper-X aerodynamic database, including wind tunnel test activities and parallel CFD analysis efforts. A brief summary of the Hyper-X aerodynamic characteristics is provided, including the direct and indirect effects of the airframe integrated scramjet propulsion system operation on the basic airframe stability and control characteristics.

Engelund, Walter C.↗

NASA NTRS1979

Mission analysis and performance specification studies report, appendix A

The Near Term Hybrid Passenger Vehicle Development Program tasks included defining missions, developing distributions of daily travel and composite driving cycles for these missions, providing information necessary to estimate the potential replacement of the existing fleet by hybrids, and estimating acceleration/gradeability performance requirements for safe operation. The data was then utilized to develop mission specifications, define reference vehicles, develop hybrid vehicle performance specifications, and make fuel consumption estimates for the vehicles. The major assumptions which underlie the approach taken to the mission analysis and development of performance specifications are the following: the daily operating range of a hybrid vehicle should not be limited by the stored energy capacity and the performance of such a vehicle should not be strongly dependent on the battery state of charge.

Source record↗

NASA NTRS2004

High Altitude Long Endurance Remotely Operated Aircraft - National Airspace System Integration - Simulation IPT: Detailed Airspace Operations Simulation Plan. Version 1.0

The primary goal of Access 5 is to allow safe, reliable and routine operations of High Altitude-Long Endurance Remotely Operated Aircraft (HALE ROAs) within the National Airspace System (NAS). Step 1 of Access 5 addresses the policies, procedures, technologies and implementation issues of introducing such operations into the NAS above pressure altitude 40,000 ft (Flight Level 400 or FL400). Routine HALE ROA activity within the NAS represents a potentially significant change to the tasks and concerns of NAS users, service providers and other stakeholders. Due to the complexity of the NAS, and the importance of maintaining current high levels of safety in the NAS, any significant changes must be thoroughly evaluated prior to implementation. The Access 5 community has been tasked with performing this detailed evaluation of routine HALE-ROA activities in the NAS, and providing to key NAS stakeholders a set of recommended policies and procedures to achieve this goal. Extensive simulation, in concert with a directed flight demonstration program are intended to provide the required supporting evidence that these recommendations are based on sound methods and offer a clear roadmap to achieving safe, reliable and routine HALE ROA operations in the NAS. Through coordination with NAS service providers and policy makers, and with significant input from HALE-ROA manufacturers, operators and pilots, this document presents the detailed simulation plan for Step 1 of Access 5. A brief background of the Access 5 project will be presented with focus on Steps 1 and 2, concerning HALE-ROA operations above FL400 and FL180 respectively. An overview of project management structure follows with particular emphasis on the role of the Simulation IPT and its relationships to other project entities. This discussion will include a description of work packages assigned to the Simulation IPT, and present the specific goals to be achieved for each simulation work package, along with the associated deliverables necessary to achieve these goals and the needs of other Access 5 IPTs. The simulation environment chosen for this task is then outlined. This section includes a description of the system architecture, a list of the necessary assumptions made by the Simulation IPT, and the roles, responsibilities and interactions of simulation participants. The method of simulation conduct is presented in the next section with particular emphasis on scenario development and applicability to evaluation of Step 1 HALE-ROA operations. Following, data collection and analysis methods are discussed for air traffic specialists and air vehicle control station operators. Lastly, a schedule of Step 1 simulation activities is presented for reference.

Source record↗

NASA NTRS2019

Health Management and Prognostics for Electric Aircraft Powertrain

W and c Any air borne vehicle needs incorporating safety as key parameter of measure, and inclusion of autonomy raises the critical need for safety under autonomous operations. Management of faults and component degradation is key as complexity in autonomous operations grow over the period of time. Therefore, in addition to basic operational requirements, an autonomous electric vehicle should be able to make accurate estimates of its current system health and take the correct decisions to complete its mission successfully. Real-time safety and state-awareness tools are therefore essential for the vehicle to be able to reach its destination in a safe and successful manner. The need for safety assurance and health management capabilities is particularly relevant for aircraft electric propulsion systems, which are relatively new and with limited historical to learn. They are critical systems requiring high power density along with reliability, resilience, efficient management of weight, and operational costs. A model- based fault diagnosis and prognostics approach of complex critical systems can successfully accomplish the safety and state awareness goal for such electric propulsion systems, enabling autonomous decision making capability for safe and efficient operation. To identify critical components in the system a Qualitative Bayesian approach using FMECA is implemented. This requires the assessment of some quantities representing the state of the electric unmanned aerial systems (e-UAS), as well as look-ahead forecasts of such states during the entire flight, presented in form of safety metrics (SM). In-service data and performance data gathered from degraded components sup- ports diagnostic and prognostic methods for these systems, but this data can be difficult to obtain as weight and packaging restrictions reduce redundancy and instrumentation on-board the vehicle. Therefore, an model-based framework should be capable or operating with limited data. In addition to data scarcity, the variability of such complex critical systems re- quires the model-based framework to reason in the presence of uncertainty, such as sensor noise, and modeling imperfections. Quantification of errors and uncertainties in the measured states and quantities is therefore a fundamental step for a precise estimation of such SMs; un-modeled uncertainty may result in erroneous state assessment and un- reliable predictions of future states of e-UAVs. Typical, centralized model-based schemes suffer from inherent disadvantages such as computational complexity, single point of failure, and scalability issues, and therefore may fail in such a complex scenario. This paper presents a methodology for developing a system level diagnostics and prognostics approach using a Qualitative Bayesian FMECA approach along with a formal uncertainty management framework for an e-UAS. In this work we demonstrate the efficacy of the framework to predict effects of sub-system level degradation on vehicle operation incorporating uncertainty management to predict future behavior under different operating conditions.

Kulkarni, Chetan↗

NASA NTRS2008

Orchestrator Telemetry Processing Pipeline

Orchestrator is a software application infrastructure for telemetry monitoring, logging, processing, and distribution. The architecture has been applied to support operations of a variety of planetary rovers. Built in Java with the Eclipse Rich Client Platform, Orchestrator can run on most commonly used operating systems. The pipeline supports configurable parallel processing that can significantly reduce the time needed to process a large volume of data products. Processors in the pipeline implement a simple Java interface and declare their required input from upstream processors. Orchestrator is programmatically constructed by specifying a list of Java processor classes that are initiated at runtime to form the pipeline. Input dependencies are checked at runtime. Fault tolerance can be configured to attempt continuation of processing in the event of an error or failed input dependency if possible, or to abort further processing when an error is detected. This innovation also provides support for Java Message Service broadcasts of telemetry objects to clients and provides a file system and relational database logging of telemetry. Orchestrator supports remote monitoring and control of the pipeline using browser-based JMX controls and provides several integration paths for pre-compiled legacy data processors. At the time of this reporting, the Orchestrator architecture has been used by four NASA customers to build telemetry pipelines to support field operations. Example applications include high-volume stereo image capture and processing, simultaneous data monitoring and logging from multiple vehicles. Example telemetry processors used in field test operations support include vehicle position, attitude, articulation, GPS location, power, and stereo images.

Powell, Mark↗

NASA NTRSDate not supplied

Gateway Autonomy for Enabling Deep Space Exploration

The Gateway spacecraft is an important stepping-stone to exploration of the solar system, integrating commercial and international partners into a tightly coupled system, enabling cislunar activities, and implementing key technologies for missions to Mars. Autonomy is a capability area necessary to handle long communication outages where intervention from Earth is impossible, to prepare to operate with long communication delays that will be common in interplanetary travel, and to make spaceflight more affordable and accessible by reducing sustaining operations costs. The Gateway Concept of Operations states that one of Gateway’s goals is to “focus on infrastructure and systems that will allow autonomous operations aboard the Gateway with robotics, automated systems, advanced communications, and distributed computing.” Gateway’s Vehicle Systems Manager (VSM) and associated Autonomous Spacecraft Management Architecture (ASMA) are key products towards delivering autonomous capability. The primary functions of the control architecture are Mission Management and Timeline Execution, Resource Management, Fault Management, and Vehicle Control and Operation (VCO). In each of these areas, there is an initial level of capability to be delivered at launch, with plans to continue development and grow to greater capability. The initial deployment of VSM will focus on maintaining vehicle safety by focusing on full fault management capabilities and deploying only enough resource and timeline planning functionality to support that. The final deployment of VSM will add significant planning and control optimization functionality to support nominal operations for up to 21 days without ground support, even accommodating fault and failure conditions. While the VSM is the vehicle-level representation of autonomous reasoning, distributed automation is essential to provide the right scope and abstraction of information to process. Module and system support of automation and simplicity of interfaces are two important design paradigms that Gateway is focusing on to garner a systems approach to autonomy. Distribution of reasoning can increase complexity, so Gateway is also taking a strict hierarchical approach to information flow and decision making. VSM is not the only capability necessary to achieve an autonomous spacecraft. Robotics support for maintenance of the spacecraft will be essential to provide continued vehicle functionality even when crew is not present. Technical and programmatic challenges exist when implementing autonomous robotics operations. These challenges include sufficient network flexibility to support data transfer to the rest of the vehicle to coordinate module-to-module robotic walk-offs and finding the proper interfaces to allow sufficient dexterity. Communication system upgrades planned for Gateway include Delay Tolerant Networking to best utilize the complex network of relays that will be part of mature cislunar operations. Distributed computing and management will provide failure tolerance, robustness, and growth of capabilities while still allowing significant reuse of heritage software on heritage systems as well as reuse of common applications across a spacecraft to minimize new development, but this requires adherence to key standards and interfaces. The Gateway program has demonstrated significant progress towards these capabilities and has identified challenges other spacecraft developers should be aware of from the start.

Molly Anderson↗

NASA NTRSDate not supplied

Gateway Autonomy for Enabling Deep Space Exploration

The Gateway spacecraft is an important stepping-stone to exploration of the solar system, integrating commercial and international partners into a tightly coupled system, enabling cislunar activities, and implementing key technologies for missions to Mars. Autonomy is a capability area necessary to handle long communication outages where intervention from Earth is impossible, to prepare to operate with long communication delays that will be common in interplanetary travel, and to make spaceflight more affordable and accessible by reducing sustaining operations costs. The Gateway Concept of Operations states that one of Gateway’s goals is to “focus on infrastructure and systems that will allow autonomous operations aboard the Gateway with robotics, automated systems, advanced communications, and distributed computing.” Gateway’s Vehicle Systems Manager (VSM) and associated Autonomous Spacecraft Management Architecture (ASMA) are key products towards delivering autonomous capability. The primary functions of the control architecture are Mission Management and Timeline Execution, Resource Management, Fault Management, and Vehicle Control and Operation (VCO). In each of these areas, there is an initial level of capability to be delivered at launch, with plans to continue development and grow to greater capability. The initial deployment of VSM will focus on maintaining vehicle safety by focusing on full fault management capabilities and deploying only enough resource and timeline planning functionality to support that. The final deployment of VSM will add significant planning and control optimization functionality to support nominal operations for up to 21 days without ground support, even accommodating fault and failure conditions. While the VSM is the vehicle-level representation of autonomous reasoning, distributed automation is essential to provide the right scope and abstraction of information to process. Module and system support of automation and simplicity of interfaces are two important design paradigms that Gateway is focusing on to garner a systems approach to autonomy. Distribution of reasoning can increase complexity, so Gateway is also taking a strict hierarchical approach to information flow and decision making. VSM is not the only capability necessary to achieve an autonomous spacecraft. Robotics support for maintenance of the spacecraft will be essential to provide continued vehicle functionality even when crew is not present. Technical and programmatic challenges exist when implementing autonomous robotics operations. These challenges include sufficient network flexibility to support data transfer to the rest of the vehicle to coordinate module-to-module robotic walk-offs and finding the proper interfaces to allow sufficient dexterity. Communication system upgrades planned for Gateway include Delay Tolerant Networking to best utilize the complex network of relays that will be part of mature cislunar operations. Distributed computing and management will provide failure tolerance, robustness, and growth of capabilities while still allowing significant reuse of heritage software on heritage systems as well as reuse of common applications across a spacecraft to minimize new development, but this requires adherence to key standards and interfaces. The Gateway program has demonstrated significant progress towards these capabilities and has identified challenges other spacecraft developers should be aware of from the start.

Molly Anderson↗

NASA NTRS2003

Simulation of Wind Profile Perturbations for Launch Vehicle Ascent Flight Systems Design Assessments

Ideally, a statistically representative sample of measured high-resolution wind profiles with wavelengths as small as tens of meters is required for assessment of launch vehicle ascent flight systems component capability and vehicle operability for a selected launch site. At most potential launch sites a sample of high-resolution measured wind profiles may not exist. Representative samples of Rawinsonde wind profiles are more likely to be available because of the extensive network of measurement sites established for routine measurements at 12-hr intervals in support of national and international weather observing and forecasting activity. Such a sample, although large enough to statistically represent relatively large wavelength perturbations, would be inadequate for launch system design assessment applications because the Rawinsonde system can accurately measure wind perturbations with wavelengths no smaller than 2000m (1000m altitude increment). Wavelengths less than 2000m in the raw Rawinsonde data, which tend to be dominated by un-damped spurious balloon motion and radar tracking system noise, are filtered within the data processing scheme. The Kennedy Space Center (KSC) Jimsphere wind profiles (150/month and seasonal pairs) are the only adequate high resolution (approximately 150 to 300m effective resolution, but over-sampled at 25m intervals) data that have been used extensively in launch vehicle design, operability assessments and operational protection of vehicle systems for wind perturbation uncertainty. Jimsphere wind profiles have been measured at a few other potential launch sites but the number of profiles is relatively small and the samples are not statistically representative of the site dependent wind profile variability. A simulation process has been developed for enhancement of measured low-resolution Rawinsonde profiles that are more likely to be available in the vicinity of potential launch sites and are a statistically representative sample of wind profile perturbation wavelengths greater than 2000m. The enhancement produces perturbed wind profiles with wavelengths as small as desired for application in launch vehicle ascent flight simulations and design assessments.

Adelfang, S. I.↗

NASA NTRS2006

An Alternative for Emergency Preemption of Traffic Lights

An electronic communication-and-control system has been developed as a prototype of advanced means of automatically modifying the switching of traffic lights to give priority to emergency vehicles. This system could be used alternatively or in addition to other emergency traffic-light-preemption systems, including a variety of systems now in use as well as two proposed systems described in "Systems Would Preempt Traffic Lights for Emergency Vehicles" (NPO-30573), NASA Tech Briefs, Vol. 28, No. 10 (October 2004), page 36. Unlike those prior systems that depend on detection of sounds and/or lights emitted by emergency vehicles, this system is not subject to severe range limitations. This system can be retrofitted into any pre-existing traffic-light-control system, without need to modify that system other than to make a minimal number of wire connections between the two systems. This system comprises several subsystems, including a transponder and interface circuitry on each emergency vehicle, a monitoring and control unit at each intersection equipped with traffic lights, and a wide-area two-way radio communication network that connects the emergency vehicles and intersection units. Computers in the various intersections and vehicle units run special-purpose software that implements the traffic- light-preemption scheme. The operations of the intersection and vehicle units are synchronized by use of Global Positioning System (GPS) timing signals. The transponder in each vehicle estimates its own position and velocity by use of GPS signals, deductive ("dead") reckoning, data from the onboard diagnostic (OBD) computer of the vehicle, and/or triangulation of beacon signals. When the operator of an emergency vehicle turns on its flashing lights and sirens in response to a request for an emergency response, the transponder unit goes into action, reading the OBD data to determine speed and acceleration, and reading and gathering further navigational data as described above. The position, velocity, and acceleration data are combined with vehicle-identification data in a prescribed format, and the resulting set of data is transmitted to the intersections within communication range of the transponder.

Foster, Conrad↗

NASA NTRS1972

An investigation of the landing characteristics of the NASA-MSC August 1969 baseline orbiter configuration in ground effect

A 0.05 scale model of the NASA-MSC August 1969 baseline shuttle craft was tested in Texas A&M University's 7- x 10-foot low speed wind tunnel facility. The purpose of the test was to determine the landing aerodynamic characteristics of the shuttle craft vehicle in ground effect and to evaluate control surface hinge moments experienced in the cruise and landing operational phases of flight. Analysis of the final data will allow evaluation of vehicle flight stability in ground effect and estimation of vehicle control surface power system requirements.

Chambliss, E. B.↗

NASA NTRS1965

Gemini Program Mission Planning Report

This report defines the Gemini Program objectives and presents guidelines for the individual Gemini missions. It provides general space vehicle configuration data, and descriptions of planned missions. Contingency mission requirements and extravehicular operations to be performed during specific missions are described in the last two sections of the basic document. Data on spacecraft weights and Gemini Launch Vehicle performance capabilities are provided in Appendix A, while Appendix B provides descriptions of onboard experiments to be conducted during Gemini missions.

Source record↗

NASA NTRS1973

Humidity

The glossary contains atmospheric and ground vapor concentration data on the various NASA space vehicle development and operation sites for consideration by the vehicle design engineer.

Daniels, G. E.↗

NASA NTRS1991

A PC-based bus monitor program for use with the transport systems research vehicle RS-232 communication interfaces

Experiment critical use of RS-232 data busses in the Transport Systems Research Vehicle (TSRV) operated by the Advanced Transport Operating Systems Program Office at the NASA Langley Research Center has recently increased. Each application utilizes a number of nonidentical computer and peripheral configurations and requires task specific software development. To aid these development tasks, an IBM PC-based RS-232 bus monitoring system was produced. It can simultaneously monitor two communication ports of a PC or clone, including the nonstandard bus expansion of the TSRV Grid laptop computers. Display occurs in a separate window for each port's input with binary display being selectable. A number of other features including binary log files, screen capture to files, and a full range of communication parameters are provided.

Easley, Wesley C.↗