Search NASA⌕ Search

SEARCH · Search NASA

Results for “flight software testing”

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 91 records · Page 5
All sourcesNASA NTRSDOE OSTI
NASA NTRS2016

SEXTANT X-Ray Pulsar Navigation Demonstration: Flight System and Test Results

The Station Explorer for X-ray Timing and Navigation Technology (SEXTANT) is a technology demonstration enhancement to the Neutron-star Interior Composition Explorer (NICER) mission. NICER is a NASA Explorer Mission of Opportunity that will be hosted on the International Space Station (ISS). SEXTANT will, for the first time, demonstrate real-time, on-board X-ray Pulsar Navigation (XNAV), a significant milestone in the quest to establish a GPS-like navigation capability available throughout our Solar System and beyond. This paper gives an overview of the SEXTANT system architecture and describes progress prior to environmental testing of the NICER flight instrument. It provides descriptions and development status of the SEXTANT flight software and ground system, as well as detailed description and results from the flight software functional and performance testing within the high-fidelity Goddard Space Flight Center (GSFC) X-ray Navigation Laboratory Testbed (GXLT) software and hardware simulation environment. Hardware-in-the-loop simulation results are presented, using the engineering model of the NICER timing electronics and the GXLT pulsar simulator-the GXLT precisely controls NASA GSFC's unique Modulated X-ray Source to produce X-rays that make the NICER detector electronics appear as if they were aboard the ISS viewing a sequence of millisecond pulsars

Pulsar↗
NASA NTRS2017

NASA's Space Launch System: Systems Engineering Approach for Affordability and Mission Success

NASA is working toward the first launch of a new, unmatched capability for deep space exploration, with launch readiness planned for 2018. The initial Block 1 configuration of the Space Launch System will more than double the mass and volume to Low Earth Orbit (LEO) of any launch vehicle currently in operation - with a path to evolve to the greatest capability ever developed. The program formally began in 2011. The vehicle successfully passed Preliminary Design Review (PDR) in 2013, Key Decision Point C (KDPC) in 2014 and Critical Design Review (CDR) in October 2015 - nearly 40 years since the last CDR of a NASA human-rated rocket. Every major SLS element has completed components of test and flight hardware. Flight software has completed several development cycles. RS-25 hotfire testing at NASA Stennis Space Center (SSC) has successfully demonstrated the space shuttle-heritage engine can perform to SLS requirements and environments. The five-segment solid rocket booster design has successfully completed two full-size motor firing tests in Utah. Stage and component test facilities at Stennis and NASA Marshall Space Flight Center are nearing completion. Launch and test facilities, as well as transportation and other ground support equipment are largely complete at NASA's Kennedy, Stennis and Marshall field centers. Work is also underway on the more powerful Block 1 B variant with successful completion of the Exploration Upper Stage (EUS) PDR in January 2017. NASA's approach is to develop this heavy lift launch vehicle with limited resources by building on existing subsystem designs and existing hardware where available. The systems engineering and integration (SE&I) of existing and new designs introduces unique challenges and opportunities. The SLS approach was designed with three objectives in mind: 1) Design the vehicle around the capability of existing systems; 2) Reduce work hours for nonhardware/ software activities; 3) Increase the probability of mission success by focusing effort on more critical activities.

Hutt, John J.↗
NASA NTRS2008

Delivery of Colloid Micro-Newton Thrusters for the Space Technology 7 Mission

