Search NASA⌕ Search

SEARCH · Search NASA

Results for “onboard data management”

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 73 records · Page 4

Virtual environment and computer-aided technologies used for system prototyping and requirements development

The Space Station Freedom (SSF) Data Management System (DMS) consists of distributed hardware and software which monitor and control the many onboard systems. Virtual environment and off-the-shelf computer technologies can be used at critical points in project development to aid in objectives and requirements development. Geometric models (images) coupled with off-the-shelf hardware and software technologies were used in The Space Station Mockup and Trainer Facility (SSMTF) Crew Operational Assessment Project. Rapid prototyping is shown to be a valuable tool for operational procedure and system hardware and software requirements development. The project objectives, hardware and software technologies used, data gained, current activities, future development and training objectives shall be discussed. The importance of defining prototyping objectives and staying focused while maintaining schedules are discussed along with project pitfalls.

Logan, Cory↗

Onboard Science Data Analysis: Opportunities, Benefits, and Effects on Mission Design

Much of the initial focus for spacecraft autonomy has been on developing new software and systems concepts to automate engineering functions of the spacecraft: guidance, navigation and control, fault protection, and resources management. However, the ultimate objectives of NASA missions are science objectives, which implies that we need a new framework for perfoming science data evaluation and observation planning autonomously onboard spacecraft.

spacecraft autonomy observation planning science d↗

Command and control of unmanned scientific spacecraft

Recent developments in command and control technology for use with the Voyager and the planned Galileo are discussed. These spacecraft each carry more than 10 scientific instruments, many of which are very complex, and these instruments must be able to function with a considerable degree of autonomy because the round-trip light time to the spacecraft in the vicinity of Jupiter and Saturn is too great to permit prompt ground-based management of onboard anomalies or control of some observation programs. Command and control procedures, including data storage procedures, for systems of the two spacecraft are examined.

Gates, C. R.↗

Analytical redundancy management mechanization and flight data analysis for the F-8 digital fly-by-wire aircraft flight control sensors

The details are presented of an onboard digital computer algorithm designed to reliably detect and isolate the first failure in a duplex set of flight control sensors aboard the NASA F-8 digital fly-by-wire aircraft. The algorithm's successful flight test program is summarized, and specific examples are presented of algorithm behavior in response to software-induced signal faults, both with and without aircraft parameter modeling errors.

Deckert, J. C.↗

Space shuttle/mesoscale lightning experiment

A payload integration plan (PIP) is now being developed with Johnson Space Center integration personnel which covers management, structural thermal, electrical power/avionics, training, ground operations, safety requirements, etc., in support of this experiment. If a Shuttle flight can be identified, researchers hope to conduct the experiment in the late summer or fall of 1985. Some preliminary TV lightning data has been collected by Shuttle crews on 41D and 51D and researchers are doing an analysis of it. Additional flights will be conducted to obtain data on Mesoscale Lightning Observations. Researchers will continue to study how to improve the data collection using the onboard TV cameras. By more interaction with the crews who have used the TV camera to obtain TV of lightning, they are planning to optimize the crew time and have better TV camera operations management to produce more useful data. As the crews are better trained in the use of the gain control settings and/or camera iris operations, the quality of the TV data will be improved.

Vaughan, O. H., Jr.↗

Life sciences Spacelab Mission Development test 3 (SMD 3) data management report

Development of a permanent data system for SMD tests was studied that would simulate all elements of the shuttle onboard, telemetry, and ground data systems that are involved with spacelab operations. The onboard data system (ODS) and the ground data system (GDS) were utilized. The air-to-ground link was simulated by a hardwired computer-to-computer interface. A patch board system was used on board to select experiment inputs, and the downlink configuration from the ODS was changed by a crew keyboard entry to support each experiment. The ODS provided a CRT display of experiment parameters to enable the crew to monitor experiment performance. An onboard analog system, with recording capability, was installed to handle high rate data and to provide a backup to the digital system. The GDS accomplished engineering unit conversion and limit sensing, and provided realtime parameter display on CRT's in the science monitoring area and the test control area.

Moseley, E. C.↗

Space Telescope pointing control

The Space Telescope, a long life, high performance spacecraft deployed by the Space Shuttle, will carry five scientific instruments on its first mission. Its pointing control system will permit target-to-target maneuvering and precision pointing on a target star to support scientific objectives. Spacecraft attitude control is achieved by onboard computer processing of attitude and rate sensor data to generate reaction wheel torque commands. A momentum management control system is provided to desaturate the reaction wheels. This paper discusses the pointing control system and the control hardware investigations and improvements leading to system design.

