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 253 records · Page 14
All sourcesNASA NTRSDOE OSTI
NASA NTRS1986

An empirical study of flight control software reliability

The results of a laboratory experiment in flight control software reliability are reported. The experiment tests a small sample of implementations of a pitch axis control law for a PA28 aircraft with over 14 million pitch commands with varying levels of additive input and feedback noise. The testing which uses the method of n-version programming for error detection surfaced four software faults in one implementation of the control law. The small number of detected faults precluded the conduct of the error burst analyses. The pitch axis problem provides data for use in constructing a model in the prediction of the reliability of software in systems with feedback. The study is undertaken to find means to perform reliability evaluations of flight control software.

Dunham, J. R.↗
NASA NTRS2006

Development of a Low-Cost Sub-Scale Aircraft for Flight Research: The FASER Project

An inexpensive unmanned sub-scale aircraft was developed to conduct frequent flight test experiments for research and demonstration of advanced dynamic modeling and control design concepts. This paper describes the aircraft, flight systems, flight operations, and data compatibility including details of some practical problems encountered and the solutions found. The aircraft, named Free-flying Aircraft for Sub-scale Experimental Research, or FASER, was outfitted with high-quality instrumentation to measure aircraft inputs and states, as well as vehicle health parameters. Flight data are stored onboard, but can also be telemetered to a ground station in real time for analysis. Commercial-off-the-shelf hardware and software were used as often as possible. The flight computer is based on the PC104 platform, and runs xPC-Target software. Extensive wind tunnel testing was conducted with the same aircraft used for flight testing, and a six degree-of-freedom simulation with nonlinear aerodynamics was developed to support flight tests. Flight tests to date have been conducted to mature the flight operations, validate the instrumentation, and check the flight data for kinematic consistency. Data compatibility analysis showed that the flight data are accurate and consistent after corrections are made for estimated systematic instrumentation errors.

Owens, Donald B.↗
NASA NTRS2026

Development of the Orion Life-Support Integration Facility (OLIF)

Testing the life support hardware of a vehicle that is going to take humans beyond low-Earth orbit (LEO) in conditions similar to space is crucial. The Orion Life-Support Integration Facility (OLIF) at NASA Johnson Space Center (JSC) was designed and built to test the Orion vehicle’s hardware and software as integrated systems to provide a complete Environmental Control and Life Support System (ECLSS) system-level qualification. The existing 11 Foot human rated vacuum chamber has been adapted to accommodate and integrate various qualification and flight like components of the Orion vehicle’s Air Revitalization System (ARS), Pressure Control System (PCS), Active Thermal Control System (ATCS) and the Orion Crew Survival System Suits (OCSS). The ultimate goal was to create an analog testbed that could safely support up to four test subjects in open “shirt-sleeve” or closed suit loop configurations and simulate Orion Cabin conditions. This integrated hardware/software ARS and PCS will help identify any technical issues that should be addressed prior to the Artemis-2 mission. This paper will discuss the history of Orion ECLSS hardware development testing in the 11 Foot Chamber, the challenge of integrating flight hardware and software control systems, and the capabilities that make it a unique, world class facility for NASA. It will provide an overview of past and future testing, and the lessons learned along the way.

Peter A Masi↗
NASA NTRS2013

Orion GNC Mitigation Efforts for Van Allen Radiation

