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.

SourceResearch connectionFrom yearThrough year

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

At least 199 records · Page 11

All sources NASA NTRS DOE OSTI

NASA NTRS2011

Virtual Sensor Test Instrumentation

Virtual Sensor Test Instrumentation is based on the concept of smart sensor technology for testing with intelligence needed to perform sell-diagnosis of health, and to participate in a hierarchy of health determination at sensor, process, and system levels. A virtual sensor test instrumentation consists of five elements: (1) a common sensor interface, (2) microprocessor, (3) wireless interface, (4) signal conditioning and ADC/DAC (analog-to-digital conversion/ digital-to-analog conversion), and (5) onboard EEPROM (electrically erasable programmable read-only memory) for metadata storage and executable software to create powerful, scalable, reconfigurable, and reliable embedded and distributed test instruments. In order to maximize the efficient data conversion through the smart sensor node, plug-and-play functionality is required to interface with traditional sensors to enhance their identity and capabilities for data processing and communications. Virtual sensor test instrumentation can be accessible wirelessly via a Network Capable Application Processor (NCAP) or a Smart Transducer Interlace Module (STIM) that may be managed under real-time rule engines for mission-critical applications. The transducer senses the physical quantity being measured and converts it into an electrical signal. The signal is fed to an A/D converter, and is ready for use by the processor to execute functional transformation based on the sensor characteristics stored in a Transducer Electronic Data Sheet (TEDS). Virtual sensor test instrumentation is built upon an open-system architecture with standardized protocol modules/stacks to interface with industry standards and commonly used software. One major benefit for deploying the virtual sensor test instrumentation is the ability, through a plug-and-play common interface, to convert raw sensor data in either analog or digital form, to an IEEE 1451 standard-based smart sensor, which has instructions to program sensors for a wide variety of functions. The sensor data is processed in a distributed fashion across the network, providing a large pool of resources in real time to meet stringent latency requirements.

Wang, Roy↗

NASA NTRS2017

A Virtual Laboratory for Aviation and Airspace Prognostics Research

Integration of Unmanned Aerial Vehicles (UAVs), autonomy, spacecraft, and other aviation technologies, in the airspace is becoming more and more complicated, and will continue to do so in the future. Inclusion of new technology and complexity into the airspace increases the importance and difficulty of safety assurance. Additionally, testing new technologies on complex aviation systems and systems of systems can be challenging, expensive, and at times unsafe when implementing real life scenarios. The application of prognostics to aviation and airspace management may produce new tools and insight into these problems. Prognostic methodology provides an estimate of the health and risks of a component, vehicle, or airspace and knowledge of how that will change over time. That measure is especially useful in safety determination, mission planning, and maintenance scheduling. In our research, we develop a live, distributed, hardware- in-the-loop Prognostics Virtual Laboratory testbed for aviation and airspace prognostics. The developed testbed will be used to validate prediction algorithms for the real-time safety monitoring of the National Airspace System (NAS) and the prediction of unsafe events. In our earlier work1 we discussed the initial Prognostics Virtual Laboratory testbed development work and related results for milestones 1 & 2. This paper describes the design, development, and testing of the integrated tested which are part of milestone 3, along with our next steps for validation of this work. Through a framework consisting of software/hardware modules and associated interface clients, the distributed testbed enables safe, accurate, and inexpensive experimentation and research into airspace and vehicle prognosis that would not have been possible otherwise. The testbed modules can be used cohesively to construct complex and relevant airspace scenarios for research. Four modules are key to this research: the virtual aircraft module which uses the X-Plane simulator and X-PlaneConnect toolbox, the live aircraft module which connects fielded aircraft using onboard cellular communications devices, the hardware in the loop (HITL) module which connects laboratory based bench-top hardware testbeds and the research module which contains diagnostics and prognostics tools for analysis of live air traffic situations and vehicle health conditions. The testbed also features other modules for data recording and playback, information visualization, and air traffic generation. Software reliability, safety, and latency are some of the critical design considerations in development of the testbed.

LVC-DE↗

NASA NTRS2016

Infrared Observations of the Orion Capsule During EFT-1 Hypersonic Reentry