Dougherty, H.↗

Mission Planning for Trident: Discovery proposal to Neptune’s moon, Triton

Trident was one of the four Discovery-class Step-1 mission proposals selected by NASA in 2020 for further development and study; however, in 2021, the Step-2 proposal was not down-selected to transition into the next phase of mission development, i.e., a mission for flight.Neptune’s largest moon, Triton, was the primary focus of study for Trident. Triton’s physical and orbital characteristics make it a unique planetary target for scientific exploration, providing opportunities for investigations in a wide variety of scientific fields, including geomorphological, atmospheric, geophysical, magnetospheric, and ionospheric studies. The science objectives of the Trident mission encompassed an in-depth interior-to-exterior set of objectives, focused on multiple outstanding questions resulting from the 1989 encounter of Voyager 2, and subsequent analysis.Ball Aerospace Corp. was tasked with building the Trident spacecraft, with JPL responsible for providing Engineering Support (Mission Design & Navigation, Mission Planning, Flight Operations, Ground Data Systems, Systems Engineering) and leading Project Management. The observatory would carry a wide-ranging suite of scientific instruments onboard, including an Infrared Spectrometer (IRS) and Narrow Angle Camera (NAC) to be provided by Ball Aerospace Corp., a Wide Angle Camera (WAC) from JPL, a Magnetometer from UCLA, a contributed Plasma Science Suite from IRF (Sweden), and a contributed Radio Science instrument from ASI (Italy). All of these instruments would be used to collect unique datasets during the Triton encounter. Trident would have taken advantage of an ~13-yr, nearly-ballistic trajectory to Triton, utilizing a timely Jupiter Gravity Assist, to execute a 10-day long encounter in the Neptunian system. Launch was planned for October 2025, with Triton arrival scheduled for December 2038. The timeline for this mission would have been sub-divided into seven major phases: Launch, Commissioning, Inner Planet Cruise, Outer Planet Cruise, Approach, Encounter, and Science Data Return. Multiple planetary flybys were planned to be performed during the cruise, including three Earth flybys and one Venus flyby in the Inner Planet Cruise phase, and one Jupiter flyby in the Outer Planet Cruise phase. Along with conventional (Range and Doppler) tracking data, Delta-DOR and Optical Navigation data were also to be acquired to assist with spacecraft navigation during the Approach and Encounter phases. A 3 meter X-Band High Gain Antenna would allow playback of all science data at 1 kbps within 1 year after the Triton Encounter. The Mission Planning element on Trident encompassed and informed multiple aspects of this proposal, ranging from science observation planning during the Triton Encounter phase, to generation of activity timelines for all mission phases; performing ground coverage analysis for science observations to be acquired by all instruments and tracing them to science requirements; evaluation of spacecraft resources including data volume stored onboard, power/energy consumption, telecom (commanding/telemetry) requirements, and overall, working at the interface of science and engineering teams on the mission. All of these functions that were performed by the Mission Planning team on this proposal are discussed in this paper.

Prockter, Louise↗

Shuttle avionics and the goal language including the impact of error detection and redundancy management

The relationship is examined between the space shuttle onboard avionics and the ground test computer language GOAL when used in the onboard computers. The study is aimed at providing system analysis support to the feasibility analysis of a GOAL to HAL translator, where HAL is the language used to program the onboard computers for flight. The subject is dealt with in three aspects. First, the system configuration at checkout, the general checkout and launch sequences, and the inventory of subsystems are described. Secondly, the hierarchic organization of onboard software and different ways of introducing GOAL-derived software onboard are described. Also the flow of commands and test data during checkout is diagrammed. Finally, possible impact of error detection and redundancy management on the GOAL language is discussed.

Flanders, J. H.↗

Radiation protection and instrumentation

Radiation was found not to be an operational problem during the Apollo program. Doses received by the crewmen of Apollo missions 7 through 17 were small because no major solar-particle events occurred during those missions. One small event was detected by a radiation sensor outside the Apollo 12 spacecraft, but no increase in radiation dose to the crewmen inside the spacecraft was detected. Radiation protection for the Apollo program was focused on both the peculiarities of the natural space radiation environment and the increased prevalence of manmade radiation sources on the ground and onboard the spacecraft. Radiation-exposure risks to crewmen were assessed and balanced against mission gain to determine mission constraints. Operational radiation evaluation required specially designed radiation detection systems onboard the spacecraft in addition to the use of satellite data, solar observatory support, and other liaison. Control and management of radioactive sources and radiation-generating equipment was important in minimizing radiation exposure of ground-support personnel, researchers, and the Apollo flight and backup crewmen.

