Results for “flight software testing” — Page 15

NASA NTRS2009

Real-Time Simulation of Ares I Launch Vehicle

The Ares Real-Time Environment for Modeling, Integration, and Simulation (ARTEMIS) has been developed for use by the Ares I launch vehicle System Integration Laboratory (SIL) at the Marshall Space Flight Center (MSFC). The primary purpose of the Ares SIL is to test the vehicle avionics hardware and software in a hardware-in-the-loop (HWIL) environment to certify that the integrated system is prepared for flight. ARTEMIS has been designed to be the real-time software backbone to stimulate all required Ares components through high-fidelity simulation. ARTEMIS has been designed to take full advantage of the advances in underlying computational power now available to support HWIL testing. A modular real-time design relying on a fully distributed computing architecture has been achieved. Two fundamental requirements drove ARTEMIS to pursue the use of high-fidelity simulation models in a real-time environment. First, ARTEMIS must be used to test a man-rated integrated avionics hardware and software system, thus requiring a wide variety of nominal and off-nominal simulation capabilities to certify system robustness. The second driving requirement - derived from a nationwide review of current state-of-the-art HWIL facilities - was that preserving digital model fidelity significantly reduced overall vehicle lifecycle cost by reducing testing time for certification runs and increasing flight tempo through an expanded operational envelope. These two driving requirements necessitated the use of high-fidelity models throughout the ARTEMIS simulation. The nature of the Ares mission profile imposed a variety of additional requirements on the ARTEMIS simulation. The Ares I vehicle is composed of multiple elements, including the First Stage Solid Rocket Booster (SRB), the Upper Stage powered by the J- 2X engine, the Orion Crew Exploration Vehicle (CEV) which houses the crew, the Launch Abort System (LAS), and various secondary elements that separate from the vehicle. At launch, the integrated vehicle stack is composed of these stages, and throughout the mission, various elements separate from the integrated stack and tumble back towards the earth. ARTEMIS must be capable of simulating the integrated stack through the flight as well as propagating each individual element after separation. In addition, abort sequences can lead to other unique configurations of the integrated stack as the timing and sequence of the stage separations are altered.

Tobbe, Patrick↗

NASA NTRS2006

Estimation of Stability and Control Derivatives of an F-15

A technique for real-time estimation of stability and control derivatives (derivatives of moment coefficients with respect to control-surface deflection angles) was used to support a flight demonstration of a concept of an indirect-adaptive intelligent flight control system (IFCS). Traditionally, parameter identification, including estimation of stability and control derivatives, is done post-flight. However, for the indirect-adaptive IFCS concept, parameter identification is required during flight so that the system can modify control laws for a damaged aircraft. The flight demonstration was carried out on a highly modified F-15 airplane (see Figure 1). The main objective was to estimate the stability and control derivatives of the airplane in nearly real time. A secondary goal was to develop a system to automatically assess the quality of the results, so as to be able to tell a learning neural network which data to use. Parameter estimation was performed by use of Fourier-transform regression (FTR) a technique developed at NASA Langley Research Center. FTR is an equation- error technique that operates in the frequency domain. Data are put into the frequency domain by use of a recursive Fourier transform for a discrete frequency set. This calculation simplifies many subsequent calculations, removes biases, and automatically filters out data beyond the chosen frequency range. FTR as applied here was tailored to work with pilot inputs, which produce correlated surface positions that prevent accurate parameter estimates, by replacing half the derivatives with predicted values. FTR was also set up to work only on a recent window of data, to accommodate changes in flight condition. A system of confidence measures was developed to identify quality-parameter estimates that a learning neural network could use. This system judged the estimates primarily on the basis of their estimated variances and of the level of aircraft response. The resulting FTR system was implemented in the Simulink software system and auto-coded in the C programming language for use on the Airborne Research Test System (ARTS II) computer installed in the F-15 airplane. The Simulink model was also used in a control room that utilizes the Ring Buffered Network Bus hardware and software, making it possible to evaluate test points during flights. In-flight parameter estimation was done for piloted and automated maneuvers, primarily at three test conditions. Figure 2 shows results for pitching moment due to symmetric stabilator actuations for a series of three pitch doublet maneuvers (in a doublet maneuver, a command to change attitude in a given direction by a given amount is followed immediately by a command to change attitude in the opposite direction by the same amount). A time window of 5 seconds was used. The portions of the curves shown in red are those that passed the confidence tests. The technique showed good convergence for most derivatives for both kinds of maneuvers - typically within a few seconds. The confidence tests were marginally successful, and it would be necessary to refine them for use in an IFCS.