Two flight-qualified clusters of four Colloid Micro-Newton Thruster (CMNT) systems have been delivered to the Jet Propulsion Laboratory (JPL). The clusters will provide precise spacecraft control for the drag-free technology demonstration mission, Space Technology 7 (ST7). The ST7 mission is sponsored by the NASA New Millennium Program and will demonstrate precision formation flying technologies for future missions such as the Laser Interferometer Space Antenna (LISA) mission. The ST7 disturbance reduction system (DRS) will be on the ESA LISA Pathfinder spacecraft using the European gravitational reference sensor (GRS) as part of the ESA LISA Technology Package (LTP). Developed by Busek Co. Inc., with support from JPL in design and testing, the CMNT has been developed over the last six years into a flight-ready and flight-qualified microthruster system, the first of its kind. Recent flight-unit qualification tests have included vibration and thermal vacuum environmental testing, as well as performance verification and acceptance tests. All tests have been completed successfully prior to delivery to JPL. Delivery of the first flight unit occurred in February of 2008 with the second unit following in May of 2008. Since arrival at JPL, the units have successfully passed through mass distribution, magnetic, and EMI/EMC measurements and tests as part of the integration and test (I&T) activities including the integrated avionics unit (IAU). Flight software sequences have been tested and validated with the full flight DRS instrument successfully to the extent possible in ground testing, including full functional and 72 hour autonomous operations tests. Delivery of the cluster assemblies along with the IAU to ESA for integration into the LISA Pathfinder spacecraft is planned for the summer of 2008 with a planned launch and flight demonstration in late 2010.

Precision Formation Flying↗
NASA NTRS2022

Simulating Mars: Enabling Testing of the Perseverance Rover Sampling and Caching Subsystem on Earth

The development of the Sampling and Caching Subsystem (SCS) on the JPL Perseverance Rover lies at the intersection of testing, robotics, and geology. The SCS team established three primary system test campaigns and venues to aid in the development of SCS through verification and validation testing – Qualification Model Dirty Testing (QMDT) to provide a venue for testing in a Martian environment, Vehicle System Testbed (VSTB) for testing while integrated with the mobility subsystem on Martian-like terrain, and the Flight Software Testbed (FSWTB) for conducting tests using the flight motor controllers and software system on a hexapod which had the ability to simulate rover tilt. Each venue contributed a vital piece to the SCS building blocks. However, the QMDT venue operating within a 10-ft diameter Thermal Vacuum chamber to simulate Martian environment provided a sui generis opportunity to fine tune the entire sampling and caching process while building the team’s knowledge base about rock drillability, system life, and target selection. On Earth, because Martian rocks are not readily available, the development team must utilize geoanalogs to the rocks and regolith on Mars. Geologists on the team helped establish a set of standard rock types to use for Mars missions, like Basalt, Sandstone, Mudstone, Gypsum, and other related geoanalogs. These geoanalogs are characterized with a standard suite of tests for density, compressibility, and other characteristics to categorize potential drillability. This concept of drillability is what links the geoanalogs on Earth to the samples we collect on Mars. With the simulant characteristics defined, these geoanalog rocks are ready to be drilled into as we do on the Martian surface. A key aspect of interacting with the surface on Mars is rock target identification and selection. The Perseverance robotic system uses the on-board cameras, instrumentation, and software to collect enough information to identify potential scientific targets. With the targets identified, SCS can place the Corer and abrade the surface or collect a sample. For a ground test activity like QMDT, the test team did not have all of the camera and instrumentation systems that the rover does, so the team developed ground test equivalents to process a rock, build a target map, and define the target. The team constructed a Rock Scanning Station to build a 3D point cloud of the rock. This point cloud was then processed and evaluated with predefined and programmed criteria in a Target Downselect Tool. A primary output of the Target Downselect Tool is a defined target that can be uploaded directly to the robotic software system to simulate and build the robotic sequences used in tests. With these insights and programmatic definition of targets, the QMDT test team was able to make the same decisions that the Perseverance surface operations team does. In addition, valuable lessons learned from developing the target selection ground tools and using them were implemented into the tools used for surface operations.

Kim, Junggon↗
NASA NTRS1979

Integrated testing and verification system for research flight software design document