J. Vernon Bailey↗

Communications and information research: Improved space link performance via concatenated forward error correction coding

With the development of new advanced instruments for remote sensing applications, sensor data will be generated at a rate that not only requires increased onboard processing and storage capability, but imposes demands on the space to ground communication link and ground data management-communication system. Data compression and error control codes provide viable means to alleviate these demands. Two types of data compression have been studied by many researchers in the area of information theory: a lossless technique that guarantees full reconstruction of the data, and a lossy technique which generally gives higher data compaction ratio but incurs some distortion in the reconstructed data. To satisfy the many science disciplines which NASA supports, lossless data compression becomes a primary focus for the technology development. While transmitting the data obtained by any lossless data compression, it is very important to use some error-control code. For a long time, convolutional codes have been widely used in satellite telecommunications. To more efficiently transform the data obtained by the Rice algorithm, it is required to meet the a posteriori probability (APP) for each decoded bit. A relevant algorithm for this purpose has been proposed which minimizes the bit error probability in the decoding linear block and convolutional codes and meets the APP for each decoded bit. However, recent results on iterative decoding of 'Turbo codes', turn conventional wisdom on its head and suggest fundamentally new techniques. During the past several months of this research, the following approaches have been developed: (1) a new lossless data compression algorithm, which is much better than the extended Rice algorithm for various types of sensor data, (2) a new approach to determine the generalized Hamming weights of the algebraic-geometric codes defined by a large class of curves in high-dimensional spaces, (3) some efficient improved geometric Goppa codes for disk memory systems and high-speed mass memory systems, and (4) a tree based approach for data compression using dynamic programming.

Rao, T. R. N.↗

Deploying a Route Optimization EFB Application for Commercial Airline Operational Trials

The Traffic Aware Planner (TAP), developed for NASA Langley Research Center to support the Traffic Aware Strategic Aircrew Requests (TASAR) project, is a flight-efficiency software application developed for an Electronic Flight Bag (EFB). Tested in two flight trials and planned for operational testing by two commercial airlines, TAP is a real-time trajectory optimization application that leverages connectivity with onboard avionics and broadband Internet sources to compute and recommend route modifications to flight crews to improve fuel and time performance. The application utilizes a wide range of data, including Automatic Dependent Surveillance Broadcast (ADS-B) traffic, Flight Management System (FMS) guidance and intent, on-board sensors, published winds and weather, and Special Use Airspace (SUA) schedules. This paper discusses the challenges of developing and deploying TAP to various EFB platforms, our solutions to some of these challenges, and lessons learned, to assist commercial software developers and hardware manufacturers in their efforts to implement and extend TAP functionality in their environments. EFB applications (such as TAP) typically access avionics data via an ARINC 834 Simple Text Avionics Protocol (STAP) server hosted by an Aircraft Interface Device (AID) or other installed hardware. While the protocol is standardized, the data sources, content, and transmission rates can vary from aircraft to aircraft. Additionally, the method of communicating with the AID may vary depending on EFB hardware and/or the availability of onboard networking services, such as Ethernet, WIFI, Bluetooth, or other mechanisms. EFBs with portable and installed components can be implemented using a variety of operating systems, and cockpits are increasingly incorporating tablet-based technologies, further expanding the number of platforms the application may need to support. Supporting multiple EFB platforms, AIDs, avionics datasets, and user interfaces presents a challenge for software developers and the management of their code baselines. Maintaining multiple baselines to support all deployment targets can be extremely cumbersome and expensive. Certification also needs to be considered when developing the application. Regardless of whether the software is itself destined to be certified, data requirements in support of the application and user interface elements may introduce certification requirements for EFB manufacturers and the airlines. The example of TAP, the challenges faced, solutions implemented, and lessons learned will give EFB application and hardware developers insight into future potential requirements in deploying TAP or similar flight-deck EFB applications.

Roscoe, David A.↗

Data reduction, management, and analysis software for CID

In an overview of the Data Reduction System, three major steps are examined. First, the raw data tapes were selected from the onboard recorders. These tapes should provide the best quality data for the data reduction software system. These tapes contained 352 channels of data, plus the monitor channels recorded in 8 bit Pulsed Coded Modulation (PCM) words. The next step consists of transcribing the PCM tapes from 8 bit serial digital data to 8 bit parallel digital data. This puts the data in the correct format for processing. The transcription process was accomplished here at LaRC in the Central Data Transportation Facility (CDTF). The last step in this 3 step process is to process the data through the reduction system developed for the Impact Dynamic Research Facility in the early part of 1980. Processing system criteria, system interface routines, and engineering units program that reads digitized data from tapes, and file management programs are discussed.

