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 217 records · Page 12
All sourcesNASA NTRSDOE OSTI
NASA NTRS2011

Updates on HRF Payloads Operations in Columbus ATCS

The NASA developed Human Research Facility 1 (HRF1) and Human Research Facility (HRF2) experiment racks have been operating in the European Space Agency (ESA) Columbus module of the International Space Station (ISS) since Summer 2008. The two racks are of the same design. Since the start of operations, unexpected pressure spikes were observed in the Columbus module's thermal-hydraulic system during the racks activation sequence. The root cause of these spikes was identified in the activation command sequence in the Rack Interface Controller (RIC), which controls the flow of thermal-hydraulic system fluid through the rack. A new Common RIC Software (CRS) release fixed the bug and was uploaded on both racks in late 2009. This paper gives a short introduction to the topic, describes the Columbus module countermeasures to mitigate the spikes, describes the ground validation test of the new software, and describes the flight checks performed before and after the final upload. Finally, the new on-orbit test designed to further simplify the racks hydraulic management is presented.

DePalo, Savino↗
NASA NTRS1983

Galileo attitude and articulation control subsystem closed loop testing

In order to ensure the reliable operation of the Attitude and Articulation Control Subsystem (AACS) which will guide the Galileo spacecraft on its two and one-half year journey to Jupiter, the AACS is being rigorously tested. The primary objectives of the test program are the verification of the AACS's form, fit, and function, especially with regard to subsystem external interfaces and the functional operation of the flight software. Attention is presently given to the Galileo Closed Loop Test System, which simulates the dynamic and 'visual' flight environment for AACS components in the laboratory.

Lembeck, M. F.↗
NASA NTRS1993

An assessment of space shuttle flight software development processes