The NASA Langley Research Center is developing the MUST (Multipurpose User-oriented Software Technology) program to cut the cost of producing research flight software through a system of software support tools. The HAL/S language is the primary subject of the design. Boeing Computer Services Company (BCS) has designed an integrated verification and testing capability as part of MUST. Documentation, verification and test options are provided with special attention on real time, multiprocessing issues. The needs of the entire software production cycle have been considered, with effective management and reduced lifecycle costs as foremost goals. Capabilities have been included in the design for static detection of data flow anomalies involving communicating concurrent processes. Some types of ill formed process synchronization and deadlock also are detected statically.

Taylor, R. N.↗
NASA NTRS2013

Lean Development with the Morpheus Simulation Software

The Morpheus project is an autonomous robotic testbed currently in development at NASA's Johnson Space Center (JSC) with support from other centers. Its primary objectives are to test new 'green' fuel propulsion systems and to demonstrate the capability of the Autonomous Lander Hazard Avoidance Technology (ALHAT) sensor, provided by the Jet Propulsion Laboratory (JPL) on a lunar landing trajectory. If successful, these technologies and lessons learned from the Morpheus testing cycle may be incorporated into a landing descent vehicle used on the moon, an asteroid, or Mars. In an effort to reduce development costs and cycle time, the project employs lean development engineering practices in its development of flight and simulation software. The Morpheus simulation makes use of existing software packages where possible to reduce the development time. The development and testing of flight software occurs primarily through the frequent test operation of the vehicle and incrementally increasing the scope of the test. With rapid development cycles, risk of loss of the vehicle and loss of the mission are possible, but efficient progress in development would not be possible without that risk.

Brogley, Aaron C.↗
NASA NTRS2009

Importance of Model Simulations in Cassini In-Flight Mission Events

Simulation environments have been an integral part of Cassini's heritage. From the time of flight software development and testing to the beginning of the spacecraft's extended mission operations, both softsim and hardware-in-the-loop testbeds have played vital roles in verifying and validating key mission events. Satellite flybys and mission-critical events have established the need to model Titan's atmospheric torque, Enceladus' plume density, and other key parametric spacecraft environments. This paper will focus on enhancements to Cassini's Flight Software Development System (FSDS) and Integrated Test Laboratory (ITL) to model key event attributes which establish valid test environments and ensure safe spacecraft operability. Comparisons between simulated to in-flight data are presented which substantiate model validity.

FSDS↗
NASA NTRS2022

Electrical Ground Support Equipment for the Sampling Caching System of the Mars 2020 Rover

In this work we describe in detail the architecture, design, testing and operation of the Electrical Ground Support Equipment (EGSE) “Blue Box” used to test and validate the Sampling Caching System (SCS) of the Mars 2020 Perseverance rover. The Blue Box architecture is centered around COTS motor controllers and COTS input-output modules communicating over an EtherCAT bus. A custom, low-level safety subsystem ensures no harm can be done to the flight articles. The modular architecture of the EGSE reduces cost and complexity while expediting assembly time. The Blue Box drives the 19 actuators of the SCS which span the main robotic arm, the corer system, the internal sample handling arm, the sample tube sealing system and the gas dust removal tool; mimicking the Rover Motor Control Assembly (RMCA). Due to the limited availability of RMCA’s, the EGSE enabled and performed the bulk of testing activities for SCS. The majority of the SCS actuators are composed of a 3-phase DC brushless motors, hall sensors for commutation, dual resolvers for output angular measurement, brakes, heaters and platinum thermistors. Additionally, the EGSE read 12 strain gauges forming part of a force torque sensor, and switches used for external positioning references. Over the 3-year span of the V&V campaign for the SCS, over 32 EGSE systems were built, tested and deployed to test venues at JPL and externally. The EGSE tested several families of the SCS subsystem, ranging from engineering units, life test units and two flight units. Test venues that this EGSE supported included lab benches, ultra-clean cleanrooms, ATLO facilities, and thermal vacuum chambers. Together with the test software systems, SSDEV and SSDEV-ECAT, the Blue Box EGSE enabled the team to efficiently test flight hardware and flight software together. We go over the safety features and fault management techniques employed to protect flight hardware. The effects of the long, 50-feet, EGSE harnesses on motor performance, EMI, electrical noise, and motor control performance are explained. Mitigations to these unwanted effects, including shielding strategy and inductance compensation, are summarized. We go over an excerpt of notable anomalies that this EGSE suffered through its operation, along with investigations and resolutions. Lessons learned, areas of improvement as part of future work, and recommendations for future implementations for similar EGSE’s, are shared.