The Orion Crew Module (CM) is NASA's next generation manned space vehicle, scheduled to return humans to lunar orbit in the coming decade. The Orion avionics and GN&C architectures have progressed through a number of project phases and are nearing completion of a major milestone. The first unmanned test mission, dubbed "Exploration Flight Test One" (EFT-1) is scheduled to launch from NASA Kennedy Space Center late next year and provides the first integrated test of all the vehicle systems, avionics and software. The EFT-1 mission will be an unmanned test flight that includes a high speed re-entry from an elliptical orbit, which will be launched on an expendable launch vehicle (ELV). The ELV will place CM and the ELV upper stage into a low Earth orbit (LEO) for one revolution. After the first LEO, the ELV upper stage will re-ignite and place the combined upper stage/CM into an elliptical orbit whose perigee results in a high energy entry to test CM response in a relatively high velocity, high heating environment. While not producing entry velocities as high as those experienced in returning from a lunar orbit, the trajectory was chosen to provide higher stresses on the thermal protection and guided entry systems, as compared against a lower energy LEO entry. However the required entry geometry with constraints on inclination and landing site result in a trajectory that lingers for many hours in the Van Allen radiation belts. This exposes the vehicle and avionics to much higher levels of high energy proton radiation than a typical LEO or lunar trajectory would encounter. As a result, Van Allen radiation poses a significant risk to the Orion avionics system, and particularly the Flight Control Module (FCM) computers that house the GN&C flight software. The measures taken by the Orion GN&C, Flight Software and Avionics teams to mitigate the risks associated with the Van Allen radiation on EFT-1 are covered in the paper. Background on the Orion avionics subsystem is provided, as well as an overview of the GN&C software architecture. The measures taken to handle radiation induced failure of the one or both of the FCM's are presented, and finally simulation and actual hardware-in-the-loop (HWIL) results are shown confirming the validity of the implementation. The paper presents an overview of the Orion avionics architecture describing the GNC sensors, onboard data network as well as the flight control computers and their planned restart capabilities. GN&C sensors include two Orion Inertial Measurement Units (OIMU's), a Vision Processing Unit (VPU) to process camera images, three barometric altimeters and a single GPS receiver. All of the sensors communicate to one of two Power and Data Units (PDU's). The PDU's multiplex analog and serial data from the sensors and write the data to the Orion Data Network (ODN). The OIMU s write measurement messages directly as onto the ODN, but they are routed through PDU network switches.

King, Ellis T.↗
NASA NTRS2014

Autonomous Real Time Requirements Tracing

One of the more challenging aspects of software development is the ability to verify and validate the functional software requirements dictated by the Software Requirements Specification (SRS) and the Software Detail Design (SDD). Insuring the software has achieved the intended requirements is the responsibility of the Software Quality team and the Software Test team. The utilization of Timeliner-TLX(sup TM) Auto- Procedures for relocating ground operations positions to ISS automated on-board operations has begun the transition that would be required for manned deep space missions with minimal crew requirements. This transition also moves the auto-procedures from the procedure realm into the flight software arena and as such the operational requirements and testing will be more structured and rigorous. The autoprocedures would be required to meet NASA software standards as specified in the Software Safety Standard (NASASTD- 8719), the Software Engineering Requirements (NPR 7150), the Software Assurance Standard (NASA-STD-8739) and also the Human Rating Requirements (NPR-8705). The Autonomous Fluid Transfer System (AFTS) test-bed utilizes the Timeliner-TLX(sup TM) Language for development of autonomous command and control software. The Timeliner-TLX(sup TM) system has the unique feature of providing the current line of the statement in execution during real-time execution of the software. The feature of execution line number internal reporting unlocks the capability of monitoring the execution autonomously by use of a companion Timeliner-TLX(sup TM) sequence as the line number reporting is embedded inside the Timeliner-TLX(sup TM) execution engine. This negates I/O processing of this type data as the line number status of executing sequences is built-in as a function reference. This paper will outline the design and capabilities of the AFTS Autonomous Requirements Tracker, which traces and logs SRS requirements as they are being met during real-time execution of the targeted system. It is envisioned that real time requirements tracing will greatly assist the movement of autoprocedures to flight software enhancing the software assurance of auto-procedures and also their acceptance as reliable commanders.

Plattsmier, George↗
NASA NTRS2014

Autonomous Real Time Requirements Tracing