Davis, C. W.↗

High-Rate Communications Outage Recorder Operations for Optimal Payload and Science Telemetry Management Onboard the International Space Station

All International Space Station (ISS) Ku-band telemetry transmits through the High-Rate Communications Outage Recorder (HCOR). The HCOR provides the recording and playback capability for all payload, science, and International Partner data streams transmitting through NASA's Ku-band antenna system. The HCOR is a solid-state memory recorder that provides recording capability to record all eight ISS high-rate data during ISS Loss-of-Signal periods. NASA payloads in the Destiny module are prime users of the HCOR; however, NASDA and ESA will also utilize the HCOR for data capture and playback of their high data rate links from the Kibo and Columbus modules. Marshall Space Flight Center's Payload Operations Integration Center manages the HCOR for nominal functions, including system configurations and playback operations. The purpose of this paper is to present the nominal operations plan for the HCOR and the plans for handling contingency operations affecting payload operations. In addition, the paper will address HCOR operation limitations and the expected effects on payload operations. The HCOR is manifested for ISS delivery on flight 9A with the HCOR backup manifested on flight 11A. The HCOR replaces the Medium-Rate Communications Outage Recorder (MCOR), which has supported payloads since flight 5A.1.

Shell, Michael T.↗

Flight-Tested Prototype of BEAM Software

Researchers at JPL have completed a software prototype of BEAM (Beacon-based Exception Analysis for Multi-missions) and successfully tested its operation in flight onboard a NASA research aircraft. BEAM (see NASA Tech Briefs, Vol. 26, No. 9; and Vol. 27, No. 3) is an ISHM (Integrated Systems Health Management) technology that automatically analyzes sensor data and classifies system behavior as either nominal or anomalous, and further characterizes anomalies according to strength, duration, and affected signals. BEAM (see figure) can be used to monitor a wide variety of physical systems and sensor types in real time. In this series of tests, BEAM monitored the engines of a Dryden Flight Research Center F-18 aircraft, and performed onboard, unattended analysis of 26 engine sensors from engine startup to shutdown. The BEAM algorithm can detect anomalies based solely on the sensor data, which includes but is not limited to sensor failure, performance degradation, incorrect operation such as unplanned engine shutdown or flameout in this example, and major system faults. BEAM was tested on an F-18 simulator, static engine tests, and 25 individual flights totaling approximately 60 hours of flight time. During these tests, BEAM successfully identified planned anomalies (in-flight shutdowns of one engine) as well as minor unplanned anomalies (e.g., transient oil- and fuel-pressure drops), with no false alarms or suspected false-negative results for the period tested. BEAM also detected previously unknown behavior in the F- 18 compressor section during several flights. This result, confirmed by direct analysis of the raw data, serves as a significant test of BEAM's capability.

Mackey, Ryan↗

On-board B-ISDN fast packet switching architectures. Phase 2: Development. Proof-of-concept architecture definition report

For the next-generation packet switched communications satellite system with onboard processing and spot-beam operation, a reliable onboard fast packet switch is essential to route packets from different uplink beams to different downlink beams. The rapid emergence of point-to-point services such as video distribution, and the large demand for video conference, distributed data processing, and network management makes the multicast function essential to a fast packet switch (FPS). The satellite's inherent broadcast features gives the satellite network an advantage over the terrestrial network in providing multicast services. This report evaluates alternate multicast FPS architectures for onboard baseband switching applications and selects a candidate for subsequent breadboard development. Architecture evaluation and selection will be based on the study performed in phase 1, 'Onboard B-ISDN Fast Packet Switching Architectures', and other switch architectures which have become commercially available as large scale integration (LSI) devices.

Shyy, Dong-Jye↗

Flight study of a vehicle operational status and monitoring system

An analog onboard monitoring system was installed on a YF-12 airplane as the first phase of a program to monitor the engine inlet and portions of the airplane's electrical and fuel management subsystems in flight. The system provided data which were considered to form a suitable base for diagnostic test logic and decision criteria for the rest of the program. The data were also adequate for the purpose of maintaining the engine inlet and identifying malfunctions within it. The investigation showed that the requirements of an onboard monitoring system should be considered during the original design of the system to be monitored.

Love, J. E.↗