Levine, Dan↗
NASA NTRSDate not supplied

OASSIS: Onboard Adaptive Safe-site Identification System Y3

The OASSIS Year 3 project continues to innovate with three goals: 1) transition to a generic configuration compatible with GNC flight software, 2) implement a new, computationally-efficient TRN algorithm for lunar landing, and 3) integrate with the a HWIL testbed to validate lunar landing GNC systems. This project enables lunar lander GNC flight software to be tested dynamically without the need of a costly flight campaign and without the risk of catastrophic hardware loss. Additionally, the TRN algorithm development and testing enhances the state-of-the-art in pinpoint landing navigation, ultimately improving the overall landing accuracy, safety, and reliability of a crewed lunar landing mission.

James S Mccabe↗
NASA NTRS2015

A Vehicle Management End-to-End Testing and Analysis Platform for Validation of Mission and Fault Management Algorithms to Reduce Risk for NASA's Space Launch System

The engineering development of the new Space Launch System (SLS) launch vehicle requires cross discipline teams with extensive knowledge of launch vehicle subsystems, information theory, and autonomous algorithms dealing with all operations from pre-launch through on orbit operations. The characteristics of these spacecraft systems must be matched with the autonomous algorithm monitoring and mitigation capabilities for accurate control and response to abnormal conditions throughout all vehicle mission flight phases, including precipitating safing actions and crew aborts. This presents a large and complex system engineering challenge, which is being addressed in part by focusing on the specific subsystems involved in the handling of off-nominal mission and fault tolerance with response management. Using traditional model based system and software engineering design principles from the Unified Modeling Language (UML) and Systems Modeling Language (SysML), the Mission and Fault Management (M&FM) algorithms for the vehicle are crafted and vetted in specialized Integrated Development Teams (IDTs) composed of multiple development disciplines such as Systems Engineering (SE), Flight Software (FSW), Safety and Mission Assurance (S&MA) and the major subsystems and vehicle elements such as Main Propulsion Systems (MPS), boosters, avionics, Guidance, Navigation, and Control (GNC), Thrust Vector Control (TVC), and liquid engines. These model based algorithms and their development lifecycle from inception through Flight Software certification are an important focus of this development effort to further insure reliable detection and response to off-nominal vehicle states during all phases of vehicle operation from pre-launch through end of flight. NASA formed a dedicated M&FM team for addressing fault management early in the development lifecycle for the SLS initiative. As part of the development of the M&FM capabilities, this team has developed a dedicated testbed that integrates specific M&FM algorithms, specialized nominal and off-nominal test cases, and vendor-supplied physics-based launch vehicle subsystem models. Additionally, the team has developed processes for implementing and validating these algorithms for concept validation and risk reduction for the SLS program. The flexibility of the Vehicle Management End-to-end Testbed (VMET) enables thorough testing of the M&FM algorithms by providing configurable suites of both nominal and off-nominal test cases to validate the developed algorithms utilizing actual subsystem models such as MPS. The intent of VMET is to validate the M&FM algorithms and substantiate them with performance baselines for each of the target vehicle subsystems in an independent platform exterior to the flight software development infrastructure and its related testing entities. In any software development process there is inherent risk in the interpretation and implementation of concepts into software through requirements and test cases into flight software compounded with potential human errors throughout the development lifecycle. Risk reduction is addressed by the M&FM analysis group working with other organizations such as S&MA, Structures and Environments, GNC, Orion, the Crew Office, Flight Operations, and Ground Operations by assessing performance of the M&FM algorithms in terms of their ability to reduce Loss of Mission and Loss of Crew probabilities. In addition, through state machine and diagnostic modeling, analysis efforts investigate a broader suite of failure effects and associated detection and responses that can be tested in VMET to ensure that failures can be detected, and confirm that responses do not create additional risks or cause undesired states through interactive dynamic effects with other algorithms and systems. VMET further contributes to risk reduction by prototyping and exercising the M&FM algorithms early in their implementation and without any inherent hindrances such as meeting FSW processor scheduling constraints due to their target platform - ARINC 653 partitioned OS, resource limitations, and other factors related to integration with other subsystems not directly involved with M&FM such as telemetry packing and processing. The baseline plan for use of VMET encompasses testing the original M&FM algorithms coded in the same C++ language and state machine architectural concepts as that used by Flight Software. This enables the development of performance standards and test cases to characterize the M&FM algorithms and sets a benchmark from which to measure the effectiveness of M&FM algorithms performance in the FSW development and test processes.