One of the more challenging aspects of software development is the ability to verify and validate the functional software requirements dictated by the Software Requirements Specification (SRS) and the Software Detail Design (SDD). Insuring the software has achieved the intended requirements is the responsibility of the Software Quality team and the Software Test team. The utilization of Timeliner-TLX(sup TM) Auto-Procedures for relocating ground operations positions to ISS automated on-board operations has begun the transition that would be required for manned deep space missions with minimal crew requirements. This transition also moves the auto-procedures from the procedure realm into the flight software arena and as such the operational requirements and testing will be more structured and rigorous. The autoprocedures would be required to meet NASA software standards as specified in the Software Safety Standard (NASASTD- 8719), the Software Engineering Requirements (NPR 7150), the Software Assurance Standard (NASA-STD-8739) and also the Human Rating Requirements (NPR-8705). The Autonomous Fluid Transfer System (AFTS) test-bed utilizes the Timeliner-TLX(sup TM) Language for development of autonomous command and control software. The Timeliner- TLX(sup TM) system has the unique feature of providing the current line of the statement in execution during real-time execution of the software. The feature of execution line number internal reporting unlocks the capability of monitoring the execution autonomously by use of a companion Timeliner-TLX(sup TM) sequence as the line number reporting is embedded inside the Timeliner-TLX(sup TM) execution engine. This negates I/O processing of this type data as the line number status of executing sequences is built-in as a function reference. This paper will outline the design and capabilities of the AFTS Autonomous Requirements Tracker, which traces and logs SRS requirements as they are being met during real-time execution of the targeted system. It is envisioned that real time requirements tracing will greatly assist the movement of autoprocedures to flight software enhancing the software assurance of auto-procedures and also their acceptance as reliable commanders

Plattsmier, George I.↗
NASA NTRS1981

Space Shuttle Dynamic Integrated Tests - Concept and results for STS-1

It is pointed out that ground tests, which involve end-to-end checks of various subsystems often by stimulating an input device and examining the resultant effect, do not exercise dynamically all subsystem interactions encountered during a real flight. The development and implementation of the Dynamic Integrated Test (DIT) for the Space Transportation System, patterned on the ASIST (Avionics System Integration Self Test) concept, are examined. It is noted that the complete hardware-software data paths which are utilized in flight simply do not exist until the vehicle is assembled. The integrated test is considered necessary in order to verify the integrity of these paths, that is, to establish that proper connections have been made, that correct polarity is maintained, and that no unexpected interference is generated. As a result of four tests carried out on the Space Transportation System, hardware and software problems, both on-board the vehicle and within the launch support complex, were identified and resolved. Significant return was also realized in the training of the launch and flight crews.

Brody, S.↗
NASA NTRS2021

MBSE Validation and Verification: Case Study for LADEE

The Lunar Atmosphere Dust Environment Explorer (LADEE) mission orbited the moon in order to measure the density, composition, and time variability of the lunar dust environment. The successful mission launched September 7, 2013 and was de-orbited and impacted the moon's surface on April 17, 2014. The ground-side and onboard flight software for the mission was developed using a “Model-Based Software Engineering” (MBSE) methodology combined with strong reuse of Government and Commercial Off-The Shelf (G/COTS) components. Models of the spacecraft and flight software were developed in a graphical dynamics modeling package. Flight Software requirements were prototyped and refined using the simulated models. After the model was shown to work as desired in the simulation framework, C-code software was automatically generated from the models. The auto-generated software was then tested in real-time Processor-in-the-Loop and Hardware-in-the-Loop test beds. “Traveling Road Show” test beds were used for early integration tests with payloads and other subsystems. Traditional techniques for verifying computational sciences models were used to characterize the spacecraft simulation. A lightweight set of formal methods analysis, static analysis, formal inspection, and code coverage analyses were utilized to further reduce defects in the onboard flight software artifacts. These techniques were applied early and often in the development process, iteratively increasing the capabilities of software and fidelity of vehicle models and test beds.

Model-Based Software Engineering, Validation and V↗
NASA NTRS2000

X-33 Leading the Way to VentureStar(Trademark) in this Decade

The X-33, reusable space plane technology demonstrator is on course to begin the flights of the X-33 by the end of 2002 that will serve as a basis for industry and government decisions that could lead to VentureStar(Trademark). Lockheed Martin has placed the VentureStar(Trademark) LLC in it's Space Company and is now competing in an industry wide effort that will permit NASA to select a Second Generation RLV source by 2005. This move provides the focus for firm business planning needed to enable the decision by the time X-33 flies in mid 2002 and possibly with upgraded technologies a year or so later. Since the IAF 50th Congress in Amsterdam, most of the major hardware elements of X-33 have been through their assembly and test. The flight liquid oxygen tank was the first major element to complete final assembly. Aerospike Engine qualification testing has progressed successfully through its test objectives and the two flight engines are in preparation to be delivered to the Assembly Facility in Palmdale. All Thermal Protection System (TPS) metallic panels have completed qualification testing and have been delivered to Palmdale and all remaining TPS elements have been assembled and are ready for delivery. Flight Software and Avionics have been delivered and are in integration testing. In November 1999, the first graphite composite liquid hydrogen tank experienced a debond between the tank inner skin and the honeycomb core in testing. This tank had completed its third successful cryogenic and loads testing at MSFC. Replacement liquid hydrogen tanks have completed design and are in fabrication. The resulting delay from this change of design for the liquid hydrogen tank will be approximately two years.