Smith, Mark↗

NASA NTRS2013

Automatic Parameter Tuning for the Morpheus Vehicle Using Particle Swarm Optimization

A high fidelity simulation using a PC based Trick framework has been developed for Johnson Space Center's Morpheus test bed flight vehicle. There is an iterative development loop of refining and testing the hardware, refining the software, comparing the software simulation to hardware performance and adjusting either or both the hardware and the simulation to extract the best performance from the hardware as well as the most realistic representation of the hardware from the software. A Particle Swarm Optimization (PSO) based technique has been developed that increases speed and accuracy of the iterative development cycle. Parameters in software can be automatically tuned to make the simulation match real world subsystem data from test flights. Special considerations for scale, linearity, discontinuities, can be all but ignored with this technique, allowing fast turnaround both for simulation tune up to match hardware changes as well as during the test and validation phase to help identify hardware issues. Software models with insufficient control authority to match hardware test data can be immediately identified and using this technique requires very little to no specialized knowledge of optimization, freeing model developers to concentrate on spacecraft engineering. Integration of the PSO into the Morpheus development cycle will be discussed as well as a case study highlighting the tool's effectiveness.

Birge, B.↗

NASA NTRS2000

PTS performance by flight- and control-group macaques

A total of 25 young monkeys (Macaca mulatta) were trained with the Psychomotor Test System, a package of software tasks and computer hardware developed for spaceflight research with nonhuman primates. Two flight monkeys and two control monkeys were selected from this pool and performed a psychomotor task before and after the Bion 11 flight or a ground-control period. Monkeys from both groups showed significant disruption in performance after the 14-day flight or simulation (plus one anesthetized day of biopsies and other tests), and this disruption appeared to be magnified for the flight animal.

Flight Experiment↗

NASA NTRS1981

A new method for hardware/software integration of strategic systems - Case study of the Space Shuttle

An advanced system integrated self-test has been developed to provide dynamic checkout of all critical subsystems and hardware/software interfaces of the Space Shuttle during pre-launch ground testing. The system modifies hardware sensor data to represent a real flight scenario. This modified data then drives the flight software. The system was sucessfully utilized for three phases of Space Shuttle testing, and will be expanded for use as a maintenance tool.

Haque, S. I.↗

NASA NTRS1988

Successful completion of a cyclic ground test of a mercury ion auxiliary propulsion system

An engineering model Ion Auxiliary Propulsion System (IAPS) 8-cm thruster (S/N 905) has completed a life test at NASA Lewis Research Center. The mercury ion thruster successfully completed and exceeded the test goals of 2557 on/off cycles and 7057 hr of operation at full thrust. The final 1200 cycles and 3600 hr of the life test were conducted using an engineering model of the IAPS power electronics unit (PEU) and breadboard digital controller and interface unit (DCIU). This portion of the test is described in this paper with a charted history of thruster operating parameters and off-normal events. Performance and operating characteristics were constant throughout the test with only minor variations. The engineering model power electronics unit operated without malfunction; the flight software in the digital controller and interface unit was exercised and verified. Post-test inspection of the thruster revealed facility enhanced accelerator grid erosion but overall the thruster was in good condition. It was concluded that the thruster performance was not drastically degraded by time or cycles. Additional cyclic testing is currently under consideration.

Francisco, David R.↗

NASA NTRS1988

Successful completion of a cyclic ground test of a mercury Ion Auxiliary Propulsion System

An engineering model Ion Auxiliary Propulsion System (IAPS) 8-cm thruster (S/N 905) has completed a life test at NASA Lewis Research Center. The mercury ion thruster successfully completed and exceeded the test goals of 2557 on/off cycles and 7057 hr of operation at full thrust. The final 1200 cycles and 3600 hr of the life test were conducted using an engineering model of the IAPS power electronics unit (PEU) and breadboard digital controller and interface unit (DCIU). This portion of the test is described in this paper with a charted history of thruster operating parameters and off-normal events. Performance and operating characteristics were constant throughout the test with only minor variations. The engineering model power electronics unit operated without malfunction; the flight software in the digital controller and interface unit was exercised and verified. Post-test inspection of the thruster revealed facility enhanced accelerator grid erosion but overall the thruster was in good condition. It was concluded that the thruster performance was not drastically degraded by time or cycles. Additional cyclic testing is currently under consideration.

Francisco, David R.↗

NASA NTRS1982

Integration and software for thermal test of heat rate sensors