In early 1991, the National Aeronautics and Space Administration's (NASA's) Office of Space Flight commissioned the Aeronautics and Space Engineering Board (ASEB) of the National Research Council (NRC) to investigate the adequacy of the current process by which NASA develops and verifies changes and updates to the Space Shuttle flight software. The Committee for Review of Oversight Mechanisms for Space Shuttle Flight Software Processes was convened in Jan. 1992 to accomplish the following tasks: (1) review the entire flight software development process from the initial requirements definition phase to final implementation, including object code build and final machine loading; (2) review and critique NASA's independent verification and validation process and mechanisms, including NASA's established software development and testing standards; (3) determine the acceptability and adequacy of the complete flight software development process, including the embedded validation and verification processes through comparison with (1) generally accepted industry practices, and (2) generally accepted Department of Defense and/or other government practices (comparing NASA's program with organizations and projects having similar volumes of software development, software maturity, complexity, criticality, lines of code, and national standards); (4) consider whether independent verification and validation should continue. An overview of the study, independent verification and validation of critical software, and the Space Shuttle flight software development process are addressed. Findings and recommendations are presented.

Source record↗
NASA NTRS1995

Parameter identification and modeling of longitudinal aerodynamics

Using a comprehensive flight test database and a parameter identification software program produced at NASA Ames Research Center, a math model of the longitudinal aerodynamics of the Harrier aircraft was formulated. The identification program employed the equation error method using multiple linear regression to estimate the nonlinear parameters. The formulated math model structure adhered closely to aerodynamic and stability/control theory, particularly with regard to compressibility and dynamic manoeuvring. Validation was accomplished by using a three degree-of-freedom nonlinear flight simulator with pilot inputs from flight test data. The simulation models agreed quite well with the measured states. It is important to note that the flight test data used for the validation of the model was not used in the model identification.

Aksteter, J. W.↗
NASA NTRS2011

NASA Technology Demonstrations Missions Program Overview

The National Aeronautics and Space Administration (NASA) Fiscal Year 2010 (FY10) budget introduced a new strategic plan that placed renewed emphasis on advanced missions beyond Earth orbit. This supports NASA s 2011 strategic goal to create innovative new space technologies for our exploration, science, and economic future. As a result of this focus on undertaking many and more complex missions, NASA placed its attention on a greater investment in technology development, and this shift resulted in the establishment of the Technology Demonstrations Missions (TDM) Program. The TDM Program, within the newly formed NASA Office of the Chief Technologist, supports NASA s grand challenges by providing a steady cadence of advanced space technology demonstrations (Figure 1), allowing the infusion of flexible path capabilities for future exploration. The TDM Program's goal is to mature crosscutting capabilities to flight readiness in support of multiple future space missions, including flight test projects where demonstration is needed before the capability can transition to direct mission The TDM Program has several unique criteria that set it apart from other NASA program offices. For instance, the TDM Office matures a small number of technologies that are of benefit to multiple customers to flight technology readiness level (TRL) 6 through relevant environment testing on a 3-year development schedule. These technologies must be crosscutting, which is defined as technology with potential to benefit multiple mission directorates, other government agencies, or the aerospace industry, and they must capture significant public interest and awareness. These projects will rely heavily on industry partner collaboration, and funding is capped for all elements of the flight test demonstration including planning, hardware development, software development, launch costs, ground operations, and post-test assessments. In order to inspire collaboration across government and industry, more than 70% of the TDM funds will be competitively awarded as a result of yearly calls for proposed flight demonstrators and selected based on possible payoff to NASA, technology maturity, customer interest, cost, and technical risk reduction. This paper will give an overview of the TDM Program s mission and organization, as well as its current status in delivering advanced space technologies that will enable more flexible and robust future missions. It also will provide several examples of missions that fit within these parameters and expected outcomes.

Turner, Susan↗
NASA NTRS2012

NASA's Robotic Lunar Lander Development Project

Since early 2005, NASA's Robotic Lunar Lander Development (RLLD) office at NASA MSFC, in partnership with the Applied Physics Laboratory (APL), has developed mission concepts and preformed risk-reduction activities to address planetary science and exploration objectives uniquely met with landed missions. The RLLD team developed several concepts for lunar human-exploration precursor missions to demonstrate precision landing and in-situ resource utilization, a multi-node lunar geophysical network mission, either as a stand-alone mission, or as part of the International Lunar Network (ILN), a Lunar Polar Volatiles Explorer and a Mercury lander mission for the Planetary Science decadal survey, and an asteroid rendezvous and landing mission for the Exploration Precursor Robotics Mission (xPRM) office. The RLLD team has conducted an extensive number of risk-reduction activities in areas common to all lander concepts, including thruster testing, propulsion thermal control demonstration, composite deck design and fabrication, and landing leg stability and vibration. In parallel, the team has developed two robotic lander testbeds providing closed-loop, autonomous hover and descent activities for integration and testing of flight-like components and algorithms. A compressed-air test article had its first flight in September 2009 and completed over 150 successful flights. This small test article (107 kg dry/146 kg wet) uses a central throttleable thruster to offset gravity, plus 3 descent thrusters (~37lbf ea) and 6 attitude-control thrusters (~12lbf ea) to emulate the flight system with pulsed operation over approximately 10s of flight time. The test article uses carbon composite honeycomb decks, custom avionics (COTS components assembled in-house), and custom flight and ground software. A larger (206 kg dry/322 kg wet), hydrogen peroxide-propelled vehicle began flight tests in spring 2011 and fly over 30 successful flights to a maximum altitude of 30m. The monoprop testbed also uses a central gravity-canceling thruster and 3 descent thrusters, but has 12 attitude-control thrusters and a maximum flight time of over a minute. The testbed uses aluminum ortho-grid decks, an LN200-1 IMU, Roke Manor Radar Altimeter, Illunis optical cameras, Novatel Pro-Pak GPS truth data system, Pressure transducers & thermocouples for housekeeping, "In-Control" ground system software, and the core Flight Executive (cFE) modular software environment. The peroxide lander testbed is able to accept other sensors and algorithms for testing, both from within NASA and from other customers. Through these activities, the RLLD team has significantly reduced technical risks for all small and medium class robotic landers for the Moon and other airless planetary bodies.

Cohen, Barbara A.↗
NASA NTRS2011

Evolution of the Space Shuttle Primary Avionics Software and Avionics for Shuttle Derived Launch Vehicles

As a result of recommendation from the Augustine Panel, the direction for Human Space Flight has been altered from the original plan referred to as Constellation. NASA s Human Exploration Framework Team (HEFT) proposes the use of a Shuttle Derived Heavy Lift Launch Vehicle (SDLV) and an Orion derived spacecraft (salvaged from Constellation) to support a new flexible direction for space exploration. The SDLV must be developed within an environment of a constrained budget and a preferred fast development schedule. Thus, it has been proposed to utilize existing assets from the Shuttle Program to speed development at a lower cost. These existing assets should not only include structures such as external tanks or solid rockets, but also the Flight Software which has traditionally been a "long pole" in new development efforts. The avionics and software for the Space Shuttle was primarily developed in the 70 s and considered state of the art for that time. As one may argue that the existing avionics and flight software may be too outdated to support the new SDLV effort, this is a fallacy if they can be evolved over time into a "modern avionics" platform. The technology may be outdated, but the avionics concepts and flight software algorithms are not. The reuse of existing avionics and software also allows for the reuse of development, verification, and operations facilities. The keyword is evolve in that these assets can support the fast development of such a vehicle, but then be gradually evolved over time towards more modern platforms as budget and schedule permits. The "gold" of the flight software is the "control loop" algorithms of the vehicle. This is the Guidance, Navigation, and Control (GNC) software algorithms. This software is typically the most expensive to develop, test, and verify. Thus, the approach is to preserve the GNC flight software, while first evolving the supporting software (such as Command and Data Handling, Caution and Warning, Telemetry, etc.). This can be accomplished by gradually removing the "support software" from the legacy flight software leaving only the GNC algorithms. The "support software" could be re-developed for modern platforms, while leaving the GNC algorithms to execute on technology compatible with the legacy system. It is also possible to package the GNC algorithms into an emulated version of the original computer (via Field Programmable Gate Arrays or FPGAs), thus becoming a "GNC on a Chip" solution where it could live forever to be embedded in modern avionics platforms.

Ferguson, Roscoe C.↗
NASA NTRS2006

NASA Crew Launch Vehicle Flight Test Process

In response to the Vision for Space Exploration, the National Aeronautics and Space Administration (NASA) has defined a new space exploration architecture to return humans to the Moon and to prepare for human exploration of Mars. One of the first new developments will be the Crew Launch Vehicle (CLV) , which will carry the Crew Exploration Vehicle (CEV) into Low Earth Orbit (LEO) to support International Space Station (ISS) missions and, later, to support lunar missions. As part of the CLV development, NASA will perform a series of CLV flight tests. The tests will provide data that will inform the engineering and design process and verify the flight hardware and software. In addition, the data gained from the flight tests will be used to certify the new CLV/CEV vehicle for human space flight. This paper will provide an overview of the CLV flight test process and details of the individual flight tests

Davis, Stephan R.↗
NASA NTRS1982

Mission Control Center operations for the Space Transportation System

Orbital flight tests of the Space Shuttle Program involved three types of activities, including classic flight testing of the vehicle hardware and software, operational procedures evaluation and development, and performance of payload mission operations. This combination of activities required a capability of the Mission Control Center (MCC) to provide thorough support to the Orbiter and its crew across a broad spectrum of activities. Attention is given to MCC organization, the general functions performed by the MCC teams, a flight support description, the motivation for a change in MCC operations, support elements, orbit phase functions, and dynamic flight phase functions. It is pointed out that the MCC facilities for the operational mode of support will not be fully implemented until 1984.

Frank, M. P.↗
NASA NTRS2003

A Distributed Simulation Software System for Multi-Spacecraft Missions

The paper will provide an overview of the web-based distributed simulation software system developed for end-to-end, multi-spacecraft mission design, analysis, and test at the NASA Goddard Space Flight Center (GSFC). This software system was developed for an internal research and development (IR&D) activity at GSFC called the Distributed Space Systems (DSS) Distributed Synthesis Environment (DSE). The long-term goal of the DSS-DSE is to integrate existing GSFC stand-alone test beds, models, and simulation systems to create a "hands on", end-to-end simulation environment for mission design, trade studies and simulations. The short-term goal of the DSE was therefore to develop the system architecture, and then to prototype the core software simulation capability based on a distributed computing approach, with demonstrations of some key capabilities by the end of Fiscal Year 2002 (FY02). To achieve the DSS-DSE IR&D objective, the team adopted a reference model and mission upon which FY02 capabilities were developed. The software was prototyped according to the reference model, and demonstrations were conducted for the reference mission to validate interfaces, concepts, etc. The reference model, illustrated in Fig. 1, included both space and ground elements, with functional capabilities such as spacecraft dynamics and control, science data collection, space-to-space and space-to-ground communications, mission operations, science operations, and data processing, archival and distribution addressed.

Burns, Richard↗
NASA NTRS2003

An Internet Protocol-Based Software System for Real-Time, Closed-Loop, Multi-Spacecraft Mission Simulation Applications

The paper will provide an overview of the web-based distributed simulation software system developed for end-to-end, multi-spacecraft mission design, analysis, and test at the NASA Goddard Space Flight Center (GSFC). This software system was developed for an internal research and development (IR&D) activity at GSFC called the Distributed Space Systems (DSS) Distributed Synthesis Environment (DSE). The long-term goal of the DSS-DSE is to integrate existing GSFC stand-alone test beds, models, and simulation systems to create a "hands on", end-to-end simulation environment for mission design, trade studies and simulations. The short-term goal of the DSE was therefore to develop the system architecture, and then to prototype the core software simulation capability based on a distributed computing approach, with demonstrations of some key capabilities by the end of Fiscal Year 2002 (FY02). To achieve the DSS-DSE IR&D objective, the team adopted a reference model and mission upon which FY02 capabilities were developed. The software was prototyped according to the reference model, and demonstrations were conducted for the reference mission to validate interfaces, concepts, etc. The reference model, illustrated in Fig. 1, included both space and ground elements, with functional capabilities such as spacecraft dynamics and control, science data collection, space-to-space and space-to-ground communications, mission operations, science operations, and data processing, archival and distribution addressed.

Davis, George↗
NASA NTRS1991

A ground test program to support condition monitoring of a spacecraft attitude control propulsion system

The Comet Rendezvous Asteroid Flyby (CRAF) mission involves seven years of flight from 0.6 to 4.57 Astronomical Units (AU), followed by about 915 days of maneuvering around a comet. Ground testing will characterize the very critical attitude control system thrusters' fuel consumption and performance for all anticipated fuel temperatures over thruster life. The ground test program characterization will support flight condition monitoring. A commercial software application hosted on a commercial microcomputer will control ground test operations and data acquisition using a newly designed thrust stand. The data acquisition and control system uses a graphics-based language and features a visual interface to integrate data acquisition and control.

Clark, Douglas J.↗
NASA NTRS1983

Forecasting trends in NASA flight software development tools

The experience gained in the design and development of Shuttle flight and ground support embedded software systems along with projections of increasing role and size of software in the proposed Space Station and other future NASA projects provides the basis for forecasting substantial changes in the tools and methodologies by which embedded software systems are developed and acquired. Similar changes in software architectures and operator interfaces will lead to substantial changes in the approach and techniques involved in software test and system integration. Increasing commonality among different flight systems and between flight and supporting ground systems is projected, along with a more distributed approach to software acquisition in highly complex projects such as Space Station.

Garman, J. R.↗
NASA NTRS2002

Software Development and Test Methodology for a Distributed Ground System

The Marshall Space Flight Center's (MSFC) Payload Operations Center (POC) ground system has evolved over a period of about 10 years. During this time the software processes have migrated from more traditional to more contemporary development processes in an effort to minimize unnecessary overhead while maximizing process benefits. The Software processes that have evolved still emphasize requirements capture, software configuration management, design documenting, and making sure the products that have been developed are accountable to initial requirements. This paper will give an overview of how the Software Processes have evolved, highlighting the positives as well as the negatives. In addition, we will mention the COTS tools that have been integrated into the processes and how the COTS have provided value to the project.

Ritter, George↗
NASA NTRS2003

Aerostructures Test Wing

The Aerostructures Test Wing (ATW) was an apparatus used in a flight experiment during a program of research on aeroelastic instabilities. The ATW experiment was performed to study a specific instability known as flutter. Flutter is a destructive phenomenon caused by adverse coupling of structural dynamics and aerodynamics. The process of determining a flight envelope within which an aircraft will not experience flutter, known as flight flutter testing, is very dangerous and expensive because predictions of the instability are often unreliable. The ATW was a small-scale airplane wing that comprised an airfoil and boom (see upper part of Figure 1). For flight tests, the ATW was mounted on the F-15B/FTF-II testbed, which is a second-generation flight-test fixture described in Flight-Test Fixture for Aerodynamic Research (DRC- 95-27), NASA Tech Briefs, Vol. 19, No. 9, September 1995, page 84. The ATW was mounted horizontally on this fixture, and the entire assembly was attached to the undercarriage of the F-15B airplane (see lower part of Figure 1). The primary objective of the ATW project was to investigate traditional and advanced methodologies for predicting the onset of flutter. In particular, the ATW generated data that were used to evaluate a flutterometer. This particular flutterometer is an on-line computer program that uses method analysis to estimate worst-case flight conditions associated with flutter. This software was described in A Flutterometer Flight Test Tool NASA Tech Briefs, Vol. 23, No. 1, January 1999, page 52.

Lind, RIck↗
NASA NTRS2020

Antenna and Flight Control Software for Conformal Phased Array Antenna Design (CPAAD)

The National Aeronautics and Space Administration (NASA) is developing lightweight conformal phased array antenna designs (CPAAD) for beyond line of sight communications [1]. The CPAAD system is developed to address reliable and affordable autonomous next generation aviation systems. The technology takes advantage of newly assigned provisional Ku-bands for UAVs. The antenna design is unique to avoid interference with the ground and the unconventional substrate reduces weight. The surface mounted conformal design allows for reduced drag during flight. The software developed for the CPAAD system operates the antenna hardware and provides a graphic user interface (GUI) for ground testing and flight operations.

phased array antenna control software↗
NASA NTRS1993

Reduced gravity multibody dynamics testing

The Final Report on reduced gravity multibody dynamics testing is presented. Tests were conducted on board the NASA KC-135 RGA in Houston, Texas. The objective was to analyze the effects of large angle rotations on flexible, multi-segmented structures. The flight experiment was conducted to provide data which will be compared to the data gathered from ground tests of the same configurations. The flight and ground tested data will be used to validate the TREETOPS software, software which models dynamic multibody systems, and other multibody codes. The flight experiment consisted of seven complete flights on board the KC-135 RGA during two one-week periods. The first period of testing was 4-9 Apr. 1993. The second period of testing was 13-18 Jun. 1993.

Sillanpaa, Meija↗
NASA NTRS2005

An Overview of the Guided Parafoil System Derived from X-38 Experience

The NASA Johnson Space Center built a 4200 sq ft parafoil for the U.S. Army Natick Soldier Center to demonstrate autonomous flight using a guided parafoil system to deliver 10,000 lbs of useable payload. The parafoil's design was based upon that developed during the X-38 program. The drop test payload consisted of a standard 20-foot Type V airdrop platform, a standard 12-foot weight tub, a 60 ft drogue parachute, a 4200 ft2 parafoil, an instrumentation system, and a Guidance, Navigation, and Control (GN&C) system. Instrumentation installed on the load was used to gather data to validate simulation models and preflight loads predictions and to perform post flight trajectory and performance reconstructions. The GN&C system, developed during NASA's X-38 program, consisted of a flight computer, modems for uplink commands and downlink data, a compass, laser altimeter, and two winches. The winches were used to steer the parafoil and to perform the dynamic flare maneuver for a soft landing. The laser was used to initiate the flare. The GN&C software was originally provided to NASA by the European Space Agency. NASA incorporated further software refinements based upon the X-38 flight test results. Three full-scale drop tests were conducted, with the third being performed during the Precision Airdrop Technology Conference and Demonstration (PATCAD) Conference at the U.S. Army Yuma Proving Ground (YPG) in November of 2003. For the PATCAD demonstration, the parafoil and GN&C software and hardware performed well, concluding with a good flare and the smallest miss distance ever experienced in NASA's parafoil drop test program. This paper describes the 4200 sq ft parafoil system, simulation results, and the results of the drop tests.

Stein, Jenny M.↗