Flight packaged onboard checkout systems development unit. Software documentation, overall specification, level 2 - Test Oriented Onboard Language system /TOOL/
Test Oriented Onboard Language /TOOL/ system for spacecraft checkout
Source record↗
SEARCH · Engineering Papers
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.
Integration of the Remote Agent for the NASA Deep Space One Autonomy Experiment
This paper describes the integration of the Remote Agent (RA), a spacecraft autonomy system which is scheduled to control the Deep Space 1 spacecraft during a flight experiment in 1999. The RA is a reusable, model-based autonomy system that is quite different from software typically used to control an aerospace system. We describe the integration challenges we faced, how we addressed them, and the lessons learned. We focus on those aspects of integrating the RA that were either easier or more difficult than integrating a more traditional large software application because the RA is a model-based autonomous system. A number of characteristics of the RA made integration process easier. One example is the model-based nature of RA. Since the RA is model-based, most of its behavior is not hard coded into procedural program code. Instead, engineers specify high level models of the spacecraft's components from which the Remote Agent automatically derives correct system-wide behavior on the fly. This high level, modular, and declarative software description allowed some interfaces between RA components and between RA and the flight software to be automatically generated and tested for completeness against the Remote Agent's models. In addition, the Remote Agent's model-based diagnosis system automatically diagnoses when the RA models are not consistent with the behavior of the spacecraft. In flight, this feature is used to diagnose failures in the spacecraft hardware. During integration, it proved valuable in finding problems in the spacecraft simulator or flight software. In addition, when modifications are made to the spacecraft hardware or flight software, the RA models are easily changed because they only capture a description of the spacecraft. one does not have to maintain procedural code that implements the correct behavior for every expected situation. On the other hand, several features of the RA made it more difficult to integrate than typical flight software. For example, the definition of correct behavior is more difficult to specify for a system that is expected to reason about and flexibly react to its environment than for a traditional flight software system. Consequently, whenever a change is made to the RA it is more time consuming to determine if the resulting behavior is correct. We conclude the paper with a discussion of future work on the Remote Agent as well as recommendations to ease integration of similar autonomy projects.
Dorais, Gregory A.↗
Challenges of the Cassini Test Bed Simulating the Saturnian Environment
The Cassini-Huygens mission is a joint NASA and European Space Agency (ESA) mission to collect scientific data of the Saturnian system and is managed by the Jet Propulsion Laboratory (JPL). After having arrived in Saturn orbit and releasing the ESA's Huygens probe for a highly successful descent and landing mission on Saturn's moon Titan, the Cassini orbiter continues on its tour of Saturn, its satellites, and the Saturnian environment. JPL's Cassini Integrated Test laboratory (ITL) is a dedicated high fidelity test bed that verifies and validates command sequences and flight software before upload to the Cassini spacecraft. The ITL provides artificial stimuli that allow a highly accurate hardware-in-the-loop test bed model that tests the operation of the Cassini spacecraft on the ground. This enables accurate prediction and recreation of mission events and flight software and hardware behavior. As we discovered more about the Saturnian environment, a combination of creative test methods and simulation changes were necessary to simulate the harmful effect that the optical and physical environment has on the pointing performance of Cassini. This paper presents the challenges experienced and overcome in that endeavor to simulate and test the post Saturn Orbit Insertion (SOI) and Probe Relay tour phase of the Cassini mission.
Titan atmospheric drag↗
Power, Avionics and Software - Phase 1.0:
This report describes Power, Avionics and Software (PAS) 1.0 subsystem integration testing and test results that occurred in August and September of 2013. This report covers the capabilities of each PAS assembly to meet integration test objectives for non-safety critical, non-flight, non-human-rated hardware and software development. This test report is the outcome of the first integration of the PAS subsystem and is meant to provide data for subsequent designs, development and testing of the future PAS subsystems. The two main objectives were to assess the ability of the PAS assemblies to exchange messages and to perform audio testing of both inbound and outbound channels. This report describes each test performed, defines the test, the data, and provides conclusions and recommendations.
Communiocations↗
Robotic Lunar Lander Development Status
NASA Marshall Space Flight Center and John Hopkins University Applied Physics Laboratory have developed several mission concepts to place scientific and exploration payloads ranging from 10 kg to more than 200 kg on the surface of the moon. The mission concepts all use a small versatile lander that is capable of precision landing. The results to date of the lunar lander development risk reduction activities including high pressure propulsion system testing, structure and mechanism development and testing, and long cycle time battery testing will be addressed. The most visible elements of the risk reduction program are two fully autonomous lander flight test vehicles. The first utilized a high pressure cold gas system (Cold Gas Test Article) with limited flight durations while the subsequent test vehicle, known as the Warm Gas Test Article, utilizes hydrogen peroxide propellant resulting in significantly longer flight times and the ability to more fully exercise flight sensors and algorithms. The development of the Warm Gas Test Article is a system demonstration and was designed with similarity to an actual lunar lander including energy absorbing landing legs, pulsing thrusters, and flight-like software implementation. A set of outdoor flight tests to demonstrate the initial objectives of the WGTA program was completed in Nov. 2011, and will be discussed.
Ballard, Benjamin↗
NASA's Robotic Lunar Lander Development Program
NASA Marshall Space Flight Center and the Johns Hopkins University Applied Physics Laboratory have developed several mission concepts to place scientific and exploration payloads ranging from 10 kg to more than 200 kg on the surface of the moon. The mission concepts all use a small versatile lander that is capable of precision landing. The results to date of the lunar lander development risk reduction activities including high pressure propulsion system testing, structure and mechanism development and testing, and long cycle time battery testing will be addressed. The most visible elements of the risk reduction program are two fully autonomous lander flight test vehicles. The first utilized a high pressure cold gas system (Cold Gas Test Article) with limited flight durations while the subsequent test vehicle, known as the Warm Gas Test Article, utilizes hydrogen peroxide propellant resulting in significantly longer flight times and the ability to more fully exercise flight sensors and algorithms. The development of the Warm Gas Test Article is a system demonstration and was designed with similarity to an actual lunar lander including energy absorbing landing legs, pulsing thrusters, and flight-like software implementation. A set of outdoor flight tests to demonstrate the initial objectives of the WGTA program was completed in Nov. 2011, and will be discussed.
Ballard, Benjamin W.↗
Implications of Responsive Space on the Flight Software Architecture
The Responsive Space initiative has several implications for flight software that need to be addressed not only within the run-time element, but the development infrastructure and software life-cycle process elements as well. The runtime element must at a minimum support Plug & Play, while the development and process elements need to incorporate methods to quickly generate the needed documentation, code, tests, and all of the artifacts required of flight quality software. Very rapid response times go even further, and imply little or no new software development, requiring instead, using only predeveloped and certified software modules that can be integrated and tested through automated methods. These elements have typically been addressed individually with significant benefits, but it is when they are combined that they can have the greatest impact to Responsive Space. The Flight Software Branch at NASA's Goddard Space Flight Center has been developing the runtime, infrastructure and process elements needed for rapid integration with the Core Flight software System (CFS) architecture. The CFS architecture consists of three main components; the core Flight Executive (cFE), the component catalog, and the Integrated Development Environment (DE). This paper will discuss the design of the components, how they facilitate rapid integration, and lessons learned as the architecture is utilized for an upcoming spacecraft.
Wilmot, Jonathan↗
Space Station integration and verification concepts
The TAVERNS concept for the integration, verification, and maintenance of the Space Station avionics and payload systems is described. The functional requirements which TAVERNS integrates are discussed, showing the mode of integration and the flight systems integration. The top and bottom TAVERNS sections are described, and the use of TAVERNS to develop software required for flight applications and testing is discussed.
Chevers, Edward S.↗
The development of an air motion measurement system for NASA's Electra aircraft
The development of the Turbulent Air Motion Measurement System (TAMMS), which is to measure dynamical and photochemical processes over a wide range of spatial and temporal scales, is examined. The composition and operation of the TAMMS subsystems, which include (1) fast-response meteorological sensors; (2) a boom/inertial navigation system; (3) baseline meteorological sensors; (4) an analog/digital interface; (5) control and data acquisition; and (6) data/reduction and spectral analysis software, are described. The planned flight testing and calibration of the TAMMS are discussed. The TAMMS platform wil be able to estimate the turbulent fluxes of heat, moisture, momentum, and any chemical species for which fast-response instrumentation is available.
Ritter, J.↗
An Immunized Aircraft Maneuver Selection System
The objective of this project, as stated in the original proposal, was to develop an immunized aircraft maneuver selection (IAMS) system. The IAMS system was to be composed of computational and informational building blocks that resemble structures in natural immune systems. The ultimate goal of the project was to develop a software package that could be flight tested on aircraft models. This report describes the work performed in the first year of what was to have been a two year project. This report also describes efforts that would have been made in the final year to have completed the project, had it been continued for the final year. After introductory material is provided in Section 2, the end-of-year-one status of the effort is discussed in Section 3. The remainder of the report provides an accounting of first year efforts. Section 4 provides background information on natural immune systems while Section 5 describes a generic ar&itecture developed for use in the IAMS. Section 6 describes the application of the architecture to a system identification problem. Finally, Section 7 describes steps necessary for completing the project.
Karr, Charles L.↗
MER : from landing to six wheels on Mars ... twice
Application of the Pathfinder landing system design to enclose the much larger Mars Exploration Rover required a variety of Rover deployments to achieve the surface driving configuration. The project schedule demanded that software design, engineering model test, and flight hardware build to be accomplished in parallel. This challenge was met through (a) bounding unknown environments against which to design and test, (b) early mechanical prototype testing, (c) constraining the scope of on-board autonomy to survival-critical deployments, (d) executing a balance of nominal and off-nominal test cases, (e) developing off-nominal event mitigation techniques before landing, (f) flexible replanning in response to surprises during operations. Here is discussed several specific events encountered during initial MER surface operations.
Mars Exploration Rover (MER)↗
SEXTANT - Station Explorer for X-ray Timing and Navigation Technology
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, which is scheduled to launch in late 2016 and will be hosted as an externally attached payload on the International Space Station (ISS) via the ExPRESS Logistics Carrier (ELC). During NICER's 18-month baseline science mission to understand ultra-dense matter though observations of neutron stars in the soft X-ray band, SEXTANT will, for the first-time, demonstrate real-time, on-board X-ray pulsar navigation, which is a significant milestone in the quest to establish a GPS-like navigation capability that will be available throughout our Solar System and beyond. Along with NICER, SEXTANT has proceeded through Phase B, Mission Definition, and received numerous refinements in concept of operation, algorithms, flight software, ground system, and ground test capability. NICER/SEXTANT's Phase B work culminated in NASA's confirmation of NICER to Phase C, Design and Development, in March 2014. Recently, NICER/SEXTANT successfully passed its Critical Design Review and SEXTANT received continuation approval in September 2014. In this paper, we describe the X-ray pulsar navigation concept and provide a brief history of previous work, and then summarize the SEXTANT technology demonstration objective, hardware and software components, and development to date.
X-rays↗
An Autonomous sUAS Operating in UTM TCL4+ and STEReO Fire Scenario
This study presents a sUAS payload point design that enables autonomous BVLOS flightin UTM TCL4+ urban environments and STEReO fire responses. The payload components include an onboard computer, 360 deg LIDAR, range finder altimeter, downward-facing monocular camera, forward-facing thermal and visible light dual camera, vehicle-to-vehicle radio modem, and Li-ion smart battery. The components are mounted on an enclosed structural frame that was designed in-house. Placing the autonomy components onboard leverages the advantages of sUAS over manned aircraft such as low-cost, quick response time, and increased scalability. Autonomous capabilities include object and fire detection, V2V communication, embedded processing, and SLAM. Data processing is conducted on-board the aircraft to eliminate the dependency on a ground station downlink. The payload is evaluated in both software simulation as well as flight tests.
Autonomous UAS↗
Orion Hardware In The Loop OIMU Stimulation Latency Effect on Navigation State Estimation
Because Hardware In The Loop (HITL) testing involves the integration of flight software and flight hardware on the ground, non-flight-like effects may arise. One of these non-flight-like effects includes Inertial Measurement Unit (IMU) stimulation latency that affects the time in which the measurement is received by the Extended Kalman Filter (EKF). This paper seeks to present the extent to which this stimulation latency affects the navigational state estimate from the Orion navigation system for all phases of flight for Artemis II.
Christopher A Ertl↗
Orion Hardware In The Loop OIMU Stimulation Latency Effect on Navigation State Estimation
Because Hardware In The Loop (HITL) testing involves the integration of flight software and flight hardware on the ground, non-flight-like effects may arise. One of these non-flight-like effects includes Inertial Measurement Unit (IMU) stimulation latency that affects the time in which the measurement is received by the Extended Kalman Filter (EKF). This paper seeks to present the extent to which this stimulation latency affects the navigational state estimate from the Orion navigation system for all phases of flight for Artemis II.
Christopher A Ertl↗
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↗
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.↗
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↗