A minicomputer controlled radiant test facility is described which was developed and calibrated in an effort to verify analytical thermal models of instrumentation islands installed aboard the space shuttle external tank to measure thermal flight parameters during ascent. Software was provided for the facility as well as for development tests on the SRB actuator tail stock. Additional testing was conducted with the test facility to determine the temperature and heat flux rate and loads required to effect a change of color in the ET tank external paint. This requirement resulted from the review of photographs taken of the ET at separation from the orbiter which showed that 75% of the external tank paint coating had not changed color from its original white color. The paint on the remaining 25% of the tank was either brown or black, indicating that it had degraded due to heating or that the spray on form insulation had receded in these areas. The operational capability of the facility as well as the various tests which were conducted and their results are discussed.

Wojciechowski, C. J.↗

NASA NTRS2002

The Propulsive Small Expendable Deployer System (ProSEDS)

This Annual Report covers the following main topics: 1) Updated Reference Mission. The reference ProSEDS (Propulsive Small Expendable Deployer System) mission is evaluated for an updated launch date in the Summer of 2002 and for the new 80-s current operating cycle. Simulations are run for nominal solar activity condition at the time of launch and for extreme conditions of dynamic forcing. Simulations include the dynamics of the system, the electrodynamics of the bare tether, the neutral atmosphere and the thermal response of the tether. 2) Evaluation of power delivered by the tether system. The power delivered by the tethered system during the battery charging mode is computed under the assumption of minimum solar activity for the new launch date. 3) Updated Deployment Control Profiles and Simulations. A number of new deployment profiles were derived based on the latest results of the deployment ground tests. The flight profile is then derived based on the friction characteristics obtained from the deployment tests of the F-1 tether. 4) Analysis/estimation of deployment flight data. A process was developed to estimate the deployment trajectory of the endmass with respect to the Delta and the final libration amplitude from the data of the deployer turn counters. This software was tested successfully during the ProSEDS mission simulation at MSFC (Marshall Space Flight Center) EDAC (Environments Data Analysis Center).

Lorenzini, Enrico C.↗

NASA NTRS2010

Tools Automate Spacecraft Testing, Operation

"NASA began the Small Explorer (SMEX) program to develop spacecraft to advance astrophysics and space physics. As one of the entities supporting software development at Goddard Space Flight Center, the Hammers Company Inc. (tHC Inc.), of Greenbelt, Maryland, developed the Integrated Test and Operations System to support SMEX. Later, the company received additional Small Business Innovation Research (SBIR) funding from Goddard for a tool to facilitate the development of flight software called VirtualSat. NASA uses the tools to support 15 satellites, and the aerospace industry is using them to develop science instruments, spacecraft computer systems, and navigation and control software."

Source record↗

NASA NTRS2019

Air Traffic Management Technology Demonstration-1 (ATD-1) Avionics Phase 2 Flight Test Training for Interval Management

Prior to the successful flight test validation of a new avionics prototype, participants from Boeing, Honeywell, and United Airlines underwent group training at NASA Langley Research Center. New prototype software for an algorithm which enables greater efficiency in high-density airspace, called Interval Management, was to be incorporated into Electronic Flight Bags and placed in the cockpit for pilot usage. The goals of the training were to teach the flight test pilots how to operate the new software, establish techniques to simultaneously position three aircraft prior to each test scenario, and ensure a common communication protocol among team members when coordinating the position of aircraft for the next scenario. The multi-tiered interactive training regimen consisted of a process that continually built upon previous foundational material. The primary learning elements were 1) a portable computer-based trainer that was provided to the pilots prior to classroom training sessions, 2) classroom learning, 3) full mock-up simulator training, and 4) refresher training just prior to the flight test. Each part of the regimen was designed to repeat and build upon the previous element. The purpose of this Technical Memorandum is to inform the aviation industry how flight training for Interval Management was conducted at Langley Research Center in order to reduce overall development costs of future Interval Management training programs. Secondly, the paper provides insight regarding the decision-making process when attempting to conduct a flight test.

Roper, Roy D.↗

NASA NTRS2016

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.↗

NASA NTRS1982

Evaluation of the Shuttle GN&C during powered ascent flight phase

An overview of the ascent trajectory and GN&C (guidance, navigation, and control) system design is followed by a summary of flight test results for the ascent phase of STS-1. The most notable variance from nominal pre-flight predictions was the lofted trajectory observed in first stage due to an unanticipated shift in pitch aerodynamic characteristics from those predicted by wind tunnel tests. The GN&C systems performed as expected on STS-1 throughout powered flight. Following a discussion of the software constants changed for Flight 2 to provide adequate performance margin, a summary of test results from STS-2 and STS-3 is presented. Vehicle trajectory response and GN&C system behavior were very similar to STS-1. Ascent aerodynamic characteristics extracted from the first two test flights were included in the data base used to design the first stage steering and pitch trim profiles for STS-3.