High-resolution infrared observations of the Orion capsule during its atmospheric reentry on December 5, 2015 were made from a US Navy NP-3D. This aircraft, equipped with a long-range optical sensor system, tracked the capsule from Mach 10 to 7 from a distance of approximately 60 nmi. Global surface temperatures of the capsule's thermal heatshield were derived from near infrared intensity measurements. The global surface temperature measurements complemented onboard instrumentation and were invaluable to the interpretation of the in-depth thermocouple measurements which rely on inverse heat transfer methods and material response codes to infer the desired surface temperature from the sub-surface measurements. The full paper will address the motivations behind the NASA Engineering Safety Center sponsored observation and highlight premission planning processes with an emphasis on aircraft placement, optimal instrument configuration and sensor calibrations. Critical aspects of mission operations coordinated from the NASA Johnson Spaceflight Center and integration with the JSC Flight Test Management Office will be discussed. A summary of the imagery that was obtained and processed to global surface temperature will be presented. At the capsule's point of closest approach relative to the imaging system, the spatial resolution was estimated to be approximately 15-inches per pixel and was sufficient to identify localized temperature increases associated with compression pad support hardware on the heatshield. The full paper will discuss the synergy of the quantitative imagery derived temperature maps with in-situ thermocouple measurements. Comparison of limited onboard surface thermocouple data to the image derived surface temperature will be presented. The two complimentary measurements serve as an example of the effective leveraging of resources to advance the understanding of high Mach number environments associated with an ablated heatshield and provide unique data for the validation of design tools and numerical flight simulation techniques. Collaborative opportunities and technology investments in support of planned observations of NASA's next Orion flight test in 2018 will be explored in the full manuscript.

Horvath, Thomas J.↗

NASA NTRSDate not supplied

TPSAS-NF1676L-33992-DND

The CERES Science Team integrates and fuses observations from 6 CERES instruments aboard the Terra, Aqua, S-NPP, and NOAA-20 missions with data from more than 20 other unique data sources. Following the November 2017 launch of CERES Flight Model 6 (FM6) onboard NOAA20, CERES has now amassed over 80 instrument-years of valuable Earth radiation budget data. The rapidly growing volume of CERES data coupled with the introduction of new data products alongside improvements to existing science algorithms fosters the requirement for faster, more flexible, and scalable data production and orchestration. New virtualized, cloud-centric compute hardware hosted by the NASA Langley Research Center’s (LaRC) Atmospheric Sciences Data Center (ASDC) provides an ideal environment for these ever-increasing data production demands for CERES. This poster discusses updates to the implementation of the CERES Data Management Team’s (DMT) CERES AuTomAted job Loading sYSTem (CATALYST), a custom data processing workflow engine for CERES, to use on-demand computing resources to perform automated CERES data production processing in a Linux-based container environment. Linux containers provide CERES the flexibility to build multiple production environments in containers tailored for specific workloads and allow effortless provisioning of resources based on the CERES Science Team’s data production requirements.

Thomas N. Hillyer↗

NASA NTRSDate not supplied

Designing a Flight Test of a Flight Path Management System for Advanced Air Mobility Research

The National Aeronautics and Space Administration (NASA) has completed a flight test to evaluate the performance of an onboard prototype automation system operating in future high density urban airspace. The test was part of a research investigation of the Urban Air Mobility (UAM) concept, with a focus on a future environment having hundreds of simultaneous operations over a metropolitan area. The complexity of this future UAM airspace may require automation capable of replanning an aircraft’s path in the presence of traffic and other changing constraints. A live-virtual-constructive (LVC) approach was used to conduct the test. Prototype automation technology was integrated into one of the two live aircraft, which were combined with virtual traffic to create a mixed reality environment at the target airspace density. In-flight evaluation enabled verification of the automation’s functions and discovery of any unexpected behaviors resulting from its operation in an actual flight environment. The in-flight evaluation also provided data for validation of air traffic simulations. This paper discusses the design, methodology, and challenges overcome to conduct a successful flight test. Remaining challenges, future work, and recommendations to improve the flight test capability are also discussed.

Advanced Air Mobility↗

NASA NTRS1999

Satellite ATM Networks: Architectures and Guidelines Developed