Trevino, Luis↗
NASA NTRS2013

Orion MPCV GN and C End-to-End Phasing Tests

End-to-end integration tests are critical risk reduction efforts for any complex vehicle. Phasing tests are an end-to-end integrated test that validates system directional phasing (polarity) from sensor measurement through software algorithms to end effector response. Phasing tests are typically performed on a fully integrated and assembled flight vehicle where sensors are stimulated by moving the vehicle and the effectors are observed for proper polarity. Orion Multi-Purpose Crew Vehicle (MPCV) Pad Abort 1 (PA-1) Phasing Test was conducted from inertial measurement to Launch Abort System (LAS). Orion Exploration Flight Test 1 (EFT-1) has two end-to-end phasing tests planned. The first test from inertial measurement to Crew Module (CM) reaction control system thrusters uses navigation and flight control system software algorithms to process commands. The second test from inertial measurement to CM S-Band Phased Array Antenna (PAA) uses navigation and communication system software algorithms to process commands. Future Orion flights include Ascent Abort Flight Test 2 (AA-2) and Exploration Mission 1 (EM-1). These flights will include additional or updated sensors, software algorithms and effectors. This paper will explore the implementation of end-to-end phasing tests on a flight vehicle which has many constraints, trade-offs and compromises. Orion PA-1 Phasing Test was conducted at White Sands Missile Range (WSMR) from March 4-6, 2010. This test decreased the risk of mission failure by demonstrating proper flight control system polarity. Demonstration was achieved by stimulating the primary navigation sensor, processing sensor data to commands and viewing propulsion response. PA-1 primary navigation sensor was a Space Integrated Inertial Navigation System (INS) and Global Positioning System (GPS) (SIGI) which has onboard processing, INS (3 accelerometers and 3 rate gyros) and no GPS receiver. SIGI data was processed by GN&C software into thrust magnitude and direction commands. The processing changes through three phases of powered flight: pitchover, downrange and reorientation. The primary inputs to GN&C are attitude position, attitude rates, angle of attack (AOA) and angle of sideslip (AOS). Pitch and yaw attitude and attitude rate responses were verified by using a flight spare SIGI mounted to a 2-axis rate table. AOA and AOS responses were verified by using a data recorded from SIGI movements on a robotic arm located at NASA Johnson Space Center. The data was consolidated and used in an open-loop data input to the SIGI. Propulsion was the Launch Abort System (LAS) Attitude Control Motor (ACM) which consisted of a solid motor with 8 nozzles. Each nozzle has active thrust control by varying throat area with a pintle. LAS ACM pintles are observable through optically transparent nozzle covers. SIGI movements on robot arm, SIGI rate table movements and LAS ACM pintle responses were video recorded as test artifacts for analysis and evaluation. The PA-1 Phasing Test design was determined based on test performance requirements, operational restrictions and EGSE capabilities. This development progressed during different stages. For convenience these development stages are initial, working group, tiger team, Engineering Review Team (ERT) and final.