Olson, L.↗

NASA NTRS2022

Making or Breaking a Rover: System Engineering Parameters On-Board the Mars 2020 Perseverance Rover

On February 18, 2021, Perseverance, NASA’s Jet Propulsion Laboratory’s (JPL’s) Mars 2020 Rover, successfully landed on Mars with all systems nominal, despite the risk surrounding the over 200,000 internal flight parameters that had to be properly configured. The Perseverance team defines these parameters as software variables that are configurable, commandable and retrievable from Earth. In 2015, the Mars 2020 project leaders focused on improving systems engineering of parameters based on their experiences from parameter management on previous Mars rovers (Curiosity, Opportunity, Spirit, and Pathfinder) and parameter failures of past missions, such as the mission-ending parameter of the Mars Climate Orbiter. The new rigorous development process allowed for efficient certification and effective implementation of the parameters, allowing the rover to approach and land on the red planet (the most challenging phase of the mission) with zero parameter issues. Although successful, the Perseverance team learned many lessons for how to better manage parameters for the continued surface operations of the Mars 2020 mission and future missions. This paper will discuss eight parameter-management topics for the Perseverance Mission. The first is parameter definition: how we define parameters on our mission, where they are physically located on the vehicle, and why we have so many of them. The second topic is the updated parameter flight software module from Curiosity, including details on the 99% reduction in parameter commands, new bulk configuration capabilities, and improved parameter traceability. The third topic is parameter selection for different mission phases; this includes improving and tweaking our preferred parameter settings until they become certification candidates and managing parameter configurations based on test venue throughout the mission life cycle. The fourth topic is our flight certification process; this includes certification of flight values for four different epochs in the mission: Launch, Entry Decent and Landing (EDL) - 6days, Landing + 5 Sols (Martian Days, still on Cruise Flight Software), and once are on Surface Flight Software (FSW). The fifth topic covers in-flight command implementation, along with details on testing, validation, and verification of those commands. In the sixth section, we will explain our use of open-source management tools, including how we used GitHub for version control and management approvals. The seventh topic will describe the ground tools used in operations, including capabilities of the in-house built tool called Parasol. The eighth and final topic will dig into lessons learned for improving parameter management in the future of this mission and others.

Roth, Brian↗

NASA NTRS2022

Making or Breaking a Rover- Systems Engineering Parameters On-Board the Mars 2020 Perseverance Rover

On February 18, 2021, Perseverance, NASA’s Jet Propulsion Laboratory’s (JPL’s) Mars 2020 Rover, successfully landed on Mars with all systems nominal, despite the risk surrounding the over 200,000 internal flight parameters that had to be properly configured. The Perseverance team defines these parameters as software variables that are configurable, commandable and retrievable from Earth. In 2015, the Mars 2020 project leaders focused on improving systems engineering of parameters based on their experiences from parameter management on previous Mars rovers (Curiosity, Opportunity, Spirit, and Pathfinder) and parameter failures of past missions, such as the mission-ending parameter of the Mars Climate Orbiter. The new rigorous development process allowed for efficient certification and effective implementation of the parameters, allowing the rover to approach and land on the red planet (the most challenging phase of the mission) with zero parameter issues. Although successful, the Perseverance team learned many lessons for how to better manage parameters for the continued surface operations of the Mars 2020 mission and future missions. This paper will discuss eight parameter-management topics for the Perseverance Mission. The first is parameter definition: how we define parameters on our mission, where they are physically located on the vehicle, and why we have so many of them. The second topic is the updated parameter flight software module from Curiosity, including details on the 99% reduction in parameter commands, new bulk configuration capabilities, and improved parameter traceability. The third topic is parameter selection for different mission phases; this includes improving and tweaking our preferred parameter settings until they become certification candidates and managing parameter configurations based on test venue throughout the mission life cycle. The fourth topic is our flight certification process; this includes certification of flight values for four different epochs in the mission: Launch, Entry Decent and Landing (EDL) - 6days, Landing + 5 Sols (Martian Days, still on Cruise Flight Software), and once are on Surface Flight Software (FSW). The fifth topic covers in-flight command implementation, along with details on testing, validation, and verification of those commands. In the sixth section, we will explain our use of open-source management tools, including how we used GitHub for version control and management approvals. The seventh topic will describe the ground tools used in operations, including capabilities of the in-house built tool called Parasol. The eighth and final topic will dig into lessons learned for improving parameter management in the future of this mission and others.