An important element of satellite-supported asynchronous transfer mode (ATM) networking will involve support for the routing and rerouting of active connections. Work published under the auspices of the Telecommunications Industry Association (http://www.tiaonline.org), describes basic architectures and routing protocol issues for satellite ATM (SATATM) networks. The architectures and issues identified will serve as a basis for further development of technical specifications for these SATATM networks. Three ATM network architectures for bent pipe satellites and three ATM network architectures for satellites with onboard ATM switches were developed. The architectures differ from one another in terms of required level of mobility, supported data rates, supported terrestrial interfaces, and onboard processing and switching requirements. The documentation addresses low-, middle-, and geosynchronous-Earth-orbit satellite configurations. The satellite environment may require real-time routing to support the mobility of end devices and nodes of the ATM network itself. This requires the network to be able to reroute active circuits in real time. In addition to supporting mobility, rerouting can also be used to (1) optimize network routing, (2) respond to changing quality-of-service requirements, and (3) provide a fault tolerance mechanism. Traffic management and control functions are necessary in ATM to ensure that the quality-of-service requirements associated with each connection are not violated and also to provide flow and congestion control functions. Functions related to traffic management were identified and described. Most of these traffic management functions will be supported by on-ground ATM switches, but in a hybrid terrestrial-satellite ATM network, some of the traffic management functions may have to be supported by the onboard satellite ATM switch. Future work is planned to examine the tradeoffs of placing traffic management functions onboard a satellite as opposed to implementing those functions at the Earth station components.

vonDeak, Thomas C.↗

NASA NTRS2021

Concept of Operations for OSIRIS-REx Optical Navigation Image Planning

Optical navigation (OpNav) is a critical subsystem of the OSIRIS-REx asteroid sample return mission, which operated in the vicinity of near-Earth asteroid (101955) Bennu from August 2018 through April 2021. A substantial amount of mission resources across multiple subsystems and institutions is required to ensure that the OpNav data are successfully acquired. The KinetX OpNav team, part of the Flight Dynamics System (FDS), is responsible for performing required analysis to develop the OpNav operations plans; requesting, reviewing and verifying the plans; and ultimately using the image data for critical navigation operations. The FDS team, responsible for the mission navigation, is operated by KinetX Aerospace with management and operations support from NASA’s Goddard Space Flight Center. The Science Processing and Operations Center (SPOC), located at the University of Arizona’s Lunar and Planetary Laboratory, is responsible for generating the planning products for all science and most OpNav data. These plans are integrated into the spacecraft sequences, tested, and commanded by the Mission Support Area (MSA) at Lockheed Martin Space. To ensure mission-critical navigation image data are successfully acquired, the plan is developed through a waterfall of planning cycles over the course of 3 months prior to onboard plan execution. During the initial strategic planning for a mission phase, detailed analysis is performed by the OpNav team to conceptualize the concept of operations (ConOps) for image data collection. This phase OpNav Narrative is included along with other strategic planning documents for the key ground segment stakeholders to review and provide feedback. The detailed OpNav plans get defined in the tactical planning cycle, which spans 8 to 3 weeks before the week-long integrated sequence is executed on-board the spacecraft. During the tactical cycle, the initial OpNav Request is submitted along with the science requests, kicking off development of the science and OpNav plans. Once the initial plan is drafted, interfaces are exercised so that the plan can be reviewed and iterated, if necessary. A rigorous schedule is followed by the planning teams during the implementation cycle, spanning the last 18 days before uplink, to ensure all the necessary integration, testing, and reviewing can occur on time. The development of the OpNav planning ConOps, including responsibilities, interfaces, timelines, and procedures, took extensive collaboration across mission elements and institutions. The process was robust throughout the 137 weeks of continuous Optical Navigation Operations at Bennu, which concluded on April 9th, 2021.

Coralie D. Adam↗

NASA NTRS2015

Hardware in the Loop Testing of an Iodine-Fed Hall Thruster

CUBESATS are relatively new spacecraft platforms that are typically deployed from a launch vehicle as a secondary payload,1 providing low-cost access to space for a wide range of end-users. These satellites are comprised of building blocks having dimensions of 10x10x10 cm cu and a mass of 1.33 kg (a 1-U size). While providing low-cost access to space, a major operational limitation is the lack of a propulsion system that can fit within a CubeSat and is capable of executing high delta v maneuvers. This makes it difficult to use CubeSats on missions requiring certain types of maneuvers (i.e. formation flying, spacecraft rendezvous). Recently, work has been performed investigating the use of iodine as a propellant for Hall-effect thrusters (HETs) 2 that could subsequently be used to provide a high specific impulse path to CubeSat propulsion. Iodine stores as a dense solid at very low pressures, making it acceptable as a propellant on a secondary payload. It has exceptionally high ρIsp (density times specific impulse), making it an enabling technology for small satellite near-term applications and providing the potential for systems-level advantages over mid-term high power electric propulsion options. Iodine flow can also be thermally regulated, subliming at relatively low temperature ( less than100 C) to yield I2 vapor at or below 50 torr. At low power, the measured performance of an iodine-fed HET is very similar to that of a state-of-the-art xenon-fed thruster. Just as importantly, the current-voltage discharge characteristics of low power iodine-fed and xenon-fed thrusters are remarkably similar, potentially reducing development and qualifications costs by making it possible to use an already-qualified xenon-HET PPU in an iodine-fed system. Finally, a cold surface can be installed in a vacuum test chamber on which expended iodine propellant can deposit. In addition, the temperature doesn't have to be extremely cold to maintain a low vapor pressure in the vacuum chamber (it is under 10(exp -6) torr at -75 C), making it possible to 'cryopump' the propellant with lower-cost recirculating refrigerant-based systems as opposed to using liquid nitrogen or low temperature gaseous helium cryopanels. In the present paper, we describe testing performed using an iodine-fed 200 W Hall thruster mounted to a thrust stand and operated in conjunction with MSFCs Small Projects Rapid Integration and Test Environment (SPRITE) Portable Hardware In the Loop (PHIL) hardware. This work is performed in support of the iodine satellite (iSAT) project, which aims to fly a 200-W iodine-fed thruster on a 12-U CubeSat. The SPRITE PHIL hardware allows a given vehicle to do a checkout of its avionics algorithm by allowing it to monitor and feed data to simulated sensors and effectors in a digital environment. These data are then used to determine the attitude of the vehicle and a separate computer is used to interpret the data set and visualize it using a 3D graphical interface. The PHIL hardware allows the testing of the vehicles bus by providing 'real' hardware interfaces (in the case of this test a real RS422 bus) and specific components can be modeled to show their interactions with the avionics algorithm (e.g. a thruster model). For the iSAT project the PHIL is used to visualize the operating cycle of the thruster and the subsequent effect this thrusting has on the attitude of the satellite over a given period of time. The test is controlled using software running on an Andrews Space Cortex 160 flight computer. This computer is the current baseline for a full iSAT mission. While the test could be conducted with a lab computer and software, the team chose to exercise the propulsion system with a representative CubeSat-class computer. For purposes of this test, the "flight" software monitored the propulsion and PPU systems, controlled operation of the thruster, and provided thruster state data to the PHIL simulation. Commands to operate the thruster were initiated from an operator's workstation outside the vacuum chamber and passed through the Cortex 160 to exercise portions of the flight avionics. Two custom-designed pieces of electronics hardware have been designed to operate the propellant feed system. One piece of hardware is an auxiliary board that controls a latch valve, proportional flow control valves (PFCVs) and valve heaters as well as measuring pressures, temperatures and PFCV feedback voltage. An onboard FPGA provides a serial link for issuing commands and manages all lower level input-output functions. The other piece of hardware is a power distribution board, which accepts a standard bus voltage input and converts this voltage into all the different current-voltage types required to operate the auxiliary board. These electronics boards are located in the vacuum chamber near the thruster, exposing this hardware to both the vacuum and plasma environments they would encounter during a mission, with these components communicating to the flight computer through an RS-422 interface. The auxiliary board FPGA provides a 28V MOSFET switch circuit with a 20ms pulse to open or close the iodine propellant feed system latch valve. The FPGA provides a pulse width modulation (PWM) signal to a DC/DC boost converter to produce the 12-120V needed for control of the proportional flow control valve. There are eight MOSFET-switched heating circuits in the system. Heaters are 28V and located in the latch valve, PFCV, propellant tank and propellant feed lines. Both the latch valve and PFCV have thermistors built into them for temperature monitoring. There are also seven resistance temperature device (RTD) circuits on the auxiliary board that can be used to measure the propellant tank and feedline temperatures. The signals are conditioned and sent to an analog to digital converter (ADC), which is directly commanded and controlled by the FPGA.

Polzin, Kurt A.↗

NASA NTRS1985

Space station data system analysis/architecture study. Task 3: Trade studies, DR-5, volume 1

The primary objective of Task 3 is to provide additional analysis and insight necessary to support key design/programmatic decision for options quantification and selection for system definition. This includes: (1) the identification of key trade study topics; (2) the definition of a trade study procedure for each topic (issues to be resolved, key inputs, criteria/weighting, methodology); (3) conduct tradeoff and sensitivity analysis; and (4) the review/verification of results within the context of evolving system design and definition. The trade study topics addressed in this volume include space autonomy and function automation, software transportability, system network topology, communications standardization, onboard local area networking, distributed operating system, software configuration management, and the software development environment facility.

Source record↗

NASA NTRS2024

Single Drop Cytometry Onboard the International Space Station

Real-time lab analysis is needed to support clinical decision making and research on human missions to the Moon and Mars. Powerful laboratory instruments, such as flow cytometers, are generally too cumbersome for spaceflight. Here, we show that scant test samples can be measured in microgravity, by a trained astronaut, using a miniature cytometry-based analyzer, the rHEALTH ONE, modified specifically for spaceflight. The base device addresses critical spaceflight requirements including minimal resource utilization and alignment-free optics for surviving rocket launch. To fully enable reduced gravity operation onboard the space station, we incorporated bubble-free fluidics, electromagnetic shielding, and gravity-independent sample introduction. We show microvolume flow cytometry from 10 μL sample drops, with data from five simultaneous channels using 10 μs bin intervals during each sample run, yielding an average of 72 million raw data points in approximately 2 minutes. We demonstrate the device measures each test sample repeatably, including correct identification of a sample that degraded in transit to the International Space Station. This approach can be utilized to further our understanding of spaceflight biology and provide immediate, actionable diagnostic information for management of astronaut health without the need for Earth-dependent analysis.

Daniel J. Rea↗

NASA NTRS1982

Space telescope - Meeting the pointing control challenge with today's technology

The pointing control system of the Space Telescope, which provides target-to-target maneuvering capability and precision pointing on the target star (with 0.007-arcsec stability and 0.01-arcsec accuracy), is described. Spacecraft attitude control is undertaken by onboard computer processing of attitude and rate sensor data that generates reaction wheel torque commands. The Space Telescope Operations Control Center communicates with the Space Telescope via the synchronous altitude tracking and data relay satellite system, and determines vehicle attitude more precisely by means of sun sensors, magnetometers and fixed-head star trackers. Such disturbance torques as those of gravity gradients and aerodynamics act on the Space Telescope, causing the speeds of the four reaction wheels to increase. In order to prevent the wheels from reaching a speed-saturated condition, a momentum control system is provided for the management of reaction wheel speed buildup. Attention is given to development testing and control hardware investigations and improvements.

Dougherty, H.↗

NASA NTRS1993

A real-time navigation monitoring expert system for the Space Shuttle Mission Control Center

The ONAV (Onboard Navigation) Expert System has been developed as a real time console assistant for use by ONAV flight controllers in the Mission Control Center at the Johnson Space Center. This expert knowledge based system is used to monitor the Space Shuttle onboard navigation system, detect faults, and advise flight operations personnel. This application is the first knowledge-based system to use both telemetry and trajectory data from the Mission Operations Computer (MOC). To arrive at this stage, from a prototype to real world application, the ONAV project has had to deal with not only AI issues but operating environment issues. The AI issues included the maturity of AI languages and the debugging tools, verification, and availability, stability and size of the expert pool. The environmental issues included real time data acquisition, hardware suitability, and how to achieve acceptance by users and management.

Wang, Lui↗

NASA NTRS2000

Internet Technology on Spacecraft

The Operating Missions as Nodes on the Internet (OMNI) project has shown that Internet technology works in space missions through a demonstration using the UoSAT-12 spacecraft. An Internet Protocol (IP) stack was installed on the orbiting UoSAT-12 spacecraft and tests were run to demonstrate Internet connectivity and measure performance. This also forms the basis for demonstrating subsequent scenarios. This approach provides capabilities heretofore either too expensive or simply not feasible such as reconfiguration on orbit. The OMNI project recognized the need to reduce the risk perceived by mission managers and did this with a multi-phase strategy. In the initial phase, the concepts were implemented in a prototype system that includes space similar components communicating over the TDRS (space network) and the terrestrial Internet. The demonstration system includes a simulated spacecraft with sample instruments. Over 25 demonstrations have been given to mission and project managers, National Aeronautics and Space Administration (NASA), Department of Defense (DoD), contractor technologists and other decisions makers, This initial phase reached a high point with an OMNI demonstration given from a booth at the Johnson Space Center (JSC) Inspection Day 99 exhibition. The proof to mission managers is provided during this second phase with year 2000 accomplishments: testing the use of Internet technologies onboard an actual spacecraft. This was done with a series of tests performed using the UoSAT-12 spacecraft. This spacecraft was reconfigured on orbit at very low cost. The total period between concept and the first tests was only 6 months! On board software was modified to add an IP stack to support basic IP communications. Also added was support for ping, traceroute and network timing protocol (NTP) tests. These tests show that basic Internet functionality can be used onboard spacecraft. The performance of data was measured to show no degradation from current approaches. The cost to implement is much less than current approaches due to the availability of highly reliable and standard Internet tools. Use of standard Internet applications onboard reduces the risk of obsolescence inherent in custom protocols due to extremely wide use across all domains. These basic building blocks provide the framework for building onboard software to support direct user communication with payloads including payload control. Other benefits are payload to payload communication from dissimilar spacecraft, constellations of spacecraft, and reconfigurability on orbit. This work is funded through contract with the National Aeronautics and Space Administration (NASA) Goddard Space Flight Center (GSFC).

Rash, James↗

NASA NTRS2024

Evolution of Spaceflight Renal Stone Risks and Update to the NASA Human Research Program (HRP) Renal Stone Evidence Report and Integrated Concept of Operations

BACKGROUND: The NASA HRP Evidence Report on the Risk of Renal Stone Formation is being updated based on new information obtained from 9 years of data from NASA’s astronaut renal stone surveillance program. In addition, the Concept of Operations for missions beyond Low Earth Orbit (LEO) was created to supplement the Evidence Report, and the NASA clinical practice guideline(CPG)for renal stone surveillance was updated. OVERVIEW: A literature review was performed to evaluate the state of literature regarding renal stone prevention, mitigation, and management both in terrestrial and spaceflight environments. Current renal stone treatment guidelines for the ISS, which were created by the Inflight Clinical Medicine Working Group and approved by the Multilateral Medical Operations Panel (MMOP)were reviewed, as well as recent ultrasound technology demonstrations onboard the ISS. This information was used in conjunction with emerging evidence from the surveillance program to update the Evidence Report and in-flight Concept of Operations. DISCUSSION: There are known and emerging renal stone prevention strategies including astronaut selection, the use of medications and resistive exercise, early diagnosis with regular urine studies and ultrasound imaging. In-flight treatment options include pharmaceuticals, use of lithotripsy and propulsive ultrasound, placement of percutaneous drains and other modalities. This information is useful to gauge future risks and update our strategies for prevention and management of renal stones in astronauts to reduce the risk of in-flight renal stone colic that could cause morbidity and mission impact.

E Stratton↗

NASA NTRS2005

An Error Analysis of the Phased Array Antenna Pointing Algorithm for STARS Flight Demonstration No. 2

STARS is a multicenter NASA project to determine the feasibility of using space-based assets, such as the Tracking and Data Relay Satellite System (TDRSS) and Global Positioning System (GPS), to increase flexibility (e.g. increase the number of possible launch locations and manage simultaneous operations) and to reduce operational costs by decreasing the need for ground-based range assets and infrastructure. The STARS project includes two major systems: the Range Safety and Range User systems. The latter system uses broadband communications (125 kbps to 500 kbps) for voice, video, and vehicle/payload data. Flight Demonstration #1 revealed the need to increase the data rate of the Range User system. During Flight Demo #2, a Ku-band antenna will generate a higher data rate and will be designed with an embedded pointing algorithm to guarantee that the antenna is pointed directly at TDRS. This algorithm will utilize the onboard position and attitude data to point the antenna to TDRS within a 2-degree full-angle beamwidth. This report investigates how errors in aircraft position and attitude, along with errors in satellite position, propagate into the overall pointing vector.

Carney, Michael P.↗

NASA NTRS2012

Multiplexer/Demultiplexer Loading Tool (MDMLT)

The purpose of the MDMLT is to improve the reliability and speed of loading multiplexers/demultiplexers (MDMs) in the Software Development and Integration Laboratory (SDIL) by automating the configuration management (CM) of the loads in the MDMs, automating the loading procedure, and providing the capability to load multiple or all MDMs concurrently. This loading may be accomplished in parallel, or single MDMs (remote). The MDMLT is a Web-based tool that is capable of loading the entire International Space Station (ISS) MDM configuration in parallel. It is able to load Flight Equivalent Units (FEUs), enhanced, standard, and prototype MDMs as well as both EEPROM (Electrically Erasable Programmable Read-Only Memory) and SSMMU (Solid State Mass Memory Unit) (MASS Memory). This software has extensive configuration management to track loading history, and the performance improvement means of loading the entire ISS MDM configuration of 49 MDMs in approximately 30 minutes, as opposed to 36 hours, which is what it took previously utilizing the flight method of S-Band uplink. The laptop version recently added to the MDMLT suite allows remote lab loading with the CM of information entered into a common database when it is reconnected to the network. This allows the program to reconfigure the test rigs quickly between shifts, allowing the lab to support a variety of onboard configurations during a single day, based on upcoming or current missions. The MDMLT Computer Software Configuration Item (CSCI) supports a Web-based command and control interface to the user. An interface to the SDIL File Transfer Protocol (FTP) server is supported to import Integrated Flight Loads (IFLs) and Internal Product Release Notes (IPRNs) into the database. An interface to the Monitor and Control System (MCS) is supported to control the power state, and to enable or disable the debug port of the MDMs to be loaded. Two direct interfaces to the MDM are supported: a serial interface (debug port) to receive MDM memory dump data and the calculated checksum, and the Small Computer System Interface (SCSI) to transfer load files to MDMs with hard disks. File transfer from the MDM Loading Tool to EEPROM within the MDM is performed via the MILSTD- 1553 bus, making use of the Real- Time Input/Output Processors (RTIOP) when using the rig-based MDMLT, and via a bus box when using the laptop MDMLT. The bus box is a cost-effective alternative to PC-1553 cards for the laptop. It is noted that this system can be modified and adapted to any avionic laboratory for spacecraft computer loading, ship avionics, or aircraft avionics where multiple configurations and strong configuration management of software/firmware loads are required.

Brewer, Lenox Allen↗

NASA NTRS1992

Intelligent diagnostics systems

Intelligent systems have been applied to today's problems and could also be applied to space operations integrity. One of these systems is the XMAN tool designed for 'troubleshooting' jet engines. XMAN is the eXpert MAiNtenance tool developed to be an expert information analysis tool which stores trending and diagnostic data on Air Force engines. XMAN operates with a 'network topology' which follows a flow chart containing engine management information reports required by the governments technical order procedures. With XMAN technology, the user is able to identify engine problems by presenting the assertions of the fault isolation logic and attempting to satisfy individual assertions by referring to the databases created by an engine monitoring system. The troubleshooting process requires interaction between the technician and the computer to acquire new evidence form auxiliary maintenance tests corroboration of analytical results to accurately diagnose equipment malfunctions. This same technology will be required for systems which are functioning in space either with an onboard crew, or with an unmanned system. The technology and lessons learned developing this technology while suggesting definite applications for its use with developing space systems are addressed.

Mcquiston, Barbara M.↗

NASA NTRS2021

Scheduling and Operations of the ECOSTRESS Mission

This paper describes the development and use of an automated scheduling system for the National Aeronautics and Space Administration’s (NASA) ECOsystem Spaceborne Thermal Radiometer Experiment on Space Station (ECOSTRESS) mission. Key to the success of the ECOSTRESS mission has been the use of automated scheduling in mission analysis pre-launch, and in successful operations where automated scheduling was deployed to address several operational challenges. ECOSTRESS uses an adaptation of the Compressed Large-scale Activity Scheduling and Planning (CLASP) system to automatically select science observations respecting area and point target priorities as well as visibility, illumination, onboard storage, and radiation constraints to satisfy high-level prioritized science campaigns. The ECOSTRESS scheduler was used pre-launch to predict the effectiveness of alternative formulations of science campaign definitions accounting for the impact of data volume, keepout, and orbit/illumination/visibility constraints to derive the initial operational science campaign definitions and priorities. The scheduler was then used after instrument checkout for operations. ECOSTRESS has faced multiple operational challenges relating to instrument firmware and hardware, and the scheduler has been updated several times to address these challenges. The instrument Mass Storage Units (MSUs) had operational issues, requiring the scheduler to plan for and schedule commands to handle intricacies of data management. After many months of operations, both MSUs on the instrument became non-functioning and the firmware of the instrument was updated to bypass the MSUs. A further update to the ECOSTRESS scheduler enabled the scheduler to operate in this new operations mode. The ECOSTRESS scheduler has also been updated to improve handling of along-track uncertainty inherent in International Space Station operations. The flexibility and ease of updating of the automated scheduler has been a significant contributor to successful operations of the ECOSTRESS mission.

Padams, Jordan↗