Neumann, Brian C.↗
NASA NTRS1984

Investigation of a nozzle instability on an F100 engine equipped with a digital electronic engine control

An instability in the nozzle of the F100 engine, equipped with a digital electronic engine control (DEEC), was observed during a flight evaluation on an F-15 aircraft. The instability occurred in the upper left hand corner (ULMC) of the flight envelope during augmentation. The instability was not predicted by stability analysis, closed-loop simulations of the the engine, or altitude testing of the engine. The instability caused stalls and augmentor blowouts. The nozzle instability and the altitude testing are described. Linear analysis and nonlinear digital simulation test results are presented. Software modifications on further flight test are discussed.

Burcham, F. W., Jr.↗
NASA NTRS2013

The Mars Science Laboratory Entry, Descent, and Landing Flight Software

This paper describes the design, development, and testing of the EDL program from the perspective of the software engineer. We briefly cover the overall MSL flight software organization, and then the organization of EDL itself. We discuss the timeline, the structure of the GNC code (but not the algorithms as they are covered elsewhere in this conference) and the command and telemetry interfaces. Finally, we cover testing and the influence that testability had on the EDL flight software design.

Entry, Descent, Landing (EDL)↗
NASA NTRS2003

Development and Flight Testing of an Autonomous Landing Gear Health-Monitoring System

Development and testing of an adaptable vehicle health-monitoring architecture is presented. The architecture is being developed for a fleet of vehicles. It has three operational levels: one or more remote data acquisition units located throughout the vehicle; a command and control unit located within the vehicle; and, a terminal collection unit to collect analysis results from all vehicles. Each level is capable of performing autonomous analysis with a trained expert system. Communication between all levels is done with wireless radio frequency interfaces. The remote data acquisition unit has an eight channel programmable digital interface that allows the user discretion for choosing type of sensors; number of sensors, sensor sampling rate and sampling duration for each sensor. The architecture provides framework for a tributary analysis. All measurements at the lowest operational level are reduced to provide analysis results necessary to gauge changes from established baselines. These are then collected at the next level to identify any global trends or common features from the prior level. This process is repeated until the results are reduced at the highest operational level. In the framework, only analysis results are forwarded to the next level to reduce telemetry congestion. The system's remote data acquisition hardware and non-analysis software have been flight tested on the NASA Langley B757's main landing gear. The flight tests were performed to validate the following: the wireless radio frequency communication capabilities of the system, the hardware design, command and control; software operation; and, data acquisition, storage and retrieval.

Woodard, Stanley E.↗
NASA NTRS2006

Evolution of the Hubble Space Telescope Safing Systems

The Hubble Space Telescope (HST) was launched on April 24 1990, with an expected lifespan of 15 years. Central to the spacecraft design was the concept of a series of on-orbit shuttle servicing missions permitting astronauts to replace failed equipment, update the scientific instruments and keep the HST at the forefront of astronomical discoveries. One key to the success of the Hubble mission has been the robust Safing systems designed to monitor the performance of the observatory and to react to keep the spacecraft safe in the event of equipment anomaly. The spacecraft Safing System consists of a range of software tests in the primary flight computer that evaluate the performance of mission critical hardware, safe modes that are activated when the primary control mode is deemed inadequate for protecting the vehicle, and special actions that the computer can take to autonomously reconfigure critical hardware. The HST Safing System was structured to autonomously detect electrical power system, data management system, and pointing control system malfunctions and to configure the vehicle to ensure safe operation without ground intervention for up to 72 hours. There is also a dedicated safe mode computer that constantly monitors a keep-alive signal from the primary computer. If this signal stops, the safe mode computer shuts down the primary computer and takes over control of the vehicle, putting it into a safe, low-power configuration. The HST Safing system has continued to evolve as equipment has aged, as new hardware has been installed on the vehicle, and as the operation modes have matured during the mission. Along with the continual refinement of the limits used in the safing tests, several new tests have been added to the monitoring system, and new safe modes have been added to the flight software. This paper will focus on the evolution of the HST Safing System and Safing tests, and the importance of this evolution to prolonging the science operations of the telescope.