Roth, Brian↗

NASA NTRS2019

Testing of the Lunar Reconnaissance Orbiter Attitude Control System Re-Design Without a Gyro

The Lunar Reconnaissance Orbiter (LRO) was launched in 2009 and, with itsseven science instruments, has made numerous contributions to our understandingof the moon. LRO is in an elliptical, polar lunar orbit and nominally maintainsa nadir orientation. There are frequent slews off nadir to observe various sciencetargets. LRO attitude control system (ACS) has two star trackers and a gyro forattitude estimation in an extended Kalman filter (EKF) and four reaction wheelsused in a proportional-integral-derivative (PID) controller. LRO is equipped withthrusters for orbit adjustments and momentum management. In early 2018, thegyro was powered off following a fairly rapid decline in the laser intensity on theX axis. Without the gyro, the EKF has been disabled. Attitude is provided by asingle star tracker and a coarse rate estimate is computed by a back differencingof the star tracker quaternions. Slews have also been disabled. A new rate estimationapproach makes use of a complementary filter, combining the quaterniondifferentiated rates and the integrated PID limited control torque (with reactionwheel drag and feedforward torque removed). The filtered rate estimate replacesthe MIMU rate in the EKF, resulting in minimal flight software changes. The paperwill cover the preparation and testing of the new gyroless algorithm, both inground simulations and inflight.

Halverson, Julie↗

NASA NTRS2020

Hardware Verification and Validation for a Navigation Sensor Software Model in Support of Flight Vehicle Performance Analysis

… or, “It’s in the details, how to make complicated software perform like complicated hardware.” In attempts to minimize development time and quickly build an operational vehicle, NASA’s Space Launch System (SLS) has had to be intentional about integrated testing. Constraints on budget and schedule have required balance between testing needs and the desire for an integrated flight vehicle as soon as possible. To provide key insights early in design and analysis cycles, a large amount of effort has shifted into maturing and validating models at the component level with integrated testing as a means to validate their integration. In terms of SLS Navigation, this, and the model-based design approach have pushed explicit requirements for sensor models to be validated against flight hardware to high precision. This paper covers the approach taken to verify and validate the models for the two key navigation sensors on the SLS vehicle, the Redundant Inertial Navigation Sensor and the Rate Gyro Assembly. These models are used in performance evaluation, fault detection, and operations development extensively. Using a mix of data from hardware vendor documentation and testing reports, limited in-house testing, and integration activities, these models were able to be validated against flight hardware at multiple levels, from the internal software design to statistical behavior at the raw sensor and integrated box levels. The high level of insight into the hardware elements is instrumental to support flight certification activities and building confidence in SLS Navigation capability. Focused testing enabled additional insight and validation that proved invaluable and the resulting insights were used to focus and mature models. Additionally, of having validated performance-based hardware models enables a wide breadth of activities including detailed fault detection studies and integration into future vehicle frameworks, such as an upper stage and provide a valuable asset to continued SLS analysis and design.

Evan J Anzalone↗

NASA NTRS2020

Hardware Verification and Validation for a Navigation Sensor Software Model in Support of Flight Vehicle Performance Analysis

… or, “It’s in the details, how to make complicated software perform like complicated hardware.” In attempts to minimize development time and quickly build an operational vehicle, NASA’s Space Launch System (SLS) has had to be intentional about integrated testing. Constraints on budget and schedule have required balance between testing needs and the desire for an integrated flight vehicle as soon as possible. To provide key insights early in design and analysis cycles, a large amount of effort has shifted into maturing and validating models at the component level with integrated testing as a means to validate their integration. In terms of SLS Navigation, this, and the model-based design approach have pushed explicit requirements for sensor models to be validated against flight hardware to high precision. This paper covers the approach taken to verify and validate the models for the two key navigation sensors on the SLS vehicle, the Redundant Inertial Navigation Sensor and the Rate Gyro Assembly. These models are used in performance evaluation, fault detection, and operations development extensively. Using a mix of data from hardware vendor documentation and testing reports, limited in-house testing, and integration activities, these models were able to be validated against flight hardware at multiple levels, from the internal software design to statistical behavior at the raw sensor and integrated box levels. The high level of insight into the hardware elements is instrumental to support flight certification activities and building confidence in SLS Navigation capability. Focused testing enabled additional insight and validation that proved invaluable and the resulting insights were used to focus and mature models. Additionally, of having validated performance-based hardware models enables a wide breadth of activities including detailed fault detection studies and integration into future vehicle frameworks, such as an upper stage and provide a valuable asset to continued SLS analysis and design.

Thomas Park↗