Austin, Robert E.↗
NASA NTRS2015

ACTE Wing Loads Analysis

The Adaptive Compliant Trailing Edge (ACTE) project modified a Gulfstream III (GIII) aircraft with a new flexible flap that creates a seamless transition between the flap and the wing. As with any new modification, it is crucial to ensure that the aircraft will not become overstressed in flight. To test this, Star CCM a computational fluid dynamics (CFD) software program was used to calculate aerodynamic data for the aircraft at given flight conditions.

CFD↗
NASA NTRS2006

Cooperative Collision Avoidance Step 1 - Technology Demonstration Flight Test Report. Revision 1

The National Aeronautics and Space Administration (NASA) Access 5 Project Office sponsored a cooperative collision avoidance flight demonstration program for unmanned aircraft systems (UAS). This flight test was accomplished between September 21st and September 27th 2005 from the Mojave Airport, Mojave, California. The objective of these flights was to collect data for the Access 5 Cooperative Collision Avoidance (CCA) Work Package simulation effort, i.e., to gather data under select conditions to allow validation of the CCA simulation. Subsequent simulation to be verified were: Demonstrate the ability to detect cooperative traffic and provide situational awareness to the ROA pilot; Demonstrate the ability to track the detected cooperative traffic and provide position information to the ROA pilot; Demonstrate the ability to determine collision potential with detected cooperative traffic and provide notification to the ROA pilot; Demonstrate that the CCA subsystem provides information in sufficient time for the ROA pilot to initiate an evasive maneuver to avoid collision; Demonstrate an evasive maneuver that avoids collision with the threat aircraft; and lastly, Demonstrate the ability to assess the adequacy of the maneuver and determine that the collision potential has been avoided. The Scaled Composites, LLC Proteus Optionally Piloted Vehicle (OPV) was chosen as the test platform. Proteus was manned by two on-board pilots but was also capable of being controlled from an Air Vehicle Control Station (AVCS) located on the ground. For this demonstration, Proteus was equipped with cooperative collision sensors and the required hardware and software to place the data on the downlink. Prior to the flight phase, a detailed set of flight test scenarios were developed to address the flight test objectives. Two cooperative collision avoidance sensors were utilized for detecting aircraft in the evaluation: Traffic Alert and Collision Avoidance System-II (TCAS-II) and Automatic Dependent Surveillance Broadcast (ADS-B). A single intruder aircraft was used during all the flight testing, a NASA Gulfstream III (G-III). During the course of the testing, six geometrically different near-collision scenarios were evaluated. These six scenarios were each tested using various combinations of sensors and collision avoidance software. Of the 54 planned test points 49 were accomplished successfully. Proteus flew a total of 21.5 hours during the testing and the G-III flew 19.8 hours. The testing fully achieved all flight test objectives. The Flight IPT performed an analysis to determine the accuracy of the simulation model used to predict the location of the host aircraft downstream during an avoidance maneuver. The data collected by this flight program was delivered to the Access 5 Cooperative Collision Avoidance (CCA) Work Package Team who was responsible for reporting on their analysis of this flight data.

Trongale, Nicholas A.↗
NASA NTRS2019

Lessons Learned from the Flight Unit Testing of the Near Earth Asteroid Scout Flight System