Pepe, Joyce↗
NASA NTRS2016

Thomas Leps Internship Abstract

An optical navigation system is being flown as the backup system to the primary Deep Space Network telemetry for navigation and guidance purposes on Orion. This is required to ensure Orion can recover from a loss of communication, which would simultaneously cause a loss of DSN telemetry. Images taken of the Moon and Earth are used to give range and position information to the navigation computer for trajectory calculations and maneuver execution. To get telemetry data from these images, the size and location of the moon need to be calculated with high accuracy and precision. The reentry envelope for the Orion EM-1 mission requires the centroid and radius of the moon images to be determined within 1/3 of a pixel 3 sigma. In order to ensure this accuracy and precision can be attained, I was tasked with building precise dot grid images for camera calibration as well as building a hardware in the loop test stand for flight software and hardware proofing. To calibrate the Op-Nav camera a dot grid is imaged with the camera, the error between the image dot location and the actual dot location can be used to build a distortion map of the camera and lens system so that images can be fixed to display truth locations. To build the dot grid images I used the Electro Optics Lab optical bench Bright Object Simulator System, and gimbal. The gimbal was slewed to a series of elevations and azimuths. An image of the collimated single point light source was then taken at each position. After a series of 99 images were taken at different locations the single light spots were extracted from each image and added to a composite image containing all 99 points. During the development of these grids it was noticed that an intermittent error in the artificial "star" locations occurred. Prior to the summer this error was attributed to the gimbal having glitches in it's pointing direction and was going to be replaced, however after further examining the issue I determined it to be a software issue. I have since narrowed the likely source of the error down to a Software Development Kit released by the camera supplier PixeLink. I have since developed a workaround in order to build star grids for calibration until the software bug can be isolated and fixed. I was also tasked with building a Hardware in the Loop test stand in order to test the full Op-Nav system. A 4k screen displays simulated Lunar and Terrestrial images from a possible Orion trajectory. These images are then projected through a collimator and then captured with an Op-Nav camera controlled by an Intel NUC computer running flight software. The flight software then analyzes the images to determine attitude and position, this data is then reconstructed into a trajectory and matched to the simulated trajectory in order to determine the accuracy of the attitude and position estimates. In order for the system to work it needs to be precisely and accurately aligned. I developed an alignment procedure that allows the screen, collimator and camera to be squared, centered and collinear with each other within a micron spatially and 5 arcseconds in rotation. I also designed a rigid mount for the screen that was machined on site in Building 10 by another intern. While I was working in the EOL we received a $500k Orion startracker for alignment procedure testing. Due to my prior experience in electronics development, as an ancillary duty, I was tasked with building the cables required to operate and power the startracker. If any errors are made building these cables the startracker would be destroyed, I was honored that the director of the lab entrusted such a critical component with me. This internship has cemented my view on public space exploration. I always preferred public sector to privatization because, as a scientist, the most interesting aspects of space for me are not necessarily the most profitable. I was concerned that the public sector was faltering however, and that in order to improve human space exploration I would be forced into private sector. I now know that, at least at JSC, human spaceflight is still progressing, and exciting work is still being done. I am now actively seeking employment at JSC after I complete my Ph.D and have met with my branch chiefs and mentor to discuss transitioning to a grad Co-op position.

Leps, Thomas↗
NASA NTRS2017

Implementation of Real-Time Hardware in the Loop Simulation for WAVE Instrument Avionics

The Regolith and Environment Science and Oxygen and Lunar Volatile Extraction (RESOLVE) payload will lead the Resource Prospector rover to hydrogen-rich locations on the moon supporting NASA's in-situ resource utilization (ISRU) mission. The Water Analysis and Volatile Extraction (WAVE) system will be responsible for heating up regolith samples and analyzing their volatiles in a vaporized state. Given the space environment, testing flight hardware and software using the scientific instruments can be costly and time consuming, which can hold back progress involving the instruments. A hardware-in-the-loop (HITL) simulation will test the Avionics Data Acquisition as well as the Instrument Interface Unit, through simulating sensors and actuators involved in supporting the WAVE instruments. HITL is a platform for testing and developing WAVE's avionics and software, where the simulation plant will imitate the LAVA and OVEN instruments, thus allowing for an accessible, efficient, and replicable testing environment.

Al Qaraghuli, Ali↗
NASA NTRS1995

Concept Designed and Developed for Distortion- Tolerant, High-Stability Engine Control

Engine Control Future aircraft turbine engines, both commercial and military, must be able to successfully accommodate expected increased levels of steady-state and dynamic engine-face distortion. Advanced tactical aircraft are likely to use thrust vectoring to enhance their maneuverability. As a result, the engines will see more extreme aircraft angles-of-attack and sideslip levels than are currently encountered with present-day aircraft. Also, the mixed-compression inlets needed for the High Speed Civil Transport will likely encounter disturbances similar to those seen by tactical aircraft, in addition to planar pulse, inlet buzz, and high distortion levels at low flight speed and off-design operation. The current approach of incorporating a sufficient component design stall margin to tolerate these increased levels of distortion would significantly reduce performance. The objective of the High Stability Engine Control (HISTEC) program is to design, develop, and flight demonstrate an advanced, high-stability, integrated engine-control system that uses measurement-based, real-time estimates of distortion to enhance engine stability. The resulting distortion-tolerant control reduces the required design stall margin, with a corresponding increase in performance and decrease in fuel burn. The HISTEC concept has been designed and developed, and the software implementing the concept has successfully accommodated time-varying distortion. The NASA Lewis Research Center is currently overseeing the development and validation of the hardware and software necessary to flight test the HISTEC concept. HISTEC is a contracted effort with Pratt & Whitney of West Palm Beach, Florida. The HISTEC approach includes two major systems: A Distortion Estimation System (DES) and Stability Management Control (SMC). DES is an aircraft-mounted, high-speed processor that estimates the amount and type of distortion present and its effect on the engine. It uses high-response pressure measurements at the engine face to calculate indicators of the type and extent of distortion in real time. From these indicators, DES determines the effects of distortion on the propulsion systems and the corresponding engine match point necessary to accommodate it. DES output consists of fan and compressor pressure ratio trim commands that are passed to the SMC. In addition, DES uses maneuver information, consisting of angle-of-attack and sideslip from the flight control, to anticipate high inlet distortion conditions. The SMC, which is contained in the engine-mounted, Improved Digital Electronic Engine Control (IDEEC), includes advanced control laws to directly control the fan and compressor transient operating line (pressure ratio). These advanced control laws, with a multivariable design, have the potential for higher bandwidth and the resulting more precise control of engine match. The ability to measure and assess the distortion effects in real time coupled with a high-response controller improves engine stability at high levels of distortion. The software algorithms implementing DES have been designed, developed, and demonstrated, and integration testing of the DES and SMC software has been completed. The results show that the HISTEC system will be able to sense inlet distortion, determine the effect on engine stability, and accommodate distortion by maintaining an adequate margin for engine surge. The Pratt &Whitney Comprehensive Engine Diagnostic Unit was chosen as the DES processor. An instrumented inlet case for sensing distortion was designed and fabricated. HISTEC is scheduled for flight test on the ACTIVE F-15 aircraft at the NASA Dryden Flight Research Center in Edwards, California, in late 1996.

Source record↗