The Near Earth Asteroid Scout flight mission is set to launch on the maiden voyage of the Space Launch System as a secondary payload. The spacecraft will be jettisoned in cis-lunar space and embark on an ambitious 2.5 year mission to image an asteroid. The spacecraft is uniquely equipped with an 85m2 solar sail as the main propulsion system. The monolithic sail system is designed to package within a 6U volume for launch and then deploy during flight. The NEA Scout team has presented in the past to the International Symposium on Solar Sailing topics related to the engineering development unit and design efforts to achieve flight hardware build. This paper will focus on the lessons learned from building and testing the NEA Scout flight system. Focus will be on the mechanical, software, and electrical interfaces as well as preparation for subsystem environmental tests, including thermal vacuum. Due to the unique design of the spacecraft, the solar sail subsystem was required to be located in the center of the spacecraft. This requirement lead to design challenges such as designing and accommodating critical cable harnesses to run through the center of the sail subsystem, packaging and deployment design of the sail subsystem, and integrated testing efforts through an avionics test bed to verify and validate a complete system architecture.

Lockett, Tiffany Russell↗
NASA NTRS2016

Topic Modeling of NASA Space System Problem Reports: Research in Practice

Problem reports at NASA are similar to bug reports: they capture defects found during test, post-launch operational anomalies, and document the investigation and corrective action of the issue. These artifacts are a rich source of lessons learned for NASA, but are expensive to analyze since problem reports are comprised primarily of natural language text. We apply topic modeling to a corpus of NASA problem reports to extract trends in testing and operational failures. We collected 16,669 problem reports from six NASA space flight missions and applied Latent Dirichlet Allocation topic modeling to the document corpus. We analyze the most popular topics within and across missions, and how popular topics changed over the lifetime of a mission. We find that hardware material and flight software issues are common during the integration and testing phase, while ground station software and equipment issues are more common during the operations phase. We identify a number of challenges in topic modeling for trend analysis: 1) that the process of selecting the topic modeling parameters lacks definitive guidance, 2) defining semantically-meaningful topic labels requires nontrivial effort and domain expertise, 3) topic models derived from the combined corpus of the six missions were biased toward the larger missions, and 4) topics must be semantically distinct as well as cohesive to be useful. Nonetheless,topic modeling can identify problem themes within missions and across mission lifetimes, providing useful feedback to engineers and project managers.

Data Mining↗
NASA NTRS1990

Flight Dynamics Analysis System

Flight Dynamics Analysis System (FDAS) collection of computer programs provides environment for configuration and study of Ada software. Designed to support flight-dynamics research and analysis activities concerning software models, algorithms, and techniques used within flight Dynamics Division at Goddard Space Flight Center. Assists analysts and programmers in building, testing, and evaluating applications software by providing integrated support system for modification and reconfiguration of software. Includes capability of assembling reusable software components into applications programs, and reconfiguring assembled program after partially or fully completed. Developed in Ada for use on DEC VAX computer operating under VMS 4.3 or higher and version 1.3 or higher of VAX Ada Compilation System (ACS).

Tasaki, Keiji↗
NASA NTRS2024

Crew Health and Performance Integrated Data Architecture (CHP-IDA) TechPort May 2024

Future exploration missions to Mars will have increased need for crew autonomy. Crew Health & Performance (CHP) related data on the ISS is currently, manually downlinked and in disparate locations, which limits crew autonomy for future missions. The CHP-IDA project is developing a backend data system platform that grants the ability to seamlessly collect, store, process, and display CHP-related data for exploration missions. This platform allows for integration of data and advanced analytics that offer crew and ground teams better insight into the crew’s health and performance. It also enables applications that can improve the crew’s ability to provide more autonomous medical care during exploration missions. Data will be collected automatically to reduce crew and ground team time and effort and will synchronize across all in-mission vehicles, habitats, and ground as communication delay permits. The Human Research Program’s (HRP) Medical Data Architecture (MDA) project focused on this backend data architecture but for medical data only. The CHP-IDA project, a joint effort between HRP’s Exploration Medical Capability (ExMC) element and the Exploration Medical Integrated Product Team (XMIPT), expands this capability to all relevant CHP-related data. The additional inputs from nutrition, environment, exercise, radiation, and any other relevant sources will give more insight into crew’s health and performance. Currently, the Human Systems Engineering and Integration Division at Johnson Space Center (JSC) is designing the system. The team completed a system requirements review (SRR) in FY22 and now the focus is on core software development, testbed buildup, and use case scenario demonstration. An end-to-end demonstration with multiple data sources across CHP domains is schedule for the end of FY24 where all three focus areas will be displayed. Following this ground demo, the software will be completed, tested, and validated for flight.

Courtney M Schkurko↗
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.↗